Hetzner backups vs snapshots vs independent off-site backups

Use Hetzner Cloud Backups for automated recent server-disk recovery, take a Hetzner Snapshot before a deliberate high-risk change, and keep an independent off-site backup for the application data and database artifacts you cannot afford to lose with the server or project. These are complementary layers, not substitutes.

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, where the risk warrants it, with a separate provider.

Start with the failure you need to reverse. A failed operating-system upgrade, deleted server, damaged database, deleted uploads directory, and compromised cloud account all need different recovery paths. Three copies inside one administrative boundary are not three independent protections. For a broader inventory of recoverable Linux state, see [what to back up on a Linux server](/blog/what-to-back-up-linux-server).

There is no universal winner. The best default for many small production servers is a layered design: automatic Cloud Backups for convenient recent rollback, a Snapshot before planned infrastructure changes, and an independent backup for application-aware recovery. The lower-operational-effort option is Cloud Backups alone, but it has important coverage and independence limits. The higher-resilience option adds separately controlled storage, tested recovery access, and database-aware artifacts.

Provider behavior, supported server types, locations, billing, and limits can change. Confirm the current details in Hetzner's official [Backups and Snapshots overview](https://docs.hetzner.com/cloud/servers/backups-snapshots/overview/) and [FAQ](https://docs.hetzner.com/cloud/servers/backups-snapshots/faq/) before making a recovery commitment.

• Cloud Backups: automatic daily server-disk copies with seven rotating recovery slots per server; best for recent whole-server rollback without relying on an in-guest scheduler.
• Snapshots: manually created server-disk copies retained until deletion; best as a checkpoint before a migration, major package upgrade, or other intentional change.
• Independent off-site backups: scheduled copies of selected files, configuration, and database-aware artifacts to separately controlled storage; best for selective restores and reducing shared project or account risk.
• Attached Volumes: Hetzner Cloud Backups and Snapshots do not include them, so Volume data requires its own protection and restore procedure.
• Costs: evaluate provider image charges separately from independent backup software, object-storage capacity, retrieval or egress charges, and the operator time required to monitor and rehearse restores. Do not choose solely on the price of the stored copy.

Automatic creation is the main advantage. Once enabled, Cloud Backups produce daily copies without depending on a script inside the guest. That is useful when an in-guest scheduler fails, the filesystem becomes unbootable, or you need to reverse an operating-system change. The seven-slot rotation provides several recent disk states without someone remembering to create each recovery point.

The natural recovery unit is the server disk. You can rebuild a server from an image or create a separate server from it. Rebuilding is direct but destructive: data written after the selected recovery point is not preserved. Creating a separate server is often the safer first move because the original and recovered systems can coexist while you inspect data, validate services, and decide what to copy or switch over.

Do not mistake automation for complete coverage. Hetzner documents that Cloud Backups are bound to the server and are deleted when that server is deleted. They also do not include attached Volumes. The fixed seven-slot rotation is short operational history, not a long-term archive. If your service stores uploads, database files, or logs on an attached Volume, a green server backup can still leave the important data absent.

• Good fit: a recent whole-server recovery point for a mostly self-contained Linux server.
• Failure mode: the server is deleted, the needed recovery point has rotated out, or the required data was on an attached Volume.
• Safer restore practice: create a separate recovery server first when time permits, inspect mounts and service configuration, then test the application before replacing production.

A Snapshot is a manual checkpoint. It is well suited to a planned migration, major package upgrade, configuration change, or preserving a known-good server state before work begins. Unlike a Backup, a Snapshot remains after the source server is deleted. Hetzner also offers deletion protection for Snapshots, which can help prevent an ordinary accidental delete. It is not immutability: an authorized operator can remove that protection and delete the Snapshot.

Manual timing is useful precisely because it is deliberate, but it also creates a maintenance obligation. A Snapshot can be an accurate image of a six-month-old system and still be a poor answer to yesterday's data loss. Record why each Snapshot exists, its owner, the change it protects, and the date it can be retired. Keep an automated process protecting the changing application data between snapshots.

Hetzner documents location behavior for these images, including location-specific exceptions. Read that behavior as infrastructure resilience within Hetzner's documented design, not as a separate-provider or separate-account recovery boundary. A Snapshot remains controlled through the Hetzner project.

• Take one immediately before a change whose fastest rollback is restoring the complete server disk.
• Write the rollback decision in the change plan: restore the Snapshot, create a separate server for inspection, or repair forward.
• Do not use a pre-change Snapshot as the only protection for live data that continues changing after the checkpoint.

An independent backup addresses a different threat model. Its repository can be placed in separately controlled object storage, protected by credentials that ordinary Hetzner administrators do not hold, and retained according to recovery requirements instead of image-slot limits. Because selection happens in the operating system or application layer, the backup can include needed data from attached Volumes as well as server-root paths.

This approach is usually better for selective recovery. You can restore one configuration file, one uploads directory, or a database artifact without first recreating an entire VM. Client-side encryption can protect backup contents from the storage operator, but it does not remove the need to protect storage access, the repository password or recovery key, and recovery documentation. A repository check is useful evidence of repository integrity; an isolated restore and application smoke test are the evidence that matters for usable recovery. See [why a successful backup can still be unrecoverable](/blog/successful-backup-still-unrecoverable) for the distinction.

For small teams, [Rested Backups](https://restedbackups.com) can make encrypted restic schedules, run outcomes, snapshots, and restore work visible in one workspace while the team retains responsibility for its storage account, permissions, recovery key, scope, and restore testing. It is useful operational visibility, not a substitute for designing and rehearsing the recovery path.

Test independence rather than assuming it. A bucket at another 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 or production server is unavailable.

• Best default: back up application files, protected configuration, and database-aware artifacts on a schedule derived from your recovery point objective (RPO), the maximum data loss you can accept.
• Lower-cost pattern: use a controlled object-storage repository with a simple documented restore procedure, while accepting more operator responsibility.
• Higher-resilience pattern: separate production and backup credentials, preserve recovery information outside the production server, and test restoration from a clean environment.

Do not assume a running-server image is a database backup. Hetzner recommends powering a server off before creating a Backup or Snapshot to ensure disk consistency and does not guarantee consistency for an image taken while the server is running. A disk image captures blocks; it does not ask PostgreSQL, MySQL, or another database engine to prepare a supported recovery artifact.

A cold image can be a valid physical recovery point when the database has stopped cleanly and every required data and log file is included. A deliberately coordinated filesystem snapshot can also be valid for some engines. An ordinary live server image, however, should be treated as crash-consistent: recovery may depend on journal or transaction-log replay, and the database and application still need validation. If files or logs live 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 restore method documented by the engine. For PostgreSQL, [pg_dump vs pg_dumpall](/blog/pg-dump-vs-pg-dumpall) is an important scope decision, and PostgreSQL's official [backup and restore documentation](https://www.postgresql.org/docs/current/backup.html) explains the available approaches. Keep a server image for reconstructing the surrounding operating system; it complements, rather than replaces, database recovery artifacts.

• Before imaging a database server: identify every data directory, transaction-log location, mounted Volume, secrets file, and service dependency required to start it.
• Before relying on a logical export: restore it into an isolated database instance, run engine-level validation, and perform a minimal application query or smoke test.
• Failure signal: the VM boots but the database fails to start, replays logs indefinitely, lacks expected roles or extensions, or the application cannot authenticate or find its expected data.