Snapshots machen und wiederherstellen

Ein Snapshot ist der etcd-Snapshot von k3s selbst: der Zustand des Clusters, jedes Kubernetes-Objekt einschließlich der Secrets. Diese Seite macht jetzt einen, stellt einen an Ort und Stelle wieder her und sagt, was ein Snapshot zurückbringt und was nicht.

In Arbeit: noch nicht buchbar

Gebaut im Labor: Am 2026-10-10 ging ein Snapshot in 25 Sekunden von einem echten Node in den Bucket, und eine Wiederherstellung an Ort und Stelle dauerte 160 Sekunden, mit unversehrten Daten in den Volumes. Ein selbst betriebener S3-Server stand für den Bucket. Die Wiederherstellung auf einen neuen Server ist Geplant. Die Oberfläche des Portals ist englisch, darum stehen ihre Beschriftungen hier auf Englisch. Sag mir, wenn es buchbar ist.

Was ein Snapshot enthält

Er enthält nicht die Daten in deinen Volumes. Eine Datenbank auf einem Volume, hochgeladene Dateien, alles, was ein Pod auf eine Platte schreibt: Das sicherst du mit den Werkzeugen, die du dafür benutzt. Für Postgres richtet die PaaSbox Platform die Backups selbst ein In Arbeit.

k3s nimmt die geplanten Snapshots und lädt sie in deinen Bucket, nach dem Zeitplan, den du unter Backups einrichten festlegst. Der Reiter Backups listet die Snapshots, die der Cluster zuletzt gemeldet hat, mit ihrer Art (Kind): Scheduled, On demand, Before an upgrade oder Final.

Jetzt einen Snapshot machen

Du musst Team-Admin sein, und der Cluster muss laufen.

1. Wähle auf der Overview oder dem Reiter Backups des Clusters Snapshot now.

2. pbx-agent nimmt ihn bei seiner nächsten Synchronisation und bestätigt, dass er im Bucket angekommen ist, bevor er Erfolg meldet. Operations zeigt die Schritte.

3. Der Snapshot erscheint unter Snapshots, als On demand, mit Where S3.

Vor jedem Upgrade nimmt pbx-agent selbst einen Snapshot; löschst du einen Cluster, bietet das Portal einen letzten an.

Wiederherstellung an Ort und Stelle

Eine Wiederherstellung setzt den Zustand des Clusters auf einen Snapshot zurück, auf demselben Server. Starten kann sie nur ein Team-Admin, nur bei einem Cluster, der bereit oder fehlgeschlagen ist, und nur aus einem Snapshot in S3.

1. Wähle auf dem Reiter Backups neben dem Snapshot Restore.

2. Lies, was die Wiederherstellung tut, tippe zur Bestätigung den Namen des Clusters ein und wähle Restore. Das Portal schreibt den Admins des Teams eine Mail, dass eine Wiederherstellung angestoßen wurde, und von wem In Arbeit.

3. pbx-agent hält k3s an, legt den Snapshot auf den Node (die Kopie, die k3s dort hat, oder aus dem Bucket geholt), setzt den Zustand des Clusters darauf zurück, startet k3s, wartet auf die API und entfernt nach zwei Minuten Wartezeit jeden anderen Node, der nicht zurückgekommen ist. Die Kubernetes-API ist so lange nicht erreichbar. Operations zeigt jeden Schritt.

Im Labor war die API etwa 35 Sekunden nach dem Start zurück, und die ganze Wiederherstellung dauerte 160 Sekunden. Wird pbx-agent während einer Wiederherstellung angehalten, macht er beim Schritt weiter, in dem er war.

Was eine Wiederherstellung an Ort und Stelle ändert und was sie behält:

• Weg: alles, was der Cluster nach dem Snapshot gespeichert hat: Deployments, Secrets, ConfigMaps und jedes andere Objekt, das seitdem angelegt oder geändert wurde.
• Bleibt: die Daten in deinen Volumes auf der Platte des Servers. Ein Volume, das nach dem Snapshot angelegt wurde, bleibt auf der Platte, aber der wiederhergestellte Cluster hat kein Objekt mehr, das darauf verweist.

Hältst du die Schlüssel des Buckets selbst, funktioniert eine Wiederherstellung nur, solange die Kubernetes-API läuft, denn pbx-agent liest dein Secret, bevor er k3s anhält. Stell einen Snapshot nur auf derselben oder einer neueren k3s-Version wieder her als der, die ihn genommen hat. Das Portal behält jede Version des Server-Tokens des Clusters, die ein behaltener Snapshot braucht, und schickt die passende mit der Wiederherstellung.

Wiederherstellung auf einen neuen Server

Geplant Das Portal soll einen neuen Server anlegen, dessen pbx-agent den Snapshot wiederherstellt, bevor k3s zum ersten Mal startet. pbx-agent kann seinen Teil schon; die Seite im Portal und der Schritt im Provisioner, die einen solchen Server anlegen, sind nicht gebaut. Bis dahin ist die Antwort auf einen verlorenen Server ein neuer Cluster, auf dem du deine Apps neu deployst, oder eine Wiederherstellung von Hand (Ohne PaaSbox weiterbetreiben).

Was was übersteht

Ereignis	Zustand des Clusters (Objekte, Secrets)	Daten in Volumes auf der Platte des Servers	Daten auf Hetzner-Volumes
Ein Upgrade	bleibt	bleiben	bleiben
Eine Wiederherstellung an Ort und Stelle	zurückgesetzt auf den Snapshot	bleiben	bleiben
Der Server geht verloren	im letzten Snapshot in deinem Bucket	verloren	bleiben, in deinem Projekt
Den Cluster löschen	im letzten Snapshot, wenn du ihn gewählt hast	mit dem Server gelöscht (ein übernommener Server behält seine Platte)	mit dem Cluster gelöscht

Backups einrichtenDer Bucket, seine Schlüssel, der Zeitplan und die Aufbewahrung.

5 · Eine Wiederherstellung übenLernschritt 5: ein Snapshot, eine Änderung, eine Wiederherstellung, und was zurückkam.