We kijken niet alleen of een back-up is gemaakt, maar ook of deze correct en volledig is. Afwijkingen worden gesignaleerd en direct opgepakt om problemen bij herstel te voorkomen.
Hoe wordt gecontroleerd of back-ups bruikbaar zijn?
- Wat is het verschil tussen een back-up en disaster recovery?"
Een back-up zet je terug naar hoe het was op het moment van die back-up. Disaster recovery is erop gericht dat je verdergaat waar je gebleven was, met zo weinig mogelijk dataverlies en zo weinig mogelijk stilstand.
Back-up terugzetten Disaster recovery Doel Een oudere versie terughalen Zo snel mogelijk weer operationeel zijn Typisch gebruik Een bestand is per ongeluk gewist of overschreven Een server, locatie of hele omgeving is uitgevallen Dataverlies Alles sinds de laatste back-up Zo klein mogelijk, soms bijna nul Tijd Kan lang duren bij grote volumes Ingericht op snelle overschakeling Veel organisaties hebben een back-up goed geregeld en denken daarmee klaar te zijn. Een back-up is vooral een opslag van historische data. Bij een echte calamiteit is dat vaak niet genoeg.
" - Wat betekenen RTO en RPO bij disaster recovery?"
RTO is hoe lang je maximaal zonder een systeem kunt. RPO is hoeveel werk je maximaal kwijt mag raken. Het eerste gaat over tijd, het tweede over data.
Term Voluit De vraag die het beantwoordt Voorbeeld RTO Recovery Time Objective Hoe snel moet dit weer werken? Vier uur betekent: binnen vier uur na de storing moet het systeem weer beschikbaar zijn. RPO Recovery Point Objective Hoeveel data mag ik verliezen? Maak je elke vier uur een back-up, dan is je RPO vier uur. Je verliest maximaal vier uur werk. Twee dingen om in het achterhoofd te houden. Hoe korter je RTO en RPO, hoe duurder je oplossing wordt. En je RPO kan in de praktijk slechter uitvallen dan je denkt: als een incident optreedt terwijl de back-up nog loopt of de laatste back-up beschadigd blijkt, moet je terug naar een oudere versie. Dan raak je meer data kwijt én duurt het herstel langer.
" - Hoe bepaal je de juiste RTO en RPO voor je organisatie?"
Niet op gevoel, maar door te meten. We zetten een testomgeving van een bekende omvang terug, klokken hoelang dat duurt, en rekenen dat door naar jouw werkelijke omvang.
- We nemen bijvoorbeeld een virtuele server van 500 gigabyte en zetten die naast de bestaande omgeving terug. De originele omgeving blijft gewoon staan.
- We meten precies hoelang dat herstel duurt.
- Vanuit die meting kunnen we doorrekenen wat een drie keer zo grote omgeving zou kosten aan tijd.
- Daarmee weet je of de RTO en RPO die je op papier hebt afgesproken werkelijk haalbaar zijn.
De rekenregel voor de minimale hersteltijd is eenvoudig: het aantal terug te zetten gigabytes gedeeld door de herstelsnelheid in gigabytes per seconde. De uitkomst is de tijd die je minimaal nodig hebt. Sneller dan dat wordt het niet.
Deze oefening levert regelmatig een ongemakkelijke conclusie op. Een database die door de jaren heen is gegroeid tot enkele terabytes past soms simpelweg niet meer binnen de afgesproken hersteltijd. Dan is het antwoord niet een snellere back-up, maar de omgeving zo herinrichten dat herstel wél binnen de benodigde tijd past.
" - Welke RTO en RPO kun je realistisch verwachten na een storing?"
Dat hangt volledig af van je inrichting. Draai je één omgeving die vanuit back-up hersteld moet worden, dan praat je over uren tot dagen. Staat je data verspreid over twee datacenters, dan kan er een locatie wegvallen zonder dat je hoeft te herstellen.
De belangrijkste factoren:
Factor Effect op RTO en RPO Hoeveelheid data Bepalend. Herstel van enkele terabytes duurt onvermijdelijk lang. Wel of niet gespreid over meerdere datacenters Bij spreiding is herstel vaak niet eens nodig; je schakelt over. Frequentie van de back-up Bepaalt direct je RPO. Type back-up Herstel vanuit losse aanvullende back-ups duurt langer dan vanuit één volledige. Snelheid van de vervangende omgeving Een langzamere vervanger verlengt het herstel. Moment van de dag Herstellen tijdens werktijd duurt langer dan 's nachts. Ga bij het opstellen van een plan altijd uit van het slechtste scenario: hardware kan stuk, de back-up kan onbruikbaar zijn, de vervangende omgeving kan langzamer zijn. Juist door daar rekening mee te houden vind je de pijnlijke plekken in je infrastructuur, zodat de RTO en RPO die je wilt ook echt haalbaar worden.
" - Hoe is disaster recovery bij ROOT opgezet?"
Voor kritische omgevingen bouwen we redundantie in op elke laag, verdeeld over minimaal twee datacenters. Herstel uit back-up is dan het laatste vangnet, niet het eerste antwoord.
Alle onderdelen worden dubbel uitgevoerd en over twee of meer datacenters gespreid:
- De internetverbinding. Er zijn manieren om internet via twee datacenters naar één klant te laten lopen, waarbij een van de twee routers mag uitvallen zonder dat de dienst stopt.
- De firewall, ook verdeeld over twee datacenters.
- De verkeersverdelers die het werk over servers spreiden.
- De webservers en de databaseomgeving.
- De opslag zelf, met drie kopieën van elke back-up in drie datacenters.
Cruciaal is dat je goed rekent. Draaien twee servers elk op 70 procent van hun capaciteit en valt er één weg, dan zou de ander 140 procent moeten leveren. Dat kan hij niet. Bij het ontwerp moet dus per onderdeel gelden dat de rest het werk kan overnemen. Omdat gebruik in de loop der jaren groeit, kijken we die verhoudingen periodiek opnieuw na.
" - Hoe worden back-ups getest en hoe vaak gebeurt dat?"
Door daadwerkelijk terug te zetten en te klokken hoe lang dat duurt. Daarnaast controleren we elke dag of alle verwachte back-uprapportages binnen zijn gekomen. Een back-up maken zonder te testen geeft alleen het gevoel dat je gedekt bent.
Wij ontvangen dagelijks honderden rapportages over back-ups. Bij die aantallen mis je de ene die niet komt, tenzij je daar iets voor hebt gebouwd. Daarom hebben we een overzicht waarin per systeem staat welke melding we elke dag verwachten.
- Groen betekent: binnengekomen en in orde.
- Rood betekent: verwacht, maar niet ontvangen. Daar gaat iemand naar kijken.
- Grijs betekent: dit systeem verwachten we niet meer, bijvoorbeeld omdat het is vervangen.
- De rapportages worden ook op inhoud beoordeeld. Meldingen die succes melden worden direct gearchiveerd; alles met een waarschuwing of fout gaat naar een aparte postbus die dagelijks wordt nagelopen.
Testen is net zo belangrijk als maken, om dezelfde reden dat je auto naar de beurt gaat. Test je niet, dan blijkt na verloop van tijd dat dingen toch niet goed genoeg zijn. Dat overkomt ons ook: na het vervangen van netwerkapparatuur bleek bij een test dat de nieuwe opstelling niet goed was ingeregeld, omdat in het project geen goede acceptatietest was uitgevoerd. Zonder die test hadden we het pas gemerkt toen het echt nodig was.
" - Wat gaat er het vaakst mis bij back-up en herstel?"
Dat niemand controleert of de back-up werkelijk loopt. We hebben een organisatie gezien die vijf jaar lang trouw een tape wisselde, terwijl er in die vijf jaar nooit een back-up is gemaakt.
Die situatie kwam pas aan het licht toen de organisatie een verzekering tegen ransomware had afgesloten en de verzekeraar bewijs vroeg dat de back-up goed was ingericht. Er is destijds iets opgeleverd, de leverancier is op een bepaald moment uit beeld geraakt, en daarna werd de handeling wel uitgevoerd maar gebeurde er niets.
De meest gemaakte fouten:
- Geen dagelijkse controle of de back-up is gelukt. Iemand moet daar elke dag naar kijken, of er moet iets zijn dat het opmerkt.
- Nooit een herstel getest, waardoor je pas bij een calamiteit ontdekt hoe lang het duurt of dat het niet werkt.
- De back-up staat in hetzelfde netwerk als de data die geback-upt wordt, waardoor ransomware er ook bij kan.
- Geen rekening houden met groei. Een omgeving die vijf jaar geleden binnen de hersteltijd paste, past dat nu misschien niet meer.
- Niemand in de organisatie die het geheel overziet. Je hoeft het niet zelf te doen, maar er moet iemand zijn die snapt wat er is afgesproken en of het nog klopt.
- Waarom is een back-up onderdeel van een serieuze IT-omgeving?"
Zonder back-up is er geen vangnet. Incidenten zoals ransomware, menselijke fouten of technische storingen kunnen altijd voorkomen. Met een goede back-upstrategie zorg je dat je snel kunt herstellen en de impact beperkt blijft.
" - Hoe wordt gecontroleerd of back-ups bruikbaar zijn?"
We kijken niet alleen of een back-up is gemaakt, maar ook of deze correct en volledig is. Afwijkingen worden gesignaleerd en direct opgepakt om problemen bij herstel te voorkomen.
" - Waar slaan jullie onze back-ups op?"
Back-ups worden opgeslagen in onze eigen storage clusters, die draaien in Nederlandse datacenters. De data staat los van de productieomgeving en wordt verdeeld over meerdere locaties, zodat deze beschikbaar blijft bij storingen of incidenten.
" - Hoe zit het met back-ups binnen Microsoft 365?"
Hoewel Microsoft 365 veel functionaliteit biedt, ligt de verantwoordelijkheid voor databehoud bij de organisatie zelf. Daarom adviseren wij aanvullende back-upoplossingen om bedrijfsdata extra te beschermen.
"
Home Kennis Veelgestelde vragen Continuïteit & Disaster Recovery Hoe wordt gecontroleerd of back-ups bruikbaar zijn?