Take and restore snapshots
A snapshot is k3s’ own etcd snapshot: the cluster’s state, every Kubernetes object including the Secrets. This page takes one now, restores one in place, and says what a snapshot brings back and what it does not.
What a snapshot holds
Section titled “What a snapshot holds”It does not contain the data in your volumes. A database on a volume, uploaded files, anything a pod writes to disk: back that up with the tools you use for it. The PaaSbox Platform sets up backups for Postgres itself In progress.
k3s takes the scheduled snapshots and uploads them to your bucket, on the schedule you set in Set up backups. The Backups tab lists the snapshots the cluster reported last, with their Kind: Scheduled, On demand, Before an upgrade or Final.
Take a snapshot now
Section titled “Take a snapshot now”You need to be a team admin, and the cluster must be running.
-
On the cluster’s Overview or Backups tab, choose Snapshot now.
-
pbx-agenttakes it at its next sync and confirms that it reached the bucket before it reports success. Operations shows the steps. -
The snapshot appears under Snapshots, On demand, with Where S3.
Before every upgrade pbx-agent takes a snapshot of its own; when you delete a cluster, the portal offers a final one.
Restore in place
Section titled “Restore in place”A restore resets the cluster’s state to a snapshot, on the same server. Only a team admin can start it, only on a cluster that is ready or failed, and only from a snapshot in S3.
-
On the Backups tab, choose Restore next to the snapshot.
-
Read what the restore does, type the cluster’s name to confirm, and choose Restore. The portal mails the team’s admins that a restore was queued, and by whom In progress.
-
pbx-agentstops k3s, puts the snapshot on the node (k3s’ own copy there, or fetched from the bucket), resets the cluster’s state to it, starts k3s, waits for the API, and after a two-minute grace removes any other node that has not come back. The Kubernetes API is down meanwhile. Operations shows each step.
In the lab the API was back about 35 seconds after the start, and the whole restore took 160 seconds. A pbx-agent that is stopped during a restore resumes at the step it was in.
What a restore in place changes and keeps:
- Gone: everything the cluster stored after the snapshot: Deployments, Secrets, ConfigMaps and every other object created or changed since.
- Kept: the data in your volumes on the server’s disk. A volume created after the snapshot stays on the disk, but the restored cluster has no object that refers to it.
If you hold the bucket’s keys yourself, a restore works only while the Kubernetes API is up, because pbx-agent reads your Secret before it stops k3s. Restore a snapshot only onto the same or a newer k3s version than the one that took it. The portal keeps every version of the cluster’s server token that a kept snapshot needs, and sends the matching one with the restore.
Restore onto a new server
Section titled “Restore onto a new server”Planned The portal is to create a new server whose pbx-agent restores the snapshot before k3s first starts. pbx-agent can already do its part; the portal page and the provisioner step that create such a server are not built. Until then, the answer to a lost server is a new cluster with your apps deployed again, or a restore by hand (Run without PaaSbox).
What survives what
Section titled “What survives what”| Event | Cluster state (objects, Secrets) | Data in volumes on the server’s disk | Data on Hetzner volumes |
|---|---|---|---|
| An upgrade | kept | kept | kept |
| A restore in place | reset to the snapshot | kept | kept |
| The server is lost | in the last snapshot in your bucket | lost | kept, in your project |
| Deleting the cluster | in the final snapshot, if you chose it | deleted with the server (an adopted server keeps its disk) | deleted with the cluster |