Als je een back-up maakt, worden je gegevens gekopieerd naar een aparte opslaglocatie zodat je ze kunt herstellen als het origineel verloren gaat of beschadigd raakt. Het proces varieert afhankelijk van het type back-up en de gekozen opslagmethode, maar het doel is altijd hetzelfde: een betrouwbaar herstelpunt creëren. De vragen hieronder geven je een helder beeld van wat er achter de schermen gebeurt.
Waar worden je gegevens opgeslagen tijdens een back-up?
Tijdens een back-up worden je gegevens gekopieerd naar een aparte opslaglocatie, die losstaat van het originele systeem. Dit kan een lokale schijf zijn, een externe harde schijf, een netwerkopslag (NAS of SAN), of een cloudplatform zoals Azure Blob Storage of Amazon S3. De locatiekeuze bepaalt grotendeels hoe snel je kunt herstellen en hoe veilig je data is bij een calamiteit.
De meest robuuste aanpak combineert meerdere locaties. De bekende 3-2-1-regel schrijft voor dat je drie kopieën van je data bewaart, op twee verschillende opslagtypen, waarvan één offsite. Zo ben je beschermd tegen lokale incidenten zoals brand, diefstal of een hardwarestoring die meerdere apparaten tegelijk treft.
Voor databases zoals SQL Server, Azure SQL, Oracle en PostgreSQL worden back-ups vaak direct naar cloudopslag weggeschreven. Dit maakt herstel vanaf elke locatie mogelijk en vermindert de afhankelijkheid van fysieke hardware.
Wat is het verschil tussen een volledige, incrementele en differentiële back-up?
Een volledige back-up kopieert alle geselecteerde gegevens in één keer. Een incrementele back-up slaat alleen de wijzigingen op ten opzichte van de vorige back-up, ongeacht het type. Een differentiële back-up slaat alle wijzigingen op ten opzichte van de laatste volledige back-up. Het verschil zit in wat er wordt opgeslagen en hoe snel herstel daarna verloopt.
- Volledig: Langzaamste om te maken, snelste om te herstellen. Je hebt maar één bestand nodig.
- Incrementeel: Snelste om te maken, maar herstel vereist de volledige back-up plus alle tussenliggende incrementele back-ups in de juiste volgorde.
- Differentieel: Middenweg. Iets groter dan incrementeel, maar herstel is eenvoudiger: je hebt alleen de volledige back-up en de meest recente differentiële back-up nodig.
In de praktijk combineren organisaties deze typen. Een veelgebruikte strategie is een wekelijkse volledige back-up aangevuld met dagelijkse incrementele of differentiële back-ups. Welke combinatie het beste werkt, hangt af van de hoeveelheid data, de beschikbare opslagruimte en hoe snel je systemen hersteld moeten zijn.
Hoe lang duurt het om een back-up te maken?
De duur van een back-up hangt af van de hoeveelheid data, het type back-up, de snelheid van de opslagverbinding en de belasting op het systeem tijdens de back-up. Een volledige back-up van een grote database kan uren duren, terwijl een incrementele back-up van dezelfde omgeving in enkele minuten klaar kan zijn.
Factoren die de back-upduur beïnvloeden zijn onder andere:
- De totale omvang van de te kopiëren data
- De schrijfsnelheid van de doelopslaglocatie
- Netwerkbandbreedte bij back-ups naar een externe locatie of de cloud
- Compressie en encryptie, die extra verwerkingstijd kosten maar de overdrachtsgrootte verkleinen
- Gelijktijdige belasting op de databaseserver
Back-ups worden daarom vaak gepland buiten piektijden, bijvoorbeeld ‘s nachts. Bij kritieke systemen is het verstandig om te meten hoe lang een back-up daadwerkelijk duurt, zodat je zeker weet dat het back-upvenster niet overlapt met het begin van de werkdag.
Wat gebeurt er met je gegevens als de back-up mislukt?
Als een back-up mislukt, veranderen je bestaande gegevens niet. De originele data blijft intact. Wat je wel verliest, is het nieuwe herstelpunt dat de back-up had moeten creëren. Als er daarna iets misgaat met het originele systeem, val je terug op de laatste succesvolle back-up, wat betekent dat je meer data kwijtraakt dan je had gewild.
Back-ups kunnen mislukken door uiteenlopende oorzaken: onvoldoende opslagruimte, een verbroken netwerkverbinding, een fout in de back-upsoftware, of een databasestatus die back-ups tijdelijk blokkeert. Veel organisaties merken een mislukte back-up pas op als ze proberen te herstellen, op het moment dat het al te laat is.
Daarom is monitoring essentieel. Stel meldingen in die je direct waarschuwen bij een mislukte back-up, en controleer regelmatig de back-uplogboeken. Een back-up die stilzwijgend faalt, biedt geen enkele bescherming.
Hoe worden gegevens hersteld vanuit een back-up?
Gegevens herstellen vanuit een back-up betekent dat de opgeslagen kopie wordt teruggeschreven naar het originele systeem of een nieuwe omgeving. Het exacte herstelproces verschilt per databaseplatform en het type back-up, maar de basisstappen zijn vergelijkbaar: de juiste back-upbestanden selecteren, de doelomgeving voorbereiden en de herstelbewerking uitvoeren.
Bij een volledig herstel van een SQL Server database gebruik je bijvoorbeeld het RESTORE DATABASE-commando. Bij een gedeeltelijk herstel, waarbij je alleen specifieke tabellen of records wilt terugzetten, is het proces complexer en vereist het soms extra stappen zoals het herstellen naar een tijdelijke omgeving en het handmatig overzetten van de gewenste data.
Twee begrippen zijn hierbij cruciaal. De RPO (Recovery Point Objective) bepaalt hoeveel dataverlies acceptabel is: hoever mag het herstelpunt teruggaan in de tijd? De RTO (Recovery Time Objective) bepaalt hoe snel systemen weer operationeel moeten zijn. Zonder heldere afspraken over deze parameters is herstel een kwestie van geluk in plaats van controle. Meer over databeheer en herstelstrategieën lees je op onze kennispagina.
Hoe weet je of je back-up betrouwbaar genoeg is?
Een back-up is pas betrouwbaar als je hebt aangetoond dat je er ook daadwerkelijk uit kunt herstellen. De enige manier om dat te weten, is door regelmatig een hersteltest uit te voeren. Een back-up die nooit getest is, biedt een vals gevoel van veiligheid.
Controleer bij het beoordelen van je back-upbetrouwbaarheid minimaal de volgende punten:
- Volledigheid: Worden alle kritieke databases en bestanden meegenomen?
- Frequentie: Sluit de back-upfrequentie aan op je RPO? Als je maximaal vier uur dataverlies accepteert, is een dagelijkse back-up onvoldoende.
- Integriteit: Zijn de back-upbestanden niet beschadigd? Controleer dit via checksums of ingebouwde verificatiemechanismen.
- Hersteltijd: Past de daadwerkelijke hersteltijd binnen je RTO? Test dit in een gecontroleerde omgeving.
- Documentatie: Is het herstelproces gedocumenteerd zodat ook een collega het kan uitvoeren onder druk?
In de praktijk worden hersteltests zelden uitgevoerd totdat het te laat is. Plan ze daarom proactief in, minimaal een paar keer per jaar, en documenteer de resultaten.
Hoe wij helpen met back-up en herstel van databases
Bij Brander Company zorgen we ervoor dat back-up en herstel geen bijzaak zijn, maar een structureel onderdeel van je databasebeheer. We werken met SQL Server, Azure SQL, Oracle en PostgreSQL en bouwen herstelstrategieën die aansluiten op de specifieke risico’s van jouw organisatie.
Wat we concreet voor je doen:
- We stellen heldere RPO- en RTO-doelstellingen op in overleg met jou
- We richten een back-upstrategie in die aansluit op je bedrijfskritische systemen
- We plannen en begeleiden regelmatige hersteltests, zodat je weet dat het werkt voordat het nodig is
- We zorgen voor monitoring en alerting, zodat mislukte back-ups direct worden gesignaleerd
- We documenteren alle processen zodat jouw team ook zelfstandig kan handelen
Wil je weten of jouw huidige back-upstrategie bestand is tegen een echte calamiteit? Neem contact met ons op en we kijken samen naar wat er nodig is.
Frequently Asked Questions
Hoe vaak moet ik een hersteltest uitvoeren om zeker te weten dat mijn back-up werkt?
Een vuistregel is om minimaal twee tot vier keer per jaar een volledige hersteltest uit te voeren, afhankelijk van hoe bedrijfskritisch je systemen zijn. Voor kritieke databases of omgevingen met frequente wijzigingen is een hogere testfrequentie verstandig, bijvoorbeeld maandelijks. Documenteer elke test met de datum, de hersteltijd en eventuele bevindingen, zodat je trends kunt signaleren en het proces continu kunt verbeteren.
Wat is het verschil tussen een back-up en een snapshot, en wanneer gebruik je welke?
Een snapshot is een momentopname van de staat van een systeem of schijf op een specifiek tijdstip, vaak gemaakt op blokniveau binnen dezelfde opslagomgeving. Een back-up kopieert de data naar een volledig aparte locatie, wat bescherming biedt bij verlies van de primaire omgeving. Snapshots zijn ideaal voor snelle herstelacties na een menselijke fout of een mislukte update, maar ze vervangen een back-up niet: als de onderliggende opslag uitvalt, zijn ook je snapshots weg.
Hoe bescherm ik mijn back-ups tegen ransomware?
Ransomware richt zich steeds vaker specifiek op back-upbestanden om herstel onmogelijk te maken. Bescherm je back-ups door ze op te slaan op een locatie die niet direct toegankelijk is vanuit het primaire netwerk, zoals een offsite cloudopslag met immutable storage (onveranderbare opslag) ingeschakeld. Zorg daarnaast voor strikte toegangscontrole op je back-upsystemen en overweeg de 3-2-1-1-regel: één kopie op een airgapped of offline medium dat volledig losstaat van je netwerk.
Kan ik een back-up terugzetten naar een andere server of een andere omgeving?
Ja, dat is in de meeste gevallen mogelijk en zelfs aan te raden om te testen. Bij SQL Server kun je een back-up herstellen op een andere instantie, mits de versie van de doelserver gelijk of hoger is dan de bronserver. Bij cloudplatforms zoals Azure SQL zijn er specifieke opties voor herstel naar een andere regio of resource. Let wel op compatibiliteitsverschillen in databaseversies, configuraties en gebruikersmachtigingen, die kunnen herstel compliceren als ze niet vooraf zijn gedocumenteerd.
Hoe bepaal ik de juiste RPO en RTO voor mijn organisatie?
Begin met een bedrijfsimpactanalyse: vraag per systeem hoeveel dataverlies en downtime de organisatie financieel en operationeel kan dragen. Een webshop heeft andere eisen dan een intern rapportagesysteem. Vertaal die antwoorden naar concrete tijdswaarden, bijvoorbeeld een RPO van één uur en een RTO van vier uur, en gebruik die als uitgangspunt voor je back-upfrequentie, opslagkeuze en herstelinfrastructuur. Zorg dat deze afspraken schriftelijk worden vastgelegd en periodiek worden herzien.
Wat moet ik doen als ik merk dat mijn back-ups al langere tijd stilzwijgend falen?
Controleer als eerste de back-uplogboeken om te achterhalen wanneer de laatste succesvolle back-up is gemaakt en wat de oorzaak van de fouten is. Los de onderliggende oorzaak op, zoals onvoldoende schijfruimte of een verlopen verbinding, en draai direct een handmatige volledige back-up om een actueel herstelpunt te creëren. Stel daarna onmiddellijk monitoring en alerting in zodat toekomstige fouten direct worden gesignaleerd, en overweeg een hersteltest om te verifiëren dat de nieuw gemaakte back-up daadwerkelijk bruikbaar is.
Hoeveel opslagruimte heb ik nodig voor een goede back-upstrategie?
De benodigde opslagruimte hangt af van de omvang van je data, de retentieperiode en het type back-upstrategie dat je hanteert. Een combinatie van wekelijkse volledige back-ups met dagelijkse incrementele back-ups is aanzienlijk zuiniger in opslagruimte dan dagelijkse volledige back-ups. Compressie kan de benodigde ruimte verder terugbrengen met 30 tot 70 procent, afhankelijk van het datatype. Reken als richtlijn op twee tot vijf keer de originele dataomvang voor een strategie met een retentie van twee tot vier weken, en pas dit aan op basis van je gemeten groeisnelheid.
Related Articles
- Hoe voorkom je veelgemaakte fouten bij business intelligence?
- Wat zijn failover-scenario's?
- Wanneer moet je een database expert inhuren?
- Hoe gebruik je database management tools?
- Waarom geen Excel gebruiken in plaats van SQL?
This content was generated with the help of AI — it may contain mistakes
