Restoring Replicated Suffixes

Suffixes that are replicated between supplier servers and consumer servers require special consideration before being restored. If possible, update the suffix through the replication mechanism instead of restoring it from a backup.

When you restore a supplier or hub instance, the server configuration must be the same as it was when the backup was made. To ensure this, restore the dse.ldif file before restoring Directory Server data. Use --safe option while starting the server. For more information, see To Start, Stop, and Restart Directory Server.

This section explains how and when to restore a replica, and how to ensure that it is synchronized with other replicas after the operation. To initialize a replica, see Initializing Replicas.

If you have a large replicated suffix and you want to add many entries and ensure that replication updates are added correctly, see Incrementally Adding Many Entries to Large Replicated Suffixes.

This section contains information about the following:

• Restoring the Supplier in a Single-Master Scenario

• Restoring a Supplier in a Multi-Master Scenario

• Restoring a Hub

• Restoring a Dedicated Consumer

• Restoring a Master in a Multi-Master Scenario

Restoring the Supplier in a Single-Master Scenario

A suffix that is a single-master supplier contains the authoritative data for the entire replication topology. Therefore, restoring this suffix is equivalent to reinitializing all data in the entire topology. You should restore a single master only if you want to reinitialize all data from the contents of the backup to be restored.

If the single-master data is not recoverable due to an error, consider using the data on one of the consumers because it might contain updates that are more recent than a backup. In this case, you need to export the data from the consumer replica to an LDIF file, and reinitialize the master from the LDIF file.

Whether you restore a backup or import an LDIF file on a master replica, you must then reinitialize all of the hubs and consumer replicas that receive updates from this replica. A message is logged to the supplier servers’ log files to remind you that reinitialization of the consumers is required.

Restoring a Supplier in a Multi-Master Scenario

In multi-master replication, the other masters each contain an authoritative copy of the replicated data. You cannot restore an old backup because it might be out of date with the current replica contents. If possible, allow the replication mechanism to bring the master up to date from the contents of the other masters.

If that is not possible, restore a multi-master replica in one of the following ways:

• The simplest way is not to restore a backup, but to reinitialize the intended master from one of the other masters. This ensures that the latest data is sent to the intended master and that the data will be ready for replication. See Replica Initialization From LDIF.

• For replicas with millions of entries, it can be faster to make a binary copy to restore a more recent backup of one of the other masters. See Initializing a Replicated Suffix by Using Binary Copy.

• If you have a backup of your master that is not older than the maximum age of the change log contents on any of the other masters, the backup may be used to restore this master. See To Modify Change Log Settings on a Master Replica for a description of change log age. When the old backup is restored, the other masters will use their change logs to update this master with all modifications that have been processed since the backup was saved.

Regardless of how you restore or reinitialize, the master replica will remain in read-only mode after the initialization. This behavior allows the replica to synchronize with the other masters, after which time you may allow write operations, as described in Restoring a Master in a Multi-Master Scenario.

The advantage of allowing all replicas to converge before allowing write operations on the restored or reinitialized master is that none of the hub or consumer servers will require reinitialization.

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.

Restoring a Dedicated Consumer

This section applies only in situations where the replication mechanism cannot automatically bring a dedicated consumer 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 consumer in one of the following ways:

• The simplest way is not to restore a backup, but to reinitialize the consumer from one of its suppliers, either a master or a hub replica. This ensures that the latest data is sent to the consumer and that the data will be ready for replication. See Replica Initialization From LDIF.

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

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

Restoring a Master in a Multi-Master Scenario

In the case of multi-master replication, other masters may process change operations while a given master is being restored. Therefore, when restoration is complete, the new master must also receive new updates that were not included in the restore data. Because restoring a master might take a significant amount of time, the number of pending updates might also be significant.

To allow convergence of these pending updates, newly restored masters are automatically set to read-only mode for client operations after restoration. This is true only when restoring a master by importing data from an LDIF file at the command line, or by using a backup to perform a binary copy.

Therefore, after restoration, a master in a multi-master configuration will process replication updates and allow read operations, but it will return referrals for all write operations from clients.

To verify that the new master is fully synchronized with the other masters before allowing updates, manually enable updates on an initialized master.

To Begin Accepting Updates Through the Command Line

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

The following commands can be used in scripts that automate the process of initializing a multi-master replica.

1. Use the insync tool to ensure that the replica has converged with all other masters.

   Replicas are in sync if the delay between modifications on all servers is zero or if the replica has never had any changes to replicate (delay of -1). For more information, see the insync(1) man page.

2. Begin accepting updates.

   $ dsconf set-suffix-prop -h host -p port suffix-DN repl-accept-client-update-enabled:on

   This command automatically sets the server to read-write mode.