Hoeveel backups heb je écht nodig? Een gids voor je retentiestrategie

De 3-2-1-regel als startpunt

De 3-2-1-regel is een al lang bestaande, industriestandaard basis voor backupstrategie, niet gebonden aan één specifiek product of provider: houd in totaal 3 kopieën van je data aan, sla ze op 2 verschillende soorten media of storage-systemen op, en bewaar 1 kopie offsite, weg van de primaire locatie. De logica achter elk cijfer is eenvoudig. Drie kopieën betekent het origineel plus twee backups, zodat een enkele storing je nooit zonder redundantie zet. Twee verschillende mediatypen beschermen tegen een storing die in één klap een hele categorie storage kan uitschakelen, denk aan een RAID-controllerfout of een specifieke bug in een storage-systeem. Eén kopie offsite beschermt tegen alles wat de hele primaire locatie treft: brand, diefstal, een incident op datacenterniveau, of simpelweg een storing die de primaire locatie volledig offline haalt.

3-2-1 is een startkader, geen rigide formule. Het dwingt je om na te denken over waar een single point of failure nog steeds zowel je live data als je backups in één keer zou kunnen wegvagen, en om die koppeling bewust te doorbreken.

Retentievensters instellen: hoe ver terug moet je écht kunnen gaan?

Retentie is geen los cijfer, het zijn eigenlijk meerdere verschillende problemen die toevallig hetzelfde woord gebruiken. Bepaal voor elk van deze situaties apart hoe ver terug je zou moeten kunnen herstellen, want ze vragen om verschillende retentievensters:

• Ongewenste verwijdering. Iemand verwijdert het verkeerde bestand of dropt de verkeerde tabel. Dit valt meestal snel op, dus een retentievenster van een paar dagen is vaak genoeg, zolang backups frequent genoeg zijn dat je niet veel werk verliest tussen de verwijdering en de meest recente backup daarvoor.
• Traag ontdekte corruptie. Sommige problemen, zoals een subtiel corrupte database, een mislukte migratie, of een bug die stilletjes verkeerde data wegschrijft, vallen pas na verloop van tijd op. Tegen de tijd dat je het ontdekt, bevatten je meest recente backups mogelijk al diezelfde corruptie. Dit vraagt om een retentievenster van enkele weken, zodat je een schoon herstelpunt hebt van vóór het moment waarop het probleem begon.
• Compliance-gedreven retentie. Sommige data moet om wettelijke of contractuele redenen veel langer opvraagbaar blijven, los van een daadwerkelijk operationeel incident. Dit is weer een andere eis, meestal maanden of langer, en wordt bepaald door beleid in plaats van door hoe snel problemen doorgaans aan het licht komen.

Als je dit als één instelling behandelt, betaal je meestal onnodig om alles voor het langste venster te bewaren, of ontdek je te laat dat het specifieke herstelpunt dat je nodig had al is verlopen.

Snapshot-achtige backups vs. capaciteitsgerichte backup storage

Deze lossen verschillende delen van hetzelfde probleem op, en de meeste strategieën in de praktijk gebruiken allebei in plaats van er één te kiezen:

• Snapshot-achtige backups zijn snel en frequent, en worden meestal maar kort bewaard. Ze zijn gebouwd voor snelle rollback: de laatste paar uur of dagen aan wijzigingen ongedaan maken zonder gedoe. Zie Backups en snapshots: wat is het verschil voor hoe dit in de praktijk werkt.
• Capaciteitsgerichte backup storage is minder frequent en gebouwd voor langere retentie, en is de kostenefficiëntere plek om data te bewaren die je weken, maanden of langer moet vasthouden, in plaats van voor een rollback op dezelfde dag. Zie Backup Storage inzetten als disaster-recoverydoel.

Het juiste gereedschap koppelen aan het retentieprobleem dat het daadwerkelijk oplost, snelle rollback versus herstel over een lang venster, houdt zowel de kosten als de complexiteit lager dan wanneer je één systeem beide taken goed probeert te laten doen.

Waarom het testen van een restore net zo belangrijk is als het maken van de backup

Een backup waar je nog nooit uit hersteld hebt, is een aanname, geen garantie. Backups kunnen stilletjes falen: een taak die succes meldt maar een al corrupt bestand heeft gebackupt, rechten die een restore blokkeren op het moment dat je die juist nodig hebt, een incomplete backup die niemand opmerkte omdat niemand keek. De enige manier om te weten of een backup echt bruikbaar is, is eruit herstellen en het resultaat controleren. En dat af en toe doen, niet pas wanneer een echt incident de vraag afdwingt, is wat "we hebben backups" verandert in iets waar je onder druk daadwerkelijk op kunt vertrouwen. Dit is net zo belangrijk wanneer je een dienst afbouwt: zie Wat er met je data gebeurt als je een dienst opzegt voor wat je al ergens anders veiliggesteld moet hebben vóór dat moment.