[Velero](https://velero.io/) backs up both the YAML that defines your workloads and the actual data sitting in your volumes. If you keep your manifests in Git, the volume data is the part Git cannot give you back, which is what [Backup strategy](/docs/hetzner/apalla/storage/backup/backup-strategy) covers. A database backs itself up, and files belong in object storage, so Velero is the fallback for volumes that hold plain files.

On Syself Autopilot you run it in file-copy mode: the node agent reads the files inside each volume and writes them to your bucket, which works the same on cloud volumes and local disks. Point it at [SeaweedFS](/docs/hetzner/apalla/storage/object/run-seaweedfs) or any S3-compatible endpoint. The Syself Consulting team can set up backups for you or run them as a full service if you would rather not operate Velero yourself.

<Steps>
<Step>Install the CLI</Step>

Download the `velero` client for your platform from the [Velero releases](https://github.com/vmware-tanzu/velero/releases), then confirm it runs:

```console
$ velero version --client-only
```

<Step>Give Velero bucket credentials</Step>

Velero talks to any S3-compatible store through the `aws` provider, because the endpoint speaks the S3 API. Put your access key and secret in a file in AWS credentials format:

```ini title="credentials-velero"
[default]
aws_access_key_id=<access-key>
aws_secret_access_key=<secret-key>
```

`velero install` reads this file and stores it as the `cloud-credentials` Secret in the cluster, so keep it local and delete it afterwards.

Generate a key scoped to the backup bucket rather than reusing a broad one. [Run SeaweedFS](/docs/hetzner/apalla/storage/object/run-seaweedfs) covers creating least-privilege keys.

<Step>Install the server</Step>

Install Velero with the node agent and file-copy backups, and turn CSI volume snapshots off:

```console
$ velero install \
    --provider aws \
    --plugins velero/velero-plugin-for-aws:v1.10.0 \
    --bucket cluster-backups \
    --secret-file ./credentials-velero \

    --use-volume-snapshots=false \
    --use-node-agent \
    --default-volumes-to-fs-backup \
    --backup-location-config region=<your-region>,s3ForcePathStyle=true,s3Url=https://<your-s3-endpoint>
```

Two flags carry the design:

- `--use-volume-snapshots=false` turns off CSI snapshots. Cloud volumes have no snapshot API to call, and a local snapshot never leaves the node, so Velero copies files instead. See [Volume snapshots and their limits](/docs/hetzner/apalla/storage/backup/snapshots-and-limits).
- `--use-node-agent` with `--default-volumes-to-fs-backup` runs a node agent that copies every volume's files by default, so you do not annotate each pod by hand.

Confirm the backup location is reachable:

```console
$ velero backup-location get
NAME      PROVIDER   BUCKET/PREFIX     PHASE       LAST VALIDATED                  ACCESS MODE   DEFAULT
default   aws        cluster-backups   Available   2026-08-17 09:14:22 +0000 UTC   ReadWrite     true
```

<Step>Take a backup</Step>

Back up a namespace, volumes included:

```console
$ velero backup create app-backup --include-namespaces my-app
$ velero backup describe app-backup --details
```

If you installed without `--default-volumes-to-fs-backup`, opt a pod's volumes in with an annotation naming the volumes to copy:

```console
$ kubectl -n my-app annotate pod/<pod> backup.velero.io/backup-volumes=<volume-name>
```

<Step>Schedule recurring backups</Step>

An on-demand backup is fine for a one-off, but a workload's recovery point depends on how often a backup runs. Create a `Schedule` so Velero backs the namespace up on a fixed cadence:

```console
$ velero schedule create app-recurring --schedule="0 */6 * * *" --include-namespaces my-app
```

The schedule interval is what sets a workload's recovery point: back up every six hours and you can lose at most six hours of files.

</Steps>

## Databases need a native backup instead

A file copy of a running database is crash-consistent, not [application-consistent](/docs/hetzner/apalla/storage/backup/snapshots-and-limits), so the database can refuse to load it. Back databases up with their own tooling (a dump or an operator backup) and store the result in object storage, and let Velero cover the surrounding Kubernetes resources and volumes that hold plain files.

A backup you have never restored proves nothing. Rehearse recovery in [Run a restore drill](/docs/hetzner/apalla/storage/backup/restore-drill).