私は、リモート ロケーション (「バックアップ ホスト」と呼びます) へのバックアップを作成するために、保守しているほぼすべてのホストで duplicity を使用しています。
完全バックアップまたは増分バックアップを実行する頻度とタイミングは、ホストとその使用事例によって異なります。
私は、一般的な障害 (人為的エラー、ハードウェア/ソフトウェアなど) から自分自身を保護しようとしているだけでなく、潜在的な攻撃から回復することも試みています。
私の場合、このような duplicity バックアップを実行するために SSH/SFTP バックエンドを使用しています。duplicity はバックアップ ホストへの読み取り/書き込みアクセスを必要とするため、バックアップ対象のホストの制御権を取得した人は、バックアップ ホストに接続して、それぞれのバックアップを削除したり、変更したりすることもできます。
それにもかかわらず、私の理解によれば、バックアップ対象のホストもバックアップ ホスト上のファイルを削除する必要があるようです。つまり、スペースが不足しないように、バックアップ対象のホストは、古いバックアップを削除するために、remove-all-but-n-full- および-actions を使用して duplicity を頻繁に呼び出します。remove-all-inc-of-but-n-full
私が聞いた限りでは、このようなクリーンアップは、バックアップ ホスト自体では実行できません。これは、どのファイルがどのセットに属しているかに関する duplicity のメタデータを含むバックアップが暗号化されているのに対し、それぞれの秘密キー (GPG) がバックアップ ホスト上に存在しないためです。
したがって、バックアップ ホストでこのようなクリーンアップを実行するには、ファイルのタイムスタンプに基づいて実行する必要があり、その結果、バックアップ セットが破損したり、部分的になったりする可能性もあります。
現在、このような攻撃から自分自身を「保護」するために、プライマリ バックアップ ホストに定期的に接続し、プライマリからセカンダリ バックアップ ホストにすべてのバックアップ データを rsync する 2 番目のバックアップ ホストを用意しています。
しかし、ここでも私はすでに上で述べた問題に直面しています:
- ファイルのファイル構造をまったく理解せずに、プライマリ ホストから 2 番目のバックアップ ホストにファイルをコピーするだけです (つまり、まだ完了していないファイルや部分的なセットなどをコピーします)。
- スペースが不足しないようにするには、ファイルのタイムスタンプのみに基づいて古いバックアップを再度削除する必要があり、その結果、バックアップ セットが使用できなくなる可能性があります。
バックアップ対象のホストを、Duplicity を介して自動的にバックアップし、同時に、バックアップ対象のホストへの完全なアクセス権を取得した攻撃者が、既に作成されたバックアップを操作できないようにするための最もエレガントでクリーンな方法は何ですか?
どうもありがとう！