Regula, în trei rânduri
- 3 copii ale datelor: originalul plus două backup-uri.
- 2 tipuri diferite de suport sau sisteme, ca o singură defecțiune să nu le ia pe toate.
- 1 copie în altă locație fizică, în afara sediului.
Regula a fost formulată de fotograful Peter Krogh, pentru arhive de imagini, și a devenit standardul de facto în IT pentru că e ușor de reținut și greu de păcălit. Fiecare cifră răspunde la un scenariu real de pierdere: eroare umană, defecțiune de hardware, dezastru la sediu.
De ce sincronizarea nu e backup
Cea mai frecventă confuzie: „avem totul în OneDrive / Google Drive / Dropbox”. Sincronizarea face ca același fișier să existe în mai multe locuri, dar orice modificare se propagă peste tot. Dacă un ransomware criptează documentele de pe laptop, versiunile criptate ajung în cloud în câteva minute. Dacă cineva șterge un folder, dispare de peste tot.
Unele servicii păstrează un coș de gunoi sau versiuni pentru 30 de zile, ceea ce ajută la un fișier pierdut ieri. Nu ajută când descoperi la audit că un contract a fost suprascris acum patru luni. Backup-ul propriu-zis înseamnă copii independente, cu istoric, pe care sistemul de producție nu le poate atinge.
Versiunea din 2026: 3-2-1-1-0
Ransomware-ul a adăugat două cerințe la regula clasică:
- 1 copie imutabilă sau offline: o versiune care nu poate fi modificată sau ștearsă nici de un atacator care a obținut drepturi de administrator în rețea. Fără asta, atacatorii criptează întâi backup-ul și abia apoi producția, exact ca să te lase fără opțiuni.
- 0 erori la testul de restaurare. Un backup pe care nu l-ai restaurat niciodată e o presupunere, nu o asigurare.
Test rapid: dacă cineva ar cripta în acest moment toate calculatoarele și serverele din rețeaua ta, cu drepturi de administrator, ar mai rămâne o copie a datelor pe care nu ar putea-o atinge? Dacă răspunsul e „nu știu”, răspunsul e „nu”.
Două cifre pe care trebuie să le decizi: RPO și RTO
RPO (Recovery Point Objective) e cât de multe date accepți să pierzi: dacă backup-ul rulează o dată pe noapte, într-un scenariu rău pierzi ziua de lucru curentă. Pentru contabilitate, o zi e de obicei acceptabil. Pentru un magazin online cu comenzi din minut în minut, nu.
RTO (Recovery Time Objective) e cât timp accepți să stai fără sisteme: câteva ore, o zi, o săptămână. Restaurarea unui fișier durează minute; restaurarea unui server întreg de câțiva terabytes durează ore și depinde de conexiunea la locul unde stă backup-ul.
Ambele cifre sunt decizii de business, nu tehnice. Ele determină frecvența backup-ului, cât spațiu plătești și ce infrastructură de restaurare ai nevoie. O firmă care nu le-a discutat niciodată le descoperă în ziua incidentului, când sunt deja prea mari.
Cele cinci greșeli pe care le vedem cel mai des
- Backup-ul pe același server sau pe un al doilea disc din aceeași mașină. O defecțiune de alimentare, un furt sau un ransomware le ia pe amândouă.
- Hard-ul extern din dulap. E rulat „când ne aducem aminte”, stă în aceeași clădire și, conectat la calculator, e criptat împreună cu restul.
- Fără istoric. O singură copie, suprascrisă de fiecare dată. Perfect pentru a păstra intact ultimul fișier corupt.
- Fără notificări. Job-ul de backup a eșuat în martie; se descoperă în octombrie, la incident.
- Fără test de restaurare. Copia există, dar e incompletă, criptată cu o cheie pierdută sau incompatibilă cu serverul nou.
Și GDPR?
Articolul 32 din GDPR cere explicit „capacitatea de a restabili disponibilitatea și accesul la datele cu caracter personal în timp util în cazul unui incident”. Cu alte cuvinte, backup-ul testat nu e doar bună practică, ci obligație legală pentru orice firmă care prelucrează date personale, adică toate. Locul unde stau copiile contează și el: un backup în afara Uniunii Europene aduce cu sine toată problematica transferurilor internaționale de date.
Cum arată o implementare corectă
- Un agent pe fiecare server și stație importantă, care rulează automat, fără să depindă de un om.
- Criptare pe echipamentul sursă, înainte de transfer, cu cheia la client.
- Copii versionate într-un datacenter din altă locație, în România, cu versiuni imutabile.
- Alerte la eșec și rapoarte periodice, ca lipsa unui backup să se vadă în ziua următoare, nu peste luni.
- Un test de restaurare programat, documentat, cu timpul real măsurat.
Exact pe acest model am construit Real-Backup. Dar principiile sunt aceleași indiferent cu cine lucrezi: dacă furnizorul tău actual nu îți poate răspunde în două minute la întrebările despre imutabilitate, retenție și ultimul test de restaurare, ai de fapt răspunsul.