For multiple-server trees, ensure that all eDirectory partitions are replicated on more than one server, for fault tolerance.
For information on creating replicas, see Adding a Replica.
Do a full backup of the eDirectory database regularly (such as weekly).
Do an incremental backup regularly (such as nightly).
Do full and incremental tape backups of the file system shortly after full or incremental eDirectory database backups are completed.
The Backup Tool writes the backup files to a directory you specify on the server, but has no way of placing the data directly to tape. File system backup should be set to run after the eDirectory backup has run, to place the database backup files on tape for safe storage.
Turn on and configure roll-forward logging, if it's necessary in your environment.
You must turn on roll-forward logging for servers that participate in a replica ring. If you don't, when you try to restore from your backup files you will get errors and the database will not open. The restore by default won't open a database that shares replicas with other servers unless it is restored back to the state it was in at the moment before it went down.
In a single-server environment, roll-forward logging is not required for the restore verification process, but you can use it if you want to be able to restore eDirectory to the moment before it went down instead of just to the last backup.
Here is a list of the main issues you must address when you turn on roll-forward logging. For more information, see Using Roll-Forward Logs.
Specify a new location for the roll-forward logs (don't use the default).
The logs must be local to the server. For fault tolerance, they must not be stored on the same disk partition/volume or the same storage device as eDirectory. You might want a separate disk partition/volume just for roll-forward logs.
Document where the roll-forward logs are placed, so that you can find them in the event of a failure.
To find out the location when the server is healthy, refer to the Location of the Roll-Forward Logs. But, if the server has a failure that affects eDirectory (such as a hardware failure), you won't be able to look up the location of the roll-forward logs.
Monitor disk space on the disk partition/volume where the roll-forward logs are stored, so that you can prevent it from filling up.
If roll-forward logs cannot be created because no more disk space is available, eDirectory will stop responding on that server.
Restrict access to where the roll-forward logs are kept, so that unauthorized users cannot see them.
If a restore is necessary, make sure you re-create the roll-forward log configuration on the server after the restore is complete. The settings are reset to the default during a restore. After turning on the roll-forward logs, you must also do a new full backup.
If you use NICI, ensure that your eDirectory backups include NICI security files as eDirectory requires the same NICI files to open the DIB and read the encrypted data.
For more information about NICI security, see the Novell International Cryptographic Infrastructure 2.7 Administration Guide and refer to Backing Up and Restoring NICI.
For multiple-server trees, if you are using the Backup Tool to back up a server, you should upgrade all the servers that share replicas with it to eDirectory 8.5 or later.
The restore verification process is backward compatible only with 8.5 or later. For more information about the restore verification, see Overview of How the Backup Tool Does a Restore.
Periodically check the backup log file to make sure that unattended backups were successful.
Do a cold backup before upgrading a server, as described in Upgrading Hardware or Replacing a Server.
For multiple-server trees, ensure that all eDirectory partitions are replicated on more than one server, for fault tolerance.
In addition to making objects available when a server is down, such as during maintenance, replicating your partitions also provides fault tolerance in a case where you lose a server, such as a hardware failure. If a server in a multiple-server tree holds a partition that is not replicated, and the server has a failure, there's a risk that you might not be able to recover the partition. It's best to make sure all partitions are replicated. For more information on why you might not be able to recover an unreplicated partition in a multiple-server tree, see Overview of How the Backup Tool Does a Restore, Using Roll-Forward Logs, and Recovering the Database If Restore Verification Fails.
For information on replication, see Replicas and Section 6.0, Managing Partitions and Replicas.
Ensure that the backup tapes containing the eDirectory and file system backups are in a safe location.
Regularly test your backup strategy to make sure it meets your goals.
(Optional) If you plan to access servers remotely to do cold backups (a full backup with the database closed) or to do advanced backup and restore tasks, install DSBK on the machine you plan to use. Also, arrange for access (such as VPN access) behind the firewall.
iManager lets you do backup and restore tasks remotely, outside the firewall, but it does not support cold backup and advanced tasks.
DSBK is installed with eDirectory on the server, and you can also use it on workstations with Sun JVM 1.3.1. For information on installing and configuring DSBK, see Using DSBK.
(Optional) If you plan to access servers remotely to do cold backups (a full backup with the database closed) or to do advanced backup and restore tasks, install eMBox on the machine you plan to use. Also, arrange for access (such as VPN access) behind the firewall.iManager lets you do backup and restore tasks remotely, outside the firewall, but it does not support cold backup and advanced tasks.
iManager lets you do backup and restore tasks remotely, outside the firewall, but it does not support cold backup and advanced tasks.
eMBox is installed with eDirectory on the server, and you can also use it on workstations with Sun JVM 1.3.1. For information on installing and configuringeMBox, refer to the Using the eMBox Client for Backup and Restore.
Address the issues listed above.
For multiserver trees, consider creating DSMASTER servers to help you prepare for the event of a disaster.
See Using DSMASTER Servers as Part of Disaster Recovery Planning.
Regularly test your disaster recovery strategy to make sure it meets your goals.