VPS Snapshots vs Backups: What Is the Difference

Short answer: snapshots roll back, backups rescue

A snapshot is a point-in-time image of the entire VPS disk: operating system, configuration, code and data. You create it in the provider's panel in a couple of clicks and can quickly restore the whole server from it or clone a new one.

A backup, in the strict sense, is an independent copy of important data that is stored separately from the server and the provider and restored through a tested procedure.

A snapshot answers "how do I get back to yesterday's state quickly". A backup answers "how do I keep my data if the server is gone".

What a snapshot captures and where it lives

• It copies the block device as a whole, without knowing which blocks are files and which are junk.
• It is usually incremental: the first snapshot is full, later ones store only changed blocks.
• It is stored in the same provider's infrastructure, often in the same region and always in the same account.
• Restoring means rolling back the whole disk or creating a new server from the image. Pulling out a single file is often clumsy.

The key point: a snapshot is convenient, but it is tied to one account at one provider.

Why a snapshot at the same provider is not a real backup

A snapshot will not help in scenarios that hit the whole account or provider:

• Account compromise. An attacker with panel access deletes servers and snapshots alike.
• Suspension or unpaid invoices. The account is frozen and you lose access to everything.
• Server deletion. With some providers, automatic copies belong to the server and disappear with it.
• Data errors. If corrupted or deleted records are noticed a week later and snapshots are kept for three days, there is nothing to roll back to.
• Data center or region incidents. Rare, but copies in the same region can become unavailable together with the server.

The consistency problem with databases

Snapshotting a running server is roughly like pulling the power cord: the copy is crash-consistent. Database files may be caught mid-write.

• PostgreSQL and MySQL (InnoDB) usually recover using their logs, but that is not a guarantee, especially when data is spread across several disks.
• It is safer to take a logical dump with the database's own tools, or a physical backup with log archiving (WAL, binlog).
• If you specifically need a consistent snapshot, pause writes briefly: stop the service or freeze the file system (fsfreeze) while the snapshot is taken.

# PostgreSQL: consistent dump without stopping the database
pg_dump -Fc -d app_db -f /backup/app_db.dump

# MySQL/InnoDB: dump inside a single transaction
mysqldump --single-transaction --routines app_db > /backup/app_db.sql

How to combine snapshots and backups

A setup that works for most projects:

1. Automatic provider snapshots daily, kept for several days, plus a manual snapshot before every major update.
2. Scheduled database dumps at least once a day, more often for critical data, or continuous log archiving.
3. File backups of user uploads, configs and secrets with tools such as restic or borg, encrypted.
4. Off-site storage: object storage at a different provider or in a separate account with its own credentials. The server should be able to write there but not delete.
5. Retention policy: for example, daily copies for a week, weekly for a month, monthly for a year, adjusted to your requirements.
6. Monitoring: if a backup fails, you find out right away, not on the day of the outage.

Test restores are mandatory

A backup you have never restored from is hope, not protection. On a regular basis:

• spin up a clean server and restore the database dump and files on it;
• check that the application starts and the data is current;
• time the restore, because that is your real RTO;
• write the steps into a short runbook so more than one person can do it.

Common mistakes

• Treating automatic provider snapshots as the only protection.
• Keeping backups on the same server, just on another partition.
• Giving the server permission to delete off-site copies.
• Leaving backups that contain personal data and keys unencrypted.
• Never testing a restore.