Voor iedereen die verantwoordelijk is voor een database zijn twee begrippen onmisbaar: back-up en databaserecovery. Ze worden vaak in één adem genoemd, maar betekenen fundamenteel iets anders. Het verschil begrijpen is niet alleen theoretisch interessant; het bepaalt direct hoe goed jouw organisatie bestand is tegen dataverlies en uitval.
In dit artikel beantwoorden we de meest gestelde vragen over back-up en databaserecovery, zodat je precies weet wat je wanneer nodig hebt en welke fouten je moet vermijden.
Wat is een databaseback-up precies?
Een databaseback-up is een kopie van je databasegegevens die op een bepaald moment is vastgelegd. Die kopie sla je op een veilige locatie op, los van de productieomgeving, zodat je de gegevens kunt herstellen als er iets misgaat. Zonder back-up is herstel na een storing simpelweg niet mogelijk.
Er zijn verschillende soorten back-ups, elk met een eigen doel en frequentie:
- Volledige back-up (full backup): een complete kopie van de gehele database op dat moment.
- Differentiële back-up: alleen de wijzigingen die zijn opgeslagen sinds de laatste volledige back-up.
- Transactielogback-up: een back-up van alle uitgevoerde transacties, waarmee je tot op de minuut nauwkeurig kunt herstellen.
De combinatie van deze typen bepaalt hoeveel dataverlies je riskeert bij een incident. Een omgeving die alleen wekelijks een volledige back-up maakt, kan bij een storing een week aan data kwijtraken. Een omgeving met regelmatige transactielogback-ups verliest hooguit enkele minuten aan data.
Wat is databaserecovery en hoe werkt het?
Databaserecovery is het proces waarbij je een database na een storing, fout of dataverlies herstelt naar een werkende, consistente toestand. Recovery gebruikt de beschikbare back-ups als startpunt en past vervolgens transactielogs toe om de database naar het gewenste herstelpunt te brengen.
Het herstelproces verloopt doorgaans in een aantal stappen:
- De meest recente volledige back-up wordt teruggezet naar de doelomgeving.
- Eventuele differentiële back-ups worden boven op de volledige back-up toegepast.
- Transactielogs worden in volgorde afgespeeld tot het gewenste herstelpunt is bereikt.
- De database wordt gecontroleerd op consistentie en vrijgegeven voor gebruik.
Twee begrippen zijn hierbij cruciaal: de RPO (Recovery Point Objective) en de RTO (Recovery Time Objective). De RPO bepaalt hoeveel dataverlies acceptabel is, uitgedrukt in tijd. De RTO bepaalt hoe snel de database weer beschikbaar moet zijn. Zonder heldere afspraken over deze parameters is herstel een kwestie van geluk in plaats van controle.
Wat is het verschil tussen back-up en databaserecovery?
Het verschil tussen back-up en databaserecovery is dat een back-up de voorbereiding is en recovery de uitvoering. Een back-up is een passieve kopie van je data die je aanmaakt en bewaart. Databaserecovery is het actieve proces waarbij je die kopie gebruikt om een beschadigde of verloren database te herstellen.
Een goede manier om het onderscheid te onthouden: een back-up is de brandverzekering, recovery is de brandweer. Je hebt de verzekering nodig om schade te kunnen vergoeden, maar de brandweer voert het herstel daadwerkelijk uit. Zonder back-up kan recovery niet plaatsvinden. Maar een back-up die nooit is getest, biedt ook geen garantie dat recovery succesvol verloopt.
Dit maakt het testen van je herstelstrategie net zo belangrijk als het maken van de back-ups zelf.
Wanneer heb je een back-up nodig en wanneer recovery?
Je hebt altijd een back-up nodig: continu en proactief. Databaserecovery pas je toe op het moment dat er daadwerkelijk iets misgaat. De meest voorkomende situaties waarin recovery noodzakelijk is, zijn menselijke fouten, datacorruptie, hardwarestoringen en ransomware-aanvallen.
Situaties waarin recovery onvermijdelijk is
Menselijke fouten zijn veruit de meest voorkomende reden voor dataverlies. Denk aan een per ongeluk verwijderde tabel, een foutief uitgevoerd UPDATE-commando zonder WHERE-clausule, of een mislukte migratie. In al deze gevallen is een recente back-up, gecombineerd met een getest herstelproces, de enige uitweg.
Bij hardwarestoringen of datacenteruitval speelt de RTO een grote rol. Hoe snel moet de database weer beschikbaar zijn? Voor een webshop kan een uur uitval al grote financiële gevolgen hebben. Voor een intern administratiesysteem is dat misschien minder kritisch. Die afweging bepaalt hoe je back-upstrategie en recovery-infrastructuur moeten worden ingericht.
Welke back-upstrategie past bij jouw databaseomgeving?
De juiste back-upstrategie hangt af van drie factoren: hoeveel dataverlies je organisatie kan tolereren (RPO), hoe snel herstel moet plaatsvinden (RTO), en de omvang en complexiteit van je databaseomgeving. Er is geen universele aanpak die voor elke organisatie werkt.
Aandachtspunten per omgeving
Voor omgevingen op SQL Server en Azure SQL biedt de combinatie van volledige back-ups, differentiële back-ups en transactielogback-ups de meeste flexibiliteit. Azure SQL heeft bovendien ingebouwde geo-redundantie, wat extra bescherming biedt bij regionale uitval.
Op Oracle en PostgreSQL zijn vergelijkbare strategieën beschikbaar, maar de implementatie verschilt per platform. Oracle gebruikt RMAN voor back-up en herstel, terwijl PostgreSQL werkt met pg_dump en WAL-archivering voor point-in-time recovery. Kennis van het specifieke platform is essentieel om de strategie goed in te richten.
Ongeacht het platform geldt: bewaar back-ups altijd op meerdere locaties, bij voorkeur ook offsite of in de cloud. Een back-up die op dezelfde server staat als de database die uitvalt, biedt geen enkele bescherming.
Wat zijn de meest gemaakte fouten bij databaseback-up en databaserecovery?
De grootste fout bij databaseback-up en databaserecovery is het nooit testen van de herstelstrategie. Organisaties maken netjes back-ups, maar controleren nooit of die back-ups ook daadwerkelijk kunnen worden teruggezet. Pas bij een echte crisis blijkt dat de back-up corrupt is, onvolledig is of niet meer aansluit op de huidige databaseversie.
Andere veelgemaakte fouten zijn:
- Te lage back-upfrequentie: dagelijkse back-ups klinken solide, maar bij een storing aan het einde van de dag ben je alsnog een volledige werkdag aan data kwijt.
- Geen afspraken over RPO en RTO: zonder heldere doelstellingen weet niemand wat een acceptabel herstel is, wat leidt tot verwarring en verkeerde prioriteiten tijdens een crisis.
- Back-ups op dezelfde locatie als de productiedatabase: bij een servercrash of ransomware-aanval zijn back-up en database tegelijk verloren.
- Geen documentatie van het herstelproces: in een crisissituatie is er geen tijd om te improviseren. Zonder duidelijke procedures vergroot tijdsdruk de kans op fouten.
- Vergeten van afhankelijke systemen: een database herstellen terwijl gekoppelde applicaties of andere databases niet worden meegenomen, leidt tot inconsistente data en nieuwe problemen.
Het structureel plannen van hersteltests is de meest effectieve manier om deze fouten te voorkomen: niet eenmalig, maar regelmatig en gedocumenteerd.
Hoe Brander Company helpt bij databaserecovery
Een solide back-upstrategie en een getest herstelproces zijn geen luxe, maar een basisvereiste voor elke organisatie die afhankelijk is van haar data. Wij helpen organisaties dit concreet en betrouwbaar in te richten, van strategie tot uitvoering.
Wat we doen:
- We stellen samen met jou heldere RPO- en RTO-doelstellingen vast, afgestemd op de risico’s voor jouw organisatie.
- We ontwerpen en implementeren back-upstrategieën voor SQL Server, Azure SQL, Oracle en PostgreSQL.
- We plannen en begeleiden regelmatige, gestructureerde hersteltests, zodat je zeker weet dat recovery werkt als het erop aankomt.
- We zorgen voor gedegen documentatie en duidelijke processen, zodat jouw team ook onder druk precies weet welke stappen gezet moeten worden.
- We beheren en monitoren de databaseomgeving proactief, zodat problemen worden gesignaleerd voordat ze tot uitval leiden.
Wij geloven niet in snelle, tijdelijke oplossingen. We bouwen robuuste, toekomstbestendige recovery-strategieën die aansluiten op jouw specifieke situatie, transparant en zonder onnodig jargon. Wil je weten hoe jouw huidige back-up- en recovery-setup ervoor staat? Neem contact op met Brander Company voor een vrijblijvend gesprek.
