Back-ups maken doet iedereen, restoren bijna niemand

Een back-up die nooit getest is

Wat ik bij nieuwe klanten vaak aantref: er is een back-up-procedure ingericht, hij draait, hij maakt keurig bestanden aan. Tot zover niets aan de hand. Wat er vervolgens niet is: een testprocedure. Geen documentatie over hoe je een restore uitvoert. Geen planning voor periodieke tests. Niemand die ooit heeft gecontroleerd of die back-up ook daadwerkelijk terug te zetten is.

En dan komt het moment dat je hem nodig hebt. Dat is niet het moment om erachter te komen dat het niet werkt.

De tapedrive die drie maanden out of sync was

Ik heb het zelf meegemaakt, vroeg in mijn carrière. We werkten nog met tapes en op een gegeven moment bleek de kop van de recorder out of sync te zijn. Niet een beetje, volledig. Geen enkele tape was nog bruikbaar.

Het ergste: het had al drie tot vier maanden zo gelopen. Drie tot vier maanden lang dachten we dat we back-ups hadden. Hadden we niet. We hebben er uiteindelijk een engineer bij moeten halen om alles weer te restoren, en dat heeft lang geduurd. Al die tijd zaten we zonder vangnet.

Als we regelmatig hadden getest, waren we er binnen een week achter gekomen in plaats van na drie maanden. Dat is een les die je maar één keer hoeft te leren.

Frequentie afstemmen op je verwerkingssnelheid

De vraag die elke organisatie zichzelf moet stellen: hoeveel data kun je je veroorloven om kwijt te raken? Als je back-up eenmaal per dag draait, ben je bij een crash maximaal een dag aan data kwijt. Draai je hem eenmaal per uur, dan is het een uur. Voor sommige organisaties is dat prima. Voor een omgeving waar continu transacties worden verwerkt, is het veel te veel. Stem je back-upfrequentie af op je verwerkingssnelheid en op wat jouw organisatie als acceptabel dataverlies beschouwt. Wij adviseren in de meeste gevallen tussentijdse transaction-logback-ups, die alleen de wijzigingen vastleggen sinds de vorige back-up. Hoe vaak je die draait (elk kwartier, elke vijf minuten, continu) hangt af van je situatie.

De full back-up blijft op schema, de tussentijdse back-ups vullen hem aan. Zo beperk je je maximale dataverlies tot precies het interval dat je zelf hebt gekozen. Die keuze maak je bewust, niet pas achteraf als je erachter komt dat je te veel kwijt bent.

Hoe je restores test zonder productie te raken

Het liefst test je restores op een dedicated machine die daar specifiek voor bedoeld is. Zo houd je je productieomgeving schoon en kun je rustig controleren of alles klopt.

Er is ook een slimmere variant die ik steeds vaker zie: organisaties die een aparte queryomgeving hebben waar alleen gelezen wordt. Die omgeving vullen ze met de back-ups van productie. Elke nacht worden alle productiedatabases gebackupt, en die back-ups worden automatisch ingeladen in de queryomgeving. De volgende dag gebruiken medewerkers die omgeving voor rapportages.

Het mooie daarvan: je test je back-up- en restoreproces elke nacht, zonder dat iemand er apart bij hoeft stil te staan. Werkt de restore niet, dan merk je dat de volgende ochtend doordat de queryomgeving niet beschikbaar is. Dat is een stuk minder pijnlijk dan erachter komen tijdens een storing.

Daarbovenop kun je zo nu en dan een datacompare draaien: de data in je queryomgeving vergelijken met productie. Dat hoeft niet dagelijks, maar periodiek even checken of wat je hebt gerestored ook klopt met wat er staat. Dat hele proces is te automatiseren met scripts en een scheduler.

Vijf van de zes systemen gecrasht, back-ups redden de zaak

Onlangs crashten bij een klant vijf van de zes productiesystemen door een infrastructuurstoring. Gelukkig gebeurde het in het weekend, waardoor er weinig gebruikers actief waren en het dataverlies beperkt bleef.

Alle productiesystemen zijn teruggezet met de dagelijkse back-ups. Het restoreproces was gedocumenteerd, geautomatiseerd en getest. Het werkte. De data die in het gat tussen de laatste back-up en de crash viel, kon deels worden gereconstrueerd uit gekoppelde systemen.

Achteraf waren ze enorm opgelucht dat het hele back-up- en restoreproces op orde was. Wij hadden daar aan meegebouwd en meegeschreven. Zonder dat voorwerk was de schade vele malen groter geweest.

Het ongeschoven kindje van IT

Het back-up-proces is een ongeschoven kindje. Iedereen weet dat het er moet zijn, maar de urgentie ontbreekt zolang het goed gaat. En in onze wereld gaat het meestal goed. Dan schuift het op de prioriteitenlijst naar beneden: “Oh ja, dat komt nog wel.” Of: “Dat richten we later wel in.”

De grote organisaties hebben het doorgaans op orde. Bij de kleinere bedrijven is het wisselender. Daar wordt het pas een prioriteit als het misgaat. En dan leer je de les op de harde manier.

Dat is geen schande. Ik vind dat je het moet zien als een les. Het overkomt je een keer, en daarna richt je het goed in. Waar ik wel moeite mee heb is als het een tweede keer gebeurt.

Advies aan de IT-manager

Als ik zelf IT-manager was, zou ik het volgende willen. Regelmatige steekproeven: laat zien dat een restore werkt, niet alleen op papier maar in de praktijk. Zorg dat de documentatie klopt en actueel is, want er is niets zo veranderlijk als IT. Er hoeven maar een paar dingen te verschuiven in je proces en als dat niet gedocumenteerd is, sta je bij een storing te zoeken.

Plan uitwijktests vaker dan één keer per jaar. Veel organisaties doen jaarlijks een uitwijktest waarbij ze simuleren dat een datacenter uitvalt en kijken of de failover werkt. Dat is goed, maar voor je back-up- en restoreproces is het te weinig. Doe het elk kwartaal, of op zijn minst elk halfjaar.

Automatiseer waar je kunt. Het testen van restores hoeft geen handmatig klusje te zijn. Met de juiste scripts en scheduling draait het op de achtergrond en krijg je een seintje als er iets niet klopt. Bespreek het met je team. Maak het een vast onderdeel van jullie overleg, niet iets dat erbij komt als er tijd over is.

Hoe concreet dat kan zijn, bewees de brand bij NorthC Datacenters in Almere in mei dit jaar. Organisaties als de NAK zagen hun volledige dienstverlening stilvallen omdat ze niet bij hun data konden. Geen certificaten, geen veldwerk, geen labwerk. Wekenlang. Het herstel duurde weken.

Een applicatie herbouw je, je data niet

Je hoort steeds vaker dat de database “gewoon een commodity” is. Ontwikkelaars die zeggen: “Doe maar een database, gooi mijn data er maar in.” Die houding onderschat wat er op het spel staat. Een applicatie kun je herbouwen. Je data niet. En de enige manier om je data te beschermen is een back-upproces dat niet alleen draait, maar dat je ook hebt bewezen dat het werkt.

Wil je weten hoe jouw back-up- en restoreproces ervoor staat? Neem contact op voor een vrijblijvend gesprek. We kijken graag met je mee.