A Simple Cloud Backup Strategy: Snapshots, Object Storage, and Retention
A three-layer backup strategy for cloud servers: provider snapshots for fast rebuilds, application-level dumps in S3-compatible object storage, an off-site copy at a second provider, and a retention policy you can afford.
Cloud providers keep your servers running, but they do not keep your data safe from you. A bad deploy, a deleted volume, a compromised key, or a mistyped command destroys data just as effectively on a cloud server as on a laptop, and provider snapshots alone are not a backup strategy. This guide lays out a simple, affordable approach that works on Hetzner, Vultr, Kamatera, and any other provider: server snapshots for fast recovery, application-level backups in object storage for durability, and a retention policy that keeps the right copies without paying to keep everything forever.
Three layers, three jobs
A workable backup strategy has three layers, and each does something the others cannot.
- Snapshots
- Whole-server images taken by the provider; fastest way to rebuild a machine
- Application backups
- Database dumps and file archives you create; restorable anywhere
- Off-site copy
- The same backups in a bucket at a different provider or region; survives an account problem
Snapshots are convenient but live inside the same account and often the same location as the server. Application backups are portable but slower to restore. The off-site copy covers the failure mode people forget: losing access to the account itself.
Layer one: provider snapshots and automated backups
Every provider in this category offers two related features. A snapshot is a manual, point-in-time image of a server or volume that you create and delete yourself. An automated backup is a scheduled snapshot the provider takes on a fixed rotation, usually for a percentage surcharge on the server price.
Hetzner Cloud offers both: Backups are enabled per server, taken daily, and kept in a rotation of the most recent copies; Snapshots are on-demand and billed per gigabyte for as long as they exist. Hetzner Volumes can also be snapshotted separately. Vultr provides Automatic Backups as an add-on per instance with daily, alternate-day, weekly, or monthly schedules, and manual Snapshots stored per gigabyte. Kamatera offers a daily backup service as a paid option per server plus manual server images you can clone from. Pricing and rotation counts are set by each provider and change; check the current console.
Snapshots are the right tool for rebuilding a server to a known state after a bad update or a broken configuration. They are the wrong tool as the only copy of a database, for two reasons. First, a snapshot of a running database can be inconsistent unless the database was paused or the filesystem frozen. Second, the snapshot lives in the same account as the server; if the account is suspended, compromised, or closed, the snapshot goes with it.
Layer two: application-level backups to object storage
The durable layer is a backup you create at the application level and store as an object. For a database that means a logical dump: pg_dump for PostgreSQL, mysqldump or a Percona XtraBackup archive for MySQL and MariaDB, mongodump for MongoDB, and the RDB or AOF files for Redis. For files it means a compressed archive of the directories that matter, or better, an incremental tool such as restic, borgbackup, or rclone that deduplicates and encrypts before upload.
Send the result to an S3-compatible bucket. Hetzner Object Storage, Vultr Object Storage, DigitalOcean Spaces, Linode Object Storage, Backblaze B2, and Amazon S3 all speak the same API, so a single script or restic repository configuration works across them with a change of endpoint and credentials. Create a dedicated access key for the backup job with write permission to that bucket only, and store it on the server in a file readable only by the backup user.
- Schedule the job with cron or a systemd timer at a quiet hour.
- Dump the database to a temporary location, then archive files.
- Encrypt the archive if the tool does not do it for you.
- Upload to the bucket under a path that includes the hostname and date.
- Log the result and send an alert on failure. A backup job that fails silently for six months is the same as no backup.
Layer three: an off-site copy at a second provider
The third layer is the same backups replicated to a bucket that the first account cannot reach. A second provider is the cleanest separation: a Hetzner server backing up to Vultr Object Storage, or a Kamatera server backing up to Hetzner Object Storage, means no single account holds both the data and its only backup. A second region at the same provider is a weaker but still useful choice if a second account is impractical.
rclone can sync one bucket to another on a schedule, and restic supports multiple repositories from one host. Use a separate access key for the second destination, and keep that key off the production server if you can by running the replication from a small independent machine. The goal is that a full compromise of the production account does not give the attacker every copy.
Retention: how many copies to keep
Keeping every backup forever is expensive and rarely useful. A grandfather-father-son rotation covers most needs: several recent daily copies for quick rollback, a few weekly copies for problems noticed late, and monthly copies for compliance or long-term reference. Tools such as restic and borgbackup apply this kind of policy with a single forget command; on a plain bucket, lifecycle rules can delete objects older than a set number of days or move them to a cheaper storage class.
| Copy type | Where it lives | Suggested retention | Recovers from |
|---|---|---|---|
| Provider backup or snapshot | Same account and location as the server | The provider’s rotation, plus one manual snapshot before risky changes | Broken deploys, bad OS updates |
| Daily application backup | Bucket at the same provider | Recent days | Data corruption, accidental deletion |
| Weekly and monthly copies | Bucket at the same provider | Weeks to months, per your compliance needs | Problems discovered late |
| Off-site replica | Bucket at a second provider or region | Mirrors the above | Account loss, ransomware, provider incident |
Set the retention numbers from two questions: how far back would you ever need to go, and how much are you willing to pay per month to keep that option.
Test the restore, not the backup
A backup only exists once you have restored from it. Schedule a restore test: create a fresh server from a snapshot and confirm it boots and serves traffic; pull the latest database dump into an empty instance and run the application against it; restore a random file from the off-site bucket. Time each restore and write the steps down, because the person doing it during an outage will be under pressure. Repeat the test whenever the application, the database version, or the backup tool changes.
Finally, keep the backup credentials and the restore procedure somewhere that survives losing the server and the account, such as a password manager shared with a second person. A backup nobody else can find or decrypt protects only as long as you are available.
Where to go next
Providers with snapshot, automated backup, and object storage features that fit this strategy are listed on the Buy Hetzner Accounts page, the Buy Vultr Account page, and the Buy Kamatera Accounts page. Server limits on those labels restate the account’s current ceiling; backup features are standard on each platform.
Related reading in the Cloud Library:
- Object storage vs block storage: which one does your app need?
- API keys and secrets management in the cloud
- Securing a VPS: firewalls, Fail2ban, and automatic updates
Browse every guide in the Cloud Library.