De automatische back-up liep al twee jaar. De dag van de storing wist niemand hoe te herstellen: slechte momentopname, beschadigde database, DNS verwijst nog steeds naar de oude server. “We hadden back-ups” – ja. Geen herstelplan.
Dit scenario herhaalt zich zodra een team kopiëren en continuïteit door elkaar haalt. Een PRA (disaster recovery plan) beantwoordt specifieke vragen: hoe lang kun je zonder service (RTO), hoeveel data kun je verliezen (RPO), wie doet wat, in welke volgorde en hoe kun je klanten en partners informeren. De back-ups die door de host worden aangeboden, zijn slechts één steen: niet het plan. Kruis het aan met De mythe van de 99,99%: SLA-credits vervangen nooit een organisatie die weet hoe ze terug moet komen.
Definieer zakelijke RTO en RPO
RTO en RPO worden niet gekozen op basis van technisch gevoel. Ze weerspiegelen een zakelijke risicotolerantie: omzetverlies, onvermogen om te factureren, contractuele overtreding jegens een B2B-klant. Begin met een eenvoudige tabel, gevalideerd met de productmanager of het management.
| Website | Indicatieve RPO | Indicatieve RTO |
|---|---|---|
| E-commerce | 15 minuten – 1 uur | 1–4 uur |
| B2B SaaS | 5–15 minuten | < 1 uur |
| Bedrijfswebsite | 24 uur | 4–24 uur |
| Blog | 24 uur | 48 uur |
Een RPO van één uur impliceert een back-up per uur, of zelfs binaire logbestanden als de database dit toestaat. Een vier uur durende RTO vereist een gedocumenteerde procedure en een eerder geteste restauratie – niet een eerste poging onder stress op een zondagavond. Als niemand een volledig herstel heeft getimed, is uw weergegeven RTO een gok.
Minimale architectuur en rol van de gastheer
De 3-2-1-regel blijft de basis: drie kopieën, twee media, één extern. Maak een volledige inventarisatie: code in Git, database, geüploade bestanden, DNS-records, geheimen en certificaten. Schrijf een genummerd runbook: dat de host aanroept, dat de DNS schakelt, dat de herstelde database valideert — zie redirects domaine voor de omschakelingstraps.
Bereid een herstelomgeving voor: koude VPS, kant-en-klare image of tweede gedocumenteerde host. Plan externe communicatie via een vooraf geschreven statuspagina en incidentberichten. De host levert vaak momentopnamen; u moet de database exporteren, een externe kopie coderen, het herstel testen en een secundaire DNS-failover beheren als het probleem dit rechtvaardigt.
Test de restauratie: het enige bewijs dat telt
Een back-up die nooit is hersteld, is een belofte. Voer elk kwartaal een volledige oefening uit: herstel op staging, verificatie van uploads, test van de applicatieverbinding, realtime meting. Let op de verschillen tussen de gemeten duur en de aangekondigde RTO.
Typische fouten verschijnen hier: back-upplug-in die de directory uploads uitsluit, snapshot te oud, incompatibele PHP-versie op de herstelserver, ontbrekende geheimen in de kluis. Herstel het proces na elke oefening – en niet alleen de denkbeeldige storing.
Omschakeling, DNS en tweede host
Voor kritieke locaties verlaagt een tweede host of een vooraf geconfigureerde herstelzone de RTO. De DNS-omschakeling blijft het zwakke punt: hoge TTL, solver-cache, certificaten gekoppeld aan de oude server. Documenteer de volgorde: TTL-reductie de dag vóór een geplande wijziging, A/AAAA-schakelaar, HTTPS-controle, terugdraaien indien mislukt.
Een koude stand-by kost minder dan een warme stand-by, maar verlengt de tijd om weer in gebruik te nemen. De keuze wordt gemaakt op basis van de geaccepteerde RTO en het budget – niet op basis van het technische ego van het team.
De top: het veiligstellen stelt gerust; alleen het herstel bewijst
Beslis en ga vooruit zonder blinde vlek
Begin met het instellen van een RTO en een RPO per kritieke dienst, gevalideerd met de business. Automatiseer vervolgens externe back-ups en houd een inventaris bij van geheimen en afhankelijkheden. Plan een driemaandelijkse hersteltest en noteer de daadwerkelijk waargenomen duur. Vergelijk hosts die hun snapshots en procedures documenteren via de overzicht. Overweeg een tweede gast- of herstelgebied als het financiële of reputatiebelang groter is dan de kosten van ontslag.
Veelgestelde vragen
Wat is het verschil tussen een back-up- en herstelplan?
Back-up kopieert gegevens. In het herstelplan wordt gedefinieerd wie wat herstelt, binnen hoe lang, met welk aanvaardbaar verlies, en hoe verder moet worden gegaan als de host niet beschikbaar is. Zonder een schriftelijke en beproefde procedure blijft de kopie theoretisch op de dag van de crisis.
Zijn de automatische back-ups van de host voldoende?
Nee, niet alleen. Frequentie, retentie en herstel zijn niet altijd contractueel gegarandeerd. Een externe kopie is vereist, een driemaandelijkse test en een gedocumenteerde procedure — zie CGV hosting.
Welke RTO/RPO voor een e-commercesite?
Indicatief: RPO minder dan één uur voor orders, RTO minder dan vier uur om de handel te hervatten – te kalibreren op de omzetverlies per uur. Een showcaseblog tolereert vaak vierentwintig uur; een mand die overdag geblokkeerd is, kost veel meer.
Is er een tweede host nodig?
Voor kritieke sites: ja: DNS-failover, stand-by-infrastructuur, gevalideerd runbook. De kosten zijn vergelijkbaar met het risico. Bij gedeelde diensten is een tweede host niet verplicht als een lange RTO acceptabel blijft – op voorwaarde dat dit expliciet wordt aangenomen.
Een back-up die u nooit heeft hersteld, is een belofte. Een PRA is de belofte waargenomen met een stopwatch.