Wanneer een database uitvalt of beschadigd raakt, hoor je al snel twee termen door elkaar gebruikt worden: database restore en database recovery. Toch zijn het twee fundamenteel verschillende stappen in het herstelproces, elk met een eigen rol en volgorde. Het begrijpen van dit onderscheid is niet alleen nuttig voor IT-professionals, maar ook voor iedereen die verantwoordelijk is voor de beschikbaarheid van bedrijfsdata.
In dit artikel beantwoorden we de meest gestelde vragen over databaseherstel, zodat je precies weet wat er gebeurt als het misgaat, welke fouten je wilt vermijden en wanneer het verstandig is om hulp in te schakelen.
Wat houdt een database restore precies in?
Een database restore is het fysiek terugplaatsen van een back-upbestand naar een databasesysteem. Bij een restore kopieer je opgeslagen data van een back-upmedium terug naar de server, waarna de database in een consistente staat wordt teruggebracht, zoals die bestond op het moment van de back-up.
Een restore is dus altijd een bewuste, handmatige actie. Een databasebeheerder kiest een specifiek back-uppunt en plaatst de data terug. Dit kan een volledige back-up zijn, een differentiële back-up of een reeks transactielogboeken. De keuze hangt af van hoe recent de data moet zijn en hoe snel het herstel moet plaatsvinden.
Belangrijk om te begrijpen: na een restore is de database nog niet per se beschikbaar voor gebruikers. De restore is slechts de eerste stap. Pas als het systeem de data heeft gevalideerd en de integriteit heeft bevestigd, kan de database in gebruik worden genomen.
Wat is database recovery en wanneer vindt het plaats?
Database recovery is het automatische proces waarbij het databasesysteem zelf de consistentie van de data waarborgt na een restore of na een onverwachte afsluiting. Recovery vindt altijd plaats na een restore, maar ook automatisch bij het herstarten van een database na een crash.
Tijdens recovery doorloopt het systeem het transactielogboek en voert het twee acties uit:
- Roll forward: transacties die volledig waren afgerond maar nog niet waren weggeschreven naar de databestanden, worden alsnog doorgevoerd.
- Roll back: transacties die niet volledig waren afgerond op het moment van de crash of back-up, worden ongedaan gemaakt.
Dit proces zorgt ervoor dat de database in een consistente, betrouwbare staat terechtkomt. Recovery is in de meeste gevallen onzichtbaar voor de eindgebruiker, maar het is de cruciale schakel die bepaalt of de data daadwerkelijk bruikbaar en betrouwbaar is na het herstelproces.
Kunnen restore en recovery zonder elkaar plaatsvinden?
Recovery kan plaatsvinden zonder een voorafgaande restore, maar een restore is altijd zinloos zonder recovery. Dit is het kernverschil in de relatie tussen beide processen.
Recovery treedt automatisch op bij elke herstart van een database, ook als er geen back-up is teruggezet. Denk aan een server die plotseling uitvalt door een stroomstoring: zodra de database opnieuw opstart, voert het systeem automatisch een recovery uit op basis van het transactielogboek. Er is geen restore nodig geweest.
Andersom geldt: een restore zonder recovery levert een database op die technisch gezien in een onbepaalde staat verkeert. Sommige databasesystemen, zoals SQL Server, laten je zelfs bewust een restore uitvoeren zonder de database direct te herstellen. Dit is handig wanneer je meerdere back-upbestanden achter elkaar terugplaatst, zoals een volledige back-up gevolgd door transactielogboeken. Pas bij de laatste stap activeer je de recovery en wordt de database beschikbaar gesteld.
Wat zijn veelgemaakte fouten bij databaseherstel?
De meest gemaakte fouten bij databaseherstel zijn het niet testen van back-ups, het ontbreken van duidelijke herstelprocessen en het onderschatten van de tijd die recovery in beslag neemt. Deze fouten komen pas aan het licht op het slechtst mogelijke moment: tijdens een daadwerkelijke crisis.
Back-ups die nooit getest worden
Een back-up die nooit getest is, is in feite een aanname. Bestanden kunnen corrupt raken, opslagmedia kunnen falen en configuratiewijzigingen kunnen ervoor zorgen dat een back-up niet meer bruikbaar is. Regelmatig testen van herstelprocedures is de enige manier om zeker te weten dat je back-up ook echt werkt wanneer je hem nodig hebt.
Geen heldere afspraken over RPO en RTO
Zonder duidelijke afspraken over de Recovery Point Objective (RPO) en de Recovery Time Objective (RTO) weet je niet hoeveel dataverlies acceptabel is en hoe snel systemen weer operationeel moeten zijn. Dit leidt tot herstelstrategieën die niet aansluiten op de werkelijke bedrijfsrisico’s. Een organisatie die denkt dat een nachtelijke back-up voldoende is, maar in werkelijkheid geen uur dataverlies kan tolereren, heeft een fundamenteel probleem in haar herstelstrategie.
Improviseren onder druk
In een crisissituatie is er geen ruimte voor improvisatie. Teams die geen gedocumenteerde herstelprocedures hebben, verliezen kostbare tijd met uitzoeken welke stappen gezet moeten worden. Goede documentatie is daarom net zo belangrijk als de back-up zelf.
Wanneer schakel je een specialist in voor databaseherstel?
Je schakelt een specialist in voor databaseherstel wanneer de interne kennis ontbreekt, wanneer de omgeving te complex is om zelfstandig te herstellen, of wanneer de bedrijfsrisico’s te groot zijn om te experimenteren. Hoe sneller systemen beschikbaar moeten zijn en hoe meer data er op het spel staat, hoe eerder specialistische hulp gerechtvaardigd is.
Concrete situaties waarin je een specialist nodig hebt:
- De database is corrupt en standaard herstelprocedures werken niet.
- Er zijn meerdere back-upbestanden en transactielogboeken die in de juiste volgorde teruggezet moeten worden.
- Het gaat om een productieomgeving met strikte RTO-eisen waarbij downtime directe financiële of operationele gevolgen heeft.
- De omgeving draait op een platform zoals Oracle, PostgreSQL of Azure SQL waarbij diepgaande platformkennis vereist is.
- Er is geen interne documentatie beschikbaar over de herstelstrategie.
Ook als het herstel succesvol is verlopen, is het verstandig om achteraf te evalueren wat er misging en hoe de herstelstrategie verbeterd kan worden. Een specialist helpt niet alleen bij het oplossen van het directe probleem, maar ook bij het voorkomen van herhaling.
Hoe Brander Company helpt bij database recovery
Wij geloven dat een goede herstelstrategie begint voordat er iets misgaat. Bij Brander Company helpen we organisaties om database recovery niet aan het toeval over te laten, maar te bouwen op een solide, gedocumenteerde aanpak die past bij hun specifieke bedrijfsrisico’s.
Wat wij concreet bieden:
- Het opstellen en documenteren van herstelstrategieën op basis van duidelijke RPO- en RTO-afspraken.
- Regelmatige, gestructureerde hersteltests op omgevingen zoals SQL Server, Azure SQL, Oracle en PostgreSQL.
- Begeleiding bij herstel in crisissituaties, zodat je team ook onder druk weet welke stappen gezet moeten worden.
- Proactief beheer en monitoring om problemen te signaleren voordat ze tot uitval leiden.
- Duidelijke communicatie zonder onnodig technisch jargon, zodat ook niet-technische stakeholders begrijpen wat er speelt.
Wil je weten of jouw huidige herstelstrategie bestand is tegen een echte crisis? Neem contact op met Brander Company voor een vrijblijvend gesprek over database recovery en wat wij voor jouw organisatie kunnen betekenen.
