In De 3-2-1 Backup Strategie schreef ik, in de sectie over 3-2-1-1-0, een bewering op: een backup die je niet hebt getest is geen backup, het is een aanname. Dat is een makkelijke zin om op te schrijven. Ik was je nog schuldig wat die test dan precies is.
Het verschil zit niet in de restore
Iedereen kan één keer een bestand terugzetten en zich even gerustgesteld voelen. Dat gevoel is binnen een week verdampt, en je kunt het aan niemand laten zien.
Wat overblijft is een record. De datum, wat er is teruggezet, hoe lang het duurde, of het werkte, en wat er niet werkte. Zonder datum is een hersteltest een herinnering. Met datum is het bewijs — voor jezelf, voor je bestuur, en voor wie het ooit komt natrekken.
Dat is de kern: het record is het opgeleverde ding, niet de restore zelf. De restore is het werk dat je toch al doet. Het record is wat dat werk omzet in iets dat standhoudt.
Een bestand is geen dienst
“Ik heb een bestand teruggezet” en “ik heb een dienst hersteld” zijn twee verschillende tests, en de eerste zegt bijna niets over de tweede.
Een los bestand terugzetten test of je backup leesbaar is. Een dienst herstellen — een database, een mailserver, een hele machine — test of alles eromheen ook klopt: configuratie, afhankelijkheden, volgorde van opstarten, wachtwoorden die ergens anders staan dan je dacht. Dat zijn andere lagen, en ze falen op andere plekken.
Wie alleen ooit een bestand heeft teruggehaald, weet dus niet of hij een dienst kan herstellen. Hij weet alleen dat zijn backup niet corrupt is.
Dat onderscheid is precies waarom het record per type restore apart moet vermelden wat er is teruggezet. “Restore getest” zonder dat detail verbergt welke van de twee tests je eigenlijk hebt gedaan.
Waar de tijd echt gaat zitten
De meest voorkomende teleurstelling die ik zie is niet dat de restore mislukt. Het is dat hij lukt, maar dat niemand meer precies weet hoe. De doorlooptijd wordt dan niet bepaald door het kopiëren van data — dat gaat vanzelf — maar door uitzoeken welke knop, welk wachtwoord, welke volgorde.
Dat is precies wat een geschreven record oplost. Niet omdat het de restore sneller maakt de eerste keer, maar omdat de volgende keer niemand meer hoeft te zoeken.
De eerste hersteltest is dan ook bijna altijd de traagste, en dat is prima. Het punt van opschrijven is niet dat de eerste keer al vlekkeloos gaat. Het punt is dat de tweede keer sneller gaat dan de eerste, en dat je dat kunt aantonen in plaats van beweren.
Wat je opschrijft
Een simpel formulier, geen formulier-ontwerp. Zes velden, elke keer opnieuw ingevuld:
Datum + uitgevoerd door:
Wat is teruggezet (bestand / dienst / hele machine):
Vanaf welke kopie:
Doorlooptijd (van besluit tot werkend):
Geverifieerd werkend? (ja/nee — niet alleen "aanwezig")
Wat ging mis of duurde langer dan verwacht:Dat laatste veld is het veld dat mensen overslaan. Het is ook het veld dat de volgende test beter maakt. Een hersteltest zonder genoteerde haperingen is geen test, het is een vinkje.
De nul in 3-2-1-1-0
In januari noemde ik de uitgebreide variant van de regel: drie kopieën, twee media, één offsite, één air-gapped of immutable, en nul fouten na verificatie. Die verificatie is precies dit record. Geen fouten betekent: getest, gedateerd, en op papier gezet — niet: waarschijnlijk in orde.
Waar dit in mijn werk landt
Op grotere implementatietrajecten hoort een uitgevoerde hersteltest bij de oplevering: met datum, doorlooptijd en uitkomst op papier. Niet bij elke opdracht — dat zou het record uithollen tot een afvinklijstje. Wel bij de trajecten waar het ertoe doet of iemand na jou nog weet wat er gebeurd is.
Een restore die je één keer deed en niet opschreef, ben je binnenkort weer kwijt. Een restore die op papier staat, kun je morgen herhalen — en dat is het enige dat telt op het moment dat je het echt nodig hebt.