ヘッダーを前に移動するかどうかはわかりません。 これは現在実装されていないことは知っていますが、ローカルリポジトリの場合、最後にヘッダーがあるということは、ファイルのコピーを保存できることを意味します。

興味深い点、ありがとう。 何が良いかを判断する方法はまだわかりません。 リモートバックエンドの場合は、（バックエンドインターフェイスにいくつかの変更を加えた後） io.Readerを渡すだけで、stdlibがsendfileを使用してファイルをディスクから直接ストリーミングすることもできます。 うーん。

参考までに、なぜGCMを使用しないのか疑問に思っていたので、ベンチマークを実行しました。 CPUにAES-NIがない場合、AES-CTR + Poly1305はかなり高速です（Go組み込みGCMよりも50％高速です）。 AES-NIを使用すると、GoのGCM用に最適化されたアセンブリコードはおそらく無敵です。

Intel Xeon E312xx

restic:
BenchmarkEncrypt-4        50      32470322 ns/op     258.35 MB/s

stupidgcm:
Benchmark4kEncStupidGCM-4     200000         10620 ns/op     385.67 MB/s
Benchmark4kEncGoGCM-4         300000          5540 ns/op     739.22 MB/s

Intel Pentium G630（AES-NIなし）

restic:
BenchmarkEncrypt-2            10     108468078 ns/op      77.34 MB/s

stupidgcm:
Benchmark4kEncStupidGCM-2          50000         24182 ns/op     169.38 MB/s
Benchmark4kEncGoGCM-2              20000         96391 ns/op      42.49 MB/s

これはこの問題には属していませんが、とにかく答えます：

私がresticを始めたとき、Goには最適化されたバージョンのGCMがなかったと思います。 さらに、GCMを理解できなかったため、使い心地が悪くなりましたが、Poly1305の用紙の方がはるかに読みやすく、理解しやすかったです。

あなたのベンチマークははるかに小さなデータのブロブを処理していると思います。ブロブが大きいほど、より近くなるかもしれません。

分かりました。 ええ、最適化されたGCMはごく最近のもので、CloudflareがGo1.5に寄付したと思います。

ブロックサイズに関しては、resticベンチマークは8 MiBを使用し、stupidgcmは4kiBを使用します。 stupidgcmに対して8MiBのブロックサイズで再試行しましたが、結果は実質的に同じです。

ですから、これに時間を無駄にしないようにしましょう。CTR+Poly1305は十分に高速だと思います。

インデックスファイルまたはパックフッターに非圧縮サイズを含めることは重要ですか？ ブロブ内でしかわからなくても大丈夫だと思います。そうすれば、レスティックで必要な変更は少なくなります。 この追加の場所で新しい機能を認識できるようになりますか？

私の意見では、リポジトリ形式2 ==BLOBデータの最初のバイトは圧縮形式を示しています。必要なのはそれだけです。 おそらく、255の可能な形式の1つは、{64ビットの非圧縮長}{圧縮データ}である可能性があります。

バックアップにはエラー訂正が良い考えだと思います。 しかし、私はそれがファイルシステムの責任だと思います。 また、restic内にRAIDを実装しますか？

インデックスファイルまたはパックフッターに非圧縮サイズを含めることは重要ですか？

はい：パックヘッダーはパックの内容を記述し、これは抽出プロセスに何を期待するかを指示します（圧縮アルゴリズム、非圧縮サイズ、および後で暗号化に使用されたキーなどの他の属性に関して）。 同じことがインデックスに表示される必要があります。これは、resticがパックヘッダー内のすべてのblobを検索する必要がないように導入されたものです。 したがって、同じ情報がそこに存在する必要があります。

私の意見では、リポジトリ形式2 ==BLOBデータの最初のバイトは圧縮形式を示しています。必要なのはそれだけです。 おそらく、255の可能な形式の1つは、{64ビットの非圧縮長}{圧縮データ}である可能性があります。

このアイデアは好きではありません。ファイル形式がより複雑になります。BLOBの先頭とヘッダーの2つの異なる場所に制御情報があります。 ヘッダーは、正確には制御情報を含む場所です。

バックアップにはエラー訂正が良い考えだと思います。 しかし、私はそれがファイルシステムの責任だと思います。

