Snapshot vs backup: what is the difference?

"I have a snapshot, so I'm backed up" is one of the most expensive assumptions in hosting. Snapshots and backups both save copies of your data, but they protect against different problems. This guide explains how each works, where each falls short, and how to combine them using the 3-2-1 rule so that no single failure can take your data with it.

Before you start

• A rough list of what on your server matters: website files, databases, app data, configuration, desktop files on an Admin RDP.
• An idea of how much data you could afford to lose: an hour, a day, a week. This decides how often you back up.

What a snapshot is

A snapshot is a point-in-time image of a whole server disk, taken at the virtualisation or storage level. Restoring it rolls the entire server back to exactly how it was at that moment: operating system, apps, settings and data.

Snapshots are good for:

• Quick rollback before a risky change, such as a major upgrade or a big config edit.
• Restoring the whole server at once, without reinstalling anything.

Their limits:

• They usually live on the same platform as the server. A problem there can affect the server and its snapshots together.
• They are all or nothing. Rolling back to get one deleted file also undoes everything else since the snapshot.
• They are often short-lived: kept for days, not months.
• A snapshot of a running database may be inconsistent, like pulling the plug and copying the disk.

What a backup is

A backup is an independent copy of your data, stored somewhere else: another server, object storage or your own computer. It is usually made from inside the server by a backup tool, a script or a database dump.

Backups are good for:

• Surviving the loss of the server, whatever the cause: a mistake, a hack, a cancelled service or a hardware problem.
• Restoring single files or databases without rolling back the whole server.
• Keeping history: daily copies for a week, weekly for a month, monthly for a year.
• Moving to a new server, because the data is not tied to the old one.

Their limits:

• Restoring a whole server takes longer: reinstall, then restore data and settings.
• You must set them up, check them and keep them running.

Side by side

• Where it lives: snapshot, on the hosting platform; backup, somewhere separate you choose.
• What it covers: snapshot, the whole disk; backup, whatever you choose to copy.
• Restore: snapshot, the whole server at once; backup, anything from one file to everything.
• Protects against loss of the server: snapshot, often not; backup, yes, if stored off the server.
• Best use: snapshot, a quick undo button; backup, your real safety net.

The 3-2-1 backup rule

A simple rule many sysadmins follow:

• 3 copies of your data: the live copy plus two backups.
• 2 different types of storage, such as the server disk and object storage.
• 1 copy off-site, away from the server's platform.

For a single VPS, a practical version is:

1. The live data on the server.
2. A nightly backup to separate storage, such as object storage or another server.
3. A weekly copy downloaded to your own computer or a second provider.

Many people add one more idea: keep at least one copy that cannot be changed or deleted from the server itself. Ransomware and attackers often delete backups they can reach.

Back up databases properly

Copying a live database's files can give you a broken copy. Use the database's own dump tool so the backup is consistent. For example, for MySQL or MariaDB on Linux:

mysqldump --single-transaction --all-databases > all-databases.sql

--single-transaction takes a consistent copy of InnoDB tables without locking them. Then copy the .sql file off the server with your backup tool.

Check it works

A backup you have never restored is a hope, not a backup. Every few months:

1. Pick a backup at random.
2. Restore it to a test location, such as a spare folder or a test server.
3. Open some files, or import the database dump and check a few records.
4. Note how long the restore took. That is your real recovery time.

Troubleshooting

• Backups stopped running and nobody noticed: set up an alert when a backup job fails, or check the newest backup's date every week.
• The backup is too big to download: back up only data and configuration, not the operating system, which you can reinstall.
• A restore from snapshot lost recent changes: that is expected. Anything after the snapshot time is gone. Restore those files from a backup instead.
• The database backup will not import: check that it was made with a dump tool, not by copying data files from a running server.

Next steps

• Set up backups on Linux: Back up a Linux VPS with rsync and restic.
• Set up backups on Windows: Back up Windows Server.
• Go deeper on the rule: The 3-2-1 backup rule for a VPS.