DRP og BCP
Hvad er RTO?
RTO (Recovery Time Objective, mål for genoprettelsestid) er den maksimale tid, en tjeneste må være utilgængelig. Den måles fra hændelsen, eller fra beslutningen om failover, til en bruger igen kan udføre en normal arbejdsopgave. Ikke til en maskine er tændt, hvis applikation endnu ikke er kontrolleret.
Opdateret i oktober 20263 min. læsetid4 kilder citeret
Det vigtigste
- RTO er summen af seks tidsrum: registrering, beslutning, fremskaffelse af adgange, teknisk tid, forretningskontrol, brugernes genadgang.
- NIST skelner det fra den maksimalt acceptable afbrydelsestid (MTD): RTO skal normalt være kortere end MTD.
- Et RTO fastlægges pr. tjeneste: Telefonomstillingen og arkiverne har ikke det samme.
- Kun en test med tidtagning viser, om det skriftlige RTO overholdes.
- Supportens åbningstider og manglende vagtordning er en del af det reelle RTO.
Officiel definition
NIST definerer RTO som den maksimale tid, en ressource i informationssystemet kan være utilgængelig, før konsekvenserne bliver uacceptable for de aktiviteter, den understøtter. NIST skelner det fra den maksimalt acceptable afbrydelsestid (MTD), som er den samlede nedetid, ledelsen accepterer for en aktivitet. RTO skal sikre, at MTD ikke overskrides: Det er derfor normalt kortere.
ANSSI, Frankrigs nationale agentur for cybersikkerhed, bruger begrebet maksimalt acceptabel afbrydelsesvarighed (DMIA). Agenturet kræver, at en backupstrategi tager højde for den for hver forretningsværdi, og at en gendannelsesrækkefølge fastlægges på forhånd ud fra afhængigheder (DNS, katalogtjeneste …) og applikationernes kritikalitet.
Hvad RTO er summen af
Ved en klassisk gendannelse:
- tiden til at opdage nedbruddet;
- tiden til at beslutte og få fat i den person, der ved, hvad der skal gøres;
- tiden til at finde nøgler, adgangskoder og procedure;
- den tekniske tid til kopiering eller opstart;
- tiden til kontrol udført af en forretningsbruger;
- tiden til, at arbejdsstationer eller fjernklienter igen får adgang til tjenesten (DNS, VPN, IP).
Et RTO »på to timer«, som en software lover, dækker ofte kun trin 4 under laboratorieforhold. Det reelle RTO er summen af alle seks. Om natten og i weekenden kan trin 2 alene overstige to timer, hvis ingen har vagt.
For en BCP er trin 4 og 6 forberedt på forhånd. Tilbage er registreringen og risikoen for en failover, som ingen tør godkende.
RTO og RPO forhandles ikke op mod hinanden
Man kan have et kort RPO (hyppige kopier) og et langt RTO (langsom gendannelse af en stor datamængde). Man kan have et kort RTO (nødmiljøet kører allerede) og et middelmådigt RPO, hvis nødmiljøet er to timer bagud. Begge tal skal skrives ned.
Data før hændelsen
Genstart af tjenesterne
| RPO | RTO | |
|---|---|---|
| Spørgsmål | Hvor meget arbejde kan vi miste? | Hvor længe kan vi stå stille? |
| Måles | Bagud fra hændelsen | Fremad fra hændelsen |
| Styres af | Hyppigheden af kopier | Forberedelsen af nødmiljøet |
| Kontrolleres via | Datoen for den seneste vellykkede kopi | En test med tidtagning |
Ét RTO pr. tjeneste
Telefonomstillingen og dokumenthåndteringssystemet til arkiverne har ikke det samme RTO. At skrive »RTO 4 timer« for hele virksomheden tvinger en enten til at betale for meget for arkivsystemet eller til at lyve om omstillingen. Én linje pr. tjeneste er nok.
Hvordan ved man, om RTO overholdes
Kun med et stopur under en test. Hvis testen varede seks timer, og det skriftlige RTO er to timer, er det det skriftlige RTO, der er forkert, indtil arkitekturen ændres. Man »sigter« ikke mod et RTO, som den seneste måling har modbevist. ANSSI lægger vægt på dette: En gendannelsesprocedure skal udarbejdes og jævnligt gennemføres. Testhyppigheden behandles i Hvor ofte skal man teste sin DRP?.
Hos WeDoBack
Der offentliggøres ikke ét samlet RTO-tal på sitet, og det ville være vildledende at opfinde et: Det afhænger af datamængden, forbindelsen, instansens størrelse og tilgængeligheden af personerne hos kunden. Det, arkitekturen ændrer, er tidsrummets karakter. Ved en simpel gendannelse skal data hentes tilbage og eventuelt geninstalleres. Med DRP genstartes serverne på nødinstanser ud fra den valgte version: Den tekniske tid er denne genstart, ikke tiden til at købe en ny server. En opstartstest finder sted hver måned uden at røre ved produktionen. Med BCP kører cloudinstanser konstant og formidles af en agent på kundens netværk uden ændring af IP-adresse: Det resterende RTO er primært tiden til registrering og beslutning. Replikering eller synkronisering af data mellem BCP-instansen og den oprindelige server er ikke indbygget: Den sker via en specifik proces, tilpasset behovet, som WeDoBack kan etablere efter tilbud. I alle tre tilfælde tæller forretningskontrollen med på stopuret. Den personlige support kan kontaktes kl. 9-13 og 14-17.30 (Paris-tid).
Ofte stillede spørgsmål
Hvad er forskellen på RTO og MTD?
MTD (Maximum Tolerable Downtime) er den samlede nedetid, som ledelsen accepterer for en aktivitet, alle konsekvenser medregnet. RTO er tiden til at genetablere en it-ressource. NIST præciserer, at RTO normalt skal være kortere end MTD for at give plads til de øvrige trin i genetableringen.
Et stykke software lover et RTO på få minutter. Er det realistisk?
Tallet dækker som regel kun den tekniske opstartstid i et laboratorium. Det omfatter hverken registrering af hændelsen, tiden til at få fat i den bemyndigede person eller en brugers kontrol. Jeres reelle RTO er det, I målte ved jeres seneste test, fra hændelsen blev anmeldt, til den første forretningsopgave lykkedes.
Er RTO et lovkrav?
Ingen lovtekst pålægger en SMV en bestemt tidsgrænse. GDPR (artikel 32) kræver dog midler til at genoprette tilgængeligheden af og adgangen til personoplysninger »rettidigt« i tilfælde af en hændelse. RTO er den konkrete måde at definere denne rettidighed på.
Kilder
Dokumenter gennemgået i oktober 2026.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Sauvegarde des systèmes d’information – Les fondamentaux (Backup af informationssystemer – det grundlæggende, ANSSI-BP-100, v1.1, 27. november 2025) — ANSSI (fransk agentur)
- Forordning (EU) 2016/679 (GDPR), artikel 32 — EUR-Lex
- Tilbuddet DRP: genoptagelse af driften efter en katastrofe — WeDoBack
Et projekt inden for backup, DRP eller BCP?
Mere end 20 års erfaring med beskyttelse af virksomheders data.
Anmod om et tilbud+33 9 72 50 78 28Beskyt dine data med WeDoBack
Krypteret offsite-backup, uforanderlig lagring, DRP og BCP: Fortæl os om dine servere, så foreslår vi den rette kombination.
