Hetzner offsite backup: a Storage Box is not outside Hetzner

Search for "hetzner offsite backup" and the most common answer is "use a Storage Box." It is a reasonable answer to a different question. A Storage Box is off the server. It is not off Hetzner, and it is not outside the account that also holds the server, the snapshots and the backups. This article is about the difference, what Hetzner's three built-in options are each good at, and what it takes to hold one copy that would survive losing the account.

What "offsite" means when the failure domain is the account

The 3-2-1 rule is old and still right: three copies of your data, on two different media, one of them offsite. The word that does the work is "offsite," and it has always meant "in a different failure domain." When the failure domain was a building, offsite meant a different building. In a cloud account the building is not the interesting boundary; a fire is not the likeliest way to lose everything at once.

The likeliest way is the account. Locked for a missed invoice, closed after an abuse complaint you did not see, terminated with 30 days' notice and no reason, taken over by someone who got into the email address. Each has happened to Hetzner customers in public; the cases are collected in Hetzner account locked: what actually happens to your data. The short version: when Kiwix's account was terminated in December 2024, every server was wiped at midnight, and the only reason the project came back within two days was a copy at a different provider.

So the question to ask of any backup is not "is it on a different disk" but "does it survive me losing the login." Applied to Hetzner's own tools, the answer is no three times.

Hetzner's three built-ins, compared honestly

All three are good products. None of them is an offsite copy in the sense above.

Backups

Hetzner Cloud Backups are automatic daily copies of the server's disk. There are seven slots per server, so you get a rolling week. The price is a flat 20 percent of the server's monthly price, per the billing FAQ: "We will bill you for Backups with a monthly flat price, which is 20% of the price of the server you activate them for."

The limit is the coupling. The backups and snapshots FAQ states: "Backups are bound to a single server and will automatically be deleted if you delete the server." If you want to keep one, you convert it into a snapshot first.

Best at: finding out on Wednesday that Monday's deploy corrupted something. Cheap, automatic, restored with a click.

Snapshots

A Snapshot is a manual copy of the disk that "is saved until you decide to delete" it and is "never deleted or updated automatically." The default limit is 30 snapshots across all projects in the account, not per server. Billing is per gigabyte of compressed size per month, roughly €0.014 per GB at the time of writing, so a small server's snapshot costs cents.

Snapshots outlive the server: "Your Snapshots will be saved and remain available even if you delete the server a Snapshot was taken of." What they cannot do is leave. There is no download or export endpoint in the API, and the request to add one to the CLI was closed as not planned. We wrote up the alternatives in Can you download a Hetzner Cloud snapshot?. Snapshots have also been lost while the account was healthy: in April 2022 a cluster failure in Nuremberg destroyed a set of customer snapshots permanently.

Best at: the point-in-time copy before a risky change, a template for new servers, and rolling back within Hetzner. If you want snapshots taken and pruned on a schedule, that is a solved problem; hetsnap.com does exactly that and nothing else.

Neither backups nor snapshots include volumes. Hetzner's own words, from the volumes documentation: "we do not provide Backups or Snapshots for Volumes." Anything on a volume needs its own path in every plan below; see Hetzner snapshots do not include volumes.

Storage Box

A Storage Box is a large, cheap network share, starting at 1 TB, reachable over SFTP, SCP, rsync over SSH, Samba, WebDAV, and with first-class support for BorgBackup, restic and rclone. As a target for nightly file-level backups it is hard to beat on price, and it is on different hardware from your Cloud servers.

It is also a product on the same Hetzner account, billed on the same invoice, administered through the same Console login. A payment lock, an account closure or a compromised login reaches the Storage Box exactly as it reaches the server. That is not a criticism of the product; Hetzner never described a Storage Box as offsite. The forum answers did.

Best at: cheap, high-retention file backups with Borg or restic, as the second copy in a 3-2-1 plan. Not the third.

Options for a copy outside the account

