Niet of, maar wanneer, en vooral: hoe lang dan. De meeste organisaties hebben wel iets van een back-up en bijna niemand weet hoeveel uur er tussen de storing en het weer draaien zit. Dat getal is de hele oefening.
Het eerste is het herstelpunt: hoeveel werk mag je kwijtraken. Draait je back-up elke nacht, dan is dat in het slechtste geval een dag. Het tweede is de hersteltijd: hoe lang mag het duren voor je weer werkt. Die twee zijn onafhankelijk van elkaar, en het is de combinatie die de prijs bepaalt.
Het nut van die twee getallen is dat ze een technische discussie omzetten in een zakelijke. Een dag werk kwijt is voor een boekhouding vervelend en voor een kassa onaanvaardbaar. Vier uur stilstand is voor een interne tool geen ramp en voor een webshop op zaterdag wel. Zodra de getallen per systeem op tafel liggen, volgt de oplossing vanzelf, en zie je ook waar je nu te veel betaalt voor zekerheid die je daar niet nodig hebt.
Daarna komt de onaangename vraag: klopt wat je nu hebt met die getallen. Bijna altijd is het antwoord nee, en bijna altijd zit het verschil niet in de gegevens maar in alles eromheen. De databank staat er wel, maar de sleutels, de certificaten, de dns en de afspraken met de leverancier stonden nergens.
Zes stukken tussen een systeem dat stilvalt en een organisatie die weer draait.
Een kopie op dezelfde server, bij dezelfde leverancier of in hetzelfde account is geen kopie maar een tweede exemplaar van hetzelfde risico. De kopie staat elders, bij een andere partij, met eigen sleutels die de bron niet kent.
Microsoft houdt je omgeving in de lucht, niet je gegevens tegen jezelf. Een mailbox die iemand leegmaakt of een SharePoint die iemand herstructureert is na de bewaartermijn weg. Een back-up buiten 365 vangt dat op.
Een back-up die nooit teruggezet werd, is een vermoeden. Een herstel op een lege omgeving, met de klok erbij, maakt er een cijfer van: zoveel uur, en dit stuk bleek te ontbreken.
Een versie die stukloopt hoort niet hersteld te worden uit een back-up maar teruggezet te worden naar de vorige. Dat vraagt dat de uitrol herhaalbaar is en dat migraties op de databank vooruit en achteruit kunnen.
Alles dubbel uitvoeren kost het dubbele en levert zelden het dubbele op. Wat wel loont is weten welk stuk de hele keten stillegt, en net dat stuk dubbel zetten. Meestal is dat de databank of de dns, en niet de webserver.
Op het moment zelf is de persoon die het systeem gebouwd heeft misschien met vakantie. Een blad met wie je belt, waar de sleutels staan, in welke volgorde je herstelt en wat je tegen klanten zegt, is dan meer waard dan een extra server.
Vijf dingen die het verschil maken tussen een back-up die bestaat en een herstel dat werkt.
Hoeveel werk mag je kwijtraken, en hoe lang mag het duren voor je weer draait. Beantwoord in uren, per systeem, en niet in het algemeen. Een boekhouding van gisteren is doorgaans te overleven; een kassa die een halve dag stilstaat is dat niet. Zonder die twee getallen is elke back-upkeuze een gok.
Een bestand dat gesynchroniseerd wordt, is op alle toestellen even snel weg als het op een ervan verwijderd wordt. De prullenbak en de versiegeschiedenis vangen een ongelukje op, geen versleuteling en geen opruimactie die drie weken eerder begon. Dat is de meest voorkomende vergissing die ik tegenkom.
Ransomware zoekt naar wat er van de besmette machine bereikbaar is, inclusief de netwerkschijf waar de back-up op staat. Een kopie die enkel te schrijven en niet te overschrijven is, of die met eigen sleutels van elders opgehaald wordt, overleeft dat wel.
Een herstel dat je op het draaiende systeem uitprobeert, test enkel of het bestand leesbaar is. Wat je wil weten is of je vanaf niets weer draaiend raakt: met de configuratie, de sleutels, de certificaten en de dns erbij. Dat zijn net de dingen die niemand mee back-upt.
Wie beslist dat het een incident is, wie de klanten verwittigt, wanneer je overschakelt in plaats van te blijven herstellen. Vooraf een half uur, achteraf een halve dag. Het draaiboek mag kort zijn, het moet alleen bestaan en op papier staan, want het intranet ligt er dan misschien ook uit.
Niet bij de gegevens. De databank staat er doorgaans wel, ergens. Wat ontbreekt is de omgeving eromheen: welke versie draaide er, welke instellingen stonden erin, welke sleutels hoorden erbij, welke dns wees waarheen, en bij welke leverancier staat het account waarmee je daaraan kan. Dat zijn vijf dingen die niemand back-upt omdat ze niet in een map staan.
De tweede plek waar het misloopt is de mens. Een herstel dat drie uur duurt bij iemand die het al eens deed, duurt een werkdag bij iemand die het draaiboek voor het eerst leest. Daarom hoort er in dat draaiboek geen technische samenvatting te staan maar een reeks stappen die iemand kan volgen zonder de bouwer te bellen, en hoort het minstens een keer per jaar echt gevolgd te worden.
Kan je die vraag niet in uren beantwoorden, dan is dat op zich het antwoord. Een doorlichting van een halve dag levert doorgaans al de twee of drie gaten op die er echt toe doen. Stuur gerust een bericht.
De kant van de servers en de uitrol staat bij devops en hosting, de werkplek bij Microsoft 365, en weten dat er iets stuk is voor de klant belt bij meten en fouten opvolgen.