Datenbankumstieg, Teil 2: Souveräne Datenbank auf dem eigenen Ubuntu-Server PostgreSQL 18/19 installieren, absichern und verwalten

Behörden und Unternehmen ersetzen Oracle und Microsoft SQL Server immer mehr durch eine quelloffene Datenbank unter eigener Kontrolle. PostgreSQL auf einem Ubuntu-Server folgt einer festen Reihenfolge aus Einrichtung, Absicherung, Sicherung und laufender Verwaltung im produktiven Betrieb.

Der Umstieg auf quelloffene Datenbanken in der öffentlichen Verwaltung stützt sich inzwischen auf einen finanziellen und einen rechtlichen Grund. Schleswig-Holstein beziffert die jährliche Einsparung bei Lizenzkosten nach der Abkehr von Microsoft auf mehr als 15 Millionen Euro. Die einmalige Investition von neun Millionen Euro für die Migration amortisiert sich dadurch binnen eines Jahres. Seit Juli 2026 bewerten öffentliche Auftraggeber Aspekte der digitalen Souveränität ausdrücklich als Zuschlagskriterium, verankert im neuen Paragraphen 58 der Vergabeverordnung durch das Vergabebeschleunigungsgesetz. PostgreSQL gilt damit als bevorzugte Ablösung für Oracle Database und Microsoft SQL Server in vielen Projekten. Die Installation und die Verwaltung auf einem Ubuntu-Server bauen auf den Grundlagen des ersten Teils dieser Reihe auf.

Bildergalerie

Das PGDG-Repository liefert die aktuelle Version

Ubuntu bindet in jedem Release eine feste PostgreSQL-Version ein, die über den gesamten Lebenszyklus dieser Distribution stabil bleibt. Ubuntu 24.04 LTS liefert im Archiv PostgreSQL 16; Ubuntu 26.04 LTS mit dem Codenamen Resolute stellt PostgreSQL 18 direkt bereit. Für eine über alle Distributionen einheitliche Hauptversion führt der Weg über das Apt-Repository der PostgreSQL Global Development Group (PGDG). Es baut Serverpakete, Erweiterungen und Module für die unterstützten Ubuntu-Releases von 22.04 bis 26.04.

Die Einrichtung des Repositorys übernimmt ein mitgeliefertes Skript. Nach der Installation des Pakets „postgresql-common“ bindet der Aufruf die passende Paketquelle für das laufende Ubuntu-Release ein und importiert den Signierschlüssel:

Die Option „-y“ bestätigt die Paketinstallation ohne Rückfrage. Das Skript erkennt das Release automatisch und trägt die passende Suite in die Paketquellen ein, unter Ubuntu 26.04 die Suite „resolute-pgdg“. Nach der Installation startet der Dienst automatisch. Eine Kontrolle des Status bestätigt den laufenden Betrieb:

Der Datenbank-Cluster liegt unter „/var/lib/postgresql/18/main“, die Konfigurationsdateien unter „/etc/postgresql/18/main“. Ein erster Zugang gelingt über den Systembenutzer „postgres“, den die Installation anlegt:

Innerhalb der Sitzung gibt der Befehl „SELECT version();“ die installierte Serverversion aus. Der Metabefehl „\q“ beendet die Sitzung.

Grundkonfiguration und Cluster-Verwaltung

Die zentrale Konfigurationsdatei „postgresql.conf“ steuert Netzwerk, Speicher und Protokollierung. Auf Debian- und Ubuntu-Systemen verwaltet das Paket „postgresql-common“ mehrere Cluster parallel. Der Befehl „pg_lsclusters“ listet alle vorhandenen Instanzen mit Version, Port und Status; „pg_createcluster“ und „pg_dropcluster“ legen weitere Cluster an oder entfernen sie.

Ab Werk akzeptiert der Dienst nur lokale Verbindungen, da die Einstellung „listen_addresses“ auf „localhost“ steht. Ein Zugriff aus dem Netzwerk verlangt eine explizite Freigabe:

Die Einstellung „listen_addresses“ nimmt einzelne IP-Adressen oder den Wert „*“ für alle Schnittstellen auf. Eine Bindung an die konkrete Server-Adresse begrenzt die Angriffsfläche gegenüber der Freigabe für alle Schnittstellen. Eine Änderung an „listen_addresses“ wird erst nach einem Neustart des Dienstes über „sudo systemctl restart postgresql“ wirksam.

PostgreSQL 18 führt ein asynchrones I/O-Subsystem ein, das Lesezugriffe bei sequenziellen Scans und beim Vacuum bündelt. Der Parameter „io_method“ steht ab Werk auf dem Wert „worker“, der Hintergrundprozesse für die Ein- und Ausgabe nutzt. Auf Linux-Kerneln ab Version 5.1 aktiviert der Wert „io_uring“ die kernelseitige Schnittstelle für höheren Durchsatz. Der Befehl „SHOW io_method;“ gibt die aktive Einstellung aus.

