Majoritatea diagramelor de arhitectură presupun că clădirea încă stă în picioare. Disaster recovery este disciplina de a întreba ce se întâmplă când nu mai stă. Regiunea principală cade timp de șase ore. Baza de date din producție este coruptă de o migrare proastă care a trecut curat prin review. Un payload de ransomware criptează fiecare fișier la care contul de service din producție poate scrie. Un furnizor de care depinzi pentru identitate are o pană globală și control plane-ul tău e inaccesibil.
Aceste evenimente sunt rare. Nu sunt zero. O platformă suficient de veche încât să conteze va trăi cel puțin unul dintre ele, iar întrebarea în acea zi este dacă echipa a exersat răspunsul sau îl improvizează. Improvizarea unei recuperări la 4 dimineața cu CEO-ul pe un apel de criză este cel mai rău moment posibil pentru a descoperi că backup-urile au eșuat în tăcere de unsprezece luni.
Disaster recovery este o preocupare separată de munca zilnică de fiabilitate care umple Modulul 8. SLO-urile și rotațiile on-call gestionează eșecurile care se întâmplă săptămânal: un pod care crapă, un vecin zgomotos, un deploy care trebuie dat înapoi. DR gestionează eșecurile care se întâmplă rar și contează enorm. Forma problemei e diferită, uneltele sunt diferite și disciplina e diferită.
Două butoane: RTO și RPO
Orice conversație DR începe cu două numere, iar argumentele care le sar produc planuri care nu mulțumesc pe nimeni.
Recovery Time Objective, RTO, este cât timp este dispusă afacerea să fie fără serviciu după un dezastru. RTO de o oră înseamnă că serviciul trebuie să revină într-o oră de la declararea dezastrului. RTO de o zi înseamnă că o zi întreagă de downtime este tolerabilă, dureroasă dar suportabilă. RTO este o decizie de business îmbrăcată în limbaj de inginerie: îi întreabă pe directori cât îi costă downtime-ul și produce un buget pe care arhitectura trebuie să-l respecte.
Recovery Point Objective, RPO, este câtă pierdere de date este acceptabilă. RPO de zero înseamnă că nicio tranzacție nu poate fi pierdută. RPO de o oră înseamnă că poți pierde până la o oră de date și afacerea va funcționa în continuare. RPO de o zi înseamnă că poți pierde o zi, ceea ce sună extrem până când îți amintești că un sistem corporativ de finanțe probabil chiar poate.
Cele două butoane sunt independente. Un serviciu poate avea RTO rapid și RPO lejer: site-ul revine în cinci minute dar a pierdut ultima oră de comenzi, pe care echipa le va reconstrui din log-uri. Un serviciu poate avea RTO lent și RPO strict: depozitul poate fi jos jumătate de zi în timpul recuperării dar niciun rând nu are voie să dispară. Combinația depinde de ce face sistemul. Plățile și registrele contabile au RPO strict; platformele de analytics au adesea RPO lejer și RTO moderat; uneltele interne au de obicei toleranțe generoase la ambele.
Versiunea onestă a unei conversații RTO și RPO este incomodă, pentru că întrebarea „cât costă o oră de downtime?” rareori are un răspuns curat. Echipa alege un număr care pare apărabil, directorii ripostează și apare un compromis. Acel număr conduce apoi fiecare decizie arhitecturală ulterioară din această lecție. Fără el, echipa construiește orice pare prudent, ceea ce este de obicei prea mult pentru serviciile mici și nu suficient pentru cele critice.
Cele patru niveluri DR
Industria are o taxonomie aproximativă a strategiilor DR, fiecare aterizând într-un punct diferit pe compromisul cost vs. RTO/RPO. Numirea lor „niveluri” face scara explicită: fiecare treaptă în sus este mai scumpă decât cea de dedesubt, iar întrebarea este ce treaptă se potrivește toleranței afacerii.
Nivelul 1: backup și restore. Cea mai ieftină opțiune. Backup-uri periodice merg în stocare durabilă; când lovește dezastrul, echipa reconstruiește sistemul de la zero într-o regiune sau cont nou, restaurează datele și redirecționează traficul către el. RTO este de ore până la zile, în funcție de cât e de reconstruit. RPO este intervalul de backup, de obicei ore. Acesta este nivelul potrivit pentru sisteme unde downtime-ul prelungit e enervant dar nu existențial: dashboarduri interne, raportare batch, wiki-ul.
Nivelul 2: pilot light. O versiune minimală a stivei de producție rulează continuu într-o regiune de recuperare: baza de date se replică, dar serverele de aplicație sunt scalate la zero sau aproape de zero. La dezastru, echipa scalează aplicația, redirecționează traficul către ea și rulează. RTO scade la ore. RPO scade la minute, pentru că baza de date a primit actualizări tot timpul. Costul este infrastructura permanentă de replicare plus o amprentă mică de resurse mereu pornite.
Nivelul 3: warm standby. O copie redusă a stivei complete rulează în regiunea de recuperare, gestionând ceva trafic real sau doar stând inactivă. La failover, standby-ul se scalează la capacitate completă și absoarbe tot traficul. RTO este de minute; RPO este de secunde. Costul este semnificativ: aproximativ jumătate dintr-un mediu de producție rulând continuu, plus povara operațională constantă de a ține cele două părți sincronizate (config, secrete, pipeline-uri de deploy, migrări de schemă).
Nivelul 4: active-active. Ambele regiuni sunt vii și deservesc trafic. Failover-ul este doar o decizie de direcționare a traficului: tai DNS sau ponderile de load-balancer către partea supraviețuitoare. RTO este de secunde; RPO este zero, modulo modelul de consistență ales de echipă pentru scrieri cross-region. Acesta este cel mai scump nivel și totodată cel mai exigent: fiecare serviciu trebuie proiectat să ruleze multi-master, fiecare set de date trebuie replicat cu rezolvare de conflicte, fiecare deploy trebuie să fie scos în ambele regiuni la pas. Active-active este ce rulează băncile și rețelele de publicitate pentru că costul downtime-ului se măsoară în milioane pe minut. Pentru majoritatea companiilor, e exagerat.
flowchart LR
BR[Backup and restore<br/>RTO hours-days<br/>RPO hours]
PL[Pilot light<br/>RTO hours<br/>RPO minutes]
WS[Warm standby<br/>RTO minutes<br/>RPO seconds]
AA[Active-active<br/>RTO seconds<br/>RPO zero]
BR --> PL --> WS --> AA
BR -.cheapest.-> AA
AA -.most expensive.-> BRPlanul DR al majorității companiilor este „avem backup-uri”, care e nivelul 1, iar majoritatea acelor companii nu au testat niciodată restore-ul. Secțiunea următoare e despre de ce asta e problema centrală.
Exercițiul
Planurile DR netestate nu funcționează. Această propoziție este inima lecției și majoritatea echipelor i se opun, pentru că testarea DR este scumpă, perturbantă și rareori produce un livrabil pe care roadmap-ul trimestrului următor să-l recompenseze.
Tiparul este de încredere. O echipă scrie un runbook DR acum trei ani. Runbook-ul spune „în caz de dezastru, restaurează din backup-ul S3 prod-db-snapshot, repornește worker-ele, redirecționează DNS-ul către regiunea de recuperare.” Trece timpul. Bucket-ul S3 e redenumit. Furnizorul DNS e migrat. Pool-ul de worker-i e rescris. Runbook-ul tot referențiază numele vechi. Nimeni din echipa on-call nu l-a citit vreodată. Echipa care l-a scris a plecat acum doi ani. În ziua dezastrului, runbook-ul e ficțiune.
Disciplina care repară asta este exercițiul. O cadență rezonabilă este trimestrială: în fiecare trimestru, echipa alege un scenariu (eșec de regiune, corupție de bază de date, ransomware) și parcurge runbook-ul cap-coadă. Uneori exercițiul este unul de masă, unde echipa parcurge pașii verbal și confirmă că există. Alteori este o simulare completă: echipa face efectiv failover către regiunea de recuperare, restaurează efectiv dintr-un backup real într-un mediu real, cronometrează efectiv cât a durat. Exercițiile de masă găsesc cele mai grave goluri ieftin; simulările complete găsesc golurile care apar doar sub încărcare.
Fiecare exercițiu produce o listă cu lucruri care nu au funcționat. Numele bucket-ului S3 era greșit. Rolul IAM necesar pentru a rula restore-ul fusese șters. Runbook-ul spunea „cheamă echipa de bază de date” iar echipa de bază de date e o altă echipă de opt luni. Lista intră în backlog și exercițiul următor verifică reparațiile. În timp, runbook-ul începe să fie un document viu în loc de un artefact.
Cadrul care ajută exercițiul să se întâmple este simplu: un plan DR care nu a fost exersat este aproximativ la fel de bun ca lipsa unui plan. CFO-ul ar prefera să afle asta într-un trimestru liniștit decât în timpul unui dezastru real.
Recuperează sistemul, recuperează datele
O distincție utilă. Backup-urile protejează datele. Runbook-urile protejează timpul.
O postură DR completă are nevoie de ambele. Backup-urile singure lasă echipa cu un tarball și fără cale de a-l folosi: nimic nu rulează, fără DNS, fără conturi de service cu permisiunile potrivite, fără o versiune a codului aplicației care să se potrivească cu schema backup-ului. Runbook-urile singure, fără backup-uri reale în spate, lasă echipa cu un playbook frumos care se termină la „și apoi datele sunt cumva înapoi”.
Echipele care fac DR bine tratează cele două artefacte ca pe o pereche corespondentă. Fiecare backup are un runbook corespunzător care descrie cum să-l restaureze într-un sistem funcțional. Fiecare runbook a fost testat împotriva unui backup real. Perechea este ce se exersează.
Asta se conectează cu discuția despre backup-uri din lecția 31: un backup care nu a fost niciodată restaurat nu este cu adevărat un backup, este o aspirație. Exercițiul este partea care convertește aspirația în capabilitate.
Eșecurile DR comune
Un scurt catalog de eșecuri care apar în recuperări reale, toate reale, toate prevenibile.
Backup-ul care nu se restaurează. Echipa rulează backup-uri zilnice de ani de zile. În ziua dezastrului, restore-ul eșuează: formatul de backup s-a schimbat la un upgrade de bază de date, cheia de criptare a fost rotită, politica bucket-ului refuză rolul de recuperare. Echipa află în cea mai rea zi posibilă. Prevenire: teste regulate de restore, ideal automate, care confirmă că backup-urile pot fi efectiv încărcate într-o bază de date funcțională.
Runbook-ul care referențiază servicii care nu mai există. Menționat mai sus. Reparația este exercițiul. Un runbook care nu a fost citit în optsprezece luni este ficțiune necitită.
Credențiale pe care nimeni din echipa on-call nu le are. Recuperarea cere logarea într-o consolă de furnizor cu o credențială care trăiește în managerul de parole al unei singure persoane, iar acea persoană e în vacanță într-o țară cu acoperire mobilă proastă. Prevenire: fiecare credențială necesară pentru recuperare e într-un secret store partajat cu proceduri break-glass, iar procedurile sunt parte din exercițiu.
DNS care indică spre servere moarte. Runbook-ul spune „fă failover prin actualizarea CNAME-ului”. CNAME-ul a fost actualizat. Nu se întâmplă nimic, pentru că TTL-ul e 24 de ore și clienții încă rezolvă adresa veche. Prevenire: TTL-uri mici pe înregistrările DNS care participă la failover, plus un test real al schimbării CNAME-ului în timpul exercițiului.
Regiunea de recuperare care nu are capacitate. Echipa are un warm standby în altă regiune. La failover, standby-ul nu poate scala în sus, pentru că furnizorul cloud a rămas fără capacitate pe acel tip de instanță în acea regiune. Prevenire: rezervări de capacitate, sau o strategie pilot light care nu depinde de scalare instantanee în cel mai prost moment posibil.
Tiparul în toate acestea e același: eșecul e rareori în proiectarea planului DR și aproape întotdeauna în golul dintre plan și realitate. Exercițiul închide golul.
Cum se conectează DR cu multi-region
Lecția 75 a acoperit multi-region ca topologie de deployment. Multi-region este o cale specifică de a construi o postură DR: nivelul 3 sau nivelul 4, în funcție de cât din stivă e replicat și cât de activ e standby-ul. Un deployment multi-region active-active este, prin construcție, un plan DR de nivel 4. Un deployment multi-region active-passive este un warm standby.
Punctul de reținut: multi-region este o unealtă din kit-ul DR, nu întregul kit. O echipă care rulează într-o singură regiune poate avea totuși un plan DR serios, construit pe backup-uri și recuperare pilot light într-o regiune diferită sau chiar într-un cloud diferit. O echipă care rulează active-active poate fi totuși vulnerabilă la dezastre care se propagă peste regiuni: un deploy prost care crapă ambele părți, un bug software care corupe setul de date replicat, un payload de ransomware care urmează calea de replicare. Active-active nu protejează împotriva acestora; doar backup-urile separate de credențialele de producție o fac. Redundanța geografică și backup-urile separate în timp sunt controale complementare, nu substitute.
Cum arată ce e bine
O echipă cu o postură DR sănătoasă are, ca minim, următoarele. Numere RTO și RPO pe care afacerea le-a aprobat. Un nivel DR potrivit cu acele numere. Backup-uri criptate, durabile și testate prin restore automatizat cel puțin lunar. Un runbook exersat în ultimul trimestru. O listă de credențiale și proceduri break-glass pe care echipa on-call le-a folosit efectiv în ultimul exercițiu. Un scenariu de eșec documentat, parcurs, cu golurile din ultimul exercițiu în backlog și golurile din exercițiul anterior închise.
Nimic din asta nu este glamuros. Nimic din asta nu livrează feature-uri. Tot ce e mai sus este diferența dintre o recuperare serioasă și una haotică în ziua când vine.
Lecția următoare e despre arhitectura de securitate care previne majoritatea dezastrelor de la care DR există să recupereze: IAM, segmentare de rețea, managementul secretelor și logging-ul de audit care țin suprafața de amenințare suficient de mică încât DR să fie rareori răspunsul de ultimă instanță.
Citări și lecturi suplimentare
- AWS, “Disaster Recovery of Workloads on AWS: Recovery in the Cloud”,
https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html(consultat 2026-05-01). Documentul canonic al modelului cu patru niveluri folosit în această lecție, cu numere concrete RTO/RPO per nivel. - Google Cloud, “Disaster recovery planning guide”,
https://cloud.google.com/architecture/dr-scenarios-planning-guide(consultat 2026-05-01). Aceeași scară conceptuală, prezentată din perspectiva GCP, cu exemple concrete pentru fiecare nivel. - Microsoft Azure, “Business continuity and disaster recovery”,
https://learn.microsoft.com/en-us/azure/reliability/concept-business-continuity-high-availability-disaster-recovery(consultat 2026-05-01). Cadrul Azure, incluzând definiții utile de business continuity vs. DR. - NIST SP 800-34 Rev. 1, “Contingency Planning Guide for Federal Information Systems”,
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final(consultat 2026-05-01). Referința de nivel guvernamental despre planificarea de contingență, incluzând disciplina testării.