Disaster recovery: de ce backup-ul netestat nu te salvează

„Avem backup." Sunt două cuvinte care liniștesc orice manager — și care, în ziua unui incident real, se dovedesc adesea cea mai scumpă iluzie din firmă. Pentru că între a avea un backup și a te putea recupera din el este o prăpastie pe care majoritatea companiilor o descoperă exact în momentul cel mai prost: când au nevoie de date și ele nu vin înapoi.

Un backup care nu a fost testat nu este o plasă de siguranță. Este o presupunere. Iar în 2026, această presupunere a devenit periculos de costisitoare, pentru că atacatorii au învățat exact unde să lovească: nu doar datele de producție, ci și copiile de backup care ar trebui să te salveze.

Backup nu înseamnă recuperare

Backup-ul este o copie a datelor. Disaster recovery este capacitatea de a aduce afacerea înapoi la funcționare — la timp, complet, cu procese clare. Sunt două lucruri diferite, iar a avea primul nu îți garantează deloc pe al doilea.

Poți avea copii perfecte ale datelor și, totuși, să fii la pământ două săptămâni: pentru că nimeni nu a măsurat vreodată cât durează o restaurare completă, pentru că backup-ul stă pe același server pe care l-a criptat ransomware-ul, pentru că lipsește o procedură scrisă și sub presiune toată lumea improvizează, sau pentru că ultima verificare „a mers" a fost acum un an și de atunci jobul eșuează tăcut în fiecare noapte. Backup-ul este materia primă. Disaster recovery este rețeta, bucătăria și bucătarul care știe să o pună pe masă în timpul promis.

Ce arată datele din 2025–2026

Cifrele din ultimul an spun o poveste limpede: problema nu mai e că firmele nu au backup, ci că recuperarea efectivă este mult mai grea decât pare.

• Aproape 9 din 10 breșe de securitate la firmele mici implică ransomware, comparativ cu aproximativ 4 din 10 la marile corporații — IMM-urile sunt ținta preferată, nu o excepție.
• În medie, o firmă lovită de ransomware are nevoie de aproximativ 24 de zile pentru a reveni la operare normală. Pentru multe IMM-uri, trei săptămâni de blocaj sunt fatale.
• Doar aproximativ jumătate dintre victime își revin în mai puțin de o săptămână; o parte semnificativă au nevoie de peste o lună, iar foarte puține se recuperează într-o singură zi.
• În marea majoritate a atacurilor ransomware, atacatorii vizează direct copiile de backup — și reușesc să le compromită în peste trei sferturi din cazuri. Backup-ul nu mai este un colț sigur, ci o țintă.
• Firmele care reușesc să restaureze din backup-uri intacte cheltuie, în medie, de câteva ori mai puțin pe recuperare decât cele cu backup-uri compromise — diferența se măsoară în sute de mii de euro.
• Și totuși, o mare parte din planurile de recuperare sunt testate rar sau deloc — multe firme nu au verificat niciodată dacă planul lor chiar funcționează.

Concluzia se citește printre rânduri: firmele care se recuperează rapid și ieftin nu sunt cele cu cel mai scump software de backup, ci cele care și-au testat recuperarea înainte de dezastru. Restul plătesc factura — în zile pierdute, în bani și, în cazul cel mai grav, cu însăși existența afacerii.

RTO și RPO: două decizii de business, nu tehnice

Orice plan serios de disaster recovery pornește de la două numere. Ele nu se decid de către un tehnician, ci de către management — pentru că sunt, în fond, decizii despre cât de mult risc îți permite afacerea.

RPO — cât de multe date îți permiți să pierzi

Recovery Point Objective este intervalul maxim de date pe care accepți să-l pierzi. Dacă faci backup o dată pe zi, la un incident poți pierde până la 24 de ore de muncă. Pentru o evidență contabilă, poate fi acceptabil. Pentru un magazin online sau un sistem cu tranzacții, o oră pierdută poate însemna comenzi și bani dispăruți. RPO-ul îți spune cât de des trebuie să faci copii.

RTO — cât de repede trebuie să revii

Recovery Time Objective este timpul maxim acceptabil până când sistemul redevine funcțional. Un RTO de 8 ore și unul de 15 minute cer arhitecturi complet diferite — și costuri diferite. Secretul nu este să ceri „recuperare instant" peste tot, ci să stabilești corect ce sisteme sunt critice (cele care opresc afacerea) și care pot aștepta. Pe cele critice investești; pe rest, economisești.

