S 6.150 Data backup when using OpenLDAP

Initiation responsibility: Head of IT, Specialists Responsible

Implementation responsibility: Administrator

The data of the OpenLDAP server must be backed up regularly. The data backups constitute an important prerequisite to correct occurred errors and to be able to re-install deleted data.

Comprehensive data backup

Often, data backups only comprise the data used. For OpenLDAP, this includes the objects in the directory. In order to guarantee actual continued and/or re-operation, the configuration files must be backed up additionally. Depending on how the configuration is conducted (see S 4.384 Secure configuration of OpenLDAP), this either means that the "slapd.conf" configuration files must be backed up or the "CN=config" suffix in the case of online configuration. Furthermore, the generated backup must not remain on the same system from a physical point of view, because it possibly is not available in case the IT system fails (see also S 6.20 Appropriate storage of backup data media).

Data backup for databases

The tried and tested method for backing up OpenLDAP is using the slap* tool called slapcat in order to generate a data export file in the LDIF format while the slapd server is stopped. The generated export file can be packed before being saved, because the clear text structure of the LDIF files generates unnecessarily large files.

If the data of the directory service is exported by means of slapcat while the slapd server is running, this may cause inconsistent data backups if the data is changed during the export process. It is also possible to switch the databases to be backed up to a read-only condition. However, it must be observed that the server is not available for write accesses in this case and that the online configuration cannot be saved this way. The "CN=config" suffix can also be switched to a read-only condition, but it cannot be released from this condition without restart. Therefore, consistent and complete backup is only possible with the slapd server being stopped as a matter of principle.

Restoration

The slapadd tool should always be used for restoring the databases. In general, the ldapadd tool or a suitable client application is also able to insert objects from LDIF files into a directory service. However, this entails several disadvantages:

• the slapcat tool creates the LDIF export according to the physical sequence of the objects in the database. If ldapadd or similar client applications are used to insert this file into a directory service, it may be possible that objects cannot be created if the superior objects have not yet been read in (because these were only stored in the secured database after the subordinate objects from a physical point of view).
• client applications such as ldapadd communicate with the running slapd server using a current, preferably encrypted network connection. The initial import of a data backup in the above-described manner requires an unnecessarily large amount of time, bandwidth, and resources.
• the import using ldapadd or other client applications requires a running slapd server writing access is granted to. There is the risk that other clients already access incomplete data during the import or that objects still in a conflict with data records to be restored are created or changed.

Saving a replica in the event of high availability requirements

If there are availability requirements for the slapd server not allowing for interrupting server operation (downtime) or for restricting to read-only accesses for the backup period, backup by means of a replica (see S 4.newly18 Partitioning and replication in OpenLDAP) is a good alternative. For this, the procedure described above must be applied to a consumer. The provider is continuously available while the consumer is stopped. Upon completion of the data backup, all changes made to the provider in the meantime are automatically copied to the consumer when the slapd server is restarted on the consumer using the "syncrepl" mechanism. Differences in a backed up configuration between provider and consumer must be observed.

Further application options

The data backup described here is also well suited for filling a directory service replica initially (see S 4.389 Partitioning and replication in OpenLDAP), updating OpenLDAP (see S 4.390 Secure updating of OpenLDAP), or supporting the migration to another directory service. However, these cases must be handled with care if the configuration is loaded into a directory service as part of a directory tree. For example, a non-adapted transmission of the configuration of a provider would create an identical provider (instead of a consumer), which would cause network problems due to two providers being inconsistent within a very short time.

Review questions:

• Is the data of the OpenLDAP server, including the directory service objects and configuration settings, backed up regularly?
• Are all partitions of the OpenLDAP server included in the data backup?
• Is the data only restored with the help of suitable tools in the event of a loss of data?