Măsurile de securitate discutate până acum (prepared statements, GRANT/REVOKE, privilegiu minim) urmăresc să previi un atac. Backup-ul are un rol diferit, complementar: presupune că, în ciuda oricăror măsuri preventive, ceva poate totuși să distrugă sau să corupă datele — fie un atac SQL Injection cu DROP TABLE/DELETE, fie o eroare umană, o defecțiune hardware sau un ransomware. Backup-ul e ultima linie de apărare: dacă toate celelalte măsuri au eșuat, un backup recent și testat e diferența între o incidență minoră și o pierdere ireversibilă de date.
O copie completă a întregii baze de date, la un moment dat în timp — toate tabelele, toate rândurile, structura completă.
mysqldump -u root -p Countries > countries_full_backup_2026-07-05.sqlAvantaje: cel mai simplu de restaurat — un singur fișier, o singură comandă (mysql -u root -p Countries < countries_full_backup_2026-07-05.sql). Nu depinde de alte backup-uri anterioare.
Dezavantaje: cel mai mare consum de spațiu de stocare și cel mai lent de generat, mai ales pe baze de date mari. De obicei se rulează mai rar (ex. săptămânal), fiind baza de referință pentru celelalte tipuri.
Salvează doar modificările (inserări, actualizări, ștergeri) apărute de la ultimul backup — indiferent dacă acela a fost full sau incremental. Formează practic un lanț: full → incremental 1 → incremental 2 → incremental 3...
Avantaje: cel mai rapid de generat și ocupă cel mai puțin spațiu, pentru că salvează doar diferența față de backup-ul imediat precedent.
Dezavantaje: restaurarea e mai lentă și mai riscantă — trebuie aplicat backup-ul full, apoi fiecare incremental în ordine cronologică strictă. Dacă un singur fișier din lanț e corupt sau lipsă, tot ce vine după el devine inutilizabil.
Salvează toate modificările apărute de la ultimul backup complet (nu de la ultimul backup, indiferent de tip). Fiecare backup diferențial e independent de celelalte diferențiale — depinde doar de full-ul de referință.
Avantaje: restaurare mai simplă și mai rapidă decât la incremental — ai nevoie doar de backup-ul full + cel mai recent diferențial (nu de un lanț întreg).
Dezavantaje: fișierele diferențiale cresc progresiv în dimensiune pe măsură ce trece timpul de la ultimul full backup (fiecare conține toate modificările acumulate, nu doar cele noi).
| Criteriu | Full | Incremental | Diferențial |
|---|---|---|---|
| Ce salvează | Tot | Doar de la ultimul backup (orice tip) | Tot de la ultimul full |
| Timp de backup | Mare | Mic | Mediu (crește în timp) |
| Spațiu ocupat | Mare | Mic | Mediu (crește în timp) |
| Viteză de restaurare | Rapidă | Lentă (lanț complet) | Medie (full + ultimul diferențial) |
| Risc la fișier corupt | Scăzut | Ridicat (rupe lanțul) | Scăzut |
Un atac de tip '; DROP TABLE WF_COUNTRIES; --, discutat în secțiunea anterioară, șterge instant un tabel întreg. Fără backup, datele sunt pierdute definitiv — nicio măsură de prevenție ulterioară (patch-uri, prepared statements) nu recuperează ce a fost deja șters. Cu o strategie de backup (de exemplu full săptămânal + incremental zilnic), recuperarea se reduce la restaurarea ultimului full backup și reaplicarea incrementalelor, limitând pierderea de date la intervalul scurs de la ultimul backup — nu la tot istoricul bazei.
O practică recomandată suplimentară: backup-urile trebuie stocate separat de serverul principal (offline sau pe un sistem izolat), altfel un atacator care obține acces la server poate șterge sau cripta și backup-urile, anulându-le complet utilitatea.