なぜRsyncのミラーコピーは誤って削除したファイルもバックアップに反映してしまうのですか？

rsyncミラーはミラーが現在のソースに宛先を合わせる設計のため、誤って削除されたファイルもコピーします。ジョブが使用するとき --delete または関連する削除オプションでは、ホームNASに存在しないファイルはバックアップ宛先の余分なファイルとみなされ、同期中に削除されます。この動作はミラーとしては正しいですが、唯一の復旧履歴としては安全ではありません。

rsyncは過去のすべてのバージョンを保持するのではなく、ミラールールに従っています

削除オプションなしでは、rsyncは通常新規および変更ファイルをコピーしますが、宛先のみのファイルはそのまま残します。--deleteを使うと宛先はソースに合わせて調整されます。このフラグの簡潔な説明はソースからファイルを削除すると宛先からも削除されるため、宛先が真のミラーとして保たれるというものです。

ZimaSpaceホームNASの場合、これは削除された家族写真、名前変更されたメディアフォルダ、削除されたコンテナ設定、一時的にマウントされていない状態が次回のスケジュール実行時にUSBやリモートミラーに反映されることを意味します。

削除はソースパスの欠如から始まります

rsyncはファイルが意図的に削除されたのか、アプリがクリーンアップしたのか、ユーザーのミスか、ランサムウェアによる変更か、ソースデータセットのマウント失敗かを知りません。表示されているソースツリーと宛先ツリーを比較します。オブジェクトが受信側にのみ存在し、削除が有効なら削除候補になります。

削除タイミングはファイルが削除されるかどうかを変えるのではなく、削除される時期を変えます。

関連オプションは転送のフェーズを制御します。 --delete-before コピー前に宛先のみのファイルを削除します、 --delete-during ディレクトリ処理中に削除を行い、 --delete-after 転送が完了するまで待機します。これらは空き容量の挙動や障害の露出に影響しますが、ミラーをバージョン管理されたバックアップに変えるわけではありません。

タイミングを意図的に使い分けてください。転送前に削除すると容量は空きますが、以前のミラー状態が早く失われます。転送後に削除すると古い宛先の内容が長く保持されますが、ジョブが完了すれば最終結果はソースと一致します。

マウントの欠如は大量削除のように見えることがある

最も危険なホームサーバーのケースの一つは、実際のストレージプールがマウントに失敗した後にスケジュールされたソースパスが空のディレクトリとして存在し続ける場合です。rsyncは空のソースとデータがある宛先を比較してしまいます。提案されている安全策は、実際の同期を許可する前にdry-runでチェックし、計画された削除数を数えることです。

ホームNASでは、期待されるソースのマウント、ファイルシステムUUID、マーカーディレクトリ、最小ファイル数が欠けている場合はジョブを失敗させてください。空のパスの存在を健全なソースとみなさないでください。

削除されたファイルの復旧を試みる前にジョブを一時停止する

1. スケジュールされたrsyncタスクを直ちに無効にしてください。
2. 「直るかどうか試す」ためにコマンドを再実行しないでください。
3. スナップショット、ゴミ箱、バージョン管理されたバックアップリポジトリ、2番目のオフラインコピーを確認してください。
4. ミラーにまだファイルが残っている場合は、次回実行前にrsyncの宛先外の検疫パスにコピーしてください。
5. ライブ共有に復元する前に、ソースの削除が意図的かどうかを確認してください。

家族写真を複数の独立コピーで保管するに関するZimaSpaceの記事はここで重要です：同期されたミラーは一つのレイヤーであり、古いファイルが生き残る唯一の場所ではあってはなりません。

正確な削除セットをプレビューする

同じコマンドを--dry-run、詳細な変更項目表示、削除報告付きで実行します。ソースと宛先のパス、末尾のスラッシュ、除外設定、マウント状態、計画された削除数を確認してください。最近のrsync安全性に関する記事では、ミラーは誤削除やランサムウェア被害を再現する可能性があり、別の履歴レイヤーが必要だと強調しています。

rsync -a --delete --dry-run --itemize-changes   /srv/storage/family/ /mnt/usb-mirror/family/

予想外に多い削除数は事前チェックの失敗とみなし、停止して意図したNASデータセットがマウントされているか、コマンドが親ディレクトリや誤ったリムーバブルディスクを対象にしていないかを確認してください。

削除された宛先ファイルをリカバリーエリアに移動する

ミラーが必要で短期間の復旧ウィンドウも欲しい場合は、削除とバックアップディレクトリやスナップショット層を組み合わせてください。Rsyncは置き換えられたまたは削除された宛先ファイルを即座に破棄する代わりに、日付付きの復旧ディレクトリに移動できます。削除されたrsyncデータを保持するコミュニティの指針は削除ファイルを独自のクリーンアップポリシーを持つ別の場所に保持することを推奨しています。

rsync -a --delete   --backup   --backup-dir="/mnt/usb-mirror/deleted/$(date +%F)"   /srv/storage/family/ /mnt/usb-mirror/current/

まずは重要でないデータでコマンドをテストしてください。復旧ディレクトリはミラーされたサブツリーの外に置く必要があります。そうしないと、将来の実行でソースの一部とみなされたり、同じポリシーで削除されたりする可能性があります。

過去の状態が重要な場合はバージョンスナップショットを使いましょう

現在のミラーは「今のソースはどうなっているか？」に答えます。バックアップは「ミスの前のソースはどうだったか？」に答えます。両方が必要なら、ミラーは高速アクセス用に保持し、ファイルシステムスナップショット、ハードリンクスナップショットディレクトリ、バージョン管理バックアップツール、または2台目のオフラインディスクを追加してください。

誤ってrsyncで削除した事例は根本的な弱点を明確に示しています：手作りのrsyncワークフローには明示的なローテーションと削除防止策が必要です。1つの可変な宛先に正確な同期と長期履歴の両方を期待しないでください。

よくある質問

もし削除したら --delete、ミラーはバックアップになりますか？

単独では安全ではありません。宛先にのみ存在するファイルは残りますが、上書きされたファイルは以前の内容を失う可能性があり、特定の日付のクリーンな復元ポイントはありません。スナップショットやバージョン管理されたバックアップリポジトリを追加してください。

どの削除タイミングオプションが最も安全ですか？

--delete-after 転送が完了するまで削除を遅延させることで、実行中は古い宛先の状態を長く保持します。ただし、完了時には宛先にのみ存在するファイルを削除するため、事前チェックとバージョン履歴は依然として必要です。

予期しない大量削除を止めるにはどうすればいいですか？

スケジュールを無効にし、削除出力付きのドライランを実行し、ソースのマウントとパスを確認し、削除数の閾値またはマーカーファイルのチェックを設定してください。提案された削除リストを理解するまでは、ライブコマンドを再実行しないでください。

最終的なポイント

Rsyncは削除オプションによってバックアップ先を見えるNASのソースと一致させるため、誤って削除がミラーリングされます。ZimaSpaceホームサーバーワークフローを保護するには、マウントの確認、削除のプレビュー、削除されたファイルの隔離、バージョン管理またはオフラインの復旧ポイントの保持を行いましょう。ミラーは便利ですが、履歴のない完全なミラーだけでは人為的ミスから十分に保護できません。