RTO og RPO i disaster recovery: definitioner, eksempler og sådan fastsætter du dem

RTO (recovery time objective) er den længste tid, et system må være nede efter en afbrydelse. RPO (recovery point objective) er den største datamængde, du har råd til at miste, målt som tiden siden den seneste brugbare kopi. Et RTO på 4 timer og et RPO på 15 minutter betyder: online igen inden for 4 timer, med højst 15 minutters datatab.

Vigtigste pointer

• RTO ser fremad fra nedbruddet (hvor længe går der, før tjenesten er tilbage). RPO ser bagud (hvor gammel er den seneste gode kopi af data).
• Begge dele er forretningsbeslutninger. Fastsæt dem pr. system gennem en business impact-analyse, og vælg derefter den teknologi, der opfylder dem.
• Backupfrekvensen sætter loftet for dit RPO: med backup hver 4. time er det værste datatab omkring 4 timer.
• Lavere mål koster mere. RTO/RPO tæt på nul kræver replikering og standbykapacitet på en ekstra lokation.
• Mål på papir betyder lidt, før en test har målt den faktiske gendannelsestid og det faktiske datatab.

Hvad er RTO i disaster recovery?

RTO er den maksimalt acceptable tid fra en tjeneste går ned, til den er tilbage. AWS definerer det som "den maksimalt acceptable forsinkelse mellem afbrydelsen af tjenesten og genoprettelsen af tjenesten" (oversat) i whitepaperet Disaster Recovery of Workloads on AWS. NIST ser det fra forretningens side: den tid, et system kan være under gendannelse, "før det får negativ indvirkning på organisationens mission eller mission-/forretningsprocesser" (oversat).

RTO dækker hele gendannelsen, ikke kun den tekniske restore. Opdagelse, beslutningen om at aktivere DR-planen, gendannelse af data, validering af applikationen og omstilling af brugerne tæller alle med. Teams, der kun tager tid på selve restore, overskrider som regel deres RTO ved en reel hændelse.

Hvad er RPO i disaster recovery?

RPO er det maksimalt acceptable datatab, udtrykt i tid. AWS kalder det "den maksimalt acceptable tid siden det seneste gendannelsespunkt for data" (oversat). Hvis dit RPO er 1 time, skal du efter en fejl kunne gendanne data, der højst er 1 time gamle.

RPO afhænger af, hvor ofte du kopierer data. Natlige backups giver et RPO i værste fald på omkring 24 timer. Log-backups af databasen hvert 15. minut giver cirka 15 minutter. Kontinuerlig replikering kan bringe det tæt på nul, med et forbehold, der omtales nedenfor: replikering kopierer også korruption og sletninger.

RTO og RPO: forskellen i overblik

Eksempler med tal

Eksempel 1: et ordresystem. En webshop fastsætter et RTO på 4 timer og et RPO på 15 minutter. Databasen går ned kl. 10.00. Shoppen skal kunne tage imod ordrer igen senest kl. 14.00, og højst ordrerne fra kl. 9.45 til 10.00 må mangle. Natlige backups kan ikke klare det; shoppen har brug for backup af transaktionslog eller replikering mindst hvert 15. minut, plus en scriptet måde at genopbygge applikationslaget på inden for 4 timer.

Eksempel 2: kontrol af en backupplan. Et økonomisystem sikkerhedskopieres hver 6. time, og en fuld gendannelse tager 3 timer. Hvis forretningen kræver et RPO på 1 time og et RTO på 2 timer, fejler begge mål: det værste datatab er omkring 6 timer, og selve gendannelsen overskrider RTO. Løsningen er enten hyppigere backups plus en hurtigere gendannelsesmetode eller en forretningsbeslutning om at acceptere løsere mål.

Eksempel 3: opdeling af porteføljen i niveauer. De fleste virksomheder samler systemerne i niveauer i stedet for at fastsætte mål ét for ét. Tallene nedenfor er illustrative og ikke en standard.

Strategikolonnen følger de fire tilgange i AWS' whitepaper, hvor backup og restore giver gendannelse på timer og multi-site active/active i tæt på realtid. Vores guide til disaster recovery-planen forklarer hver strategi og hvordan du vælger.

Hvordan hænger RTO og RPO sammen med maksimalt tolerabel nedetid?

Maksimalt tolerabel nedetid (MTD) er, hvor længe en forretningsproces kan være afbrudt, før skaden bliver alvorlig. NIST SP 800-34 forklarer, at RTO "normalt skal være kortere end MTD", fordi medarbejderne, når systemerne er tilbage, stadig har brug for tid til at indhente efterslæbet og genindtaste tabte data. RPO indgår ikke i MTD. Det beskriver, hvor mange data processen har råd til at miste (NIST SP 800-34 Rev. 1).

I praksis: Hvis ordreprocessen kan klare 8 timer uden systemer, og det tager 2 timer at indhente efterslæbet, skal it-RTO være 6 timer eller mindre.

Sådan fastsætter du RTO og RPO

