Een databaseback-up is pas bruikbaar als gegevens op het gewenste moment en in een consistente toestand kunnen worden hersteld. Lees hoe volledige en incrementele back-ups, point-in-time recovery, retentie en hersteltests samen een herstelstrategie vormen.
Volledige en incrementele databaseback-ups vergelijken
Een volledige back-up bevat een kopie van alle geselecteerde databasegegevens op een bepaald moment. Dat maakt het herstelmodel overzichtelijk: de back-up wordt teruggezet en vormt de basis voor verder herstel. Het nadeel is dat volledige kopieën veel opslag en leestijd kunnen vragen, zeker bij grote databases. Een dagelijkse volledige back-up kan bovendien onnodig veel gegevens opnieuw vastleggen als slechts een klein deel sinds de vorige kopie is gewijzigd.
Een incrementele back-up bevat alleen wijzigingen sinds een eerder back-uppunt. Die aanpak beperkt de hoeveelheid data die per cyclus wordt gekopieerd, maar maakt herstel afhankelijk van een keten: doorgaans is eerst de volledige basis nodig, gevolgd door iedere vereiste incrementele set in de juiste volgorde. Ontbreekt één schakel of is een bestand beschadigd, dan kan de keten onbruikbaar worden. Een differentiële back-up legt wijzigingen vast sinds de laatste volledige kopie. Herstel vraagt dan de volledige back-up en de meest recente differentiële kopie, maar de differentiële bestanden groeien naarmate de volgende volledige back-up langer uitblijft.
De keuze hangt af van databasegrootte, wijzigingssnelheid, beschikbare opslag en de gewenste herstelsnelheid. Een back-upstrategie kan bijvoorbeeld periodiek volledig en vaker incrementeel werken. Beoordeel daarbij niet alleen de kopieertijd, maar ook de hoeveelheid herstelstappen en de kans op fouten in die stappen.
Consistente back-ups maken van actieve databases
Een bestandssysteemkopie van een draaiende database is niet automatisch een geldige databaseback-up. Terwijl bestanden worden gekopieerd, kunnen transacties pagina’s wijzigen of gegevens tussen geheugen en opslag verplaatsen. Het resultaat kan daardoor onderdelen bevatten die bij verschillende momenten horen. De database-engine kan zo’n kopie soms herstellen met transactielogboeken, maar dat hangt af van de gebruikte methode en configuratie.
Databases bieden daarom eigen back-upmechanismen, zoals snapshots, hot backups of exportfuncties. Deze methoden leggen vast hoe de engine omgaat met gelijktijdige transacties, buffers en logboeken. Een logische export kan tabellen en schema-objecten opnieuw opbouwen, maar kan langer duren en bepaalde database-eigenschappen missen als die niet expliciet worden meegenomen. Een fysieke back-up kopieert databasebestanden in een formaat dat doorgaans sneller terug te zetten is, maar is sterker gekoppeld aan versie, configuratie en opslagstructuur.
Bij snapshots moet ook de samenhang tussen meerdere volumes worden gecontroleerd. Een snapshot die elk volume op een ander moment vastlegt, kan transacties onderbreken op een manier die herstel bemoeilijkt. Gebruik waar nodig een databasebewuste snapshotprocedure die de engine tijdelijk in een consistente toestand brengt of relevante logposities vastlegt. Leg per methode vast welke databaseversies en instellingen worden ondersteund, hoe actieve transacties worden behandeld en welke logbestanden nodig zijn. Zo voorkom je dat een technisch succesvolle kopie pas bij herstel inconsistent blijkt.
Point-in-time recovery met transactielogboeken
Point-in-time recovery, of PITR, maakt herstel naar een specifiek tijdstip mogelijk. Naast een basisback-up zijn daarvoor opeenvolgende transactielogboeken nodig. Afhankelijk van de database heten die bijvoorbeeld write-ahead logs, binlogs of transaction logs. De basisback-up levert de toestand waarop herstel begint; daarna speelt de database-engine de loggegevens opnieuw af tot het gekozen punt. Zo kan een beheerder bijvoorbeeld herstellen tot vlak vóór een foutieve verwijdering, in plaats van terug te gaan naar de laatste nachtelijke kopie.
PITR werkt alleen zolang de logketen compleet is en de logbestanden bruikbaar zijn. Als archivering stopt, een bestand ontbreekt of een logsegment beschadigd raakt, kan herstel niet voorbij dat punt worden voortgezet. Ook de tijdsynchronisatie van systemen is relevant: applicatielogs, databaseklokken en beheeracties moeten voldoende overeenstemmen om een incidentmoment te bepalen. Een herstel naar een exacte transactielocatie kan nauwkeuriger zijn dan een tijdstip, mits die informatie beschikbaar is.
Logboeken produceren en bewaren heeft operationele gevolgen. Een trage overdracht of volle opslag kan archivering onderbreken en de databaseconfiguratie laten ingrijpen. Meet daarom de achterstand tussen aangemaakte en veilig opgeslagen logs en stel signalering in op oplopende achterstanden. Bepaal vooraf hoe een herstelpunt wordt gekozen, welke tijdzone wordt gebruikt en hoe logbestanden na het herstel worden toegepast. PITR is geen losse functie, maar een keten van basisback-up, logarchivering, tijdsregistratie en een gecontroleerde herstelprocedure.
Retentiebeleid afstemmen op herstelpunten en logketens
Retentie bepaalt hoe lang back-ups en transactielogboeken beschikbaar blijven. Een korte bewaartermijn beperkt opslaggebruik, maar kan betekenen dat een probleem pas wordt ontdekt nadat het laatste bruikbare herstelpunt is verwijderd. Een langere termijn biedt meer keuze, maar vraagt om afspraken over capaciteit, toegang en gegevensbescherming. De juiste termijn volgt niet alleen uit een algemene bewaarrichtlijn: ze moet passen bij hoe laat fouten doorgaans worden ontdekt en hoe ver terug herstel mogelijk moet zijn.
Bij een incrementele strategie moeten alle bestanden worden bewaard die nodig zijn om de gekozen herstelpunten opnieuw samen te stellen. Verwijdering van de volledige basis terwijl afhankelijke incrementele kopieën nog binnen de retentie vallen, kan een reeks ogenschijnlijk aanwezige back-ups onbruikbaar maken. PITR stelt extra eisen: de volledige logketen vanaf de relevante basis moet beschikbaar zijn. Een retentieproces moet daarom afhankelijkheden begrijpen en bestanden niet uitsluitend op leeftijd verwijderen.
Werk met expliciete herstelvensters, bijvoorbeeld dagelijkse herstelpunten voor een recente periode en minder frequente kopieën voor langer terugkijken. Leg vast wanneer een back-up als vervallen geldt en hoe verwijdering wordt gecontroleerd. Houd ook rekening met replica’s, testkopieën en exports die buiten de primaire back-upomgeving staan. Die vallen niet vanzelf onder dezelfde retentie. Controleer periodiek of de ingestelde bewaartermijn daadwerkelijk overeenkomt met de beschikbare herstelpunten. Een beleid in documentatie is niet voldoende als automatische opschoning in de praktijk eerder bestanden verwijdert of logarchivering een gat heeft achtergelaten.
Back-ups beschermen tegen uitval, fouten en ransomware
Een back-up op dezelfde server of in dezelfde beheeromgeving als de database beschermt beperkt tegen incidenten. Hardwarefalen, een beheerdersfout, een gecompromitteerd account of ransomware kan zowel de primaire gegevens als de kopieën raken. Spreid back-ups daarom over afzonderlijke foutdomeinen: bijvoorbeeld een lokale kopie voor snelle operationele herstelacties en een kopie buiten de primaire omgeving voor verlies van een locatie of account. De precieze invulling hangt af van infrastructuur en dreigingsmodel.
Toegangsbeheer is even belangrijk als opslaglocatie. Back-upaccounts hebben doorgaans schrijfrechten nodig, maar hoeven niet automatisch ook bestaande kopieën te kunnen verwijderen. Scheid rollen voor het maken, lezen en verwijderen van back-ups, gebruik sterke authenticatie en registreer beheeractiviteiten. Immutable opslag of object lock kan verwijdering en overschrijven gedurende een vastgestelde periode verhinderen. Dat verkleint de impact van bepaalde aanvallen, maar vraagt om zorgvuldige configuratie: een verkeerde retentie kan ook legitieme opschoning of herstelprocedures blokkeren.
Versleuteling beschermt back-updata tijdens transport en opslag, maar introduceert afhankelijkheid van sleutels. Bewaar sleutelbeheer niet uitsluitend in dezelfde omgeving als de back-ups. Controleer dat sleutels tijdens een incident beschikbaar zijn voor bevoegde herstelmedewerkers en dat herstel van versleutelde kopieën werkelijk is getest. Controleer daarnaast integriteitsinformatie, zoals checksums of opslagvalidatie, en bewaak afwijkingen in back-upvolume. Een kopie kan aanwezig lijken terwijl bestanden beschadigd, gedeeltelijk geüpload of niet meer leesbaar zijn. Bescherming is dus een combinatie van isolatie, rechten, integriteit en getest sleutelbeheer.
Een database herstellen met een uitvoerbare procedure
Een herstelprocedure moet meer bevatten dan de opdracht om een back-up terug te zetten. Ze beschrijft waar de juiste back-up en bijbehorende logbestanden staan, welke databaseversie nodig is en welke configuratie vooraf moet worden ingericht. Ook netwerktoegang, opslagruimte, accounts, certificaten en encryptiesleutels kunnen noodzakelijk zijn. Als deze afhankelijkheden alleen op de productieserver bestaan, kan die server bij een incident niet als enige bron van herstelinformatie dienen.
De herstelvolgorde verschilt per back-uptype. Bij een incrementele reeks wordt doorgaans eerst de volledige kopie teruggezet en daarna elke vereiste incrementele kopie in de juiste volgorde. Voor PITR worden vervolgens transactielogboeken toegepast tot het gekozen tijdstip of de gekozen logpositie. De procedure moet aangeven hoe wordt voorkomen dat applicaties tijdens herstel nieuwe wijzigingen naar de database sturen. Denk ook aan het herstellen van rollen, extensies, schema’s, opgeslagen procedures en database-instellingen die niet in de datakopie zitten.
Een teruggezette database hoort eerst geïsoleerd te worden gecontroleerd voordat applicaties er weer mee werken. Verifieer de integriteit met database-eigen controles en vergelijk belangrijke gegevens of tellingen met beschikbare referenties. Controleer vervolgens of applicatieverbindingen, achtergrondtaken en replicatie veilig kunnen worden hervat. Leg vast wie het herstelpunt kiest en wie de heropening van de dienst autoriseert. Tijdens een incident zijn beslissingen onder tijdsdruk lastiger; vooraf beschreven keuzemomenten en alternatieve stappen beperken improvisatie. Bewaar de procedure buiten de omgeving die zij moet helpen herstellen en houd haar actueel na wijzigingen in databaseversies of infrastructuur.
Hersteltests uitvoeren en bruikbaarheid aantonen
Een geslaagde back-uptaak bevestigt meestal dat een kopie is aangemaakt of naar opslag is geschreven. Dat bewijst niet dat de bestanden volledig zijn, de logketen sluit of de database-engine ze kan terugzetten. Hersteltests toetsen de hele route: toegang tot de kopieën, beschikbaarheid van sleutels, benodigde software, herstelvolgorde en controle van de resulterende gegevens. Zonder die test blijft herstelbaarheid een aanname.
Test op een geïsoleerde omgeving die productie voldoende benadert, maar geen berichten naar echte gebruikers of externe systemen verstuurt. Begin met het terugzetten van een representatieve volledige back-up en breid uit naar incrementele reeksen en PITR. Neem ook scenario’s op waarin een bestand ontbreekt, een logketen wordt onderbroken of een herstelpunt vóór een bekende fout moet worden gekozen. Noteer hoeveel handelingen nodig zijn, waar instructies onduidelijk zijn en welke afhankelijkheden buiten de back-upomgeving ontbreken. De test is bedoeld om tekortkomingen te vinden, niet alleen om een geslaagd resultaat af te vinken.
Controleer na herstel zowel technische integriteit als functionele bruikbaarheid. Databasechecks kunnen beschadiging signaleren, terwijl applicatiegerichte controles aantonen dat cruciale tabellen, relaties en transacties logisch kloppen. Vergelijk bijvoorbeeld totalen, recente records of domeinspecifieke invarianten met betrouwbare referenties. Bewaar testresultaten met datum, gebruikte back-upidentificatie, herstelpunt, bevindingen en eventuele afwijkingen. Herhaal tests na veranderingen in databaseversie, opslag, encryptie of back-upsoftware. Zo wordt zichtbaar of een wijziging de herstelketen heeft beïnvloed, ook wanneer dagelijkse back-upmeldingen geen fout tonen.
Herstelbaarheid koppelen aan RPO, RTO en afhankelijkheden
RPO en RTO beschrijven verschillende aspecten van herstel. Recovery Point Objective geeft aan hoeveel gegevensverlies in tijd aanvaardbaar is; Recovery Time Objective beschrijft hoe lang herstel mag duren voordat een dienst weer beschikbaar moet zijn. Deze begrippen sturen technische keuzes. Een lage RPO vraagt bijvoorbeeld om frequente back-ups of doorlopende logarchivering. Een lage RTO vraagt om een herstelpad dat niet afhankelijk is van lange kopieer- en opbouwstappen. Beide doelen moeten worden getoetst aan werkelijk gemeten herstel, niet alleen aan ontwerpdocumenten.
De hersteltijd bestaat uit meer dan het terugzetten van databasebestanden. Opslag moet beschikbaar zijn, de juiste omgeving moet worden ingericht, logs moeten worden afgespeeld en controles moeten worden uitgevoerd. Bij grote databases kan overdracht van back-updata de beperkende factor zijn; bij kleine databases kan ontbrekende configuratie of handmatige autorisatie juist de meeste tijd kosten. Meet daarom afzonderlijke stappen tijdens tests en leg vast waar wachttijd ontstaat. Een kopie op afstand kan bescherming bieden tegen locatieverlies, maar de netwerkcapaciteit naar die kopie bepaalt mede hoe snel herstel daarvandaan mogelijk is.
Ook databases staan zelden op zichzelf. Applicaties, DNS, identiteitsdiensten, berichtwachtrijen en externe koppelingen kunnen nodig zijn om een herstelde database veilig te gebruiken. Een herstelplan bepaalt welke afhankelijkheden eerst beschikbaar moeten zijn en welke integraties tijdelijk uitgeschakeld blijven om dubbele verwerking te voorkomen. Replicatie vraagt extra aandacht: een foutieve wijziging kan snel naar replica’s worden gekopieerd, waardoor replicatie op zichzelf geen historische back-up vervangt. Documenteer welke gegevensbron leidend is, hoe herstel met afhankelijke systemen wordt afgestemd en welke controles nodig zijn voordat verwerking wordt hervat.
Veelgestelde vragen
Wat is het verschil tussen RPO en RTO bij databaseherstel?
RPO bepaalt hoeveel gegevensverlies je maximaal accepteert; RTO bepaalt hoe lang de database maximaal onbeschikbaar mag zijn. Een RPO van vijftien minuten betekent dat je bij een incident hoogstens vijftien minuten aan wijzigingen wilt verliezen. Een RTO van twee uur betekent dat de dienst binnen twee uur weer beschikbaar moet zijn. Bepaal deze grenzen per database op basis van de gevolgen van gegevensverlies en uitval. Gebruik ze daarna om back-upfrequentie, herstelmethoden en testdoelen vast te stellen.
Is databasereplicatie een vervanging voor back-ups?
Nee, replicatie vervangt geen back-ups, omdat wijzigingen op de primaire database vaak ook naar replica’s worden gekopieerd. Een foutieve verwijdering, beschadiging of kwaadwillige wijziging kan daardoor snel op meerdere systemen terechtkomen. Replicatie kan de beschikbaarheid verhogen en een failover versnellen, terwijl back-ups herstel naar een eerdere toestand mogelijk maken. Gebruik ze daarom voor verschillende doelen en zorg dat back-ups onafhankelijk van de replica’s worden bewaard.
Hoe bepaal ik hoe vaak ik een databaseback-up moet maken?
Bepaal de back-upfrequentie aan de hand van hoeveel wijzigingen je sinds het vorige bruikbare herstelpunt maximaal kwijt wilt raken. Breng per database in kaart hoe snel gegevens veranderen, hoe belangrijk recente transacties zijn en welke uitvaltijd aanvaardbaar is. Vergelijk die grens met de tijd die nodig is om een back-up te maken en te herstellen. Als periodieke kopieën niet vaak genoeg zijn, kan aanvullende logarchivering nodig zijn om kleinere herstelintervallen te bereiken.
Hoe bereken ik hoeveel opslagruimte databaseback-ups nodig hebben?
Schat de benodigde opslag door de werkelijke omvang en groei van back-ups gedurende de volledige bewaartermijn te meten. Neem niet alleen de databasekopieën mee, maar ook incrementele bestanden, transactielogboeken, meerdere herstelpunten en eventuele extra kopieën op andere locaties. Houd rekening met groei van de database, pieken in wijzigingsvolume, compressie en ruimte voor tijdelijke bestanden tijdens het maken of terugzetten. Controleer de schatting regelmatig aan de hand van het gemeten verbruik en reserveer capaciteit voordat opslag volloopt.
Kan ik productieback-ups gebruiken in een testomgeving?
Dat kan technisch, maar productieback-ups kunnen persoonsgegevens, geheimen of andere vertrouwelijke informatie bevatten en zijn daarom niet automatisch geschikt voor testgebruik. Beperk toegang tot de testomgeving en gebruik waar mogelijk gemaskeerde of synthetische gegevens. Maskeer gevoelige waarden nadat je een kopie hebt teruggezet, en controleer dat testapplicaties geen echte e-mails, betalingen of berichten versturen. Leg ook vast wie de kopie mag gebruiken en wanneer die wordt verwijderd, zodat testdata niet onnodig blijft bestaan.
