これを実装するときは、ベンチマークを追加し、特に-benchmemとbenchcmpを使用してメモリ使用量を確認してください。

lz4、lzo、lzma、null。 bz2はかなり遅いです。

スナッピーは適度な圧縮で高速です

チャンクごとに圧縮を行う場合は、透かし/フィンガープリント攻撃に対してレスチックバックアップを開いたままにしないように注意する必要があります。

これは、CDC重複排除プロセスのフィンガープリントに関連して説明したのと本質的に同じ問題です。
「ナイーブ」CDCを使用すると、攻撃者が個々のブロックのサイズを監視できる場合、ファイルでCDCを並行して使用し、結果のチャンクと個々の量を比較することで、「既知のプレーンテキスト」ファイルがバックアップ内に存在することを確認できます。チャンクの長さ。
前に説明したように、これは、屋根裏部屋で行われているように、CDCアルゴリズムを秘密の値でソルトすることによっていくらか軽減できます。

ソルトCDCでは、問題のあるファイルをチャンクに分割した後、個々のチャンクで圧縮が行われると思います。 Resticチャンクは512KBから8MBの範囲です（ただし、均等に分散されていません-そうですか？）。

• 攻撃者は、CDCアルゴリズムがシークレットソルトを使用することを知っているため、攻撃者は、ファイルの最初の512KBから8MBで構成されるチャンクの範囲を、有効なチャンク長ごとに1つずつ生成します。 攻撃者は、圧縮されたチャンクの長さを判別することもできます。
• 次に、攻撃者は圧縮アルゴリズムを使用してそのチャンクを圧縮します。
• 攻撃者は、結果のチャンクの長さを、resticバックアップセットの最初のチャンクと比較します。
• 一致するブロック長が見つかった場合、攻撃者は次のチャンク、次のチャンク、次のチャンク、...、次のチャンクで演習を繰り返します。
• 十分に大きなファイルがあり、CDCアルゴリズムが約1 MBのブロックの生成に「偏っている」（より良い言葉がない）という事実を考慮すると、これは特定の大きなファイルであるかどうかを確認するのに十分であると私は信じています。ファイルはバックアップに存在します。

いつものように、妄想的で非常に非科学的な意識の流れ。

考え？

面白い。 あなたが説明する攻撃が、圧縮が使用されているかどうかにどのように依存するのかわかりませんが、それはまったく必要ですか？ この攻撃は、圧縮の有無にかかわらず機能しませんか？

現時点では、＃56の実装方法を考えています。 複数のblobを1つのファイルにまとめることについてどう思いますか？

CDC実装の正確な動作は、私には少し不明確です。

• 正確なバイト境界で分割しますか、それとも512 KB〜8 MBのブロックを倍数に「切り上げ」ますか？
• （本当の問題は、（15 * 512 * 1024）/（AES-CTRのために16）可能なチャンクサイズ、またはそれ以下がありますか？）
• また、既知のファイルの十分なチャンクが与えられた場合にシードを再構築することがどれほど実行可能であるかについても興味があります-あまり実行可能ではないと思いますか？

最初の質問に答えるには：
シードされたCDCの場合、「フィンガープリント」は（コンテンツ+シークレットシード）に依存しますが、違いは、チャンクの_後に_圧縮が行われ、個々のブロックを互いに区別できると仮定すると、フィンガープリントがあります/コンテンツのみに依存する透かし（特定のブロックの圧縮率）。このシナリオでは、既知のプレーンテキストです。

例：
透かしを入れたファイルに64MB（8〜128チャンク）の「AAAA」、64 MBの「ABCABCABCABC」、64 MBのランダムデータが含まれている場合、最初の16〜256チャンクは非常に小さくなります（これらのシーケンスは非常によく圧縮されるため） 、8〜128チャンクの圧縮はかなり不十分です）。
攻撃者は、最後の（24番目から384番目の）チャンクから始めて、攻撃者がまったく同じチャンクサイズに圧縮されるサイズを見つけるまで、512KBから8MBを圧縮することもできます。 それが見つかると、元の平文の「次の」512KB〜8MBが圧縮され、最後から2番目のブロックの長さ（23〜383番目）に圧縮される長さが検出されます。 「AAAA」文字列の結果である小さなチャンク。
これでは、透かしの入ったファイルがバックアップに保存されていることを攻撃者が積極的に確認することはできませんが、十分なデータがあれば、統計的には非常に明確な結果を生み出すことができると思います。

私はいくつかの潜在的な解決策を見ます、おそらくあなたはより多くのアイデアを持っています：

• 特定のディレクトリの圧縮や重複排除をオフにすることを許可します（おそらく実装が最も簡単です）
• 圧縮辞書をランダム化します（これについてはあまり考えていませんが、興味深いアイデアのようです）
• 攻撃者が個々の圧縮されたチャンクの長さを学習するのを防ぎます。たとえば、パディング（非常に高価になる可能性があります）や、いくつかの小さなチャンクをまとめて残りのチャンクをパディングする（より複雑ですが、より効率的）ことによって行います。

ご説明ありがとうございます。シナリオがわかりました。

プログラムの現在の構造を考えると、これを行うのは非常に難しいため、resticで重複排除をオフにするオプションはおそらくありません。resticはCDCを中心に構築されています。 現在、圧縮サポートの追加は優先度が低く、アルファリリースの目標ではありません。

3番目のアイデアは＃56（複数のチャンクをバンドルする）で実装されます。私は現在それに取り組んでいます。 そして、チャンカーがどのように機能するかについて、おそらくdoc/Design.mdドキュメントを追加します。

このシナリオを提起してくれてありがとう！

@cfcsをフォローしているかどうかは

ともかく。 私が作成した変更されたdeflate / gzipライブラリを恥知らずに紹介したかっただけです。 一定時間の圧縮モードにすると、どのデータでも最大150MB /秒/コアのスループットが可能になり、バックアップシナリオではほとんど見えなくなります。 複数のコアで大きなファイルをgzip圧縮する並列gzipパッケージもあります。

@klauspost ：ファイルではなく個々のチャンクの圧縮サイズについて説明していることに注意してください。 平均チャンクサイズが1MBの100GBファイルには、約100 x 1024のチャンクがあり、それぞれがファイルの特定の部分の圧縮率をリークします。 これにより、単一の圧縮ファイルのサイズよりもはるかに多くの統計データが得られ、CDCソルト（したがってチャンクの正確な配置境界）が不明な場合でも、既知のプレーンテキストを圧縮およびチャンク化されたファイルと比較できます。

ただし、151がマージされたため、これはおそらく現在の問題ではありません。

私の意見では、シードされたチャンカー（カスタムのリポジトリごとの多項式を介して）とブロブパッキング（攻撃者は個々のチャンクを見ることができず、チャンクのグループとチャンクの数のみを見ることができる）があることを考えると、この情報漏えいはそれほど重要ではありませんグループ内で、クリアテキストヘッダーの長さを介して）。 速度やプライバシーの問題から完全に圧縮を無効にすることをお勧めしますが、デフォルト（これが実装されている場合）はおそらく「有効」になります。

@klauspost指摘してくれてありがとう、私は間違いなくあなたのライブラリを見て

上記の@ fd0の観察に同意しますが、特定のターゲットファイル/ディレクトリ/デバイスの圧縮を選択的に無効にする別の重要なユースケースがあると思います。たとえば、すでにマルチメディア形式をバックアップする場合などです。十分に圧縮されない、または暗号化されたボリュームの増分バックアップを実行する場合の、エントロピーが高い圧縮されたバイナリファイル。

@ cfcs -

非圧縮ファイルに関しては、名前がすべてのデータを同じ速度で圧縮し、非圧縮データの保存に自動的にフォールバックすることを意味するため、私がデフレートする定数時間ハフマン専用モードについて言及した理由です。 したがって、コンテンツが圧縮されている場合、最大オーバーヘッドは約0.04％です。

ここにいくつかのベンチマークがあります。 バックアップに最も適しているのは、おそらく「中圧縮」です。これは、圧縮可能と非圧縮の10GBの混合コンテンツです。

デフォルトでgzipHuffmanのみに設定し、CPUをより多く消費する圧縮レベルを指定するオプションがあることは理にかなっています。

私の意見では、データオブジェクトとツリーオブジェクトに対して別々に圧縮を選択的に有効/無効にすることは価値があるかもしれません。 特に大きなツリーオブジェクトは、非常によく圧縮されるはずです。

圧縮を挿入することが理にかなっているいくつかの「ポイント」を調べました。 最も透明で用途の広い場所は、リポジトリとバックエンドの間のどこかになります。

Repository.EncryptとRepository.DecryptToの変更について簡単に説明しましたが、タイプがなく、サイズが異なると混乱します。

私の提案は、圧縮と_encryption_を「バックエンド」として実装することです。どちらも基盤となるバックエンドに書き込みます。 これにより、圧縮と暗号化がリポジトリに対して透過的になります。

暗号化を分離する必要がある理由は、暗号化されたデータが圧縮されないためです（おそらくご存知でしょう）。

repository.Repository

圧縮アルゴリズムは初期化時にのみ設定でき、構成以外はすべてそのアルゴリズムで圧縮されていると見なされます。

repository.Config

構成を圧縮することはできません。 すべてに使用する解凍タイプを示す文字列を追加します。 空（ ""）は圧縮されていません。 それ以外の場合は、使用される圧縮ライブラリのパッケージ名の最後の部分です。

圧縮レベルは、実行/タイプごとに変更できることに注意してください。 デコンプレッサが同じである限り、一部のスナップショット/タイプがレベル0（ストア）とレベル9（最適な圧縮）のデフレートであるリポジトリを使用しても問題はありません。

type Config struct {
    Version           uint        `json:"version"`
    ID                string      `json:"id"`
    ChunkerPolynomial chunker.Pol `json:"chunker_polynomial"`
+   Compression       string
}

圧縮は作成パラメータとして追加されます：

