The short version
Hetzner Cloud Backups and Snapshots copy the server disk. They do not include attached Volumes.
That single detail creates a dangerous false sense of safety for Minecraft operators who moved world data onto a Volume.
If your live world is on a Volume and you rely only on Cloud Backups or Snapshots, your restore plan is incomplete.
Why this matters for Minecraft
Minecraft world data changes constantly:
- chunk saves
- player data
- plugin or mod state
- region files
Many admins place ./data or the world directory on a separate Volume for storage flexibility.
That is operationally reasonable, but it changes what Hetzner infrastructure features can actually recover.
If the world lives on an attached Volume, a server-level Snapshot will not capture it.
What Hetzner documents
Hetzner's documentation makes three important points:
- Backups and Snapshots are copies of a server's disk
- Backups are created automatically once per day
- each server gets seven backup slots
Most importantly, Hetzner states that Backups and Snapshots do not include attached Volumes.
That is the line many Minecraft admins miss.
Typical failure scenario
A very common layout looks like this:
- OS and Docker on the main server disk
- Minecraft world data on an attached Volume
After an outage or bad update, the admin restores a Snapshot and expects the world to come back. What actually comes back is only the server disk state. The separate Volume state is not part of that restore point.
What to do instead
Use Hetzner Backups or Snapshots as infrastructure recovery, not as your only Minecraft backup strategy.
For the world itself, add an application-aware backup path such as docker-mc-backup.
That combination gives you:
- server rebuild options from Hetzner
- world-level restore points from inside the Minecraft stack
Safer architecture for setupmc.com-style deployments
For a small production setup, the practical model is:
- use Hetzner Backups for the server disk
- run
itzg/mc-backupfor the Minecraft data - test restores with a real restore runbook
If your world is on a Volume, this is not optional housekeeping. It is the difference between a full recovery plan and an incomplete one.
Common mistakes
| Mistake | Why it is dangerous | Better approach |
|---|---|---|
| Assuming a Snapshot includes the Volume | World data may be missing in a disaster | Back up the world separately |
| Enabling Hetzner Backups and stopping there | Daily server-disk copies are not world-aware | Add application-level backups |
| Never testing a restore | Backup quality stays theoretical | Rehearse a restore on a staging target |
| Storing backups only on the same host | One host failure can wipe both live and backup copies | Add a second location later |
FAQ
Are manual Snapshots still useful?
Yes. They are useful before major infrastructure changes, but they are not a complete world-protection strategy when Volumes are involved.
What if I keep everything on the server disk?
Then Hetzner Backups and Snapshots cover more of your Minecraft setup, but an application-aware backup is still better for consistent restore operations.
Next steps
- Add automatic Minecraft backups with docker-mc-backup.
- Document your real recovery steps with the Docker restore runbook.
- If you are still in initial deployment, revisit the Hetzner Docker setup guide.