Disaster recovery, back-ups, RTO/RPO, failover en vooral de vraag die veel bedrijven zichzelf pas na een storing stellen: kunnen we het systeem echt herstellen en weer aan het werk gaan?
Serverstoring. Beschadigde database. Fout na implementatie. Ransomware. Problemen met de infrastructuurleverancier. Per ongeluk verwijderde gegevens. Storing in een hele regio.
Er zijn veel scenario's. Het probleem is dat de meeste bedrijven zich vooral voorbereiden op het voorkomen van een storing.
En veel minder vaak op de situatie waarin die storing toch plaatsvindt.
Dat is precies het domein van disaster recovery.
En hier komt de fundamentele vraag: als jouw applicatie vandaag om 14:00 uur stopt met werken, hoeveel tijd heb je nodig om die opnieuw op te starten en hoeveel gegevens kun je daarbij verliezen?
Als het antwoord luidt: "we hebben een back-up", dan is dat nog geen antwoord op die vraag.
Een back-up is geen disaster recovery
Een back-up is een kopie van gegevens. Disaster recovery is het proces om de werking van het systeem te herstellen.
Dat is een heel belangrijk onderscheid.
Je kunt dagelijks databasekopieën maken en toch niet weten:
-
of de laatste kopie correct is,
-
of deze kan worden hersteld,
-
hoe lang het herstel zal duren,
-
of de database na herstel zal samenwerken met de huidige versie van de applicatie,
-
of je ook de systeemconfiguratie kunt herstellen,
-
of je alle sleutels, certificaten en geheimen hebt die nodig zijn om de omgeving te starten,
-
of de infrastructuur die nodig is om de applicatie te starten nog beschikbaar is,
-
wie de afzonderlijke stappen moet uitvoeren,
-
of het hele proces binnen de bedrijfsmatig aanvaardbare tijd valt.
NIST wijst expliciet op de noodzaak om het terugzetten van back-ups te testen, en de actuele AWS-richtlijnen behandelen periodieke recovery-tests ook als een manier om te controleren of een back-up werkelijk de beoogde RTO en RPO haalt.
Daarom is een back-up een onderdeel van de recovery-strategie, en niet het volledige equivalent ervan.
De belangrijkste vraag: wat gebeurt er na een storing?
Laten we ons een webshop voorstellen.
Om 10:17 uur reageert de database niet meer.
De applicatieserver draait nog steeds, maar gebruikers kunnen niet inloggen. Bestellingen werken niet. Het beheerpaneel reageert niet meer. Het betalingssysteem ontvangt geen correcte informatie.
Het team onderzoekt de situatie.
Het blijkt dat de laatste back-up van de database om 8:00 uur is gemaakt.
In theorie kunnen de gegevens worden hersteld.
Maar dan rijzen er nieuwe vragen;
- Weet men waar de kopie zich bevindt?
- Weet men hoe deze moet worden teruggezet?
- Is de persoon die dat kan doen beschikbaar?
- Is de back-up compleet?
- Komt de applicatieconfiguratie overeen met de versie die in de kopie is opgeslagen?
- Zal de database na herstel werken met de huidige applicatie?
- En het belangrijkste: hoe lang duurt het om de webshop weer operationeel te krijgen?
Als niemand dat eerder heeft gecontroleerd, kan het antwoord verrassend zijn.
RTO - hoeveel downtime kunnen we accepteren?
RTO, oftewel Recovery Time Objective, bepaalt de maximale aanvaardbare hersteltijd van het systeem na een storing.
Voorbeeld: RTO = 4 uur betekent dat de organisatie ervan uitgaat dat de werking van het systeem binnen maximaal vier uur kan worden hersteld.
Dat betekent echter niet dat elke applicatie een RTO van vier uur zou moeten hebben.
Voor een intern systeem dat slechts een paar keer per dag wordt gebruikt, kan zo'n tijd acceptabel zijn. Voor een verkoopplatform dat 24/7 draait, kan het zeer ernstige verliezen betekenen.
RTO moet dus voortkomen uit het bedrijf, niet uit wat de infrastructuur momenteel biedt.
NIST definieert RTO als de tijd gedurende welke een systeem in de herstelfase kan blijven voordat dit de activiteiten van de organisatie negatief beïnvloedt.
RPO - hoeveel gegevens kunnen we verliezen?
De tweede basisparameter is RPO, oftewel Recovery Point Objective.
RPO beantwoordt de vraag: hoe ver terug kunnen we in de gegevens gaan na een storing?
Voorbeeld: RPO = 1 uur betekent dat de organisatie een mogelijk verlies van maximaal ongeveer één uur aan gegevens accepteert.
Als het systeem om 15:00 uur uitvalt en de laatste bruikbare kopie van 14:00 uur is, dan valt precies zo'n scenario binnen de veronderstelde RPO. Maar als een back-up slechts één keer per dag wordt gemaakt, is het moeilijk om een RPO van één uur te verwachten.
RPO heeft dus direct invloed op de manier waarop back-ups, gegevensreplicatie en infrastructuurontwerp worden uitgevoerd.
RTO vertelt ons vooral hoe lang we onbeschikbaar kunnen zijn.
RPO zegt hoeveel gegevens we kunnen verliezen.
Deze twee parameters moeten samen met het bedrijf worden vastgesteld, omdat het behalen ervan kosten en technische oplossingen met zich meebrengt. Microsoft benadrukt ook dat RTO en RPO moeten voortkomen uit daadwerkelijke bedrijfsbehoeften, en niet uit de abstracte aanname van "nul downtime en nul dataverlies".
Een back-up kan bestaan en toch nutteloos zijn
Dit is een van de gevaarlijkste mythes in IT.
"De back-up wordt correct uitgevoerd" betekent niet automatisch: "het systeem kan eruit worden hersteld".
De kopie kan onvolledig zijn. Ze kan beschadigd zijn. Ze kan gegevens bevatten die niet correct kunnen worden gebruikt. Ze kan op een manier zijn gemaakt die het onmogelijk maakt om de hele omgeving te herstellen.
Daarom moet een back-up worden getest door een daadwerkelijke herstelactie.
Het is niet genoeg om te controleren of het bestand bestaat.
Je moet het terugzetten.
Het systeem opstarten.
De gegevens controleren.
De afhankelijkheden verifiëren.
De configuratie controleren.
De tijd meten.
En beantwoorden of het resultaat overeenkomt met de RTO- en RPO-aannames.
AWS wijst als typische fout juist op het terugzetten van een back-up zonder te controleren of de herstelde bron daadwerkelijk werkt en of de herstelde gegevens kunnen worden gebruikt.
Failover - wanneer we niet willen wachten op herstel
Niet elke applicatie kan zich enkele uren wachten op herstel permitteren. In zulke gevallen worden onder andere failovermechanismen gebruikt.
Failover betekent het overzetten van de werking van de primaire omgeving naar een voorbereide backupomgeving.
Dat kan zijn:
-
een reserve-server,
-
een tweede beschikbaarheidszone,
-
een tweede regio,
-
een database-replica,
-
een standby-omgeving,
-
alternatieve infrastructuur die klaarstaat om te worden opgestart.
In het eenvoudigste model draait de applicatie op één locatie, en bij een storing starten we een reserveomgeving op. In meer geavanceerde oplossingen draait een deel van de infrastructuur parallel en is deze voorbereid om het verkeer over te nemen.
Er bestaat echter niet één strategie die voor iedereen geschikt is.
Backup en restore zijn meestal goedkoper, maar kunnen een langere hersteltijd betekenen. Oplossingen zoals warm standby of actieve redundantie kunnen de recovery aanzienlijk verkorten, maar vereisen meer investeringen en een complexere infrastructuur.
Failover moet je ook testen
Hier komt nog een ander probleem bij.
Een bedrijf kan een reserveomgeving hebben, maar die al twee jaar niet hebben gebruikt;
- Werkt die nog steeds?
- Komt de configuratie overeen met productie?
- Heeft die voldoende capaciteit?
- Zijn alle diensten beschikbaar?
- Zijn de certificaten actueel?
- Schakelt DNS correct over?
- Verbindt de applicatie met de database?
- Werkt het autorisatiemechanisme?
- Weet het team precies wat het moet doen?
Alleen een test geeft antwoord op deze vragen.
AWS adviseert om failover regelmatig te testen, juist om het herstelpad te verifiëren en te controleren of de werkelijke RTO en RPO overeenkomen met de uitgangspunten.
Een disaster-recoveryomgeving die nooit is getest, is deels alleen een aanname.
Disaster recovery is niet alleen infrastructuur
Het is makkelijk om DR alleen te bekijken door de bril van servers.
Dat is een fout.
Recovery omvat ook:
- Gegevens
Zijn alle belangrijke gegevens beschermd? - Applicatie
Beschikken we over de juiste versie van de code en de mogelijkheid om die uit te rollen? - Configuratie
Weten we welke instellingen nodig zijn om het systeem op te starten? - Geheimen en certificaten
Hebben we veilige toegang tot sleutels, tokens en certificaten? - Externe afhankelijkheden
Wat gebeurt er als een extern betalingssysteem, API, identiteitsprovider of SaaS-dienst niet beschikbaar is? - Infrastructuur
Hebben we een plek waar de applicatie kan draaien? - Mensen
Is duidelijk wie beslist over het starten van de procedure? - Procedures
Bestaat er een concrete runbook, of is recovery afhankelijk van de kennis van één persoon?
Dat laatste is bijzonder belangrijk.
Als slechts één beheerder weet hoe het systeem moet worden hersteld, dan hebben we nog geen robuuste procedure. Dan hebben we een afhankelijkheid van één specifieke persoon.
Het slechtste moment om een recoveryprocedure te schrijven
Dat is het moment waarop het systeem al niet meer werkt.
Dan ontstaat tijdsdruk, stress, telefoontjes van klanten en vragen van het management.
Daarom moet de procedure vooraf worden opgesteld.
Ze moet onder andere bepalen:
-
wanneer we disaster recovery activeren,
-
wie de beslissing neemt,
-
welke systemen de hoogste prioriteit hebben,
-
waar de backups zich bevinden,
-
hoe ze worden hersteld,
-
welke afhankelijkheden moeten worden opgestart,
-
hoe failover eruitziet,
-
hoe de correcte werking wordt geverifieerd,
-
hoe de storing wordt gecommuniceerd,
-
wanneer failback kan beginnen,
-
wie de terugkeer naar de primaire omgeving goedkeurt.
Bij een ernstige storing zou er geen ruimte moeten zijn voor de vraag: “Wat doen we nu?”
De procedure moet dat vooraf al beantwoorden.
DR moet worden getest zoals een applicatiefunctie
Een goede aanpak is recovery te behandelen zoals softwaretests. Het is niet genoeg om de procedure één keer op te stellen.
Het systeem verandert.
De database groeit.
Afhankelijkheden veranderen.
Er komt nieuwe infrastructuur bij.
Applicatieversies veranderen.
Er ontstaan nieuwe integraties.
Rechten veranderen.
Daarom moet ook de recoverystrategie voortdurend worden gecontroleerd.
Een test kan beginnen met een eenvoudig scenario: “De database is verloren gegaan. Laten we die herstellen vanaf de laatste kopie.”
Daarna kun je doorgaan naar complexere scenario's:
- “De applicatieserver werkt niet.”
- “De hele productieomgeving is niet beschikbaar.”
- “De gegevens zijn versleuteld.”
- “De primaire infrastructuurregio werkt niet.”
- “We hebben geen toegang tot de hoofdbeheerder.”
Elke dergelijke test kan problemen blootleggen die tijdens de normale werking van het systeem niet zichtbaar zijn.
Heeft elke applicatie geavanceerde disaster recovery nodig?
Nee.
En dat is ook belangrijk.
Een infrastructuur ontwerpen die bestand is tegen elk denkbaar scenario kan onevenredig duur zijn.
Als een storing van een interne applicatie slechts een uur ongemak betekent, hebben we niet per se een active-active infrastructuur in meerdere regio's nodig. Maar als een storing van het systeem betekent dat verkoop, productie, klantenservice of een kritisch bedrijfsproces stilvalt, ziet de situatie er heel anders uit.
Eerst moet de impact van de storing op de business worden bepaald.
Pas daarna kies je de technologie.
Dat kan leiden tot verschillende oplossingen:
Backup + restore
Een eenvoudigere en goedkopere oplossing voor systemen met een lagere kriticiteit.
Warm standby
De reserveomgeving is gedeeltelijk voorbereid en kan snel worden opgestart.
Hot standby
De reserveomgeving draait in grotere mate parallel en is klaar om de belasting over te nemen.
Active-active
Twee omgevingen kunnen tegelijk verkeer afhandelen, waardoor de afhankelijkheid van één enkel storingspunt wordt beperkt.
De keuze van de oplossing moet voortkomen uit RTO, RPO, de kriticiteit van het systeem, de kosten van uitval en de technische mogelijkheden.
Checklist: is jouw applicatie klaar voor een storing?
Het is de moeite waard om een paar eenvoudige vragen te beantwoorden.
1. Hebben we een backup?
Dat is pas het begin.
2. Wordt de backup opgeslagen op een manier die hem ook beschermt tegen een storing van de productieomgeving?
3. Hebben we ooit een volledig herstel uitgevoerd?
4. Hoe lang duurt een restore daadwerkelijk?
5. Kennen we de RTO?
6. Kennen we de RPO?
7. Kunnen we niet alleen de gegevens herstellen, maar ook de applicatie en de configuratie ervan?
8. Hebben we een recoveryprocedure?
9. Kan meer dan één persoon die uitvoeren?
10. Hebben we failover getest?
11. Is de reserveomgeving actueel?
12. Hebben we recovery opnieuw getest na de laatste wijzigingen in het systeem?
Als we op een paar vragen antwoorden met 'ik weet het niet', dan is dat een heel goed moment om naar de disaster-recoverystrategie te kijken.
De belangrijkste test luidt: „Laat het zien”
In IT is het heel gemakkelijk om te zeggen:
- „We hebben een backup.”
- „We hebben een reserve-server.”
- „We hebben een procedure.”
- „We hebben disaster recovery.”
- Maar de veiligheid van een systeem mag niet uitsluitend op verklaringen berusten.
De belangrijkste vraag luidt: Laat zien dat je het kunt herstellen.
- Voer een restore uit.
- Meet de tijd.
- Controleer de gegevens.
- Test de applicatie.
- Voer failover uit.
- Controleer de procedure.
- Herhaal de test na belangrijke wijzigingen.
Pas dan kun je zeggen dat de recoverystrategie in de praktijk is getest.
Backup beschermt data. Recovery herstelt het bedrijf
Dat is waarschijnlijk het belangrijkste verschil.
Backup beantwoordt de vraag: „Hebben we een kopie?”
Disaster recovery beantwoordt een veel moeilijkere vraag: „Kunnen we na een storing weer operationeel worden?”
En tussen die twee ligt de volledige herstelinfrastructuur: RPO, RTO, replicatie, backups, restore, failover, configuratie, procedures, verantwoordelijkheid en regelmatige tests.
Een goed ontworpen systeem gaat er niet van uit dat er nooit een storing zal optreden. Het gaat ervan uit dat er ooit een storing zal optreden en dat je moet weten wat je moet doen.
Want echte veerkracht van een applicatie zit er niet in dat ze nooit stukgaat. Ze zit erin dat wanneer er iets misgaat, de organisatie op een voorspelbare, gecontroleerde en aan de zakelijke eisen conforme manier weer operationeel kan worden.
Woordenlijst
Disaster Recovery (DR) - strategie en procedures waarmee systemen na een ernstige storing weer operationeel kunnen worden.
Backup - een kopie van gegevens die bedoeld is om later te worden hersteld.
Restore - het proces van het herstellen van gegevens of een systeem vanuit een kopie.
RTO (Recovery Time Objective) - de maximaal aanvaardbare hersteltijd van een systeem.
RPO (Recovery Point Objective) - het maximaal aanvaardbare gegevensverlies uitgedrukt in tijd.
Failover - het overschakelen van de werking van het systeem van de primaire omgeving naar de noodomgeving.
Failback - het terugschakelen van de werking naar de primaire omgeving nadat de oorzaak van de storing is verholpen.
Recovery test - een test die moet bevestigen dat het systeem daadwerkelijk kan worden hersteld volgens de aangenomen uitgangspunten.
Runbook - een gedetailleerde instructie voor handelen in een bepaald storingsscenario.
