Backing Up and Restoring Data

Oracle Unified Directory provides an extensible framework that supports a variety of repository types. The directory server uses the Berkeley DB Java Edition (JE) as its primary back end. The JE back end provides some advantages over other databases as it provides a high-performance, scalable transactional B-tree database with full support for ACID semantics for small to very large data sets. It can also store its entries in encoded form and provide indexes for fast, efficient data retrieval.

This section covers the following topics:

Overview of the Backup and Restore Process
Backing Up Data
Backing Up the Server Configuration
Backing Up for Disaster Recovery
Restoring Data
Restoring Replicated Directory Servers

Overview of the Backup and Restore Process

To maintain the directory data on the JE back end, the directory server provides efficient backup and restore utilities that support full and incremental backups. A full backup saves the directory data files in the environment as a compressed archive file. An incremental backup saves and compresses just those files that have been written since the previous backup, together with a list of names of files that are unchanged since the previous backup. The directory server stores its backup information in a backup back end for easy restores.

Directory server backups also can be made on the local disks or on remote disks, for example, on network-attached storage (NAS). If you run a backup locally, you should then copy and store the backup on a different machine or file system for security purposes.

Before you start backing up and restoring data, consider the following:

You must design a workable backup and restore strategy for your directory services system. For example, you can run an incremental backup daily and perform a full backup at least once a week. Test your backup process and your ability to restore regularly. For data restores, many companies restore a directory server from a replicated server, which ensures that the most update copy of the directory data is used. Backup tapes are still needed if the directory data is damaged (for example, missing entries) and the corrupted data has been replicated to other servers.
Ensure that you have a disaster recovery plan in place. Disaster recovery is necessary when catastrophic events, data corruption, or data tampering occurs. Companies devise their own plans or out source the work to third party specialists. See Backing Up for Disaster Recovery for more information.
Ensure that you have a place to store your back ups. Store the archived data, configuration directory, schema subdirectory, and installation directory used for your server together in a single location. All these items are required when you restore the server.

Backing Up Data

The directory server provides an efficient command-line utility (backup) to back up databases. The backup command can be run immediately or scheduled as a task. If the backup is scheduled, the command contacts the server over SSL, using the administration connector, and registers a backup task. If no connection options are specified, the command runs immediately.

The following procedures show the use of the backup command in various backup scenarios.

To Back Up All Back Ends

You can back up all back ends end by using the --backUpAll option.

Run the backup command with the --backUpAll option.
The following command is run on a standalone directory server and specifies that all databases should be backed up, compresses the backup file, and saves the file to a specified location.
```
$ backup --backUpAll --compress --backupDirectory /tmp/backup
```
The backup directory contains subdirectories for each back end:
```
$ ls /tmp/backup
./ ../ config/ schema/ tasks/ userRoot/
```
The backup utility writes the backup to the specified directory and creates a backup.info file that provides details about the backup. The directory server assigns a backup ID based on the current date and time. To create your own ID, use the --backupID option:
```
$ ls /tmp/backup/config
./ backup.info
../ config-backup-20070827153501Z
```
The backup.info file contains detailed information about the current backup.
```
$ more /tmp/backup/config/backup.info
backend_dn=ds-cfg-backend-id=config,cn=Backends,cn=config

backup_id=20070827153501Z
backup_date=20070827153511Z
incremental=false
compressed=true
encrypted=false
property.archive_file=config-backup-20070827153501Z
```

To Back Up All Back Ends with Encryption and Signed Hashes

The backup utility provides encryption and signed hash support for secure backups. The use of the encryption and signed hash options requires a connection to an online server instance, so the appropriate connection options must be specified.

Run the backup command .

The following command backs up all back ends, compresses them, generates a hash, signs the hash, and encrypts the data.

$ backup -h localhost -p 4444 -D "cn=directory manager" -w password --backUpAll -X \
  --compress --hash --signHash --encrypt --backupID 123 --backupDirectory /tmp/backup

To Perform an Incremental Backup on All Back Ends

Incremental backups save only those changes that have occurred since the last backup (full or incremental). The main advantage of an incremental backup is the faster time to back up a system when compared to that of full backups. The disadvantage of an incremental backup is that each incremental backup must be restored, which requires more time and care than that of a full restore.