-func CreateConfig(r JSONUnpackedSaver) (Config, error) {
+func CreateConfig(r JSONUnpackedSaver, compression string) (Config, error) {

バックエンドは、LoadConfig / CreateConfigの後に置き換えられます。 これがどのように見えるかの例です：

// SearchKey finds a key with the supplied password, afterwards the config is
// read and parsed.
func (r *Repository) SearchKey(password string) error {
    key, err := SearchKey(r, password)
    if err != nil {
        return err
    }

-   r.key = key.master
-   r.keyName = key.Name()
    r.Config, err = LoadConfig(r)
+   r.be, err = FindCompressor(r.Config.Compression, Encryption(key, r.be))
    return err
}

圧縮の実装

コンプレッサーは、一部のタイプに対して選択的/調整可能な圧縮を実装できます。 これは「バックエンド」と見なされるため、圧縮されたサイズがリポジトリに表示されることはありません。 コンプレッサーは、すべての設定で合計である必要があります。

問題

HELPME / FIXME：暗号化は各ファイルで再開されるため、「パックされた」ファイルは問題のようです。 暗号化がバックエンドに移動された場合、暗号化は各ファイルではなく、blob全体に対して行われます。 それが問題だと思いますが、良い解決策はありません。

TODO：パラメーター/構成をコンプレッサーに送信するための良い方法を見つけてください。 最初の実装には必要ありません。

TODO：ディスク上のサイズは気になりますか？ 上記が実装されている場合、リポジトリはそれを認識しません。

あなたの考えを共有してくれてありがとう、ここに私のものがあります：

圧縮と暗号化を統合する必要があると思います。これについて考えます。 現時点では、圧縮/暗号化レイヤーを相互に完全に抽象化するという考えは好きではありません。 すでに説明したように、暗号化されたデータの圧縮など、愚かなことをしないように注意する必要があります。 さらに、速度やセキュリティ上の懸念から、圧縮を無効にするオプションを提供する必要があります。 暗号化について：後でrestic用の非暗号モードがあるかもしれませんが、今のところ暗号はオプションではありません。

また、パックされたファイルはそれ自体が抽象化のレベルであり（たとえば、ものを再パックすることができます）、暗号化の抽象化では機能しません。

Repositoryオブジェクトは非常に複雑であり、これに取り組む前に一般的なオーバーホールが必要だと思います。 私は今それのために本当に良い計画を準備していません。

さまざまな圧縮アルゴリズムとオプションについて：データ用に1つのアルゴリズム（パラメーターのセットを含む）を選択し、JSONツリー構造を圧縮するために2つ目のアルゴリズムを選択する必要があると思いますが、それだけです。 すべてのオプションのもの（たとえば、さまざまな構成可能な圧縮アルゴリズムやパラメーター）について、追加された複雑さと追加のコードの量に対する利点を重み付けするための適切な検討が必要です。

誤解しないでください。resticに機能を追加したいのですが、特にディスク上のフォーマットを変更する変更については、非常に良い議論が必要です。 圧縮を追加する一般的なケースでは、利点がわかりますが、ディスク上のフォーマットの複雑さと変更は管理可能でなければなりません。

さまざまなアルゴリズムとパラメーターが必要になります（リポジトリごとだけでなく、バ​​ックアップの実行ごとでも）。「すべてのユースケースに最適」な圧縮はありません。

実用的な例として：

会社のサーバーから自宅のバックアップサーバーにバックアップを行います。 〜700kbit / sのdslアップリンク。
このために私は最高の圧縮（lzma +高レベルのような）が欲しいです。 CPUは、安っぽい接続が次のパケットを受け入れるのを待っている間、夜間に多くの空き時間を持っています。

同じリポジトリに、家にいるときにラップトップもバッ​​クアップします。ワイヤレスの「N」接続があります。 もちろん、そこでlzma + high levelを使用して接続を遅くしたくはありませんが、lz4のようにまったく遅くならない非常に高速なものが必要です。 私はまだ圧縮が必要ですが、lz4を使用しないと約2倍のスペースが必要になります。

ここにlzmaが欲しいのですが、そこにlz4があります（言い換えると:-)）

それはすべてバイクシェディングの私見です...合理的なデフォルトを選択し、あまり多くの構成を公開しないようにしましょう。それは少しの利益のために多くの複雑さを導入するだけです、私見。

Repositoryオブジェクトは非常に複雑であり、これに取り組む前に一般的なオーバーホールが必要だと思います。 私は今それのために本当に良い計画を準備していません。

けっこうだ。 私はrepository.goを調べ始め、圧縮/解凍ステップを挿入するすべての場所を見つけましたが、複雑さが増すのは良いことではありませんでした。 backendインターフェースとして実装することで、突然すべての暗号化を取り除き、バックエンドチェーンの一部にすることができます。 圧縮や暗号化など、バックエンド部分の対称性を保証する一般的なテストを行うことができます。

暗号化について：後でrestic用の非暗号モードがあるかもしれませんが、今のところ暗号はオプションではありません。

これが、バックエンドチェーンが非常に優れている理由です。 暗号化を省略する（またはパススルーバックエンドを作成する）だけで、シームレスに機能します。

圧縮を追加する一般的なケースでは、利点がわかりますが、ディスク上のフォーマットの複雑さと変更は管理可能でなければなりません。

これは私が見ることができる最も邪魔にならない方法でした。 「パックされたファイル」の問題を修正する方法がある場合、非圧縮リポジトリは完全な下位互換性を維持します。 古いクライアントは、新しいクライアントと一緒に以前と同じようにそれらを操作できるようになります。

圧縮されたリポジトリは明らかにそうではありませんが、リポジトリが圧縮されている場合にのみversionを2に変更できます。これにより、古いクライアントが失敗します。 その後、チェックを明らかにif cfg.Version > RepoVersion {に変更する必要がありますが、互換性の問題はありません。

それはすべてバイクシェディングの私見です...合理的なデフォルトを選択し、あまり多くの構成を公開しないようにしましょう。それは少しの利益のために多くの複雑さを導入するだけです、私見。

同意。 ほとんどのアルゴリズム（lzma / deflate）は、同じ解凍形式内で十分な柔軟性を備えています。

圧縮性をテストするには、DataSmokeがあります： https ：

また、pcompressはさまざまな圧縮アルゴリズムを選択します： https ：

スカッシュ圧縮抽象化ライブラリには、アルゴリズムとベンチマークの優れたリストがあります： https ：

ここにテキスト圧縮ベンチマークがあります： http ：

簡単なアプローチは、常にcrypto/crypto.go暗号化/復号化関数内でフィルタリングすることです。

gzip-compression-v1.patch.txtこれは、ヘッドに適用できる概念実証の差分です。

@mappuをお試しいただきありがとうございますが、これを実装する前に、戦略について合意する必要があります。 （頭のてっぺんからの）未解決の質問は少なくとも次のとおりです。

• 圧縮はいつ適用されますか？ （データ？メタデータ/ JSON？）
• どのアルゴリズムを実装する必要がありますか？ @klauspostにはいくつかの提案があると思います:)
• クライアントを壊さずにこれをリポジトリに保存するにはどうすればよいですか？

圧縮はいつ適用されますか？ （データ？メタデータ/ JSON？）

データは明らかにそうです。
メタデータ/ json、おそらくそれは無意味ですが、JSONデータはほとんどASCIIであり、算術符号化/ハフマンフェーズ（gzipにはあります）の恩恵を受けるため、大きなメタデータファイルに役立つと思います。

データ/メタデータは常に暗号化されているので、暗号化/復号化ルーチンに追加することは、すべての使用法をキャッチする簡単な方法だと思います。「repository.goを調べ始めて、圧縮/解凍ステップを挿入するすべての場所を見つけました。複雑さが増したのは良いことではありませんでした。」 @klauspostの。
また、blobはhash（ciphertext）ではなくhash（plaintext）という名前で保存されるため{{明らかに重複排除に必要です。そうでない場合、ランダムIVは重複排除を破壊します}}、重複排除を損なうことなくこれを行うのが安全です。

どのアルゴリズムを実装する必要がありますか？ @klauspostにはいくつかの提案があると思います:)

気にしないでください@ThomasWaldmannに同意しますが、構成可能である必要があります。 少なくとも--bestと--fastユースケースでは。

gzipをお勧めするのは、それが純粋なgoであり、golang標準ライブラリにあり、Googleからパフォーマンスの注目を集めているからです。 xzははるかに強力な低速圧縮です。 lz4ははるかに弱い高速圧縮です。 gzipはバランスが取れており、極端に到達しなくても簡単に調整できます。

クライアントを壊さずにこれをリポジトリに保存するにはどうすればよいですか？

リポジトリは一方向でのみ互換性がある必要があります。 新しいレポが読めるのであれば、古いレポが読めなくても大丈夫だと思います。

たぶん、MACの後にタグバイトを追加することができます。 存在しない-圧縮なし（古いレスティック）。 次に、バイトは、使用された圧縮アルゴリズムを示すこともできます。 0x01 gzip 0x02lz4かそこら。

屋根裏部屋と同じ（またはもっと悪い）問題が存在するようです（現在の形式で使用されている圧縮タイプ/パラメーターバイトはありません）。

屋根裏部屋（borg）では、古い形式はgzipのみであり、gzip形式は最初の2バイトから検出できるため、幸運でした。 そのため、gzipを追加のバイト（古いリポジトリと同じ）なしで保持し、最初の2つのgzipバイトで決して曖昧にならないタイプバイト（圧縮なしまたはその他の圧縮用）を追加しました。

明らかに、古い形式が生の任意のデータである場合、そのようにすることはできません。

いいえ。ただし、この情報を通知する方法は他にもあります。 たとえば、暗号化されたチャンクの開始時のIVが正確に「NEWFORMAT」（1 :: 2 ^ xyzの衝突の可能性）である場合、新しい形式として解析します。 それほど「クリーン」ではありませんが、実際には問題ないと思います。

nmdcロックハンドシェイクのEXTENDEDPROTOCOLで行われるように。

いいえ、このように醜いことはしませんし、そうする必要もありません。 これを実装することにした場合、パックファイルには各blobのフィールドtypeがあります。 これはuint8であり、現時点ではdataとtreeに対してのみ定義されているため、 compressed dataとcompressed treeを簡単に追加できます。 https://github.com/restic/restic/blob/master/doc/Design.md#pack -format

現時点では、この機能の優先度は高くないと思います。

パック形式に新しいblobタイプを追加することは、データ圧縮には問題ありませんが、インデックス圧縮は提供しません。 インデックスが大きくなる可能性があり、JSONの圧縮率が高く、インデックスにローカルキャッシュがない可能性があるため、インデックスも圧縮することが重要だと思います。

簡単にアップグレードできるように、new-resticがold-repoと連携することが重要です。 シームレス（推奨）またはrestic upgrade-repoツール（非推奨）のいずれかである必要があります。

では、これはどうですか？

すべてのresticコマンドは、すでにconfig最初にロード+復号化します。

• 最初のconfigバイトが{ （jsonオブジェクトの最初のバイト）の場合、リポジトリ全体が古い形式（非圧縮）です
• それ以外の場合、最初のconfigバイトは{タグバイト}であり、リポジトリ全体が新しい形式です。 復号化されたデータの開始時の{タグバイト}は圧縮形式を示します。 例0x00非圧縮0x01gzip

提案してくれてありがとう。 これは非常に小さなファイルであり、常にJSON形式のままであり、インデックスファイルが圧縮されているかどうかなど、必要に応じてフィールドを追加できるため、構成を圧縮する必要はないと思います。

昨日、良いバックアップソリューションを探しているときにresticを見つけました。 私の主な関心事の1つは、データが占めるスペースの量を制限することです。 特に、S3のように、料金を支払っている場所にデータを送信する場合はそうです。 重複排除は間違いなく役立ちますが、圧縮はバックアップソリューションの一部になると思います... https：//github.com/restic/restic/issues/21#issuecomment -185920429であなた（ @ fd0 ）はこれを言います優先度が低いのですが、その理由を説明していただけますか？ どこでも見ることができるロードマップはありますか？

また、+ 1。 ;）

現在、古いバックアップデータ（＃518）の削除に取り組んでいます。 圧縮を正しく安全に行うことは簡単ではありません。これをリポジトリ形式に統合する方法についてもう少し考える必要があります。

圧縮を実装します（結局のところ、この問題の内容です）が、まだ実行されていません。 resticはかなり新しいプロジェクトです。ご容赦ください:)

この問題は＃116に関連しています。 暗号化のため、他のツールでバックアップを圧縮することはできませんね。 圧縮と暗号化をオプションにすることの間で、どのような優先順位がありますか？ （私は最初に圧縮に賭けます！）
_これについて圧力をかけて申し訳ありませんが、リポジトリの形式には注意が必要です！_

これは簡単に答えることができます。圧縮が最初に実装されます。

これは、現時点では暗号化をオプションにする予定がないためです。 うまくいくのも大変だと思います。 これはオプションであってはならないものであるため、整合性について考える必要がありますが、（少なくとも現時点では）暗号化と緊密に結合されています。

@ fd0私の質問に答えてくれてありがとう。 私の開発スキルがこれを支援するまでになっていることを願っています。 しかし、私はgoにほとんど触れていないだけで、他のxpのほとんどはwebdevまたはsysadminスクリプトにあります。

圧縮が「正しく安全に」行われるようにする必要があることに完全に同意します。 それが物事を遅らせるなら、そうです。 ：笑顔：

ここでresticにsnappy圧縮を実装しました： https ：

それは単なる提案です。 基本的に、パック内のblobにスナップ圧縮/解凍を追加し、blobタイプのバイトのビットをマークとして使用します。 また、パックインデックスにフィールドPLength（プレーンテキストの長さ）を追加しました。これは、それまで保存されていませんでしたが、「bloblength--crypto.Extension」として計算されていました。

一部のバックアップでは、必要なスペースが少ないだけでなく、動作も高速である（処理するデータが少ない）ことに気付きました。

すべてのresticテストは問題なく合格します。 以前のresticリポジトリでは機能しますが、通常のrestic（マスターのリポジトリ）では新しいblobを処理できません。

@ fd0の速度の目標にあまり影響しないと思ったので、snappy（https://github.com/golang/snappy）を使用しました。

マスターへの圧縮着陸に50ドルの報奨金を追加

上記のように、メディア、暗号化されたファイル、またはすでに圧縮されたファイルなどの非圧縮ファイルを圧縮しようとしないように、自動化された構成不可能な方法が必要です。 この問題は、PDFのような一部のコンテナ形式によって悪化し、その内容は圧縮可能である場合とそうでない場合があります。

@klauspostによる最初のコメントで述べた定数時間圧縮モードのように、これを透過的に処理するアルゴリズムを使用するのが最も簡単です。

そうでなければ、ファイルタイプリストが必要になります：ブラックリストは決して圧縮されない、ホワイトリストは常に圧縮される、ファイルのごく一部を圧縮しようとする残りのヒューリスティック、そしてサイズの縮小がなければあきらめる指定されたしきい値を超えています。

これがファイルレベルではなくチャンクでどれだけうまくマッピングされるかはわかりません。

私はそれを暗号化/復号化パスに追加することに反対します。
一部のデータは予測可能であり、結果として得られるパック/ブロブの長さにより、予測不可能な/秘密のデータの平文に関する情報が漏洩する可能性があるため、さまざまな種類のデータを混在させたくありません。
たとえこれが「あまり良くない」ようになったとしても、それはファイルごとであるべきだと思います。 ただし、これには、ファイルを読み取るために大量のパックファイル（それぞれに1つのblobのみ）の漂遊解凍を実行する必要がないという利点があります。

@teknico

上記のように、メディア、暗号化されたファイル、またはすでに圧縮されたファイルなどの非圧縮ファイルを圧縮しようとしないように、自動化された構成不可能な方法が必要です。

私の変更したdeflateパッケージは、すでに圧縮されたデータのスキップを実装し、コアあたり最大250MB /秒の速度でスキップします。 Go 1.7 deflateは、最速の圧縮レベルでのみサポートします。

SnappyとLZ4は、同様のスキップ機能をサポートしています。

定数時間圧縮モードのように、これを透過的に処理するアルゴリズムを使用するのが最も簡単です。

それは間違いなくオプションでなければなりません。 Go 1.7（現在はHuffmanOnlyおよび同等のものと呼ばれています）では、このモードは入力に関係なくコアあたり最大200MB /秒をサポートします。 ただし、圧縮は、通常80MB /秒/コアで動作する「最高速度」と比較して大幅に妨げられます。

@cfcs

たとえこれが「あまり良くない」ようになったとしても、それはファイルごとであるべきだと思います。

