PostgreSQL · Patroni · CloudNativePG · pgBackRest
Ihre Anwendungen hängen an PostgreSQL, der Betrieb soll nicht an einzelnen Personen hängen. SKAFFON betreibt Cluster mit automatischem Failover, Backups mit Point-in-Time-Recovery, Monitoring und Wartung, rund um die Uhr.
01Ausgangslage
Failover, der wirklich umschaltet. Backups, die sich nachweislich einspielen lassen. Major-Upgrades ohne Überraschungen. Wartung ohne unnötigen Ausfall. Das ist der Teil, der nach der Installation bleibt, und genau diesen Teil übernimmt SKAFFON für Ihre PostgreSQL-Datenbanken.
Der Service richtet sich an IT-Leitung und Plattformverantwortliche, deren Anwendungen von PostgreSQL abhängen. Betrieb und Support laufen 24/7; Reaktionszeiten und Kennzahlen werden vertraglich festgelegt.
Betreibbar ist das auf STACKIT, AWS, Azure, GCP sowie auf eigener Infrastruktur, etwa auf Proxmox. Für die umgebende Cloud-Umgebung siehe Cloud-Betrieb, für Kubernetes-Cluster Managed Kubernetes; die Einordnung steht unter Managed Services.
02Architektur
Das Bild zeigt die Patroni-Variante: drei Knoten in drei Verfügbarkeitszonen mit verteiltem Konsensspeicher. Für CloudNativePG auf Kubernetes gilt dasselbe Grundmuster aus Failover, einem vom Knoten getrennten Backup-Repository und dem Restore in einen neuen Cluster.
03Variantenwahl
Beide Varianten sind für Produktion vorgesehen. Welche passt, hängt von Ihrer Plattform, vorhandenem Know-how, Speichermodell und den Anforderungen an die Wiederherstellung ab. Wir legen sie gemeinsam in der Bestandsaufnahme fest.
| Aspekt | Patroni auf virtuellen Maschinen | CloudNativePG auf Kubernetes |
|---|---|---|
| Steuerung | Patroni verwaltet den Cluster und wählt über einen verteilten Konsensspeicher (etwa etcd) den Primary. | Der Operator beschreibt den Cluster deklarativ: Primary, Replikas, Services, Failover, Rolling-Updates. |
| Anwendungszugriff | Eine Verbindungsschicht leitet Anwendungen auf den aktuellen Primary. | Services für Lese- und Schreibzugriff. |
| Backup | pgBackRest: vollständige, differenzielle und inkrementelle Backups sowie WAL-Archivierung. | Laut CloudNativePG-Dokumentation über das Barman-Cloud-Plugin in Objektspeicher (Base-Backups mit WAL-Archivierung, PITR) oder über Kubernetes Volume Snapshots. |
| Geeignet, wenn | Sie VM-basierte Infrastruktur haben oder bewusst keine Kubernetes-Abhängigkeit für die Datenbank wollen. | Ihre Plattform ohnehin auf Kubernetes basiert, siehe Managed Kubernetes. |
04Betriebsumfang
Aufbau und Betrieb auf virtuellen Maschinen (Patroni) oder auf Kubernetes (CloudNativePG).
Automatische Umschaltung bei Ausfall des Primary, dazu regelmäßige Failover-Tests.
Wiederherstellung aus Backups, einschließlich Klon-Wiederherstellung zur Prüfung in einer getrennten Umgebung.
Point-in-Time-Recovery auf Basis archivierter WAL-Segmente: zurück auf einen gewählten Zeitpunkt vor einem Fehler.
Überwachung von Abfragelaufzeiten, Locks, Verbindungen und Speicher; Hinweise zu Indizes und Parametern; Vacuum-Verhalten und Bloat-Beobachtung.
Rollen- und Rechtekonzept, verschlüsselte Verbindungen, Patching, Härtung der Konfiguration, Zugriffsprotokolle. Vertiefung unter Cloud Security.
05Monitoring
Prometheus erfasst Verfügbarkeit, Replikationsverzug, Verbindungen, Speicher, langsame Abfragen, WAL-Archivierung und Backup-Status. Alarmiert wird auf Datenbankebene, nicht erst, wenn die Anwendung klagt.
Der Betriebsbericht fasst zusammen, was in der Datenbankplattform passiert ist:
06Restore-Verfahren
Ein Backup gilt erst dann als belegt, wenn ein Restore gelungen ist. So gehen wir regelmäßig und nach größeren Änderungen vor.
Zeitpunkt oder Ereignis, auf den wiederhergestellt werden soll (zum Beispiel kurz vor einer fehlerhaften Änderung), und Umfang.
Wiederherstellung in einer getrennten Umgebung oder einem neuen Cluster, nie über die Produktion drüber.
Basis-Backup einspielen, WAL bis zum Zielzeitpunkt abspielen.
Datenbank startet sauber, Integritäts- und Plausibilitätsprüfungen laufen, Stichproben der Anwendungsdaten.
Wo möglich, eine Testinstanz der Anwendung gegen die wiederhergestellte Datenbank.
Dauer der Wiederherstellung und Befunde dokumentieren; daraus ergibt sich, ob die vereinbarten Ziele erreichbar sind.
Befunde abstellen und das Runbook anpassen.
Ein Fehler in den Daten wird mitrepliziert. Replikation schützt vor dem Ausfall eines Knotens. Vor Datenfehlern und versehentlichem Löschen schützen nur Backup und PITR. Das Ergebnis jedes Restore-Tests steht als Testprotokoll in Ihrem Monatsbericht.
07Wiederherstellungsziele
Backups und WAL-Archiv liegen in einem vom Datenbankknoten getrennten Speicher. Konkrete Ziele für Datenverlust (RPO) und Wiederherstellungszeit (RTO) vereinbaren wir je Datenbank im Vertrag und weisen sie per Restore-Test nach.
| Ziel | Wird vor allem bestimmt durch |
|---|---|
| RPO: wie viel Datenverlust ist tolerierbar | WAL-Archivierung, Backup-Rhythmus und Replikationsmodus (synchron oder asynchron) |
| RTO: wie lange dauert die Wiederherstellung | Datenvolumen, Geschwindigkeit des Backup-Speichers, Topologie und Automatisierungsgrad des Failovers |
| Nachweis | Dauer und Befund des Restore-Tests, festgehalten im Monatsbericht |
Ob die vereinbarten Ziele für Ihr System erreichbar sind, belegt erst der Restore-Test mit Ihrer Datenbank.
08Wartung
Minor-Updates spielen wir im Wartungsfenster als Rolling-Update ein: zuerst auf den Replikas, dann Umschaltung (Switchover), dann der frühere Primary. Major-Upgrades sind eigene, geplante Vorhaben mit Test auf einer Kopie, Rückfallplan und Abnahme. Dringende Sicherheitsupdates stimmen wir mit Ihnen außerhalb des Regelzyklus ab.
Changes laufen als Konfiguration im Code: Review, Einstufung, Freigabe durch Sie, Umsetzung durch SKAFFON, Verifikation, Rückfallplan vorher.
Incidents folgen einem festen Ablauf: Alarm oder Meldung, Priorisierung, Eingrenzung, Behebung oder Workaround (zum Beispiel manueller Failover), Statusinformation, Abschluss mit Ihrer Bestätigung, bei schwerwiegenden Störungen Ursachenanalyse.
09Verantwortung
R = führt aus, A = trägt die Ergebnisverantwortung, C = wird konsultiert, I = wird informiert. Standardaufteilung, vertraglich anpassbar.
| Tätigkeit | SKAFFON | Kunde |
|---|---|---|
| Cluster-Topologie und Konfiguration betreiben | R/A | C |
| Minor-Updates und Sicherheitspatches | R | A (Freigabe Fenster) |
| Major-Upgrade planen und durchführen | R | A |
| Monitoring und Alarmierung betreiben | R/A | I |
| Störung auf Datenbank-/Cluster-Ebene (Failover, Replikation, Speicher) | R/A | I |
| Backup einrichten, WAL-Archivierung betreiben | R/A | C |
| Restore-Tests durchführen | R/A | C |
| Wiederherstellung im Ernstfall durchführen | R | A (Entscheidung über Zeitpunkt) |
| Schema, Migrationen, Datenmodell | C | R/A |
| Langsame Abfragen der Anwendung ändern | C | R/A |
| Index- und Parameterempfehlungen | R | A (Freigabe) |
| Datenbankrollen technisch umsetzen | R | A |
| Fachliche Zugriffsentscheidung | C | R/A |
| Datenklassifizierung, Löschfristen, Datenschutz | C | R/A |
| Kapazitätsplanung, Berichte | R | A |
Der Inhalt der Daten und die Anwendung bleiben in Ihrer Verantwortung. Wir verantworten den Betrieb der Datenbankplattform.
10Servicezeiten
Betrieb und Support laufen 24/7. Störungen werden nach Priorität eingestuft, etwa Datenbank nicht erreichbar, Replikation gestört oder Leistungsabfall. Die Prioritätsstufen P1 bis P4 und die Bedeutung der Reaktionszeit stehen im Servicelevel-Rahmen; Reaktionszeiten und Eskalationskette legt der Vertrag fest. Kontaktwege testen wir im Onboarding mit Ihnen.
Verfügbarkeitsziele vereinbaren wir je Plattform; sie hängen von der Topologie (Anzahl Knoten, Verteilung über Zonen), dem Replikationsmodus und den Wartungsfenstern ab. Kennzahlen, Messmethode und Folgen bei Abweichung werden vertraglich vereinbart; die Systematik beschreibt der Servicelevel-Rahmen.
11Einstieg
Wir starten mit einer Bestandsaufnahme und legen daraus Umfang, RACI und Berichtsrhythmus fest. Danach folgen Zielarchitektur, Aufbau oder Übernahme des Clusters, Monitoring und Backup, der erste Restore-Test und der Übergang in den Regelbetrieb.
12Abgrenzung
Vorab die Grenzen des Service, damit Sie früh wissen, ob er zu Ihrer Datenbank passt.
13
Nein. Replikation schützt vor Ausfall eines Knotens, nicht vor Datenfehlern oder versehentlichem Löschen. Dafür sind Backup und PITR zuständig.
Das hängt von Ihrer Plattform ab: auf VMs meist Patroni, auf Kubernetes CloudNativePG. Wir entscheiden das mit Ihnen nach der Bestandsaufnahme.
Ja, nach einer Bestandsaufnahme von Version, Konfiguration, Backups und Risiken.
Beschreiben Sie uns Ihre Datenbanken und Anforderungen. Rückfragen vorab beantworten wir über den Kontakt.