Introduction

There are two supported methods of backing up an OpenLDAP database:

1.  via the slapcat utility which produces a complete human-readable LDIF copy of the database, or
2.  via the mdb_copy utility that produces a binary copy of the LMDB database.

With slapcat:

• The backup is a full snapshot of the database that includes critical operational attributes
• The format of the backup file, LDIF, is automatically compatible with the slapadd utility that is used to restore databases.
• The backup is portable with both servers and OpenLDAP backend databases (MDB, BDB, HDB, etc.)
• Partial copies/dumps of the database may be made (see below).
• slapcat may be used while slapd is running.

With mdb_copy:

• The backup takes much less time because OpenLDAP need not convert the data to human-readable form,
• The restore process is a matter of seconds compared to restoring with slapadd.
• There is an option (-c) to compact the database, which creates a smaller database file more suitable for transferring over a network during restore operations. Note: using compaction with mdb_copy takes longer to complete.
• mdb_copy may be used while slapd is running.

Backups should not be taken using the ldapsearch utility for several reasons:

• The LDIF it creates may not be compatible with the slapadd utility
• Extracting the database is slower than using slapcat.
• Some critical operational attributes may be left out, making restoration impossible
• Add/modify timestamps may not be preserved
• The values of dynamic attributes, which don't actually exist in a database, could be written to the LDIF. If these values are present, restoration may not be possible.

Additionally, backups should not be taken by directly copying the database files or database directory in the filesystem. This can lead to instability and/or make the backup impossible to recover.

Backup and Restore With mdb_copy

Backing up using mdb_copy

Normal use of the mdb_copy command requires two parameters: the path of the directory in which the mdb data is stored (the value of the ‘directory’ setting in slapd.conf or the value of 'olcDbDirectory' in cn=config) and the path of a directory to write the backup file to. The backup file created will be /<destination-directory>/data.mdb  

The general format of the mdb_copy command is:

mdb_copy [-c] <mdb-database-directory> <backup-destination-directory>

The following example uses compaction:

# Create the destination directory:
mkdir /tmp/backups/mdb-backup

# Run the mdb_copy command:
mdb_copy -c /var/symas/openldap-data/ /tmp/backups/mdb-backup/

The command will result with the file /tmp/backups/mdb-backup/data.mdb. 

If you prefer to create the backup file with a custom name, you can omit the destination directory in the mdb_copy command. This will cause mdb_copy to output to stdout which can be redirected to a file:

mdb_copy -c /var/symas/openldap-data/ > backup-file-name.mdb

Restoring the Database From an mdb_copy Output File

Restoring the database is easy. You remove all of the data from the database directory. If you are using accesslog, the data in the accesslog directory is removed as well. Accesslog is re-initialized as the server starts up … it notices that accesslog is empty and takes care of it.

Note: The lock.mdb file in the database directory does not need to be copied or deleted.

Then the file produced by mdb_copy is copied back into the database directory. Then the server can be brought online. The restored server will then be busy for a while as it takes replication updates, catching up with the cluster.

# 1. Stop slapd
systemctl stop slapd

# 2a. Move the current database file to a different directory. 
#     Retain this copy in case the restore fails.
mv /var/symas/openldap-data/example/data.mdb /path/to/recovery/backup

# 2b. If the system uses delta-syncrepl for replication, remove the cn=accesslog
#     database file.

# 3. Copy the recovery database file to the database directory.
#    Rename the file to 'data.mdb' if the recovery database file is different.
cp /path/to/backup/data.mdb /var/symas/openldap-data/example/data.mdb

# 4. Start slapd
systemctl start slapd

Creating an LDIF File From an mdb_copy Backup

One concern about using mdb_copy for backups is that you don't have the full LDIF for reference and diagnosis of problems. The slapcat utility can produce the LDIF if needed. The easy way is to copy onto a test machine and slapcat from there.

slapcat Backups

Single Backend Database

If your OpenLDAP server uses only one backend database, backups are very straightforward:

Single Backend Backup

/opt/symas/sbin/slapcat -b <rootdn> -l backupName.ldif

This executes the slapcat command and writes the output to the file backupName.ldif.

Multiple Backend Databases

The slapcat utility can back up only one database suffix at a time. if your OpenLDAP server uses more than one database, you will need to run slapcat once for each suffix, specifying each suffix.

Multiple Backend Backups

/opt/symas/sbin/slapcat -b "dc=example,dc=com" -l dc-example_dc=com_Backup.ldif
/opt/symas/sbin/slapcat -b "dc=demo,dc=com" -l dc-demo_dc=com_Backup.ldif

Backing up the Configuration Database (cn=config)

The cn=config database is the database that contains the configuration for the OpenLDAP server. To backup the cn=config database, simply specify the database number as 0.

Configuration Database Backup

/opt/symas/sbin/slapcat -F /opt/symas/etc/openldap/slapd.d -n 0 -l cn-config_Backup.ldif