• この記事では、「レプリケーションの再同期」によって、ネットワーク経由で送信するデータを決定する方法について説明します。再同期を実行する手順については、次の記事を参照してください。「Data Domain：ディレクトリ レプリケーションを中断および再同期する方法。

該当製品：

• すべてのData Domain (DD)モデル
• ディレクトリ レプリケーション
• すべてのソフトウェア リリース4.3以降

対処法

再同期はinitializeとほぼ同じであり、 ディレクトリ レプリケーション コンテキストのinitializeの代わりに指定することもできますが、次の違いがあります。

レプリカ ディレクトリーは空である必要はありません。内部的には、デスティネーションによって既存のファイルが邪魔にならない場所に移動します。

(4.3 から 4.5 までは、これらのファイルの名前を $destdir/.ddrsaved/ directoryの詳細を確認してください。4.6+では、スナップショットを作成し、レプリケーション コンテキストからファイルを削除します $destdir）。

ソースディレクトリ内のファイルごとに、同じ相対パスがターゲットに存在するかどうかをチェックします( $destdir/.ddrsaved、またはスナップショット)。 

ファイルが存在する場合は、宛先ファイルがソース ファイルと同一かどうかを確認します。 

同一の場合、既存のレプリカ ファイルは所定の場所にハード リンクされ、その内容をフィルタリングしたり送信したりする必要はありません。

ファイルIDチェックは一定の時間で行われます。

レプリカ ファイルがディレクトリ レプリケーション >= 4.3 によって作成されている場合、チェックは成功します。

つまりシーディングは、コレクション レプリケーション(Data DomainがLAN内にある場合に便利)を実行してから、コレクション レプリケーションを中断し、ディレクトリー レプリケーションの再同期を実行することで実現できます。

レプリカ ファイルが見つからない場合、またはコンテンツが一致しない場合、ファイルは正常に複製されます。つまり、セグメントごとにフィルター処理されます。

再同期の要点は、可能な限りこのフィルタリングを回避することです。

潜在的な落とし穴は、ファイルの名前を変更する人間の操作またはアプリケーション ロジックによって、再同期の前にレプリケーションが中断された後に、作成者またはレプリカ ファイルが移動または名前変更される可能性があることです。

これにより、再同期のパス名検索で一致が見つからず、各ファイルの完全なフィルタリングが必要になります。

セグメントはデスティネーションに存在するため、高いレプリケーション圧縮が実現されますが、セグメント参照の送信とフィルタリングを最初に回避する機会を逃します。

• 4.5では、レプリカでリテンション ロックが有効になっているか、有効になっていた場合、再同期は失敗します。
• 4.6以降では、レプリカ上の保存ロックされたファイルに関連するいくつかの追加要件があります。基本的に、デスティネーション上の保存ロックされたファイルも存在し、オリジネーターのコンテンツと属性が一致している必要があります。これは、レプリケーションがレプリカ上の保存ロックされたファイルを削除しようとするのを防ぐためです。

• 「Data Domain：NVRAM損失の可能性により、レプリケーション コンテキストが無効になっています
• 「Data Domain：ディレクトリ レプリケーションを中断および再同期する方法