Considerations for Standard 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, consider the following issues.
Changes made in the data store after the restore might not be propagated to other replicas.
This can occur 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 source provider sends changes to a destination provider. The destination provider applies the changes and updates its 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.
When the metadata storage service is used to store metadata, changing the replica ID requires additional steps. These are:
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 on constraint conflicts, see Detecting and Resolving Constraint Conflicts.