Run this quarterly on the backup job. Its counterpart,
linux-checklist-restore-readiness, runs on the restore.
Both are needed: a job that runs perfectly and captures no
ownership metadata produces archives that restore into an
outage.
How to use this checklist
Run it once a quarter, against the backup job as it exists today rather than as it was designed. The commands assume BorgBackup; the equivalents for restic, bacula or a hosted agent differ in syntax and not in intent, so substitute the command and keep the assertion.
Two of the items cannot be closed from the backup host at all.
key-escrow-tested requires opening the repository with the
escrowed key copy from somewhere else, and restore-linkage
is closed by the restore readiness checklist. If you find
yourself marking either one green from a terminal on the
protected host, you have not tested what the item asks about.
A failure here is not “the backup is broken” - the job may be
running perfectly. It means the archives it produces will not
carry you through the incident they exist for. Treat a red
critical as a change that has to be made before the next
quarter, and record the reasoning where the next person
reviewing this will find it.
File the command output with the quarter’s record. The value
of this checklist compounds: four quarters of borg info
output is a capacity trend, and four quarters of verification
timestamps is the only evidence that the schedule held.
Sign-off
- Operator: _________________ Date: ___________
- Reviewer: ________________ Date: ___________
- Last verified restore: __________