The security measures discussed so far (prepared statements, GRANT/REVOKE, least privilege) aim to prevent an attack. Backup plays a different, complementary role: it assumes that, despite all preventive measures, something might still destroy or corrupt the data — whether a SQL Injection attack using DROP TABLE/DELETE, human error, hardware failure, or ransomware. Backup is the last line of defense: if every other measure fails, a recent, tested backup is the difference between a minor incident and an irreversible data loss.
A complete copy of the entire database at a given point in time — all tables, all rows, the complete structure.
mysqldump -u root -p Countries > countries_full_backup_2026-07-05.sqlAdvantages: simplest to restore — a single file, a single command (mysql -u root -p Countries < countries_full_backup_2026-07-05.sql). Does not depend on any prior backups.
Disadvantages: the highest storage consumption and the slowest to generate, especially on large databases. Usually run less frequently (e.g., weekly), serving as the reference baseline for the other backup types.
Saves only the changes (inserts, updates, deletes) made since the last backup — regardless of whether that last backup was full or incremental. It effectively forms a chain: full → incremental 1 → incremental 2 → incremental 3...
Advantages: fastest to generate and takes up the least space, since it saves only the difference from the immediately preceding backup.
Disadvantages: restoration is slower and riskier — you must apply the full backup, then every incremental backup in strict chronological order. If a single file in the chain is corrupted or missing, everything after it becomes unusable.
Saves all changes made since the last full backup (not since the last backup of any type). Each differential backup is independent of the other differentials — it only depends on the reference full backup.
Advantages: simpler and faster restoration than incremental — you only need the full backup plus the most recent differential (not an entire chain).
Disadvantages: differential files progressively grow in size as time passes since the last full backup (each one contains all accumulated changes, not just the new ones).
| Criterion | Full | Incremental | Differential |
|---|---|---|---|
| What it saves | Everything | Only since the last backup (any type) | Everything since the last full |
| Backup time | Long | Short | Medium (increases over time) |
| Storage used | Large | Small | Medium (increases over time) |
| Restore speed | Fast | Slow (full chain) | Medium (full + latest differential) |
| Risk from a corrupted file | Low | High (breaks the chain) | Low |
An attack such as '; DROP TABLE WF_COUNTRIES; --, discussed in the previous section, instantly wipes out an entire table. Without a backup, the data is permanently lost — no subsequent preventive measure (patches, prepared statements) can recover what has already been deleted. With a backup strategy in place (for example, weekly full backups plus daily incrementals), recovery is reduced to restoring the last full backup and reapplying the incrementals, limiting the data loss to the time elapsed since the last backup — not the entire history of the database.
An additional recommended practice: backups should be stored separately from the main server (offline or on an isolated system); otherwise, an attacker who gains access to the server can delete or encrypt the backups as well, completely nullifying their usefulness.