Database recovery is een onderwerp dat pas urgent lijkt als het al te laat is. Toch is het voor elke organisatie die met kritieke data werkt essentieel om te begrijpen hoe herstel in de praktijk werkt. De term “7 data recovery” duikt regelmatig op in discussies over database recovery, maar wat betekent het precies en welke methoden vallen eronder?
In dit artikel beantwoorden we de meest gestelde vragen over database recovery: van de zeven veelgebruikte herstelmethoden tot veelgemaakte fouten die organisaties duur komen te staan. Of je nu werkt met SQL Server, Oracle of PostgreSQL, de principes zijn grotendeels universeel toepasbaar.
Welke 7 methoden vallen onder data recovery?
De zeven methoden die onder data recovery vallen, zijn: volledig backupherstel, differentieel herstel, transactielogboekherstel, point-in-time recovery, bestandsgroepherstel, paginaherstel en online herstel. Samen vormen ze een gelaagd systeem waarmee databasebeheerders voor vrijwel elke situatie een passende hersteloptie hebben.
Elke methode heeft zijn eigen toepassingsgebied. Volledig backupherstel is de meest basale vorm en herstelt de database naar de staat van de laatste volledige backup. Differentieel herstel vult dat aan door alleen de wijzigingen sinds die laatste volledige backup terug te zetten. Transactielogboekherstel gaat nog een stap verder en maakt herstel tot op het niveau van individuele transacties mogelijk.
De overige vier methoden zijn meer gespecialiseerd. Paginaherstel is waardevol wanneer slechts een klein deel van de database beschadigd is en je niet de hele omgeving wilt terugzetten. Bestandsgroepherstel werkt op het niveau van afzonderlijke bestandsgroepen binnen een database, wat handig is in grote omgevingen. Online herstel maakt het mogelijk om een deel van de database te herstellen terwijl de rest beschikbaar blijft voor gebruikers. Point-in-time recovery, tot slot, laat je de database terugzetten naar een exact tijdstip, wat met name relevant is na menselijke fouten.
Hoe werkt herstel via transactielogboeken in de praktijk?
Herstel via transactielogboeken werkt door alle geregistreerde databasewijzigingen in chronologische volgorde opnieuw toe te passen of terug te draaien. Het transactielogboek legt elke insert, update en delete vast, waardoor je de database kunt herstellen tot op een specifiek tijdstip of een specifieke transactie.
In de praktijk verloopt dit proces in een vaste volgorde. Eerst herstel je de meest recente volledige backup. Vervolgens pas je eventuele differentiële backups toe. Daarna speel je de transactielogboeken in chronologische volgorde terug, tot het gewenste herstelpunt is bereikt.
Wat heb je nodig voor logboekherstel?
Voor succesvol transactielogboekherstel zijn drie dingen onmisbaar: een ononderbroken keten van logboekbestanden, de juiste recovery-modus op de database (bij SQL Server is dat de modus “Full” of “Bulk-logged”) en voldoende opslagruimte voor de logbestanden. Als een schakel in de logboekenketen ontbreekt, is herstel tot dat punt niet meer mogelijk. Dit is een van de meest voorkomende redenen waarom herstel mislukt: logboeken worden niet bewaard of worden te vroeg overschreven.
Wat is het verschil tussen volledige en differentiële recovery?
Volledige recovery herstelt de database volledig op basis van een volledige backup, inclusief alle data op het moment van die backup. Differentiële recovery herstelt alleen de wijzigingen die zijn gemaakt na de laatste volledige backup, waardoor het proces sneller verloopt, maar altijd afhankelijk blijft van een eerdere volledige backup als fundament.
Het praktische verschil zit vooral in de hersteltijd en de hoeveelheid data die je terugzet. Een volledige backup is groter en duurt langer om terug te zetten, maar is volledig zelfstandig. Een differentiële backup is kleiner en sneller, maar kan nooit zonder de bijbehorende volledige backup worden gebruikt.
Voor de meeste organisaties is een combinatie van beide de slimste aanpak. Een wekelijkse volledige backup, gecombineerd met dagelijkse differentiële backups, zorgt voor een goede balans tussen hersteltijd en opslagkosten. Hoe kleiner het interval tussen backups, hoe minder data je maximaal kwijtraakt bij een incident, wat direct de RPO (Recovery Point Objective) beïnvloedt.
Wanneer kies je voor point-in-time database recovery?
Point-in-time database recovery is de juiste keuze wanneer je de database wilt herstellen naar een exact tijdstip, meestal na een menselijke fout zoals een onbedoelde delete of een foutief uitgevoerde update. In plaats van alle data te verliezen tot de vorige backup, herstel je de database naar het moment vlak voordat de fout plaatsvond.
Dit type herstel is bijzonder waardevol in situaties waarin een gebruiker of applicatie per ongeluk grote hoeveelheden data heeft verwijderd of overschreven. De fout is dan al doorgevoerd in de database, maar via de transactielogboeken kun je precies terugkeren naar het tijdstip net daarvoor.
Point-in-time recovery vereist wel dat je in de juiste backupmodus werkt en dat de transactielogboeken intact zijn. Zonder een ononderbroken logboekenketen is dit type herstel niet uitvoerbaar. Het is dan ook verstandig om van tevoren te testen of deze methode daadwerkelijk werkt in jouw specifieke omgeving, in plaats van dit voor het eerst te proberen tijdens een crisis.
Welke fouten maken organisaties bij database recovery?
De meest gemaakte fouten bij database recovery zijn: nooit testen of backups ook daadwerkelijk herstelbaar zijn, geen gedocumenteerde herstelprocedure hebben, de logboekenketen niet bewaken en geen duidelijke afspraken maken over RPO en RTO. Elk van deze fouten kan een herstelproces ernstig vertragen of volledig onmogelijk maken.
Een backup die nooit getest is, is geen backup. Dit klinkt als een open deur, maar in de praktijk voeren de meeste organisaties hersteltests vrijwel nooit uit. Het gevolg is dat fouten in de backupstrategie pas aan het licht komen op het moment dat herstel echt nodig is.
Gebrek aan documentatie
Een tweede veelgemaakte fout is het ontbreken van duidelijke herstelprocedures. Onder druk, midden in een incident, is er geen tijd om te improviseren of te zoeken naar de juiste stappen. Een gedocumenteerd herstelplan, dat ook door andere teamleden begrepen en uitgevoerd kan worden, is geen luxe maar een noodzaak.
Geen heldere RPO- en RTO-afspraken
Tot slot onderschatten veel organisaties het belang van concrete afspraken over hoeveel dataverlies acceptabel is en hoe snel systemen weer operationeel moeten zijn. Zonder die parameters is er geen basis om de herstelstrategie op te bouwen en is het onmogelijk om te beoordelen of de huidige aanpak voldoende is.
Hoe Brander Company helpt bij database recovery
Wij bij Brander Company weten uit ervaring dat een goede herstelstrategie begint lang voordat er iets misgaat. We helpen organisaties hun database recovery op orde te brengen in omgevingen zoals SQL Server, Azure SQL, Oracle en PostgreSQL. Concreet doen we dat door:
- Het in kaart brengen van de juiste RPO en RTO op basis van jouw specifieke bedrijfsrisico’s
- Het opzetten en valideren van een volledige backupstrategie, inclusief transactielogboeken
- Het uitvoeren van regelmatige, gestructureerde hersteltests, zodat je zeker weet dat je backups ook echt werken
- Het opstellen van heldere, gedocumenteerde herstelprocedures die ook onder druk bruikbaar zijn
- Het begeleiden van het herstelproces bij een daadwerkelijk incident, van analyse tot volledige operationele terugkeer
We geloven niet in tijdelijke oplossingen of onduidelijk jargon. We bouwen robuuste, toekomstbestendige recoverystrategieën die aansluiten op hoe jouw organisatie werkt. Wil je weten hoe jouw huidige herstelstrategie ervoor staat? Neem contact met ons op voor een vrijblijvend gesprek.
