RPO en RTO: snel weer op de rit met veilige back-ups
Een back-up van je bedrijfsdata inrichten geeft een veilig gevoel. Er draaien schema’s, kopieën zijn gemaakt en er is opslagcapaciteit. In de meeste gevallen worden de back-ups zonder schijnbare problemen succesvol afgerond. Een back-up is een krachtig middel, maar helaas geen garantie. Een kopie hebben is niet hetzelfde als (snel) je data, systemen en processen kunnen herstellen als het misgaat, bijvoorbeeld na een technische storing, menselijke fout, ransomwareaanval of calamiteit. Binnen de tijd die je verwacht en met het dataverlies dat je acceptabel vindt. In de praktijk kijken we daarom naar RPO en RTO. Jeroen Stokkink, Productmanager multi-cloud, netwerk en managed services bij Acknowledge ICT, gaat in deze blog er nader op in.
Wat betekenen RPO en RTO?
Het is belangrijk de continuïteit concreet te maken zo schrijft Jeroen Stokking. Hiervoor kijken we naar recovery point objective (RPO) en recovery time objective (RTO). Met RPO bepaal je hoeveel data je maximaal mag verliezen. Als je RPO vier uur is accepteer je dat je bij een incident maximaal vier uur aan data kwijt kunt raken. Hoe lang een systeem maximaal offline mag zijn leg je vast met de RTO. Een RTO van acht uur betekent dat het systeem binnen acht uur weer beschikbaar moet zijn. Deze afspraken lijken technisch, maar zijn vooral zakelijk. Ze gaan over de vraag hoeveel stilstand en dataverlies je organisatie kan dragen. Voor een intern archiefsysteem is een langere hersteltijd misschien acceptabel. Voor je ERP, klantportaal, productieomgeving, financiële administratie of andere essentiële applicatie ligt dat anders. Niet ieder systeem hoeft dezelfde RPO en RTO te hebben. Maar voor ieder kritisch systeem moet wel een bewuste keuze worden gemaakt.
Recovery work time
Maar zelfs als je RPO en RTO gehaald worden ben je er nog niet helemaal. Met de work recovery time (WRT) bepaal je hoelang het duurt voordat je organisatie weer operationeel is. Systemen zijn niet alleen beschikbaar, maar processen draaien, gebruikers kunnen werken en de omgeving is gevalideerd. In de praktijk zit hier vaak extra tijd tussen. Systemen kunnen technisch hersteld zijn, maar gebruikers missen toegang, koppelingen werken nog niet volledig of data moet eerst gecontroleerd worden. Die tijd bepaalt wanneer je bedrijf weer écht verder kan. WRT is daarmee vaak de echte maat voor downtime vanuit businessperspectief.
RPO en RTO- snel weer op de rit met veilige back-ups
De gevaarlijke aanname
Veel organisaties denken dat ze weten hoe snel ze kunnen herstellen. Maar in de praktijk is dat vaak gebaseerd op aannames als ‘we maken elke nacht een back-up’ en ‘onze ICT-partner regelt dat’. Dat klinkt logisch, tot het moment dat herstel echt nodig is. Dan blijkt bijvoorbeeld dat de back-up niet compleet is of dat het terugzetten veel langer duurt dan verwacht. Soms is de data wel terug, maar werkt de applicatie niet goed of ontbreken bepaalde rechten, sleutels, configuraties of koppelingen. We zien ook regelmatig dat back-ups niet goed beschermd zijn tegen ransomware en dat back-updata op een locatie staat waar te weinig grip op is. In de praktijk is weet vaak niemand precies wie verantwoordelijk is voor het herstelproces. Op dat moment heb je geen back-upvraagstuk meer, maar een bedrijfscontinuïteitsprobleem.
Restore-test
Een succesvolle back-upmelding zegt dus weinig over de vraag of je organisatie kan herstellen. Daarom is testen essentieel. Niet alleen controleren of de back-up is gemaakt, maar daadwerkelijk terugzetten. Het liefst op een manier die de werkelijkheid zo goed mogelijk benadert. Daarbij wil je weten:
- Welke systemen zijn getest?
- Waar staat onze data?
- Hoeveel data zouden we verliezen?
- Is de data actueel genoeg?
- Hoelang duurt het herstel echt?
- Werkt de applicatie daarna nog?
- Zijn koppelingen met andere systemen intact?
- Zijn rechten en identiteiten correct hersteld?
- Zijn onze RPO- en RTO-afspraken realistisch?
- Wie heeft toegang tot de back-upomgeving?
- Wie is verantwoordelijk voor besluitvorming tijdens herstel?
Een restore-test kan confronterend zijn, maar dat is precies de waarde van het testen. Je ontdekt liever tijdens een gecontroleerde test dat herstel langer duurt dan verwacht, dan tijdens een incident waarbij de organisatie stilligt. Voor daarom op regelmatige basis een restore-test uit.
RPO en RTO- snel weer op de rit met veilige back-ups
Niet alles is even kritisch
Een goede continuïteitsstrategie begint met prioriteren. Niet ieder systeem vraagt om dezelfde maatregelen. Sommige systemen mogen tijdelijk offline zijn, andere systemen moeten zo snel mogelijk terug zijn. Maak daarom onderscheid tussen verschillende typen systemen en data, zoals ERP, CRM, Microsoft 365, databases, productiesystemen of klantportalen. Per onderdeel bepaal je wat acceptabel is. Hoeveel data mag maximaal verloren gaan? Hoe lang mag het systeem offline zijn? Welke afhankelijkheden zijn er? Wie neemt het besluit om herstel te starten? Wie voert het uit? Zonder die keuzes ontstaat er tijdens incidenten een discussie die je op dat moment echt niet kan gebruiken. Bedenk dat wanneer herstel niet lukt of te lang duurt dat niet alleen IT raakt, maar het volledige bedrijf en de keten. Medewerkers kunnen niet werken, klanten kunnen geen gebruikmaken van diensten, financiële processen lopen vertraging op.
Datasoevereiniteit
Onderdeel van datasoevereiniteit
Bij datasoevereiniteit denken veel organisaties aan productieomgevingen, cloudlocaties en toegang tot (kritische) systemen. Maar back-ups worden soms vergeten. Dat is opvallend, want de back-up bevat een kopie van je meest waardevolle data, soms zelfs van bijna alles. Wie grip wil hebben op data, moet ook grip hebben op de kopieën van die data. Daarom zijn ook bij back-ups vragen belangrijk zoals:
- Waar staat de back-updata?
- In welke regio of welk datacenter?
- Wie heeft toegang tot de back-upomgeving?
- Is de data versleuteld?
- Kan een leverancier erbij?
- Valt de opslag onder andere wetgeving?
- Kun je data terughalen of verwijderen?
- Zijn back-ups beschermd tegen ongewenste aanpassing of verwijdering?
Van back-up naar herstelplan
Een volwassen aanpak begint met inzicht in je kritieke processen. Daarna bepaal je welke systemen en data nodig zijn om die processen weer op te starten. Vervolgens leg je per systeem RPO en RTO vast. Niet als technische exercitie, maar samen met de business. Daarna controleer je of je huidige back-up- en hersteloplossing die afspraken ook echt kan waarmaken. Een herstelplan is geen document dat je één keer maakt. Het moet meegroeien met je organisatie, applicaties, cloudgebruik en risico’s.
Een back-up geeft pas zekerheid als herstel is getest. Zolang je niet weet hoe snel systemen terug zijn, hoeveel data je verliest en of applicaties na herstel echt werken blijft continuïteit gebaseerd op vertrouwen. En vertrouwen is belangrijk, maar bij bedrijfskritische systemen niet genoeg. De vraag is dus niet of je een back-up hebt. De vraag is of je bedrijf weer snel kan opstarten wanneer het nodig is. Wil je weten of jouw RPO- en RTO-aannames kloppen met de praktijk? Plan een vrijblijvende digitale reality-check met Acknowledge en HPE.
Door: Jeroen Stokkink, Productmanager multi-cloud, netwerk en managed services bij Acknowledge ICT
