Restoring a Hub

This section applies only in situations where the replication mechanism cannot automatically bring a hub replica up to date. Such situations include if the database files become corrupted or if replication has been interrupted for too long. In these cases, you need to restore or reinitialize the hub replica in one of the following ways:

• The simplest way is not to restore a backup, but to reinitialize the hub from one of the master replicas. This ensures that the latest data is sent to the hub and that the data will be ready for replication. See Initializing a Suffix.

• For replicas with millions of entries, it can be faster to make a binary copy to restore a more recent backup taken from another hub replicated suffix. See Initializing a Replicated Suffix by Using Binary Copy. If there is no other hub replica to copy, reinitialize the hub as described in the previous item, or restore it as described in the next item, if possible.

• If you have a backup of your hub that is not older than the maximum age of the change log contents on any of its suppliers, either hub or master replicas, the backup may be used to restore this hub. When the hub is restored, its suppliers will use their change logs to update this hub with all modifications that have been processed since the backup was saved.

Regardless of how you restore or reinitialize the hub replica, you must then reinitialize all consumers of this hub, including any other levels of hubs.