Wanneer een database uitvalt, telt elke seconde. De impact van zo’n storing hangt niet af van geluk, maar van de afspraken die je vooraf hebt gemaakt over herstel. Drie begrippen staan daarbij centraal: RTO, RPO en MTD. Wie deze termen begrijpt en toepast, legt de basis voor een solide database recovery-strategie die écht werkt onder druk.
In dit artikel beantwoorden we de meest gestelde vragen over RTO, RPO en MTD, zodat je precies weet wat deze begrippen betekenen, hoe je ze bepaalt en hoe je ze vertaalt naar een concreet herstelplan voor jouw organisatie.
Wat zijn RTO, RPO en MTD bij database recovery?
RTO, RPO en MTD zijn drie meetbare parameters die samen bepalen hoe een organisatie omgaat met database-uitval. De RTO (Recovery Time Objective) is de maximale tijd dat een systeem offline mag zijn. De RPO (Recovery Point Objective) is de maximale hoeveelheid dataverlies die acceptabel is. De MTD (Maximum Tolerable Downtime) is de absolute grens waarboven de bedrijfsschade onherstelbaar wordt.
Stel je voor dat een database om 14:00 uur uitvalt. Als jouw RPO vier uur is, mag je maximaal terugvallen op een back-up van 10:00 uur. Als jouw RTO twee uur is, moet het systeem uiterlijk om 16:00 uur weer operationeel zijn. De MTD geeft aan hoelang de organisatie dit überhaupt kan overleven, bijvoorbeeld acht uur, voordat klanten afhaken of contractuele verplichtingen worden geschonden.
Samen vormen deze drie parameters de ruggengraat van elke serieuze database recovery-strategie. Ze dwingen organisaties om herstel concreet en meetbaar te maken, in plaats van te vertrouwen op vage aannames.
Wat is het verschil tussen RTO, RPO en MTD?
Het kernverschil is wat elk begrip meet: RTO meet hersteltijd, RPO meet dataverlies en MTD meet de bedrijfstolerantie voor uitval. Ze zijn gerelateerd, maar niet hetzelfde, en verwarring tussen de drie leidt tot herstelplannen die op papier kloppen, maar in de praktijk tekortschieten.
RTO versus RPO
RTO gaat over tijd: hoe snel moet het systeem weer draaien? RPO gaat over data: hoeveel informatie mag je kwijtraken? Een financieel systeem kan een lage RPO vereisen, met vrijwel nul dataverlies, maar een hogere RTO accepteren als herstel een paar uur duurt. Een klantenportaal kan juist een lage RTO nodig hebben omdat klanten direct merken dat het systeem plat ligt, maar een RPO van enkele uren accepteren.
MTD als overkoepelend kader
De MTD fungeert als het overkoepelende kader. De RTO moet altijd kleiner zijn dan de MTD; anders komt het systeem pas weer online nadat de schade al onherstelbaar is. MTD wordt bepaald door bedrijfsrisico’s: reputatieschade, omzetverlies, boetes of het schenden van SLA-verplichtingen. Het is geen technische parameter, maar een zakelijke grens die door het management wordt vastgesteld.
Hoe bepaal je de juiste RTO en RPO voor jouw database?
De juiste RTO en RPO bepaal je op basis van de bedrijfsimpact van uitval, niet op basis van wat technisch haalbaar is. Breng eerst in kaart welke processen afhankelijk zijn van de database, wat een uur uitval kost en hoeveel dataverlies per proces acceptabel is. Vervolgens vertaal je die zakelijke eisen naar technische doelstellingen.
Een praktische aanpak werkt in drie stappen:
- Inventariseer afhankelijkheden: Welke applicaties, gebruikers en processen zijn afhankelijk van welke database? Niet elke database is even kritisch.
- Kwantificeer de impact: Wat kost een uur uitval in euro’s, klantvertrouwen of operationele capaciteit? Dit geeft richting aan de MTD.
- Stel prioriteiten: Databases die bedrijfskritische processen ondersteunen, krijgen een lagere RTO en RPO dan systemen voor interne rapportage of archivering.
Het is verleidelijk om overal de strengste normen te hanteren, maar dat drijft de kosten onnodig op. Een goed herstelplan differentieert per systeem en koppelt de investering aan het werkelijke risico.
Welke gevolgen heeft een te hoge RTO of RPO voor een organisatie?
Een te hoge RTO of RPO betekent dat je herstelplan de werkelijke bedrijfsschade niet beperkt. Als de RTO hoger is dan de MTD, herstel je het systeem pas nadat de organisatie al onomkeerbare schade heeft geleden. Een te hoge RPO betekent dat je bij herstel meer data verliest dan de organisatie kan accepteren.
De concrete gevolgen variëren per sector en situatie, maar komen vaak neer op:
- Financieel verlies door stilstand van verkoop, productie of dienstverlening
- Reputatieschade bij klanten en partners die merken dat systemen niet beschikbaar zijn
- Boetes of contractuele sancties bij het schenden van SLA-afspraken
- Dataverlies dat handmatig moet worden gereconstrueerd, wat tijd kost en fouten kan veroorzaken
- Juridische risico’s bij verlies van klant- of transactiedata in gereguleerde sectoren
Organisaties onderschatten vaak hoe snel de schade oploopt. Een systeem dat twee uur langer offline is dan de MTD toestaat, kan weken aan herstelwerk in klantrelaties vergen.
Hoe stel je een databaseherstelplan op met RTO en RPO als basis?
Een databaseherstelplan op basis van RTO en RPO begint met het vastleggen van de doelstellingen per systeem, gevolgd door de keuze van back-upstrategie, failovermechanismen en herstelprocedures die die doelstellingen daadwerkelijk halen. Documentatie en regelmatige tests zijn onmisbaar.
Stap 1: Doelstellingen vastleggen
Leg per database de RTO, RPO en MTD vast in een document dat zowel door IT als door het management is goedgekeurd. Dit voorkomt discussie op het moment dat er daadwerkelijk iets misgaat.
Stap 2: Technische maatregelen afstemmen
Kies back-upfrequentie, retentiebeleid en herstellocatie op basis van de vastgestelde RPO. Een RPO van één uur vereist andere maatregelen dan een RPO van 24 uur. Overweeg voor kritische systemen aanvullende oplossingen zoals log shipping, database mirroring of Always On Availability Groups in SQL Server.
Stap 3: Testen en documenteren
Een herstelplan dat nooit is getest, bestaat alleen op papier. Plan regelmatige hersteltests in waarbij je daadwerkelijk een back-up terugzet en meet of je de RTO haalt. Leg de stappen vast in een runbook dat ook door iemand zonder diepgaande databasekennis kan worden uitgevoerd in een crisissituatie.
Welke tools ondersteunen database recovery op basis van RTO en RPO?
De keuze van tools hangt af van het databaseplatform, maar voor de meest gebruikte omgevingen zijn er volwassen oplossingen beschikbaar die RTO- en RPO-doelstellingen direct ondersteunen.
Voor de meest gebruikte platforms zijn dit de relevante opties:
- SQL Server: Native back-up en herstel, Always On Availability Groups voor hoge beschikbaarheid, en Azure Backup voor cloudgebaseerde hersteloplossingen
- Azure SQL: Ingebouwde geo-redundante back-ups, point-in-time restore en automatische failovergroepen
- Oracle: Recovery Manager (RMAN) voor gestructureerde back-up en herstel, Data Guard voor standby-databases
- PostgreSQL: pg_dump en pg_basebackup voor back-ups, gecombineerd met WAL-archivering voor point-in-time recovery
Naast platformspecifieke tools zijn er ook overkoepelende oplossingen zoals Veeam, Zerto en Azure Site Recovery, waarmee je meerdere databases en omgevingen vanuit één console beheert. De keuze hangt af van de complexiteit van de omgeving, het budget en de gewenste automatiseringsgraad.
Hoe wij helpen met database recovery
Bij Brander Company geloven we dat een goede herstelstrategie begint voordat er iets misgaat. In de praktijk zien we dat hersteltests bij veel organisaties nooit worden uitgevoerd, totdat het te laat is. Wij helpen je dat te veranderen met een aanpak die concreet en toepasbaar is:
- We bepalen samen met jou de juiste RTO, RPO en MTD per database, gebaseerd op werkelijke bedrijfsrisico’s
- We bouwen en documenteren herstelstrategieën voor SQL Server, Azure SQL, Oracle en PostgreSQL
- We plannen en begeleiden regelmatige hersteltests, zodat je weet dat je plan ook onder druk werkt
- We zorgen voor een helder runbook, zodat jouw team precies weet welke stappen te zetten in een crisissituatie
- We bewaken en optimaliseren je back-up- en herstelomgeving als vast onderdeel van ons beheer
Geen snelle, tijdelijke oplossingen, maar een robuuste recovery-strategie die aansluit op jouw specifieke situatie. Wil je weten hoe jouw huidige herstelplan zich verhoudt tot jouw RTO en RPO? Neem contact op met Brander Company en we nemen het samen met je door.