一般的に私は同意します。 私はresticについて読む必要があります。 各パックサイズのバイナリサイズは暗号化されていませんか？

@klauspostいくつかの改善点がGo1.7 DEFLATE "BestSpeed"モードに統合されたようですが、それは正しいですか？ 多分それは合理的なデフォルトでしょう。

DEFLATE形式を使用する利点は、互換性のあるビットストリームを生成するさまざまなコンプレッサーが利用できるため、デコンプレッサーに対して完全に透過的であるということです。

Resticの動作（ファイルをblobに分割し、後でblobのみを処理する）の性質上、圧縮を追加する最も簡単な方法はblobレベルです。 ヒューリスティックを追加して、blobを圧縮するかどうかを決定できるかもしれませんが、それが2番目のステップになる可能性があります。

ブロブはパックファイルに結合され、リポジトリに保存されます。 パックファイルには、いくつかの（個別に暗号化された）blobが含まれ、その後に（暗号化された）ヘッダーが続き、その後に（暗号化されていない）ヘッダーの長さが続きます。 復号化キーを持たない攻撃者は、暗号文、ヘッダーの長さ、およびファイルの長さのみを確認できます。 したがって、パックファイルのサイズとヘッダーの長さに基づいて、攻撃者は特定のパックファイル内のblobの平均サイズを計算できますが、それだけです。 インデックスファイルにはすべてのデータ（サイズ、暗号化されたサイズ、そして後で圧縮されたサイズ）も含まれますが、それらも暗号化されます。 ここではリスクは見られません。

「圧縮可能な」テストヒューリスティックは、エラーが発生しやすく、かなりコストがかかります。 200 MB / s /コアをはるかに超える速度を得るのは難しいと思います。これは、AMD64の

また、使用するコンプレッサーにも大きく依存します。 Snappyはランダムなbase64データを圧縮できませんが、たとえばdeflateは圧縮するので、その部分はコンプレッサーに任せます。Snappy、LZ4、およびdeflate用に組み込まれています。

@ fd0申し訳ありませんが、ファイルごとではなく、ブロブごとを意味しました。
軽量のアルゴリズムを選択しない限り、CPUをいくらか重い圧縮がボトルネックになる可能性があります（AESの次に、将来的にはAES-NIによって処理される予定です）。

@ fd0-簡単な「圧縮率推定器」を作成しました： https ：

borg 1.1には、2つの「圧縮決定子」があります。

