A snapshot feels like a backup, but it is not one. It is a fast copy that stays in the same failure domain as the volume it copies, so if that storage fails, the snapshot goes with it. On Syself Autopilot the point is sharper still: cloud volumes cannot be snapshotted at all, and a local snapshot sits on the same disk as its source. Neither is something to recover from. Real recovery comes from a database's own backup or from data kept in object storage, which is why the platform does not lean on snapshots.

## What a CSI snapshot promises

A CSI `VolumeSnapshot` asks the storage driver to freeze a volume at a point in time. When the driver supports it well, the snapshot is quick and cheap, and you restore by cloning it back into a new volume. This is the mechanism Velero can use through its CSI plugin.

<Collapsible title="What 'when the driver supports it well' means">

The catch is the phrase "when the driver supports it well." The support has to be complete and correct, or a restore hands you a volume that does not mount or does not hold what you expected.

</Collapsible>

## What the storage here actually offers

Two facts decide this, and neither hands you a snapshot you can restore from.

A Hetzner Cloud volume cannot be snapshotted at all. The Hetzner Cloud CSI driver does not implement CSI `VolumeSnapshot`, because the Hetzner Cloud API has no volume snapshot to call: its snapshots and backups image a server's own disk and explicitly leave attached volumes out. The volume is still durable underneath, on Ceph with three copies, so it survives a disk failure, but durability is not a point-in-time copy you can roll back to.

A local TopoLVM volume can be snapshotted, but the snapshot never leaves the disk. LVM keeps a thin snapshot in the same volume group and thin pool as the source, on the same server, and TopoLVM can restore it only on that same node. A snapshot of a local volume shares the fate of the disk it sits on: lose the drive or the server and the source and the snapshot go together. That is a copy in the same failure domain, which is not a backup.

| Backend                           | CSI VolumeSnapshot                                          | Why it is not a backup here                                           |
| --------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------- |
| Hetzner Cloud volume (`standard`) | Not supported; the Hetzner Cloud API has no volume snapshot | Nothing to snapshot into; use a native backup or file copy            |
| Local storage (TopoLVM)           | Thin volumes only, restorable on the same node              | The snapshot sits on the same disk, in the same failure domain        |
| JuiceFS                           | Its data already lives in object storage                    | Protect it by backing up the object store, not with a volume snapshot |

This is why Velero here runs in file-copy mode: with no snapshot to take, the node agent reads the files inside every volume and writes them to object storage instead. This works the same on cloud volumes and on local disks, because it never asks the driver for a snapshot. The [Velero install command](/docs/hetzner/apalla/storage/backup/back-up-with-velero) has the flags that turn this on.

## Crash-consistent, not application-consistent

A file copy of a running application captures the disk mid-write. That copy is **crash-consistent**: it looks exactly like the disk would after a power cut. Most plain files survive a power cut fine, so most volumes restore cleanly.

A database is different. It may have half-written a transaction or kept recent changes in memory when the copy ran. Loading that copy is like starting the database after someone pulled the plug. It might recover, it might refuse. That is a crash-consistent copy, not an **application-consistent** one, and the difference is the whole reason databases need their own backup.

> [!IMPORTANT]
> A snapshot or a file copy is not a backup on its own. It leaves the point-in-time copy on or near the same storage, and for a database it is not guaranteed to restore. A real backup is application-consistent and lives in object storage outside the cluster.

## What this means for your data

Match the method to the data:

- **A filesystem app with no backup of its own** (config or content it writes to its volume): Velero file copy is enough. A crash-consistent copy of plain files restores cleanly. Files you control belong in object storage instead, where there is no volume to copy.
- **Databases and anything transactional**: use the database's own backup tooling for an application-consistent copy, then store that copy in object storage. Velero covers the surrounding Kubernetes resources.

Whichever method you use, prove it works before you need it.

Related: [Velero setup](/docs/hetzner/apalla/storage/backup/back-up-with-velero), [disaster recovery](/docs/hetzner/apalla/storage/backup/disaster-recovery-stateful), and [run a restore drill](/docs/hetzner/apalla/storage/backup/restore-drill).