Backups einrichten

Die Snapshots eines Clusters gehen vom Server direkt in einen S3-Bucket, der dir gehört; sie laufen nie über das Portal. Diese Seite richtet sie auf deinen Bucket, legt fest, wie oft sie entstehen und wie viele bleiben, und prüft, dass der Bucket funktioniert. Ohne Bucket bleiben die Snapshots auf der Platte des Servers und gehen mit ihm verloren.

In Arbeit: noch nicht buchbar

Gebaut im Labor: Am 2026-10-10 war ein Snapshot 25 Sekunden nach der Anfrage im Bucket, ein Bucket, der einem laufenden Cluster hinzugefügt wurde, wurde ohne Neustart von k3s genutzt, und neue Schlüssel ersetzten die alten in 8 Sekunden. Ein selbst betriebener S3-Server stand für den Bucket; Hetzner Object Storage selbst und Schlüssel, die du selbst hältst, sind In Arbeit. Die Oberfläche des Portals ist englisch, darum stehen ihre Beschriftungen hier auf Englisch. Sag mir, wenn es buchbar ist.

Was du brauchst

• Einen S3-Bucket mit Access Key und Secret Key. Ein Bucket bei Hetzner Object Storage am Standort des Clusters kostet am wenigsten. Gib dem Cluster einen eigenen Ordner, etwa seinen Namen.
• Team-Admin zu sein.

Die Snapshots auf deinen Bucket richten

Diese Felder kannst du beim Anlegen des Clusters ausfüllen, oder den Bucket später hinzufügen:

1. Öffne den Reiter Backups des Clusters und geh zu Schedule and target.

2. Wähle Who holds the bucket’s keys (unten). Trag den S3 endpoint als Hostnamen ein, wenn nötig mit Port, ohne https:// und ohne Pfad, etwa fsn1.your-objectstorage.com. Trag Bucket, Folder und Region ein.

3. Lass Schedule (cron, UTC) auf 0 */6 * * *, alle sechs Stunden ein Snapshot, und Snapshots to keep auf 28, das sind sieben Tage; oder setz eigene Werte (unten). Wähle Save. Der Node wendet es bei seiner nächsten Synchronisation an.

4. Hält das Portal die Schlüssel: Trag unter Bucket keys den Access key und den Secret key ein und wähle Save new keys. Die ersten Schlüssel gelten sofort.

Ein Bucket, der einem laufenden Cluster hinzugefügt wird, braucht keinen Neustart von k3s: pbx-agent schreibt das Secret kube-system/pbx-etcd-s3, und der nächste Snapshot geht in den Bucket.

Wer die Schlüssel des Buckets hält

Das wählst du pro Cluster: The portal holds the S3 keys (voreingestellt) oder The customer holds the S3 keys.

	Das Portal hält die Schlüssel	Du hältst die Schlüssel
Wie die Schlüssel auf den Server kommen	Du gibst sie im Portal ein. Es speichert sie verschlüsselt und schickt sie pbx-agent, versiegelt für den Schlüssel des Nodes; pbx-agent schreibt sie in das Secret kube-system/pbx-etcd-s3, das k3s liest.	Du legst das Secret kube-system/pbx-etcd-s3 selbst an. pbx-agent legt es nie an, ändert es nie und löscht es nie.
Kann das Portal deine Snapshots lesen?	Grundsätzlich ja: Zusammen mit dem Server-Token des Clusters, das es ebenfalls hält, könnten die Schlüssel einen Snapshot öffnen.	Nein. Das Portal sieht die Schlüssel nie.
Wiederherstellung an Ort und Stelle	Funktioniert auch, wenn die Kubernetes-API nicht erreichbar ist.	Funktioniert nur, solange die Kubernetes-API läuft: pbx-agent liest dein Secret, bevor er k3s anhält.

Hältst du die Schlüssel selbst, leg das Secret mit dem Typ etcd.k3s.cattle.io/s3-config-secret und diesen Schlüsseln an:

apiVersion: v1
kind: Secret
metadata:
  name: pbx-etcd-s3
  namespace: kube-system
type: etcd.k3s.cattle.io/s3-config-secret
stringData:
  etcd-s3-endpoint: fsn1.your-objectstorage.com
  etcd-s3-bucket: my-snapshots
  etcd-s3-folder: upcheck-prod
  etcd-s3-region: fsn1
  etcd-s3-access-key: <access key>
  etcd-s3-secret-key: <secret key>

Stellst du einen Cluster von Schlüsseln beim Portal auf eigene um, löscht das die Schlüssel, die das Portal hielt.

Zeitplan und Aufbewahrung

• Schedule (cron, UTC): fünf Cron-Felder aus Ziffern, *, /, - und Kommas. k3s nimmt die geplanten Snapshots selbst, darum gehen sie weiter, wenn das Portal nicht erreichbar ist.
• Snapshots to keep: von 1 bis 500. k3s löscht die ältesten über diese Zahl hinaus, auch im Bucket. Snapshots werden komprimiert.

Eine Änderung von Zeitplan oder Aufbewahrung startet k3s neu, darum wird sie im nächsten Wartungsfenster des Clusters wirksam. In Arbeit Neustarts, die auf das Fenster warten, sind auf einem echten Cluster noch nicht gelaufen. Ein neues Ziel oder neue Schlüssel brauchen keinen Neustart.

Lifecycle-Regeln, Versionierung und Zugriffsregeln des Buckets sind deine Sache. Eine Lifecycle-Regel, die Objekte löscht, kann Snapshots löschen, mit denen k3s noch rechnet.

Prüfen, dass es funktioniert

1. Wähle Snapshot now auf dem Reiter Backups oder der Overview. pbx-agent bestätigt, dass der Snapshot im Bucket angekommen ist, bevor er Erfolg meldet.

2. Der Snapshot erscheint unter Snapshots auf dem Reiter Backups, und Where sagt S3. Ein Snapshot mit Local ist auf der Platte des Servers geblieben.

3. Sieh in deinem Bucket nach: Die Datei liegt in dem Ordner, den du angegeben hast.

Kommen danach zwei geplante Snapshots hintereinander nicht an, schreibt das Portal den Admins des Teams eine Mail In Arbeit.

Neue Schlüssel

Hält das Portal die Schlüssel, ersetzt du sie unter Bucket keys mit Save new keys. Neue Schlüssel werden erst ausprobiert: pbx-agent listet den Bucket mit ihnen, und erst wenn das klappt, ersetzen sie die Schlüssel, die in Gebrauch sind. Der Abschnitt zeigt jede Prüfung als s3.verify mit ihrem Ergebnis. Ein falsches Paar fällt bei der Prüfung durch, und die Schlüssel in Gebrauch bleiben. Widerrufe danach die alten Schlüssel bei deinem S3-Anbieter. Zugangsdaten rotieren behandelt das zusammen mit den anderen Schlüsseln des Clusters.

Snapshots machen und wiederherstellenWas ein Snapshot enthält, und wie du einen an Ort und Stelle wiederherstellst.

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