Un backup nu e o măsură de securitate până când nu l-ai restaurat cu succes, pe o mașină curată, în timpul propus. Ransomware-ul modern caută întâi serverul de backup, deci o copie trebuie să fie și în afara rețelei.
Un snapshot al VPS-ului stă pe același storage, la același furnizor, sub același cont. Dacă contul e compromis sau storage-ul cedează, dispare cu serverul. E util după un update ratat, dar nu e una dintre cele trei copii. Backup-ul netestat e a doua capcană: dump-ul rulează de luni și nimeni nu l-a deschis. La incident afli că e trunchiat, că lipsește un tabel sau că cheia de criptare a rămas pe serverul criptat.
Prima copie e serverul însuși. A doua e un backup zilnic pe un storage separat, criptat la sursă cu restic sau borg, care fac deduplicare și versionare. A treia e offsite: alt datacenter sau alt furnizor, cu acces doar de scriere de pe server, ca un atacator să nu poată șterge istoricul. Copia imutabilă o obții prin object lock pe storage S3 compatibil. Pentru baze de date faci dump logic sau PITR, nu copiezi fișierele în timpul scrierii.
Art. 32 GDPR cere explicit capacitatea de a restabili disponibilitatea și accesul la datele personale în timp util după un incident; ANSPDCP verifică asta la orice notificare de breșă. Firmele care emit e-Factura trebuie să păstreze facturile transmise la ANAF pe durata legală de arhivare, deci pierderea arhivei XML e o problemă fiscală. Entitățile înregistrate la DNSC sub OUG 155/2024 au continuitatea activității și backup-ul printre măsurile cerute de art. 11 din OUG 155/2024.
| Element | Ce înseamnă | Cum îl implementezi | Cum îl verifici |
|---|---|---|---|
| 3 copii | Producție + două backup-uri | Backup zilnic local + offsite | Aceeași versiune în toate |
| 2 suporturi | Storage-uri diferite | Disc local + object storage | Un incident nu le atinge pe ambele |
| 1 offsite | Altă locație fizică | Alt datacenter sau furnizor | Restaurare de test din copia offsite |
| 1 imutabil | Nu poate fi șters de pe server | Object lock sau rest-server --append-only; curățarea rulează separat, nu de pe server | Ștergerea din contul serverului eșuează |
| 0 erori | Restaurarea reușește complet | Test lunar pe mașină separată | Aplicația pornește, datele sunt corecte |
export RESTIC_REPOSITORY=s3:https://s3.exemplu.ro/backup-exemplu
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=...
restic init
restic backup /var/www /etc /var/backups/db --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check --read-data-subset=1/10pg_dump -Fc -U app exemplu_db > /var/backups/db/exemplu_db-$(date +%F).dumprestic restore latest --target /restore
createdb exemplu_db_test
pg_restore -Fc -d exemplu_db_test /restore/var/backups/db/exemplu_db-2026-09-07.dumpArhiva XML a facturilor era doar pe serverul de aplicație și în snapshot-ul furnizorului. După un ransomware, ambele erau criptate. Firma a reconstruit arhiva din SPV cu efort mare și a trecut pe copii zilnice criptate, offsite, cu object lock.
Dump-ul de MySQL rula zilnic, dar de trei luni eșua din lipsă de spațiu și nimeni nu primea alertă. La un update ratat, ultima copie validă avea trei luni. Testul lunar de restaurare și alerta pe eșec au urmat a doua zi.
Depinde de RPO. Dacă poți pierde cel mult o zi de date, backup-ul zilnic e suficient. Un magazin cu comenzi continue are nevoie de backup al bazei de date la câteva ore sau de PITR, care permite revenirea la orice moment. Fișierele statice se pot copia mai rar decât baza de date.
O copie care, odată scrisă, nu poate fi modificată sau ștearsă până la expirarea retenției, nici de un administrator cu drepturi depline. Se obține prin object lock pe storage S3 compatibil sau prin depozite append-only. Așa un atacator care controlează serverul nu poate distruge istoricul.
E o copie bună, dar e o singură copie, la un singur furnizor, sub un singur cont. Regula 3-2-1 cere o copie în altă locație și pe alt suport, pe care tu o controlezi. Păstrezi backup-ul furnizorului ca primă linie și adaugi propria copie offsite.
Un server de producție e atacat automat din primele minute după ce primește IP public, indiferent cât de mic e proiectul. Ghidul ordonează controalele după impact, de la accesul SSH până la răspunsul la incident, cu legislația din România care se aplică. Fiecare temă are o pagină dedicată, cu răspuns scurt, exemple și configurări.