Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

6.4. Restoring Directory Server

In certain situations, administrators want to restore Directory Server, for example, after a hardware failure. This section describes the supported restore methods.

Note

Directory Server does not support restoring individual databases.
Directory Server runs the restore operation as the dirsrv user. Therefore, the permissions of the directory containing the backup must allow this user to read the files.

6.4.1. Restoring All Databases Using the Command Line

Directory Server supports restoring databases while the instance is running or while the instance is offline:

6.4.1.1. Restoring All Databases While the Server is Running

6.4.1.1.1. Restoring All Databases Using the dsconf backup restore Command
Use the dsconf backup restore command to automatically create a task that restores up all databases from a backup directory.
For example, to restore the backup stored in the /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/ directory: 
# dsconf -D "cn=Directory Manager" ldap://server.example.com backup restore /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/
The backup restore task has finished successfully
6.4.1.1.2. Restoring all Databases Using a cn=tasks entry
The cn=tasks,cn=config entry in the Directory Server configuration is a container entry for temporary entries the server uses to manage tasks. To initiate a restore operation, create a task in the cn=restore,cn=tasks,cn=config entry.

Warning

Using a restore task overrides all data in the instance.
A restore task entry requires the following attributes:
  • cn: Sets the unique name of the task.
  • nsArchiveDir: Sets the path to the directory that contains the backup.
  • nsDatabaseType: Sets the type of the database to restore. Directory Server supports only the ldbm database value in this attribute.
For example, to add a task that restores all databases from the backup stored in the /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/ directory: 
# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x

dn: cn=example_restore,cn=import,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example_restore
nsArchiveDir: /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/
nsDatabaseType: ldbm database
When the task is completed, the entry is removed from the directory configuration.

6.4.1.2. Restoring all Databases While the Server is Offline

If the server is offline when you restore databases, use the dsctl bak2db command:
  1. Stop the instance: 
    # dsctl instance_name stop
  2. Restore the databases. For example, to add a task that restores all databases from the backup stored in the /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/ directory: 
    # dsctl instance_name bak2db /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/
bak2db successful

    Note

    The dsctl bak2db command runs as the restore as the dirsrv user. Therefore, the permissions of the source directory must allow this user to read files and directories.
  3. Start the instance: 
    # dsctl instance_name start

6.4.2. Restoring All Databases Using the Web Console

To restore all database using the web console:
  1. Open the Directory Server user interface in the web console. See Section 1.4, “Logging Into Directory Server Using the Web Console”.
  2. Select the instance.
  3. Click the Actions button, and select Manage Backups.
    The displayed window lists the available backups in the /var/lib/dirsrv/slapd-instance_name/bak/ directory.
  4. Open the Actions menu next to the backup you want to restore, and select Restore Backup.
  5. Click Yes to confirm.

6.4.3. Restoring Databases That Include Replicated Entries

Several situations can occur when a supplier server is restored:
  • The consumer servers are also restored.
    For the very unlikely situation, that all databases are restored from backups taken at exactly the same time (so that the data are in sync), the consumers remain synchronized with the supplier, and it is not necessary to do anything else. Replication resumes without interruption.
  • Only the supplier is restored.
    If only the supplier is restored or if the consumers are restored from backups taken at a different times, reinitialize the consumers for the supplier to update the data in the database. If only the supplier is restored or if the consumers are restored from backups taken at a different times, reinitialize the consumers for the supplier to update the data in the database.
  • Changelog entries have not yet expired on the supplier server.
    If the supplier's changelog has not expired since the database backup was taken, then restore the local consumer and continue with normal operations. This situation occurs only if the backup was taken within a period of time that is shorter than the value set for the maximum changelog age attribute, nsslapd-changelogmaxage, in the cn=changelog5,cn=config entry. For more information about this option, see the Red Hat Directory Server Configuration, Command, and File Reference.
    Directory Server automatically detects the compatibility between the replica and its changelog. If a mismatch is detected, the server removes the old changelog file and creates a new, empty one.
  • Changelog entries have expired on the supplier server since the time of the local backup.
    If changelog entries have expired, reinitialize the consumer. For more information on reinitializing consumers, see Section 15.8.3, “Initializing a Consumer”.

Example 6.3. Restoring a Directory Server Replication Topology

For example, to restore all servers in a replication environment, consisting of two suppliers and two consumer server:
  1. Restore the first supplier. Use the dsconf backend import command to import the data. See Section 6.1.2, “Importing Using the Command Line”.
  2. Online-initialize the remaining servers by using replication:
    1. Initialize the second supplier from the first one.
    2. Initialize the consumers from the supplier.
    For details, see Section 15.8.3, “Initializing a Consumer”.
  3. On each server, display the replication status to verify that replication works correctly. For details, see Section 15.22, “Displaying the Status of a Specific Replication Agreement”.
The changelog associated with the restored database will be erased during the restore operation. A message will be logged to the supplier servers' log files indicating that reinitialization is required.
For information on managing replication, see Chapter 15, Managing Replication.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.