09-02 · Backups & disaster recovery
Doel: data- of toolverlies zet het bureau niet stil. Extra relevant door de eigen AI-tooling (VPS-fleet, dashboards, repo's) — die is maatwerk en niet zomaar te herbouwen.
Waarom
Een verloren repo, een dode VPS of een gewiste database kost dagen tot weken. Een geteste backup + herstelroute maakt het een incident van uren.
Wat wordt geborgd (inventaris)
| Bron | Waar | Backup-methode | Frequentie | Hersteltest |
|---|---|---|---|---|
| Code / repo's | GitHub | remote + lokale clones | continu | clone-test |
| Klantdata / dashboards (D1/Supabase/Turso) | Cloudflare/Supabase | export/replica | … | restore-test |
| VPS-fleet (agents, crons) | KVM-hosts | config-in-git + snapshot | … | rebuild-test |
| Credential-kluis | password manager | kluis-eigen export/emergency-kit | … | zie 09-01 |
SOP
- 3-2-1 als richtlijn. Minstens drie kopieën, twee media, één off-site.
- Config-as-code. Alles wat een agent/VPS draaiend houdt staat in git, zodat een host herbouwbaar is (verwijs VPS-blauwdruk).
- Verificatie (AI-kans). Monitor of backups vers zijn; alert bij een backup ouder dan
de afgesproken drempel (er bestaat al een
backup-staleness-checkworkflow — koppel daaraan). - Herstel-oefening. Minimaal jaarlijks één bron écht terugzetten en verifiëren dat het werkt. Een backup die nooit is teruggezet is geen backup.
- Runbook per bron. Voor elke rij in de tabel: exacte herstelstappen (koppelt aan het business-continuity-plan zodat de waarnemer het kan uitvoeren).
Klaar wanneer
- De inventaris-tabel is ingevuld met echte frequenties.
- Voor minstens de drie kritieke bronnen (repo, klantdata, kluis) is één hersteltest gedaan.