Back-ups die je ook echt terug kunt zetten als het misgaat

Vrijwel elke organisatie heeft back-ups. Er draait een taak, er staat een schema in een beheerpaneel en er komt af en toe een mailtje binnen dat niemand leest. De vraag die zelden gesteld wordt is een andere: wanneer heeft iemand voor het laatst geprobeerd er iets uit terug te halen? Meestal blijkt het antwoord nooit te zijn, en dat merk je pas op de ochtend dat een server niet meer opstart of een medewerker een map heeft leeggegooid.

Een back-up die nooit teruggezet is, is een aanname

Een groen vinkje betekent dat een taak zonder foutmelding is afgelopen. Het betekent niet dat de databank consistent is weggeschreven, dat de bestanden compleet zijn of dat je nog weet welk wachtwoord bij de opslag hoort. We komen alle drie de varianten tegen, meestal in dezelfde week dat ze nodig blijken.

Daarom begint dit werk bij ons met een terugzetactie in plaats van met een schema. We halen een bestaande back-up op, zetten hem terug op een testomgeving en kijken wat er daadwerkelijk uitkomt. Wat er ontbreekt weet je dan meteen, op een moment dat het niets kost. Werkt er iets niet, dan vertellen we je dat direct in plaats van het weg te schrijven in een rapport.

Hoeveel werk mag je verliezen en hoe lang mag je stilstaan

Dit zijn de twee vragen waar alles aan hangt, en ze verschillen per systeem. Een boekhouding die eens per nacht wordt weggeschreven is prima; van een orderpakket waar de hele dag doorheen gewerkt wordt is een nacht aan invoer kwijtraken een probleem. Andersom kan een intern wiki-tje best twee dagen plat liggen zonder dat iemand het merkt.

We lopen je systemen daarom een voor een langs en zetten er twee getallen naast: hoeveel werk je hoogstens mag verliezen en hoe lang je zonder dat systeem kunt. Die getallen bepalen de rest. Ze bepalen hoe vaak we kopiëren, waar de kopie staat en of we bij Managed databases met momentopnames van de transactielogboeken werken in plaats van met een nachtelijke dump. Het is geen technische discussie, het is een gesprek over je bedrijfsvoering.

Kopieën op meerdere plekken, ook buiten je eigen omgeving

Een back-up die op dezelfde machine staat als de data beschermt je tegen een verwijderd bestand en tegen niets anders. Brand, een defecte opslagcontroller of gijzelsoftware met beheerdersrechten nemen de kopie gewoon mee. We zorgen daarom altijd voor minstens één kopie buiten de omgeving die hij beschermt, met eigen inloggegevens die niet op de server zelf staan.

Die kopieën staan in onze beheerde omgevingen, op een andere plek dan de systemen die ze beschermen. Data blijft binnen de EU en jij blijft de eigenaar: stap je over, dan gaan de back-ups mee. Draait je omgeving op Dedicated servers, dan sluiten we het back-upverkeer aan op hetzelfde interne netwerk, zodat een volledige terugzetactie niet over de openbare verbinding hoeft. Moet je tijdens een storing doordraaien in plaats van herstellen, dan hoort daar High availability & failover bij; een back-up is een vangnet, geen tweede werkende omgeving.

Het herstelplan dat je een keer geoefend hebt

Op de dag zelf is er geen tijd om uit te zoeken wie waar bij kan en in welke volgorde de systemen terug moeten komen. Daarom leggen we het vooraf vast: wat eerst aan de beurt is, wie belt wie, waar de inloggegevens liggen en wat je klanten intussen te horen krijgen. Twee kantjes, geen map die niemand openslaat.

Dat plan oefenen we periodiek, en na afloop passen we het aan op wat er in de praktijk misging. Ondertussen bewaken onze systemen de back-uptaken en gaat een mislukte taak via een afgesproken escalatie naar een mens. Zo weet je waar je aan toe bent voordat het misgaat.