Now that our 389ds instance is fully configured and ready to go, let’s have a look at how to back it up and potentially restore it if a disaster occurs.
6. Creating a backup
To create a complete backup that allows us to restore the 389ds instance from scratch we need to take care about two things: Firstly, the directory server database, where all the information that makes up the DIT is stored. And secondly, the configuration directory /etc/dirsrv/slapd-INSTANCENAME/ where additional files (such as certificates, keys and the Root Directory Server Agent Service Entry (RootDSE) ldif file) are saved.
The integrated backup mechanism of the 389 Directory Server takes care of the database:
# dsconf localhost backup create The backup create task has finished successfully
instructs dsconf to create a database dump in /var/lib/dirsrv/slapd-localhost/bak/.
To create a backup of the configuration directory we can simply tar it up:
tar caf config_slapd-localhost_$(date +%Y-%m-%d_%H-%M-%S).tar.gz /etc/dirsrv/slapd-localhost/
7. Restoring a backup
7.1. Creating a 389ds instance from scratch
If disaster struck and we have to create a new 389ds instance from scratch we can use an inf answer file just like we did in part 1:
[general] full_machine_name = ldap.example.com start = False [slapd] instance_name = localhost root_password = mysecret port = 389 secure_port = 636 self_sign_cert = False [backend-userroot] sample_entries = yes suffix = dc=example,dc=com
The only difference is that we don’t want our instance to immediately start. Instead we’re going to restore the configuration directory and database first. Of course, you could also stop the instance manually after creation:
dscreate from-file instance.inf rm -rf /etc/dirsrv/slapd-localhost/* tar xvf config_slapd-localhost_2021-05-14_10-00-00.tar.gz -C /
This takes care of the configuration directory.
The database can be restored through dsctl.
# cp -a localhost-2021_05_14_10_00_00 /var/lib/dirsrv/slapd-localhost/bak/ # dsctl localhost bak2db localhost-2021_05_14_10_00_00 bak2db successful
One small caveat: The directory from which the database is restored has to reside in /var/lib/dirsrv/slapd-INSTANCENAME/bak/, otherwise dsctl will fail with the somewhat unhelpful error message bak2db failed.
We can now start our successfully restored 389ds instance:
systemctl start dirsrv@localhost.service
7.2. Only restoring the database while server is running
If you only want to restore the database (maybe because an object in the DIT was accidentally deleted) we don’t have to stop the server:
dsconf localhost backup restore localhost-2021_05_14_10_00_00
As before, the directory form which the database is restored has to reside in /var/lib/dirsrv/slapd-INSTANCENAME/bak/.
There’s a lot more information on how to create and restore backups in the RHDS11 documentation but this should cover the basics.