Rollen und Rechte nach dem Minimalprinzip

PostgreSQL verwaltet Zugriffe über Rollen, die sowohl Benutzer als auch Gruppen abbilden. Die Installation legt die Superuser-Rolle „postgres“ an. Ein produktiver Betrieb vergibt für diese Rolle zuerst ein Passwort:

Für Anwendungen dienen eigene Rollen mit begrenzten Rechten. Das Attribut „LOGIN“ erlaubt die Anmeldung, ohne dieses Attribut fungiert die Rolle als reine Gruppe:

Die Rechtevergabe folgt dem Minimalprinzip, das jeder Rolle nur die für ihre Aufgabe nötigen Rechte zuweist. Ein Lesezugriff auf einzelne Tabellen genügt oft, ein Vollzugriff auf die Datenbank bleibt der Eigentümer-Rolle vorbehalten:

Ab PostgreSQL 15 besitzt die Standardrolle „public“ keine Schreibrechte mehr im Schema „public“, was versehentliche Freigaben verhindert. Für Gruppenrechte bündelt eine Rolle ohne „LOGIN“ mehrere Konten, denen sich die Gruppenrolle über „GRANT gruppe TO konto“ zuweisen lässt.

Bildergalerie

Absicherung über pg_hba.conf und TLS

Die Client-Authentifizierung steuert die Datei „pg_hba.conf“ im Konfigurationsverzeichnis. Jede Zeile beschreibt eine Regel aus Verbindungstyp, Datenbank, Rolle, Herkunftsadresse und Methode. Die erste passende Regel gewinnt, weshalb die Reihenfolge über die Wirkung entscheidet.

Als Methode empfiehlt sich scram-sha-256, das Passwörter über ein Challenge-Response-Verfahren prüft und keine Klartext-Übertragung zulässt. Die Methode „trust“ erlaubt Verbindungen ohne Passwort und bleibt lokalen Testumgebungen vorbehalten, niemals dem Netzwerkzugriff. Der Verbindungstyp „hostssl“ erzwingt eine verschlüsselte Verbindung über TLS:

Die erste Regel lässt verschlüsselte Verbindungen der Rolle „app_user“ aus dem Subnetz 192.168.10.0/24 zu. Die zweite Regel weist alle übrigen Verbindungen ab. Eine explizite Ablehnung am Ende schließt ungewollte Zugänge aus.

Die verschlüsselte Verbindung verlangt ein aktiviertes TLS. Der Parameter „ssl“ steht dazu in der postgresql.conf auf „on“, ergänzt um Pfade zu Zertifikat und privatem Schlüssel:

Auf Netzwerkebene begrenzt die Firewall ufw den Zugriff auf den PostgreSQL-Port. Eine Freigabe nur für das interne Subnetz reduziert die erreichbaren Clients:

Sicherung und Wiederherstellung mit Bordmitteln

