Considerations for Simple Custom Provider Design
As with any production data store, a data store that is involved in synchronization should be backed up regularly. If you have to restore a data store from a backup, there are two main considerations:
Changes that were made in the data store after the restore might not be propagated to other replicas.
This can occur in an anchor-based provider because the anchor sent by the destination provider that the source provider uses to enumerate changes may be logically after the changes made after the restore. For example, an anchor-based provider sends changes to a destination provider, which saves the anchor used to enumerate changes. The source replica is restored from an earlier backup and changes are made. Synchronization is performed again with the same source and destination providers. The destination provider begins by sending the anchor used during the last synchronization. Depending on how the anchor is constructed, the source provider may detect that some of the changes made after the restore should not be enumerated.
This can also occur in a full enumeration provider because the tick count used to assign versions to changes on the source replica may cause changes to be detected as obsolete. For example, a full enumeration provider sends changes to a destination provider. The destination provider applies the changes and updates its internal knowledge. The source replica is restored from an earlier backup, which includes an earlier tick count. Changes made on the source replica are assigned versions based on this earlier tick count. Synchronization is performed again. Some of the changes enumerated from the source provider have a tick count that is incorrectly contained in the destination knowledge and so are detected as obsolete and are not applied to the destination replica.
The recommended solution to this situation is to assign a new replica ID to a replica whenever it is restored from a backup. This treats the restored replica as if it is a new replica that has received all of its data from the backed up replica, and treats the backed up replica as retired from the synchronization community. Other replicas in the synchronization community do not have knowledge of the restored replica because of the new replica ID, so new items added to the restored replica are correctly sent during synchronization.
Simple custom providers use the metadata storage service to store metadata, so changing the replica ID requires the following steps.
Implement the provider so that it can operate in a special mode designed for restoring from a backup. While in restore mode, the destination provider applies only metadata changes to the destination replica. The provider does not detect local changes and does not apply change data to the replica.
Restore the replica from a backup. After the replica is restored from a backup, create two instances of the provider. The source provider represents the restored replica with the old replica ID, and the destination provider represents the restored replica with a new replica ID and a new metadata store. Put the destination provider in restore mode.
Synchronize from the source provider to the destination provider. This populates the new metadata store under the new replica ID.
Delete the old metadata store and use the new metadata store and new replica ID to represent the replica. You are now ready to synchronize with the rest of the synchronization community.
New items created after the restore may cause name collisions when an item with the same name was previously created and synchronized. For example, a source replica stores files. The source provider sends a creation change for a file named "MyChange.txt". The source replica is restored from an earlier backup that does not contain MyChange.txt. A new MyChange.txt file is created and assigned a new item ID by the source provider. Synchronization is performed again. When the change for MyChange.txt is sent, the destination provider detects a constraint conflict between the two MyChange.txt files, because they have the same name but different item IDs.
The recommended solution to this situation is to handle constraint conflicts in the provider. This way, when name collisions occur, they are reported as constraint conflicts and correctly resolved. For more information, see Handling Conflicts for Simple Providers.