Restic: 暗号化されていないバックアップ

この機能のリクエストを何度か聞いたことがありますが、問題があることを念頭に置いていました。 見つからないようですので、この機能リクエストはここで追跡されます。 短いバージョンは次のとおりです。ある時点で暗号化を無効にするオプションを追加する可能性がありますが、現時点ではロードマップに含まれていません。

長いバージョンは次のとおりです。

• 暗号化はもはや高価ではありません。少なくとも、AES-NI（ハードウェアアクセラレーション暗号化）を使用している場合はそうではありません。これは、今日では非常に一般的です（少なくともラップトップとサーバーでは）
• resticは、暗号化だけでなく、データの信頼性と署名にも関心があります。 暗号化せずにこれを実装する方法を見つける必要があるので、とにかくキー/パスワードを保持する必要があります。
• 暗号化されていないバックアップを許可するコードパスを取得すると、攻撃者がクライアントをだまして、暗号化せずに（元々）暗号化されたリポジトリにデータを保存させる方法を見つける可能性があります。 これは以前に他のバックアッププログラムで発生したため、非常に注意する必要があります。これには、現時点では時間とリソースがありません。

見つけたらさらにポイントを追加する場合があります。

暗号化されていないバックアップが（ローカルで）必要なもう1つの理由は、中央リポジトリを複数のユーザーで共有できるようにするためです。つまり、ホームサーバーでは、HTTPS経由でバックアップを送信したいのですが、それらすべてを共通のリポジトリに重複排除させます。個々のユーザーに対して論理的に分離されているものとして提示されている場合でも。

攻撃者がクライアントをだまして、暗号化せずに（元々）暗号化されたリポジトリにデータを保存させる方法を見つける可能性があります。

うーん、リポジトリは暗号化されているかどうかという考えだったので、暗号化されていないデータを暗号化されたリポジトリに保存することはできません...そして暗号化されたリポジトリが何らかの形で同じものの暗号化されていないリポジトリに置き換えられた場合名前と場所、ユーザーはパスワードが要求されていないことに気付くはずです。 たぶん、リポジトリが暗号化されていないという、太字の赤い点滅テキストの警告が印刷される可能性があります:)。

@wrouesnelホスト名で区別して、すでにそれを行うことができます！ （先日同じことを考えていました）:)

@alexeymuranovユーザーが入力したパスワードが、暗号化されたディレクトリの暗号化パスワードなのか、暗号化されていないディレクトリの信頼性を検証するためのMACパスワードなのかをどのように判断しますか？ もっと--switches ？ それは非常に速く非常に乱雑になります。

ローカルバックアップを作成するためにこのオプションが欲しいのですが。 たとえば、サーバーで〜/ Musicディレクトリのバックアップを毎日実行していますが、暗号化する必要はありません。 バックアップは、ハードウェアの障害や損失から保護するためのものではなく（他にもバックアップがあります）、単に事故やビット腐敗から保護するためのものです。 また、サーバーはかなり低電力であるため、暗号化のオーバーヘッドが問題になります。

そのためのrsyncです。
編集：そしてファイルのパーミッション/属性。 ところで、「ハードウェア障害」と「ビットロット」の違いは何ですか？

@cfcs 、 rsyncは重複排除しません。

そのためにrsyncがあります。

@cfcsご存知のように、ミラーはバックアップではありません。 ;）Obnamを使用して、resticと同様の一連のバックアップを保持します。 keep = 7d,8w,12m,3y GPGキーをほとんど紛失して以来（気付かずに不思議なことに0バイトに切り捨てられ、切り捨てられたファイルがバックアップされたため）繰り返し）、そしてCD-Rの何年も前のバックアップからそれを掘り起こさなければならなかったので、古いバックアップデータを保持することの重要性を認識しています。

ところで、「ハードウェア障害」と「ビットロット」の違いは何ですか？

Bitrotは通常、腐ったデータが必要になるまで検出されず、デバイス全体が読み取れなくなることはありません。 ハードウェア障害とは、たとえば、ディスクが完全に故障している、システムが起動できないなどです。

また、Alexeyが指摘しているように、rsyncは重複排除も、古いバックアップデータのプルーニングも、データ整合性チェックなども提供しません。rsyncは優れたツールであり、私は定期的に使用していますが、バックアップは作成していません。

暗号化はもはや高価ではありません。少なくとも、AES-NI（ハードウェアアクセラレーション暗号化）を使用している場合はそうではありません。これは、今日では非常に一般的です（少なくともラップトップとサーバーでは）

あなたのソフトウェアがgoで書かれていない限り。 Goのcryproは、Intel以外のすべてのソフトウェアのみです。したがって、armデバイスを使用すると、NAS上の公式のopensslベースのバックアップソリューションで30分未満で完了する同じファイルセットの「推定バックアップ時間-14日」で立ち往生します。 。

この機能も見たいです。 転送にSSHを使用しており、バックアップをLUKS / cryptsetup暗号化ボリュームに保存しているため、暗号化によって暗号化キーを失うリスクが追加されます。 また、暗号化によりエラーが発生しやすくなり、CPUに不要な負荷がかかります。

それでも、信頼できないターゲットにバックアップする場合は、暗号化が非常に役立ちます。

人々は、バックアップと一緒にパスワードを含むテキストファイルを安全にするように動機付けられるかもしれません...

