Restic: 不完全なスナップショットからのデータ。

ああ、うーん。 特定のファイルが必要ですか、それとも「そこにあるすべてのデータ」だけが必要ですか？ データはそこにあり、resticにはそれを引き出すためのすべての手段がありますが、それはresticの周りでスクリプトを作成するか（非常に遅くなります）、resticのカスタムコードを追加することを意味します。

正直な質問：あなたにとってデータはどれほど重要ですか？ 今日は、何かを一緒にハッキングするために時間を費やすことができます。これにより、リポジトリにアップロードされたほぼすべてのデータにアクセスできるようになりますが、ほとんどのコードほど「本番環境に対応」していない可能性があります。 :)

データは私にとって非常に重要であり、残念ながら他のコピーはありません。 それは理想的ではないことはわかっていますが、それは私が解決しようとしていた問題でした。 ボリュームをオンラインに戻そうとするハードウェアの修正を進めていますが、現時点ではあまり期待できそうにありません。 ディレクトリを指定して、そのディレクトリ内のすべてにアクセスしてダウンロードできる方法があれば、それは深刻な命の恩人になるでしょう。 それは大量のデータ（その多くはビデオプロジェクトです）なので、より速いオプションが望ましいでしょう。 そうは言っても、どれだけの作業が必要かはよくわかりませんし、フリーソフトウェアであることに感謝していますが、これが可能になれば非常にありがたいです。

わかりました。何ができるかわかります。

どうもありがとうございます。

restic rebuild-index実行することから始めることができるので、リポジトリ内のすべてのパックをカバーする新しいインデックスがあります。

今すぐ始めましょう。

わあ、それはあなたの@ fd0にとても寛大です。

これに関連するテストを手伝うことができたら、私に知らせてください。

restic rebuild-indexはレポパスワードを要求する必要がありますか？ まだです。 リポジトリ内のデータ量が多いため、かなり時間がかかるのではないかと思います。 週末中、または必要に応じて来週まで実行できることに完全に満足しています。 長期間無人のままにする前に、パスワードが不要であることを確認したいだけです。

うーん、早い段階でパスワードを要求する必要があります。 リポジトリ内のすべてのファイルのすべてのヘッダーを復号化する必要があります。 環境変数RESTIC_PASSWORDエクスポートしているので、パスワードは必要ありませんか？

早い段階で次のようなものを印刷する必要があります。

repository ed6136ad opened successfully, password is correct

少なくともインタラクティブに実行する場合（stdoutをログファイルにリダイレクトしない）。

アップロードされたデータの最後の15分間がそれほど重要でない場合は、 rebuild-indexスキップすることもできます。これは、後でいつでも行うことができます。

RESTIC_PASSWORD環境変数を設定していませんが、設定してコマンドを実行します。 約10分間何も返さなかったので、 ctrl-cを渡して再試行しました。 私の構文は正しいですよね？ restic -r b2:MY_BUCKET_NAME:/ rebuild-indexいずれにせよ、最後の15分間のデータは、アップロードされたデータの合計に比べて非常に小さいはずなので、後でこれに戻って完全に満足しています。

では、まだrebuild-index実行しないでください。そうすれば、リカバリコードを試すことができます:)

ブランチrecover-dataにコミットをプッシュし、restic（ go run build.go ）をビルドして、次のように呼び出します。

$ restic -r b2:MY_BUCKET_NAME:/ recover

次に、リポジトリ内のすべてのツリーを一覧表示し、ルートツリーを見つけて、すべてのルートツリーを参照する新しいスナップショットを作成する必要があります。

repository abe002d6 opened successfully, password is correct
load index files
load 543 trees
tree (543/543)
done
found 2 roots
save tree with 2 nodes
saved new snapshot 26f25bf1

次に、復元できるスナップショット（この場合は26f25bf1 ）を作成するか、 restic mountを使用してスナップショットを参照します。 リストすることもできます：

