Cloud providers keep hardware running. They do not keep your data safe from a bad migration, a deleted volume, a compromised key or a mistaken terraform destroy. Backups are the account holder’s job, and the difference between a scare and a catastrophe is usually whether anyone tested a restore. This baseline is the minimum a production workload should have, described in terms that apply on IBM Cloud, Hetzner or any other provider.
Start with two numbers
Before choosing tools, write down two recovery objectives for each system. The recovery point objective (RPO) is how much data you can afford to lose, measured in time: an hour, a day. The recovery time objective (RTO) is how long the system can be down while you restore. A marketing site might accept a day of lost changes and a few hours of downtime. A billing database might accept minutes of each.
These numbers decide everything else. A one-hour RPO means hourly backups or continuous replication; a daily snapshot will not do. A short RTO means the restore must be scripted and rehearsed, not improvised.
Snapshots are not backups on their own
Provider snapshots are the fastest way to capture a server. Hetzner offers snapshots and scheduled backups for cloud instances; IBM Cloud provides snapshots and images for Virtual Servers for VPC. Both are essential and both have the same weakness: a snapshot lives in the same account, under the same credentials, in the same provider. Anything that deletes the account, or an attacker with the root key, takes the snapshots with it.
| Method | Protects against | Does not protect against |
|---|---|---|
| Provider snapshot | Bad deploy, disk corruption, config mistake | Account loss, credential compromise |
| Application-level backup (database dump) | Logical corruption, partial restores | Nothing else on the server |
| Off-account copy | Account loss, ransomware, provider issue | Slow to restore if not rehearsed |
A baseline uses all three layers.
The three-layer baseline
Layer 1: scheduled snapshots
Turn on the provider’s scheduled snapshot or backup feature for every stateful server. Keep enough history to cover the time it takes to notice a problem, typically a week of dailies plus a few weeklies.
Layer 2: application-level backups
Dump databases with their native tools and copy the dumps to object storage. Database dumps restore cleanly across instance sizes and even providers, which a block snapshot cannot. Encrypt them before upload.
Layer 3: an off-account copy
Copy the application-level backups to a second account or a second provider that the primary account’s credentials cannot reach. A small object storage bucket on a different provider is enough. This is the layer that survives a compromised root key, and it is the one most teams skip. The account recovery article explains why account-level loss is the scenario to design for.
Test the restore, not the backup
A backup job that succeeds every night proves only that files are being written. Schedule a restore test: monthly for critical systems, quarterly for the rest. Restore into a fresh server, run the application against it, and time the whole process against the RTO. Write down what broke; something always does the first time.
- Restore to a new instance, never over production.
- Verify data with an application check, not just a file listing.
- Record the elapsed time and compare with the RTO.
- Rotate any credentials used in the test afterward.
Where the listed accounts fit
Hetzner’s snapshot and backup features cover layer one on cloud instances, and the Hetzner 5 Server Limits Account listed on the marketplace leaves a server slot free for restore tests. IBM Cloud’s Object Storage is a natural home for layers two and three; the IBM $200 Credit Account listing is one way to keep an off-account copy on a separate provider. Whichever pairing you use, keep the two accounts under separate credentials so one compromise cannot reach both. The storage options guide compares block, object and backup storage for this purpose.
The baseline in one list
- Write an RPO and RTO for every stateful system.
- Enable scheduled provider snapshots with a week or more of retention.
- Dump databases nightly, encrypt, and store in object storage.
- Copy dumps to an off-account location with separate credentials.
- Restore-test monthly or quarterly and record the time.
- Review retention and objectives when the system changes.