原則として私は同意しますが、ファイルシステムは非常に複雑なものであり、エラーの伝播（たとえば、メディアの読み取り/書き込みエラー）はしばしば最適ではありません。 大幅に削減された（冗長性の観点から、たとえば重複排除された）バックアップデータの場合でも、エラー訂正の別のレイヤーを追加する（または追加することを提案する）ことをお勧めします。

リードソロモンコードの場合、 https：//github.com/klauspost/reedsolomonにいくつかのパフォーマンスデータを含む純粋なGo実装があります。

https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank_html/によると、ZFECの方が高速であるはずです。 実装はhttps://gitlab.com/zfec/go-zfecにあり、https：//pypi.python.org/pypi/zfecに基づいているようです。

ECCは圧縮後に適用され、通常はデータファイルにインターリーブされます。これは、データが信頼性の低い、またはノイズの多い通信チャネルを介して転送される場合、ECCを配布するとECCがより堅牢になるためです。

Usenetバイナリグループでは、ECC情報を含む個別のファイル（https://en.wikipedia.org/wiki/Parchiveを参照）を使用します。 これにより、リポジトリレイアウトに別のサブディレクトリが追加され、リポジトリ管理情報（config、index、...）にECCを適用することも簡単になります。 しかし、そのようにするとECCスキーマが弱くなるかどうかはわかりません（ECC情報内のクラスターエラーに対する堅牢性が低下する可能性があります）。

ヒントをありがとう。 私はここで論文のPDFバージョンを見つけました： https ：//www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank.pdf

ZFEC Goの実装は、Cライブラリのラッパーにすぎません。

