Een serverfout of een overstroming heeft al je computers beschadigd. Gelukkig heb je de situatie kunnen herstellen. Het dieptepunt is voorbij. Althans, dat dacht je. Want hoewel al je belangrijke data is geback-upt, kom je erachter dat die back-ups zijn mislukt en dat je business is ‘bevroren’.
Dit scenario vindt vaker plaats dan je denkt. Bedrijven komen er dan te laat achter dat hun back-ups incompleet waren of verkeerd zijn uitgevoerd. Daarom is het testen van disaster recovery noodzakelijk om ervoor te zorgen dat back-ups succesvol verlopen.
Wat en wanneer te testen?
Disaster recovery-tests zijn nodig om zeker te weten dat het bedrijfscontinuïteitsplan werkt. Afhankelijk van de oplossing – niet alle oplossingen bieden een on-site apparaat dat direct is te virtualiseren – test je of je back-ups zijn te herstellen via:
-
je on-site apparaat voor bedrijfscontinuïteit (om je ervan te verzekeren dat het apparaat je data binnen enkele seconden kan herstellen vanuit het apparaat zelf);
-
de cloud-to-on-site-locatie (om downloadsnelheden en de effecten op hulpbronnen te checken);
-
off-site cloudvirtualisatie, ook bekend als disaster recovery as a service (DRaaS).
Je eerste disaster recovery-test is waarschijnlijk een eyeopener. Maar die maakt het wel eenvoudiger om issues te identificeren en op te lossen. Door elk kwartaal te testen, bevestig je voor jezelf dat je het juiste doet voor je organisatie.
Verificatie per dag
Voor de meesten is eens per drie maanden testen niet genoeg. Je weet tenslotte nooit wanneer je een back-up nodig hebt. Gelukkig kun je ervoor zorgen dat back-ups goed werken zonder daarvoor een volledige disaster recovery-test uit te voeren.
Als je werkt met een managed service provider (msp) of it-dienstverlener, zorg dan dat die een bewijs van je dagelijkse back-up heeft. Hoewel een e-mail of een rapportage van een back-up duidelijk kan laten zien dat de back-up heeft plaatsgevonden, hoeft dat niet noodzakelijkerwijs te betekenen dat een back-up ook goed is uitgevoerd. Om dit te vast te stellen, moet je de back-up starten als een virtuele machine en checken of hij werkt.
Een andere optie is om dagelijks screenshots te krijgen om te bewijzen dat je back-up heeft gewerkt. Een screenshot is voor jou of je msp en toont het loginscherm van de machine die is geback-upt. Dit zijn geen screenshots van je echte machine – het zijn screenshots van je back-ups! Het is het ultieme bewijs dat je systeem is geback-upt en dus te herstellen is.
De beste oplossingen bieden je een rustig gevoel: jouw organisatie is veilig tegen dataverlies en downtime. Het slechtste moment om erachter te komen dat een back-up niet heeft gewerkt, is als je hem daadwerkelijk nodig hebt. Disaster recovery-tests moeten dan ook onderdeel uitmaken van de algemene bedrijfsstrategie, ondersteund door jouw leverancier van bedrijfscontinuïteitsoplossingen.
Saad Alam, senior product marketing manager bij Datto
Los van het commerciële gehalte van deze publicatie kan het inderdaad niet vaag genoeg worden benadrukt. De investering in tijd en plan van disaster recovery verdienen zich bij het allereerste incident al meteen weer terug. Het meest belangrijke hier is niet meteen de uitvoering en de technische kant van het verhaal.
Het allerbelangrijkste is de wetenschap hoe belangrijk dit onderdeel is in de gehele IT ICT keten en het realiseren dat dit ook zeker in de keten en documentatie en plannen moeten worden opgenomen. Niet in de laatste plaats moeten DR plannen en protocollen met regelmaat worden getest en geoefend.
Mijn stelling is en blijft:
Als je geen backups maakt kan je net zo goed stoppen met waar je mee bezig bent.
De eerste – en meest belangrijke – stap in het DR verhaal is dus een classificatie van de processen zelf, en hoewel sommigen er anders over denken is e-mail geen primaire service maar 1 van de n communicatie processen als ik kijk naar de koppelvlakken spaghetti. Ik haal dit even aan omdat ik dit verhaal niet erg interessant vind, ‘Inverse Chain’ heeft meer mijn interesse als we kijken naar de peer-to-peer-remote-copy technologieën.
Nu heb ik mijn bedenkingen aangaande consistency groepen met alle microservices in de cloud maar je kunt soms dus beter stoppen met het maken van backups omdat er ondertussen andere granular restore technologies zijn.
Grappig is dat.
Het artikel zegt: “Disaster recovery-tests zijn o, zo belangrijk”.
Mijn vraag blijft: Waarom dan, elke avond maken we van elke schijf een simpele image, ook van onze cloud ‘klanten’.
Ik begrijp de ophef niet. Sinds 2000 nog nooit problemen gehad met onze (globaal) 20.000 interne klanten.
Recovery testen doen we altijd anders hoef je ook geen recovery te maken, dunkt mij.
Een beetje als: een brand moet je blussen anders brand het huis af (lees: rijdt niet te hard anders krijg je een boete – koop geen Porsche).