Restic: すべてのデータを別のリポジトリにコピーするコマンドを追加

これは、1つのリポジトリ（A）から新しいリポジトリ（B）への1回限りのコピーを処理することを目的としていますか？ または、これは、最後の同期以降に（A）と（B）の間で変更されたコンテンツの「同期」または更新を実行することによって、より一般的になることを意味しますか？

現時点では、これは1回限りのコピーのみを処理することを目的としているため、ユーザーは別の場所にある別のリポジトリに、または新しいマスターキーを使用して移行できます。

インターネット接続が遅いので、s3や別の場所にできるだけ効率的にバックアップできるようにしたいと思います。

@witeshadowデータはマスターA 'を使用してリポジトリAで暗号化され、別のマスター

私が考えることができる唯一の最適化は、ホスト、パス、およびタグのフィルターを使用して、ソースリポジトリAに選択基準を設定することです。これにより、すべてをコピーする必要がなくなります。 ただし、それはユースケースによって異なります。

@ fd0この機能リクエストへの投票を追加したかっただけです。 それを実現するために私にできることはありますか？

あなたはそれを実装することができます...機能自体を行うのは難しいことではありません、2つのバックエンドを構成することは難しいことです。 複数のバックエンドへのアクセスはサポートされていません（たとえば、 $B2_ACCOUNT_ID 1つしかない）...したがって、この機能は適切な構成ファイルに依存すると思います（＃16を参照）。

AとBの2つのリポジトリがあり、A-> Bを同期して、プロセスの終了後にBのblob（およびスナップショット）のセットがAのblobのセットのスーパーセットになるようにするとします。 。

したがって、両方のリポジトリを開き、それぞれのインデックスファイルをロードします。 次に、ブロブごとにAのインデックスを繰り返し処理し、ブロブがBにも含まれているかどうかを確認します。これが当てはまる場合は、次へ進みます。 誤りの場合は、ダウンロード、復号化、暗号化してBにアップロードします。

最後は、スナップショットファイルをコピーすることです。 Aのスナップショットファイルごとに、ファイルを復号化し、B用に再度暗号化し、そこに保存すれば完了です。

私が言ったように、技術的な実装はかなり簡単です:)

素晴らしい！ ヒントをありがとう。 私はこのかゆみを持っているので、それを掻く時間を作ることができるかどうかを確認します-しかし、短期的には、このrestic merge機能なしで行かなければなりません。 私がやる前に誰かがそれに到達した場合、それは問題ありません-または私は最終的にこれに戻って回ります！

私はすでに実装されていると思います... / meは頭をかいてそれを探します...
... https://github.com/middelink/restic/tree/fix-323
それでもコンパイルできるかどうかを確認する必要がありますが、そのブランチは228コミット遅れています...

完全なコピーだけでなく、スナップショットのサブセットも許可すると便利な場合があります。 これは、＃1910で提案されているユースケース（プライマリリポジトリへのバックアップが頻繁にあり、そこからオフサイト/低速/より高価なストレージへのバックアップの頻度が少ない）をサポートし、フルコピーよりも実装がそれほど難しくないと思います。 ただし、将来的に追加される可能性があります:-)

エラー…開発スキルのない単なるユーザーが@middelinkの提案をコンパイルして試すためのニュースはありますか？

これは主に「私も」コメントですが、「すべてコピー」または「同期」セマンティクスではなく、特定のスナップショットのみを1つのリポジトリから別のリポジトリにコピーする機能が必要です。 たとえば、ローカルストレージに毎日バックアップを作成し、週に1回、最新の毎日のみをs3バケットにコピーします。

運が良ければ、私のコピーcmdは1つ以上のスナップショットIDを取得します。 実際、すべてをコピーすることは、それが行うことではありません。 最初にスナップショットIDをリストしてから、「resticcopy」コマンドラインでそれらを連結する必要があります。 私はこれを退化したユースケースと見なしているので、私はそれで問題ありません。

これを深く掘り下げることなく、おそらくncw / rcloneとのいくつかの議論が役立つかもしれません...

マージ/コピー機能にも興味があります。中央リポジトリにマージ/コピーしたいUSBスティック上のリポジトリがあります（同じパスワード）。
これに関するニュースはありますか？

フォークブランチがmasterに更新されたようですが、PRはまだありません。

@middelinkコードは完成/マージ可能ですか？ そうでない場合でも、何をする必要がありますか？ これは私が本当に欲しい機能です:)

@ theoretical2019コード自体は完成していますが、公式PRを作成するために座るたびに、準備が整う前にやらなければならないことを見つけ続けています。 ドキュメントのように、未リリース/変更ログのように...
ああ、そしてテスト！ 私はテストについて言及しましたか？ テストが必要です：P

@middelink Fyi、アップストリームマスターにリベースしてブランチをテストしましたが、かなりうまく機能しています。 同じホスト、タグ、日付で新しいスナップショットを作成しました：+1：
PRを待っています：tada：

このような機能を使用して、最初のリポジトリがメンテナンス（プルーンなど）のためにロックされている場合にのみクライアントが使用するセカンダリリポジトリを作成できます。 また、プルーニングタスクは、セカンダリの終了後にコピーをトリガーできるため、バックアップが失われることはなく、バックアップサービスのダウンタイムはゼロになります。

@middelinkコードのPRを作成して、メンテナによる編集も

重要なことは、作業する基本PRを取得することです。 私はあなたの素晴らしい仕事を動かしてもらいたいです、そして私が思う他の人もそうします:) PRを作成するのに助けが必要な場合は私に知らせてください！

@rawtazもちろんです。 同期させてください。 どういうわけか、早くそうする時間が見つかりませんでしたが、今は時間があったようです。

みなさん、ありがとうございました！

ドキュメントで回答されていない質問が1つ残っています（少なくとも私にとっては）：両方をプルーニングする必要がありますか、それともソースでそれを実行するだけで十分ですか？スナップショットの削除が伝播されますか？

@lfrancke copyコマンドを使用する場合、コピーするスナップショットを具体的にリストします。 その他、既存のスナップショット、存在しないスナップショット、および以前は存在していたが現在はプルーニングされており、もはや存在しないスナップショットの両方は適用されません。

スナップショットをレポAからレポBにコピーしてから、レポAでそれらを忘れてプルーニングした場合、スナップショットはレポBで自動的に忘れられてプルーニングされないため、レポBで自分で行う必要があります。

すばらしい、迅速で役立つ応答をありがとう@rawtaz 。