Backups & Verfügbarkeit

Zwei Fragen entscheiden, ob du einer Managed-Plattform Produktion anvertrauen kannst: Was passiert mit dem Zustand meines Clusters, wenn etwas kaputtgeht, und was passiert währenddessen mit meinen Apps. Hier sind beide Antworten, klar formuliert.

Was wir sichern

Der etcd-Zustand deines Clusters – jedes Kubernetes-Objekt, das du angelegt hast: Deployments, Services, ConfigMaps, Secrets, PVC-Bindings – wird kontinuierlich gesichert: inkrementelle Deltas ungefähr alle fünf Minuten, dazu periodische Voll-Snapshots, in S3-kompatiblen Object Storage, unabhängig von den Maschinen, auf denen deine Control Plane läuft. Falls die Plattform deine Control Plane je neu aufbauen muss, stellt sie aus dieser Kette wieder her; die Definition deines Clusters hängt an keiner einzelnen Platte.

Während ein Cluster im Ruhezustand ist, werden keine neuen Snapshots erstellt (es ändert sich ja nichts), und die jüngste Kette bleibt für das Aufwecken erhalten.

Was wir nicht sichern

Das etcd-Backup deckt die Definitionen deines Clusters ab – nicht deine Anwendungsdaten:

• Persistente Volumes und Datenbanken gehören dir. Das etcd-Backup weiß, dass ein PVC existiert; die Bytes auf dem Volume enthält es nicht.
• Alles, was deine Apps anderswo speichern – Object Storage, externe Datenbanken – liegt ebenfalls außerhalb des Sichtfelds der Plattform.

Du hast cluster-admin, kannst also jedes Backup-Tooling einsetzen, das du möchtest; eine Schritt-für-Schritt-Anleitung für Workload-Backups mit Velero auf S3-kompatiblen Storage kommt in den Guides-Bereich. Bis dahin gilt der ehrliche Einzeiler: Wir halten deinen Cluster wiederherstellbar; du hältst deine Daten wiederherstellbar.

Was die HA-Stufe ändert

Die beiden Stufen unterscheiden sich in genau einer Sache – der Fehlertoleranz der Control Plane:

• Basic betreibt je eine etcd- und API-Server-Replika. Startet der Plattform-Node darunter neu, startet deine Control Plane mit: ein paar Minuten, in denen das Management pausiert.
• HA betreibt drei synchron replizierende etcd-Replikas und mehrere API-Server, so verteilt, dass die Control Plane den Ausfall eines Plattform-Nodes ohne Unterbrechung übersteht.

Beide Stufen bekommen dieselben kontinuierlichen Backups – HA reduziert Unterbrechungen, Backups schützen vor Verlust. Das sind verschiedene Verteidigungslinien, und die zweite bekommst du unabhängig von der Stufe.

Control Plane down ≠ Apps down

Der am häufigsten missverstandene Fakt über Managed Kubernetes – und der, den du verinnerlichen solltest:

Deine Workloads laufen nicht auf der Control Plane. Sie laufen auf deinen Worker-Nodes, in deinem Hetzner-Projekt. Ist die Control Plane nicht verfügbar – ein Neustart in der Basic-Stufe, Wartung, ein Incident – laufen Pods, die bereits laufen, weiter und bedienen weiter Traffic. Deine Load Balancer leiten weiter. Was pausiert, ist das Management: Deploys, Skalierungsänderungen, Rescheduling, neue Nodes. Kommt die Control Plane zurück, holt die Reconciliation auf.

Die praktische Auswirkung einer kurzen Control-Plane-Pause auf eine laufende Anwendung ist deshalb meist: nichts, was deine Nutzer bemerken. Das ist der ehrliche Grund, warum Basic für tolerante Produktion sicher ist – und der ehrliche Grund, warum HA zählt, wenn du kontinuierlich deployst oder darauf angewiesen bist, dass Autoscaling binnen Minuten reagiert.

Zwei Grenzen, damit die Geschichte vollständig ist: Die Gesamtverfügbarkeit ist auch durch die Infrastruktur darunter begrenzt (Hetzner bietet für Cloud-Server keine starken Verfügbarkeitszusagen) und durch die Redundanz deiner eigenen Worker – ein Ein-Node-Cluster hat eine Ein-Node-Fehlerdomäne, egal was die Control Plane tut. Replikas über Nodes zu verteilen ist das Terrain des Scaling-Guides.

Was wir zusagen – und was wir noch nicht veröffentlichen

Die AGB sagen für die Steuerungsebene eine Verfügbarkeit von

95,8 % im Kalendermonat je Cluster zu, gemessen als Erreichbarkeit des Kubernetes-API-Servers, mit geplanter Wartung von höchstens vier Stunden pro Woche und 24 Stunden Vorankündigung. Wird die Quote unterschritten, gibt es eine Service-Gutschrift nach veröffentlichter Staffel.

Diese Zahl ist bewusst zurückhaltend, und wir erklären sie lieber, als sie schönzureden: PAASBOX ist ein Ein-Personen-Betrieb ohne durchgehende Rufbereitschaft – wir sagen zu, was wir auch nachts und am Wochenende halten können. Wichtig ist, was die Zahl abdeckt und was nicht: Ist die Steuerungsebene nicht erreichbar, laufen deine Workloads weiter; aus sind Deployments, Skalierung und Cluster-Änderungen.

Was wir weiterhin nicht veröffentlichen, sind gemessene Verfügbarkeitswerte (Stand: 2026-07-09). Junge Plattformen, die große Zahlen zitieren, betreiben Marketing, kein Engineering – wir veröffentlichen lieber gemessene Werte, sobald eine aussagekräftige Betriebshistorie dahintersteht. Bis dahin sagt dir diese Seite genau, wie sich das System verhält, wenn etwas ausfällt; daran kannst du uns messen.

Fragen, die diese Seite nicht beantwortet? Frag uns – und wie Zugangsdaten und Tokens geschützt sind, steht unter Sicherheit & Vertrauen.