“We maken back-ups” is een van de meest misleidende zinnen in IT. Ze klinkt geruststellend, maar zegt niets over de vraag die er werkelijk toe doet: kan je, wanneer het nodig is, ook effectief en tijdig herstellen?
De meeste organisaties die getroffen worden door dataverlies, hadden wel degelijk een back-upoplossing. Het probleem zit zelden bij de afwezigheid van back-ups, maar bij drie klassieke faalscenario’s die zich telkens opnieuw voordoen, in vrijwel elke sector.
Drie scenario’s die telkens terugkomen
1. De back-up bestaat, maar is nooit getest
Een back-up job die “succesvol” wordt gerapporteerd, betekent niet dat de data ook werkelijk herstelbaar is. Configuratiefouten, incomplete back-up sets, corrupte bestanden of vergeten applicaties (denk aan een database die net buiten het back-ups chema valt) blijven vaak onopgemerkt tot het moment van de restore. Een back-up die nooit is getest, is in de praktijk een aanname, geen garantie.
2. De restore duurt veel langer dan verwacht
Zelfs wanneer een back-up technisch in orde is, verloopt het herstel in de praktijk vaak trager dan voorzien. Netwerkbandbreedte, de volgorde waarin systemen moeten worden hersteld (een applicatie die afhankelijk is van een database-server die nog niet online is, bijvoorbeeld), en het ontbreken van een gedocumenteerd herstelplan zorgen ervoor dat een geschatte hersteltijd van enkele uren in de praktijk een volle werkdag of langer kan duren.
Recent onderzoek van Veeam toont dat de gemiddelde hersteltijd na een ransomware-aanval oploopt tot meer dan drie weken, en dat amper één op tien getroffen organisaties meer dan 90% van hun data effectief kan herstellen.
3. De back-up is zelf geïnfecteerd of versleuteld
Moderne ransomware-aanvallen zijn niet gericht op productiedata alleen. Aanvallers zoeken bewust naar back-upinfrastructuur, om te vermijden dat het slachtoffer kan herstellen zonder losgeld te betalen.
Uit datzelfde Veeam-onderzoek blijkt dat bij 89% van de organisaties die een ransomware-aanval ondergingen, de aanvallers ook actief de back-upomgeving probeerden te compromitteren. Toch gebruikt slechts een minderheid van organisaties immutable (onveranderbare) opslag om dat risico structureel weg te nemen.
De 3-2-1-1-0-regel als praktisch antwoord
Er bestaat geen wondermiddel tegen deze drie scenario’s,maar er bestaat wel een beproefde architecturale vuistregel die de risico’sstructureel beperkt: de 3-2-1-1-0-regel.
- 3 kopieën van je data: de productiedata plus minstenstwee back-upkopieën.
- 2 verschillende soorten opslagmedia: bijvoorbeeld lokale disk-opslag én cloud-of objectopslag, zodat één type storagefout niet al je kopieën tegelijktreft.
- 1 kopie offsite: fysiek gescheiden van jeproductieomgeving, zodat een lokaal incident
- (brand, diefstal, een volledige site-uitval) niet ook jeback-ups vernietigt.
- 1 kopie offline of immutable: niet toegankelijk ofniet aanpasbaar voor een aanvaller die toegang heeft tot jeproductieomgeving, zelfs niet met administrator-rechten.
- 0 fouten: geregelde, gedocumenteerde en geverifieerderestore-testen. Niet enkel een groen vinkje in een dashboard.
Die laatste twee elementen zijn de voornaamste evolutie tenopzichte van de klassieke 3-2-1-regel, en precies de elementen die in de praktijk het vaakst ontbreken.
Wat betekent dat in de praktijk?
Bij Epact combineren we, afhankelijk van de omgeving, Veeam Backup & Replication of Veeam Data Cloud met immutable objectopslag (onder andere via Wasabi, met Object Lock-functionaliteit) voor de offsite en onveranderbare kopie.
Dat betekent dat een back-up, eenmaal geschreven, gedurende de ingestelde retentieperiode door niemand nog kan worden gewijzigd of verwijderd, ook niet door een aanvaller die volledige toegang heeft verworven tot je productieomgeving of zelfs tot het back-upbeheer zelf.
Testen is geen momentopname, maar een gewoonte
Een restore-test die één keer per jaar gebeurt, tijdens een rustig moment, met een niet-kritieke applicatie, zegt weinig over hoe je omgeving zich gedraagt tijdens een echt incident. Een volwassen back-upstrategie voorziet in periodieke, gedocumenteerde restore-testen opverschillende soorten workloads (bestandsservers, databases, volledige virtuele machines), met bijhorende meting van de effectieve hersteltijd. Alleen zo weet je of je RTO-doelstelling ook werkelijk haalbaar is, in plaats van een getal op papier.
Conclusie: een back-up die nooit getest is, is geen back-up
De drie faalscenario’s in dit hoofdstuk hebben één ding gemeen: ze worden pas zichtbaar op het moment dat je ze het minst kan gebruiken. Een back-upstrategie die structureel steunt op meerdere, gescheiden en onveranderbare kopieën, gecombineerd met geregelde en gedocumenteerde restore-testen, is het verschil tussen een organisatie die een incident overleeft en eenorganisatie die er weken over doet om weer overeind te komen, als dat al lukt.
Deze blog maakt deel uit van een breder verhaal rond businesscontinuity dat we helemaal uit de doeken doen in onze “Business Continuity Gidsvoor CIO’s en IT-Managers.”