DRP och BCP

Vad är RTO?

Q: Vad är skillnaden mellan RTO och MTD?

MTD (Maximum Tolerable Downtime) är den totala avbrottstid som ledningen accepterar för en verksamhet, med alla konsekvenser inräknade. RTO är tiden för att återställa en IT-resurs till drift. NIST påpekar att RTO normalt ska vara kortare än MTD, för att lämna marginal för de övriga stegen i återställningen.

RTO (Recovery Time Objective, mål för återställningstid) är den längsta tid som en tjänst får vara otillgänglig. Den mäts från incidenten, eller från beslutet om omkoppling, till dess att en användare åter kan utföra ett normalt arbetsmoment. Inte till dess att en maskin startar vars applikation ännu inte har kontrollerats.

Uppdaterad oktober 20263 min läsning4 källor

Det viktigaste

RTO är summan av sex tidsperioder: upptäckt, beslut, att hitta behörigheter, teknisk tid, verksamhetskontroll, användarnas återkomst.
NIST skiljer den från den längsta tolerabla avbrottstiden (MTD): RTO ska normalt vara kortare än MTD.
Ett RTO anges per tjänst: telefonväxeln och arkiven har inte samma.
Endast ett tidtaget test visar om det angivna RTO hålls.
Supportens öppettider och avsaknaden av jour är en del av det verkliga RTO.

Officiell definition

NIST, den amerikanska standardiseringsmyndigheten, definierar RTO som den längsta tid en resurs i informationssystemet kan vara otillgänglig innan konsekvenserna blir oacceptabla för de verksamheter den stöder. Den skiljs från den längsta tolerabla avbrottstiden (MTD), som är den totala avbrottstid som ledningen accepterar för en verksamhet. RTO ska säkerställa att MTD inte överskrids: den är därför normalt kortare.

ANSSI, Frankrikes nationella cybersäkerhetsmyndighet, använder begreppet längsta tillåtna avbrottstid (DMIA). Myndigheten kräver att en strategi för säkerhetskopiering tar hänsyn till den för varje verksamhetsvärde, och att en återställningsordning fastställs i förväg, utifrån beroenden (DNS, katalogtjänst …) och applikationernas kritikalitet.

Vad RTO är summan av

Vid en klassisk återställning:

tiden det tar att upptäcka felet;
tiden det tar att fatta beslut och nå den som kan åtgärda det;
tiden det tar att hitta nycklar, lösenord och rutin;
den tekniska tiden för kopiering eller start;
tiden för kontroll av någon från verksamheten;
tiden det tar för arbetsstationer eller fjärrklienter att nå tjänsten igen (DNS, VPN, IP).

Ett RTO ”på två timmar” som en programvara utlovar räknar ofta bara steg 4, under laboratorieförhållanden. Det verkliga RTO är summan av alla sex. På natten och under helgen kan steg 2 ensamt överstiga två timmar om ingen har jour.

För en BCP är steg 4 och 6 förberedda i förväg. Kvar finns upptäckten och risken att ingen vågar godkänna omkopplingen.

RTO och RPO kan inte bytas mot varandra

Man kan ha ett kort RPO (täta kopior) och ett långt RTO (långsam återställning av en stor datamängd). Man kan ha ett kort RTO (reservmiljön redan igång) och ett dåligt RPO om reservmiljön ligger två timmar efter. Båda värdena ska anges.

RPOStörsta acceptabla dataförlust

RTOLängsta acceptabla avbrottstid

mäts bakåt

mäts framåt

Data före incidenten

!Incident

Tjänsterna startas om

	RPO	RTO
Frågan	Hur mycket arbete kan vi förlora?	Hur länge kan vi stå stilla?
Mäts	Bakåt, från incidenten	Framåt, från incidenten
Styrs av	Kopieringsfrekvensen	Förberedelsen av reservmiljön
Kontrolleras genom	Datumet för den senaste lyckade kopian	Ett tidtaget test

