Regularly backup 389DS configuration and data.

389-CM-004 - severity: high

Field	Value
Control ID	`389-CM-004`
Severity	high
Type	corrective
Owner	IT Operations
Status	authored
NIST 800-53	CP-9
DISA SRG	SRG-APP-000516

Rationale¶

Without regular, tested backups, any corruption of dse.ldif, a failed upgrade, or an erroneous bulk modification becomes an unrecoverable event, risking permanent loss of the directory database and all configuration. Because 389DS serves as the identity authority for dependent applications, an unrecoverable directory outage cascades into a full loss of authentication and authorization across the environment. dsconf backup create produces a consistent, hot backup of both the database files and the instance configuration, allowing point-in-time recovery without taking the server offline. Backups are a foundational prerequisite for the broader recovery controls in this checklist - 389-BR-001 (restore testing) and 389-BR-002 (offsite storage) provide no value unless backups are being taken consistently. This control satisfies NIST SP 800-53 CP-9 (Information System Backup), and is assessed by DISA SRG-APP-000516.

Check¶

Confirm that recent backups exist in the instance backup directory.

ls -lt /var/lib/dirsrv/slapd-<instance>/bak/

Remediation¶

Create a backup immediately and schedule recurring backups via a systemd timer or cron job.

dsconf <instance> backup create
# Schedule recurring backups - for example, a daily cron entry:
#   0 2 * * * dsconf <instance> backup create
# or a systemd timer that runs the same command on a defined cadence.

References¶

Red Hat Directory Server Administration Guide

Implementation Notes¶

dsconf <instance> backup create writes the archive to /var/lib/dirsrv/slapd-<instance>/bak/ by default; an explicit destination path can be appended as a positional argument. There is no backup list subcommand - to audit backup currency, inspect the backup directory directly (e.g., with ls -lt). Backup frequency should reflect your recovery-point objective (RPO): daily is a common baseline for production LDAP. Archives should be transferred offsite or to object storage promptly and encrypted at rest (see 389-BR-002). Restore procedures should be tested periodically using dsconf <instance> backup restore <archive> in a non-production environment (see 389-BR-001). Old archives should be pruned on a defined retention schedule to avoid exhausting disk space in the backup directory.