Run the backup command with the --incremental option.

$ backup --backUpAll --incremental --compress --backupDirectory /tmp/backup

To Back Up a Specific Back End

You can back up a single back end by using the --backendID option, which specifies the back end to save.

Note - If you back up a single back end and replication is configured, any changes made to that back end are stored in the change log on the replication server. When you restore that back end, the replication server detects that the back end is not up to date and replays the changes made after the backup. This behavior occurs even if there is only one directory server in the replicated topology, because the changes are stored on the replication server.

If you do not want this behavior, back up all back ends in a replicated environment. This ensures that the data, and the replication server are backed up. In this case when a restore is done, the directory server and the replication server are restored to their state before the back up, and no memory of subsequent changes remains.

(Optional) List the back ends that are configured on the server, by running the list-backends command. For example:

$ list-backends

Backend ID     Base DN
-------------- -----------------
adminRoot      cn=admin data
ads-truststore cn=trust-store
backup         cn=backups
config         cn=config
monitor        cn=monitor
schema         cn=schema
tasks          cn=tasks
userRoot       dc=example,dc=com

Run the backup command with the --backendID option.
For example, to back up the userRoot back end, run the following command:
```
$ backup --backendID userRoot --backupDirectory /tmp/backup
```

To Perform an Incremental Backup on a Specific Back End

(Optional) List the back ends that are configured on the server, by running the list-backends command. For example:

$ list-backends

Backend ID     Base DN
-------------- -----------------
adminRoot      cn=admin data
ads-truststore cn=trust-store
backup         cn=backups
config         cn=config
monitor        cn=monitor
schema         cn=schema
tasks          cn=tasks
userRoot       dc=example,dc=com

Run the backup command with the --incremental option.

$ backup --incremental --backendID userRoot --backupDirectory /tmp/backup

To Schedule a Backup as a Task

The directory server provides a task back end for processing administrative tasks, such as backups and restores. You can specify the start time for a backup or restore by using the -t or --start option. If one of these options is provided, the utility exits immediately after scheduling the task. To schedule a task for immediate execution and have the utility exit immediately after scheduling the task, specify 0 as the value for the start time. If the -t or --start option is omitted, the utility schedules the task for immediate execution and tracks the task's progress, printing log messages as they are available and exiting when the task has completed.

Access to the task back end is provided over SSL via the administration connector. If you schedule the backup as a task, you must therefore specify how the SSL certificate will be trusted. This example schedules a backup for execution at a future time. The -X option specifies that all certificates presented by the server are trusted. For more information, see Managing Administration Traffic to the Server.

Run the backup command with the following options:

$ backup --port 4444 --bindDN "cn=Directory Manager" --bindPassword password -X \
  --backUpAll --backupDirectory /tmp/backups --start 20080601121500 \
  --completionNotify admin@example.com --errorNotify admin@example.com

(Optional) View information about the scheduled task by using the manage-tasks command. For example:

$ manage-tasks --port 4444 --bindDN "cn=Directory Manager" --bindPassword password -X \
  --info 2008040210324704 --no-prompt

Backing Up the Server Configuration

All configuration settings for a directory server instance are stored in the config.ldif file, which is located in the config directory. The directory server automatically saves the config.ldif file to ensure that changes are properly accounted for in the configuration. The file is saved at two specific times:

At startup. If the current configuration does not match the archived configuration, the server saves the config.ldif file.
At modification time. Whenever a directory administrator makes changes to the configuration by using the dsconfig utility with the server online, the directory server saves the config.ldif file prior to the change.

You can access archived configuration files from the install-dir/config/archived-configs directory. This directory lists each saved configuration file, compresses it as a .gz file, and saves the configuration as config-timestamp.gz. For example, you can see archived config.ldif files as follows:

$ ls config/archived-configs
09/02/2007 03:43 PM 9,045 config-20070819055359Z.gz

Backing Up for Disaster Recovery

Directory and system administrators should have a disaster recovery plan in place in the event of a natural, human-induced, or catastrophic disaster. If your directory service is distributed over multiple individual servers, back up all the servers individually or back up all the directory data from a central location.

