Designing Backup and Restore Policies

In any failure situation that involves data corruption or data loss, it is imperative that you have a recent backup of your data. Avoid reinitializing servers from other servers where possible. For information about how to back up data, seeChapter 9, Directory Server Backup and Restore, in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

This section provides an overview of what to consider when planning a backup and recovery strategy.

High-Level Backup and Recovery Principles

Apply the following high-level principles when designing a backup strategy:

• Identify the data that must be backed up.

  For Directory Server Enterprise Edition this data includes the following:

  • Shared binaries and plug-ins

  • Certificate database files

  • Configuration files

  • Log files and the change log database

  • Schema files

  • User data

• Ensure that your backup and recovery strategy includes the hardware, operating system, and software components.

• Decide whether you will keep binary backups or LDIF backups.

  A general recommendation is that you keep both. For more information, see Choosing a Backup Method and Choosing a Restoration Method.

• Build automation around backup and recovery tools, and ensure that automatic scripts are maintained.

  This strategy avoids unnecessary delays if you have to restore from a backup in an emergency.

• Determine a retention and rotation strategy.

  This strategy includes how often you perform backups and how long you keep them. When determining retention and rotation of backups, be aware of the purge delay and its impact on backups in a replicated topology. As modifications occur on a supplier, changes are recorded in the change log. Without a method of emptying the change log, its size would continue to increase until the change log consumed all available disk space. By default, changes are purged every seven days. This period is known as the purge delay. When a change has been purged, the change can no longer be replicated. For this reason, make sure that databases are backed up at least as often as the purge delay.

• Use the backup and recovery tools provided with Directory Server Enterprise Edition rather than merely performing a system backup and recovery.

Choosing a Backup Method

Directory Server Enterprise Edition provides two methods of backing up data: binary backup and backup to an LDIF file. Both of these methods have advantages and limitations, and knowing how to use each method will assist you in planning an effective backup strategy.

Binary Backup

Binary backup produces a copy of the database files, and is performed at the file-system level. The output of a binary backup is a set of binary files containing all entries, indexes, the change log, and the transaction log. A binary backup does not contain configuration data.

Binary backup is performed using one of the following commands:

• dsadm backup must be run offline, that is, when the Directory Server instance is stopped. The command must be run on the local server containing the Directory Server instance.

• dsconf backup can be run online and remote to the Directory Server instance.

Binary backup has the following advantages:

• All suffixes can be backed up at the same time.

• Binary backup is significantly faster than a backup to LDIF.

• The replication change log is backed up.

Binary backup has one limitation. Restoration from a binary backup can be performed only on a server with an identical configuration.

This limitation implies the following:

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

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

• Both servers must have the same directory tree that is 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 virtual list view (VLV) indexes. The database files for the suffixes must have the same name.

• Each server must have the same suffixes configured as replicas. If fractional replication is configured, fractional replication must be configured identically on all master servers.

• Attribute encryption must not be used on either server.

At a minimum, you need to perform a regular binary backup on each set of coherent machines. Coherent machines are machines that have an identical configuration, as defined previously.

Because restoration from a local backup is easier, perform a binary backup on each server.

These abbreviations are used in the remaining diagrams in this chapter:

The following figure assumes that M1 and M2 have an identical configuration and that M3 and M4 have an identical configuration. In this scenario, a binary backup would be performed on M1 and on M3. In the case of failure, M1 or M2 could be restored from the binary backup of M1 (db1). M3 or M4 could be restored from the binary backup of M3 (db2). M1 and M2 could not be restored from the binary backup of M3. M3 and M4 could not be restored from the binary backup of M1.

Figure 8–2 Offline Binary Backup

For details on how to use the binary backup commands, see Binary Backup in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

Backup to LDIF

Backup to LDIF is performed at the suffix level. The output of a backup to LDIF is a formatted LDIF file, which is a copy of the data contained in the suffix. As such, this process takes longer than a binary backup.

Backup to LDIF is performed using one of the following commands:

• dsadm export must be run offline, that is, when the Directory Server instance is stopped. This command must be run on the local server containing the Directory Server instance.

• dsconf export can be run online and remote to the Directory Server instance.

Replication information is backed up unless you use the -Q option when running these commands.

The dse.ldif configuration file is not backed up in a backup to LDIF. To enable you to restore a previous configuration, back this file up manually.

Backup to LDIF has the following advantages:

• Backup to LDIF can be performed from any server, regardless of its configuration.

• Restoration from an LDIF backup can be performed on any server, regardless of its configuration.

Backup to LDIF has one limitation. In situations where rapid backup and restoration are required, backup to LDIF might take too long to be viable.

You need to perform a regular backup by using backup to LDIF for each replicated suffix, on a single master in your topology.

In the following figure, dsadm export is performed for each replicated suffix, on one master only (M1).

Figure 8–3 Offline Backup to LDIF

For information about how to use the backup to LDIF commands, see Backing Up to LDIF in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

Choosing a Restoration Method

Directory Server Enterprise Edition provides two methods of restoring data: binary restore and restoration from an LDIF file. As with the backup methods, both of these methods have advantages and limitations.

Binary Restore

Binary restore copies data at the database level. Binary restore is performed using one of the following commands:

• dsadm restore must be run offline, that is, when the Directory Server instance is stopped. This command must be run on the local server containing the Directory Server instance.

• dsconf restore can be run online and remote to the Directory Server instance.

Binary restore has the following advantages:

• All suffixes can be restored at the same time.

• The replication change log is restored.

• Binary restore is significantly faster than restoring from an LDIF file.

Binary restore has the following limitations:

• Restoration can be performed only on a server with an identical configuration, as defined in Binary Backup. For more information about restoring data with the binary restore feature, see Binary Restore in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

• If you are not aware that your database was corrupt when you performed the binary backup, you risk restoring a corrupt database. Binary backup creates an exact copy of the database.

Binary restore is the preferred restoration method if the machines have an identical configuration and time is a major consideration.

The following figure assumes that M1 and M2 have an identical configuration and that M3 and M4 have an identical configuration. In this scenario, M1 or M2 can be restored from the binary backup of M1 (db1). M3 or M4 can be restored from the binary backup of M3 (db2).

Figure 8–4 Offline Binary Restore

Restoration From LDIF

Restoration from an LDIF file is performed at the suffix level. As such, this process takes longer than a binary restore. Restoration from LDIF can be performed using one of the following commands:

• dsadm import must be run offline, that is, when the Directory Server instance is stopped. This command must be run on the local server containing the Directory Server instance.

• dsconf import can be run online and remote to the Directory Server instance.

Restoration from an LDIF file has the following advantages:

• This command can be performed on any server, regardless of its configuration.

• A single LDIF file can be used to deploy an entire directory service, regardless of its replication topology. This functionality is particularly useful for the dynamic expansion and contraction of a directory service according to anticipated business needs.

Restoration from an LDIF file has one limitation. In situations where rapid restoration is required, this method might take too long to be viable. For more information about restoring data from an LDIF file, see Importing Data From an LDIF File in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

In the following figure, dsadmin import is performed for each replicated suffix, on one master only (M1).

Figure 8–5 Offline Restoration From LDIF