Cloud Backup Strategies: Snapshots, Images and Off-Site Copies
Snapshots protect against the failure your provider already handles. This guide sorts cloud backup layers by the disaster each one actually answers, from crash-consistent volume snapshots to encrypted off-site repositories, then shows how to prove a restore works before you need it.
Four Failures, Not One
Backups get designed for the wrong disaster. Most people picture a dead disk, which is the failure cloud providers already handle for you through replication. The failures that actually destroy data look different.
The first is human error: a migration that drops the wrong table, a deploy script that wipes an upload directory. The second is malicious action, where an attacker with valid credentials deletes what they find. The third is silent corruption, discovered weeks after it started. The fourth is losing access to the account itself.
A backup strategy is only meaningful against a named list of failures. Write yours down, then check each layer below against it. If the copy would be deleted by the same credentials, or corrupted by the same bug, it does not count.
Volume Snapshots: Fast, Convenient, Not Enough
A snapshot captures a block volume at a point in time. Providers implement them incrementally, so the first one copies everything and later ones store only changed blocks while still restoring as a complete volume. Amazon EBS snapshots, Azure disk snapshots, Google persistent disk snapshots, DigitalOcean and Hetzner volume snapshots all behave this way.
Restores are quick, because you create a new volume from the snapshot and attach it. That makes snapshots the right tool for rolling back a server before a risky upgrade, or for cloning production into a test environment.
Their weaknesses are specific. A snapshot of a running database is crash consistent rather than application consistent: it looks to the engine like the power was cut, which normally replays cleanly but is not a guarantee. Quiesce the filesystem or stop writes for the moment of capture where you can.
More importantly, snapshots usually live in the same account and region as the thing they protect. Anyone who can delete your instances can typically delete your snapshots, which answers failure two badly.
Machine Images and the Rebuild Path
An image captures a whole bootable machine rather than a data volume. AWS calls it an AMI, Azure has managed images and the compute gallery, Google has machine images, and most developer clouds simply call it a custom image.
Images answer a different question: how fast can I stand this server up again somewhere else. That is a useful thing to know, but a stale image is a trap, because it restores the configuration of the day it was taken and none of the changes since.
The better pattern is to make the image unnecessary. If the server is provisioned by cloud-init and configured by a repeatable tool, rebuilding is a matter of running the code again and restoring the data. The image then becomes a speed optimisation rather than the only route back.
The Copy That Lives Somewhere Else
This is the layer that answers the serious failures, and it is the one most small teams skip. The idea is simple: a file level backup, encrypted, written to storage that the production credentials cannot delete.
Tools such as restic and BorgBackup deduplicate and encrypt client side, then write to a remote repository. Targets include any S3-compatible bucket, SFTP, or a dedicated appliance like a Hetzner Storage Box, which speaks SSH, SFTP, Samba and WebDAV and supports Borg repositories directly. A nightly job might look like restic -r s3:https://s3.example-region.provider.com/acme-backups backup /srv /etc followed by a forget --prune pass that applies your retention policy.
Three details make the difference between a copy and a real off-site backup. Use credentials scoped to append and read only, so a compromised production server cannot erase history. Store the repository in a different provider or at least a different account. And keep the encryption passphrase somewhere other than the server being backed up.
Where the target supports it, enable object lock or an immutability policy on the bucket so objects cannot be removed before their retention window expires. The mechanics of that are covered in the object storage explainer.
Writing a Policy You Can Actually Follow
The familiar shorthand is three copies of the data, on two kinds of media or two platforms, with one of them off-site. Adapted to cloud infrastructure that usually means live data, a provider snapshot schedule, and an encrypted repository elsewhere.
Retention follows a tapering pattern so history stays useful without growing without bound. Something like this covers most small estates:
| Layer | Frequency | Keeps | Answers |
|---|---|---|---|
| Volume snapshot | Daily, automated by the provider | Recent dailies | Fast rollback of one server |
| Database dump with log shipping | Continuous or hourly | A defined recovery window | Precise point in time restore |
| Encrypted file repository | Nightly | Dailies, weeklies, monthlies | Deletion, ransomware, account loss |
| Config and infrastructure code | Every commit | Full history in version control | Rebuilding the environment |
Set the numbers yourself based on how much work you can afford to lose and how long a restore may take. Those two figures, the recovery point and the recovery time, are the only inputs that matter, and the database side of them is unpacked in the point-in-time recovery article.
Proving the Restore Works
A backup system has exactly one measurable output, and it is not the success message in the log. Schedule a restore drill on a recurring calendar entry and treat a failed drill as an incident.
A workable drill takes under an hour. Create a fresh server, run the provisioning code, restore the latest repository snapshot into it, restore the database to a chosen timestamp, and start the application against a copy of the data. Record how long each step took and what you had to look up.
The gaps that surface are always the same: a missing environment file that was never in the backup set, a database role that does not exist on the new host, a hard coded path, a TLS key nobody thought to copy. Fix them in the runbook while they are cheap.
Also monitor the jobs themselves. A backup that stopped running six weeks ago is worse than none, because it removes the discomfort that would have made you check. Alert on the absence of a success signal rather than on failure messages, and fold it into the wider practice described in the server monitoring guide.
Questions Worth Settling Early
Are provider automated backups enough on their own?
They are a good first layer and a poor last one. Automated backups on Vultr, Linode, DigitalOcean and Hetzner run on a schedule you choose and restore whole servers, but they sit inside the same account. Keep them, and add an independent encrypted copy for the failures that involve the account itself.
Where should the off-site copy live?
Somewhere with different credentials and ideally a different vendor. A Hetzner account is often used for the storage side because a Storage Box handles Borg and rsync targets natively, while compute runs elsewhere. A Vultr account serves the same purpose through S3-compatible object storage, and the Hetzner and Vultr comparison covers the wider differences.
How do I back up data that never stops changing?
Separate the two problems. Use the database engine's own mechanism for transactional data, since it can produce a consistent stream without pausing writes. Use file level backup for everything else, and accept that files written during the run may be captured mid-change unless you snapshot the filesystem first.
Should backups be encrypted if the provider already encrypts at rest?
Yes. Provider encryption protects the physical media and is transparent to anyone holding valid credentials. Client side encryption means the backup target holds bytes it cannot read, which is what you want from a copy stored outside your control. See the encryption guide for how the layers stack.
Keep reading
All articles
Database Backups and Point-in-Time Recovery
Point-in-time recovery shrinks acceptable data loss to seconds by separating a full base copy from a continuous log of changes.…
Object Storage Explained: S3, Blob, GCS and S3-Compatible Options
Object storage keeps whole files as immutable blobs addressed by key. This guide explains the bucket and key model, compares…
Monitoring Cloud Servers: Metrics, Logs and Alerts
Useful monitoring answers questions rather than filling a wall with graphs. This guide covers the three kinds of signal, what…
Questions about a cloud account?
Ask about products, variants, availability or purchasing on either channel.