コミュニティソリューション

ZimaOSのバックアップで削除したファイルが残る理由:バックアップと同期の違い

Users debated why built-in Backup retained files deleted from the source; IceWhale explained that deletion mirroring behaves more like sync than backup.

ZimaOS Backupは意図的にミラーではありません。ソースからファイルを削除しても、バックアップのコピーがすぐに消えるわけではありません。組み込みのBackupアプリは復旧ポイントを保持し、誤削除から保護するように設計されています。一方、同期ソフトウェアは削除を含む変更を反映するように設計されています。

この違いが、2025年のフォーラム議論の核心でした。IceWhaleは、ソースからファイルが消えた時点でバックアップ先からも削除することに明確に反対しました。ソースから消えた直後にバックアップ先のファイルまで削除すると、バックアップの安全性が低下するためです。現在の2026年版ZimaOSドキュメントにも、同じ原則が明記されています。クラウド同期は削除をミラーリングしますが、バックアップはバージョンと復元ポイントを保持します。

削除したソースファイルがバックアップに残る理由

バックアップは、ミス、破損、ランサムウェア、望ましくない変更から復旧するために存在します。ソースファイルを削除するとすべてのバックアップコピーまで即座に削除されるなら、誤削除が、まさに救済を目的とした場所にまで反映されてしまいます。

現在のZimaOS 3-2-1 Backupガイドにも、バックアップはバージョンを保持し、クラウドミラーのように動作するのではなく、前方に書き込んでいくと明記されています。

バックアップ、片方向同期、双方向同期は別物

モード ソースファイルを削除するとどうなるか 最適な用途
バックアップ 復旧用に古いコピーやバージョンが残る場合がある データの損失やミスからの保護
片方向ミラー/同期 削除が保存先に反映される場合がある 正確なセカンダリ作業コピーの維持
双方向同期 通常、削除が両方向に反映される 複数のデバイス間で作業フォルダーを同期

2025年に保存先からの削除を求めたユーザーは、実際にはミラー/同期ポリシーを求めていましたが、そのタスクはBackupで作成されていました。

増え続けるバックアップが本当に問題になる理由

ユーザーの懸念はもっともです。削除したすべてのファイルを永久に保持すると、保存先の容量は際限なく増加する可能性があります。そのため、成熟したバックアップシステムには、削除を単純にミラーリングするのではなく、保持するバージョン数、期間による期限切れ、ストレージ容量の上限などの保持制御が必要です。

現在のZimaOS Backupを設定する際は、使用する保存先について、タスクの保持設定と復元動作を確認してください。必要な保持ポリシーがUIに表示されない場合は、保存先に余裕を持たせ、容量の増加を監視してください。

完全なミラーが必要なら同期を使う

「保存先をソースと完全に同じ状態にしたい」場合は、ファイルの作成、変更、名前変更、削除を反映するように設計された同期ツールを使用してください。Syncthing、rsyncベースのワークフロー、その他の専用同期ツールのほうが、バックアップタスクより適している場合があります。

ミラーのワークフローを「バックアップ」と呼び、削除から保護してくれると思い込まないでください。ミラーは、復旧したいと考えていたミスまで忠実に再現してしまう可能性があります。

仕事のデータ、写真、かけがえのない書類にはバックアップを使う

仕事のファイル、家族写真、税務記録、クリエイティブプロジェクト、アプリケーションデータについては、最後に復旧可能なコピーまですぐには削除しない保存先を少なくとも1つ用意してください。

バックアップ戦略の概要では、高速コピーと本当の復旧用コピーを分けて考える方法を説明しています。

1つのモードに両方を強制せず、バックアップと同期を組み合わせる

堅牢なホームサーバー構成では、次のように運用できます。

  • 作業中のフォルダー用の同期ジョブ
  • バージョンと復元ポイント用の定期バックアップ
  • 災害復旧用のオフサイトバックアップ

これにより、ファイルを同期する利便性を保ちながら、過去の状態への復旧機能を犠牲にせずに済みます。

バックアップポリシーをテストする方法

小さなテストファイルを作成し、バックアップを実行します。次にそのファイルを編集して再度バックアップを実行し、その後ソースから削除します。復元インターフェースを開き、古いコピーが引き続き利用できるか確認してください。これにより、本番データを任せる前に、現在のバージョンが実際にどのように動作するかを把握できます。

自動クリーンアップが必要な場合

保存先のファイルを手動で削除するのではなく、保持設定やバージョンの削除設定を探してください。手動でクリーンアップすると、復元履歴が壊れたり、唯一の正常なコピーを削除したりする可能性があります。

バックアップ先の空き容量が不足している場合は、容量を追加するか、対応していれば保持期間を短くするか、古いアーカイブを別のストレージ階層に移してください。唯一のバックアップを同期ミラーに変えるのは避けてください。

よくある質問

削除したソースファイルがZimaOS Backupに残るのはなぜですか?

バックアップは復旧ポイントを保持するためのものだからです。現在のZimaOSドキュメントでも、バックアップと削除をミラーリングする同期は明確に区別されています。

これはZimaOS 1.5のバグですか?

フォーラムでの議論から、この動作はバックアップの安全性を考慮して意図的に実装されたものであり、原因不明の単純な削除バグではないことが分かります。

保存先をソースと完全に同じ状態にするにはどうすればよいですか?

保持を目的としたバックアップタスクに頼るのではなく、片方向ミラーまたは同期ワークフローを使用してください。

保持した削除済みファイルでバックアップディスクがいっぱいになりませんか?

保持期間が無制限なら、その可能性があります。唯一の復旧履歴を削除するのではなく、バージョン数、保持期間、容量制限、アーカイブ階層を管理してください。