Chapter 6 — Backups and restore

Design the backup before the tool

A backup minimum that actually supports recovery: identify critical data/configuration, owner, recovery point objective (acceptable data loss), recovery time objective (acceptable outage), retention, encryption/key custody, and restore dependencies. Keep at least one copy off the host, separate administrative credentials from production, and use offline/immutable or otherwise deletion-resistant copies where the risk warrants it (restic docs; NIST SP 800-61r3). These are baseline recommendations synthesized from the need for actual recovery — not a claim that one exact copy count fits every workload, and not a compliance standard. Note also that the sources checked do not settle a universal "3-2-1" formulation; publish any such rule as an organizational choice, not a Linux requirement.

RAID is not backup (Chapter 5); encryption is not backup (Chapter 5, LUKS). A green backup job is not a restore capability.

restic: verify repositories, rehearse restores

Restic's model gives precise verification and restore tooling (restic repository checks; restic restore):

# [READ-ONLY] confirm snapshots and expected paths exist
restic snapshots
restic ls SNAPSHOT_ID

# [READ-ONLY] repository structure check (fast)
restic check
# [READ-ONLY, slow] additionally reads pack data — all of it, or a subset
restic check --read-data
restic check --read-data-subset=5%

restic check validates repository structure; --read-data additionally reads all pack data (more time/bandwidth); --read-data-subset spreads data checks over subsets. A sensible baseline combines frequent snapshot checks, periodic sampled/full repository-data verification appropriate to repository size, and actual restore exercises — a repository check is not a substitute for a restore test (restic checks).

HIGH-RISK · MUTATING — restore with deletion or in-place overwrite. Restic restore overwrites existing destination files by default, and --delete removes target files absent from the selected snapshot; restic explicitly advises previewing with --dry-run -vv (restic restore). In-place restore can leave partial state if interrupted; back up current state first and rehearse to an alternate path. Preflight: verify snapshot ID, host/path filters, target mount, include/exclude set, free space, ownership, application consistency. Rollback: the pre-restore backup. Success check: ownership/mode/content verified; application starts on the restored data.

A safe restore drill restores selected files to a new, isolated target, checks ownership/mode/content and application-level usability, and records elapsed restore time. Restic supports a restore dry run and selective includes. Periodically test a full-machine or alternate-host recovery when bare-metal recovery is part of the requirement. Make recovery tests measurable and repeatable: record restore date, snapshot, target, recovered item count, application checks, elapsed time, failures, and corrective actions — that turns a backup assertion into operational evidence and allows comparison with the declared RPO/RTO (restic restore; NIST SP 800-61r3).

Application-aware backups deserve application-native tools: the notes' guidance is to pair file-level backups with, for example, database-native consistent dumps plus a restore/import test (restic docs). (This edition does not prescribe database-specific dump procedures — see the source index.)