Fără aceste două numere, „avem backup" e o frază fără conținut. Cu ele, design-ul devine o decizie rațională: știi exact cât de des copiezi și cât de repede trebuie să restaurezi — și poți verifica dacă chiar reușești.

De ce cad backup-urile exact când ai nevoie de ele

Recuperările eșuează rareori dintr-un singur motiv spectaculos. De cele mai multe ori, cauza e una dintre acestea — banale, dar fatale:

1. 1Backup-ul nu a fost niciodată testat. Jobul „rulează", dar nimeni nu a încercat vreodată o restaurare completă. Prima oară când o faci nu trebuie să fie în mijlocul crizei.
2. 2Backup-ul stă lângă producție. O copie pe același server sau aceeași rețea cu datele de producție este criptată de același ransomware. Fără o copie off-site și imutabilă, nu ai backup — ai două victime.
3. 3Lipsește RPO/RTO. Nimeni nu a decis cât e acceptabil să pierzi, așa că nimeni nu poate spune dacă backup-ul actual e suficient sau dacă recuperarea e „la timp".
4. 4Nu există un runbook. În prima oră a unui incident, sub stres, oamenii improvizează. Fără o procedură scrisă — cine, ce, în ce ordine — se pierd ore prețioase pe decizii care ar fi trebuit luate din timp.
5. 5Retenția nu acoperă scenariul real. Unele atacuri stau ascunse zile sau săptămâni înainte să lovească. Dacă păstrezi doar ultimele câteva zile de copii, riști să restaurezi date deja compromise.
6. 6Monitorizarea lipsește. Un job de backup care eșuează tăcut timp de luni de zile descoperă problema abia la prima restaurare — adică prea târziu.

Cum arată un plan de disaster recovery care chiar funcționează

Un plan operațional, nu unul de raft, are câteva ingrediente clare:

• RPO și RTO definite per sistem, agreate cu management-ul — nu un singur număr pentru tot.
• Strategia 3-2-1-0: trei copii ale datelor, pe două medii diferite, una off-site, cu zero erori la verificare. Cel puțin o copie imutabilă, pe care ransomware-ul nu o poate șterge sau cripta.
• Testare periodică a restaurării — lunar pentru sistemele critice, trimestrial pentru rest — cu măsurarea timpilor reali și comparație cu RTO-ul țintă.
• Runbook-uri scrise: cine declanșează recuperarea, în ce ordine se restaurează sistemele, cum se comunică, când se escaladează.
• Pentru sistemele cu RTO mic, un site secundar în cloud și replicare continuă (Disaster Recovery as a Service) cu exerciții de failover.
• Politici de retenție și arhivare aliniate la cerințele GDPR — păstrezi cât trebuie, ștergi automat ce a expirat, cu audit trail complet.

Un backup pe care nu l-ai restaurat niciodată nu e un backup — e o promisiune pe care nu ai verificat-o. Singura întrebare care contează este: cât durează, de fapt, să revii?

Cum lucrăm noi

În proiectele noastre de protecție a datelor pornim de la un workshop de business impact analysis, în care stabilim împreună cu tine RPO și RTO pentru fiecare sistem. Proiectăm apoi strategia 3-2-1-0 cu o copie imutabilă, configurăm backup-ul, monitorizarea și alertarea, și — cel mai important — testăm restaurarea după un calendar clar, documentând timpii reali până atingem RTO-ul stabilit. Pentru sistemele care nu suportă downtime adăugăm replicare în cloud și runbook-uri de failover testate. Pentru că ransomware-ul este astăzi principala amenințare la adresa datelor, planul de recuperare merge mână în mână cu măsurile de securitate cibernetică. Dacă vrei să afli cât durează, în realitate, o recuperare completă în firma ta, hai să discutăm 30 de minute — îți spun concret unde ești expus.

Concluzie

Datele din 2025-2026 sunt fără echivoc: diferența dintre o firmă care trece printr-un incident și una pe care incidentul o închide nu este software-ul de backup, ci recuperarea testată. Backup-ul este obligatoriu, dar insuficient. Disaster recovery — cu RTO și RPO definite, copii imutabile, runbook-uri și teste periodice — este ceea ce transformă o copie a datelor într-o garanție reală că afacerea ta supraviețuiește. Nu lăsa prima restaurare să fie în mijlocul crizei.