Wanneer een database uitvalt, bepalen twee factoren hoe groot de schade is: hoeveel data je kwijtraakt en hoe lang het herstel duurt. De eerste factor, de RPO, verschilt aanzienlijk tussen relationele en niet-relationele databases. Wie dat verschil begrijpt, maakt betere keuzes over back-upstrategieën, replicatie en herstelplannen.
Of je nu werkt met SQL Server, PostgreSQL, MongoDB of Cassandra: de architectuur van een database bepaalt direct wat haalbaar is op het gebied van dataverlies. In dit artikel beantwoorden we de meest gestelde vragen over RPO bij beide databasetypen, zodat je een herstelstrategie kunt opzetten die past bij jouw situatie.
Wat is RPO en waarom is het belangrijk voor databases?
RPO staat voor Recovery Point Objective en geeft aan hoeveel dataverlies een organisatie maximaal kan accepteren bij een storing of incident. Concreet: als jouw RPO vier uur is, mag er in een herstelscenario maximaal vier uur aan transacties verloren gaan. Hoe lager de RPO, hoe minder dataverlies is toegestaan en hoe intensiever de herstelinfrastructuur moet zijn.
Voor databases is de RPO een kritieke parameter, omdat elke transactie, elke klantinteractie en elke wijziging die buiten het herstelvenster valt, permanent verloren is. Een webshop met een RPO van 24 uur riskeert een volledige dag aan bestellingen te verliezen. Een financieel systeem met dezelfde RPO riskeert boekhoudkundige inconsistenties die moeilijk te reconstrueren zijn.
De RPO is ook de basis voor technische keuzes: hoe frequent worden back-ups gemaakt, wordt er gebruikgemaakt van continue replicatie, en hoe worden transactielogs bewaard? Zonder een vastgestelde RPO zijn dit willekeurige beslissingen in plaats van bewuste afwegingen.
Hoe werkt RPO bij relationele databases zoals SQL Server?
Bij relationele databases zoals SQL Server, Oracle en PostgreSQL wordt de RPO primair beheerst via transactielogs. Elke wijziging in de database wordt eerst vastgelegd in een transactielog voordat deze definitief wordt doorgevoerd. Door deze logs regelmatig te back-uppen of te repliceren, kun je de database herstellen tot vrijwel elk gewenst moment.
Transactielogs als fundament van een lage RPO
SQL Server biedt bijvoorbeeld log shipping, waarbij transactielogs periodiek naar een secundaire server worden gestuurd. De frequentie van deze overdracht bepaalt direct de RPO: log shipping elke vijftien minuten geeft een RPO van maximaal vijftien minuten. Wil je een RPO dichter bij nul, dan is Always On Availability Groups de aangewezen technologie, waarbij wijzigingen vrijwel real-time worden gesynchroniseerd naar een standby-instantie.
Back-upstrategie bij relationele databases
Een volledige back-up eens per dag, gecombineerd met differentiële back-ups en log-back-ups elke vijftien minuten, is een veelgebruikt patroon. Dit geeft een RPO van vijftien minuten zonder dat de volledige database elke vijftien minuten opnieuw weggeschreven hoeft te worden. De strikte ACID-eigenschappen van relationele databases, waarbij transacties altijd volledig worden doorgevoerd of volledig worden teruggedraaid, maken dit nauwkeurige herstel mogelijk.
Hoe verschilt RPO bij niet-relationele databases zoals MongoDB of Cassandra?
Bij niet-relationele databases zoals MongoDB of Cassandra werkt RPO anders, omdat deze systemen fundamenteel anders omgaan met datadurabiliteit en consistentie. In plaats van een centrale transactielog werken veel NoSQL-databases met gedistribueerde replicatie, waarbij data gelijktijdig op meerdere nodes wordt opgeslagen. De RPO wordt hier bepaald door het replicatiemodel en de consistentie-instellingen, niet door een centrale log.
Cassandra en gedistribueerde replicatie
Cassandra repliceert data automatisch over meerdere nodes op basis van een instelbare replication factor. Als een node uitvalt, is de data nog beschikbaar op andere nodes. Dit maakt Cassandra van nature robuust bij hardwarefouten, maar het maakt gerichte herstelacties naar een specifiek tijdstip complexer. Cassandra heeft geen ingebouwde point-in-time recovery zoals SQL Server dat heeft.
MongoDB en oplog-replicatie
MongoDB gebruikt een oplog (operations log) in replica sets, vergelijkbaar met het principe van transactielogs bij relationele databases. Via de oplog kun je wijzigingen repliceren naar secundaire nodes en in theorie herstellen tot een specifiek moment. De RPO bij MongoDB hangt sterk af van hoe de replica set is geconfigureerd en hoe snel de oplog wordt gesynchroniseerd tussen primaire en secundaire nodes.
Wat zijn de grootste verschillen in RPO tussen beide databasetypen?
De grootste verschillen in RPO tussen relationele en niet-relationele databases liggen in drie gebieden: de granulariteit van herstel, de consistentiegaranties en de complexiteit van de herstelinfrastructuur.
- Granulariteit van herstel: Relationele databases bieden doorgaans nauwkeurigere point-in-time recovery dankzij transactielogs. NoSQL-databases zijn vaker ontworpen voor beschikbaarheid en schaalbaarheid, waarbij exact herstel tot een tijdstip minder centraal staat.
- Consistentiegaranties: Relationele databases hanteren ACID-transacties, wat herstel tot een consistente toestand garandeert. Veel NoSQL-databases werken met eventual consistency, waardoor herstel soms leidt tot een toestand die niet volledig consistent is over alle nodes.
- Complexiteit van de herstelinfrastructuur: Een RPO van vijf minuten is bij SQL Server relatief eenvoudig te realiseren via log-back-ups. Bij gedistribueerde NoSQL-systemen vereist een vergelijkbare RPO een zorgvuldige configuratie van replicatie, back-upfrequentie en consistentie-instellingen over meerdere nodes tegelijk.
Dit betekent niet dat NoSQL-databases slechter zijn voor herstel, maar wel dat de aanpak fundamenteel verschilt en meer maatwerk vraagt.
Welke RPO-doelstelling is realistisch voor jouw databaseomgeving?
Een realistische RPO hangt af van drie factoren: de bedrijfskritikaliteit van de data, de beschikbare infrastructuur en het budget voor herstelmaatregelen. Er bestaat geen universele RPO die voor elke organisatie geldt.
Als vuistregel geldt: hoe meer een uur dataverlies de bedrijfsvoering schaadt, hoe lager de RPO moet zijn en hoe meer investering gerechtvaardigd is. Een interne rapportagedatabase kan een RPO van 24 uur verdragen. Transactieverwerking voor betalingen of voorraadbeheer vraagt om een RPO van minuten of zelfs seconden.
Bedenk ook dat een lage RPO alleen waarde heeft als er ook regelmatig herstelscenario’s worden getest. Een RPO van vijf minuten op papier die in de praktijk niet werkt, biedt geen enkele bescherming. Het testen van herstel is daarmee net zo belangrijk als het inrichten ervan.
Hoe verbeter je de RPO van een bestaande databaseomgeving?
De RPO van een bestaande databaseomgeving verbeter je door de frequentie van back-ups te verhogen, replicatie in te richten en herstelprocessen te documenteren en te testen. Kleine aanpassingen in de back-upstrategie kunnen de RPO al aanzienlijk verlagen zonder grote infrastructurele wijzigingen.
Concrete stappen om de RPO te verbeteren:
- Verhoog de frequentie van transactielog-back-ups. Bij SQL Server of PostgreSQL kun je log-back-ups inplannen op intervallen van vijf tot vijftien minuten, wat de RPO direct verlaagt.
- Richt replicatie in naar een secundaire omgeving. Always On Availability Groups bij SQL Server of replica sets bij MongoDB zorgen voor vrijwel continue synchronisatie.
- Test herstelscenario’s regelmatig. Plan minimaal eens per kwartaal een gestructureerde hersteltest om te verifiëren dat de RPO ook in de praktijk haalbaar is.
- Documenteer de herstelstappen. Zorg dat het team zonder improvisatie weet welke stappen gezet moeten worden bij een incident.
- Evalueer de consistentie-instellingen bij NoSQL-databases. Bij Cassandra of MongoDB kun je via write concern en replication factor de duurzaamheid van schrijfoperaties verhogen, wat de RPO verlaagt.
Verbeteringen aan de RPO zijn vaak incrementeel: begin met de meest kritieke databases en werk van daaruit verder.
Hoe wij helpen bij het verbeteren van jouw RPO-strategie
Een goede RPO-strategie begint met inzicht in wat je nu hebt en wat je organisatie werkelijk nodig heeft. Wij helpen organisaties bij het inrichten, testen en verbeteren van hun databaseherstelstrategie, voor zowel relationele als niet-relationele omgevingen.
Wat wij concreet doen:
- We brengen de huidige back-up- en replicatieconfiguratie in kaart voor omgevingen zoals SQL Server, Azure SQL, Oracle en PostgreSQL.
- We stellen een RPO vast die aansluit op de bedrijfskritikaliteit van jouw data.
- We richten de juiste herstelinfrastructuur in, van log-back-ups tot Always On Availability Groups.
- We plannen en begeleiden regelmatige, gestructureerde hersteltests, zodat de RPO ook in de praktijk haalbaar is.
- We zorgen voor heldere documentatie, zodat jouw team ook onder druk weet wat te doen.
Wil je weten hoe robuust jouw huidige databaseomgeving is bij een incident? Neem contact op met Brander Company, dan kijken we samen naar een herstelstrategie die past bij jouw organisatie.
