A copy that has never been restored does not count as a backup. A working backup strategy answers three questions: what to copy, where to keep the copies, and how often to do it.
The 3-2-1 Rule
The 3-2-1 rule is the foundation of any backup strategy: three copies of the data, on two different types of media, with one copy kept off the main site. The working copy on the server does not count as a backup — it is only the first of the three.
Two different media protect against the failure of specific hardware: if one disk or one server fails, the second copy sits on a different device and is not affected along with it. The off-site copy protects against events that affect the whole server or the whole data center: fire, theft of equipment, or an administrator error that hits the main storage system.
What exactly to copy
The list of what belongs in the scheme is wider than it first looks — the forgotten part usually surfaces during the restore itself.
| What to copy | How often | Why exactly this |
|---|---|---|
| Website files | After every significant change | Code and media change rarely but are fully critical |
| Database | More often than files | Orders, comments, and user records change constantly |
| Server configuration | After every setup change | Without it the restored site will not work as before |
| Mail and mailboxes | On a schedule, separate from the site | Mail is stored separately and easily drops out of the scheme |
| Certificates and keys | On issuance or renewal | Without them the certificate has to be reissued from scratch |
Full, incremental, and differential copies
These three copy types use disk space differently and behave differently when restoring — the choice between them determines how long rolling back takes.
| Copy type | What it stores | Creation speed | Restore speed | Risk |
|---|---|---|---|---|
| Full | All data entirely | Slow | Fast | Low |
| Incremental | Changes since the last copy of any type | Fast | Slow | The chain breaks if one link is lost |
| Differential | Changes since the last full copy | Medium | Medium | Grows in size between full copies |
Two numbers that set the whole scheme
The whole strategy is built around two questions, and the answer to them determines the backup frequency and the choice of storage location.
The first is how much data you can afford to lose if a failure happens right now. The more changes happen between copies, the more is lost in the worst case, so copying should happen more often. The second is how much time there is for the restore while the site is down. If time is limited, a faster rollback method is chosen even if it is harder to set up.
Where not to keep a copy
Three places look like a backup storage, but each of them shares the fate of the original in at least one failure scenario.
- On the same disk as the original — disk damage destroys both copies at once.
- On the same server in a neighboring folder — an operating system failure or a server breach hits the copy too.
- Only in the provider's control panel — a convenient option, but not a replacement for independent storage outside the main infrastructure.
Testing by restoring
A copy that has never been deployed may turn out to be corrupted, incomplete, or incompatible with the current system version — and that is discovered at the worst possible moment. The check is worth treating as a separate task on the calendar, not as part of making the copy.
Ready-made tools are convenient for the copying itself: details on deduplication and incremental snapshots are in the article restic and BorgBackup, and on moving files between servers in the article rsync.
Frequently asked questions
What is a server backup?
A server backup is a copy of server data, files, and settings kept separately from the working system to allow recovery after a failure, breach, or mistake. The copy itself does not protect anything until it has been tested by restoring at least once, otherwise it remains an unproven assumption.
How often should backups be made?
Frequency depends on how much data can be lost in a failure: a site with daily orders is copied more often than a static brochure page. The database is usually copied more often than site files, and the server configuration after every significant settings change.
How many copies should be kept?
The 3-2-1 rule sets the minimum: three copies on two different media, one of them off the main site. A larger number of versions over time allows rolling back to an earlier point if the damage was not noticed right away but only later.
Are virtual machine snapshots enough?
A virtual machine snapshot is not yet a second independent copy if it sits on the same storage as the machine itself. Snapshots are convenient for a quick rollback, but they cannot replace the 3-2-1 scheme: a copy outside the site where the machine runs is still needed.
Where to start if there are no copies at all
The right place to start is not picking a tool but answering the question of what exactly cannot be lost: files, the database, or both at once. Next comes one copy outside the server and one trial restore run, to make sure the scheme actually works.