状態データベースを復元すると、クラウド同期ジョブが以前に削除したファイルを再アップロードするのはなぜですか？

削除を意図した操作と新たに検出されたローカルデータを区別する削除記録が復元された同期データベースに含まれていない場合、復元した同期データベースによって削除済みファイルが再アップロードされることがあります。

双方向同期が依存するのは、現在表示されているファイルだけではありません。以前のパス、バージョン、デバイスID、削除トゥームストーン、同期状態のインデックスまたはデータベースも保持しています。新しいローカルファイルやクラウドの状態を残したまま古いデータベースを復元すると、時系列の不一致が発生します。その結果、クライアントが残存するローカルコピーを新規ファイルとしてスキャンしたり、リモート側の削除を競合として解釈したりする可能性があります。どの時点の状態を正とするかを決める前に、すべての同期参加先を一時停止してください。

復元されたデータベースとファイルツリーを確認する

データベースのバックアップ日時、ローカルファイルツリーの日時、クラウドの状態、クライアント設定、デバイスID、最初に再アップロードが発生した時点を記録します。データベースとファイルが同じ復旧ポイントから取得されたものか確認してください。

Nextcloudの復元手順では、データベースとデータディレクトリを一貫したシステムとして復元することが求められます。一方の層だけを復元すると、保存されているファイルと一致しないメタデータが作成されるためです。

データベースが削除より前のもので、ローカルツリーに古い残存コピーがある場合、再アップロードは予測可能な動作です。別の自動同期を許可する前に、3つすべての状態を保持してください。

削除トゥームストーンがロールバックされたか確認する

復元された状態に、削除イベント、ファイルバージョン、リモート項目ID、元の削除を実行したデバイスが含まれているか確認します。削除直前と直後のログを比較してください。

Syncthingはローカルのインデックスデータベースを保持しており、データベースをリセットすると完全な再スキャンと再同期が強制されると警告しています。古いマウント済みファイルツリーが後から現れると、バージョンの不整合が発生する可能性があります。

新しいデータベースにしか存在しなかった削除情報は、ロールバック後には失われます。次回のスキャンでは残っているファイルが検出されますが、そのファイルを削除済みのままにすべきだと示す履歴情報がありません。

状態を保持するBisyncまたは双方向同期のリストファイルを確認する

Rclone Bisyncなどのツールでは、以前の2つのリスト、作業ディレクトリ、ロック状態、最後に成功した実行結果を確認します。新規の再同期を、正常な状態からの継続と同じものとして扱わないでください。

Rcloneのドキュメントでは、Bisyncは連続する実行間で状態を保持すること、また同期フォルダーとは別に作業データを保存することが説明されています。

これらのリストを復元または削除すると、「前回の実行以降に削除された」状態と「片側にしか存在しない」状態の区別が失われる可能性があります。ドライランを実行し、状態を再構築する前に両方のリストを保存してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

データベース復元後にサーバーのフィンガープリントを更新する

サーバープラットフォームに、データベースが復元されたことをクライアントへ通知する復旧マーカーが用意されているか確認します。クライアントを再接続する前に適用してください。

ownCloudでは、サーバーバックアップの復元後にmaintenance:data-fingerprintを実行するよう管理者に指示しています。これにより、デスクトップおよびモバイルクライアントが復元されたサーバー状態を認識できるようになります。

復旧フィンガープリントを変更しないと、クライアントは後のデータベースを前提に作られた状態から処理を続ける可能性があります。その結果、競合、再アップロード、またはサーバー上で復元されたオブジェクトを削除しようとする動作が発生することがあります。

クラウド上で削除された後も残っているローカルコピーを特定する

同期対象のすべてのデバイス、オフラインフォルダー、除外パス、ごみ箱、競合ディレクトリ、一時復旧フォルダーを検索し、削除されたファイルのコピーがないか確認します。

Dropboxでは、項目を削除すると同期済みデバイス間から削除される場合があると説明しています。ただし、別の場所で所有されているコピーや、同じ同期状態に参加しなくなったコピーは残ることがあります。

復元されたデータベースがそのファイルを以前削除されたオブジェクトとして認識しなくなると、残存するローカルファイルはアップロード候補になります。ハッシュ値を確認し、照合する前に同期ルートの外へ隔離してください。

同期状態をリセットまたは再構築する前にクライアントを一時停止する

サーバーの同期ワーカーを停止し、デスクトップ、モバイル、コンテナ、スケジュール実行されるすべての同期クライアントを一時停止します。まず、正とするエンドポイントを1つだけ再接続してください。

MicrosoftのOneDriveリセット手順では、クライアントがローカルDATファイルを再構築すると説明されています。これは、リセットによってクライアントの状態は変わるものの、どの過去のファイルバージョンを正とするかまでは決まらないことを示しています。

リセットは、正しい時系列を選択する代わりにはなりません。複数のクライアントが同時に再スキャンすると、一方が古いローカルコピーをアップロードする一方で、別のクライアントが削除を反映する可能性があります。

ドライランと独立したバックアップを使って1つのフォルダーを照合する

復元されたデータベースをエクスポートし、競合するすべてのローカルファイルを同期ルートの外へコピーして、正とする状態を選択します。そのうえで、ライブラリ全体を再開する前に、小さなフォルダー1つでテストしてください。

ZimaSpaceの3-2-1バックアップガイドは、関連する重要な境界を示しています。削除を再現したり、古いデータを再アップロードしたりできる同期状態は、独立した復旧用コピーではありません。

削除したファイルが削除されたままになり、残すべきファイルが1回だけアップロードされ、競合が記録され、2回目の管理された同期で予期しない復活が発生しなければ、問題は解決しています。

よくある質問

データベースを復元すると、削除履歴も復元されますか？

データベースのバックアップ時点までに限られます。それ以降に記録された削除は、別のログやエンドポイントに保存されていない限り失われます。

復旧中もすべての同期クライアントを接続したままにすべきですか？

いいえ。一時停止し、まず正とするエンドポイントを1つだけ再接続してください。そうすれば、古いクライアントが古いファイルをすぐに再投入するのを防げます。

完全な再スキャンを実行すれば安全に解決できますか？

再スキャンによって現在存在するものは再構築できますが、失われた過去の意図を推測することはできません。正とする状態を先に選択しないと、残存ファイルが再アップロードされる可能性があります。