簡單自訂提供者設計的考量
與任何實際執行的資料存放區相同，涉入同步處理的資料存放區應該要定期備份。如果您必須從備份還原資料存放區，就有兩大主要考量：
還原之後在資料存放區中進行的變更，可能不會傳播到其他複寫。
這可能會發生在以錨定為基礎的提供者中，因為來源提供者用來列舉變更的錨定 (由目的地提供者所傳送) 在邏輯上可能晚於還原之後所進行的變更。例如，假設某個以錨定為基礎的提供者會傳送變更到目的地提供者，而它會儲存用於列舉變更的錨定。然後又從舊版備份還原來源複寫並且進行了某些變更。對相同的來源和目的地提供者再次執行同步處理。目的地提供者一開始會先傳送上次同步處理期間使用的錨定。根據錨定的建構方式，來源提供者可能會偵測到某些在還原之後進行的變更不應該列舉。
這種情況也可能發生在完整列舉提供者，因為用於指派版本給來源複寫上之變更的滴答計數，可能會造成某些變更因而偵測為過時。例如，假設某個完整列舉提供者傳送某些變更給目的地提供者。目的地提供者便會套用變更並且更新其內部知識。從先前的備份還原來源複寫，而此備份包含舊版的滴答計數。會依據這個舊版的滴答計數指派版本給來源複寫的變更。再次執行同步處理。從來源提供者列舉的某些變更會擁有不應包含但已包含在目的地知識中的滴答計數，並因此偵測為過時並且不會套用到目的地複寫。
這種情況的建議解決方案是，每當從備份還原複寫時，將新的複寫識別碼指派給複寫。這樣做會將還原的複寫視為已經從備份之複寫接收所有資料的新複寫，並且將備份的複寫視為已經在同步處理社群中停用。同步處理社群中的其他複寫會由於新的複寫識別碼而沒有已還原複寫的知識，所以加入至已還原複寫的新項目會在同步處理期間正確傳送。
由於簡單自訂提供者會使用中繼資料儲存服務來儲存中繼資料，所以變更複寫識別碼需要進行下列步驟。
實作提供者，讓它能夠在針對從備份還原所設計的特殊模式中運作。如果處於還原模式，目的地提供者就只會將中繼資料變更套用至目的地複寫。提供者不會偵測本機變更，而且不會將變更資料套用至複寫。
從備份還原複寫。從備份還原複寫之後，請建立兩個提供者執行個體。來源提供者代表包含舊複寫識別碼的已還原複寫，而目的地提供者則代表包含新複寫識別碼和新中繼資料存放區的已還原複寫。請讓目的地提供者處於還原模式。
從來源提供者同步處理至目的地提供者。這樣會根據新的複寫識別碼填入新的中繼資料存放區。
刪除舊的中繼資料存放區，並且使用新的中繼資料存放區和新的複寫識別碼來代表複寫。您現在就可以準備同步處理其餘同步處理社群。
如果先前已建立相同名稱的項目並且已經同步處理，在還原之後建立的新項目可能會造成名稱衝突。例如，假設來源複寫還原檔案。來源提供者針對名為 "MyChange.txt" 的檔案傳送建立變更。從未包含 MyChange.txt 的舊版備份還原來源複寫。來源提供者會建立一個新的 MyChange.txt 檔案並且指派新的項目識別碼。再次執行同步處理。在傳送 MyChange.txt 時，目的地提供者會偵測到兩個 MyChange.txt 檔案之間有條件約束衝突，因為兩者的名稱相同，但是項目識別碼不同。
這種情況的建議解決方案是在提供者中處理條件約束衝突。如此一來，發生名稱衝突時，系統就會將它們回報成條件約束衝突，並且正確地進行解決。如需詳細資訊，請參閱處理簡單提供者的衝突。