Eine Wiederherstellung üben

Das ist der fünfte Schritt des Lernpfads. Du stellst Staging einmal mit Absicht aus einem Snapshot wieder her und siehst selbst, was ein Snapshot zurückbringt und was er lässt, wie es ist. Mach es auf Staging: Eine Wiederherstellung hält die Kubernetes-API an, und in der Produktion würden deine Nutzer es merken.

In Arbeit: noch nicht buchbar

Gebaut im Labor: Am 2026-10-10 hat das Portal einen Cluster auf einem echten Hetzner-Server an Ort und Stelle aus einem Snapshot in S3 wiederhergestellt. Der S3-Server war ein selbst betriebener, an Stelle von Hetzner Object Storage, das In Arbeit ist. Die Oberfläche des Portals ist englisch, darum stehen ihre Beschriftungen hier auf Englisch. Nachgehen kannst du die Schritte noch nicht. Sag mir, wenn es buchbar ist.

Was du am Ende hast

Eine Wiederherstellung, die du einmal gemacht hast, mit ihrer Dauer, und zwei Markierungen, die die Linie zeigen, die ein Snapshot zieht: Die Objekte im Cluster kommen zurück, wie sie waren, die Daten in Volumes nicht.

Was du brauchst

• upcheck-staging aus Schritt 4, mit Snapshots in seinen Bucket. Das Portal stellt nur Snapshots wieder her, die in S3 liegen.
• Eine Admin-Kubeconfig von Staging, ausgestellt, bevor du den Snapshot machst. Die Wiederherstellung entfernt alles, was der Cluster nach dem Snapshot gespeichert hat, und der ServiceAccount einer später ausgestellten Kubeconfig gehört dazu. Funktioniert deine nach der Wiederherstellung nicht mehr, hol dir eine neue.

Zwei Markierungen schreiben

1. Speichere das als drill.yaml. Es enthält eine ConfigMap, die im Zustand des Clusters lebt, und eine Datei in einem Volume auf der Platte des Servers, geschrieben von einem kleinen Pod:

   apiVersion: v1
   kind: Namespace
   metadata: {name: drill}
   ---
   apiVersion: v1
   kind: ConfigMap
   metadata: {name: marker, namespace: drill}
   data: {state: before}
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata: {name: data, namespace: drill}
   spec:
     accessModes: [ReadWriteOnce]
     storageClassName: local-lvm-thin
     resources: {requests: {storage: 1Gi}}
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata: {name: marker, namespace: drill}
   spec:
     replicas: 1
     strategy: {type: Recreate}
     selector: {matchLabels: {app: marker}}
     template:
       metadata: {labels: {app: marker}}
       spec:
         containers:
           - name: c
             image: busybox:1.37
             command: [sh, -c, "sleep 1000000"]
             volumeMounts: [{name: data, mountPath: /data}]
         volumes: [{name: data, persistentVolumeClaim: {claimName: data}}]

2. Wende sie an und schreib die Datei:

   export KUBECONFIG=~/Downloads/upcheck-staging-admin.kubeconfig
   kubectl apply -f drill.yaml
   kubectl -n drill rollout status deployment/marker
   kubectl -n drill exec deploy/marker -- sh -c 'echo before > /data/marker'

Den Snapshot machen, dann beides ändern

1. Wähle auf der Overview von Staging Snapshot now. Öffne Backups: Der Snapshot steht unter Snapshots, und Where sagt S3. Im Labor war ein Snapshot nach 25 Sekunden im Bucket.

2. Ändere beide Markierungen und leg ein Objekt an, das der Snapshot nie gesehen hat:

   kubectl -n drill patch configmap marker -p '{"data":{"state":"after"}}'
   kubectl -n drill create configmap made-after --from-literal=state=after
   kubectl -n drill exec deploy/marker -- sh -c 'echo after > /data/marker'

Wiederherstellen

1. Wähle auf Backups neben dem Snapshot Restore. Die Seite sagt, was folgt: pbx-agent stoppt k3s, setzt den Zustand des Clusters auf den Snapshot zurück und startet k3s wieder; alles, was nach dem Snapshot gespeichert wurde, ist weg; Daten in Volumes bleiben, wie sie sind.

2. Tipp upcheck-staging unter Type the cluster’s name ein und wähle Restore.

3. Verfolge die Operation unter Operations. Ihre Schritte sind stop_k3s, reset_restore (der Snapshot wird auf den Node gelegt, und k3s setzt seine Datenbank darauf zurück), start_k3s, wait_api und forget_stale_nodes, das zwei Minuten auf Nodes wartet, die nicht zurückkommen; auf einem einzelnen Node gibt es keine. Im Labor antwortete die API etwa 35 Sekunden nach dem Start wieder, und nach 160 Sekunden war die Wiederherstellung fertig.

Hält pbx-agent mittendrin an, macht er an dem Schritt weiter, bei dem er war: Im Labor wurde er im letzten Schritt beendet, nach 5 Sekunden neu gestartet und hat die Wiederherstellung abgeschlossen.

Prüfen, was zurückkam

kubectl -n drill get configmap marker -o jsonpath='{.data.state}'   # before
kubectl -n drill get configmap made-after                           # NotFound
kubectl -n drill exec deploy/marker -- cat /data/marker              # after

Die ConfigMap ist zurück, wie sie war, und die nach dem Snapshot angelegte ist weg: Ein Snapshot hält den Zustand des Clusters, jedes Objekt in der Kubernetes-API. Die Datei sagt weiter after: Das Volume gehört nicht zum Snapshot, und die Wiederherstellung lässt es in Ruhe.

Diese Linie läuft auch durch deine App. Das Postgres von upcheck hält seine Daten in einem Volume auf der Platte des Servers, also setzt eine Wiederherstellung an Ort und Stelle die Datenbank nicht auf den Zeitpunkt des Snapshots zurück. Das ist die Aufgabe ihrer eigenen Backups, data.postgres.backup, die Schritt 2 empfiehlt: Die Plattform stellt sie in eine neue App mit data.postgres.restoreFrom wieder her, auf Wunsch zu einem bestimmten Zeitpunkt. In Arbeit

Eine Wiederherstellung auf einen neuen Server, für einen Server, der weg ist, ist Geplant.

Wenn du fertig bist, räum die Übung weg: kubectl delete namespace drill.

Was du jetzt hast

Eine Wiederherstellung, die du vom Klick bis zur Prüfung verfolgt hast, mit ihren Zahlen, und die Linie zwischen dem, was ein Snapshot hält, und dem, was deine Volumes halten. Als Nächstes die andere Operation, die die API anhält: ein Upgrade.

6 · Im Wartungsfenster upgradenStaging jetzt upgraden, Snapshot, Neustart und Health-Gate beobachten, dann die Produktion einplanen.

Snapshots machen und wiederherstellenWas ein Snapshot enthält, wie du einen machst und wiederherstellst, und was was übersteht.