また、luks / dm-crypt暗号化バックアップターゲットを使用します。 / Backup /にマウントする外付けUSBディスク
その場所（/ Backup / restic_password）にパスワードファイルを作成し、-password-fileを使用してそれをresticにフィードすることができます。 リポジトリは/ Backup / restic_repo /の下にあります
パスワードファイルを不変にすることが重要です。そうしないと、誤って紛失した場合に失敗します：chattr + i / Backup / restic_password
また、念のため、パスワードとして「restic」を使用しています。

Resticの暗号化機能は、クラウドプロバイダーなどの信頼できないターゲットにバックアップする場合に非常に便利です。 しかし、自宅に保管している外付けドライブや地下室にあるNASを使用するだけの場合、強制暗号化はちょっと気が狂います。 平均的なユーザーはとにかくパスワードを忘れます。

暗号化されていないバックアップを許可すると、ZFS、BtrFS、NTFS、またはその他のファイルシステムでバックアップを圧縮できます。

（必要に応じて、下位層のdmcryptを介して暗号化を行うことができます）

暗号化されていないバックアップを許可すると、ZFS、BtrFS、NTFS、またはその他のファイルシステムでバックアップを圧縮できます。

ここでも同じですが、圧縮がなく、必須の暗号化がバックアップサーバーのスペースを大量に消費します。 私の使用例（一部の画像、多くの小さなxml / txt / csvファイル）は、暗号化なし（ZFSがその処理を実行できるようにするため）または圧縮（zstd、5で約2.3の圧縮率）のいずれかから大きな利益を得るでしょう。

ZFSを使用している場合は、 zfs sendスナップショットを使用しないのはなぜですか？

多くの場合、ZFSスナップショットはバックアップには不十分です。 ファイルに検出されない破損がある場合、または何年にもわたるセーブセットが必要な場合、ZFSスナップショットはそれほど役に立ちません。 たとえば、FreeNASを使用していて、1年間の毎週のバックアップを維持したいとします。 FreeNASに組み込まれているスケジューリングとスナップショット管理は、それを正しく実行するのに_本当に_十分ではありません。 それは「企業」ではありません。

あなたがより精巧なスケジューリングシステムを持っているなら、それはおそらくもっとうまくいくでしょう。 zfs sendには、出荷する前にスナップショットが存在する必要があるという問題もあります。 また、スナップショットスケジュールを管理し、スナップショットと送信スケジュールが（手動で）同期されていることを確認して、RTO / RPOに到達するようにする必要があります。

そしてええ..私はFreeNASのエンタープライズ機能について話している。 しかし、それが懸念事項です...

少なくともAES-NIを使用している場合は、暗号化はもはや高価ではありません

AES-NI要件は、多くの古いサーバーを除外します（場合によっては、バックアップすることが_特に重要_です！）。

私は、アフリカの田舎にあるサーバーのコレクションで、10年以上前に寄付されたハードウェア（一部はまだ32ビットです！）で実行されるより良いバックアップを誰かが取得できるように支援しています。 暗号化によってオーバーヘッドが大きくなりすぎるのではないかと心配しているので、今のところ他の場所を探す必要があると思います。

暗号化なしの場合は+1

これは便利でしょう

暗号化なしの場合は+1

これは便利でしょう

ウォッチャーの受信トレイがいっぱいになるのを防ぐために、「+ 1」の代わりに元の問題で「いいね」機能を使用してください。 ありがとう！

この機能のステータスはどうなっていますか？

会社のすべてのユーザーがアクセスできる内部Sambaサーバーからファイル（ユーザーマニュアルの翻訳などの共有ドキュメント）をバックアップする必要があります。これらのファイルは、会社の範囲内では実際には機密ではありません。 この場合のバックアップ暗号化は無意味です。とにかくバックアップのセキュリティを強化するためにjailkitを使用しており、圧縮が有効になっているbtrfsファイルシステムを使用しています。 とにかく、VMディスクダンプのようなものを他の方法でバックアップします。 私のユースケースでは暗号化は問題ではありません。データの損失を防ぐことが唯一の優先事項です。 'restic'のようなパスワードを使用することは、一種のばかげた回避策です。

これを実装してください。

@mrkafk暗号化されたresticの実際の問題は何ですか？ CPUがハードウェア暗号化をサポートしている可能性が高いため、必要がない場合でも、問題になるには非常に具体的な理由が必要になります。

私は実際の問題について説明しました。特定のコンテキストを考えると、それは必要ありませんが、少なくとも理解しているように、btrfsファイルシステムでの圧縮ゲインがなくなります。 バックアップするファイルがたくさんあるので、そもそも圧縮が有効になっているbtrfsを使用しています。これは、ハードウェアの冗長性のためにRAID-1を使用する場合、大量のディスクスペースが必要になるためです（そのためではない場合は、むしろ使用したいと思います）。 ext4）。 また、偽のパスワードに相当する暗号化と暗号化を不必要に行うことは...ばかげていると感じます。

さて、あなたが書いたものから、私は1つの実際の問題を収集します。つまり、BTRFS圧縮は、暗号化なしの場合ほど効果的ではありません。 それは良い点です。 それ以外に、resticの暗号化のためにあなたを制限するものは何も見当たりません。

暗号化されていない場合、暗号化キーを失うことは不可能です。これは特にバックアップに関連します。

Mebus

暗号化されていない場合、暗号化キーを失うことは不可能です。 これは特にバックアップに関連します。

それは、世界が明日すでに終わるように議論されています:) https://github.com/restic/restic/issues/1786