$ restic ls -l 26f25bf1 /
repository abe002d6 opened successfully, password is correct
snapshot aac6d0ed of [/recover] filtered by [/] at 2018-08-23 22:23:56.903268714 +0200 CEST):
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /0b9e25fb
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /d0d9386a

最上位のディレクトリはツリーIDにちなんで名付けられているため、少しわかりにくいですが、次のレベルのディレクトリには通常の名前が付いています。

それがあなたを助けるかどうか私に知らせてください！

それで、少し背景の話を追加するために：私はgithubの問題を読んでから、シャワーを浴びに行き、「うーん、それはそれほど難しいことではない」と思いました。 結局、私は正しかったが、そうではなかった。 この機能が他の人に役立つ場合は、後で適切なコマンドに変えることができますが、今のところはそれが機能し、B2にすでにアップロードされているデータにアクセスできることを願っています。

どのくらいのデータでしたか？ どのくらい回復しましたか？

幸運を！

うわー！ それは速かった！ どうもありがとうございます！ リポジトリのクローンを作成したばかりで、今すぐビルドを試みます。 また、rebuild-indexが機能しなかった理由もわかりました。 サーバーが接続されているネットワーク上のDNSの問題でした。 私はそれを修正してFatal: unable to create lock in backend: repository is already locked by PID 41208取得したので、結局、アップロードが正常に停止しなかったようです。 unlockコマンドは、upおよびrebuild-indexが現在実行中であることをクリアしたようです。

今日はできる限りのことをしますが、週末にミシガン州北部に向けて約15分で出発します。そこでは、インターネットアクセスがあまり良くないと思います。 これは私が戻ってきた月曜日に私の完全な注意を引くでしょう、そして私はあなたにもっと詳細を得るでしょう:-)

どうもありがとうございました！ ぶら下げて申し訳ありませんが、月曜日にご連絡いたします。

この機能が他の人に役立つ場合は、後で適切なコマンドに変えることができます

私はできる限りこれを手伝いたいです。 ここでのアップロード速度は1Mbpsであるため、最初のバックアップには最大3〜6か月かかる場合があります。 あなたが言うように、それがそれほど難しくない場合は特に、完了する前に復元する方法があることは優れた機能です。 私がどのように役立つことができるか教えてください！ これに取り組んでくれてありがとう！ ：D

また、あなたのソリューションは非常に素晴らしいと思います。 エレガントでかなりシンプル。

ぶら下げて申し訳ありませんが、月曜日にご連絡いたします。

それについて心配しないでください、それがうまくいくかどうか私はただ興味があります：サングラス：

データはB2で安全であり、消えることはありません。 recoverコマンドでさえデータを変更せず、データを読み取り、別のファイルとスナップショットを追加するだけです。それだけです。

したがって、少し背景を説明します（後でブログ投稿に展開します）：内部では、resticリポジトリには、 snapshotやdataなどのさまざまな種類のファイルが含まれています。

• dataファイルには、短いtreeまたはdataブロブが多数含まれており、ファイルの内容と場所を正確に説明するヘッダーが最後にあります。
• snapshotファイルには、スナップショットを説明する小さなJSONドキュメントが含まれています。これはtreeを参照します。

ファイルをresticで保存すると、ファイルはdataブロブに分割され、リポジトリ内の1つ以上のファイルにまとめて保存されます。 次に、ファイルの名前とdata BLOBへの参照（ID）のリストがツリーに保存されます。 ディレクトリのアーカイブが完了すると、ファイルのリスト（ dataブロブの名前と参照）がtreeブロブとして別のdataファイルに保存されます。

サブディレクトリの場合、resticは、サブディレクトリの名前を、コンテンツを説明するtree blobの参照とともに別のtree格納します。

restic backup実行の最後に、他のツリーによって参照されていないルートtreeがありますが、すべてのトップレベルツリーへのすべての参照が含まれているため、（間接的に）すべてのファイルへの参照が含まれています。およびバックアップのサブディレクトリ。 最後のステップとして、 resticは、ルートtreeを参照する新しいsnapshotファイルを作成します。