1. Opstil forretningsprocesser og deres afhængigheder. Knyt hver proces til de applikationer, databaser, identitetstjenester og tredjeparter, den bruger.
2. Vurdér konsekvensen af nedetid og datatab over tid. Omsætning, kontraktlige bøder, regulatorisk eksponering, sikkerhed og omdømme. AWS påpeger, at konsekvensen kan afhænge af tidspunktet: et lønsystem, der er nede lige før lønudbetalingen, betyder langt mere end et, der er nede lige efter.
3. Foreslå mål pr. niveau, og lad forretningsejeren godkende dem. It bør ikke vælge dem alene.
4. Prissæt mulighederne. AWS anbefaler, at hvis gendannelsesstrategien koster mere end det nedbrud, den beskytter mod, "bør den ikke indføres, medmindre der er en sekundær drivkraft som regulatoriske krav" (oversat).
5. Design og test. Byg mekanismerne til backup, replikering og failover, kør derefter en test og registrer den opnåede gendannelsestid og det opnåede gendannelsespunkt.
6. Gennemgå årligt og efter større ændringer. Systemer flytter sig mellem niveauerne, efterhånden som forretningen ændrer sig.

Hvilke teknologier opfylder hvilke mål?

• Planlagte backups og snapshots passer til RPO på timer. De beskytter godt mod korruption og sletning, fordi hver kopi er et fast tidspunkt.
• Point-in-time recovery (log-backups af databasen) bringer RPO ned på minutter for databaser.
• Asynkron replikering til en anden region giver et RPO på sekunder til minutter, afhængigt af replikeringsforsinkelsen.
• Synkron replikering på tværs af Availability Zones giver et RPO tæt på nul, til gengæld for længere skrivetid. Microsofts Azure Well-Architected-vejledning om disaster recovery anbefaler synkron replikering på tværs af zoner til data med høj prioritet og asynkron replikering på tværs af regioner til data med lavere prioritet.
• Standbymiljøer og automatisering (pilot light, warm standby, infrastructure as code, scriptet DNS-failover) nedbringer RTO.

Pas på replikeringsfælden. AWS bemærker, at kontinuerlig replikering "måske ikke beskytter mod katastrofehændelser som datakorruption eller ondsindede angreb" (oversat) lige så godt som point-in-time-backups. En ransomware-krypteret database replikeres lige så hurtigt som en sund, så behold point-in-time-kopier ved siden af replikaerne.

Sådan dokumenterer du, at du opfylder målene

Mål, antag ikke. Notér under hver DR-test, hvornår nedbruddet startede, hvornår planen blev aktiveret, hvornår tjenesten kom tilbage, og tidsstemplet på den seneste gendannede transaktion. Så har du dit opnåede RTO og RPO. Microsofts vejledning anbefaler en blanding af tabletop-øvelser, tørkørsler i miljøer uden for produktion og øvelser på produktionsniveau. Følg resultaterne over tid, og ret det langsomste trin først.

Sådan hjælper Opsio

Opsio afholder business impact-workshops, fastsætter RTO/RPO pr. niveau sammen med dine forretningsejere og bygger og tester det tilsvarende gendannelsesdesign på AWS og Azure gennem sin cloud disaster recovery-tjeneste. For SaaS-rekrutteringsplatformen WorkBuster var en tilgang med næsten ingen nedetid et ufravigeligt krav, da Opsio flyttede platformen til AWS. Designet bruger en højtilgængelig MySQL-database i flere AZ'er på Amazon RDS, med infrastrukturen defineret i CloudFormation-skabeloner.

Ofte stillede spørgsmål

Hvad er forskellen på RTO og RPO?

RTO er, hvor længe et system må være utilgængeligt efter en afbrydelse. RPO er, hvor mange data, målt i tid, du har råd til at miste. RTO handler om nedetid; RPO handler om datatab.

Hvad er et godt RTO og RPO?

Der findes intet universelt tal. Et betalingssystem kan have brug for minutter på begge, mens et internt rapporteringsværktøj kan acceptere 24 timer. Udled målene af omkostningerne ved nedetid og datatab for hver forretningsproces, og kontrollér derefter, hvad det koster at opfylde dem.

Kan RPO være nul?

Tæt på nul, ja, med synkron replikering eller multi-site active/active-designs. Sandt nul datatab er svært at garantere på tværs af regioner på grund af afstand og latenstid, og replikering alene beskytter ikke mod korruption.

Er RTO det samme som en SLA?

Nej. En SLA er et løfte til kunderne om tilgængelighed eller responstid. RTO er et internt gendannelsesmål for et katastrofescenarie. Dit RTO bør understøtte dine SLA'er, men de måles forskelligt.

Hvor ofte bør gendannelsesmål gennemgås?

Mindst én gang om året og efter større ændringer i systemer, leverandører eller forretningen. Mål dem igen i hver DR-test, for det er de opnåede værdier, der tæller.

Mere fra vores vidensbank: Sådan prissætter du IT-services