Hoe vaak je een backup moet maken, hangt af van hoe vaak jouw data verandert en hoeveel verlies je kunt accepteren. Voor de meeste bedrijven geldt: dagelijks een backup is het minimum, maar systemen met veel transacties vereisen meerdere backups per dag. In dit artikel beantwoorden we de meest gestelde vragen over backupfrequentie, backupstrategie en wat je moet weten over databasebackups.
Wat bepaalt hoe vaak je een backup moet maken?
Hoe vaak je een backup moet maken, wordt bepaald door twee factoren: hoeveel data je bereid bent te verliezen (de zogenaamde Recovery Point Objective, of RPO) en hoe snel je na een storing weer operationeel moet zijn. Hoe korter het acceptabele verliesvenster, hoe vaker je een backup moet uitvoeren.
Stel jezelf de volgende vraag: als mijn systeem nu uitvalt, hoeveel uur of dagen aan werk mag ik dan kwijt zijn? Een webshop die honderden bestellingen per dag verwerkt, kan zich geen verlies van 24 uur aan data veroorloven. Een intern planningsdocument dat eens per week wordt bijgewerkt, is een ander verhaal.
Andere factoren die de backupfrequentie bepalen:
- Transactievolume: hoe meer wijzigingen er per uur in een systeem plaatsvinden, hoe vaker je een backup wilt maken
- Wettelijke vereisten: sommige sectoren, zoals de zorg en financiële dienstverlening, hebben verplichte bewaarplichten voor data
- Opslagcapaciteit: frequentere backups vereisen meer opslagruimte, wat kosten met zich meebrengt
- Hersteltijd: een recente backup betekent minder herstelwerk na een incident
Wat is het verschil tussen een dagelijkse, wekelijkse en maandelijkse backup?
Het verschil zit in het maximale dataverlies dat je riskeert. Een dagelijkse backup betekent dat je bij een storing maximaal 24 uur aan data kwijt bent. Een wekelijkse backup kan leiden tot verlies van zeven dagen werk, en een maandelijkse backup tot verlies van een volledige maand aan wijzigingen.
In de praktijk combineren de meeste organisaties meerdere backupschema’s. Dat werkt als volgt:
- Dagelijkse backups vangen de meest recente wijzigingen op en zijn geschikt voor systemen die actief worden gebruikt
- Wekelijkse backups dienen als tussenliggende herstelpunten en zijn handig wanneer een probleem pas na enkele dagen wordt ontdekt
- Maandelijkse backups worden bewaard als langetermijnarchief, bijvoorbeeld voor audits of het terugdraaien van grote systeemwijzigingen
De combinatie van deze drie niveaus geeft je zowel flexibiliteit als diepte in je backupstrategie. Je kunt dan kiezen tot welk moment je wilt terugkeren, zonder afhankelijk te zijn van één enkel herstelpunt.
Wat is de 3-2-1 backupregel en hoe werkt die?
De 3-2-1 backupregel is een bewezen richtlijn voor een solide backupstrategie: bewaar drie kopieën van je data, op twee verschillende opslagmedia, waarvan één kopie zich op een andere locatie bevindt. Deze aanpak beschermt je tegen verlies door hardwaredefecten, brand, diefstal of ransomware.
Concreet ziet de 3-2-1 regel er zo uit:
- Drie kopieën: de originele data plus twee backups
- Twee media: bijvoorbeeld een lokale server én een externe harde schijf of NAS
- Één offsite kopie: een backup in de cloud of op een andere fysieke locatie
De kracht van deze methode is dat geen enkele storing alle kopieën tegelijk kan treffen. Als je lokale server crasht, heb je nog de externe kopie. Als er brand uitbreekt op kantoor, is de cloudbackup intact. De 3-2-1 regel is geen garantie voor nul dataverlies, maar het is de meest praktische manier om het risico drastisch te verkleinen.
Hoe vaak moet je een backup maken van een database?
Voor een actieve database geldt als vuistregel: maak minimaal één volledige backup per dag, aangevuld met transactielogbackups elke één tot vier uur. Systemen met hoge transactiebelasting, zoals een webshop of ERP-systeem, vereisen nog frequentere logbackups om dataverlies tot een minimum te beperken.
Databases zijn gevoeliger voor dataverlies dan reguliere bestanden, omdat elke transactie direct invloed heeft op de integriteit van de data. Een corrupte database kan niet zomaar worden teruggezet naar een willekeurig moment; je hebt een consistente backup nodig die de database in een stabiele toestand heeft vastgelegd.
Voor databasebeheer zijn er drie veelgebruikte backuptypen:
- Volledige backup (full backup): een complete kopie van de gehele database, doorgaans ‘s nachts uitgevoerd
- Differentiële backup: slaat alleen de wijzigingen op ten opzichte van de laatste volledige backup
- Transactielogbackup: legt elke individuele transactie vast en maakt herstel tot op de minuut mogelijk
De combinatie van deze drie typen vormt een professioneel databasebackupschema. Welke combinatie het beste past, hangt af van de grootte van de database, de hoeveelheid dagelijkse wijzigingen en de gewenste hersteltijd.
Hoe weet je of je backup ook echt werkt?
Een backup werkt pas als je hem succesvol hebt hersteld. De enige manier om zeker te weten of je backup bruikbaar is, is door regelmatig een herstelprocedure te testen. Veel organisaties maken backups zonder ooit te controleren of die backups ook daadwerkelijk te herstellen zijn, wat een gevaarlijk valse zekerheid geeft.
Een backup die nooit getest is, is geen backup, het is een aanname. Bestanden kunnen corrupt raken, opslagmedia kunnen falen en configuratiefouten kunnen ervoor zorgen dat een backup onvolledig is.
Controleer je backupstrategie op de volgende punten:
- Hersteltest: herstel de backup periodiek naar een testomgeving en controleer of de data compleet en consistent is
- Logcontrole: bekijk de backup logs na elke run op foutmeldingen of waarschuwingen
- Bewaarperiode: controleer of backups lang genoeg worden bewaard om terug te kunnen naar het gewenste herstelpunt
- Meldingen: stel automatische alerts in zodat je direct op de hoogte bent als een backup mislukt
Een goede vuistregel is om minimaal eens per kwartaal een volledige hersteltest uit te voeren. Voor kritieke systemen is maandelijks testen aan te raden.
Hoe wij bij Brander Company helpen met database backup en beheer
Een solide backupstrategie is onlosmakelijk verbonden met goed databasebeheer. Bij Brander Company zorgen we ervoor dat jouw databaseomgeving niet alleen goed presteert, maar ook volledig beschermd is tegen dataverlies.
Wat we voor je doen:
- We stellen een backupschema op dat aansluit bij jouw RPO en bedrijfsprocessen
- We richten automatische backups in voor SQL Server, Azure SQL, Oracle en PostgreSQL
- We bewaken de uitvoering via 24/7 monitoring en grijpen proactief in als iets misgaat
- We voeren periodieke hersteltesten uit zodat je zeker weet dat je backups ook echt werken
- We combineren backupbeheer met database performance monitoring en tuning in één abonnementsmodel
Wil je weten hoe jouw huidige backupstrategie ervoor staat? Neem contact met ons op voor een vrijblijvend gesprek. We kijken graag mee en geven je een eerlijk advies zonder onnodig jargon.
Frequently Asked Questions
Wat is het verschil tussen een RPO en een RTO, en waarom zijn beide belangrijk?
De RPO (Recovery Point Objective) geeft aan hoeveel dataverlies acceptabel is — bijvoorbeeld maximaal 4 uur aan transacties. De RTO (Recovery Time Objective) geeft aan hoe snel je systeem na een storing weer operationeel moet zijn. Beide doelstellingen samen bepalen hoe je backupstrategie eruit moet zien: een lage RPO vereist frequente backups, terwijl een lage RTO vraagt om snelle herstelprocedures en goed voorbereide herstelplannen.
Hoe begin ik met het opzetten van een backupstrategie als ik dat nog nooit heb gedaan?
Begin met het in kaart brengen van welke data kritiek is voor jouw bedrijfsvoering en stel per systeem een RPO vast. Kies vervolgens een backupoplossing die past bij jouw infrastructuur — cloud, lokaal of hybride — en stel een geautomatiseerd schema in zodat backups niet afhankelijk zijn van handmatige acties. Pas daarna de 3-2-1 regel toe als leidraad voor de opslag van je kopieën, en plan direct een eerste hersteltest in om te bevestigen dat alles correct werkt.
Wat zijn de meest gemaakte fouten bij het inrichten van een backupstrategie?
De meest voorkomende fout is het nooit testen van herstelprocedures — organisaties gaan ervan uit dat een backup werkt, zonder dit ooit te verifiëren. Andere veelgemaakte fouten zijn: backups op dezelfde locatie bewaren als de originele data, geen automatische meldingen instellen bij mislukte backups, en vergeten om ook applicatieconfiguraties en omgevingsinstellingen mee te nemen in de backup. Een backup die alleen bestanden bevat maar niet de bijbehorende configuratie, kan bij herstel alsnog leiden tot langdurige downtime.
Kan ik voor mijn database volstaan met alleen een dagelijkse volledige backup?
Voor databases met weinig wijzigingen kan een dagelijkse volledige backup voldoende zijn, maar voor actieve systemen is dit bijna altijd onvoldoende. Stel je voor dat je database om 15:00 uur crasht en je laatste backup van 02:00 uur 's nachts dateert — dan ben je 13 uur aan transacties kwijt. Door transactielogbackups elke één tot vier uur toe te voegen, beperk je het maximale dataverlies drastisch en kun je de database herstellen tot vrijwel het moment van de storing.
Hoe lang moet ik mijn backups bewaren?
De bewaartermijn hangt af van zowel je bedrijfsbehoeften als eventuele wettelijke verplichtingen. Een gangbare richtlijn is: dagelijkse backups 14 tot 30 dagen bewaren, wekelijkse backups 3 maanden en maandelijkse backups minimaal 1 jaar. In gereguleerde sectoren zoals de zorg of financiële dienstverlening kunnen wettelijke bewaarplichten oplopen tot 7 jaar of langer, dus controleer altijd de geldende regelgeving voor jouw branche.
Is een cloudbackup veilig genoeg, of heb ik ook altijd een lokale kopie nodig?
Een cloudbackup biedt uitstekende bescherming tegen lokale incidenten zoals brand, diefstal of hardwarestoringen, maar heeft ook nadelen: herstel vanuit de cloud kan traag zijn bij grote datasets en je bent afhankelijk van een internetverbinding en de beschikbaarheid van de cloudprovider. Daarom raadt de 3-2-1 regel aan om zowel een lokale als een offsite (cloud)kopie te bewaren — zo combineer je de snelheid van lokaal herstel met de geografische veiligheid van de cloud.
Wat moet ik doen als een backup mislukt of onvolledig blijkt te zijn?
Stel als eerste prioriteit automatische alerts in zodat je direct op de hoogte bent van een mislukte backup — wacht niet tot een incident om dit te ontdekken. Controleer de backuplogs op foutmeldingen om de oorzaak te achterhalen, zoals onvoldoende schijfruimte, netwerkstoringen of rechtenfouten, en herstel de situatie direct. Zorg er daarna voor dat je een handmatige backup uitvoert om het gemiste herstelpunt zo snel mogelijk te dichten, en evalueer of je bewakingsprocedure aanpassing behoeft om herhaling te voorkomen.
