Eine nächtliche Wiederherstellungsübung durch einen Agenten

Ein Snapshot hilft nur, wenn er sich wiederherstellen lässt, und wissen kannst du das nur, indem du einen wiederherstellst. Dieses Rezept lässt einen Agenten die Wiederherstellung jede Nacht auf Staging beweisen: Er schreibt eine Markierung, macht einen Snapshot, schreibt eine zweite Markierung, stellt den Snapshot an Ort und Stelle wieder her und prüft, dass die erste Markierung zurückgekommen ist und die zweite nicht. Dann berichtet er.

In Arbeit: noch nicht buchbar

In Arbeit Die MCP-Tools und die REST-API gibt es als Code im Portal; gegen einen echten Cluster sind sie noch nicht gelaufen. Der Snapshot und die Wiederherstellung an Ort und Stelle, die sie auslösen, sind am 2026-10-10 Gebaut im Labor auf echten Hetzner-Servern gelaufen. Eine Wiederherstellung auf einen neuen Server ist Geplant: Noch keine Seite und kein Tool legt eine an. Die Oberfläche des Portals ist englisch, darum stehen ihre Beschriftungen hier auf Englisch. Sag mir, wenn es buchbar ist.

Was du brauchst

• Staging als eigenen Cluster, upcheck-staging aus Lernschritt 4, mit seinen Snapshots in deinem S3-Bucket.
• Eine Zeit, in der Staging weg sein darf. Eine Wiederherstellung hält die Kubernetes-API des Clusters an, solange sie läuft. Im Labor dauerte die Wiederherstellung 160 Sekunden, und die API war etwa 35 Sekunden nach dem Start zurück. Eine Wiederherstellung wird sofort eingereiht; sie wartet nicht auf das Wartungsfenster, also leg die Übung selbst in das Fenster von Staging.
• Einen API-Schlüssel aus API keys & agents, angelegt von einem Team-Admin, mit allen vier Scopes: k3s:read, um die Operationen zu verfolgen, k3s:write für den Snapshot, k3s:access für eine Kubeconfig und k3s:destructive für die Wiederherstellung.
• Einen Ort für den Bericht: ein Issue, eine Chatnachricht, eine Mail; wohin dein Agent eben schreiben kann.

Die Übung

Gib deinem Agenten diese Schritte, oder schreib sie als Skript, das die REST-API aufruft. Jeder Schritt nennt das MCP-Tool und den Endpunkt unter …/k3s/clusters/upcheck-staging/.

1. Eine Kubeconfig holen. request_kubeconfig mit role admin, dann get_kubeconfig_result (POST access/, GET access/<id>/result/), lokal entschlüsselt mit paasbox_kubeconfig.py. Hol sie vor dem Snapshot: Die Wiederherstellung setzt den Zustand des Clusters auf den Snapshot zurück, und mit ihm den ServiceAccount hinter jeder Kubeconfig, die später ausgestellt wurde.

2. Die erste Markierung schreiben.

   kubectl -n default create configmap drill-before --from-literal=at="$(date -u +%FT%TZ)"

3. Den Snapshot machen. create_snapshot (POST snapshots/) reiht ihn ein. Frag get_operation (GET operations/<id>/) ab, bis state succeeded ist; im Labor war ein Snapshot nach 25 Sekunden im Bucket. Der neueste Name in list_snapshots (GET snapshots/) ist der, der wiederhergestellt wird.

4. Die zweite Markierung schreiben, die die Wiederherstellung entfernen muss:

   kubectl -n default create configmap drill-after --from-literal=at="$(date -u +%FT%TZ)"

5. Wiederherstellen. restore_snapshot (POST restore/) mit dem Namen des Snapshots und confirm gleich upcheck-staging, dem Namen des Clusters. Frag get_operation ab, bis sie succeeded oder failed ist. Die Schritte sind stop_k3s, reset_restore, start_k3s, wait_api und forget_stale_nodes; der letzte wartet zwei Minuten, bevor er Nodes entfernt, die nicht zurückgekommen sind.

6. Prüfen.

   kubectl -n default get configmap drill-before drill-after
   kubectl -n upcheck get saasapp upcheck

   drill-before muss da sein, mit seiner Zeit, drill-after muss weg sein, und die App muss wieder Ready erreichen. get_cluster muss state ready zeigen und keine Zustandsaussage, die schlechter ist als vorher. Ergänze die Prüfungen, die deine App braucht, etwa eine Anfrage an ihre Health-Seite.

7. Berichten und aufräumen. Schick, was bestanden hat und was nicht, den Namen des Snapshots, die IDs der beiden Operationen und wie lange jede gedauert hat. Dann lösch drill-before.

Schlägt ein Schritt fehl, hält der Agent dort an und berichtet ihn mit dem fehlgeschlagenen Schritt und der Meldung der Operation aus get_operation. Er versucht es nicht noch einmal: Eine zweite Wiederherstellung auf einem Cluster, der eine nicht geschafft hat, braucht zuerst deinen Blick.

Wer die Wiederherstellung bestätigt

Nachts ist niemand da, der ja sagt. Das Portal prüft, dass confirm der Name des Clusters ist; das hält den Agenten davon ab, einen Cluster wiederherzustellen, den er nicht genannt hat. Es prüft nicht, dass eine Person zugestimmt hat. Die Scopes eines Schlüssels gelten für jeden Cluster deines Teams, der Schlüssel, der Staging wiederherstellen darf, darf also auch die Produktion wiederherstellen. Drei Wege, das in der Hand zu behalten:

• Lass die Übung als Skript laufen, das du gelesen hast, mit upcheck-staging darin festgeschrieben, und halte den Schlüssel nur dort, wo das Skript läuft.
• Oder starte den Agenten jeden Morgen selbst und bestätige die Wiederherstellung an seiner Rückfrage. Dann ist es eine Übung am Morgen, keine nächtliche.
• Und halte die Produktion in einem Team, zu dem dieser Schlüssel nicht gehört, und Staging im Team des Schlüssels: Dann erreicht er die Produktion gar nicht.

Leitplanken für Agenten sagt, was jede Grenze aufhält.

Was die Übung nicht beweist

• Deine Volumes. Ein Snapshot hält den Zustand des Clusters, nicht die Daten in deinen Volumes. Eine Wiederherstellung an Ort und Stelle lässt die Platte des Servers, wie sie ist: Im Labor waren die Daten in einem Volume danach unversehrt. Im Snapshot waren sie nie.
• Deine Datenbank. Postgres auf der PaaSbox Platform hat eigene Backups, pro Anwendung. Den Zustand des Clusters wiederherzustellen, stellt keine Datenbank wieder her; das prüfst du mit der eigenen Wiederherstellung der Datenbank.
• Einen neuen Server. Ist der Server verloren, hat eine Wiederherstellung an Ort und Stelle nichts, worauf sie laufen kann. Eine Wiederherstellung auf einen neuen Server ist Geplant.
• Einen Bucket, dessen Schlüssel du selbst hältst. Das Labor nutzte einen Bucket, dessen Schlüssel das Portal hielt; mit deinen eigenen Schlüsseln ist die Wiederherstellung noch nicht gelaufen In Arbeit.

5 · Eine Wiederherstellung übenDieselbe Übung von Hand, im Lernpfad.

Snapshots machen und wiederherstellenWas ein Snapshot hält und was was übersteht.