Pe scurt: O strategie de backup solidă pentru server urmează regula 3-2-1: trei copii, două tipuri de stocare, o copie în afara sediului. Pentru ca backupurile să supraviețuiască și unui atac, cel puțin o copie are nevoie de protecție împotriva ștergerii de către serverul însuși. Iar abia un test reușit de restaurare arată că salvarea funcționează în caz real.
Ce înseamnă regula 3-2-1
Regula 3-2-1 este un principiu simplu, dovedit de ani de zile, pentru salvarea datelor:
- 3 copii: datele originale și două salvări.
- 2 tipuri de stocare: de exemplu disc local și stocare de obiecte, sau stocare pe server și bandă.
- 1 copie în afara sediului: într-un alt loc, la un alt furnizor sau offline.
Pentru serverele web, aceasta înseamnă concret: o salvare pe același disc cu site-ul nu contează ca o copie independentă. Dacă serverul cade sau este compromis, ambele sunt pierdute. Pentru conducere, întrebarea de bază nu este deci „Avem backupuri?”, ci „Putem restabili activitatea dintr-o copie pe care incidentul nu a atins-o?”
O strategie de backup pentru server care supraviețuiește unui atac
Atacatorii știu că backupurile le anulează munca. Cine are acces la un server caută de aceea adesea și salvări, pentru a le șterge sau a le cripta. O strategie modernă extinde de aceea adesea regula 3-2-1 la 3-2-1-1-0: o copie suplimentară offline sau imuabilă și zero erori la testul de restaurare.
Trei principii fac backupurile rezistente:
- Pull în loc de push: Un sistem de backup separat preia datele de la serverul web. Serverul web însuși nu are date de acces cu care ar putea șterge backupuri.
- Imuabilitate: Stocare de obiecte cu blocare a păstrării sau snapshoturi care nu pot fi șterse un timp stabilit.
- Accesuri separate: Contul de backup nu este același cu contul de client al furnizorului de hosting și are propriul al doilea factor.
Criptați backupurile care se află în afara sediului și păstrați cheia separat. O cheie pierdută face backupul inutilizabil, iar o cheie stocată împreună cu el face criptarea fără valoare.
Ce trebuie salvat
La serverele web se salvează adesea doar webroot. Pentru o restaurare completă lipsesc atunci părți importante.
| Zonă | Exemple | Indicație |
|---|---|---|
| Fișierele aplicației | webroot, încărcări, teme, extensii | încărcările se modifică des |
| Baze de date | MySQL/MariaDB, PostgreSQL | salvați consecvent, nu copiați doar fișiere |
| Configurare | server web, pool-uri PHP-FPM, php.ini, cronjoburi | necesară pentru o reconstruire rapidă |
| Certificate și chei | certificate TLS, chei de aplicație | depuneți criptat și separat |
| Documentație | accesuri, dependențe, procesul de restaurare | fără ea, orice reconstruire durează mai mult |
Exemplu: salvarea bazei de date și a fișierelor
Exemplul următor arată componentele de bază ale unei salvări zilnice. În practică, un instrument de backup cu criptare, deduplicare și reguli de păstrare preia transferul în afara sediului.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Salvați baza de date consecvent; datele de acces dintr-un fișier protejat, nu în comandă
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# Fișierele aplicației și configurarea
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Sume de control pentru verificare ulterioară
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
Fișierul .backup-my.cnf conține datele de acces ale unui utilizator de bază de date care are voie doar să citească și are drepturile 0600. --single-transaction asigură, la tabelele InnoDB, o stare consecventă, fără a opri magazinul.
Apoi, un sistem separat transferă salvarea în afara sediului. Important este ca acest pas să fie monitorizat: un job de backup care eșuează în tăcere de zile întregi se observă altfel abia în caz real. Un mesaj zilnic despre reușită, dimensiune și durată este suficient, atâta timp cât cineva îl citește și urmărește abaterile.
Dacă folosiți suplimentar backupuri sau snapshoturi ale furnizorului de hosting, clarificați în scris cât timp sunt păstrate, dacă puteți restaura singur și dacă salvările se păstrează la un cont reziliat sau blocat. Aceste copii sunt un bun adaos, dar nu înlocuiesc o salvare proprie, independentă.
Păstrarea: de ce contează stările mai vechi după PHP2Shell
După un atac, nu cel mai recent backup este cel mai valoros, ci cel mai recent curat. La PHP2Shell, potrivit rapoartelor din presă, o primă tentativă de atac a fost observată la 17.10.2026, iar patchurile au apărut la 21.10.2026. Cine păstrează doar șapte zile poate să nu mai aibă nicio stare care să fie sigur anterioară unei posibile intruziuni.
O schemă dovedită combină mai multe perioade, de exemplu salvări zilnice pentru câteva săptămâni, săptămânale pentru câteva luni și lunare pentru un an. Perioadele exacte depind de nevoia dumneavoastră de protecție și de obligațiile de ștergere din protecția datelor.
Important este și: un backup din perioada de după o intruziune poate conține webshell-uri sau fișiere modificate. După un incident nu restaurați niciodată orbește, ci comparați fișierele cu o stare curată și verificați-le înainte ca site-ul să revină online. Indicii despre ce să urmăriți găsiți la Semnele unei compromiteri. Un patch nu elimină software-ul malițios introdus, iar un backup nu o face nici el de la sine.
Testarea și documentarea restaurării
Un backup fără test este o presupunere. Abia restaurarea arată dacă toate părțile sunt prezente, dacă cheia funcționează și cât durează efectiv procesul.
- Restaurați periodic o salvare completă într-un mediu de test, inclusiv baza de date și configurarea.
- Verificați dacă site-ul funcționează apoi complet: autentificare, comenzi, formulare, e-mailuri.
- Măsurați durata și consemnați ce pași au fost manuali. Comparați rezultatul cu timpul maxim pe care activitatea dumneavoastră îl poate suporta fără site.
- Depuneți ghidul de restaurare într-un loc accesibil și când serverul este căzut, de exemplu în planul de urgență IT.
Cum ajută PHP SOS concret?
- Verificăm backupurile dumneavoastră existente pentru completitudine, păstrare, separare de server și protecție împotriva ștergerii.
- Configurăm o salvare 3-2-1 cu copie imuabilă și testăm restaurarea împreună cu dumneavoastră.
- După un incident identificăm ultima stare curată și o restaurăm pe un sistem patchuit, în cadrul eliminării malware-ului.
- În contractul de întreținere de securitate monitorizăm continuu salvările și efectuăm teste periodice de restaurare.
Întrebări frecvente
Ce înseamnă regula 3-2-1 la backupuri?
Trei copii ale datelor dumneavoastră, pe două tipuri diferite de stocare, dintre care una într-un alt loc. Regula face ca nici o defecțiune hardware, nici un atac sau un incendiu să nu lovească toate copiile simultan.
Este suficient backupul furnizorului meu de hosting?
Este un bun adaos, dar rareori suficient. Clarificați cât timp păstrează furnizorul stările, dacă puteți restaura singur și dacă un atacator cu contul dumneavoastră de client ar putea șterge backupurile. O copie proprie, independentă, este recomandată.
Pot, după un hack, să restaurez pur și simplu ultimul backup?
Doar cu prudență. Ultimul backup poate conține deja cod malițios, iar vulnerabilitatea prin care a intrat atacatorul rămâne după aceea deschisă. Mai întâi clarificați și închideți cauza, apoi restaurați o stare verificată pe un sistem patchuit.
Cât de des ar trebui să testez restaurarea?
Periodic și după modificări mai mari ale sistemului. S-a dovedit utilă o cadență fixă, de exemplu o restaurare completă pe trimestru într-un mediu de test. Important este ca testul să fie documentat și lacunele să fie remediate.