Într-o firmă cu zece sau cincisprezece angajați, planul de backup există de obicei într-o formă informală: cineva copiază din când în când un dosar pe un hard disk extern, iar restul se sprijină pe convingerea că „oricum totul e în cloud”. Distanța dintre situația aceasta și un sistem care chiar funcționează nu se măsoară în bugete mari, ci într-o succesiune de decizii luate în ordinea corectă. Ghidul de mai jos parcurge exact acel traseu: de la prima întrebare pe care trebuie să și-o pună administratorul, până la momentul în care o restaurare testată dovedește că datele pot fi aduse înapoi în timpul promis.
Prima decizie: cât timp și câte date îți poți permite să pierzi
Înainte de orice ofertă de echipament sau de abonament, răspunde la două întrebări. Prima: dacă serverul de facturare cedează marți la ora 11, cât de veche poate fi cea mai recentă copie a datelor fără ca firma să aibă o problemă majoră? Răspunsul este obiectivul de punct de recuperare, RPO, și se exprimă în ore. A doua: în cât timp trebuie ca totul să fie funcțional din nou? Acesta este obiectivul de timp de recuperare, RTO.
Cifrele nu se aleg din intuiție, ci prin comparație cu costul opririi. Într-o firmă de distribuție cu o cifră de afaceri de 1,2 milioane de lei pe an, o zi fără sistemul de facturare și fără evidența stocurilor înseamnă marjă pierdută, salarii plătite pentru muncă imposibil de făcut și comenzi amânate — în total, între 3.000 și 6.000 de lei. Dacă o zi de oprire costă atât, un RTO de trei zile nu mai este o limitare tehnică, ci o decizie financiară asumată.
Pentru majoritatea firmelor mici, un set rezonabil arată așa: RPO de 24 de ore pentru fișierele de birou, RPO de o oră pentru baza de date a ERP-ului sau a programului de facturare și RTO de patru–opt ore pentru sistemele fără de care nu se poate lucra. Notează valorile pe hârtie. Ele determină tot ce urmează, inclusiv bugetul.
Pasul 1: inventarul datelor, într-o ședință de două ore
Al doilea pas este o listă, nu o achiziție. Adună într-un tabel toate locurile în care firma ține date și notează, pentru fiecare, volumul în gigabytes, cine răspunde de el și RPO-ul stabilit anterior. În practică, lista arată aproape mereu la fel:
- baza de date a programului de contabilitate, de facturare sau a ERP-ului, inclusiv atașamentele;
- căsuțele de e-mail și fișierele din Microsoft 365 sau Google Workspace;
- dosarele partajate de pe serverul local sau de pe NAS: contracte, oferte, proiecte;
- site-ul sau magazinul online — fișierele și baza de date, tratate separat;
- aplicația de salarizare și arhivele de personal;
- fișierele XML de e-Factura descărcate din Spațiul Privat Virtual și documentele de e-Transport;
- conturile SaaS folosite de echipă: CRM, help desk, instrumentul de management al proiectelor;
- laptopurile care nu se sincronizează cu nimic, de obicei cele ale conducerii.
Punctul în care se greșește cel mai des este al doilea. Furnizorii de servicii cloud garantează disponibilitatea infrastructurii proprii, nu recuperarea unui fișier șters de un angajat acum patru luni sau a unei căsuțe golite după compromiterea unui cont. Perioadele implicite de reținere pentru elementele șterse se măsoară, în funcție de serviciu și de setări, în 30 până la 93 de zile. Un e-mail dispărut mai demult nu se mai recuperează fără o copie separată. La fel, fișierele de e-Factura rămân disponibile pentru descărcare din SPV o perioadă limitată, în timp ce obligația de arhivare rămâne integral la firmă: cinci ani pentru documentele justificative curente și 50 de ani pentru statele de salarii.
Pasul 2: arhitectura 3-2-1 și bugetul lunar realist
Regula de la care pornește orice configurație serioasă are trei numere: trei copii ale datelor, pe două tipuri diferite de suport, dintre care una păstrată în altă locație. Varianta extinsă adaugă încă două cifre — o copie imutabilă sau deconectată și zero erori la verificare — și este cea care contează în fața atacurilor cu criptare, pentru că o copie pe care atacatorul nu o poate șterge este, de multe ori, singura care rezistă.
Traducerea în echipamente și abonamente, cu prețuri orientative pentru piața din România în 2026:
- NAS cu două sau patru posturi, plus discuri destinate funcționării continue: 3.500–7.000 de lei, investiție unică, la care se adaugă înlocuirea discurilor după patru–cinci ani;
- stocare de tip obiect în cloud, compatibilă S3, cu blocare a obiectelor: circa 25–40 de lei pe TB pe lună, plus eventualele costuri de trafic la restaurare;
- soluție de backup dedicată pentru Microsoft 365 sau Google Workspace: 10–20 de lei pe utilizator pe lună;
- licență de software pentru servere fizice sau virtuale: 400–900 de lei pe server pe an, cu variante gratuite pentru un număr mic de mașini;
- agent pentru stațiile de lucru importante: 6–12 lei pe stație pe lună.
Pentru o firmă cu 12 utilizatori, un server și aproximativ 1,5 TB de date utile, bugetul se așază de regulă între 300 și 550 de lei pe lună, peste o investiție inițială de 4.000–6.000 de lei. Un detaliu practic care surprinde: prima încărcare a 1,5 TB pe o legătură cu 100 Mbps de upload real durează în jur de 33 de ore. Programeaz-o într-un weekend sau cere furnizorului o metodă de inițializare locală a depozitului.
Pasul 3: configurarea, în ordinea în care contează
Începe cu sistemul care are RPO-ul cel mai strict, nu cu cel mai ușor de configurat. În practică, asta înseamnă baza de date a ERP-ului: copie completă noaptea, copii ale jurnalului de tranzacții la fiecare oră, verificare automată a fișierului rezultat imediat după rulare.
Trei setări fac diferența dintre o simplă copie și o protecție reală. Prima: contul folosit de sistemul de backup nu trebuie să fie contul de administrator al rețelei și nu trebuie să aibă drept de ștergere pe destinația din cloud, iar autentificarea în doi pași se activează obligatoriu pentru el. A doua: activează blocarea obiectelor pe depozitul extern, cu o reținere de 14–30 de zile, astfel încât nici cu parola furată datele să nu poată fi șterse înainte de termen. A treia: criptează arhivele și păstrează cheia în afara sistemului pe care îl protejezi — un manager de parole, plus o copie tipărită într-un seif. O arhivă criptată a cărei cheie se afla doar pe serverul criptat de atacatori este, practic, pierdută.
Stabilește apoi retenția pe niveluri: 14 copii zilnice, 8 săptămânale, 12 lunare și una anuală păstrată separat, pentru cerințele de arhivare. Programele de criptare stau în rețea săptămâni întregi înainte de a declanșa atacul, tocmai pentru ca toate copiile recente să conțină deja infecția; retenția lungă este contramăsura directă pentru acest tipar.
Pasul 4: automatizarea rulărilor și alerte care ajung la un om
Un sistem care depinde de cineva care „își aduce aminte” nu este un sistem. Programează rulările în afara orelor de lucru, activează raportul zilnic pe e-mail și configurează o alertă separată pentru două eșecuri consecutive. Alocă un responsabil cu nume și pune-i în calendar 30 de minute pe lună pentru verificare. Aceeași logică de eliberare a timpului prin procese care rulează singure se regăsește și în automatizările simple care economisesc ore într-o firmă mică, cu o diferență importantă: la backup, automatizarea fără alertă vizibilă creează o falsă siguranță, pentru că o sarcină oprită de trei luni arată exact la fel ca una care merge impecabil.
Verifică și ce se întâmplă când destinația se umple sau când un disc din NAS cedează. Configurează notificarea de spațiu la 80% ocupare și scoate intenționat un disc din raft, ca să vezi dacă echipamentul chiar semnalează defecțiunea și dacă mesajul ajunge la cineva care îl citește.
Pasul 5: testul de restaurare, singura dovadă că sistemul funcționează
Un backup neverificat este o ipoteză. Testul se face pe trei niveluri, iar rezultatul fiecăruia se notează împreună cu durata reală:
- un fișier individual, șters intenționat și recuperat — ar trebui să dureze sub 15 minute;
- o căsuță de e-mail sau un dosar partajat, restaurat integral într-o locație separată;
- serverul principal, refăcut într-un mediu izolat, cu deschiderea efectivă a bazei de date și rularea unui raport, pentru a confirma că datele sunt coerente, nu doar copiate.
Calculează și timpul de aducere a datelor din cloud: 500 GB pe o conexiune de 200 Mbps înseamnă în jur de șase ore doar transfer, la care se adaugă instalarea și reconfigurarea. Dacă RTO-ul stabilit la primul pas era de patru ore, testul îți arată că restaurarea trebuie să pornească dintr-o copie locală, iar cea din cloud rămâne plasa de siguranță. Firmele descoperă frecvent la primul test lucruri de tipul: sarcina copia un dosar abandonat după migrarea ERP-ului, licența aplicației era legată de hardware-ul vechi, nimeni nu mai știa parola contului de stocare. Toate se rezolvă într-o zi de lucru, cu condiția să fie descoperite la test, nu în ziua incidentului.
Programează testul trimestrial și ține un registru simplu, cu data, ce s-a restaurat, cât a durat și ce nu a funcționat din prima.
Rezultatul: cum arată sistemul după 30 de zile
La finalul acestui parcurs ar trebui să existe un document de o pagină, tipărit și păstrat și în afara rețelei, care să conțină: ce se salvează, unde ajung copiile, cine răspunde, unde sunt cheile și parolele și procedura de restaurare în pași numerotați. Motivul pentru care se tipărește este cât se poate de concret — în ziua în care serverul este criptat, procedura salvată pe server nu se mai poate citi.
Indicatorii urmăriți lunar sunt patru: rata de succes a rulărilor, cu 98% ca prag rezonabil, vechimea celei mai recente copii verificate pentru fiecare sistem, durata măsurată la ultimul test de restaurare și costul lunar total, raportat la volumul de date. Când toate patru sunt scrise într-un singur loc și cineva le citește o dată pe lună, backupul încetează să fie o intenție și devine un proces. Restul este rutină: verificare lunară de 30 de minute, test trimestrial de restaurare și o revizuire anuală a inventarului, pentru că orice firmă adaugă sisteme noi pe care nimeni nu s-a gândit să le includă în plan.
