DRP și BCP

Ce este un RTO?

Q: Care este diferența dintre RTO și MTD?

MTD (Maximum Tolerable Downtime) este durata totală de întrerupere pe care conducerea o acceptă pentru o activitate, incluzând toate impacturile. RTO-ul este termenul de repunere în funcțiune a unei resurse IT. NIST precizează că RTO-ul trebuie în mod normal să fie mai scurt decât MTD, pentru a lăsa o marjă celorlalte etape ale recuperării.

RTO-ul (Recovery Time Objective, obiectivul timpului de recuperare) este durata maximă în care un serviciu poate rămâne indisponibil. Se măsoară de la incident, sau de la decizia de comutare, până în momentul în care un utilizator efectuează din nou o operațiune de business normală. Nu până la pornirea unei mașini a cărei aplicație nu a fost încă verificată.

Actualizat în octombrie 20263 min de lectură4 surse citate

Pe scurt

RTO-ul adună șase durate: detectarea, decizia, găsirea acceselor, timpul tehnic, verificarea de business, revenirea utilizatorilor.
NIST îl distinge de durata maximă tolerabilă de întrerupere (MTD): RTO-ul trebuie în mod normal să fie mai scurt decât MTD.
Un RTO se stabilește pe serviciu: centrala telefonică și arhivele nu au același RTO.
Doar un test cronometrat arată dacă RTO-ul scris este respectat.
Programul asistenței și lipsa unei permanențe fac parte din RTO-ul real.

Definiția oficială

NIST, organismul american de standardizare, definește RTO-ul ca durata maximă în care o resursă a sistemului informatic poate rămâne indisponibilă înainte ca impactul să devină inacceptabil pentru activitățile pe care le susține. Îl distinge de durata maximă tolerabilă de întrerupere (MTD), care este durata totală de întrerupere pe care conducerea o acceptă pentru o activitate. RTO-ul trebuie să garanteze că MTD nu este depășită: de aceea este în mod normal mai scurt.

ANSSI, agenția națională franceză de securitate cibernetică, folosește termenul de durată maximă admisibilă de întrerupere (DMIA). Ea cere ca strategia de backup să țină cont de aceasta pentru fiecare activ de business și ca o ordine de restaurare să fie definită dinainte, în funcție de dependențe (DNS, director de utilizatori…) și de criticitatea aplicațiilor.

Din ce se compune RTO-ul

Pentru o restaurare clasică:

timpul până la observarea defecțiunii;
timpul pentru a decide și a contacta persoana care știe ce are de făcut;
timpul pentru a găsi cheile, parolele și procedura;
timpul tehnic de copiere sau de pornire;
timpul de verificare de către cineva din activitatea de business;
timpul necesar ca stațiile de lucru sau clienții la distanță să regăsească serviciul (DNS, VPN, IP).

Un RTO „de două ore” anunțat de un software include adesea doar etapa 4, în condiții de laborator. RTO-ul real le adună pe toate șase. Noaptea și în weekend, etapa 2 poate depăși singură două ore dacă nimeni nu este de permanență.

Pentru un BCP, etapele 4 și 6 sunt pregătite dinainte. Rămân detectarea și riscul unei comutări pe care nimeni nu îndrăznește să o valideze.

RTO-ul și RPO-ul nu se negociază unul în detrimentul celuilalt

Puteți avea un RPO scurt (copii frecvente) și un RTO lung (restaurare lentă a unui volum mare). Puteți avea un RTO scurt (mediu de rezervă deja pornit) și un RPO mediocru dacă mediul de rezervă are două ore întârziere. Ambele valori trebuie scrise.

RPOPierderea maximă acceptabilă de date

RTOTimpul maxim acceptabil de întrerupere

se măsoară înapoi

se măsoară înainte

Datele dinaintea incidentului

!Incident

Repornirea serviciilor

	RPO	RTO
Întrebarea pusă	Câtă muncă ne permitem să pierdem?	Cât timp ne permitem să stăm opriți?
Se măsoară	Înapoi, de la incident	Înainte, de la incident
Se reglează prin	Frecvența copiilor	Pregătirea mediului de rezervă
Se verifică prin	Data ultimei copii reușite	Un test cronometrat

