Snapshot vs backup: what is the difference for a cloud server?

What a snapshot is

A snapshot copies a disk block by block: the operating system, installed packages, configuration and data, exactly as they were on disk at one moment. The provider stores it, and you restore it by creating a new server or disk from it.

Some providers store snapshots incrementally. On AWS, the first EBS snapshot of a volume is full and later ones hold only the blocks that changed, with the data kept in Amazon S3. Google Cloud works the same way. Provider "automated backups" are usually scheduled snapshots: DigitalOcean describes its backups as crash-consistent disk images.

Snapshots cover only the disks they are taken of. DigitalOcean notes that its automated backups do not include attached volumes; those need their own volume snapshots. Check the same thing on your provider.

What a backup is

A backup here means a file-level or logical copy: a tar archive of /srv/app and /etc, or a database dump from pg_dump, mysqldump or mongodump. It contains only what you chose, in an ordinary file format, and it can go anywhere: an object storage bucket at another company, a cloud drive, another server.

That portability is the point. You can restore a tar archive on any Linux server at any provider. PostgreSQL's docs note that pg_dump output can be loaded into newer PostgreSQL versions, which makes a dump useful for upgrades as well as recovery. A snapshot only restores inside the provider and account that made it.

Crash-consistent vs application-consistent

A crash-consistent snapshot captures the disk as it would be if the power were cut. AWS says an EBS snapshot "does not include data that has been cached by applications or the operating system", and Google Cloud says a crash-consistent snapshot might not capture writes still in transit from memory. Most provider snapshots are crash-consistent unless you do more.

An application-consistent snapshot is taken after the applications flush their data and pause writes. On Windows that is VSS. On Linux it means pre- and post-snapshot scripts that freeze the file system and quiesce the database, which Google Cloud and Azure both document. Azure adds a middle level, file-system consistent, where all files are captured at the same moment but apps must fix up their own data.

Databases with a write-ahead log handle crash-consistent snapshots better than you might expect. PostgreSQL's docs say a server started from a frozen snapshot "will think the previous server instance crashed and will replay the WAL log", and that this is not a problem. The catch: if the data files and WAL are on different disks, the snapshots of both must be exactly simultaneous. Separate snapshots of each disk are not, so keep data and WAL on one disk or use your provider's multi-volume snapshot feature if it has one.

The simple way to get an application-consistent copy into every snapshot is to dump the database just before it:

sudo -u postgres pg_dump -Fc appdb > /var/backups/appdb-pre-snapshot.dump

Where they live, and the same-account risk

Snapshots live with the provider, in your account. DigitalOcean puts it plainly: snapshots are saved to your account, and it also backs them up offsite for resiliency. That protects against the provider's hardware failing. It does not help if you lose the account.

Whoever controls the account controls every snapshot in it. A suspended account, an unpaid invoice, a leaked API token or a mistaken project deletion can take the server and all its snapshots together. A backup in a bucket at another company, under different credentials, survives each of those. This is the off-site part of the 3-2-1 rule.

Granularity, speed and cost

Granularity. A snapshot restores a whole disk. To get one file back, you create a disk or server from the snapshot, mount it, copy the file and delete the rest. A backup restores one file, one directory or one database directly.

Speed. For a whole server, a snapshot wins: you get the same OS, packages and configuration in one step. It is not always full speed straight away. AWS notes that a volume created from a snapshot downloads its blocks from S3 as they are first read, so it can be slower until it is fully initialized. Rebuilding from file backups means installing the OS and software first, which is slower unless you script it.

Cost. Providers charge for snapshot storage per GB per month. Incremental snapshots keep that down when little changes; AWS bills an EBS snapshot by the data written, not the size of the volume. Backups are billed per GB per month by whoever stores them. Dumps and archives leave out the OS and compress well, so they are often much smaller than the disk image.

Frequency limits. Snapshots have them. Google Cloud allows at most 6 snapshots of a disk every 60 minutes. Database dumps can run as often as the database can handle.

Comparison table

When snapshots are enough, and when they are not

Snapshots alone are enough when the server holds nothing you cannot rebuild: a stateless app server whose code is in git and whose data is in a managed database, a build runner, a test machine. A snapshot before an OS upgrade or risky change is also all you need for a quick rollback.

You need file or database backups as well when any of these is true:

• The server runs a database, or stores uploads or other data you cannot recreate.
• You will want to restore a single file, table or row without rolling back everything else.
• You need a copy that survives losing the provider account.
• You want months of history at low cost, or a way to move to another provider.

A recommended combination for a typical VPS

For a VPS running a web app and a database, use both, each for what it does best:

Send the dumps and file backups to storage at a different company from your server, with versioning or Object Lock turned on, and check them with a restore drill before you need them.

Frequently asked questions

Is a snapshot a backup?

It is a copy, so it protects against disk failure and many mistakes. It is not an independent backup: it sits in the same account at the same provider and is lost with the account.

Are my provider's automated backups snapshots?

Usually, yes. They are scheduled disk images stored in your account, so they have the same strengths and the same account risk as manual snapshots.

Can I restore a single file from a snapshot?

Yes, indirectly. Create a disk or a temporary server from the snapshot, mount it, copy the file out and delete the temporary resources. A file backup lets you skip those steps.

Do I need to stop the server before taking a snapshot?

Not usually. A running snapshot is crash-consistent, which databases with a write-ahead log can recover from. For a clean database copy, dump the database just before the snapshot. AWS recommends stopping an instance before snapshotting its root volume when you can.

Can I move a snapshot to another cloud provider?

Not directly in most cases. Snapshots restore inside the provider that made them. File and database backups are the portable copy.