DRP in BCP

Kaj je RTO?

Q: Kakšna je razlika med RTO in MTD?

MTD (Maximum Tolerable Downtime) je skupni čas izpada, ki ga vodstvo sprejme za neko dejavnost, ob upoštevanju vseh posledic. RTO je rok za ponovno vzpostavitev delovanja informacijskega vira. NIST pojasnjuje, da mora biti RTO praviloma krajši od MTD, da ostane rezerva za druge korake obnove.

RTO (Recovery Time Objective, ciljni čas obnove) je najdaljši čas, v katerem je storitev lahko nedosegljiva. Meri se od incidenta ali od odločitve za preklop do trenutka, ko uporabnik znova opravi običajno poslovno opravilo. Ne do vklopa stroja, katerega aplikacija še ni preverjena.

Posodobljeno oktobra 20263 min branja4 navedeni viri

Na kratko

RTO je vsota šestih časov: odkritje, odločitev, iskanje dostopov, tehnični čas, poslovno preverjanje, vrnitev uporabnikov.
NIST ga ločuje od najdaljšega dopustnega časa prekinitve (MTD): RTO mora biti praviloma krajši od MTD.
RTO se zapiše za vsako storitev: telefonska centrala in arhiv nimata enakega.
Le preizkus z merjenjem časa pokaže, ali zapisani RTO drži.
Delovni čas podpore in odsotnost dežurstva sta del dejanskega RTO.

Uradna opredelitev

NIST, ameriški nacionalni inštitut za standarde in tehnologijo, RTO opredeli kot najdaljši čas, v katerem je vir informacijskega sistema lahko nedosegljiv, preden vpliv na dejavnosti, ki jih podpira, postane nesprejemljiv. Ločuje ga od najdaljšega dopustnega časa prekinitve (MTD), ki je skupni čas izpada, ki ga vodstvo sprejme za neko dejavnost. RTO mora zagotoviti, da MTD ni presežen: zato je praviloma krajši.

ANSSI, francoska nacionalna agencija za kibernetsko varnost, uporablja izraz najdaljše dopustno trajanje prekinitve (DMIA). Zahteva, da ga strategija varnostnega kopiranja upošteva za vsako poslovno vrednost in da se vrstni red obnove določi vnaprej, glede na odvisnosti (DNS, imenik …) in kritičnost aplikacij.

Česa vsota je RTO

Pri klasični obnovi:

čas, da opazite okvaro;
čas za odločitev in za to, da dosežete osebo, ki ve, kaj storiti;
čas za iskanje ključev, gesel in postopka;
tehnični čas kopiranja ali zagona;
čas, ki ga za preverjanje potrebuje nekdo iz poslovnega oddelka;
čas, da delovne postaje ali oddaljeni odjemalci znova dostopajo do storitve (DNS, VPN, IP).

RTO „dveh ur“, ki ga napoveduje programska oprema, pogosto upošteva le 4. korak, v laboratorijskih pogojih. Dejanski RTO je vsota vseh šestih. Ponoči in ob koncu tedna lahko že 2. korak traja več kot dve uri, če nihče ni v pripravljenosti.

Pri BCP sta 4. in 6. korak pripravljena vnaprej. Ostaneta odkritje in tveganje preklopa, ki ga nihče ne upa potrditi.

RTO in RPO nista predmet medsebojnega pogajanja

Lahko imate kratek RPO (pogoste kopije) in dolg RTO (počasna obnova velike količine podatkov). Lahko imate kratek RTO (rezervno okolje že deluje) in slab RPO, če rezervno okolje zaostaja za dve uri. Zapišite obe številki.

RPONajvečja sprejemljiva izguba podatkov

RTONajdaljši sprejemljiv čas izpada

meri se nazaj

meri se naprej

Podatki pred incidentom

!Incident

Ponovni zagon storitev

	RPO	RTO
Vprašanje	Koliko dela lahko izgubimo?	Koliko časa lahko stojimo?
Meri se	Nazaj, od incidenta	Naprej, od incidenta
Uravnava se s	Pogostostjo kopij	Pripravo rezervnega okolja
Preveri se z	Datumom zadnje uspešne kopije	Preizkusom z merjenjem časa

RTO za vsako storitev