Alternatively, consider replication as a backup and restore strategy. Replication provides faster restores and more update data from another replicated server. For more information, see Restoring Replicated Directory Servers.

To Back Up the Directory Server For Disaster Recovery

Make a backup of all back ends by using the --backUpAll option, for example:
```
$ backup --backUpAll --backupDirectory /tmp/backup
```
Copy the configuration directory, install-dir/config.
Make sure that the schema subdirectory is present within the install-dir/config directory.
Copy the files in install-dir/logs.
Make a copy of the installation directory.
Store the archived data, configuration directory, schema subdirectory, log files and installation directory together in a single location.
All items are required when restoring the server.

Backing up and Restoring Data Using File System Snapshots

For certain deployments, file system snapshot technologies offer a viable alternative to the traditional backup. On Solaris systems, ZFS enables file system snapshots that are space efficient, very quick to create, and portable between systems. By dedicating a Directory Server per data center, or two if your entire service runs in one data center, you deploy an effective, redundant solution for restoring data as part of your disaster recovery plan.

To Take a ZFS Snapshot On a Dedicated Backup Server

Because the Directory Server is dedicated to backup, configure the server as a read-only replica if you have not already done so.
```
$ dsconfig -h host -p 4444 -D "cn=Directory Manager" -w password -X -n \
  set-global-configuration-prop --set writability-mode:internal-only
```
When you restore a server from the snapshot of the read-only replica, the restored server accepts only replication traffic until you enable writability, after the server has caught up with other replicas in the topology.
Take the ZFS snapshot.
For example, if the Directory Server files are stored in the file system corresponding to zpool/DS_FS, the command is:
```
$ zfs snapshot zpool/DS_FS@{todays_date}
```
Back up the snapshot to other storage.
```
$ zfs send zpool/DS_FS@{today_date} > /backups/DS_FS.{today_date}.zfs
```
Do not keep snapshots longer than the replication purge delay, because when you restore from a snapshot, the replication mechanism has to be able to replay all the missing changes on the replica.

To Restore a Directory Server From a ZFS Snapshot

Import the backup zpool.
Create a ZFS file system to access the backup pool, using /backups as the mount point.
Stop the Directory Server that is being restored.

Initialize the ZFS file system from /backups.

$ dd if=/backups/DS_FS.{date_to_restore}.zfs bs=32k | zfs receive -F zpool/DS_FS

Adapt the configuration as necessary to use the host name and port numbers of the Directory Server to restore.
Start the Directory Server.
Monitor replication until you observe that the Directory Server is in sync with other replicas in the topology.

Set the writability-mode to enabled, allowing the Directory Server to process write operations from clients.

$ dsconfig -h restored-host -p 4444 -D "cn=Directory Manager" -w password -X -n \
  set-global-configuration-prop --set writability-mode:enabled

Restoring Data

You can restore data by using the restore utility. The restore utility allows you to restore only one back end at a time. The directory server must be stopped prior to a restore, unless you are scheduling a restore task, or you are restoring data that has been signed or hashed.

To Restore a Back End

Stop the server, if it is running.

(Optional) Display the backup information by running the restore command with the --listBackups option. For example:

$ restore --listBackups --backupDirectory backup/userRoot  
Backup ID: 20080827153501Z 
Backup Date: 27/Aug/2008:10:35:11 -0500 
Is Incremental: false 
Is Compressed: true 
Is Encrypted: false 
Has Unsigned Hash: false 
Has Signed Hash: false 
Dependent Upon: none

Restore the back end.

$ restore --backupDirectory backup/userRoot

Repeat the restore for the other back ends.

To Restore a Back End From Incremental Backups

Typically, system administrators run a weekly full backup with daily incremental backups. Be aware that it takes longer to restore your system from incremental backups.

Restore the last full backup on your system by using the restore command.
Each back end must be restored individually.
Restore each incremental backup by using the restore command.
Restore each incremental backup starting from the last full backup.

To Schedule a Restore as a Task

