Cand pica serverul, fiecare ora de nefunctionare are un pret care se calculeaza exact: venitul anual impartit la orele lucratoare, plus salariile oamenilor care stau, plus penalitatile din contracte. Pentru o companie cu 2 milioane EUR cifra de afaceri, iese in jur de 1.000 EUR pe ora inainte sa punem la socoteala clientii care nu se mai intorc. Cu cifra asta pe masa, discutia despre backup si disaster recovery inceteaza sa mai fie una tehnica - e o decizie de business cu numere concrete de ambele parti.
Ghidul de fata e metodologia completa: cum masori ce ai de pierdut, cum dimensionezi protectia si cum verifici ca functioneaza. Pentru implementarile pe verticale specifice avem ghiduri separate - backup pentru clinici medicale si backup pentru cabinete contabile - iar aici ramanem la deciziile care se iau inaintea oricarei implementari.
Care e diferenta dintre backup si disaster recovery?
Backupul e copia datelor. Disaster recovery e capacitatea de a functiona din nou - cu tot cu servere, aplicatii, retea si oameni care stiu ce au de facut.
Diferenta pare academica pana la primul incident real. Am vazut companii cu backupuri impecabile care au stat o saptamana: datele existau, dar nu avea cine si pe ce sa le restaureze - serverul nou a venit in 4 zile, licentele s-au recuperat greu, iar singurul om care stia parolele era in concediu. Backupul raspunde la intrebarea "am datele?". Disaster recovery raspunde la "cand functionez din nou?" - si a doua intrebare e cea pe care o pune directorul general.
Cum calculezi RTO si RPO?
Doua numere decid toata arhitectura, si niciunul nu e tehnic.
RTO (Recovery Time Objective): cat timp iti permiti sa stai jos. Se calculeaza din costul orei de nefunctionare - formula din deschidere - pus fata in fata cu costul solutiei care il reduce. Daca ora de downtime te costa 1.000 EUR, un RTO de 24 de ore inseamna o expunere de 24.000 EUR per incident; brusc, o solutie de replicare care il aduce la 2 ore nu mai pare scumpa.
RPO (Recovery Point Objective): cate date iti permiti sa pierzi. Un backup pe noapte inseamna RPO de 24 de ore - tot ce s-a lucrat in ziua incidentului dispare. Pentru un depozit care emite sute de avize pe zi, asta e reintroducere manuala de date timp de zile; pentru un birou de proiectare care salveaza local si sincronizeaza seara, poate fi acceptabil.
Cifrele astea le stabileste managementul, nu IT-ul. IT-ul le traduce in arhitectura si in buget - metodologia e aceeasi pe care o formalizeaza si ghidul NIST de planificare a continuitatii, doar ca acolo pe 150 de pagini.
Ce inseamna regula 3-2-1-1-0 in practica?
Varianta scurta: 3 copii ale datelor, pe 2 tipuri de medii diferite, 1 copie in alta locatie, 1 copie imutabila sau offline, 0 erori la verificarea restaurarii.
Primele trei cifre sunt regula clasica 3-2-1 si acopera dezastrele fizice: incendiu, inundatie, furt, defectarea simultana a discurilor. Serverul de productie plus NAS-ul din aceeasi camera nu inseamna doua copii in sensul regulii - un singur incendiu le ia pe amandoua.
Cifra a patra a aparut din cauza ransomware-ului si merita explicata separat, pentru ca schimba totul.
De ce conteaza backupul imutabil impotriva ransomware-ului?
Atacurile moderne nu mai cripteaza doar productia. Prima miscare a atacatorului, dupa ce obtine acces de administrator, e sa caute backupurile si sa le stearga sau sa le cripteze - abia apoi lanseaza atacul vizibil. Un backup pe care administratorul il poate sterge e un backup pe care il poate sterge si atacatorul cu credentialele administratorului.
Imutabilitatea rupe exact lantul asta: copia scrisa nu mai poate fi modificata sau stearsa de nimeni pana la expirarea perioadei setate - nici de root, nici de vendor, nici de tine insuti intr-o zi proasta. Practic se obtine prin Object Lock pe storage S3-compatibil (Backblaze B2, Wasabi) sau prin repository imutabil pe Linux in Veeam, iar perioada tipica e de 30 de zile. Detaliile de implementare, cu retentia si costurile pe un caz real, sunt in ghidul de backup imutabil pentru clinici - principiul e identic in orice industrie.
La retentie si criptare, doua reguli scurte: retentia operationala de 30-90 de zile se dimensioneaza separat de cea legala (documentele financiar-contabile au termene proprii, tratate in ghidul pentru cabinete contabile), iar criptarea backupului e obligatorie din momentul in care copia paraseste sediul - un backup necriptat pierdut in cloud e incident GDPR, nu doar ghinion.
Cum arata un plan de disaster recovery care functioneaza?
Un plan DR care functioneaza incape pe cateva pagini si raspunde la patru intrebari: cine decide activarea, cine face fiecare pas, in ce ordine se restaureaza sistemele, si cum comunicati cat timp emailul e jos.
Ordinea de restaurare e partea pe care o rateaza aproape toate planurile scrise "ca sa fie". Nu totul revine deodata: intai domeniul si autentificarea, apoi sistemul care face banii - ERP, baza de date de productie - apoi restul, pe prioritati stabilite dinainte, nu negociate in mijlocul crizei. Iar lista de contacte (IT, furnizori, asigurator, clienti mari) sta tiparita, nu doar pe serverul care tocmai a picat. Suna banal; e diferenta dintre 4 ore si 4 zile.
Planul complet, cu roluri, scenarii si sabloane de comunicare, l-am detaliat in ghidul de plan disaster recovery si business continuity - aici raman esenta si locul lui in decizie.
Cum testezi backupul fara sa te minti singur?
Un backup netestat e o speranta, nu o strategie. Si nu, mesajul "backup completed successfully" nu e test - e doar confirmarea ca un job a rulat.
Testul real e restaurarea: iei backupul de ieri si ridici din el un server functional, intr-un mediu izolat, pana la login si deschiderea aplicatiei. Cine ruleaza Veeam are SureBackup, care face asta automat si programat; cine nu, o face manual - o data pe luna pentru sistemele critice, o data pe trimestru pentru rest, cu rezultatul notat undeva: data, durata, ce n-a mers. Durata restaurarii masurata la test e singura cifra reala pe care o poti pune langa RTO-ul promis managementului.
Din practica: la primul test de restaurare facut la un client nou, ceva nu merge in peste jumatate din cazuri. Parola de criptare stiuta de un fost angajat, un disc exclus "temporar" acum doi ani, o baza de date care se restaureaza dar nu porneste. Toate reparabile intr-o dupa-amiaza linistita; niciuna reparabila in noaptea incidentului.
Cat costa si cum alegi nivelul potrivit?
Trei niveluri acopera realist piata, iar alegerea intre ele o fac RTO-ul si RPO-ul calculate mai sus, nu bugetul disponibil in luna aia:
| Nivel | Pentru cine | Ce contine | Cost orientativ |
|---|---|---|---|
| De baza | 5-15 statii, fara server critic | backup automat pe NAS + copie cloud imutabila | 100-250 EUR/luna |
| Standard | server propriu, ERP, date de productie | Veeam, NAS dedicat, cloud imutabil, test lunar | 250-600 EUR/luna |
| Avansat | RTO sub 4 ore, mai multe sedii | replicare intre locatii, restore automatizat, DR documentat si exersat | 600-1.500 EUR/luna |
Cifrele includ licentele, storage-ul si munca de administrare - nu doar "cutia". Configuratia exacta pe fiecare nivel, cu echipamentele si scenariile de restore, e treaba paginii de serviciu backup Veeam si disaster recovery; aici conteaza sa alegi nivelul pe cifre, nu pe intuitie.
Checklist de backup si disaster recovery
- Costul orei de nefunctionare: calculat si asumat de management
- RTO si RPO: stabilite per sistem, nu global
- Regula 3-2-1-1-0: bifata integral, cu copia imutabila verificata
- Retentie: operationala 30-90 zile + termenele legale pe documente
- Criptare: activa pe orice copie care paraseste sediul
- Plan DR scris: decident, roluri, ordine de restaurare, contacte tiparite
- Test de restaurare: lunar pe critice, cu durata masurata si notata
- Backup pentru SaaS (Microsoft 365, Google Workspace): existent si separat de cont
- Revizuire anuala: planul se actualizeaza cand se schimba sistemele
Greseli frecvente
Sincronizarea confundata cu backupul - OneDrive si Google Drive replica instant si stersaturile, si criptarile; sunt colaborare, nu protectie. Toate copiile in aceeasi cladire. Parola de criptare stiuta de un singur om. Backupul serverului nou "de saptamana viitoare", care ramane asa un an. Si preferata mea: rapoartele de backup redirectionate intr-un folder de email pe care nu-l deschide nimeni - verde sau rosu, acolo mor toate la fel.
Intrebari frecvente despre backup si disaster recovery
Cat de des trebuie facut backupul?
Atat de des cat iti spune RPO-ul. Pentru majoritatea companiilor: zilnic pe tot, plus la 1-4 ore pe bazele de date critice. Daca pierderea unei zile de lucru te doare, backupul pe noapte nu ajunge.
OneDrive sau Google Drive tin loc de backup?
Nu. Sincronizarea propaga instant si greselile: fisierul sters sau criptat de ransomware dispare sau se cripteaza si in cloud. Versionarea ajuta punctual, dar are limite de timp si nu acopera scenariul in care contul insusi e compromis. Datele din Microsoft 365 au nevoie de backup separat, in afara tenant-ului.
Ce perioada de retentie aleg?
Operational, 30-90 de zile acopera scenariul "am descoperit tarziu ca fisierul era corupt". Peste asta vin termenele legale pe tipuri de documente - cele financiar-contabile au termene de ani intregi, stabilite prin lege, nu prin politica interna.
Snapshot-ul de pe server sau NAS e backup?
Nu de unul singur. Snapshot-ul traieste pe acelasi storage cu datele - daca storage-ul moare sau e criptat, mor impreuna. E excelent ca prim strat de restaurare rapida si exact atat.
Cine raspunde de backup intr-o companie?
Legal si practic, managementul - directiva NIS2 o spune explicit pentru companiile care intra sub ea, cu raspundere personala a conducerii. IT-ul, intern sau externalizat, executa si raporteaza; decizia despre cat risc isi asuma compania nu se deleaga.
In loc de concluzie
Din toate cifrele din acest ghid, una singura merita tinuta minte daca uiti restul: costul orei tale de nefunctionare. Calculeaz-o azi, in 5 minute, cu datele companiei tale. Restul deciziilor - arhitectura, bugetul, nivelul de serviciu - decurg din ea aproape singure.
