Learn LDAP - Backup & Restore

#Introduction

Episode 24 deals with what nobody wants to happen but everybody must prepare for: data loss. A directory that holds every password, name, and group membership is a single point of failure if it's lost. You'll learn the slapcat/slapadd export/import cycle, backing up the mdb database files directly, and a disaster recovery plan that includes replication.

#Backup Principles

Backup for LDAP follows the same principles as for any database, with LDAP-specific details:

• Back up the database, not just the data — configuration (cn=config) is as critical as user data; losing it means losing ACLs, overlays, and replication settings.
• Consistency — the backup must represent a single point in time; an inconsistent copy (half of an update) can break replication.
• Backup frequency — depends on the rate of change; an employee directory changes daily, an authentication directory changes every bind.
• Multiple copies — the "3-2-1 rule": three copies, two media types, one off-site.
• Periodic restores — a backup that was never restored is not a backup; test restores on a regular schedule.

#slapcat: LDIF Export

The classic tool is slapcat, which dumps the entire database — including operational attributes like entryUUID, contextCSN, and pwdChangedTime that ldapsearch filters out by default.

slapcat -b dc=example,dc=com -l /backup/ldap-data.ldif
slapcat -b cn=config -l /backup/ldap-config.ldif

Run slapcat as the openldap user (or root, but fix ownership afterward) so file permissions stay sane. The result is a full, consistent snapshot — not just the visible data.

#slapadd: LDIF Import

slapadd is the offline importer, used with slapd stopped. The user data restore:

sudo systemctl stop slapd
sudo -u openldap slapadd -l /backup/ldap-data.ldif
sudo systemctl start slapd

Make sure slapd is stopped and the destination database is empty (or use -c to skip existing entries). After starting, verify the count:

ldapsearch -x -H ldap://ldap.example.com -b dc=example,dc=com dn | wc -l
getent passwd budi

#Backing Up the mdb Files

The database itself is a file (or set of files) on disk. Under olcDbDirectory — typically /var/lib/ldap on Debian and Ubuntu — data.mdb is the main store. Two ways to back it up:

1. Copy the files — stop slapd (or use a consistent snapshot) then copy data.mdb and lock.mdb. The copy must be consistent — mdb is a copy-on-write B-tree, so an online copy is usually safe, but a stopped server is always safest.
2. LDIF dump (recommended) — slapcat produces a portable, version-independent format that survives an OpenLDAP upgrade; files copied between versions may not.

sudo systemctl stop slapd
sudo tar czf /backup/ldap-mdb.tar.gz /var/lib/ldap
sudo systemctl start slapd

The LDIF method is the recommended primary backup because it's human-readable, diff-able, and upgrade-safe; the file copy is a fast emergency snapshot.

#Backup Script and Automation

Automate with cron. A minimal script:

#!/bin/bash
set -euo pipefail
STAMP=$(date +%Y%m%d-%H%M)
sudo -u openldap slapcat -b dc=example,dc=com -l "/backup/ldap-data-$STAMP.ldif"
sudo -u openldap slapcat -b cn=config -l "/backup/ldap-config-$STAMP.ldif"
find /backup -name '*.ldif' -mtime +30 -delete

15 2 * * * /usr/local/sbin/backup-ldap.sh

Then test the restore at least once a month in a staging instance — this catches the errors that turn a "backup" into a false sense of security.

#Replication as a Backup Layer

Replication from episode 13 is availability, not a substitute for backup:

• It protects against server failure — a consumer holds a copy of the data and can serve searches.
• It does NOT protect against logical errors — a slapcat mis-typed delete, an ACL mistake, or an LDAP injection propagates to every node instantly.
• The combination — replication for uptime, scheduled slapcat for recovery, and periodic restore testing for confidence.

A deleted entry propagates to all replicas within seconds of the refreshAndPersist push. Only the scheduled backup holds the pre-delete state.

#Disaster Recovery Plan

A minimal DR plan:

1. RPO (Recovery Point Objective) — how much data loss is acceptable: e.g. one day if the backup runs nightly.
2. RTO (Recovery Time Objective) — how long until service is restored: e.g. one hour to restore from LDIF.
3. Restore procedure — the exact commands from above, written down and rehearsed.
4. Configuration restore — backup cn=config separately; test a config-only recovery.
5. Infrastructure restore — reinstalling the OS and packages, then the data; the LDIF survives a full reinstall.
6. Security of backups — the backup holds all passwords (even if hashed); encrypt it and protect it like the live system.

sudo apt install slapd ldap-utils
sudo systemctl stop slapd
sudo -u openldap slapadd -l /backup/ldap-config.ldif
sudo -u openldap slapadd -l /backup/ldap-data.ldif
sudo systemctl start slapd

#Closing

In this episode 24 you understood LDAP backup and restore: the principles of consistency and the 3-2-1 rule; slapcat for full LDIF export including operational attributes; slapadd for offline import; backing up the mdb database files; automation with cron; the role of replication as availability rather than backup; and a complete DR plan with RPO and RTO.

Key takeaways:

• LDIF is the primary backup — portable, readable, version-safe; files are the fast snapshot.
• Back up cn=config too — losing ACLs and overlays is as bad as losing data.
• Replication is not backup — logical errors replicate too.
• Restore testing is mandatory — an untested backup is an assumption.

In the next episode, episode 25, we optimize what you've built: performance tuning — mdb database tuning, index tuning, and operating system and connection limits for high-load directories.