Für logische Sicherungen einzelner Datenbanken schreibt „pg_dump“ einen konsistenten Auszug, auch bei aktiven Verbindungen (https://www.postgresql.org/docs/current/backup-dump.html). Das benutzerdefinierte Format erlaubt eine selektive Wiederherstellung einzelner Tabellen:

Der Parameter „-F c“ wählt das komprimierte Custom-Format, „-f“ bestimmt die Zieldatei. Rollen und globale Objekte über alle Datenbanken sichert „pg_dumpall --globals-only“. Die Rücksicherung aus dem Custom-Format übernimmt „pg_restore“:

Eine physische Sicherung des gesamten Clusters erstellt „pg_basebackup“. In Verbindung mit archivierten Write-Ahead-Logs (WAL) ermöglicht sie eine Wiederherstellung auf einen bestimmten Zeitpunkt, die Point-in-Time-Recovery (PITR). Der Parameter „archive_command“ in der postgresql.conf kopiert jedes abgeschlossene WAL-Segment in ein Archivverzeichnis. Bei der Wiederherstellung bestimmt „recovery_target_time“ den Zielzeitpunkt.

Große Datenbanken mit langer Aufbewahrung verwalten Zusatzwerkzeuge. Das Programm „pgBackRest“ steuert inkrementelle Sicherungen, Parallelität und Aufbewahrungsregeln über einen systemd-Timer. Für die digitale Souveränität lagern viele Betreiber die Sicherungen auf einen S3-kompatiblen Speicher innerhalb der EU aus. Eine Rücksicherung gilt erst dann als gesichert, wenn eine regelmäßige Testwiederherstellung sie überprüft.

Speicherparameter für den produktiven Betrieb

Die Standardwerte von PostgreSQL zielen auf breite Kompatibilität, nicht auf maximale Leistung. Der Parameter „shared_buffers“ bestimmt den Speicher für das gemeinsame Puffer-Cache und liegt als Faustregel bei rund einem Viertel des Arbeitsspeichers. Ein größerer Wert hält mehr Datenblöcke im Arbeitsspeicher und senkt die Zahl der Festplattenzugriffe. Die Einstellung „effective_cache_size“ teilt dem Planer mit, wie viel Speicher das Betriebssystem für Caching bereitstellt; üblich sind 50 bis 75 Prozent des Arbeitsspeichers.

Der Parameter „work_mem“ bemisst den Speicher pro Sortier- oder Hash-Vorgang. Ein zu hoher Wert summiert sich bei vielen parallelen Verbindungen zu einem Vielfachen und führt zu Speicherengpässen. Die Einstellung „maintenance_work_mem“ gilt für Wartungsvorgänge, darunter den Aufbau von Indizes, und darf höher ausfallen, da solche Vorgänge selten gleichzeitig stattfinden.

PostgreSQL 18 ergänzt den Parameter „autovacuum_vacuum_max_threshold“, der eine feste Obergrenze für tote Zeilen setzt. Der Standardwert liegt bei 100 Millionen Zeilen. Bei sehr großen Tabellen greift der prozentuale Schwellenwert erst spät, sodass sich viele tote Zeilen ansammeln. Die feste Obergrenze löst den Autovacuum früher aus und begrenzt das Aufblähen der Tabelle. Der Wert „-1“ schaltet die Obergrenze ab.

Monitoring über die Statistik-Views

Der produktive Betrieb liefert Kennzahlen über die kumulativen Statistik-Views. Die View „pg_stat_activity“ zeigt aktive Verbindungen, aktuelle Abfragen und Wartezustände. Eine hohe Zahl blockierter Verbindungen deutet auf Sperren oder lang andauernde Transaktionen hin.

Detaillierte Abfrage-Statistiken liefert die Erweiterung „pg_stat_statements“. Sie verlangt einen Eintrag in „shared_preload_libraries“ und einen Neustart des Dienstes:

Nach dem Neustart aktiviert der Befehl „CREATE EXTENSION pg_stat_statements;“ die Erweiterung in der Zieldatenbank. Sie sammelt Ausführungszeiten und Aufrufzahlen je Abfrage und deckt die teuersten Statements auf.

Für den Zustand der Tabellen zählt die Rate toter Zeilen. Ein hoher Anteil toter gegenüber lebenden Zeilen zeigt an, dass der Autovacuum die toten Zeilen nicht schnell genug entfernt. Die Trefferquote der Indizes und die Auslastung der Verbindungen bilden weitere Kennzahlen für Alarmschwellen.

Bildergalerie

Ausblick auf Hochverfügbarkeit

Über einen einzelnen Server hinaus sichert Streaming-Replikation die Verfügbarkeit. Der Parameter „wal_level“ steht dazu auf dem Wert „replica“, der die nötigen Informationen in den Write-Ahead-Logs bereitstellt. Ein Standby-Server erhält seine erste Vollkopie über „pg_basebackup“.

Der Parameter „-R“ beim Aufruf von „pg_basebackup“ schreibt die Verbindungsdaten zum primären Server in die Konfiguration und legt die Datei „standby.signal“ an. Die Datei „standby.signal“ kennzeichnet die Instanz als Stand-by, der die Write-Ahead-Logs des primären Servers ständig nachspielt. Ein solcher Stand-by dient als Lesekopie oder übernimmt bei einem Ausfall den Betrieb.

Fazit

PostgreSQL 18 auf einem Ubuntu-Server bildet eine belastbare Grundlage für die Ablösung proprietärer Datenbanken unter eigener Kontrolle. Die feste Reihenfolge aus Installation über das PGDG-Repository, Absicherung mit scram-sha-256 und TLS, geprüften Sicherungen und kontinuierlichem Monitoring führt zu einem stabilen Betrieb. Die neuen Parameter für asynchrones I/O und den Autovacuum halten auch große Datenbanken beherrschbar. Mit archivierten Write-Ahead-Logs und Streaming-Replikation deckt die quelloffene Datenbank Anforderungen an Wiederherstellbarkeit und Verfügbarkeit ab, die sonst kostenpflichtige Zusatzmodule verlangen.

Aktuelles E-Book

Open-Source-Storage – Speicher-Software zum Nulltarif

Der Bedarf an Speicherkapazität steigt von Tag zu Tag – nicht nur, um die Daten von Produkten, Kunden und Transaktionen zu sichern, sondern auch, um Compliance-Anforderungen zu erfüllen und Auditierungen gut zu überstehen. Eine leistungsfähige Storage-Lösung ist also gefragt. Eine kostenlose Option bietet Open-Source-Software für Storage, insbesondere dann, wenn man sie selbst den eigenen Anforderungen anpassen darf.

Die Themen im Überblick:

• Warum Storage als Open Source?
• NAS & Objektspeicher
• Backup & Disaster Recovery
• Dateisysteme
• Technologiestapel & Ökosysteme

E-Book „Open-Source-Storage“ kostenlos downloaden

(ID:50903033)