OpenLDAP

New in version 2.1.8 To backup OpenLDAP with borgmatic, use the openldap_databases: hook. For example:

openldap_databases:
    - name: dc=example,dc=com

borgmatic dumps each configured database with slapcat and restores it with slapadd. Both commands read and write the local slapd databases directly rather than connecting over the network, so borgmatic has to run on the LDAP server itself—and with enough permission to read those databases, which usually means running as root.

Suffixes instead of database names

Unlike the other database hooks, the name option here is an LDAP suffix (base DN) rather than a database name, because that's how slapcat and slapadd select a database with their -b flag. So list each suffix you want to backup:

openldap_databases:
    - name: dc=example,dc=com
    - name: dc=other,dc=example,dc=com

This hook also doesn't accept a name of all. slapcat without a -b flag dumps only the first configured database instead of every one of them, so there's nothing sensible for borgmatic to map all onto. Giving a database the name all is a validation error, so borgmatic rejects it up front rather than partway through a backup.

The slapd configuration database

slapcat and slapadd both need the local slapd configuration in order to run, which means a dump of your data alone isn't enough to restore from. To back up that configuration, add its suffix alongside your data suffixes:

openldap_databases:
    - name: cn=config
    - name: dc=example,dc=com

cn=config gets dumped and restored just like any other suffix. When restoring, restore cn=config first and in its own borgmatic run, so that the configuration for your data databases is in place before you load them:

borgmatic restore --archive latest --database cn=config
borgmatic restore --archive latest --database dc=example,dc=com

Dumping cn=config covers everything in the slapd.d configuration directory, schema included. It doesn't cover files that your configuration merely points to, like TLS certificates and keys, so back those up with source_directories.

And if your slapd still reads a legacy slapd.conf file instead of a slapd.d directory, then there's no configuration database to dump—slapcat -b cn=config just errors with "could not open database". In that case, back up slapd.conf itself with source_directories.

Restoring

slapadd refuses to add entries that already exist, so before you restore, stop slapd and empty the directory for the database you're restoring. borgmatic doesn't stop slapd or clear those directories for you, since it may not be responsible for every database living there.

Which directory that is depends on the suffix: your data databases live somewhere like /var/lib/ldap, while cn=config lives in the slapd.d configuration directory—/etc/ldap/slapd.d on Debian or /etc/openldap/slapd.d on Red Hat.

slapadd also writes its files as the user that runs it—root, typically—while slapd runs as an unprivileged user like openldap on Debian or ldap on Red Hat. If those don't match on your system, slapd won't be able to read what you just restored, so change the ownership of the directory afterwards.

Here's an example of the sort of configuration that may help on some distributions—adjust the paths and the user to match yours:

commands:
    - before: action
      when: [restore]
      run:
          - systemctl stop slapd
    - after: action
      when: [restore]
      run:
          - chown -R openldap:openldap /var/lib/ldap
          - chown -R openldap:openldap /etc/ldap/slapd.d
          - systemctl start slapd

The "after" hook deliberately has no states option, so it runs whether or not the restore succeeds. Otherwise a failed slapadd would leave slapd stopped.

These hooks run on every restore run, so if you're restoring cn=config and your data in separate runs as described above, slapd gets stopped and started around each of them.

Full configuration

Here's an example configuration with all of the available options for this feature in the most recent version of borgmatic. If you're using an older version, some of these options may not work, and you should instead generate a sample configuration file specific to your borgmatic version.

# List of one or more OpenLDAP databases to dump before creating a
# backup, run once per configuration file. The database dumps are
# added to your source directories at runtime and streamed directly to
# Borg. Requires the slapcat and slapadd commands, which read the
# local slapd databases directly instead of connecting over the
# network—so borgmatic must run on the LDAP server itself and with
# sufficient permissions to read those databases. See
# https://www.openldap.org/software/man.cgi?query=slapcat and
# https://www.openldap.org/software/man.cgi?query=slapadd for details.
openldap_databases:
    # The suffix (base DN) of the database to dump, given to
    # slapcat's "-b" flag. Use "cn=config" to dump the slapd
    # configuration database. Unlike the other database hooks,
    # "all" is not accepted here, as slapcat without a suffix
    # dumps only the first configured database rather than
    # every one of them. Note that using this database hook
    # implicitly enables read_special (see above) to support
    # dump and restore streaming.
    - name: dc=example,dc=com

      # Label to identify the database dump in the backup.
      label: my_backup_label

      # Command to use instead of "slapcat". This can be used to
      # run slapcat from a non-standard path or with additional
      # flags. Defaults to "slapcat".
      slapcat_command: /usr/sbin/slapcat

      # Command to run when restoring a database instead of
      # "slapadd". Defaults to "slapadd".
      slapadd_command: /usr/sbin/slapadd

Related documentation

• How to backup your databases