SYS.DOCS // DOCS

Cluster Backups and Restore

Use Backups to protect embedded-etcd clusters and recover them from the Edka backup catalog.

What cluster backups include

Each uploaded backup set contains:

an encrypted etcd snapshot
the K3s PKI bundle required for recovery
restore metadata such as cluster runtime settings and backup configuration

This is cluster-state recovery, not cloud-resource cloning.

For stateful workloads, remember:

In-place rollback is the safest option when the source cluster still exists.
Restore as new cluster does not take over the source cluster provider volumes or load balancers.
Restore deleted cluster can reuse leftover provider volumes or load balancers if they still exist in Hetzner, but that is reattachment, not cloning.

Requirements

Cluster backups are available only for clusters using the embedded etcd datastore.

External-database clusters do not support this etcd backup flow.

Enable backups

You can enable scheduled etcd backups in two places:

during cluster creation
later from Cluster Settings → Backup (the panel is headed ETCD Backups) on an existing embedded-etcd cluster

When you enable backups on an existing cluster, Edka updates the live first control plane node in place:

applies the K3s etcd snapshot schedule on that node
deploys or refreshes the backup upload agent on that node

This does not restore a snapshot, roll back the cluster, or reprovision the cluster from backup.

The user-facing backup controls are:

Snapshot schedule
Backup frequency:
- Free: every 24 hours
- Standard / Pro: every 24 hours or every 6 hours
Run backup now:
- Standard / Pro only
- available from Cluster Settings → Backup
- requires scheduled backups to already be enabled on the cluster
- triggers an immediate backup upload from the current first control plane node without restoring cluster state

Uploaded backup-set retention follows the active organization plan:

Free: 7 days
Standard: 30 days
Pro: 90 days

This retention window applies to uploaded backup sets stored in Edka-managed object storage. It is separate from the internal local snapshot pruning that K3s performs on the control plane node.

These scheduled snapshots are created locally on the control plane node first. They are not stored as separate AGE-encrypted files on disk by the backup feature.

Uploaded backup sets appear in the global backup catalog and in the per-cluster recent backup list after the first scheduled snapshot is captured and uploaded.

Encryption

There are two different encryption layers to keep in mind:

Local snapshot files: regular etcd snapshot files written on the node
Uploaded backup sets: AGE-encrypted artifacts uploaded into Edka-managed object storage

Edka encrypts the uploaded backup artifacts before upload. It does not separately AGE-encrypt the local on-node snapshot files created by K3s.

By default, Edka uses a platform-managed AGE key.

If you want customer-controlled encryption, open /backups and either:

paste your own AGE public key
generate a new AGE keypair and download the private key once

You can also remove the custom public key later and return to the platform-managed key.

Edka shows the AGE public key used for each uploaded backup set in the backup catalog and in the per-cluster backup views.

The backup catalog shows, for each backup set:

encryption mode
the AGE public key used for that set

When a backup set is customer-key encrypted, restore and rollback operations require the matching AGE private key. That private key is used only for the operation and is not stored in organization settings.

Secrets encryption vs backup encryption

Kubernetes Secrets Encryption is a separate cluster setting.

When enabled, secret data is encrypted inside etcd before it is written to the database. That means secret values remain encrypted inside both the running etcd datastore and any etcd snapshot created from it.

This is different from backup artifact encryption:

Secrets encryption protects Kubernetes Secret data inside etcd
Backup encryption protects uploaded backup artifacts in transit and at rest in object storage

Backup catalog

Open /backups to browse the cluster backup catalog across your organization.

The catalog provides:

total backup set count
customer-key encrypted set count
latest upload timestamp
filtering by cluster
search by snapshot or cluster name
direct restore entrypoints
encryption public key visibility per backup set
recovery options that distinguish Restore deleted cluster from restore-as-new cloning

Each cluster also has a Recent Backup Sets section in Cluster Settings → Backup for quick rollback and restore actions.

Recovery paths

Edka supports three main recovery paths from a backup set.

Roll back cluster

Use Roll Back Cluster to restore the current cluster in place.

Choose this when:

the cluster still exists
you want to recover stateful workloads
you want to preserve the current cluster identity

This is the preferred recovery path for live clusters with persistent volumes.

For single-master clusters, rollback is also the disaster-recovery path for a lost control plane node when the Edka cluster record still exists. Edka can reprovision the missing master from backup and continue recovery in place.

Restore deleted cluster

Use Restore deleted cluster when the source cluster no longer exists in Edka (the recovery wizard it opens is titled Recover deleted cluster).

This restore path:

uses the original cluster name
recreates the cluster from the selected backup set
can reuse leftover provider volumes or load balancers if they were not fully removed from Hetzner

Choose this after accidental deletion or infrastructure loss when you want to bring the original cluster back.

If the original cluster still exists, Edka guides you toward Restore as new cluster instead of deleted-cluster recovery.

Restore as new cluster

Use Restore as new cluster when the source cluster is still online and you want a separate copy.