A backup is a copy you can restore from. Everything else is detail, but the details decide whether the copy saves you. Plenty of people have a backup in the sense that a file exists somewhere with the word "backup" in its name; far fewer have one that would bring their site back, with its database, on a bad evening, in a time they could live with.
The things that destroy data are not exotic. A plugin update that corrupts content. A hacked account that deletes files. A mistyped command. A disk that fails. A hosting provider that has an incident in the building where your server and its only copy both live. Backups exist for all of them, and each failure favours a different kind of backup.
This article covers the vocabulary (full, incremental, differential, snapshot), the 3-2-1 rule, how to back up a database without corrupting it, how long to keep copies, and the part most people skip: practising the restore.
Kinds of backup
A full backup copies everything. It is the simplest to restore, since one set of files is all you need, and the most expensive in time and space.
An incremental backup copies only what changed since the last backup of any kind. It is small and quick, but it needs the whole chain to restore: the last full backup plus every incremental after it, applied in order. Lose one link and everything after it is unusable.
A differential backup copies what changed since the last full backup. Each one is bigger than an incremental, and it grows through the week, but a restore needs only two pieces: the full backup and the latest differential.
A snapshot is a point-in-time image of a disk or volume, usually taken by the provider or the storage layer. It is fast and useful, often taking seconds, but it generally lives on the same infrastructure as the thing it protects and is not a replacement for a separate copy.
Most real systems mix these: a weekly full, daily incrementals, and a provider snapshot as a quick undo button. Tools such as restic, borg and rsnapshot hide the chain bookkeeping by storing data in deduplicated chunks, so every backup looks like a full one while taking incremental space.
The 3-2-1 rule
Keep three copies of your data, on two different kinds of storage, with one copy somewhere else. For a small site that might be the live site, a nightly backup on the host, and a weekly download to your own cloud storage. It sounds like a lot until the day it isn't.
Each part answers a different failure. Three copies cover the chance that one is bad. Two kinds of storage cover a fault that affects a whole technology, such as a firmware bug in one vendor's disks. One copy elsewhere covers fire, flood, a provider outage, and the case most often seen in practice: an attacker or a mistake that deletes everything reachable from your account, backups included.
That last point deserves attention. If your backup storage can be written or deleted with the same password or API key as your live server, a compromise of that credential takes the backups with it. Better setups give the backup process a key that can add files but not delete them, or keep a copy in a place that needs a separate login. Several storage services offer object lock or versioning, which keeps older versions even after a delete command.
| Setup | Survives a bad update | Survives a deleted account | Survives a provider outage |
|---|---|---|---|
| Provider snapshots only | Yes | Often no | No |
| Nightly backup on the same server | Yes | No | No |
| Host backup plus offsite copy under another login | Yes | Yes | Yes |
Databases need care
Copying a database's files while it is running can produce a corrupt copy, because the engine is in the middle of writing and the files are not consistent with each other. Use a dump tool such as mysqldump, or a method the database supports for consistent copies.
mysqldump --single-transaction --routines --triggers -u backupuser -p shopdb | gzip > shopdb-2026-10-05.sql.gzThe --single-transaction flag gives a consistent view of InnoDB tables without locking the site. Check that the dump is not empty: sizes tell you a lot. A database that dumped at 48 MB last week and 2 KB today has failed, even if the command exited without a visible complaint. A quick sanity check is to look at the end of the file, since a complete dump finishes with a comment line that says "Dump completed".
ls -lh shopdb-*.sql.gz
zcat shopdb-2026-10-05.sql.gz | tail -n 2Many restores go wrong because files and database were backed up at different moments. A WordPress site whose uploads folder is from Tuesday and whose database is from Friday will have posts pointing at images that are not there, or images with no posts. Take both close together, and name them so you can pair them again.
Retention: how far back can you go?
If a plugin damages content and you notice three weeks later, a two-week retention does not help. Problems are discovered late more often than people expect: a broken contact form that nobody tested, a malware infection that sat unnoticed for a month, a product table with wrong prices that only a customer noticed. Keep daily copies for a couple of weeks and monthly ones for longer, within your storage budget.
A common scheme is called grandfather-father-son: daily copies for 14 days, weekly copies for 8 weeks, monthly copies for 6 to 12 months. With deduplicating tools this costs surprisingly little, because most of the data does not change between copies.
Also think about the opposite problem. A backup containing customer data is itself personal data, and keeping it for seven years may conflict with promises you have made or rules you are bound by. If someone asks for their data to be erased, old backups are a known awkward corner; the usual answer is a documented retention period after which backups expire, and a rule to re-apply erasures after any restore.
Test the restore
The only backup that counts is one you have restored. Do it to a staging area at least once a quarter, and time it. When something goes wrong at 11 p.m., you want to know already that it takes forty minutes and which steps to follow. Write them down.
A restore drill for a typical small site looks like this:
- Create an empty staging site or a spare directory, and an empty database.
- Unpack the file backup into the staging directory.
- Import the database:
gunzip < shopdb-2026-10-05.sql.gz | mysql -u stageuser -p stagedb. - Edit the site configuration to point at the staging database, and change the site address if the application stores it (WordPress does).
- Load the site. Log in. Open a product or post that has images. Submit a test form.
- Record how long each step took and what surprised you.
The surprises are the point. Common ones: the backup omitted a hidden file such as .htaccess; the database user needed a privilege that was never documented; the backup was of the wrong site; the archive was corrupt at byte 80,000,000 because the disk filled up during creation. Better to meet these on a quiet Tuesday.
What changes between hosting types
On shared hosting the provider usually runs backups, and the panel offers a restore button, often for the whole account or for individual files and databases. Ask how long they keep them and whether they are stored away from the server. Treat them as one copy, and add your own offsite one, even if it is a monthly manual download.
On a VPS you are in charge. Provider snapshots are convenient but usually incur a fee and live in the same account. Add a file-level backup to separate storage using a tool such as restic or borg, scheduled with cron (the cron helper can write the line), and a database dump just before it runs. On dedicated servers the same applies, with the added fact that a failed disk means a hardware repair while you wait.
Managed platforms vary widely. Read what yours actually promises: some give hourly restore points, some give a daily one and charge for more. Whatever the plan says, an independent copy under your control is cheap insurance.