resticに特定のスナップショットを忘れるように指示すると、ルートツリーは参照されなくなります。 restic pruneはこれを検出し、ツリーと他のすべての不要なtreeおよびdataブロブを削除します。

一般に、 treeは、リポジトリ内のすべてのファイルとサブディレクトリが正常に保存された場合にのみリポジトリに保存されます。 したがって、 tree BLOBが存在するとすぐに、それが参照するデータ（サブディレクトリを含む）も存在すると想定できます。

バックアップ中にresticが中止されると、リポジトリ内に多数のtreeブロブが、それらが参照するファイル内のデータとともに存在します。 したがって、データを回復するために、resticは以下を実行するだけで済みます。

• すべてのツリーIDのリストを作成し、参照されているツリーをメモします（最初はなし）。
• 各ツリーについて：
  
  
  
  • ツリーをロードする
  
  
  • ツリーのエントリごとに：
    
    
    
    
    
    • がディレクトリの場合、別のツリーを参照し、そのツリーをリストで参照されているものとしてマークします
    
    
    
  
  

次に、木のリストをもう一度調べて、参照されているものをすべて破棄します。 残りのツリーはルートツリーです。これは、スナップショットによって直接参照されている（または参照されている）ツリー、またはrestic backup実行が中止された結果として「ぶら下がっている」ツリーを意味します。

最後のステップとして、すべてのルートツリーを一覧表示する新しいツリーを作成し、それをリポジトリに保存してから、この新しいツリーを参照する新しいスナップショットを作成します。

その後、ディレクトリの不可解な名前（見つかったルートツリーの短いツリーID）を除いて、この新しいスナップショットを通常どおりに使用できます。

これをマスターにマージする前に、次のことを行う必要があると思います。

• recoverオプションを追加して、既存のスナップショットによって参照されるルートツリーを除外します。これにより、実際にぶら下がっているルートツリーのみが取得されます。 たぶん、この振る舞いはデフォルトでさえあるはずです、ほとんどのユーザーはおそらく既存のスナップショットを通してアクセスできるデータにそれほど興味がありません…
• また、参照されていないdata BLOBを新しいスナップショットで使用できるようにして、ユーザーがtreeオブジェクトにまだ含まれていないファイルの一部をつなぎ合わせることができるようにします。
• 新しいツリーと新しいスナップショットの両方に適切なメタデータを設定します。 現時点では、それは非常に醜いです（それが機能するのに十分なだけです）。
• より良い進捗報告、それは今非常にハッキーです

これに関する小さな更新：先週の木曜日に出発する前にrebuild-indexを開始しました。 それは私がread: connection reset by peer戻る前に死にました。 昨日、b2への並列接続の数を増やして再起動しましたが、正常に動作しているようです。 現在は5％に過ぎませんが、しばらく時間がかかると思います。 b2バケットには約90TBが含まれており、バックアップしていたディレクトリにはおそらく約110〜120TBが含まれていました。

アップロード中、resticが非常に安定していたことに正直に感銘を受けました。 私はresticを試す前にMac用のcloudberryを試しましたが、それほど多くのデータで動作させることができませんでした。 私は自宅でラップトップをバックアップするためにresticを使用していますが、それが大好きなので、これを試してみようと思いました。 最初のアップロードも完了していないので、 pruneようなものがどうなるかわかりませんが、大量のデータでresticがどのように動作するかに関するデータが必要な場合は、最新情報をお知らせします。 。 毎週のバックアップを1週間以内に維持するために必要なすべての操作を完了することができれば、これらのバックアップを処理するための優れた候補になると思います。

とりあえず、いくつか質問があります。 recoverを試す前に、このrebuild-index実行して完了する必要がありますか？ そうしないと何かを失うでしょうか？ 私はこれについて考えていて、これだけのデータで実行するには時間がかかるので、可能であれば最初にできるだけ回復したいと思いますが、これを殺したほうがよい場合は、 recover実行しますrebuild-index後で、私はそれを行うことができます。 rebuild-indexまたはrecoverを--quietフラグで実行すると、 backupコマンドの場合と同じように速度が上がりますか？

