restic-backup: §7 becomes a scripted, repeatable restore drill

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Julien Lutran
2026-08-28 18:42:58 +02:00
co-authored by Claude Fable 5
parent 6ab143c856
commit 0481f162ee
+15 -4
View File
@@ -248,15 +248,26 @@ freshness reasoning as before.
One shared repo would dedup the Ubuntu base across all replicas. Restore granularity: per-file; instance definitions ride
the dump tree (`incus/<inst>.yaml` + `incus-global-db.sql`).
## 7. Restore test (gate)
## 7. Restore drill (gate, then quarterly)
Per repo, one restore + diff (never to `/tmp` — 16 GiB tmpfs):
Scripted — [`restic-restore-test.sh`](https://git.lutran.fr/julien/scripts/src/branch/main/restic-restore-test.sh):
```sh
restic -r s3:…/restic-data restore latest --target /backup/restore-test --include '<subtree>'
diff -r … && rm -rf /backup/restore-test
/root/scripts/restic-restore-test.sh # tree + dump, ~2 min
/root/scripts/restic-restore-test.sh -d # also loads the dump into a
# throwaway container (strongest)
```
It restores a filesystem tree from the latest snapshot and diffs it
against the live one, restores a database dump and checks it is
well-formed (`CREATE TABLE` count + `Dump completed` marker), then
cleans up (`-k` keeps the files, `-w` changes the work dir). Never
restore into `/tmp` — it is a 16 GiB tmpfs on ks4; the script writes
under `/backup`.
A backup leg that has never been restored from is a hypothesis, not a
backup: run this at the cutover gate and once a quarter after.
## 8. Cutover (done) + what is left
Legacy on the box: plakar is still installed and its `plakar-data`