Hetzner backups vs snapshots vs independent off-site backups

Hetzner Cloud Backups and Snapshots are both disk images, but they are not interchangeable. Backups trade manual control for automatic daily creation and a rotating set of recovery points. Snapshots are created when you ask for them and remain until you delete them. An independent off-site backup is different again: it copies selected data into storage outside the server's Hetzner project, ideally under separate credentials and sometimes with a separate provider.

The right question is not which option is universally best. It is which failure you are trying to reverse. A failed operating-system upgrade, a deleted server, a damaged database, and a compromised cloud account have different recovery requirements. A useful design assigns each layer a specific job and does not count three copies inside one administrative boundary as three independent protections.

Compare the options by recovery behavior rather than by the word backup. The details below reflect Hetzner's published Cloud documentation as of July 29, 2026; recheck the provider documentation before relying on limits or location behavior for a new design.

• Hetzner Cloud Backups: automatic daily disk copies, seven rotating slots per server, useful for recent whole-server rollback.
• Hetzner Snapshots: manual disk copies retained until deletion, useful before a risky change, for a long-lived reference image, or for creating another server.
• Independent off-site backups: scheduled copies of chosen files, configuration, and database-aware artifacts to storage with a separate failure and access boundary.
• Attached Volumes: not included in Hetzner Cloud Backups or Snapshots, so they require their own protection plan.
• Database state: a powered-off disk image has stronger consistency than an image of a busy running server, while a database-aware backup can create a recovery artifact through the database engine itself.

Automatic creation is the main advantage. Once enabled, Cloud Backups produce daily copies without depending on a script inside the guest. That makes them valuable when an in-guest scheduler is disabled, the filesystem becomes unbootable, or an operating-system change needs to be reversed. The seven-slot rotation gives several recent disk states without someone remembering to take them.

Their natural recovery unit is the server disk. Hetzner lets you rebuild a server from an image or create a new server from it. Rebuilding is direct but destructive: data written after the selected backup is not preserved. Creating a separate server is usually easier to inspect because the old and recovered systems can coexist while you decide what to copy or switch over.

There are important boundaries. Hetzner states that Backups are bound to the server and are deleted when that server is deleted. They cannot be protected from deletion in the same way as Snapshots. Seven rotating slots also mean they provide a short, fixed history rather than an archive. Most importantly, an attached Hetzner Volume is outside the image. A server can therefore appear protected while its largest or most valuable data disk is not represented at all.

A Snapshot is a manual checkpoint. It is well suited to a planned migration, a major package upgrade, or preserving a known configuration before a change. Unlike a Backup, a Snapshot remains after the source server is deleted. Hetzner also offers deletion protection for Snapshots, which adds a guard against an ordinary accidental delete. That protection is an operational safeguard, not immutability: an authorized operator can disable it and then remove the Snapshot.

Snapshots give you control over timing, but that control creates an ownership problem. A manual checkpoint quietly ages if nobody is responsible for replacing it. It may be a perfect image of a server from six months ago and still be a poor answer to yesterday's data loss. Record why each Snapshot exists, when it can be deleted, and which automated process protects the changing application data between Snapshots.

Location behavior helps with some infrastructure failures but should be read precisely. Hetzner documents that Snapshots are generally stored in a different location within the same network zone, with exceptions for locations such as Ashburn, Hillsboro, and Singapore. Cloud Backups remain in the same location as the server, usually in a different data center where the location has more than one. Neither statement turns the copy into an independent provider or account boundary.

An independent backup starts with a different threat model. The repository can live in another provider account, use credentials that are not available to ordinary Hetzner administrators, and retain history on a schedule chosen from recovery needs rather than image-slot limits. It can also include data from attached Volumes because the backup selection happens inside the operating system or application layer.

This layer is usually better for selective recovery. Restoring one configuration file, one uploads directory, or one database artifact does not require creating an entire replacement VM. Client-side encryption can keep the storage operator from reading the contents, while checks and restore rehearsals provide evidence that the repository is usable. The trade-off is that somebody must operate the schedule, credentials, monitoring, retention, and recovery documentation.

Independence should be tested, not assumed. A bucket in a separate service but controlled by the same compromised email account may share more risk than the architecture diagram suggests. Review identity recovery, multifactor authentication, billing failure, deletion permissions, encryption-key custody, and whether a responder can reach the repository when the Hetzner project is unavailable.

Hetzner recommends powering a server off before a Backup or Snapshot to ensure disk consistency and says consistency cannot be guaranteed for an image taken while the server is running. This distinction matters most for databases. A disk image captures blocks; it does not ask PostgreSQL, MySQL, or another engine to produce a logically consistent export or coordinate files spread across several devices.

A cold image can be a valid physical recovery point when the database has stopped cleanly and every required file is included. A carefully coordinated filesystem snapshot can also be valid for some engines. But an ordinary live server image should be treated as crash-consistent: recovery may depend on journal or transaction-log replay, and application validation is still required. If database files or logs sit on an attached Volume, the server image alone is incomplete.

Use a database-aware logical or physical backup when you need portable recovery, database-level selection, or a documented path supported by the engine. Keep the server image as a fast way to reconstruct the surrounding operating system. The two layers complement each other rather than competing for the same job.

Write down the intended answer for each workload before buying or enabling another copy. A checklist exposes gaps that product labels tend to hide.

• Recovery point: how much recent work may be lost, and does a daily image meet that limit?
• Recovery unit: do you normally need a whole VM, an attached Volume, a directory, or one database?
• Consistency: can the workload be stopped, or does it require an application-aware online backup?
• History: are seven recent images enough to cover delayed discovery of corruption or deletion?
• Administrative independence: can the same account, API token, or project action delete both production and its recovery copies?
• Location independence: which site and provider failures does each copy actually survive?
• Recovery access: can another operator obtain credentials and encryption material without the failed server?
• Proof: when was each recovery path last rehearsed, and how long did it take?

For many small production servers, a sensible baseline is automatic Hetzner Cloud Backups for convenient recent whole-server rollback, a Snapshot before a high-risk infrastructure change, and an encrypted independent backup for application data and database-aware artifacts. That is not a universal prescription: a stateless web node may need only a reproducible image, while a high-write database may need continuous log archiving and a much tighter recovery-point objective.

Avoid counting copies without testing their boundaries. A Backup and Snapshot that omit the same attached Volume share a data gap. Two images controlled through the same project share an account risk. An independent repository whose password exists only on the failed VM shares a recovery-access risk. The strongest plan is the one whose assumptions have been written down and exercised from a clean recovery environment.