SYS.DOCS // DOCS

Cluster Backups and Restore

Use Backups to protect 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

Every Edka cloud cluster uses the embedded etcd datastore and can use this backup flow.

Satellite clusters do not support cluster backups. Database backups to S3 or GCS and agent state backups work as usual on satellites.

Enable backups

You can enable scheduled etcd backups in two places:

during cluster creation
later from Cluster Settings → Backups on an existing 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 → Backups
- 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 Backups after the first scheduled snapshot is captured and uploaded. The cluster’s Backups settings page shows the set count and the latest set, and links to the catalog filtered to that cluster.

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.

The catalog shows which key each set was written with: Current key, Edka managed, or Previous key together with that key’s public part when a set predates a key rotation. Keep the matching private key for as long as those sets are within retention.

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 every backup set across your organization. It is the one place to inspect and restore sets; the per-cluster settings page only holds the schedule and key.

Coverage lists each live cluster with its schedule and the age of its newest set, and flags clusters where backups are off, no set exists yet, or the last set is overdue. Deleted clusters that still have sets are counted underneath.

The set list shows one row per set: cluster, snapshot, when it was taken, k3s version, and key status. You can filter by cluster, by live or deleted source, and search by snapshot or cluster name. The retention window for your plan is stated above the list.

Each row offers the recovery actions that apply to it:

Restore as new on every set
Recover on sets whose source cluster was deleted
Roll back on sets whose source cluster is live, for organization owners and admins and the cluster’s owner

Recovery paths

Edka supports three main recovery paths from a backup set.

Roll back cluster

Use Roll back 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 Recover when the source cluster no longer exists in Edka. It opens the Recover deleted cluster wizard.

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, the catalog offers Restore as new instead of recovery.

Restore as new cluster

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