Ett RTO per tjänst

Telefonväxeln och dokumenthanteringssystemet för arkiven har inte samma RTO. Att skriva ”RTO 4 timmar” för hela företaget tvingar en antingen att betala för mycket för dokumenthanteringen eller att ljuga om telefonväxeln. En rad per tjänst räcker.

Hur vet man om RTO hålls?

Endast med ett stoppur under ett test. Om testet tog sex timmar och det angivna RTO är två timmar, är det det angivna RTO som är fel, tills arkitekturen ändras. Man ”siktar” inte på ett RTO som den senaste mätningen har motbevisat. ANSSI betonar detta: en återställningsrutin ska skrivas ned och tillämpas regelbundet. Testfrekvensen diskuteras i Hur ofta ska man testa sin DRP?.

Hos WeDoBack

Inget enskilt RTO-värde publiceras på webbplatsen, och det vore missvisande att hitta på ett: det beror på datavolymen, förbindelsen, instansstorleken och tillgängligheten hos kundens personal. Det som arkitekturen ändrar är tidens karaktär. Vid enkel återställning måste data hämtas tillbaka och eventuellt installeras om. Med DRP startas servrarna om på reservinstanser utifrån den valda versionen: den tekniska tiden är tiden för denna omstart, inte tiden för att köpa en server. Ett starttest görs varje månad, utan att röra produktionen. Med BCP är molninstanser ständigt igång och nås via en agent i kundens nätverk, utan byte av IP-adress: det återstående RTO är främst tiden för upptäckt och beslut. Replikering eller synkronisering av data mellan BCP-instansen och den ursprungliga servern är inte inbyggd: den sker genom en särskild process, anpassad efter behovet, som WeDoBack kan sätta upp mot offert. I alla tre fallen ingår verksamhetskontrollen i tidtagningen. Personlig support nås kl. 9.00–13.00 och 14.00–17.30 (Paris-tid).

Upptäck DRP Upptäck BCP

Vanliga frågor

Vad är skillnaden mellan RTO och MTD?

MTD (Maximum Tolerable Downtime) är den totala avbrottstid som ledningen accepterar för en verksamhet, med alla konsekvenser inräknade. RTO är tiden för att återställa en IT-resurs till drift. NIST påpekar att RTO normalt ska vara kortare än MTD, för att lämna marginal för de övriga stegen i återställningen.

En programvara utlovar ett RTO på några minuter. Är det realistiskt?

Den siffran räknar i regel bara den tekniska starttiden, i laboratoriemiljö. Den inkluderar varken upptäckten, tiden för att nå den behöriga personen eller kontrollen av en användare. Ert verkliga RTO är det ni mätte vid ert senaste test, från incidentanmälan till det första lyckade verksamhetsmomentet.

Är RTO ett lagkrav?

Ingen text föreskriver en angiven tid för ett litet eller medelstort företag. Däremot kräver dataskyddsförordningen (GDPR, artikel 32) förmåga att återställa tillgängligheten och tillgången till personuppgifter ”i rimlig tid” vid en incident. RTO är det konkreta sättet att definiera denna rimliga tid.

Läs vidare

Källor

Dokumenten konsulterades i oktober 2026.

SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
Säkerhetskopiering av informationssystem – grunderna (ANSSI-BP-100, v1.1, 27 november 2025, på franska) — ANSSI (fransk myndighet)
Förordning (EU) 2016/679 (dataskyddsförordningen, GDPR), artikel 32 — EUR-Lex
Erbjudandet DRP: återställning efter katastrof — WeDoBack

Ett projekt inom säkerhetskopiering, DRP eller BCP?

Över 20 års erfarenhet av att skydda företags data.

Begär en offert +33 9 72 50 78 28

Skydda era data med WeDoBack

Krypterad extern säkerhetskopiering, oföränderlig lagring, DRP och BCP: beskriv era servrar för oss så föreslår vi rätt kombination.

Begär en offert Se erbjudanden och priser