なぜリモート同期は再接続後にフォルダー全体を再コピーするのですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Does Remote Sync Recopy an Entire Folder After Reconnecting? - Zima Store Online

リモート同期は、クライアントがローカルとリモートのファイルが同一であることを証明できなくなった場合に、フォルダ全体を再コピーします。

ノートパソコン、NAS、マウントされた共有、またはリモートピアが再接続した後、同期エンジンはインデックスを再構築したり、異なるファイルシステムの識別子を検出したり、保存されたハッシュを失ったり、変更されたタイムスタンプを検出したり、名前変更されたファイルを新しいオブジェクトとして扱ったり、古いデータベースと比較したりすることがあります。正しい診断はまず両方のコピーを保護し、その後クライアントが再スキャン、再ハッシュ、再ダウンロード、または実際にデータを再転送しているかどうかを判断し、ライブラリをリセットするかどうかを決定します。

クライアントがスキャン、ハッシュ、または転送を行っているか確認する

見かけ上の再コピー中にネットワークスループット、ディスク読み取り、CPU使用率、クライアントの状態、ログメッセージを記録します。完全なスキャンやチェックサム処理は、フォルダ全体をインターネット経由で送信しなくても数時間忙しく見えることがあります。

rcloneのディスカッションでは、チェックサムモードが毎回チェックサム処理を繰り返すことが説明されています。この動作はストレージとCPUを消費しますが、真のネットワーク再送信とは異なります。

ファイルごとの転送カウンターやパケット合計を使ってイベントを分類します。メタデータとハッシュのみが読み取られている場合はスキャン状態を最適化し、完全なペイロードバイトが再度移動している場合は、識別、インデックス、タイムスタンプ、名前変更のテストを続行します。

同期データベースまたはインデックスが再構築されたか確認する

再接続時のクライアントログを調べ、データベースの移行、破損、インデックスの欠落、リセット、再スキャン、初回実行メッセージを確認します。クライアントの設定ディレクトリとデータベースのタイムスタンプを最後の正常な同期と比較します。

Syncthingのサポートケースでは、破損したインデックスデータベースは再構築が必要であり、デバイスがフォルダを新規追加されたかのように振る舞い、大規模な初期再スキャンを引き起こす可能性があると説明されています。

データベースを削除またはリセットする前にバックアップを取ってください。アプリの再インストール、コンテナの再作成、プロファイルのリセット、データベースの消失直後に再コピーが始まった場合は、良好なデータを保持し、クライアントのサポートされている既存フォルダへの再接続ワークフローを使用してください。

ファイル名以外のファイル識別情報を比較する

クライアントが再コピーしようとしている複数のファイルを選び、両側のサイズ、変更日時、チェックサム、権限、所有権、大文字小文字、拡張属性、パスを比較します。どのフィールドが異なるかを記録します。

FreeFileSyncユーザーは、サイズとタイムスタンプだけではペアのファイルが同一であることを常に証明できないためチェックサムを保存し、チェックサムデータベースは独自の状態要件を追加すると議論しています。これは再接続後のファイル比較メタデータが重要である理由を示しています。

コンテンツのハッシュが一致しているがタイムスタンプや権限が異なる場合は、コンテンツを再転送するのではなく、時計、メタデータ保持、比較設定を修正してください。ハッシュが異なる場合は、自動上書きを許可する前にどちらが正当な側かを特定してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

フォルダが異なる識別子で再接続されたか確認する

切断前後のマウントパス、ファイルシステムUUID、ネットワーク共有名、ドライブレター、ボリューム識別子、コンテナのバインドマウント、大文字小文字の区別を比較します。見慣れたフォルダパスでも異なるマウントや空のローカルディレクトリを指していることがあります。

同期ツールは表示されるパスだけを信用せず、フォルダの識別情報をローカルデータベースに保存することが多いです。再マウントされたNAS共有、交換されたUSBディスク、変更されたDockerボリューム、再作成されたクライアントプロファイルは、新しいターゲットのように見えることがあります。

期待されるマウントが存在しないかフォルダがローカルのフォールバックストレージを指している場合は同期を停止してください。元のマウントを復元し、サンプルファイルを確認してからライブラリを再接続し、削除や重複ダウンロードを防ぎます。

移動や名前変更が検出されているかテストする

小さなフォルダを1つ選び、両方のピアが接続されている間に名前を変更し、クライアントがメタデータの移動を行うか、すべてのファイルを新しいコンテンツとしてアップロードするかを観察します。切断と再接続後に繰り返します。

Syncthingの機能ディスカッションでは、ツールが既存のインデックスで変更されたパスを一致させられない場合、移動や名前変更が新しい転送として扱われ、削除と再アップロードの動作を引き起こすことが指摘されています。

再コピーが上位フォルダの名前変更に続く場合は、クライアントがインデックス交換を完了するまで待ってからさらに変更を加えてください。大規模なライブラリでは、複数のピアで同時に大量の名前変更を避け、バージョニングやバックアップ保護を有効にしておいてください。

良好なコピーをリセットせずに安全に再接続する

正当な側のバックアップまたはスナップショットを作成し、同期を一時停止して、クライアントの既存フォルダまたは再リンク機能を使って小さなサブフォルダをテストします。方向性を理解せずに一般的なリセットや再同期ボタンをクリックしないでください。

ZimaSpaceの1つの共有フォルダを安全に復元する方法のガイドは、影響を受けないデータを保護するための同じ封じ込めの原則を提供しています。

問題は、再接続がインデックスを保持し、既存ファイルをペイロード転送なしで比較し、本物の変更のみを適用し、再度の切断に耐えられる場合にのみ解決されます。データベースが繰り返し破損または消失する場合は、繰り返される完全同期を受け入れるのではなく、ストレージ、シャットダウン、コンテナの永続性、クライアントインストールの問題を修正してください。