1. パスパターンマッチに基づいてファイルごとに決定します（ *.zip 、 *.mp3 、 /htdocs/photos/* 、...）
2. 未決定の場合は、チャンクごとに決定し、圧縮性のテストとしてlz4を使用します-圧縮する場合は、目的の圧縮（lz4、zlib、lzma）で再度圧縮し、そうでない場合は圧縮しないでください。

@klauspost hm、そのテストは私のマシンではそれほど悪くありません：

BenchmarkCompressibility-4           100      10345544 ns/op     810.84 MB/s

ベンチマークコードはこちら： https ：

Lz4にはエントロピーコーダーがないため、多くの場合、偽陰性になります
多分？

（グローバルに）3つのモードが必要だと思います。

• 線形時間コンプレッサーですべてのデータBLOBを圧縮します（デフォルト）
• 圧縮なし
• 最大圧縮（CPUパワーは大きいが、帯域幅が狭い人向け）

常にツリーオブジェクト（JSON）を圧縮したいので、ASCIIテキストに適切なアルゴリズムを選択する必要があります。

それ以外の場合は、 @ viricとすれば、具体的な実装について

考え？

@klauspost hm、そのテストは私のマシンではそれほど悪くありません

私はいつも、新しいGoコンパイラがどれほどうまくできるかを忘れています。 私が期待したものの少なくとも2倍。

（グローバルに）3つのモードが必要だと思います。

より効率的なコンプレッサー（主にLZMA）がありますが、Deflateは3つすべてをかなりうまく実行します。 圧縮せずに収縮することはもちろん不要ですが、もちろん高速でオーバーヘッドが最小限であるため、一般的な収縮アプローチを使用でき、後で他の方法を指定することもできます。

私は別のスピードアップを検討し始めました。これは、速度と圧縮の両方の点でレベル1とハフマンの間にあります。 ただし、現時点では時間が少し貴重であり、新しいことに移る前に、Go1.7の最終的な変更のいくつかのバックポートをテストする必要があります。

単一の圧縮アルゴリズムが必要な場合は、新しい候補zstdを確認する必要があります： https ：

これはlz4と同じ開発者によって開発され、gzipよりも優れた圧縮率を持ち、3倍以上高速です： https ：//code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with

Goで実装を見つけることができませんでしたが、zstdは非常に有望に見えます。

公式サイトhttp://facebook.github.io/zstd/#other-languagesはこのGo実装にリンクしています： https ：

それとも、純粋なGoの実装を意味しますか？

はい、純粋なGoの実装を意味しました。 現時点では、resticはCコードに依存していません。理想的には、そのままにしておきたいと思います。

圧縮を実装する予定はありますか？

圧縮の実装は、リポジトリ形式の変更に依存します（計画/アイデアは＃628にあります）。これには細心の注意が必要です。 したがって、いいえ、圧縮が追加される明確な日付はありません;）

これを実現するために私たちができることや貢献できることはありますか？

私はそうは思いません、ごめんなさい：wink：、それはただ時間が必要です。

なので、もう一度＃790のテストベッドが使えると思いました。 Resticのビルドでは、すべての暗号化を削除してから、もう一度完全バックアップを作成しました。 暗号化されたものと同じサイズでした-ここで驚くことはありません。 しかし、それから私はリポジトリを圧縮しました、そして私が見つけたものは次のとおりです：

35G backup-unencrypted
6.4G    backup-unencrypted.tgz2

なんという違いでしょう。 比較のために、圧縮された単一のデータベースダンプのサイズは次のとおりです。

1.7G    single-backup.sql.gz

私は上記の29を持っています。 通常のバックアップと比較して約100倍の節約！

暗号化が追加された場所をすべて見つけたので、ストックのgzip実装を使用して、非常に単純な構成可能な圧縮を追加でき、将来的には別の圧縮エンジンを使用できると思います。 異議はありますか？

（私はおそらく成功または失敗するために2週間分の夜を自分自身に与えるでしょう。）

あなたの研究とここに結果を投稿してくれてありがとう！ 同様の結果を期待していました。 あなたに正直に言うと、私は暗号を削除するもの、あるいはそれをオプションにするものをマージしません。 それは後でできることですが、慎重に計画する必要があります。

圧縮を追加することは最初は簡単に思えるかもしれませんが、そうではありません。 予期しない攻撃に対して誤ってresticを脆弱にしないように非常に注意する必要があります（これはTLSプロトコルに連続して数回発生しています（はい、これは別の状況であることを認識しています））。

プロジェクト全体で最も重要なことはコードではありません。それはリポジトリ形式です。 ユーザーは自分のデータで私たちを信頼しており、resticを長期間使用した後にデータを復元できることに依存しているため、リポジトリ形式の安定性が最も重要です。 したがって、圧縮をサポートするには、最初にリポジトリ形式の次のバージョンを決定（および実装）する必要があります。 議論はここにあります： https ：

あなたはこれを実装すること（そしてコードを提供することさえ）に非常に熱心であることがわかりますが、リポジトリの形式に同意し、この問題のすべての角度について議論するまで、これに時間を費やさないでください。 ありがとう！

削除された暗号については、それをマージすることを提案するつもりはありません。 私はそれを行ったのは、圧縮が機能するかどうかを確認するためだけ

json.Unmarshalを使用するので、必要な数の新しいキーを構成に追加できます。 JSONで見つからない場合は、デフォルト値のままになります。

アルゴリズムの選択は要点ではなく、理解されています。しかし、将来の参考のために、 Brotliは強力な候補のようです。

私が知っている限り、Brotliの圧縮は非常に遅い（iircはgzipの60倍）ので、バックアップではおそらく一般的ではない書き込みと圧縮に比べて、非常に頻繁に読み取られるデータに推奨されます。 しかし、ええ、まだ詳細には立ち入りません:)

これにより、さまざまな圧縮アルゴリズムの概要がわかります。

Brotliは常に高速であるか、圧縮率が高くなっています。 圧縮レベルによって異なります。

@ibibどうやってその結論に達するのですか？ brotliは、（混合データセット上で）他のほとんどのデータセットよりも遅いように見えますが、特に驚くべき圧縮率は達成されていません。 たぶん、特定の種類の構造化データに適していますか？

Squashベンチマークでの比較にリストされているように、次の3つのパラメーターを使用する必要があります。

• 達成された圧縮率：ディスクスペース（およびバックエンドへのI / O）を節約するには、どれだけ適切に圧縮するかが重要です。

• 圧縮速度：ブロックを追加するたびにこの操作を実行するため、重要です。ボトルネックにならないように、AES-NIと一般的なI / Oに対応できるものが本当に必要です。 これらの新しいアルゴリズム（ zstd 、 lz4 、 brotliは逆のWebブラウザーの使用例があるため、解凍よりも圧縮が遅いアルゴリズムを選択することはおそらく望ましくありません。 brotli ）は最適化されています（「一度圧縮して頻繁に解凍する」とは対照的に、「頻繁に圧縮し、ほとんど解凍しない」）。

• 解凍速度：解凍速度は、復元する場合にのみ関係します。 遅い復元で問題がなければ、遅い解凍速度を受け入れることができます。 一方、ゆっくりと解凍したくないメタデータもあるため、2つの異なるアルゴリズムが必要になる場合もあります。

densityは、圧縮率の点では特に効率的ではありませんが、最速の1つであるように見えます。 ボトルネックにならないという点では、（平均で）2：1の圧縮率がほぼ無料で得られるようです。 4：1が必要な場合は、別のアルゴリズムを選択する必要がありますが、その場合は、座ってそれを待つことになります。

また、2つの（少なくとも？）異なる種類のデータがあります。 およびデータチャンク。 この2つは使用方法が異なり、異なるアルゴリズムを選択することが理にかなっているのかどうかについて議論できると思います。 個人的には、Resticの再実装（新しい言語など）が不当に難しくならないように、（選択したものは何でも） 1つのアルゴリズムに固執する必要があると思います。 また、 2つのエキサイティングな圧縮アルゴリズムのバグにさらされないようにするためです。これらは、コーナーケースをテストするのが難しいためです。

私はあなたの推奨するトレードオフに同意しなければなりません。 バックアップは、都合の良いときにバックグラウンドで実行できます（おそらく、素敵な10で）。 それらの復元は、時間のプレッシャーの下で行われます。 私が見る関連するトレードオフは、ブロックサイズと圧縮率の間です。 ブロックが小さすぎると、圧縮が不十分になり、メタデータのオーバーヘッドが増加します。 ブロックが大きすぎると、重複排除率が低下します。 ほとんどの圧縮アルゴリズムでは、高レベルの設定では小さな入力の圧縮率は向上しません。

さらに、圧縮率を高くすると、ユーザーはより多くのバージョンのデータを同じスペースに保持できます。

snappyを使用したテストの結果は、1）バックアップサイズが小さい（圧縮、通常）、2）バックアップと復元が高速（データ暗号化、HMAC、転送が少ない）であることに注意してください。 非常に安価なラップトップを使用しています。

@cfcsgzipとbrotliの比較を参照しました

ここでbrotliは常により速くより良い圧縮を持っています。

@Crestそれは十分に公平です、おそらく異なるユースケースがあります-私はあなたと同じようにrestic使用しません。 私は自分のラップトップのバックアップを作成し、ラップトップを持って去ることができるように、それをすぐに終了させたいと思っています。 私はあなたがバックアップレートがそれほど重要ではないサーバーまたは他の常時接続されたマシンのバックアップについて話していると思います。 同様に、時間のプレッシャーの下ですべてのデータを復元する必要はありません。 時間のプレッシャーがある場合（専門的なコンテキストで使用しているためですか？）、必要なデータを選択的に復元し、後で残りの作業を続行できます。

あなたは「多くの場合、小さな入力」について非常に良い点を述べています。

@viricあなたが参照している効果は、 Transfer + Processingと呼ばれるセクションの下のスカッシュベンチマークで考慮されます:-)

@ibibああ、

@ibibそのチャートをどこから入手したかをリンクできますか？

チャートはhttps://quixdb.github.io/squash-benchmark/からのものです

私はbrotliとzstdでいくつかのテストを行ってきましたが、私の結果がスカッシュベンチマークの結果とまったく一致しないことに気づきました。 それから私はそのベンチマークが1。5年前のものであることを理解しました。

zstdは私にとって非常にうまく機能します。 高速+高比率、およびその「レベル」により、高速と高比率の間の非常に大きなスパンが可能になります。 素晴らしいことです。

Brotliは私にとって非常に遅く動作し、はるかに高速なzstdよりも優れた圧縮率はありません。 そして、brotliは英語のテキストの小さなファイルに焦点を合わせているようです（英語の辞書が含まれています）。 HTML圧縮などの場合。

私が見つけた最近のベンチマーク： https ：

そこで、LZMA圧縮を使用したzbackupに対して

35G backup-unencrypted
6.4G    backup-unencrypted.tgz
2.5G    zbackup

印象的ですね。

zbackupには独自の制限と欠点があると言えば十分です。

したがって、 @ viric lzbenchリンクによると、最も適切なコンプレッサーは、バックアップの速度を低下させず（高い圧縮速度？、> 200 MB /秒）、実際には良好な圧縮率（> = 50）を備えたコンプレッサーです。

そこで、比率順の表から結果を除外しました。

また、Go実装の_クイック_検索も実行しました（そのため、それらをテーブルに保持しました）。 取り消し線とは、実装が見つからなかったことを意味し、ほとんどすべてが削除されました。 クイック検索だったので、結果を残しておきました。 単なるラッパーであるzstdの例外。

| コンプレッサー名| 圧縮| 解凍します。| Compr。 サイズ| 比率|
| --------------- | ----------- | ----------- | ----------- | ----- |
| zstd 1.1.4 -1 | 242MB /秒| 636 MB / s | 73654014 | 34.75 |
| トカゲ1.0-30 | 258MB /秒| 867 MB / s | 85727429 | 40.45 |
| 密度0.12.5ベータ-3 | 253MB /秒| 235MB /秒| 87622980 | 41.34 |
| gipfeli 2016-07-13 | 233MB /秒| 451 MB / s | 87931759 | 41.49 |
| pithy 2011-12-24 -9 | 257MB /秒| 1263 MB / s | 90360813 | 42.63 |
| pithy 2011-12-24 -6 | 295 MB / s | 1268MB /秒| 92090898 | 43.45 |
| quicklz 1.5.0 -1 | 346MB /秒| 435MB /秒| 94720562 | 44.69 |
| トカゲ1.0-20 | 284MB /秒| 1734MB /秒| 96924204 | 45.73 |
| pithy 2011-12-24 -3 | 352 MB / s | 1222 MB / s | 97255186 | 45.89 |
| lzrw 1991年7月15日-4 | 243 MB / s | 392MB /秒| 100131356 | 47.24 |
| lzo1x 2.09 -1 | 394MB /秒| 551 MB / s | 100572537 | 47.45 |
| lz4 1.7.5 | 452MB /秒| 2244 MB / s | 100880800 | 47.60 |
| fastlz 0.1 -2 | 243 MB / s | 469MB /秒| 100906072 | 47.61 |
| lzo1y 2.09 -1 | 397MB /秒| 556MB /秒| 101258318 | 47.78 |
| lzo1x 2.09 -15 | 406 MB / s | 549MB /秒| 101462094 | 47.87 |
| 密度0.12.5ベータ-2 | 480MB /秒| 655MB /秒| 101706226 | 47.99 |
| lzf 3.6 -1 | 251MB /秒| 565 MB / s | 102041092 | 48.14 |
| スナッピー1.1.4 | 327 MB / s | 1075MB /秒| 102146767 | 48.19 |
| blosclz 2015-11-10 -9 | 220 MB / s | 696MB /秒| 102817442 | 48.51 |
| pithy 2011-12-24 -0 | 384MB /秒| 1221 MB / s | 103072463 | 48.63 |
| lzo1x 2.09 -12 | 418 MB / s | 550MB /秒| 103238859 | 48.71 |
| トカゲ1.0-10 | 360 MB / s | 2625 MB / s | 103402971 | 48.79 |
| fastlz 0.1 -1 | 235MB /秒| 461MB /秒| 104628084 | 49.37 |
| lzrw 1991年7月15日-3 | 226MB /秒| 449MB /秒| 105424168 | 49.74 |
| lzf 3.6 -0 | 244MB /秒| 550MB /秒| 105682088 | 49.86 |
| lzo1x 2.09 -11 | 424MB /秒| 560MB /秒| 106604629 | 50.30 |
| lz4fast 1.7.5 -3 | 522MB /秒| 2244 MB / s | 107066190 | 50.52 |
| 竜巻0.6a-1 | 233MB /秒| 334MB /秒| 107381846 | 50.66 |
| memcpy | 8657 MB / s | 8891 MB / s | 211947520 | 100.00 |

LZ4は最も適切なコンプレッサーのように見えますか？

もしあれば、lz4（> = 1.7.0 r129）とzstd（> = 1.3.0）が必要だと思います。 これらはborgbackupにも使用します。

しかし、zstdは、lz4の速度からより良いものまで、1つの整数で非常に調整可能です。
xz圧縮より。 それは密集した幸せなユーザーを遅くするでしょう
圧縮と高速圧縮のもの。 そのzstdは言うまでもありません
圧縮作業に関係なく、非常に高速に解凍します。

lz4は非常に狭い目的です。

2017年12月16日土曜日09:50:49 AM -0800に、TWは次のように書いています。

もしあれば、lz4とzstdが必要だと思います。 これらはborgbackupにも使用します。

-
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/restic/restic/issues/21#issuecomment -352199097

-
（Escriu-me xifrat si saps PGP / PGPを知っている場合は暗号化された書き込み）
PGPキー7CBD1DA5- https： //emailselfdefense.fsf.org/

ええと..https ： //github.com/restic/restic/issues/21#issuecomment -250983311によると、resticの依存関係を解放しておくと、今のところzstdはオプションではありません。 また、特許/ライセンスの問題に関するスレッドがいくつかあります。

xzと高い圧縮率については、低い圧縮設定でも、表によると、最速の圧縮は約15MB /秒です。

高速バックアップの要件が低くなった場合、たとえば、> = 30MB /秒の場合、次のように追加できます。

| コンプレッサー名| 圧縮| 解凍します。| Compr。 サイズ| 比率|
| --------------- | ----------- | ----------- | ----------- | ----- |
| xz 5.2.3 -9 | 1.70 MB / s | 56 MB / s | 48745306 | 23.00 |
| xz 5.2.3 -6 | 1.89 MB / s | 58MB /秒| 49195929 | 23.21 |
| xz 5.2.3 -3 | 4.18 MB / s | 55MB /秒| 55745125 | 26.30 |
| zstd 1.1.4 -8 | 30MB /秒| 609MB /秒| 61021141 | 28.79 |
| zling 2016-01-10 -2 | 32MB /秒| 136MB /秒| 61917662 | 29.21 |
| xz 5.2.3 -0 | 15MB /秒| 44MB /秒| 62579435 | 29.53 |
| zling 2016-01-10 -0 | 38MB /秒| 134MB /秒| 63407921 | 29.92 |
| zstd 1.1.4 -5 | 88MB /秒| 553MB /秒| 64998793 | 30.67 |
| lzfse 2017-03-08 | 48MB /秒| 592 MB / s | 67624281 | 31.91 |
| libdeflate 0.7 -6 | 64MB /秒| 609MB /秒| 67928189 | 32.05 |
| brotli 2017-03-10 -2 | 98MB /秒| 289MB /秒| 68085200 | 32.12 |
| zstd 1.1.4 -2 | 185MB /秒| 587MB /秒| 70164775 | 33.10 |
| 竜巻0.6a-4 | 91MB /秒| 197MB /秒| 70513617 | 33.27 |
| libdeflate 0.7 -3 | 96 MB / s | 602MB /秒| 70668968 | 33.34 |
| xpack 2016-06-02 -1 | 98MB /秒| 506MB /秒| 71090065 | 33.54 |
| 竜巻0.6a-3 | 119MB /秒| 188MB /秒| 72662044 | 34.28 |
| libdeflate 0.7 -1 | 117MB /秒| 570MB /秒| 73318371 | 34.59 |
| トカゲ1.0-42 | 90MB /秒| 938 MB / s | 73350988 | 34.61 |
| zstd 1.1.4 -1 | 242MB /秒| 636 MB / s | 73654014 | 34.75 |

複数のdeflate実装がありますが、それらが比較可能かどうかは不明です。
参考のために左xz
zstdはとても有望に見えます。 残念ながら、Goの実装はありません

@viriczstdは完全にlz4の速度ではありません。

ただし、コンプレッサーを複数ではなく1つだけにしたい場合は、zstdの方が柔軟性があります。

私の遅刻を許してください。 いくつかのコメント：

圧縮速度：ブロックを追加するたびにこの操作を実行するため、重要です。ボトルネックにならないように、AES-NIと一般的なI / Oに対応できるものが本当に必要です。 これらの新しいアルゴリズム（zstd、lz4、brotliなど）が最適化されているWebブラウザーの反対のユースケースがあるため、解凍よりも圧縮が遅いアルゴリズムを選択することはおそらく望ましくありません（「頻繁に圧縮し、ほとんど解凍しない」 「一度圧縮し、頻繁に解凍する」とは対照的です）。

いいえ、ハードウェアアクセラレーションによるAES速度で圧縮する必要はありません。 圧縮とは、サイズと時間を交換することです。 圧縮バックアップにはさらに時間がかかることが完全に予想されます。

たとえば、個人のバックアップでresticを使用するのではなく、Obnamを使用しています。これは、それらを保存する小さなサーバーの1つで、圧縮されていないと収まらないためです。 バックアップにはすでに数時間かかり、バックグラウンドで実行されるため、気付くことさえありません。

resticの圧縮バックアップに時間がかかってもかまいません。 確かに、私は彼らがそうすることを期待しています、そしてそれは私がしなければならないトレードオフです。 この種の圧縮がなければ、resticは私には役に立ちません。

解凍速度：解凍速度は、復元する場合にのみ関係します。 遅い復元で問題がなければ、遅い解凍速度を受け入れることができます。 一方、ゆっくりと解凍したくないメタデータもあるため、2つの異なるアルゴリズムが必要になる場合もあります。

復元はバックアップよりもはるかに少ない頻度で実行されるため、解凍速度はそれほど重要ではありません。 誰かが、それらは時間のプレッシャーの下で行われることが多いと述べました。これは真実ですが、復元がバックアップと同じくらい高速である必要がある、またはそれに近い場所である必要があるという意味ではありません。

また、2つの（少なくとも？）異なる種類のデータがあります。 およびデータチャンク。 この2つは使用方法が異なり、異なるアルゴリズムを選択することが理にかなっているのかどうかについて議論できると思います。

インデックスを圧縮する必要はないかもしれません（または必ずしも良い考えではありません）。 インデックスであるため、全体の目的は一意のデータを格納することであるため、そもそもインデックスが適切に圧縮される可能性は低いと思われます。

個人的には、Resticの再実装（新しい言語など）が不当に難しくならないように、（選択したものは何でも）1つのアルゴリズムに固執する必要があると思います。 また、2つのエキサイティングな圧縮アルゴリズムのバグにさらされないようにするためです。これらは、コーナーケースをテストするのが難しいためです。

私はこれらの懸念を理解していますが、それは間違いだと思います。 少なくとも、リポジトリ形式では、将来新しいアルゴリズムを追加できるように、複数の圧縮アルゴリズムを許可する必要があります。 ユーザーが使用したいものを選択できるように、おそらく圧縮用のプラグ可能なモジュールがあるはずです。たとえば、ユーザーが必要に応じてインストールできるrestic-xz 、 restic-zstdなどのDebianパッケージを想像できます。それらのアルゴリズムを使用してください。 バックアップデータの圧縮は、resticが圧縮関数に一部のデータを渡して圧縮を取り戻すように抽象化する必要があり、resticはその間に何が起こってもかまわないようにする必要があります。 減圧についても同じです。

高速バックアップの要件が低くなった場合、たとえば> = 30MB /秒の場合、追加できます

それは私には理にかなっているようです。 ローカルバックアップは1種類だけであることを忘れないでください。 ネットワークバックアップは、圧縮速度によってボトルネックになる可能性が低くなります。

ただし、ユーザーがニーズに合った適切なソリューションを選択できるように、これはユーザーが調整できる必要があります。

：beer：:)に10 $の報奨金を追加しました

🍺++

他の誰かが貢献したい場合は、BountySourceへのリンクがあります

https://api.bountysource.com/badge/issue?issue_id=6096108

速度とサイズの選択はユーザーが決定できるように、これをユーザーが構成可能な方法で実装できるかどうか疑問に思います。 私はデフォルトとしてより高い圧縮を好むでしょう。

いつそこに着くかを決めましょう。 記録のために：私はユーザーに速度対サイズの点で少しの制御を与えることに問題はありません。

圧縮の実装が必要なresticの場合は+1。 私はresticを使用してVMイメージをバックブレイズにバックアップしており、アップロードする前にそれらを圧縮できるようにしたいと考えています。 私のユースケースでは、転送/保存されるデータのサイズを減らすために、ほぼ無限の時間/ CPUを交換します。 スピードがもっと気になる人もいると思います。 複数のアルゴリズムを選択できるプラグ可能なアーキテクチャを持つことが重要です。

これがさらに検討されるので、私はテストを手伝ってうれしいです。

@ fd0私がresticコードベースに取り組んでからしばらく経ちました。 あなたが良いアプローチと私がどこを見るべきかについての迅速な指示を与えることは可能ですか？

@klauspost技術レベルで圧縮を追加することはそれほど簡単ではありませんが、それはかなり簡単ですが、下位互換性のある方法でリポジトリ形式のアップグレードを処理する方法です。 私は現在、アーカイバの部分を書き直すのに忙しいので（＃549のような醜いものがなくなるように）、その後、圧縮を追加してからリポジトリv2に切り替えたいと思います。

どの圧縮アルゴリズムを使用すべきかについてどう思いますか？ 私は3つのモードをサポートすることを考えています：
1）圧縮なし
2）「線形時間」圧縮（CPU負荷をあまり追加しません）
3）「最大圧縮」

たぶん、最初と2番目のモードは同じになるでしょう、私はまだわかりません

zstdのようなものを使用できるのは最も素晴らしいことですが、ネイティブのGoコードとして使用できます。 ダミアンは、JavaバージョンまたはCバージョンのいずれかを移植するのはそれほど手間がかからないかもしれないとほのめかしました：https：//twitter.com/dgryski/status/947259359628738560、それを試すことに興味を持ってもらうために私にできることはありますか？ :)

私はzstd形式の仕様を見てきましたが、実装するのは簡単ではありません（まあ）。 Javaソースは解凍のみです。

高速圧縮の場合、LZ4は非常にうまく機能するはずです。 Goポートは優れています。 zstdの方が良いでしょうが、cgo実装を使用したくない場合を除いて、私は実証済みのパッケージを使用します。

中途半端な場合でも、デフレート圧縮は速度/圧縮の点で優れています。 よくテストされているなど。

高圧縮はもう少し注意が必要です。 ただし、 github.com / ulikunitz / xzパッケージにネイティブのLZMA（2）Go実装がある

ソースを調べて、圧縮ステップを挿入する自然な場所を見つけました。 私にとって理にかなっているのは、ここで解凍することでした。 しかし、圧縮を特定して追跡することには課題があります。

また、私が作成した「圧縮率推定器」も

また、私が作成した「圧縮率推定器」もご覧ください。 データのブロブがどれだけ圧縮可能であるかを簡単に見積もることができます。 通常、> 500MB / sで動作するため、圧縮が難しいデータをすばやく拒否するために使用できます。

圧縮率推定器が大好きです！ 圧縮できないデータを圧縮しようとしないようにすると、速度が大幅に向上します。

Zstdにはそのようなものが組み込まれています： [1]

Zstdは、非圧縮性データをより高速に通過します。 1GB /秒を超える何かを期待する

その明確なベンチマークは見つかりませんでしたが。

xzパッケージはlzmaにとってお得なもののように見えます。 デフォルト設定でいくつかの簡単なテストを行いました：

| アルゴリズム| レベル| insize | 特大| ミリス| mb / s | 比率|
| ----------- | ------- | ------------ | ----------- | ---- ---- | -------- | -------- |
| lz4 | -| 1000000000 | 625968314 | 5454 | 174.85 | 62.60％|
| flatekp | 1 | 1000000000 | 391051805 | 12367 | 77.11 | 39.11％|
| flatekp | 5 | 1000000000 | 342561367 | 20164 | 47.3 | 34.26％|
| flatekp | 9 | 1000000000 | 324191728 | 43351 | 22 | 32.42％|
| lzma2 | | 1000000000 | 291731178 | 149437 | 6.38 | 29.17％|
| lzma | | 1000000000 | 291688775 | 161125 | 5.92 | 29.17％|

非常に合理的な速度/圧縮のトレードオフ。 すべてenwik9でのシングルコアパフォーマンス10GBのコーパスのようなものをテストする時間がありませんでした。

lzma2は、標準のlzmaよりも現在の実装で多くを提供しているようには見えません。 あなたは小さなブロックを扱っているので、違いはかなり小さいはずです。

Zstdにはそのようなものが組み込まれています

はい、lz4やdeflateと同様に、しかし、私はそれが専用の機能ほど速くは見ていません。

zstdは間違いなく本当に印象的です。 cgo実装を使用したベンチマーク：

| レベル| insize | 特大| ミリス| mb / s | 比率|
| ------- | ------------ | ----------- | -------- | ------- -| -------- |
| 1 | 1000000000 | 358512492 | 5100 | 186.96 | 35.85％|
| 2 | 1000000000 | 332265582 | 6264 | 152.24 | 33.23％|
| 3 | 1000000000 | 314403327 | 8099 | 117.75 | 31.44％|
| 4 | 1000000000 | 310346439 | 8588 | 111.04 | 31.03％|
| 5 | 1000000000 | 305644452 | 12739 | 74.86 | 30.56％|
| 6 | 1000000000 | 292551252 | 18531 | 51.46 | 29.26％|
| 7 | 1000000000 | 287414827 | 23212 | 41.08 | 28.74％|
| 8 | 1000000000 | 282783804 | 27811 | 34.29 | 28.28％|
| 9 | 1000000000 | 280432907 | 31752 | 30.03 | 28.04％|

私が何かを逃した場合は私を許してください、しかし私はこれらの質問が以前に答えられたのを見ませんでした。

1. ファイルレベルではなく、チャンクレベルでの圧縮について話しているようですよね？
2. その場合、単一ファイルの複数のチャンクに複製されたデータが保存され、チャンクごとに圧縮されるため、これは明らかに有効性を制限します。
3. ただし、それは明らかにチャンクサイズにも依存します。
4. では、平均チャンクサイズはどれくらいですか？ このように、圧縮がどれほど有用であるかという重要な要素であるように思われます。
5. チャンクサイズがかなり小さい場合は、圧縮性の高いファイルに対して、フルファイルの事前チャンク圧縮を検討する必要があります（たとえば、 @ klauspostの推定量を使用）。 たとえば、50 MBのテキストファイル（ログファイル、大きなOrg-modeファイルなど）は、単一のファイルとして非常に圧縮可能である可能性があります。 ただし、最初にチャンク化され、次に各チャンクがインデックスを共有せずに個別に圧縮されると、圧縮（IIUC）の有効性が大幅に制限されます。

ありがとう。

ファイル全体を圧縮すると、重複排除アルゴリズムが改ざんされ、効率が低下する可能性があります。

それ以外に、スペース的に大きな利点を提供しながら圧縮を行うと、サイドチャネル攻撃が発生する可能性があることを忘れないでください。 圧縮されたデータのサイズから、データの内容について知識に基づいた推測を行うことができます。 これは前に述べたと思いますが、それでも。

@alphapapa

ファイルレベルではなく、チャンクレベルでの圧縮について話しているようですよね？

はい、チャンクレベルで。

その場合、単一ファイルの複数のチャンクに複製されたデータが保存され、チャンクごとに圧縮されるため、これは明らかに有効性を制限します。 ただし、それは明らかにチャンクサイズにも依存します。 では、平均チャンクサイズはどれくらいですか？ このように、圧縮がどれほど有用であるかという重要な要素であるように思われます。

1MiBを目指していますが、8MiBにもなる可能性があります。

チャンクサイズがかなり小さい場合は、圧縮性の高いファイルに対して、フルファイルの事前チャンク圧縮を検討する必要があります（たとえば、 @ klauspostの推定量を使用）。 たとえば、50 MBのテキストファイル（ログファイル、大きなOrg-modeファイルなど）は、単一のファイルとして非常に圧縮可能である可能性があります。 ただし、最初にチャンク化され、次に各チャンクがインデックスを共有せずに個別に圧縮されると、圧縮（IIUC）の有効性が大幅に制限されます。

最初に、圧縮をチャンクレベルで統合し、それが実際のシナリオでどの程度うまく機能するかを確認したいと思います。 このアイデアは後で再検討できます。

@klauspostいくつかのアルゴリズム/実装とあなたの推奨事項のベンチマークに時間をcgo依存しないことがはるかに重要だと思います。 そして、圧縮率推定器を使用することは素晴らしいアイデアです、私はそれが大好きです。

圧縮/解凍を追加するために言及した場所は良いように聞こえますが、そのためのメタデータを別の場所で追跡する必要があります。 おそらく、パックヘッダーのバイトのビットに意味を追加すると思います。http： //restic.readthedocs.io/en/latest/100_references.html#pack-formatを参照してください。 これは非常に注意深く行う必要がある部分です。

それで、＃1494で終了させて​​ください。そうすれば、これが解決されることがわかります。

@sanmai re：サイドチャネル：私はもともとそれを取り上げました。
さまざまな解決策が提案されましたが、私は個人的に次のことに満足します。

• 圧縮のホワイトリスト/ブラックリスト使用のための構成オプションがある（ファイルインクルードの場合と同様）

もう1つのアイデアは、パックファイル内のチャンク境界を非表示にすることでした。これにより、理論的には難しくなりますが、ネットワーク書き込みのタイミングや、チャンクが書き込まれたファイルシステムの範囲などのサイドチャネルは引き続き可能だと思います。などを使用して境界を推測できるため、機密データを圧縮しないようにアドバイスするのが最も安全で簡単だと思います。

これは素晴らしいでしょう！ ：ビール：+ $ 10

ただそれを捨てるだけですが、lzmaやより一般的な圧縮アルゴリズムを別にして、ランレングスエンコーディングやゼロスカッシングはどうですか？ それとも、これは十分な人々にとって十分に有用ではないでしょうか？

（私はこの狩りに犬を飼っています、私はしばしばたくさんの沈黙のある巨大なWAVファイルをバックアップしています。）

+ $ 15

ただそれを捨てるだけですが、lzmaやより一般的な圧縮アルゴリズムを別にして、ランレングスエンコーディングやゼロスカッシングはどうですか？ それとも、これは十分な人々にとって十分に有用ではないでしょうか？

ほとんど空のスペース/スパースファイルを含むVMドライブのバックアップにも役立ちます（resticがすでにスパースファイルのバックアップ/復元をサポートしているかどうかはわかりません）

@bherila resticは、スパースファイルのアーカイブ/復元をまだサポートしていません。ファイルは、多くのゼロが含まれているようにリポジトリに保存されます。 これらのゼロの大きなブロックは重複していないため、リポジトリ内のスペースをあまり占有しません。 ただし、復元の場合、「穴」のない通常の（スパースではない）ファイルになります。

確認したかったのですが、すでに何らかの圧縮がありますか？ 50GBのデータを備えたコンピューターを含むいくつかのコンピューターをバックアップしましたが、サーバー上の数ははるかに少なくなっています。

# du -shc /home/restic/
40G     /home/restic/
40G     total

@Alwaysinもちろん一部のファイルが除外されていない限り、おそらく重複排除です。

@rawtazありがとうございます。重複排除については知りませんでした。

@rawtazが述べたように、大きな繰り返しブロックの

@klauspostあなたはこれを見ましたか？ https://github.com/mvdan/zstd

はい、しかし正直なところ、ストリームデコーダーは簡単な部分です。 FSEのエンコード/デコードを終了し、ハフマンエンコーダーの準備ができました。 ハフマンデコードが完了すると、zstdストリームデコーダーは非常に簡単になり、完全なエンコーダーが最後の部分になります。

LZ4は完全に十分であり、すぐに勝つこともできます。

lz4を追加して、zstdをサポートする別のPRを作成してみませんか？

lz4を追加して、zstdをサポートする別のPRを作成してみませんか？

@ dave-flリポジトリの形式を変更するときは、細心の注意を払う必要があるためです。 これは、下位互換性のある方法で実行する必要があります。 プロジェクト全体の最も重要な部分は、実装ではなく、リポジトリ形式です。 人々は、データを復元できるようにフォーマットを台無しにしないことを私たちに頼っています:)

圧縮で待ちきれないと思います。 サーバーバックアップのいくつかのリポジトリでいくつかのテストを行ったところですが、リポジトリをgzipで圧縮してもまったく勝ちません！ @Alwaysinのように、重複排除ですでに30％を獲得しています。

下位互換性のある方法については、Resticが両方の形式またはツールを読み取って、古い形式から新しい形式に移行する必要があることを意味しますか？ Resticがv1.0.0でない場合は、移行するだけで問題ないと思います。

サーバーバックアップのいくつかのリポジトリでいくつかのテストを行ったところですが、リポジトリをgzipで圧縮してもまったく勝ちません！

うーん、それは予想されることです。リポジトリ内のすべてのデータは暗号化されているため、圧縮することはほとんどできません。 圧縮を使用する場合は、暗号化する前にデータに対して圧縮を行う必要があります。

LZ4を使用すると、下位互換性がなくなる方法がわかりません。 圧縮は圧縮です。 複数のフォーマットをサポートしないのはなぜですか？

そうです、私はそれについて考えていませんでした。
ただし、ソースをgzipで圧縮すると、30％を超えて勝つことはありません。重複排除は、重複が多い大きなディレクトリですでに非常に効率的です。 しかしもちろん、両方でそれは印象的である可能性があります。
圧縮と重複排除を行うzpaqを使用すると、それほど多くはなく、もう少しだけ勝ちます。
私は圧縮を使用してブランチをテストすることに非常にオープンです。互換性がないかどうかは関係ありません。

LZ4を使用すると、下位互換性がなくなる方法がわかりません。 圧縮は圧縮です。 複数のフォーマットをサポートしないのはなぜですか？

2つのクライアントが同じリポジトリを使用しているが、そのうちの1つが圧縮をサポートしていない古いバージョンのresticを使用している場合はどうなりますか？ この機能は、考えられるすべてのコーナーケースを念頭に置いて慎重に設計する必要があります。

以前のバックアップを壊す可能性のある、半分機能するソリューションよりも圧縮しないほうがいいと思います。

圧縮の追加の問題については十分な議論があったと思います。 待望の機能だと思います。 新しいアーカイバコードを完成させた後、次にこれに取り組みます（＃1494を参照）。

これ以上コメントを追加しないでください、ありがとう！

@dimejoあなたが言っていることは、私が提案したこととは何の関係もありません。 zstdまたはlz4のどちらを実装するかは、両方の場合に影響します。

私はあえてzstdのCGOバージョンがいくらか移植可能に見えると言います:)

私は、仕様に基づいて、zstdのgolang実装を非常に簡単に書くことがどれほど実現可能であるかを調べました。

zstdはほとんどすべての社内アルゴリズムですが、（オプションで）エラーチェックのためにgolangポートがあります。 オプションのビットはオプションであるため、resticでリーダー/ライターのzstdサポートを取得するためにこれらの部分を実装する必要はありません。 zstdは、圧縮を最適化するための「辞書」の概念をサポートしています。これが制限とどのように相互作用するかはわかりませんが、JSONやメタデータストリームなど、アーカイブの特定の部分を圧縮するための興味深い研究分野です。 それ以外の場合、その実装はオプションであるためスキップすることもできます。

もちろん、トリッキーになるのは、エントロピーコーディングが始まるところです。zstdは、有限状態エントロピー（FSE、[ANS]のバリエーション）（https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#、他のエントロピーコーディングビットはハフマンコーディングで実装されており、そのうちの2つは標準ライブラリにあります。1つはcompress.flateにあり、もう1つはnet.http2.hpackにあります。かなり奇妙です。

私の知る限り、他のすべてはその上に接着剤です...いくつかのハフマンツリー、シーケンス、フレーム、ブロック。 ブロックとフレームの構築方法にも興味深いプロパティがあり、それらはレストブロブにうまくマッピングされる可能性があります。これにより、ブロブを内部で分離したままリポジトリ全体を圧縮できる可能性がありますが、詳細は調べていません。 。 また、リポジトリ形式と圧縮の間の結合が受け入れられなくなる可能性があります。

zstdはgzipやxzipよりも大幅に複雑で、それぞれ36kと12kと比較して、約70k行のコード（clocによる）があります。 ただし、これには多数のテストが含まれます。これらを無視すると、実装自体はgzip（〜34k）とほぼ同等になります。

したがって、要約すると、これがgoで実装されるのは時間の問題です。 zstdの「フレーム」は互いに独立しているため、このようなエンジンはgolangの並列処理も活用できると思います。 ただし、フレームがどのように使用されるかはわかりません。テストしたほとんどのストリームには、1つ（ zstd /etc/motd ）または2つ（ zstd isos/Fedora-Workstation-Live-x86_64-27-1.6.iso ）のフレーム（ binwalk -R "\x28\xb5\x2f\xfd" ）しかありませんzstd /etc/motdブロックは相互に関連していて並列化が難しいため、そこではそれほど利益が得られない可能性があります。

とにかく、ここの誰かが実際に座ってそれを移植したいのでなければ、すべてが議論の余地がありますが、私はそれを読んでいる間に見つけたものを共有すると思いました... zstdがコンプレッサーのLZ77ファミリーのLZMA部分の拡張であることを考えると、それはすべきではありません移植するのは不可能ではありません...

圧縮に関する更新はありますか？ 多くの人がzstdを待ちたいと思っていることは知っていますが、 lz4またはlzoまたはlzmaを実装するとどうなるでしょうか。

更新があった場合、この問題は更新されます。

それまでの間、作者の要求を尊重してみましょう。

これ以上コメントを追加しないでください、ありがとう！

@ fd0 、zstdアルゴリズムhttps://github.com/klauspost/compress/tree/master/zstdの純粋なGo実装があるようだということを指摘したかっただけです。 私はこれを自分で試したことがありません。 しかし、これは私がresticでの圧縮サポートの可能性に興奮しました。

Go zstdのもの（速度？コード品質？メンテナンス？）はわかりませんが、C zstdのものは、高速/小圧縮から低速/高圧縮までの幅広い範囲をサポートしているため、バックアップツールに必要なすべてのものです。

borgbackupに他のすべての圧縮アルゴリズム（lz4、zlib、lzma）がまだなく、今すぐ圧縮を追加し始める場合は、zstdだけで生きることができると思います。

好み/好みの問題として、デフォルトはなし（以前のように）または非常に高速なzstdレベル（転送するデータが少ないため、全体としてほとんどのバックアップが高速になります）になります。

こんにちは、
私の意見では、圧縮はresticの機能を備えている必要はありません。 Duplicati（圧縮あり）とrestic（圧縮なし）で実行したデータのバックアップを比較しましたが、全体的な使用スペースは非常に似ていました。
高速で信頼性の高い増分バックアップを取得するためにのみ、resticが必要です。 ビットを壊す必要はありません...
復元も重要であり、resticは災害復旧に適しています。 ローカルデータベースを失った場合、修復タスクに数日かかるため、重複は悪夢です...

@ fd0に感謝し、すべての貢献者に感謝します！

@filippobottega実験で大きな違いが見られなかった場合は、次のいずれかを意味します。

• データが（あまり）圧縮可能ではなかった（ただし、これは一般的にはそうではありません）、または
• その重複は、圧縮とは関係のないストレージ効率の低下をもたらしたため（たとえば、ストレージ形式、粒度、アルゴリズムなどが異なるため）、圧縮の節約は他の領域での損失によって補われました。

どちらも、圧縮が無意味であることを意味するものではありません。

@ThomasWaldmann最初の理由で大きな違いは見られません。
今日のデータはすでに多くの方法で圧縮されています。docx、xlsx、pptx、zip、7z、jpeg、tifなどはすべて圧縮形式です。 また、isoイメージには圧縮ファイルが含まれています。 このため、圧縮はレスティックでは無意味だと思います。

@filippobottegaあなたの見解は、人々がバックアップにresticを使用しているデータについて少し狭義です。 SQLダンプ、ソースコード、データセット、生の画像などはどうですか？ 重複排除は、バックアップ間のデルタサイズを削減するのに優れた役割を果たしますが、データセットの元のサイズを削減することはできません。 非圧縮形式の場合、これは数ギガバイトを意味する可能性があります。 言うまでもなく、非圧縮形式を保存してから圧縮+重複排除を行うと、すでに圧縮されているファイルを重複排除するよりも良い結果が得られる可能性があります。

SQLダンプは私の最初の考えでしたが、resticはメールサーバーもバックアップし、Duplicatiからresticに移行するときに取得したいくつかのRARスナップショットに基づいて全体的な圧縮が向上しているようです。

圧縮をオプションにし、ファイルタイプのデフォルトのリストを作成するためのユースケースを見ることができますが、圧縮によってかなりの金額を節約できます。

@mrschyte

あなたの見解は、人々がバックアップにresticを使用しているデータについて少し狭義です。

今、個人的になる必要はありません。 彼の見方はあなたの見方と同じくらい有効であり、検討する価値があります。 バックアップするほとんどのデータは、ファイル形式が原因ですでに圧縮されていることがわかりました。

SQLダンプはどうですか

SQLダンプを実際に非圧縮で保存していますか？ 私はそれらを生で保存する必要がないので、それらをバックアップする前にすべて私のものをgzします。

ソースコード、データセット、生画像など

圧縮バックアップの唯一の有効な使用例は、繰り返しの多い大きな非圧縮ファイルであると思います。これらのファイルはアクティブに使用されているため、まだ圧縮されて保存されていません。 私の経験（他の人のデータの管理を何年も含む）では、このカテゴリに分類されるデータはほとんどありません。 少なくとも、これらの場合に大きな違いを生むには十分ではありません。

ただし、データセットの元のサイズを縮小することはできません。

間違いなく、それはバックアッププログラムの仕事ではありません。 元のデータに触れてはいけません。

言うまでもなく、非圧縮形式を保存してから圧縮+重複排除を行うと、すでに圧縮されているファイルを重複排除するよりも良い結果が得られる可能性があります。

多くの圧縮アルゴリズムは複製に依存して作業を行っているため（フラットの辞書を参照）、少なくとも時々は正しいと思いますが、これは_一般的に_確信が持てません。

（resticでの圧縮が正しく行われた場合に_悪い_と言っているのではなく、特に長引くパフォーマンスの問題と比較して、優先する必要はないと主張しているだけです。 @ fd0の時間制約を尊重する必要があります。ビジョンに関する願い。）

@mholt一般的には同意しますが、ルートバックアップを実行すると（ダンプを介して、または/の内容を反復処理することで）、優れた圧縮率が得られます。 使用量の合計はすでに少ないため、必須ではありませんが、約50％の節約になります。エンドユーザーに関する限り、これは「無料」でいつでも利用できるので便利です。

このテストを試してください。

1. SQLダンプまたはその他の非圧縮ファイルを取得します。 それを圧縮してから
   それをバックアップするresticを使用してください。
2. SQLデータベースからテーブルを削除し、2番目のダンプを取得してから、圧縮します。
   次に、resticを使用してバックアップします。

圧縮は前に行われるので、あなたはそれを見つけると思います
重複排除では、resticsの重複排除アルゴリズムをほぼ完全に無効にします。
ただし、重複排除後にresticが圧縮を処理できる場合
全体的な出力がはるかに小さくなるはずです。

DataDomainのようなツールを使用するエンタープライズストレージ業界では、常に
圧縮されていない状態でデータをストレージデバイスにフィードすることをお勧めします
フォーマットして、デバイスに重複排除と圧縮を実行させます。 NS
これらのツールを適用する一般的な順序は重複排除です。
圧縮、次に暗号化。 これについて少し考えてみてください。
同じデータを複数回圧縮するために余分なCPUをすべて費やしたい
とにかくそれが重複排除され、本質的に破棄されるためだけの時間ですか？ これは
重複排除を最初に行うことでデータセットを削減することが最善であると一般に認められています
圧縮を行うという潜在的に重いタスクを費やす前に。

2019年8月2日金曜日午後1時29分ブランドンシュナイダー[email protected]
書きました：

@mholt https://github.com/mholt私は一般的に同意し
ルートバックアップ（いくつかのダンプを介して、または/の内容を反復することによって）、
私にとっては素晴らしい圧縮率が得られます。 合計として、必須ではありません
使用済みはすでに小さいですが、約50％の節約になり、それは常に素晴らしいことです
エンドユーザーに関する限り、「無料」で利用できます。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/restic/restic/issues/21?email_source=notifications&email_token=AC3I762ZVGTTJL4TF3ODZILQCRVIXA5CNFSM4AXPP352YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLO
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AC3I767IQQD3CZBIWM37C6TQCRVIXANCNFSM4AXPP35Q
。

SQLダンプを実際に非圧縮で保存していますか？ 私はそれらを生で保存する必要がないので、それらをバックアップする前にすべて私のものをgzします。
間違いなく、それはバックアッププログラムの仕事ではありません。 元のデータに触れてはいけません。

この種のビューはデータの効率的な保存を妨げるように感じますか？ すべてのプログラムとエクスポート操作が独自のアドホック圧縮形式を実装する必要があるという考えは、重複排除/圧縮などが事前定義されたファイルごと（またはディレクトリtarball）スコープ以外で機能するのを防ぐため、私が避けようとしているものです。 ファイルを個別に圧縮すると、さまざまなファイル/ダンプなどの共通点を見つけることができなくなり、その後、重複排除のすべての利点が失われます。 物事を非圧縮に保つことで、ファイルシステム（zfs、btrfsなど）がこれをすべて行うことができます。また、フォルダーやスナップショットなどを圧縮および重複排除し、動作する必要のあるツールとの互換性を維持しながら、これをすべて抽象化できるため、より優れています。圧縮されていないデータを使用します。

圧縮は、top resticの重複排除に対する単なる追加の最適化と見なすことができますが、個別に実行すると相互に互換性がないように見えます...ファイルをバックアップする前に圧縮して前処理することを提案すると、すべてがワークフローに戻ります。代わりにrsync / rcloneを使用するだけなので、そもそもなぜresticを使用するのでしょうか。

この種のビューはデータの効率的な保存を妨げるように感じますか？ すべてのプログラムとエクスポート操作が独自のアドホック圧縮形式を実装する必要があるという考えは、重複排除/圧縮などが事前定義されたファイルごと（またはディレクトリtarball）スコープ以外で機能するのを防ぐため、私が避けようとしているものです。 ファイルを個別に圧縮すると、さまざまなファイル/ダンプなどの共通点を見つけることができなくなり、その後、重複排除のすべての利点が失われます。 物事を非圧縮に保つことで、ファイルシステム（zfs、btrfsなど）がこれをすべて行うことができます。また、フォルダーやスナップショットなどを圧縮および重複排除し、動作する必要のあるツールとの互換性を維持しながら、これをすべて抽象化できるため、より優れています。圧縮されていないデータを使用します。

これは、データの効率的な保存だけでなく、既存のワークフローでもあります。 システムの他の側面にワークフローを適用するのではなく、バックアップ製品がデータを確実かつ効率的にバックアップすることを望んでいます。 バックアップ（保持される可能性があり、無期限に保持される可能性があります）を効率的に保存することははるかに重要ですが、ライブ作業データは、アクティブに使用する方法に最適な形式で保存する必要があります。

現在、特に低速のストレージシステムで非常に圧縮可能なデータを使用する場合は、保存する前に圧縮することが理にかなっている場合がありますが、これは私の経験ではルール以上の例外です。

+1圧縮は本当に私を助けます！ ソフトウェアエンジニアとして働いている私は、圧縮されていないソースコードがたくさんあるホームフォルダ全体をバックアップします（そして、RubyやPythonなどの動的言語では、ほとんどの場合、ソースコードであり、ほとんどの依存関係もあります）。

自宅では、バイナリ、manファイル、リソースファイルなど、圧縮の恩恵を受ける多くのものを含めて、/全体をバックアップします。

もちろん、それらすべてを圧縮し、バックアップする前に多くの変換を行うことはできますが、それでは、非常に単純なコマンドを実行するだけで、バックアップを取得できるという便利さの多くが損なわれます。物事を復元します。

もちろん、うまく圧縮されないファイルのクラスはたくさんありますが、強制的に圧縮する必要があるとは誰も言っていません。 これを解決するための多くのアプローチがあります-圧縮するファイルタイプをホワイトリストに登録する、ファイルを圧縮しないブラックリストに登録する、または最も単純な方法です：圧縮してみて、結果のサイズが改善されない場合は、圧縮せずに保存します（ZFSを信じています）オンディスク圧縮が有効になっている場合は、このアプローチを使用します）。

結局のところ、圧縮は古典的なスペースと時間のトレードオフの一例です。より多くのCPUを支払うのか、それともより多くのストレージを支払うのか。 私の場合、ストレージが私のコストを支配しているので、クアッドコアがもう少し熱くなり、ファイルホスティングの請求額が少なくなれば素晴らしいと思います。

最後に、4TB強をクラウドプロバイダーにバックアップしましたが、アップロード速度はとにかく弱いので、ボーナス圧縮によりバックアッププロセスが遅くなるのではなく速くなります-私のCPUは私の貧弱なVDSL接続に追いつく以上のことができます。

はい、私はここで他のすべてに同意することができます。 圧縮は非常に重要であり、resticが圧縮を使用すべきではない理由についてはまったく議論がありません。

@mholt私はあなたに完全に同意します。 すべての単語。
たとえば、TFSをソース管理として使用し、すべてのソースがSQLバックアップで既に圧縮されており、アプリケーションイメージがmsiセットアップファイルまたは7zアーカイブで圧縮されているため、ツールチェーンでは圧縮が重複排除の前に行われます。 安全なディザスタリカバリ計画を実装するために必要なのは、毎日のデルタを取得してクラウドに送信するための高速で簡単な方法だけです。
@ fd0は、製品に他の複雑さを追加しようとするよりも、問題を解決するために時間を集中する必要があると思います。

auto,zstd圧縮とrestic（圧縮なし）を使用して、最初に/ 、次に/home 、VMイメージやDockerイメージ（実際のバックアップでもバックアップしないため）。 テストマシンは私の毎日のソフトウェア開発マシンであり、多くのバイナリファイル、いくつかの圧縮された画像とオーディオファイルが含まれていますが、かなりの量のプレーンテキストソースコードも含まれています。

/ ：1053136ファイル、92.9 GiB

• ボーグ、なし：17：27分、64.1 GiB
• ボーグ、zstd：19：29分、 40.6 GiB
• レスティック： 09 ：

/home ：221338ファイル、58.3 GiB

• ボーグ、zstd：09：06分、 30.7 GiB
• レスティック：04： 36分、39.4 GiB
  保管スペースに関しては、resticとほぼ同じであるため、ここでは圧縮せずにborgを省略しました。

まず、そのテストケースでほぼ正確に2倍高速であるというresticを称賛したいと思います。 ボーグの速度が遅いことは別として、圧縮によって全体のバックアップ期間が最大2分（+ 11％）しか追加されないが、 /場合（-35）に保存されるデータが大幅に削減されることは興味深いかもしれません。 ％）。 私のホームディレクトリの場合、ストレージの節約は約20％です。

（その場合、テストは外部ディスクに対して実行されました。リモートストレージにバックアップする場合、バックアップにかかる時間は、少なくともCPUとIOの速度がネットワークよりもはるかに速い場合は、アップロード帯域幅に大きく依存します。テストしました。これと圧縮を使用したborgは、圧縮によって転送されるデータが少なくなるため、実際にはresticよりも高速です）。 全体として、私は、圧縮のサポートを取得することに非常に賛成です。理想的には、自動検出を使用して、チャンクが圧縮の恩恵を受けているかどうかを確認します。

@nioncode私の計算が正しければ、約100 / 150MB / sをバックアップします。 これは、zstdが圧縮できる範囲を下回っています。 圧縮は非同期であるため、実際に速度が低下することはありません。 書くことが少ないので、少し速くなるかもしれません。

VMのアーカイブがユースケースになる可能性があることは知っていますが、その必要性を回避しようとしています。
ISOファイルとセットアップファイルから始めて、VM構築全体を自動化しようとしています。
ディザスタリカバリの場合、セットアップファイル、ドキュメント、データベースのバックアップを使用してVM全体を復元できるようにしたいと考えています。 そして、私はユーザーの操作なしでそれをやろうとしています。
このようにして、一時ファイルやexeファイルやdllファイルなどの非圧縮ファイルなど、VMに含まれる多くのゴミ箱ファイルを圧縮してバックアップする必要がなくなります。
簡単ではありませんが、同じ不要なGBのファイルを圧縮して重複排除することで、ディスク容量と帯域幅を節約できます。

誰がどのように物事を行うかについて、このスレッドを乱雑にしないでください。 それで十分です。

圧縮は多くの人が望んでいる機能であり（私自身も含まれます）、中低速のインターネット接続の場合、バックアップストレージとアップロード時間の両方を節約できます。30％以上の人もいます。

ただし、すべての人がそれを必要としているわけではなく、一部の人々はそれを処理するためにスマートな方法でワークフローを適応させています-または単にお金または帯域幅、あるいはその両方を単に気にしないようにしています。

いずれにせよ、双方が話しました。

@ bjoe2k4または、暗号化する前にデータを圧縮することによるセキュリティへの悪影響について懸念しています。これにより、過去数年間にこのスレッドで何度か議論されてきたように、平文データに関する情報が提供されます。 :)

圧縮が必須にならない限り、圧縮のセキュリティ上の懸念は、ユーザーが行うことができるトレードオフにすぎません。 この理論上のリスク（データセットが大きく、変更が予測できないため、とにかく悪用できない可能性が高いリスク）に対して、バックアップを高速化し、月次および1回限りのコストを削減します。そのため、ノイズは、圧縮からの信号）。

しかし、圧縮を必須にすることについて誰も話しているとは思いません。

私の特別な使用例は、CSVおよびSQLダンプの大きなセットをバックアップすることです。 これらのファイルは非常に圧縮可能です...そして私はそれらを事前に圧縮したくない/できません。

GBのオンラインストレージごとに支払うので、圧縮機能が本当に必要です。

この議論はもう少し活発になっているので、私が持っていたいくつかの発見を私の友人のパッチを当てたレスティックバージョンと共有したいと思います。 彼らはresticに圧縮を追加し（私が知る限り、多かれ少なかれ迅速で汚い）、誰かが興味を持った場合に実装の詳細についてコメントできるように、この投稿について通知します。
私のユースケースは、独自のデータベース形式を持つ本当に醜い銀行ソフトウェアです。 規制上の理由からこのソフトウェアを使用する必要があります。データは数TBのかなり大きなファイルであり、元のサイズの90％に圧縮できます。 したがって、明らかに、圧縮によってバックアップストレージ、バックアップ時間、および復元時間が大幅に節約されます。
上流のrestic、圧縮を使用したパッチを適用したrestic、およびtarを使用した現在のバックアップソリューションを比較したときの私の調査結果は、 https ：//gist.github.com/joerg/b88bf1de0ce824894ffc38f597cfef5fにあります

| ツール| バックアップ時間（m：s）| 復元時間（m：s）| バックアップスペース（G）| バックアップスペース（％）| バックアップ（MB /秒）| 復元（MB /秒）|
| --------------------------- | ----------------- | ------------------ | ---------------- | ---------------- | ------------- | -------------- |
| タール| 4:42 | 5:19 | 11 | 9.6％| 404 | 357 |
| ResticS3ローカルアップストリーム| 10:04 | 30:56 | 102 | 89.5％| 189 | 61 |
| ResticS3ローカル圧縮| 5:43 | 19:28 | 8.6 | 7.5％| 332 | 98 |
| Restic Local Upstream | 8:33 | 26:06 | 102 | 89.5％| 222 | 73 |
| Restic Local Compress | 5:21 | 16:57 | 8.6 | 7.5％| 355 | 112 |
| ResticS3リモートアップストリーム| 17:12 | 46:06 | 102 | 89.5％| 110 | 41 |
| ResticS3リモート圧縮| 5:27 | 21:42 | 8.6 | 7.5％| 349 | 88 |

Resticは、ほとんどすべてを削減するため、任意の種類のオプションの圧縮で大幅に向上すると思います。

すべてのファイルに興味深い圧縮率があるわけではありません。 ビデオファイルを圧縮することはおそらく価値がありませんが、SQLダンプを圧縮することは間違いなく価値があります。 そのため、Btrfsのようなファイルシステムは最初にファイルの最初の128KBを圧縮しようとし、かなりの圧縮率がある場合はファイル全体を圧縮します。 完全ではありませんが、高速であり、ファイルを個別に圧縮することにした場合、ほとんどのユースケースで機能するはずです。

オプションとして圧縮を提供することに反対している人のために、私の使用例は、私が内容を制御できないほとんど圧縮可能なファイルタイプの混合物をバックアップすることであり、データを圧縮する必要があると期待するのは不合理ですバックアップ操作を実行する前に、複数のマシン（新しいアーカイブに圧縮する場合により多くのローカルディスクスペースを使用するか、関連するアプリケーションでファイルを使用できなくする）。

私はDRバックアップツールとしてresticを使用できることを望んでいますが、現在borgを使用しています（低速で大量のRAM要件など）。これにより、圧縮と重複排除により、バックアップ操作ごとに数ギガバイトのネットワーク転送が節約されます。バックアップセット全体にわたって、クラウド内の1テラバイトのストレージスペース（月ごとに支払います）を簡単に超えます。 Resticが圧縮をサポートしていれば、バックアップをより長く保持したり、ストレージコストを削減したりできます。

こんにちは@joerg 、あなたのテストを共有してくれてありがとう。
Tar圧縮タスクの出力をresticでバックアップしようとしましたか？
「ResticS3RemoteCompress」と「Tar」+「ResticS3RemoteUpstream」の比較に興味があります。
さらに、あなたの言うことは本当に真実ではないようです：

Resticは、ほとんどすべてを削減するため、任意の種類のオプションの圧縮で大幅に増加すると思います

テスト結果を見ると、resticに必要なCPU時間は、ローカルバックアップの場合は2倍、復元の場合は6倍長いようです。 Tarに比べてあまり良くありません。

tarは圧縮アルゴリズムではありません。 もちろん速いです。
編集：ああ、ところで。 ディレクトリをtarすると、ファイルごとに複数のスレッドが使用されず、一度に2つ以上のファイルでも機能しません。代わりに、ディレクトリをスキャンしてファイルを追加してから、次のファイルに移動します。 かなり遅い。 しかし、問題は、複数のスレッドで追加するように設計されていないアーカイブファイルです。

テスト結果を見ると、resticが使用するCPU時間は、ローカルバックアップでは2倍遅く、復元では6倍遅いようです。 Tarに比べてあまり良くありません。

ここでのあなたの主張は完全にはわかりません。 確かに、resticはTarよりも遅いですが、圧縮ありのresticは、圧縮なしのresticよりも常に高速であるため、resticには明らかにメリットがあります。

Tarは、「このハードウェアのベストケース」との比較に役立ちますが、resticの他の機能のほとんどが欠けています（スナップショットとデータ重複排除が思い浮かびます）。 圧縮を追加すると、バックアップ時間、復元時間、およびストレージコストだけが改善されるようです。これらはすべて、バックアップ製品にとって重要です。

@joerg友達がプルリクエストを開いて、圧縮を使用したresticのパッチを公開できますか？ 彼らはどの圧縮アルゴリズムを使用していますか？

@joerg @thedaveCA
申し訳あり@ joergの主張の意味を誤解しました。 明らかに、圧縮ありのレスティックは、圧縮なしのレスティックよりも優れています。 今私の質問は：タール+レスティックは、圧縮を伴うレスティックと比較して優れているか、そうでないか？

ベアtarアーカイブは使用していませんが、特別な並列zip実装を備えたgzip圧縮されたtarアーカイブを使用していることに注意してください。そうしないと、テラバイト単位のデータのアーカイブに、現在の「ちょうど」時間ではなく数日かかります：https：//gist.github。 com / joerg / b88bf1de0ce824894ffc38f597cfef5f＃tarpigz
@shibumi私はこの問題と私の投稿について彼らに知らせたので、彼らがこれに関与したいかどうか、そしてどこまで関与したいかは彼ら次第です。 個人的に、私は彼らがそのプルリクエストを開くことを願っています...

圧縮は暗号化には適していません。 攻撃者は、使用されている暗号化キーに関係なく、ファイルのセクション（チャンク）が同じサイズに圧縮されるため、暗号化されたリポジトリに特定のファイルが含まれているかどうかを推測できます。 これは暗号化プロトコルの非常によく知られた脆弱性であり、そのためTLS1.3から圧縮が削除されました。

既知の問題を作成しないでください。

（この問題はすでに言及されており、おそらく一度も発生しないと思います。それでもこの問題は未解決であり、この理由だけで完全に解決する必要があると思います。）

なぜ問題をスパムしているのですか？ :(何度も議論されているので、ほとんど話題から外れています。圧縮を有効にするように強制されることはありません!!

さらに、あなたの攻撃のアイデアでは、攻撃者がデータを圧縮および暗号化するように制御できる必要があると思います（ただし、よくわかりません！）。 https://en.m.wikipedia.org/wiki/CRIME

ただし、いずれの場合も、セキュリティ上の懸念がある場合でも、誰かが自分の管理下にあるストレージに対してのみ圧縮を使用して、単にストレージスペースを節約したい場合があります。

暗号化を弱めるオプション機能さえあると、誤った安心感を招きます。 Resticは、_安全な_バックアッププログラムであると主張しています。 オプションの圧縮を追加すると、常に安全であるとは限らず、フルタイムでしか保護できないため、この約束は無効になります。 そして確かに、CVEレポートがあります。 誰が自分のソフトウェアにこの種の「人気」を望んでいますか？

しかし、暗号化で使用されないように圧縮を追加することは、実行可能なオプションだと思います。

2017年にFWIWは、Resticから暗号化を取り除いたデモを作成し、圧縮が非常に効果的であることを

実際、CRIMEは暗号文の長さを知る必要がありますが、これは基本的に制限文では不可能です。
また、「安全な」バックアッププログラムはありません。 サードパーティがバックアップファイルにアクセスできる場合、誰かがデータを改ざんまたは悪化させる可能性が常にあります。
ですから、圧縮が悪化すると言うのはばかげています。

実際、CRIMEは暗号文の長さを知る必要があります

犯罪は必要ですが、あなたは必要ありません。 あなたが調査ジャーナリストであり、情報源から極秘ファイルのセットを与えられたと想像してみてください。 あなたは暗号化でそれらをバックアップします、そして誰もあなたがこれらのファイルを持っていることを知りません。

ここで、圧縮を有効にするほど賢くなかったと想像してください。圧縮されてから暗号化されたチャンクのサイズから判断すると、これらのファイルを持っている他のすべての人は、このアーカイブにこれらの最高機密ファイルがあることを知っています。暗号化キーを知る必要さえあります。 これは安全とは程遠いです。 人々はこの「特徴」のために刑務所に行くか、拷問されるか、さらに悪いことになります。

「安全な」バックアッププログラムはありません

次に、これを更新する必要があります。

また、デフォルトでセキュアであることに注意してください。

resticはパックされたチャンクのみを格納するため、チャンクのサイズは明らかではありません。
キーを持っていない人。

2019年8月9日金曜日02:09:23 AM -0700に、AlexeyKopytkoは次のように書いています。

圧縮は暗号化には適していません。 攻撃者は、使用されている暗号化キーに関係なく、ファイルのセクション（チャンク）が同じサイズに圧縮されるため、暗号化されたリポジトリに特定のファイルが含まれているかどうかを推測できます。 これは暗号化プロトコルの非常によく知られた脆弱性であるため、TLS1.3から圧縮が削除されました。

既知の問題を作成しないでください。

-
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/restic/restic/issues/21#issuecomment -519844526

-
（Escriu-me xifrat si saps PGP / PGPを知っている場合は暗号化された書き込み）
PGPキー7CBD1DA5- https： //emailselfdefense.fsf.org/

これらのセキュリティ上の懸念についてもっと知りたい人のために、それを説明する素晴らしい論文がありますhttp://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf
私の理解では、ファイルがチャンク化されてから圧縮および暗号化されると、欠陥が発生する可能性があります。 しかし、ファイルがチャンク化される前に圧縮されている場合、それは他のファイルと同様にバイナリファイルであり、それらのプレーンテキスト攻撃は役に立たなくなります。

しかし、ファイルがチャンク化される前に圧縮されている場合、それは他のファイルと同様にバイナリファイルであり、それらのプレーンテキスト攻撃は役に立たなくなります。

それは正しいです。 しかし、圧縮アルゴリズムはファイルのバージョンごとに異なる語彙を使用し、非常に異なるバイナリ結果をもたらす可能性があるため、正しく理解していれば、効率的な重複排除には正確には役立ちません。 これは明らかに重複排除されません。 そうでなければ、結果のチャンクを圧縮することだけが意味があります。

resticはパックされたチャンクのみを格納するため、チャンクのサイズはキーを持っていない人にはわかりません。

それは安心です。

私の言いたいことは、暗号化と一緒に圧縮を実装するときに、プログラムに隠れた弱点を追加する方法はたくさんあるので、まったく追加しないのが最善だということです。 TLSについて決定する暗号化_専門家_でさえ、圧縮を削除することを選択しました。 彼らは同様の理由を持っていたと思います。

ところで：

However, it is important to note that these attacks have little security impact on, say, a bulkencryption application which compresses data before encrypting

..。
あなたが暗号化されたファイルの複数の異なるバージョンを持っている場合も、犯罪にのみ動作します。
つまり、複数のバックアップを実行します（攻撃者がすべてを取得した異なるリポジトリへ）
そしてそれはまた、唯一の少量のデータで動作します。

犯罪は必要ですが、あなたは必要ありません。 あなたが調査ジャーナリストであり、情報源から極秘ファイルのセットを与えられたと想像してみてください。 あなたは暗号化でそれらをバックアップします、そして誰もあなたがこれらのファイルを持っていることを知りません。

ここで、圧縮を有効にするほど賢くなかったと想像してください。圧縮されてから暗号化されたチャンクのサイズから判断すると、これらのファイルを持っている他のすべての人は、このアーカイブにこれらの最高機密ファイルがあることを知っています。暗号化キーを知る必要さえあります。 これは安全とは程遠いです。 人々はこの「特徴」のために刑務所に行くか、拷問されるか、さらに悪いことになります。

それはでたらめです。 小さいサンプルサイズでのみ機能するためです。 圧縮せずに刑務所に行くことも可能です。 特にある時点で、攻撃者がバックアップファイルを入手したときに、将来的にそれらを攻撃できる可能性があります。
将来的に現れる他のセキュリティ問題などがあるかもしれません...
議論はただ無意味な恐怖に変わりました。

@sanmai 、私はこの例を取得しません

あなたが調査ジャーナリストだと想像してみてください...圧縮を有効にするほど賢くなかったと想像してみてください。圧縮されてから暗号化されたチャンクのサイズだけで判断すると、これらのファイルを持っている他のすべての人がそれを知っているでしょう。暗号化キーを知らなくても、このアーカイブにこれらのトップシークレットファイルがあります。

何を意味しています？ サイズを見ただけで、暗号化されたスナップショットにこれらのファイルがあると誰かがですか？ これは、ファイルが単独で、または他の既知のファイルと一緒に圧縮されていることを前提としています。 しかし、暗号化されていないシャップショットでも同じ推測を行うことができます。

実際、バックアップする前にファイルをgzipするのはどうですか？ これはセキュリティの脆弱性も開きますか？

この例はまったくナンセンスだと思います。スナップショットに既知の（任意の）ファイルの圧縮バージョンが含まれているかどうかを判断できると主張する場合は、圧縮されていないファイルが含まれているかどうかも判断できます。

圧縮によって暗号化の安全性が大幅に低下する可能性があるとは思いません。

ほとんどの圧縮サイドチャネル攻撃には、いくつかの要因が関係しています。
1）攻撃者は入力を制御できます
2）攻撃者は出力のサイズを観察できます
3）入力データにわずかな変更を加えると、出力サイズに測定可能な変更が加えられます。
4）攻撃者は入力を変更し、数十万回再試行できます

Webベースのシステムとは異なり、復元バックアップを含む大多数では、（1）と（2）が同時に保持されることはめったにありません。 さらに、ブロックベースの圧縮（3）は実際には保証されておらず、ほとんどのバックアップ体制（4）は確かに成り立ちません。 バックアップの頻度は通常1日1回程度であるため、データを操作して圧縮出力サイズを監視し、大きな違いに気付くまでに数千年かかります。これは、他のデータが変更されていないことを前提としています。ほとんどの場合、だろう。

出力サイズが表示されている場所でバックアップを作成している場合は、圧縮を無効にすることを検討してください。 そうでなければ、それに対する実際的な攻撃は実際にはなく、それを有効にすることで安全性が低下することはありません。

resticはすでに重複排除を行っており、とにかく圧縮サイドチャネルと同じ理論上の攻撃にさらされています。私の知る限り、これについて誰も文句を言っていません。

実際には、何百または何千ものユーザーが圧縮機能の恩恵を受け、マイナス面はまったくありません。 この5年前の問題を、それに取り組んでいる開発者に任せてもらえますか？

正直に言うと...私はresticの概念を好みます...しかし私は自分のユースケース（多くのCSVファイルとSQLダンプ）でテストを行い、borgに切り替えなければなりませんでした。

4世代の増分バックアップでテストしたところ、ファイルは7：1の圧縮率になり、重複排除と合わせて20：1以上を達成しました。 オンラインバックアップストレージの料金はGBごとに支払うとすでに言っているので、それを無視することはできません。

root<strong i="7">@xxxx</strong>:~# borg list
2019-08-08_14:37                     Thu, 2019-08-08 14:37:10 [5e113a8102f2bd7e40d100343f849dc73843d145011c7214d5fa0895927eb6d1]
2019-08-08_22:28                     Thu, 2019-08-08 22:28:21 [17d815d000212a576610b2fd5688ab87cce00039bb89f63722c6a7819dec1821]
2019-08-09_02:00                     Fri, 2019-08-09 02:00:23 [217c53b07f30dfbca584c49468cfa624a2445a005890220509c97715f7007e81]
2019-08-10_02:00                     Sat, 2019-08-10 02:00:10 [5dd45b8ccf0aa382bf00d5b08e1d5d88daae014f0a1a42b3e2b0fc368623bba0]
root<strong i="8">@xxxx</strong>:~# borg info
Repository ID: xxxx
Location: ssh://xxxx
Encrypted: Yes (repokey)
Cache: /var/lib/borg/cache/xxxx
Security dir: /var/lib/borg/security/xxxx
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:               69.02 GB             11.24 GB              2.80 GB

                       Unique chunks         Total chunks
Chunk index:                    9227                41812

何を意味しています？ サイズを見るだけで、暗号化されたスナップショットにこれらのファイルがあることを誰かが_推測_できますか？ これは、ファイルが単独で、または他の既知のファイルと一緒に圧縮されていることを前提としています。 しかし、暗号化されていないシャップショットでも同じ推測を行うことができます。

丁度。 プレーンテキストファイルを均等にスライスし、圧縮してから暗号化します。 もう一度スライスし、圧縮して暗号化します。 暗号化されたファイルのサイズはAESごとに変化しないため、どちらの場合も、指紋のように互いに一致する範囲サイズがあることがわかります。 彼ら（そして私は主にイランやロシアのような抑圧的な政権の政権を意味します）は、これらのファイルがここに存在するという合理的な仮定を立てることができます。 なぜこれらのアイデアに腹を立てるのか理解できませんが、理解するのは簡単ではありませんか？ これはそれ自体が犯罪ではありませんか？

ただし、@ viricが前述したように、暗号化キーがないとチャンクのサイズが表示されないため、技術的にはResticはこれらの脆弱性の影響を受けません。 ただし、ある時点で圧縮が追加された場合、Resticは現在は影響を受けない可能性がありますが、後で影響を受ける可能性があります。

圧縮を追加すると、重複排除がすでに実行されている場合、Resticは追加の脆弱性にさらされますか？

攻撃者が圧縮されたブロックサイズを推測して非圧縮サイズを推測することが懸念される場合は、わかりましたが、圧縮によってこれが悪化しますか？ 攻撃者は同じ基本情報を持っていませんか？

攻撃者が各ファイルの圧縮されていないサイズと圧縮されたサイズを見ることができれば、識別はより現実的になる可能性がありますが、これはresticでは不可能です。

最終的に、重複排除は、圧縮が影響を与えると思われるすべての理論上の攻撃にすでにさらされています。さらに、状況に適している場合は、もちろん圧縮を無効にして現在の状況を維持することもできます。

暗号化されたチャンクのサイズを見てファイルの存在を推測することに関する仮想的なセキュリティの懸念について話し合う理由がわかりません。.、、

あなたたちはZIPまたはGZを使用しますか？ その後、あなたは大丈夫なはずです。

イラン当局は私のコンテンツをサイズで推測できると思いますか？ 次に、圧縮（！）を使用しないでください。 それは単に圧縮が利用可能であるべきではないという意味ではありません。

Resticに圧縮を追加するためのすべての関連する角度をカバーしたと思います。すべての入力に感謝します。

圧縮を追加してデフォルトで有効にする必要があると思いますが、ユーザーは圧縮を無効にできます。 作業する時間がもう少しあるまで、しばらくお待ちください。

この議論は手に負えないように感じるので、私は今のところこの問題をロックしています。 このディスカッションを続けたい場合は、フォーラムにアクセスし