Un RTO pentru fiecare serviciu

Centrala telefonică și sistemul de gestiune electronică a arhivelor nu au același RTO. A scrie „RTO 4 ore” pentru întreaga companie vă obligă fie să plătiți prea mult pentru arhive, fie să mințiți în privința centralei. Este suficient un rând pentru fiecare serviciu.

Cum aflați dacă RTO-ul este respectat

Numai cu un cronometru, în timpul unui test. Dacă testul a durat șase ore, iar RTO-ul scris este de două ore, RTO-ul scris este cel greșit, până când arhitectura se schimbă. Nu „vizați” un RTO pe care ultima măsurătoare l-a infirmat. ANSSI insistă asupra acestui punct: o procedură de restaurare trebuie redactată și pusă în aplicare în mod regulat. Ritmul testelor este discutat în Cât de des trebuie testat DRP-ul?.

La WeDoBack

Pe site nu este publicat un RTO cifrat unic și ar fi înșelător să inventăm unul: el depinde de volum, de conexiune, de dimensiunea instanței și de disponibilitatea persoanelor din partea clientului. Ceea ce schimbă arhitectura este natura termenului. La o restaurare simplă, datele trebuie aduse înapoi și, eventual, sistemul reinstalat. Cu DRP, serverele repornesc pe instanțe de rezervă pornind de la versiunea aleasă: termenul tehnic este cel al acestei reporniri, nu cel al achiziției unui server. Un test de pornire are loc lunar, fără a atinge producția. Cu BCP, instanțe cloud funcționează permanent și sunt conectate printr-un agent în rețeaua clientului, fără schimbarea adresei IP: RTO-ul rezidual este în principal cel al detectării și al deciziei. Replicarea sau sincronizarea datelor între instanța BCP și serverul de origine nu este nativă: ea presupune un proces specific, adaptat nevoii, pe care WeDoBack îl poate implementa pe bază de ofertă. În toate cele trei cazuri, verificarea de business rămâne inclusă în cronometru. Asistența umană este disponibilă între 9:00 și 13:00 și între 14:00 și 17:30 (ora Parisului).

Descoperiți DRP Descoperiți BCP

Întrebări frecvente

Care este diferența dintre RTO și MTD?

MTD (Maximum Tolerable Downtime) este durata totală de întrerupere pe care conducerea o acceptă pentru o activitate, incluzând toate impacturile. RTO-ul este termenul de repunere în funcțiune a unei resurse IT. NIST precizează că RTO-ul trebuie în mod normal să fie mai scurt decât MTD, pentru a lăsa o marjă celorlalte etape ale recuperării.

Un software anunță un RTO de câteva minute. Este realist?

Această cifră include de regulă doar timpul tehnic de pornire, în condiții de laborator. Ea nu include nici detectarea, nici timpul necesar pentru a contacta persoana autorizată, nici verificarea de către un utilizator. RTO-ul dumneavoastră real este cel pe care l-ați măsurat la ultimul test, de la declararea incidentului până la prima operațiune de business reușită.

Este RTO-ul o obligație legală?

Niciun act normativ nu impune o durată cifrată unui IMM. În schimb, RGPD (articolul 32) cere mijloace care să permită restabilirea disponibilității datelor cu caracter personal și a accesului la acestea „în timp util” în cazul unui incident. RTO-ul este modul concret de a defini acest termen adecvat.

Pentru a aprofunda

Surse

Documente consultate în octombrie 2026.

SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
Backupul sistemelor informatice – Elementele fundamentale (ANSSI-BP-100, v1.1, 27 noiembrie 2025, în franceză) — ANSSI (agenție franceză)
Regulamentul (UE) 2016/679 (RGPD), articolul 32 — EUR-Lex
Oferta DRP: recuperarea activității după un dezastru — WeDoBack

Aveți un proiect de backup, DRP sau BCP?

Peste 20 de ani de experiență în protecția datelor companiilor.

Solicitați o ofertă +33 9 72 50 78 28

Protejați-vă datele cu WeDoBack

Backup criptat în afara sediului, stocare imuabilă, DRP și BCP: descrieți-ne serverele dumneavoastră și vă propunem combinația potrivită.

Solicitați o ofertă Vedeți ofertele și tarifele