Telefonska centrala in sistem za upravljanje arhivskih dokumentov nimata enakega RTO. Če za celotno podjetje zapišete „RTO 4 ure“, boste za sistem dokumentov bodisi preveč plačali bodisi zavajali glede centrale. Zadošča ena vrstica na storitev.

Kako ugotoviti, ali RTO drži

Samo s štoparico med preizkusom. Če je preizkus trajal šest ur, zapisani RTO pa je dve uri, je napačen zapisani RTO, dokler se arhitektura ne spremeni. Ne „cilja“ se na RTO, ki ga je zadnja meritev ovrgla. ANSSI to poudarja: postopek obnove je treba zapisati in redno izvajati. O ritmu preizkusov govori vodnik Kako pogosto preizkušati DRP?.

Pri WeDoBack

Na spletnem mestu ni objavljen en sam številčni RTO in zavajajoče bi bilo izmisliti si ga: odvisen je od količine podatkov, povezave, velikosti instance in razpoložljivosti ljudi na strani stranke. Arhitektura spremeni naravo časa. Pri preprosti obnovi je treba podatke prenesti nazaj in morda ponovno namestiti sistem. Pri ponudbi DRP se strežniki znova zaženejo na rezervnih instancah iz izbrane različice: tehnični čas je čas tega zagona, ne čas nakupa strežnika. Preizkus zagona poteka vsak mesec, brez poseganja v produkcijo. Pri ponudbi BCP so instance v oblaku stalno vklopljene in jih prek agenta v omrežju stranke povežemo brez spremembe naslova IP: preostali RTO je predvsem čas odkritja in odločitve. Replikacija ali sinhronizacija podatkov med instanco BCP in izvornim strežnikom ni vgrajena: poteka prek posebnega postopka, prilagojenega potrebam, ki ga WeDoBack lahko vzpostavi na podlagi ponudbe. V vseh treh primerih poslovno preverjanje ostaja del merjenega časa. Človeška podpora je dosegljiva od 9.00 do 13.00 in od 14.00 do 17.30 (po pariškem času).

Oglejte si DRP Oglejte si BCP

Pogosta vprašanja

Kakšna je razlika med RTO in MTD?

MTD (Maximum Tolerable Downtime) je skupni čas izpada, ki ga vodstvo sprejme za neko dejavnost, ob upoštevanju vseh posledic. RTO je rok za ponovno vzpostavitev delovanja informacijskega vira. NIST pojasnjuje, da mora biti RTO praviloma krajši od MTD, da ostane rezerva za druge korake obnove.

Programska oprema napoveduje RTO nekaj minut. Je to realno?

Ta številka praviloma upošteva le tehnični čas zagona v laboratoriju. Ne vključuje odkritja, časa, da dosežete pooblaščeno osebo, niti preverjanja s strani uporabnika. Vaš dejanski RTO je tisti, ki ste ga izmerili pri zadnjem preizkusu, od prijave incidenta do prvega uspešnega poslovnega opravila.

Ali je RTO zakonska obveznost?

Nobeno besedilo malemu ali srednjemu podjetju ne nalaga točno določenega roka. Splošna uredba o varstvu podatkov (GDPR, člen 32) pa zahteva sredstva, ki ob incidentu omogočajo ponovno vzpostavitev razpoložljivosti osebnih podatkov in dostopa do njih „pravočasno“. RTO je konkreten način, kako ta ustrezni rok opredeliti.

Več o tem

Viri

Dokumenti, pregledani oktobra 2026.

SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
Varnostno kopiranje informacijskih sistemov – osnove (ANSSI-BP-100, v1.1, 27. november 2025) — ANSSI (francoska agencija)
Uredba (EU) 2016/679 (Splošna uredba o varstvu podatkov), člen 32 — EUR-Lex
Ponudba DRP: obnova delovanja po nesreči — WeDoBack

Načrtujete projekt varnostnega kopiranja, DRP ali BCP?

Več kot 20 let izkušenj z zaščito poslovnih podatkov.

Zahtevajte ponudbo +33 9 72 50 78 28

Zaščitite svoje podatke z WeDoBack

Šifrirano varnostno kopiranje zunaj lokacije, nespremenljiva hramba, DRP in BCP: opišite nam svoje strežnike in predlagali vam bomo pravo kombinacijo.

Zahtevajte ponudbo Oglejte si ponudbe in cene