Initializing a Replicated Suffix by Using Binary Copy

A binary copy enables you to clone an entire server by using the binary backup files from one server to restore the identical directory contents onto another server. You can use a binary copy to initialize or reinitialize any server from the binary copy of a master or hub server, or a consumer from the binary copy of another consumer server.

This advanced procedure interacts with the database files of Directory Server and should only be used by experienced administrators.

Certain restrictions on this feature make it practical and time efficient only for replicas with very large database files, for example, replicas containing millions of entries.

Restrictions for Using Binary Copy With Replication

Because a binary copy moves database files from one machine to another, the mechanism is subject to the following strict limitations:

• Both machines must run the same operating system, including any service packs or patches.

• Both machines must share the same processor architecture. For example, you can perform binary copy between two UltraSPARC® T1 processors but not between an UltraSPARC T1 and an AMD Opteron processor.

• Both machines must be either big endian or little endian.

• Both machines must map memory the same way. For example, you can perform binary copy between server instances on two 64-bit systems, but not between one server instance on a 32-bit system and another on a 64-bit system.

• Both machines must have the same version of Directory Server installed, including binary format (32 bits or 64 bits), service pack, and patch level.

• Both servers must have the same directory tree divided into the same suffixes. The database files for all suffixes must be copied together. Individual suffixes cannot be copied.

• Each suffix must have the same indexes configured on both servers, including VLV (virtual list view) indexes. The databases for the suffixes must have the same name.

• Each server must have the same suffixes configured as replicas.

• If fractional replication is configured, it must be configured identically on all servers.

• Attribute encryption must not be used on either server.

• The attribute value uniqueness plug-in must have the same configuration on both servers if enabled, and it must be re-configured on the new copy, as explained in the following procedures.

  These procedures describe alternate ways of performing a binary copy: a binary copy that does not require stopping the server and a binary copy that uses the minimum amount of disk space.

Making a Binary Copy for Initializing a Server

This section describes how to make a binary copy for initializing a server, and how to make a binary copy that uses minimum disk space.

To Make a Binary Copy For Initializing a Server

Use this procedure to perform a binary copy for initializing a replicated server because it uses the normal backup functionality to create a copy of the server’s database files. Performing a normal backup ensures that all database files are in a coherent state without requiring you to stop the server.

This procedure has certain limitations. The backup and restore operations create copies of the database files on the same machine, thereby doubling the amount of disk space required by those files on each machine. Additionally, the actual copy operation on these files might take a significant amount time if your directory contains gigabytes of data.

For parts of this procedure, you can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help. Other parts of the procedure can only be done using the command line.

1. Install Directory Server on the target machine for the new replicated suffix, create a new instance of the server if necessary, and configure the server according to Restrictions for Using Binary Copy With Replication.

2. Create all replication agreements in your replication topology that involve this replicated suffix.

   Include agreements from suppliers to this replica. If this replica is not a dedicated consumer, include agreements from this replica to its consumers. See Creating and Changing Replication Agreements.

3. Select a fully configured and initialized replica of the same type as you want to initialize, either master, hub, or consumer, and perform a normal backup on it according to Binary Backup.

4. Copy or transfer the files from the backup directory to a directory on the target machine by using the ftp command, for example.

5. If you have initialized a new master in a multimaster replication scenario, follow the procedures in Restoring a Master in a Multi-Master Scenario.

To Use Binary Copy for Initializing a Server Using Minimum Disk Space

This procedure uses less disk space and takes less time because it does not make backup copies of the database files. However, it requires you to stop the server that is being cloned to order to ensure that the database files are in a coherent state.

For parts of this procedure, you can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help. Other parts of the procedure can only be done using the command line.

1. Install Directory Server on the target machine for the new replicated suffix, create a new instance of the server if necessary, and configure the server according to Restrictions for Using Binary Copy With Replication.

2. Create all replication agreements in your replication topology that involve this replica.

   Include agreements from suppliers to this replica. If this replica is not a dedicated consumer, include agreements from this replica to its consumers. See Creating and Changing Replication Agreements.

3. Stop the target server that will be initialized or reinitialized, as described in Starting, Stopping, and Restarting a Directory Server Instance .

4. Select a fully configured and initialized replica of the same type that you want to initialize, either master, hub, or consumer, and stop this server as well.

   If you are cloning a master replica in a multimaster configuration, ensure that it is fully up-to-date with all of the latest changes from the other masters before stopping it.

5. Restart both the source and the target servers.