ZFECの場合、[https://github.com/korvus81/jfec]にjfecという名前の追加（ゴルーチンの使用）が追加されたGoポートがあります。

新しいリポジトリ形式の実装を追跡するために「プロジェクト」（GitHubに最近追加されたもの）を追加しました： https ：//github.com/restic/restic/projects/3

下位互換性を破るときに調べることができるいくつかのアイデア：

• sha256からsha512に変更します

sha256の代わりにsha512（またはsha512 / 256）を使用すると、バックアップ速度が向上しますか？ 私が見る限り、これはARMを除くほとんどのプラットフォームに当てはまります。

Syncthingディスカッション（https://github.com/syncthing/syncthing/issues/582）

ボーグディスカッション（https://github.com/jborg/attic/issues/209）

sha512 / 256に関する論文（https://eprint.iacr.org/2010/548.pdf）

• 単純なパスワードの代わりに公開鍵暗号化を使用する

現在、リポジトリへの書き込みにアクセスできるすべての人が、リポジトリからの読み取りにアクセスできます。 公開鍵暗号化はこれを排除し、ハッシュに基づく重複排除を可能にします。

公開鍵暗号化をデータBLOBに適用することは機能しますが、resticがツリー構造を処理する方法に精通しておらず、そのためにも正常に実装できるかどうかを知ることができません。 それはおそらく多くの複雑さをもたらす可能性があります。 データブロブのみが非表示になっている場合でも、ツリーには多くの情報があります。

NaCl- https://godoc.org/golang.org/x/crypto/nacl/box

• リポジトリの識別

現在、リポジトリに出くわしたときに、resticリポジトリを見ていることを知る方法はありません。 現在、キーファイルで"created":"TIMESTAMP","username":"XXXXX","hostname":"XXXXX"をリークしています。 この情報を非表示にして、代わりにrestic repository version Xなどのresticに関する情報を含めることをお勧めします。 READMEと同じくらい簡単かもしれません。

以前の議論について; 私は、何らかの形のエラー訂正を実装することに非常に賛成です。

@oysolsアイデアを追加していただきありがとうございます！

以下に私の考えを追加します：

sha256からsha512に変更（速度用）

現時点では、速度には関心がないので（レスティックはすでに非常に高速です）、少なくとも私にとっては、このアイテムの優先度は低くなっています。 SIMD対応プロセッサ用に最適化されたバージョンのSHA256もあり、簡単に切り替えることができます。 一方、resticを高速化することを決定し、ハッシュについて説明する場合は、おそらくKeccak（SHA3）またはBlake2をお勧めします。これらは（私が知る限り、まだベンチマークを実行していません）はるかに高速。

それで、私の観点から、このアイテムは今のところ延期されています。

単純なパスワードの代わりに公開鍵暗号化を使用する

この機能は計画されていますが（＃187を参照）、複雑であり、多くの検討といくつかの主要なインフラストラクチャの変更が必要です。 また、これを延期し、すべてを変更するものではなく、より小さな増分更新を実行したい->延期します。

リポジトリの識別（READMEファイルをリポジトリに追加します）

非常に良い点です。何も壊さずに追加することもできます。

リポジトリの「情報漏えい」（キーファイルからユーザー名、ホスト名、作成されたタイムスタンプを削除）

それも良い点です。 現在、この情報は、 key listコマンドのキーIDと一緒に表示するためにのみ使用されています。 usernameとhostは簡単に削除できます。タイムスタンプは多くの情報を提供しません。ほとんどの場合、ファイルの作成日と同じになります。

usernameとhostをドロップして、作成したタイムスタンプを残しておきたいのですが。

今日はhttps://github.com/klauspost/reedsolomonで遊んだことがありますが、パックファイルの最後にエラー訂正コードを簡単に追加できると思います（パックヘッダーをファイルの先頭に移動すると） ）。 ただし、2つの欠点があります。

• リードソロモンに選択したパラメータに応じて、ファイルサイズは約14〜30％増加します
• パックファイルのセクションのチェックサム（必ずしも暗号化ハッシュである必要はありません）をパックファイル自体に保存する必要があります。再構築のアルゴリズムではファイルのどの部分が破損しているかを知る必要があるため、これらは再構築に必要です。 したがって、高速チェックサム（CRCなど）を使用することもできますが、計算には少し時間がかかります。

考え？

それでは、データロッド保護はオプションでしょうか？ サイズが限界以上に大きくなっていると思います（信じていますが、他の人にとっては素晴らしい機能です！）

これを少し試してみましょう。ECCと圧縮を組み合わせたときにリポジトリがどれだけ大きくなるか（または小さくなるか）を感じることができます。 たぶん、2種類のコードを追加します。1つはパックヘッダー用で、もう1つ（おそらくオプション）はデータ用です。

ユーザー名とホストを削除します

いい考えのようですね。 情報を保持したい場合は、マスターキーと同じ方法で、別の暗号化されたフィールドに追加できます。

ECC：ファイルサイズは約14〜30％増加します。

パックファイル自体にECCを含めるのは良い考えではないと思います。 これらは通常の復元シナリオでは役に立たず、パックファイルが破損している場合にのみ使用されます。

パリティデータを別のディレクトリに配置することをお勧めします。

repo/data/1e/1ef7267...
repo/parity/1e/1ef7267...

• パリティは完全にオプションであり、バックアップ後に作成される場合があります。
• 復元操作の速度低下はありません。 復元に追加の帯域幅は必要ありません。
• 同一のファイル名を使用すると、正しいパリティデータを簡単に識別できます。 これは、パリティデータがそれ自体のsha256ハッシュにちなんで名付けられていないことを意味しますが、追加のインデックスは必要ありません。 （とにかく、パリティデータの検証はパックファイルを検証することによって行う必要があります。）
• ユーザーは、パリティデータの量を把握できます。

それがどのように実装されていても、 圧縮と暗号化の多くの層があるので、ある種のECCが必要だと思います。 1つの間違ったビットは多くの問題を引き起こす可能性があります。

コメントありがとうございます。ディスカッションを、作成したばかりの別の問題＃804に移しましょう。

Resticの前方誤り訂正コードについて2つのグループが互いに話し合っているという印象を受けずにはいられません。 あるグループは、レポをビットロットから（ただ）保護したいと考えています。これは、単一のビットフリップでも、重複していないレポで大きな問題を引き起こす可能性があるためです。 もう1つのグループは、イレイジャーコードを使用して、リポジトリを複数の障害ドメイン（RAID以外のディスクなど）に分散させたいと考えています。 どちらの目標もリードソロモンコードで実現できますが、必要なパラメーターとストレージレイアウトが異なります。

Pythonスクリプト（https://github.com/oysols/restic-python）を使用してリポジトリのクイックチェックを実行しました。

header_length:        8688549
tree_length:         53898054
data_length:     146443506727
treeblobs:               8466
datablobs:             200975
packfiles:              29351
---- repo size by dir ----
            155   config
146 510 470 574   data
     27 538 629   index
          4 545   keys
          4 243   locks
         14 041   snapshots
          4 096   tmp
-----
Currently 116071 original files contained in the backup.

146 GBのバックアップのうち、ツリーBLOBはわずか54 MBであり、圧縮を実装すると、元のスペースの約3分の1まで適切に圧縮されます。

ツリーBLOBをデータBLOBから分離することで、パフォーマンスが向上しますか？

復元中に実行される操作のほとんどは、実際にデータを復元する前に、ツリーブロブに基づいて実行されるようです。 それらを別々のパックファイルに分離すると、バックアップのツリーを解析するためにダウンロードする必要のあるデータの量を最小限に抑えることができます。 ツリーBLOBのサイズが小さい場合、復元プロセスを開始する前にすべてのツリーBLOBをダウンロードする方が高速な場合があります。

もちろん; この分布は、すべてのリポジトリで同じではない場合があります。

これはさらに調査する価値があると思いますか？

ツリーBLOBをデータBLOBから分離することで、パフォーマンスが向上しますか？

たぶん、これは私が将来に向けて考えている最適化の1つです。

これとは別に、メタデータ用のローカルキャッシュも追加して、リポジトリからフェッチする必要がまったくないようにします。 これにより、多くの操作の速度が大幅に向上するはずです。

ツリーBLOBをデータBLOBから分離することで、パフォーマンスが向上しますか？

これにより、理論的にpruneの操作が改善される可能性があります。これは、ツリーBLOBとデータBLOBが別々のパックファイルにある場合に必要な再パックが少なくなるためです（古いパックファイルを再パックする代わりに大規模に削除できる可能性があります）。

私はすでに＃842の間にそれを見ています

gcm vs ctr： http ://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html

sym vs asym：アイデアは、「セッション」キーをpubkey-encryptすることですよね？

今のところ延期されているので、この問題では暗号について議論しないでください。 非対称暗号の議論に関連する問題は＃187です。 また、ユースケースが確定するまで、ハイレベルな議論を続けていきたいと思います。 次に、低レベルの暗号について話すことができます。

キーファイルからユーザー名とホスト名を削除します。

巨大なメタデータリーク！
たとえば、 "username":"WorldBank\\JimYongKim"は、上位の所有者を明確に示します。

2017年1月に最初のWindowsバイナリがコンパイルされてから、これが_削除_（または_暗号化_）されるのを待っています。
幸い、プライバシーを意識したフェローにResticをアップロードまたは推奨する前に、バックアップを調べました。

編集：ユーザーのタイムゾーンもプレーンテキストで記載されており、機密保持の原則にも反しています。

Re：SHA3-採用する価値がない理由についての1つの意見があります（まだ？）： https ：//www.imperialviolet.org/2017/05/31/skipsha3.html

したがって、SHA-3はおそらく使用すべきではないと思います。 SHA-2に勝る魅力的な利点はなく、多くのコストがかかります。 私が信じることができる唯一の議論は、バックアップハッシュ関数があるのはいいことですが、SHA-256とSHA-512の両方が一般的にサポートされており、コアが異なります。 したがって、すでに2つの安全なハッシュ関数がデプロイされており、もう1つは必要ないと思います。

私は投稿を読み、aglの議論を理解しました。 Resticの場合、これはそれほど重要ではありません。暗号化プロトコルの構成要素としてではなく、ハッシュ関数を使用してブロブを（一意に）識別しています。 他のハッシュ関数を調べる私の考えは、特にローエンドシステムでは、SHA-256の計算が遅いということでした。 他のハッシュ関数ははるかに高速です（例：blake2）。

これがレポ形式のものかどうかわからない：暗号化をオプションにするのはどうですか？ すでに暗号化されたディスクがある信頼できるバックアップサーバーに保存されるバックアップを考えています。

@mschiffその議論については、＃1018を参照してください。 ;）

パーツサイズをオプションにしてみませんか？
現在、ファイルごとに4〜6MBあります。 ファイルは少ないが大きいほど、リモートバックアップははるかに高速になります。

@ fd0は書いた：

現時点では、速度には関心がないので（レスティックはすでに非常に高速です）、少なくとも私にとっては、このアイテムの優先度は低くなっています。 SIMD対応プロセッサ用に最適化されたバージョンのSHA256もあり、簡単に切り替えることができます。 一方、resticを高速化することを決定し、ハッシュについて説明する場合は、おそらくKeccak（SHA3）またはBlake2をお勧めします。これらは（私が知る限り、まだベンチマークを実行していません）はるかに高速。

より高速でCPU負荷の少ないハッシュアルゴリズム（Blake2など）に関するもう1つの考慮事項は、電源に接続されていないときにバックアップを作成するときのラップトップのバッテリー使用量を減らすことです。

最初の投稿への返信：

キーファイルからユーザー名とホスト名を削除します。

これは、キー名またはある種の説明に置き換えられますか？ 異なるキーを区別する何らかの方法（たとえば、あるマシンのアクセスを取り消す場合など、キー自体にアクセスすることなく）は、キー管理を有用にするのに役立つと思いますか？

1つの新しい提案：ブロブ、ツリー、スナップショットに別のキーを使用するのはどうですか？ これにより、AFAICSは、クライアントではなくバックアップストレージサーバーで忘却とプルーニングが発生するシナリオを可能にします。 ストレージサーバーにツリーオブジェクトとスナップショットオブジェクトへのアクセスを許可することにより、どのスナップショットでどのオブジェクトが必要で、どのオブジェクトが使用されなくなったかを判断するのに十分な情報が必要になります。 ストレージサーバーがすべて侵害された場合、ツリーメタデータへのアクセスは取得されますが、実際のファイルの内容へのアクセスは取得されません。

これは、残りのメタデータへのアクセスを許可せずに、ツリーによって参照されるオブジェクトIDのリストへのアクセスのみを許可することで、わずかに強化できます（ただし、これには、ツリーごとに追加のデータ構造が必要になります）。

上記が可能になれば、自動プルーニングや自動プルーニングを犠牲にすることなく、書き込み専用/追加専用の種類のストレージ（バックアップされたクライアントがバックアップを削除できない場合、＃784を参照）を使用する方法が開かれます。データセキュリティ。

以前のコメント（データへのフルアクセスを必要としないプルーニング）について：これは、バックアップのチェックにも当てはまります（おそらくさらに強力です）。 効率上の理由から（リポジトリをリモートでチェックするにはすべてのコンテンツを転送する必要がある）、または真の書き込み専用サポートを実装する場合（https://github.com/ncw/rclone/issuesを参照）、ストレージサーバー上のリポジトリをチェックすることは理にかなっています。 / 2499）。

また、真の書き込み専用アプローチの場合、読み取る必要のあるファイルを制限するために制限を変更する必要があります（https://github.com/ncw/rclone/issues/2499#issuecomment-418609301による）。 リポジトリ形式の変更も必要かどうかわかりません。変更が必要な場合は、ここに含めると便利です。

リモートサーバー上のリポジトリをチェックして整理するのは本当に素晴らしいことです。 私は複数のホストをバックアップするためにresticをセットアップしている最中であり、クライアントのセットアップが可能な限り簡単で、バックアップを定期的に実行するだけでよいように、リモートですべてのメンテナンスタスクを実行したいと考えています。

スナップショットファイル形式へのいくつかの（おそらくオプションの）追加について説明したいと思います。

• 使用済みインデックスファイルのリストを追加します（＃1988を参照）
• ユーザー定義データの可能性を追加します（追加の説明など、現在問題が見つかりませんでした）
• ファイル/ブロブの数、使用済みスペースなどの統計データを追加します。これにより、統計の表示がはるかに高速になり、追加のチェックが可能になります。

パックファイル形式について、ヘッダーを完全に削除しない理由について質問したいと思います。
情報は、インデックスファイルに冗長に含まれています。 エラー訂正のために冗長性を追加することについていくつかの議論がありましたが、IMOはこれを一般的なリポジトリ形式から分離する必要があり（そして分離でき）、その上に追加される場合とされない場合があります。

簡単に言うと、エラー訂正のための追加情報が必要ない、または必要ない場合は、パックヘッダーファイルとインデックスファイルの情報を複製する必要はありません。 インデックスファイルは、パフォーマンスの高い操作に必要であり、あらゆる場所で使用されます。 パックヘッダーが使用されることはめったにありません。その場合は、ダブルチェックまたはエラー訂正のためにのみ使用されます。

別の提案：ユーザー名、ホスト名、および構成ファイルの内容をキーファイルのdataセクションに追加します。 したがって、構成ファイルを完全に削除します。

すでに提案されているように、ユーザー名とホストは暗号化された形式でのみ存在する必要があります。 KDFから派生したキーが有効かどうかを確認するには、暗号化されたdataセクションのMACを確認するだけで十分です。
IMOには、キーを識別するために必要なすべての情報をそこに置くのが理にかなっています。 configファイルに保存されている情報を追加すると、ATMはリポジトリから余分なファイルを削除するだけで、リポジトリの初期化が容易になります。

「ばかげた」質問で申し訳ありませんが、すぐに改善されたフォーマットを導入するために真剣な努力が行われていますか？ 私はこの問題を何年もフォローしています。 現在、resticは、大規模なデータセットの場合、またはスナップショットが多数あり、大量のメモリを必要とする場合にはうまく機能しません。 圧縮の欠如とJSONエンコードされたメタデータの大きなオーバーヘッドが、resticの大きな問題のようです。 「完璧」を達成する必要性が認識されているため、努力が行き詰まっているのではないでしょうか。

また、未来がレスティックにもたらすものにも興味があります。 特に非対称暗号化と圧縮で。
ちなみに、新しいハッシュ関数には、非常に新しく、非常に高速なblake3もあります： https ：//github.com/BLAKE3-team/BLAKE3
ハッシュ関数の変更に関してまだ決定がなされていない場合、これは興味深いかもしれません。

repo.v2のその他のアイデア：

• ツリーとデータのBLOBを別のディレクトリに保存します（以前はツリーとデータが混在していましたが、これはキャッシュの導入により非推奨になりました）。
• 「作成された時間」情報をデータBLOBに追加します。

これにより、amazon Glacierのように非常に低速または高価なダウンロードで、「コールド」ストレージのサポートが簡素化されます。

* save tree and data blobs to different directories (in the past tree and data was mixed, but this was deprecated with introduction of cache).

私はこのアイデアが好きではありません。それは、バックアップのファイルサイズを推測するのをはるかに簡単にしますが、その利点はわかりません。

* add 'created time' info to data blobs.

「作成された時間」を追加することの使用は見当たりません。 ユースケースを教えていただけますか？

これにより、amazon Glacierのように非常に低速または高価なダウンロードで、「コールド」ストレージのサポートが簡素化されます。

「コールドストレージ」のサポートは、現在のレポ形式ですでに達成できます。これは、ローカルキャッシュなど、頻繁に使用されるファイルを復元および二重保存するための微調整の可能性を追加することによって実現できます。 ＃2504も参照してください

* save tree and data blobs to different directories (in the past tree and data was mixed, but this was deprecated with introduction of cache).

私はこのアイデアが好きではありません。それは、バックアップのファイルサイズを推測するのをはるかに簡単にしますが、その利点はわかりません。

この利点は、この問題に関する以前のコメントで詳しく説明されています。
https://github.com/restic/restic/issues/628#issuecomment -280436633
https://github.com/restic/restic/issues/628#issuecomment -280833405
最初のコメントの結果は、これら2つのタイプのblobを混合しても、意味のある方法でファイルサイズが不明瞭にならないことも示しています。

関連するフォーラム投稿：
https://forum.restic.net/t/feature-using-an-index-for-restic-find/1773

@cfbaoあなたが参照しているコメントは、1つのデータファイル（パック）内でツリーとデータブロブを混合することに関するものです。 これを分離すると、キャッシュ処理を有効にするのに役立ちました。 これもrestic内ですでに変更されています。

ただし、ツリーとデータのBLOBを別のディレクトリに保存するメリットはまだわかりません。 ユースケースを教えていただけますか？ （IMOのフォーラム検索トピックは関連していません-そこで回答します）

ただし、ツリーとデータBLOBエントリを別々のインデックスファイル（ディレクトリ「index-data」と「index-tree」など）に分離すると、いくつかの改善が可能になります。

ツリーブロブはすでに別のパックファイルに保存されています（これはキャッシュと一緒に導入されました）。
それらを別のディレクトリに書き込むだけで、ダウンロードが非常に遅いストレージのサポートを改善する方法が開かれます（Amazon Glacier標準の場合は3〜5時間）。 すべてのメタデータ（通常のS3ではインデックス+スナップショット+ツリー、Glacierではデータ）を保存するのと同じです。

2504はそれを少し改善しますが、「ローカルキャッシュ」に依存したり、キャッシュがいっぱいになるのをたくさん待ったりするのは好きではありません。

通常のS3またはその他の場所にtree+index+snapshotsを格納するリバースプロキシを作成するというアイデアがはるかに好きですが、データはディープアーカイブに保存されます。
いずれにせよ、確かにresticをそのまま使用することは可能ですが、いくつかの制限があります。 ただし、一部の形式の変更により、状況が改善/簡素化される場合があります。

@cfbaoは、コードrestic findから見る限り、これによるメリットはありません。 すでにスナップショットをウォークオーバーしています。 基本的にはrestic ls <all-snapshots> | grep somethingとほとんど同じです。

@dionorgua
データパックを除くすべてがキャッシュされる「追加の」キャッシュとして任意のリポジトリを追加するというアイデアが好きです。 これはリポジトリレイアウトを変更する必要がなく、IMOははるかに柔軟性があります。
私はすでにこれに取り組んでいます。＃2516の最後のコメントも参照してください。

ばかげた考えかもしれませんが、borgやkopiaと互換性のあるフォーマットはどうでしょうか。

@aawsome

あなたが参照しているコメントは、1つのデータファイル（パック）内でツリーとデータブロブを混合することに関するものです。

本当です。 私の悪い。 ええ、これが私が気にする唯一のことです。

これもrestic内ですでに変更されています。

これがどのPR/バージョンで変更されたか知っていますか？ 前回レポジトリをチェックしたとき、同じパックファイルにデータとツリーブロブが混在していることに気づきました。 リポジトリをより適切に分離するために（おそらくゆっくりと）変換できる方法はありますか？

ツリーとデータのBLOBを別のディレクトリに保存するメリットはまだわかりません。 ユースケースを教えていただけますか？

何も思いつきません。 前に述べたように、私はこれについてはあまり気にしません。

@dionorgua

私がコードから見る限り、resticfindはこれから利益を得ることができません。 すでにスナップショットをウォークオーバーしています。 基本的にそれはresticlsとほとんど同じです| grep何か。

ツリーブロブをデータブロブから分離すると、検索に必要なAPI呼び出しの数が減りませんか？ 集中すると、ツリーBLOBを含むパックファイルの数が減り、resticは、多くのパックファイルから多くのセグメントをフェッチする代わりに、少数のファイル全体をダウンロードできます。 これは、比較的低速でレート制限が厳しいバックエンド（Googleドライブなど）にとって重要です。

どんな方法でも（おそらくゆっくりと）リポジトリをより良いものに変換することができます
分離？

最近のバージョンのresticでは、「prune」を実行すると、これらの混合パックが再構築されます。
'prune'の実際の実装は、リモートリポジトリに大量のトラフィックを生成することに注意してください。 ＃2718の実験的な再実装では、トラフィックを最小限に抑えながら、混合パックのみを再パックできます。

ツリーブロブをデータブロブから分離しないと、APIの数が減ります
検索に必要な呼び出し？

最近のバージョンでは、混合パックがないリポジトリでは、必要なすべての情報がローカルにキャッシュされます。

改善されたリポジトリ形式の別のアイデア：

これまで見てきたように、パックファイルをblobタイプごとに分けることは有益です（ツリーとデータのblobは異なるパックファイルに入れられます）。 インデックスファイルもblobタイプで区切るのは良い考えではないでしょうか。 最近のインデックスPRは、メモリ内表現でツリーとデータBLOBのインデックスエントリを分離する方向にすでに進んでいます。
また、インデックスの一部のみをロードするための最適化も可能です。

リポジトリでもこれを行うと、よりコンパクトな表現が可能になります。

{
  "supersedes": [
    "ed54ae36197f4745ebc4b54d10e0f623eaaaedd03013eb7ae90df881b7781452"
  ],
  "type": "data",
  "packs": [
    {
      "id": "73d04e6125cf3c28a299cc2f3cca3b78ceac396e4fcf9575e34536b26782413c",
      "blobs": [
        {
          "id": "3ec79977ef0cf5de7b08cd12b874cd0f62bbaf7f07f3497a5b1bbcc8cb39b1ce",
          "offset": 0,
          "length": 25
        },{
          "id": "9ccb846e60d90d4eb915848add7aa7ea1e4bbabfc60e573db9f7bfb2789afbae",
          "offset": 38,
          "length": 100
        },
        {
          "id": "d3dc577b4ffd38cc4b32122cabf8655a0223ed22edfd93b353dc0c3f2b0fdf66",
          "offset": 150,
          "length": 123
        }
      ]
    }, [...]
  ]
}