VPS Backups vs Snapshots: What Actually Protects Your Data?
“Backup” and “snapshot” are often used as if they mean the same thing. They do not always provide the same schedule, retention, deletion behavior, consistency, or coverage. Before relying on either, read the provider’s exact rules and perform a restore test.
Snapshot, provider backup, and application backup
| Method | Typical purpose | Main limitation |
|---|---|---|
| Snapshot | Manual point-in-time server image before a risky change | May be crash-consistent rather than application-consistent; often needs manual lifecycle management. |
| Provider backup | Automated server-image recovery with a stated retention window | May be tied to the server and may omit attached volumes. |
| Application backup | Consistent export of databases, uploads, configuration, and keys | You must design, encrypt, monitor, and test it. |
Read the product-specific fine print
Hetzner documents a concrete example: Cloud backups are daily disk copies with seven slots, and the oldest is removed when the slots are full. Those backups are bound to the server and are deleted when the server is deleted. Snapshots are created by the customer and remain until deleted. Hetzner also states that attached Volumes are not included in Cloud backups or snapshots.
The same documentation recommends powering off the server for disk consistency when creating a backup or snapshot. A running image may restore to a filesystem that starts, but a database can still need recovery or contain incomplete transactions. For important databases, use the database’s supported dump or backup mechanism in addition to an image.
Use the 3-2-1 principle as a target
A useful target is three copies of important data, stored on two different types of systems, with one copy outside the failure domain of the production server. A provider snapshot stored inside the same account is convenient, but account compromise, accidental project deletion, or a billing problem can affect both production and recovery copies.
An independent backup can be an encrypted archive in object storage under a separate account, a second provider, or an offline copy. Choose a retention period that covers both fast operational mistakes and slower discoveries such as corrupted data that went unnoticed for weeks.
A minimum backup checklist
- Identify every data location: server disk, attached volumes, databases, object storage, DNS, and secrets.
- Automate application-consistent database and file backups.
- Keep at least one encrypted copy outside the production server’s account or failure domain.
- Alert when a scheduled backup is missing or unusually small.
- Protect snapshots from accidental deletion if the provider offers that feature.
- Document the restore order and required credentials.
- Test a full restore on a separate server at a regular interval.
Backups are only useful after a successful restore
A dashboard showing green backup jobs is not enough. Create a temporary recovery server, restore the data, verify the application, and record how long it takes. This reveals missing environment files, expired credentials, DNS assumptions, or volumes that were never included.
If you find an inaccurate statement in this guide, use our contact form. Our sourcing and correction standards are described in the Editorial Policy.
Sources checked
Last checked: July 16, 2026. Backup behavior is provider- and product-specific.