うんいいね！ 次のことをお勧めします。

• rebuild-index中止します
• restic recover実行します
• 新しく作成されたスナップショットに含まれるデータを確認してください

試してみたい場合は、 rebuild-index再度実行して、残りのメガバイトのデータをリポジトリから取得できます。 おそらくそれは数百メガバイト未満であり、これによってスナップショットにまだ含まれていない新しいデータが明らかにならない可能性があります。 しかし、あなたはそれを試すことができます:)

rebuild-index実行中は、リポジトリにアクセスできません。

再構築インデックスを実行するか、-quietフラグを使用して回復すると、バックアップコマンドの場合と同じように速度が向上しますか？

いいえ。

私は物事を一晩実行させました、そしてそれはハードドライブをいっぱいにして失敗したようです：

found 755 roots Fatal: unable to save new tree to the repo: fs.TempFile: open /var/folders/tq/67qp8py137n_5nzf563qlylr0000gn/T/restic-temp-pack-913168611: no space left on device

この操作でダウンロードする必要のあるデータの量を知る簡単な方法や、ダウンロードする量を減らす方法はありますか？

また、このディスク領域を解放したい場合は、 restic cache --cleanupその方法ですか？

いいえ、30日間使用されていないキャッシュディレクトリのみが削除されます。 キャッシュディレクトリを削除するだけです。これは、ホームディレクトリのどこかにあるはずです。

どのコマンドを正確に実行しましたか？ rebuild-indexとrecoverはどちらも、メタデータキャッシュを除いて、ハードディスクに多くのデータを保存しないはずです...

現時点では私の机にはありません。 しかし、それは次のようなもの./restic -o b2.connections=x -r b2:mybucket:/ recover ： -o b2.connections=xビットなしで再起動できます。 キャッシュディレクトリを見つけて削除しました。

まず第一に、素晴らしいツールです。
また、低速の接続を介してテラバイトのデータをバックアップする必要があり、まだ完了していないのにバックアップが失敗する可能性があります。 一度に数個のファイルのみをバックアップするための推奨される方法はありますか？

一度に数個のファイルのみをバックアップするための推奨される方法はありますか？

通常は機能しますが（聞いたことがあります）、ソースデータの個々の部分（単一のディレクトリなど）を保存し、それが完了すると、すべてのディレクトリを一緒に保存します。 ソースデータが変更されていない場合、組み込みの重複排除により、resticはほとんど何もアップロードしないはずです。

そのような質問のためのより良い場所はhttps://forum.restic.netのフォーラムであり、質問（そして答え！）はそこではるかに発見可能です。

@pauletgでは、どうでしたか？

＃2056で新しいコマンドrecoverを提案しました。

前回の投稿以来、レスティックの回復についてはあまり進んでいません。 幸いなことに、サーバーを復活させることができ、クラッシュしてもデータが損なわれなかったので、データを入手できました。 回復コマンドは、完了する前に、私のマシンのHDを埋めているようです。 これは、いくつかの要因が原因である可能性があります。バックアップが膨大で、アップロードにb2への接続を多数使用しており、リカバリに使用していたマシンのHDが比較的小さかった。 私のバックアップがもっと妥当なサイズであれば、おそらくうまくいくと確信しています。 あなたに役立つ情報が他にあるかどうか教えてください。 これに取り組んでいただきありがとうございます。この機能をラップトップのバックアップに使用できるのは本当に素晴らしいことです。

フィードバックをお寄せいただきありがとうございます！ 必要に応じて（そして時間があれば）、 --no-cacheでこれを再試行できますが、さらに時間がかかります。 ＃2056がマージされたら、この問題を解決します。

追加のフィードバックがある場合はお知らせください。 :)