解決策 1:
単純なバックアップ (単一のコピー、すべてのデータの上書き) を行っている場合、目的を達成する方法はありません。攻撃者は常に空のファイル (または空のファイル セット) の山を「バックアップ」でき、結果としてすべてのデータはさようなら。したがって、ここでは、適切なアーカイブ バックアップを行っており、バックアップを十分に監視しており、空のバックアップ セットを送信してバックアップを根絶しようとする試みが、永続的な損傷が発生する前に検出されると想定しています。
rsync-over-(おそらく)-SSH が強制コマンドを使用して rsync を実行する場合 宛先で、削除からできるだけ安全になります。特定の rsync のみを実行したいので コマンドを使用すると、すべての引数をハードコーディングでき、新しいデータを書き込むことしかできなくなります。毎回新しいツリーにバックアップし、変更されていないファイルをハードリンクを使用して以前のバックアップに関連付けることで、アーカイブは簡単です。これにより、スペースと転送時間が節約されます。
もう 1 つの方法は、バックアップ サーバーが rsync を開始して管理するプル バックアップを使用することです。 操作 -- これは、クライアント マシンが制限された rsync コマンドを実行する機能さえ持っていないことを意味します。つまり、攻撃者はファイルを削除する権限を持っていません。
これはすべて、バックアップ サーバーが安全であることを前提としています。攻撃者が別の手段でアクセスできる場合、何をしても骨が折れます。
解決策 2:
最も簡単なことは、おそらくバックアップを逆にすることです。バックアップ サーバーからプルします。それが、rdiff-backup でバックアップを実行する方法です。
解決策 3:
これは、Tarsnap バックアップ サービスで気に入っている機能の 1 つです。読み取り、書き込み、および/または削除機能を持つサブキーを作成できます。
私のサーバーでは、通常、読み取りと書き込みの機能を持つサブキーを保持しています。古いバックアップ アーカイブを削除する必要がある場合や削除したい場合は、ローカルのデスクトップ コンピューターのマスター キーを使用して削除します。
Tarsnap 自体がストレージ サービスであることに注意してください。 Tarsnap ソフトウェアを使用して、独自のストレージ サーバーに対してバックアップを作成することはできません。
解決策 4:
実際の宛先をマスクする書き込み専用ファイルシステム レイヤーの使用を試みてください。
ここで、FUSE を使用した例を見つけました。
誰でも書き込むことができる暗号化されたファイルシステムを使用することもできますが、キー証明書を変更する必要があります (実装中におそらくより多くの計画が必要ですが、最も安全なオプションのようです)。 enCrypted FileSystem) と TrueCrypt
したがって、最初の解決策ではファイルシステムを「マスク」しますが、これは実際にはマシン内の別の場所に保存され、アクセス許可を持つシステム ユーザーに変更できますが、2 番目の解決策では、適切なキーでのみ変更できます。
解決策 5:
ftp:たとえば、vsftp には削除を無効にするオプションがあり、アップロードのみが可能です。次に、反対側で、x 日より古いバックアップを削除するスクリプトを作成します。私はこのオプションを使用します。メイン サーバーのバックアップは、tar + gz を使用した単純なバックアップであり、sftp 経由で NAS サーバーにアップロードされ、NAS サーバーが削除します。 7 日以上前のバックアップ。
rsync:rsync サーバーには削除を無効にするオプションがあるため、それも機能する可能性がありますが、rsync protocol/server.refuse options =delete を使用する必要があります
ただし、「削除」ファイルを時々手動で削除する必要があります。