Conduct periodic tests of backup and recovery processes.
389-BR-001 - severity: high
| Field | Value |
|---|---|
| Control ID | 389-BR-001 |
| Severity | high |
| Type | corrective |
| Owner | IT Operations |
| Status | authored |
| NIST 800-53 | CP-9, CP-10 |
| DISA SRG | SRG-APP-000516 |
Rationale¶
A backup that has never been restored is an assumption, not a recovery capability. Data, schema, or procedural problems - truncated archive files, missing schema elements, an obsolete restore procedure, missing encryption keys - will only be discovered at the worst possible moment: mid-incident, under pressure, when the directory is unavailable and dependent services are failing. Periodic restore tests exercise the full recovery path in a safe environment, confirm that backup archives are structurally sound and complete, prove that the restore procedure is understood and executable by on-call staff, and surface gaps while there is still time to correct them. A test failure in staging costs an hour; the same failure during an actual outage costs the full recovery window plus cascading service downtime. NIST SP 800-53 CP-9 requires protecting information system backup and CP-10 requires information system recovery and reconstitution - neither can be relied upon without evidence of a successful restore test.
Check¶
Confirm a recent restore test was performed and backups exist.
ls -lt /var/lib/dirsrv/slapd-<instance>/bak/
# confirm the date of the last documented restore test
Remediation¶
Periodically restore a backup into a staging instance to prove recoverability.
dsconf <staging-instance> backup restore /var/lib/dirsrv/slapd-<instance>/bak/<backup-archive>
# record the test date and outcome
References¶
Implementation Notes¶
Always restore into a staging instance, never into production; restoring over a live instance will overwrite current data.
There is no backup list subcommand in dsconf - inventory available backups
by listing the backup directory (/var/lib/dirsrv/slapd-<instance>/bak/) directly.
Each backup archive is a timestamped subdirectory within that path.
After a successful staging restore, verify that a representative sample of entries, attributes, and ACIs are present and that the instance starts cleanly. Record the test date, backup archive used, the staging host, and the outcome in your change/operations log. Complement restore testing with checksum verification (389-BR-003) and offsite storage (389-BR-002) to complete the backup assurance lifecycle.