Performing binary restores in replicated environments requires special care depending on your replicated topology. If possible, update your back end by using the replication mechanisms in your system instead of restoring it from a backup. Replication has distinct advantages over traditional tape backups. Data restores are much faster than tape restores, and the data is more up to date. However, tapes are still needed in the event that the replicated data is corrupt and has been propagated to other servers.
When restoring a replicated server, ensure that the configuration file install-dir/config/config.ldif is the same as when the backup was made. Restore the config.ldif file prior to restoring the server back ends.
You cannot restore an old backup to a master server because it might be out of date. Rather allow the replication mechanism to bring a master up to date with the other master servers by setting that master to read-only. When the master has been synchronized, you can reset it to read-write.
If you need to restore a replicated server, reinitialize the server from one of the other replicated servers by importing an LDIF file.
For very large databases (millions of entries), make a binary copy of one server and restore it on the other replicated server.
If you have a fairly recent backup (one that is not older than the maximum age of the change log contents on any of the other replicated servers), you can use that version to restore your data. When the old backup is restored, the other servers will update that server with recent updates made since the backup was saved.