Noch zwei Monate bis zum Support-Ende von PostgreSQL 14: Wiederherstellung vor dem Upgrade üben
Es gibt Teams, die zwar einen Zeitplan für das Upgrade ihrer Datenbankversion festgelegt haben, aber nicht wissen, wie viel Zeit ein Rollback im Fehlerfall in Anspruch nimmt. Wenn Sie PostgreSQL 14 betreiben, ist das jetzt benötigte Arbeitsergebnis mehr als nur der Name einer neuen Version: Es ist ein wiederherstellbarer Migrationsplan. Zum Stichtag 14. September 2026 verbleiben noch etwa zwei Monate bis zum offiziellen Support-Ende.
Bestätigte Fakten: Community-Support und Hosting-Verträge unterscheiden sich
Die offizielle Versionsrichtlinie von PostgreSQL sieht eine fünfjährige Unterstützung für Hauptversionen vor und gibt den 12. November 2026 als Datum für das finale Release von Version 14 an. Dies ist der Zeitplan für den Community-Support. Upgrade-Fenster, separater erweiterter Support und anfallende Gebühren für Managed Services müssen gesondert in der Dokumentation und den Verträgen des jeweiligen Anbieters geprüft werden.
Zudem muss zwischen Minor-Updates derselben Hauptversion und Major-Upgrades unterschieden werden. Das Einspielen der neuesten Korrekturversion von 14 ersetzt nicht den Umstieg auf Version 15 oder höher. Umgekehrt ist es nicht ratsam, notwendige Fehlerbehebungen für die aktuelle Version mit dem Verweis auf einen geplanten Versionswechsel fortlaufend aufzuschieben.
Erstes Arbeitsergebnis: Abhängigkeitsliste statt Datenmenge
Ab hier folgen praxisbezogene Betriebsempfehlungen und keine offiziellen Support-Richtlinien. Dokumentieren Sie zunächst auf einer Seite die Datenbankversion jedes Dienstes, die Erweiterungsmodule samt Versionen, Verbindungstreiber, Batch-Jobs, Backup-Speicherorte und die Replikationskonfiguration. Bestimmen Sie die Zielversion nicht allein deshalb, weil sie die neueste ist, sondern prüfen Sie zugleich die tatsächliche Hosting-Umgebung und den Supportumfang der Erweiterungen.
Die Annahme, eine kleine Datenbank lasse sich schnell migrieren, greift zu kurz. Wenn sich Erweiterungen oder Abfragen ändern, die in geschäftskritischen Pfaden – wie der ersten Abfrage nach dem Login oder der Aktualisierung des Zahlungsstatus – genutzt werden, kann die Migration selbst bei kurzer Datenkopierzeit scheitern. Das Ziel dieser Liste besteht darin, Abhängigkeiten aufzuspüren, für die niemand die Verantwortung trägt.
Zweites Arbeitsergebnis: Wiederherstellungsergebnis statt Backup-Erfolgsmeldung
Stellen Sie ein aktuelles Backup in einer isolierten Umgebung wieder her und führen Sie die typischen Lese- und Schreibabläufe der Anwendung aus. Bei dieser Übung muss zuerst das Verbindungsziel überprüft werden, um sicherzustellen, dass keine Schreibvorgänge an die Produktionsdatenbank gesendet werden. Wiederhergestellte Kopien mit echten Daten sind im Rahmen der bestehenden Zugriffskontrollen zu handhaben.
Wenn Sie den Beginn des Backups, den Abschluss der Wiederherstellung und den Abschluss der Validierung separat erfassen, verwechseln Sie die Zeit für den Dateitransfer nicht mit der Zeit, ab der der Dienst wieder schreibfähig ist. Messen Sie die Zeiten anhand einer Wiederherstellungskopie, die der Produktionsgröße nahekommt, anstatt nur künstlich schnelle, kleine Stichproben durchzuwinken, und dokumentieren Sie auch Kosten- und Speicherplatzbeschränkungen.
Ein erfolgreicher pg_upgrade-Check ersetzt keine Service-Validierung
Die offizielle Dokumentation zu pg_upgrade erklärt, dass mit --check vor dem eigentlichen Upgrade eine Kompatibilitätsprüfung durchgeführt werden kann. Die Kompatibilität externer Module muss gesondert geprüft werden, und es werden auch Shared Libraries benötigt, die zum neuen Server passen. Deuten Sie den Erfolg des Prüfbefehls keinesfalls so, als seien Anwendungsabfragen und Leistung bereits vollständig verifiziert.
Insbesondere bei der Option --link besteht die Einschränkung, dass der alte Cluster nach dem Start des neuen Clusters nicht mehr unverändert weiterverwendet werden kann. Wer sich nur aufgrund der Geschwindigkeit für dieses Verfahren entscheidet, riskiert, dass der vorgesehene Rollback-Pfad verloren geht. Führen Sie die Probe unter identischen Bedingungen wie bei der tatsächlichen Migration durch und legen Sie genau fest, ab welchem Zeitpunkt ein Rollback auf Basis einer Wiederherstellung erforderlich ist.
Kriterien, die vor der Wiederaufnahme von Schreibvorgängen festzulegen sind
Legen Sie die Erfolgskriterien vorab schriftlich fest, um Ad-hoc-Absprachen am Tag der Umstellung zu vermeiden. Beispielsweise können der erfolgreiche Abschluss von Lese- und Schreibvorgängen wichtiger APIs, die Wiederaufnahme von Batch-Läufen ohne Doppelverarbeitung, übereinstimmende betriebliche Aggregationen in zentralen Tabellen und die Überprüfung des Replikationsstatus bestimmten Verantwortlichen zugewiesen werden. Dies dient als Orientierung und soll nicht jedem Dienst identische Schwellenwerte aufzwingen.
Sobald auf der neuen Datenbank Schreibvorgänge begonnen haben und anschließend auf ein früheres Backup zurückgegriffen werden muss, stellt sich die Frage, wie die zwischenzeitlichen Änderungen bewahrt werden können. Das bloße Hochfahren des alten Servers darf nicht mit einem geordneten Rollback ohne Datenverlust gleichgesetzt werden. Der zulässige Rahmen für Datenverlust und Ausfallzeiten muss von den Serviceverantwortlichen einvernehmlich beschlossen werden.
Aufgaben für diese Woche und Gegenargumente
Wenn es schwierig ist, alle Datenbanken auf einmal zu migrieren, messen Sie die Zeiten für Wiederherstellung, Validierung und Rollback zunächst an einem Dienst mit den geringsten Abhängigkeiten und nutzen Sie die Ergebnisse als Grundlage für die Planung weiterer Dienste. Wenn Verantwortliche, Zieltermine für die Migration und Abbruchkriterien bei fehlgeschlagener Validierung in einem einzigen Dokument gebündelt werden, verwandelt sich ein Projekt, das bislang nur aus Terminen bestand, in konkrete, ausführbare Arbeitspakete.
Der Einwand, die Produktentwicklung habe derzeit höhere Priorität, ist nachvollziehbar. Bleibt die Wiederherstellungsprozedur jedoch bis kurz vor Ablauf der Frist ungeklärt, schrumpft das Zeitfenster für notwendige Überprüfungen drastisch. Dieser Artikel erhebt keinen Anspruch auf allgemeine Leistungsversprechen bestimmter Versionen oder die Meinung der gesamten Community. Es handelt sich um operative Vorschläge, bei denen die Vorbereitung auf einen Migrationsfehlschlag wichtiger ist als das Tempo bei der Einführung neuer Funktionen.