Back-up ≠ herstel: zo bewijs je herstelbaarheid

TL;DR
Veel organisaties gaan ervan uit dat ze kunnen terugzetten, maar hebben geen recent bewijs. Back-ups zijn een vangnet; herstelbaarheid is het vermogen om een dienst weer werkend te krijgen binnen je RTO (tijd) en met een acceptabel RPO (dataverlies). In deze blog: een simpele aanpak om in een paar dagen “restore-proof” te worden, met stappen, checklist, KPI’s en een compact runbook-voorbeeld.

Waarom dit nu telt

Cloud verandert elke dag: nieuwe workloads, wisselingen in teams, uitzonderingen die permanent worden. Back-ups zijn er vaak wel, maar kun je onder tijdsdruk aantonen dat de dienst weer werkt? Leidinggevenden worden niet afgerekend op “we hadden back-ups”, maar op hersteltijd en impact voor klanten.

Het verschil dat uitmaakt

Back-up = er bestaat ergens een kopie.

Herstel = die kopie komt terug als werkende dienst, binnen je afgesproken RTO, met dataverlies binnen je RPO. Bestuurders geven vooral om die tweede.

Vijf stappen naar “restore-proof”

1. Kies een scenario dat ertoe doet. Pak één kritieke service (bijv. app + database) en één waarschijnlijk probleem (per ongeluk verwijderen, corruptie, ransomware). Leg je doelen vast: RTO (hoe snel weer werken) en RPO (maximaal dataverlies).
2. Wijs één eigenaar aan. Niet “het team”, maar een naam. Bepaal wie mag stoppen als het uitloopt en wie beslist of “goed genoeg” is bereikt.
3. Maak herstel herhaalbaar. Schrijf op één pagina: waar staan back-ups (retentie, immutability), welke rollen/credential zijn nodig (liefst least-privilege), pre-checks (Key Vault/keys, netwerk/DNS, quotas), het runbook (stappen met verwachte tijden) en hoe je controleert dat de service écht oké is (health-endpoint, testquery, testlogin).
4. Doe een droge run. Voer het runbook uit in een veilige omgeving of met kopie-data. Meet tijd van start tot “bruikbaar”. Noteer blokkades (rechten, throttling, soft-delete locks, ontbrekende afhankelijkheden).
5. Leg bewijs vast. Maximaal 2 pagina’s: scenario, RTO/RPO-targets, gemeten tijden, issues, besluiten. Plan meteen de volgende oefening over 3–6 maanden met een ander scenario.

Mini-checklist

[ ] RTO/RPO per kritieke service zijn afgesproken en opgeschreven.

[ ] Runbooks in versiebeheer met een eigenaar.

[ ] Back-ups zijn geïsoleerd/immutable en een restore is getest.

[ ] Validatie is objectief: health-check, testlogin of synthetische transactie.

[ ] Restore kan met least-privilege rollen (break-glass gecontroleerd).

[ ] Monitoring/alerts vangen restore-fouten.

[ ] Rapport bevat doorlooptijd, dataverlies en lessons learned.

KPI’s die helpen

Hersteltijd (RTO, P50/P90): tijd van “restore start” tot “service gezond”. P50 = normaal; P90 = slechte dag. Richting: P50 ≤ 60 min, P90 ≤ 120 min voor topdiensten (pas aan op jouw context).

Dataverlies (RPO): verschil tussen gekozen herstelpunt en incident/drill-start. Hou dit in minuten/uren bij.

Restore-succesratio: % oefeningen dat in één keer slaagt binnen RTO/RPO met bewijs dat de dienst werkt. Streef ≥ 95% voor geplande drills.

Oefen-frequentie en dekking: hoe vaak per dienst geoefend en welk % van je tier-1 in de laatste 6–12 maanden. Streef 100% dekking per jaar.

MTTR in drills: gemiddelde hersteltijd over oefeningen; laat trends zien als je automatiseert. Toon altijd óók P90.

Forecast vs. realiteit: voor disciplines die kosten meenemen: verschil tussen verwachting en echte maandkosten; wekelijks aanscherpen.

Veelgemaakte valkuilen

Snapshots ≠ strategie: een snapshot is geen plan.

Verborgen afhankelijkheden: Key Vault, private endpoints, DNS, service-principals.

Onrealistische testdata: gebruik representatieve, privacy-veilige data.

Heldencultuur: één engineer “die het trucje kent”. Documenteer en automatiseer.

Zo start je deze week (zonder project te maken)

Dag 1: kies één service + één scenario, leg RTO/RPO vast, wijs een eigenaar aan.

Dag 2: schrijf de 1-pagina herstelhandleiding (locatie back-ups, rollen, pre-checks, stappen, validatie).

Dag 3: plan en draai een droge run van 90 minuten, meet start-tot-gezond.

Dag 4: noteer blokkades, maak acties met eigenaren en deadlines.

Dag 5: schrijf een kort rapport (tijden, dataverlies, lessons learned, besluiten).

Dag 6: automatiseer kleine dingen (script voor health-check, runbook in pipeline).

Dag 7: plan de volgende oefening over 3–6 maanden met een nieuw scenario.

Voorbeeld: compact runbook (template)

Doel: herstel Service X na datacorruptie; RTO 120 min; RPO 15 min.

Back-up: Vault A, retentie 30 dagen, immutability 14 dagen.

Rollen: RestoreOperator (geen Global Admin); break-glass in kluis.

Pre-checks: keys/secrets in Key Vault beschikbaar; private endpoints/DNS oké; compute/storage quotas voldoende.

Stappen: 1) DB point-in-time herstellen (T-15m) 2) app-config/secrets naar herstelde DB 3) app warmdraaien/migratie indien nodig 4) traffic switch en 10 min monitoren.

Validatie: /healthz = 200, testlogin slaagt, end-to-end flow (bijv. order) werkt.

Succescriterium: < 120 min totaal, < 15 min dataverlies.

Slot

Back-ups zijn noodzakelijk. Herstelbaarheid is wat je klanten ervaren. Begin klein, bewijs het één keer, maak er een gewoonte van en de volgende keer dat het misgaat, heb je rust, data en een draaiboek.