RPO is how much you can lose; restore effort is how long until you are serving traffic again on a machine that is not at Hetzner. Costs are rough, at the time of writing.

A few notes the table cannot hold.

File-level backups are the right first offsite copy for almost everyone. They are cheap, incremental and encrypted, and both tools have years of production use. The catch is the restore: you are rebuilding a machine, not booting one, and the time is dominated by everything you did not think to back up. Package lists, the exact nginx configuration, the firewall rules. People who test their file-level restore usually add three or four paths to the include list afterwards.

Database dumps are not optional even when you have an image. Snapshots and images are crash-consistent, not application-consistent. A dump taken by the database itself is the only copy that is guaranteed to be internally coherent. Keep both.

A whole-server image is the fastest restore and the slowest to take. Its RPO is whenever you last took it, which makes it a poor primary backup and a good exit copy: the thing you use when the account is gone and you need to be running elsewhere this afternoon.

A layered recommendation for a typical small setup

For one to five Cloud servers running a web application with a database, a plan that survives a datacenter, a bad deploy and the account looks like this.

1. Snapshot before every deploy or upgrade. Pruned so you stay under the 30-snapshot account limit. This is your rollback, and it is what snapshots are for.
2. Nightly file-level backup to object storage outside Hetzner. restic or Borg, encrypted client-side, to a bucket or repository billed to a different company on a different login. Include the application data, the configuration directories, a dpkg --get-selections or equivalent, and a database dump taken immediately before the backup run. Retention: daily for two weeks, weekly for a few months.
3. A whole-server image at a low cadence. Monthly, or before and after large changes, stored next to the file backups. This is the copy that boots on a Proxmox box when the login no longer works, and the one an auditor accepts as an offsite full backup with a date on it. Volumes are outside it; back them up in step 2.
4. Keep the account boring. Two-factor authentication, a recovery email on a domain not hosted at Hetzner, invoices paid by a method that will not expire, and a second person who receives the billing and abuse mail.

Hetzner's built-in Backups fit in as an optional layer between 1 and 2 if 20 percent of the server price is worth a week of automatic daily copies to you.

How to test a restore

A backup that has not been restored is a hope. The test does not have to be dramatic, but it has to be real, meaning the restored system serves a request that the original would have served.

For the file-level copy: create a fresh VM anywhere that is not your Hetzner account. Install the OS from scratch. Restore from restic or Borg using only the credentials in your password manager, not the ones on the server you are supposedly protecting. Start the application. Note every step that made you go back to the live server to look something up; each one is a gap in the backup or in the runbook, and write the time down.

For the database: restore the newest dump into an empty database on the test machine and run the one query that would tell you the data is current. A dump that restores cleanly but is three weeks old is a monitoring failure, not a backup success.

For the whole-server image: decompress it and boot it under QEMU, VirtualBox or Proxmox with the firmware type the server actually used. Modern Hetzner x86 images boot through UEFI, and a BIOS VM will fail to boot a UEFI disk in a way that looks exactly like a corrupt download. Expect the first boot to come up without network, because the image still carries Hetzner's static address and gateway; that is normal and is covered in the Proxmox migration guide. Once the network is fixed, log in and check that the newest data you expect is there.

Put the test on a calendar; quarterly is realistic for a small team.

Where a whole-server export fits

Everything above works without any paid tool, and the file-level layer should exist regardless. The whole-server layer is the one people skip, because taking an image of a running Hetzner server by hand means either downtime in the rescue system or a snapshot, a throwaway clone and a pipeline you have to get right. That is the part hetshield does for you: it snapshots the running server, clones it, reads the disk block by block from the rescue system and streams it compressed out of Hetzner, then removes what it created. You receive a bootable raw image and a restore guide for your hypervisor, at $29 per export, any size, refunded if the run does not finish. The documentation lists exactly what is in the image, what is not, and every API call made in your project.

Use it, or use the manual method, or use neither and keep a tested file-level restore. What matters is that at least one copy of your server exists somewhere that does not stop existing when the Hetzner account does.