Regularly verify backup integrity and completeness.
389-BR-003 - severity: high
| Field | Value |
|---|---|
| Control ID | 389-BR-003 |
| Severity | high |
| Type | corrective |
| Owner | IT Operations |
| Status | authored |
| NIST 800-53 | CP-9, CP-9(1) |
| DISA SRG | SRG-APP-000516 |
Rationale¶
Silent backup corruption - from storage hardware faults, filesystem errors, incomplete writes, or ransomware that encrypts backup files without deleting them - renders a backup unrestorable without any visible warning. The failure is discovered only during a recovery attempt, at exactly the moment when time and availability are most critical. A cryptographic checksum generated immediately after the backup completes and re-verified at regular intervals detects bit-rot, truncation, and unauthorised modification before a recovery attempt is made under pressure. Checksums catch structural corruption but cannot prove completeness - an archive can pass a checksum check and still be missing entries or schema elements. Only a trial restore (389-BR-001) proves completeness; together, checksums and restore tests form a complete integrity assurance posture. NIST SP 800-53 CP-9 requires protecting the integrity of backup information, and CP-9(1) specifically requires testing backup information to verify media reliability and information integrity.
Check¶
Verify backup integrity via checksums.
sha256sum -c /var/lib/dirsrv/slapd-<instance>/bak/<backup-archive>.sha256
Remediation¶
Generate and verify checksums for each backup, and confirm completeness with a trial restore.
# After each backup, record a checksum and verify it:
sha256sum /var/lib/dirsrv/slapd-<instance>/bak/<backup-archive> > /var/lib/dirsrv/slapd-<instance>/bak/<backup-archive>.sha256
sha256sum -c /var/lib/dirsrv/slapd-<instance>/bak/<backup-archive>.sha256
# periodically confirm completeness with a trial restore (389-BR-001)
References¶
Implementation Notes¶
Generate the SHA-256 checksum immediately after dsconf <instance> backup create
completes, while the archive is still locally cached and provably unmodified.
Replace <backup-archive> with the actual archive subdirectory name found under
/var/lib/dirsrv/slapd-<instance>/bak/; there is no backup list subcommand -
list the directory directly.
Store checksums separately from the data they verify. A checksum file co-located with a corrupted or ransomware-encrypted archive has no protective value. Copy checksum files to a separate path, offsite store, or append-only log alongside the offsite replication in 389-BR-002.
Schedule checksum verification as a cron job that runs independently of the backup schedule (e.g., daily) so that corruption introduced after the backup is detected promptly. Integrity checks are a complement to, not a replacement for, periodic restore tests (389-BR-001).