Gå til indhold
atlas

Genopretningsmål (RTO/RPO)

Også kendt som: RTO, RPO, genoprettelsestid, tolereret datatab

To aftalte grænser ved nedbrud - hvor længe et system må være nede (RTO), og hvor meget af de seneste data der må gå tabt (RPO).

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

Recovery time objective (RTO) er den længste tid, et system eller en proces må være ude af drift, før skaden bliver uacceptabel. Recovery point objective (RPO) er det ældste tidspunkt, data må gendannes fra, og afgør dermed, hvor ofte der skal tages backup.

Forklaret enkelt

Hvis din telefon går i stykker, er RTO, hvor længe du kan klare dig uden; RPO er, hvor mange dages billeder du kan tåle at miste siden din seneste kopi.

I praksis

En dansk webshop beslutter, at ordresystemet skal have en RTO på fire timer og en RPO på et kvarter, så den kopierer ordrer til en anden lokation hvert kvarter og øver et skifte to gange om året.

Hvorfor det betyder noget

De to tal gør et vagt ønske om at "være hurtigt oppe igen" til et klart mål, der afgør, hvor meget der skal bruges på backup og reservesystemer.

Teknisk uddybning

NIST SP 800-34 Rev. 1 (§3.2) definerer tre beslægtede værdier, der kommer ud af konsekvensanalysen. Den maksimalt tålelige nedetid (MTD) er den samlede tid, en forretningsproces kan være afbrudt, før konsekvensen bliver uacceptabel. Recovery time objective (RTO) er den længste tid, en systemressource kan være utilgængelig, før det påvirker de processer, der afhænger af den, og den skal være kortere end MTD. Recovery point objective (RPO) er det tidspunkt før afbrydelsen, som data skal kunne gendannes til, med andre ord det størst acceptable datatab. En udbredt opdeling er MTD = RTO + WRT, hvor work recovery time dækker verifikation af gendannede systemer, genindtastning af data og afvikling af efterslæb, før forretningsprocessen er helt tilbage. ISO 22301 bruger det tilsvarende begreb maksimalt tålelig afbrydelsesperiode (MTPD), hvor RTO'erne fastsættes inden for den, og tilføjer det minimale kontinuitetsniveau (MBCO) for det reducerede serviceniveau, der er acceptabelt under afbrydelsen.

RPO styrer designet af databeskyttelsen. En natlig backup giver en RPO på op til omkring 24 timer; snapshots hver time eller log shipping bringer den ned på minutter; synkron replikering kommer tæt på nul, men giver skrivelatens, der vokser med afstanden, og replikerer logisk korruption og ransomwarekryptering øjeblikkeligt, så den skal kombineres med kopier fra bestemte tidspunkter. RTO styrer designet af genopretningen: gendannelseshastighed, tiden til at etablere infrastruktur, rækkefølgen af afhængigheder og medarbejdernes tilgængelighed om natten og i weekender. For store datamængder er gendannelseshastigheden fra backuplageret eller over en WAN-forbindelse ofte den begrænsende faktor, og gendannelse af flere titals terabyte kan tage dage, selv når selve backuppen er intakt.

Målene er mål, ikke målinger. Den faktiske genoprettelsestid og det faktiske gendannelsespunkt måles ved øvelser, og forskellen mellem mål og virkelighed er det mest nyttige resultat af en DR-test. En hyppig fejl er at fastsætte én RTO pr. system uden at tænke på scenariet: failover af en virtuel maskine efter en hardwarefejl kan tage minutter, mens genopbygning efter ransomware i hele domænet kræver forensisk frigivelse, ren infrastruktur og nulstilling af adgangsoplysninger, hvilket kan tage uger. Målene bør derfor testes mod et ødelæggende cyberscenarie og ikke kun mod en teknisk fejl.

RTO og RPO adskiller sig fra service level objectives. En SLO beskriver pålideligheden i normal drift, fx 99,9 % tilgængelighed over en måned, og styres med fejlbudgetter, mens genopretningsmål beskriver den tålelige konsekvens, når en afbrydelse allerede er sket. Begge skal hænge sammen med kontrakterne: en SLA, der lover genopretning inden fire timer, er meningsløs, hvis DRP'ens testede genoprettelsestid er to døgn.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

  1. Aktivfortegnelse (asset inventory)
  2. →Tilgængelighed
  3. →CIA-triaden
  4. →Aktiv
  5. →Kritiske aktiver
  6. →Konsekvens
  7. →Konsekvensanalyse (BIA)
  8. →Genopretningsmål (RTO/RPO)

Relationer

Forveksl ikke med
Serviceniveaumål (SLO)
Bruges sammen med
Backup

Kilder og videre læsning

Standarder og officielle tekster

  • NIST SP 800-34 Rev. 1 - Contingency Planning Guide for Federal Information Systems · NIST
  • ISO 22301:2019 - Business continuity management systems, Requirements · ISO

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.