The directory server provides a task back end for processing administrative tasks, such as backups and restores. You can specify the start time for a restore by using the -t or --start option. If one of these options is provided, the utility exits immediately after scheduling the task. To schedule a task for immediate execution and have the utility exit immediately after scheduling the task, specify 0 as the value for the start time. If the -t or --start option is omitted, the utility schedules the task for immediate execution and tracks the task's progress, printing log messages as they are available and exiting when the task has completed.

Access to the task back end is provided over SSL, using the administration connector. If you schedule the restore as a task, you must therefore specify how the SSL certificate will be trusted.

Ensure that the server is stopped prior to the scheduled restore time.
Schedule the restore by using the -t or --start option of the restore command.
The following command restores the userRoot back end at a scheduled start time by using the --start option. The restore sends a completion and error notification to admin@example.com. The -X option specifies that all certificates presented by the server are trusted.
```
$ restore -p 4444 -D "cn=Directory Manager" -w password -X \ 
  -d /backup/userRoot --start 20080125121500 --completionNotify admin@example.com \
  --errorNotify admin@example.com
```
(Optional) You can view this scheduled task by using the manage-tasks utility.
For more information, see Configuring Commands As Tasks.

To Restore the Configuration File

You might need to restore the configuration file to transfer the configuration to another server, for disaster recovery purposes, or for other events. In general, if a server is online, the current configuration file is equivalent to the latest archived configuration file. However, you can choose to restore the config.ldif file from a previous date.

Stop the server if it is running.

Locate the required configuration file on the system. For example:

$ ls install-dir/config/archived-configs
./ 
../
config-20070817192057Z.gz
config-20070827153200Z.gz
config-20070817192052Z.gz
config-20070827153214Z-2.gz

Manually decompress the archived configuration file, using a decompression utility such as gunzip.
Copy the file to the config directory, replacing the current config.ldif file.
```
$ cp config-20070817182052Z install-dir/config/config.ldif
```

To Restore a Directory Server During Disaster Recovery

Install the same version of the directory server that was previously installed on the host.
Create a server instance by using the setup command.
Copy the saved config directory to install-dir/config.
The config.ldif file should reside in this directory. The saved schema subdirectory should be located in install-dir/config/schema.
Check that the configuration for the restored server is correct.
Restore the individual back ends by using the restore command.

Restoring Replicated Directory Servers

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.

Deleting Backup Data

If you run regular backups, the backup files might start to consume too much disk space. You must remove the old backup files manually to create space for new ones.

To Delete Backup Files

When you delete backup files manually, make sure that you do not break any dependencies between backup sets.

List the existing backups in your backup directory.

For example, to list the backups in the default backup directory, run the following command:

UNIX: $ ls install-dir/bak
       backup-userRoot-20090929184101Z backup-userRoot-20091029184509Z
       backup.info backup.info.save

WINDOWS: C:\> dir install-dir\bak
         backup-userRoot-20090929184101Z backup-userRoot-20091029184509Z
         backup.info backup.info.save

Delete the backup file from the backup directory.
For example, to remove the oldest backup of the userRoot database in the preceding step, run the following command:
```
UNIX: $ rm install-dir/bak/backup-userRoot-20090929184101Z

WINDOWS C:\> del install-dir\bak\backup-userRoot-20090929184101Z
```

Remove the associated backup information from the backup.info file.

You can display the contents of the backup.info, as follows (on UNIX systems):

$ more install-dir/bak/backup.info
     backend_dn=ds-cfg-backend-id=userRoot,cn=Backends,cn=config

     backup_id=20090929184101Z
     backup_date=20090929184104Z
     incremental=false
     compressed=false
     encrypted=false
     property.last_logfile_name=00000000.jdb
     property.last_logfile_size=160773
     property.archive_file=backup-userRoot-20090929184101Z
     
     backup_id=20091029184509Z
     backup_date=20091029184512Z
     incremental=false
     compressed=false
     encrypted=false
     property.last_logfile_name=00000000.jdb
     property.last_logfile_size=160773
     property.archive_file=backup-userRoot-20091029184509Z

For Windows systems, use an appropriate text editor.

Skip Navigation Links
Exit Print View
	Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1)