PostgreSQL ist ein relationales Open-Source-Datenbankmanagementsystem. Viele Webanwendungen (Django, Laravel, Nextcloud, n8n, Gitea) funktionieren auch mit PostgreSQL, einige (Odoo, Mastodon) sogar ausschließlich damit. Auf einem eigenen KVM-VPS lässt es sich innerhalb weniger Minuten aus dem Repository der Distribution oder aus dem eigenen Repository des PostgreSQL-Projekts (PGDG) installieren.

Dieser Artikel führt Sie durch die Installation unter AlmaLinux und Ubuntu sowie durch die gemeinsamen Schritte: Erstellung von Benutzern und Datenbanken, Anmeldung mit Passwort, Fernzugriff, Datensicherung und Wechsel der Hauptversion. Die Schritte wurden im November 2026 auf den Systemen AlmaLinux 10.2, AlmaLinux 9.8 und Ubuntu 26.04 getestet. Führen Sie die Befehle mit einem Benutzer aus, der über sudo-Rechte verfügt (siehe: Benutzer anlegen und sudo-Rechte zuweisen).

Wenn die Anwendung in einem Docker-Container läuft, kann auch PostgreSQL in einem eigenen Container neben ihr betrieben werden – und zwar über eine einzige compose.yaml-Datei: Dies wird in dem Artikel zur Verwendung von Docker Compose erläutert. Falls Sie eine MySQL-kompatible Datenbank benötigen, haben wir die Installation von MariaDB in einem separaten Artikel beschrieben.

Woher stammt welche Version?

Zum Zeitpunkt des Tests war die neueste Hauptversion von PostgreSQL die Version 18 (18.6); das Projekt unterstützte die Hauptversionen 14 bis 18 (die Version 14 bis zum 12. November 2026). Jede Hauptversion erhält fünf Jahre lang Patches.

System	Im Repository des Systems	Im PGDG-Repository
AlmaLinux 10	PostgreSQL 16 (postgresql-server), PostgreSQL 18 (postgresql18-server)	14–18
AlmaLinux 9	PostgreSQL 13 (Standard), 15, 16 und 18 (Module postgresql:15, :16 und :18)	14–18
Ubuntu 26.04	PostgreSQL 18	10–18
Ubuntu 24.04	PostgreSQL 16	10–18
Debian 13	PostgreSQL 17	10–18

Die Zeilen für Ubuntu 24.04 und Debian 13 haben wir anhand der Paketlisten ausgefüllt; auf diesen Systemen wurde keine Installation vorgenommen. Im PGDG-Repository erhalten Hauptversionen älter als 14 keine Updates mehr.

Für welche Option sollten Sie sich entscheiden?

• Das Repository des Systems, sofern die darin enthaltene Hauptversion mit der Anwendung kompatibel ist. Unter AlmaLinux 10 und 9 sowie unter Ubuntu 26.04 stammt auch die Hauptversion 18 von hier. Die Pakete werden durch das System-Update aktualisiert, und unter AlmaLinux gelten für sie zudem die SELinux-Regeln (siehe weiter unten).
• Verwenden Sie das PGDG-Repository (yum.postgresql.org, apt.postgresql.org), wenn die gewünschte Hauptversion nicht im System-Repository vorhanden ist (beispielsweise PostgreSQL 18 unter Ubuntu 24.04 oder eine ältere Hauptversion aufgrund einer Anwendung) oder wenn Sie mehrere Hauptversionen parallel betreiben möchten. Im PGDG sind alle unterstützten Hauptversionen verfügbar.

A) Installation unter AlmaLinux

Aus dem Repository des Systems

Unter AlmaLinux 10 ist PostgreSQL 18 unter einem separaten, versionsspezifischen Paketnamen verfügbar (es gibt kein Modul):

sudo dnf install postgresql18-server

Der Befehl sudo dnf install postgresql-server würde die Hauptversion 16 installieren. Die beiden Pakete schließen sich gegenseitig aus.

Unter AlmaLinux 9 muss ein Modul ausgewählt werden, andernfalls wird Version 13 installiert:

sudo dnf module enable postgresql:18
sudo dnf install postgresql-server

Das Datenverzeichnis (das „Cluster“) muss unter AlmaLinux manuell angelegt und der Dienst gestartet werden:

sudo postgresql-setup --initdb
sudo systemctl enable --now postgresql

Der Name des Dienstes lautet postgresql, das Datenverzeichnis ist /var/lib/pgsql/data, darin befinden sich auch die Konfigurationsdateien (postgresql.conf, pg_hba.conf). Das Protokoll befindet sich im Verzeichnis /var/lib/pgsql/data/log/ in Dateien, die nach den Wochentagen benannt sind (z. B. postgresql-Sun.log). Im Test wurde auf beiden Systemen die Version 18.6 installiert.

Ein wichtiger Unterschied zu Ubuntu und PGDG: Das AlmaLinux-Paket richtet auch für interne TCP-Verbindungen (127.0.0.1, ::1) eine ident-Authentifizierung ein, sodass eine Anmeldung per Passwort standardmäßig nicht möglich ist. Dies werden wir weiter unten im Abschnitt zur Passwortanmeldung ändern.

Aus dem PGDG-Repository

Einrichtung des PGDG-Repositorys unter AlmaLinux 10 auf einem x86_64-Rechner (Intel/AMD); unter AlmaLinux 9 lautet der Pfad EL-9-x86_64, auf einem ARM-Rechner EL-10-aarch64:

sudo dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL-10-x86_64/pgdg-redhat-repo-latest.noarch.rpm
sudo rpm --import /etc/pki/rpm-gpg/PGDG-RPM-GPG-KEY-*
sudo dnf install postgresql18-server

Der manuelle Import des Schlüssels war im Test erforderlich, da dnf ohne diesen bei den Metadaten des Repositorys mit der Fehlermeldung „Signing key not found“ abbrach.

Unter AlmaLinux 10 haben die PGDG-Pakete denselben Namen wie in AppStream (postgresql18-server), doch das PGDG-Repository hat eine höhere Priorität, sodass im Test die PGDG-Version installiert wurde (18.6-4PGDG.rhel10.2). Mit dem Befehl rpm -q postgresql18-server lässt sich feststellen, welche Version installiert wurde. Unter AlmaLinux 9 muss laut der PGDG-Anleitung zunächst das Systemmodul deaktiviert werden (sudo dnf -qy module disable postgresql); dies haben wir nicht getestet.

Das PGDG-Paket verwendet andere Pfade und einen anderen Dienstnamen:

sudo /usr/pgsql-18/bin/postgresql-18-setup initdb
sudo systemctl enable --now postgresql-18

	AlmaLinux-Repository	PGDG
Dienst	postgresql	postgresql-18
Datenverzeichnis	/var/lib/pgsql/data	/var/lib/pgsql/18/data
Programme	/usr/bin	/usr/pgsql-18/bin (psql lässt sich auch über /usr/bin starten)
Lokale TCP-Authentifizierung	ident	scram-sha-256

B) Installation unter Ubuntu

Aus dem Ubuntu-Repository

sudo apt update
sudo apt install postgresql

Unter Ubuntu 26.04 wird das Paket postgresql-18 installiert (im Test 18.6-0ubuntu0.26.04.1), unter Ubuntu 24.04 die Hauptversion 16. Im Gegensatz zu AlmaLinux gibt es hier keinen separaten initdb-Schritt: Das Paket erstellt und startet sofort einen Cluster namens main. Die Cluster werden von pg_lsclusters aufgelistet:

pg_lsclusters

Unter Ubuntu (und Debian) können auf einem Rechner mehrere Hauptversionen und mehrere Cluster nebeneinander laufen; daher verfügt jeder Cluster über eine eigene systemd-Einheit: postgresql@18-main. Der Dienst postgresql ist lediglich eine Sammeleinheit, die alle diese Cluster startet und stoppt. So können Sie einen Cluster verwalten:

sudo systemctl restart postgresql@18-main
sudo pg_ctlcluster 18 main restart

Die Konfigurationsdateien befinden sich hier nicht im Datenverzeichnis, sondern im Verzeichnis /etc/postgresql/18/main/ (postgresql.conf, pg_hba.conf sowie ein Unterverzeichnis conf.d für eigene Einstellungen). Die Daten befinden sich in /var/lib/postgresql/18/main, das Protokoll in der Datei /var/log/postgresql/postgresql-18-main.log. Für die internen TCP-Verbindungen auf dem Rechner richtet das Paket bereits eine Passwortauthentifizierung mit scram-sha-256 ein.

Aus dem PGDG-Repository

Das Paket postgresql-common enthält ein Skript, das das PGDG-Repository einrichtet:

sudo apt install postgresql-common
sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
sudo apt install postgresql-18

Die Hauptversion wird durch den Paketnamen angegeben (postgresql-17, postgresql-18). Da auf dem Rechner bereits der Cluster der Version 18 lief, führte die Installation der Hauptversion 17 im Test nicht zur Erstellung eines neuen main-Clusters; in diesem Fall erstellt der Befehl sudo pg_createcluster 17 main --start einen solchen Cluster auf dem nächsten freien Port (5433).

Unter Ubuntu 26.04 wurde nach der Einrichtung des PGDG-Repositorys die PGDG-Version (18.6-1.pgdg26.04+2) anstelle des systemeigenen postgresql-18-Pakets als Aktualisierungskandidat ausgewählt, da deren Versionsnummer höher ist. Das nächste apt upgrade ersetzt das Paket daher durch das PGDG-Paket; die Hauptversion bleibt dieselbe, lediglich die Quelle des Pakets ändert sich.

Erste Anmeldung

Bei der Installation werden ein postgres-Systembenutzer und ein gleichnamiger Datenbank-Superuser angelegt. Auf dem Server gilt die peer-Authentifizierung über Unix-Sockets: Der Name des PostgreSQL-Benutzers muss mit dem des Systembenutzers übereinstimmen. Daher ist eine Anmeldung ohne Passwort wie folgt möglich:

sudo -u postgres psql

Einige nützliche psql-Befehle:

Befehl	Wirkung
\l	Liste der Datenbanken
\du	Liste der Benutzer (Rollen)
\c appdb	Wechsel in eine andere Datenbank
\dt	Liste der Tabellen in der aktuellen Datenbank
\password appuser	Passwort festlegen oder ändern mit versteckter Eingabe
\q	Abmelden

Benutzer und Datenbank anlegen

Erstellen Sie für jede Anwendung einen eigenen Benutzer und eine eigene Datenbank und stellen Sie keine Verbindung über den postgres-Superuser her. Verwenden Sie dazu die Befehlszeilentools:

sudo -u postgres createuser --pwprompt appuser
sudo -u postgres createdb -O appuser appdb

Die Option --pwprompt fordert das Passwort zweimal an, wobei es verborgen bleibt; die Option -O appuser macht den Benutzer zum Eigentümer der neuen Datenbank. Das Gleiche in SQL, in psql:

CREATE ROLE appuser LOGIN PASSWORD 'Hosszu-Egyedi-Jelszo';
CREATE DATABASE appdb OWNER appuser;

Bei der SQL-Variante kann das Passwort auch in den psql-Befehlsverlauf (~/.psql_history) gelangen; daher sind der Befehl \password appuser oder createuser --pwprompt die sicherere Wahl. Das Ergebnis wird durch die Befehle \du und \l angezeigt:

Wenn der Benutzer nicht der Eigentümer der Datenbank ist. Seit PostgreSQL 15 kann im Schema public nur der Eigentümer der Datenbank Tabellen anlegen. Wenn Sie eine bereits vorhandene Datenbank, die sich im Besitz eines anderen Benutzers befindet, an einen Benutzer übertragen, wird das Anlegen von Tabellen mit der Fehlermeldung „permission denied for schema public“ abgebrochen. Gewähren Sie in diesem Fall Zugriffsrechte für das Schema:

sudo -u postgres psql -d masikdb -c "GRANT ALL ON SCHEMA public TO appuser"

Ungarische alphabetische Reihenfolge. Die Sortierregel (Collation) der Datenbank wird bei der Erstellung festgelegt; im Test wurde unter AlmaLinux en_US.UTF-8 und unter Ubuntu C.UTF-8 verwendet. Wenn die Anwendung die Sortierung ungarischer Wörter der Datenbank überlässt, richten Sie die Datenbank bitte mit ungarischen Einstellungen ein:

sudo -u postgres createdb -O appuser -T template0 -l hu_HU.UTF-8 appdb_hu

Unter AlmaLinux benötigen Sie hierfür zunächst das Paket glibc-langpack-hu; ohne dieses Paket tritt der Fehler „invalid LC_COLLATE locale name“ auf. Im Test ist die Datenbank hu_HU.UTF-8 gemäß den ungarischen Regeln sortiert (cukor vor csiga, olló vor öböl), die Datenbank en_US.UTF-8 hingegen nicht.

Anmeldung mit Passwort (pg_hba.conf)

Die Anwendungen stellen in der Regel eine Verbindung über TCP her (localhost, Port 5432) und verwenden dabei einen Benutzernamen und ein Passwort. Wer sich von wo aus und mit welcher Authentifizierung anmelden darf, wird in der Datei pg_hba.conf festgelegt. PostgreSQL liest die Zeilen von oben nach unten, wobei die erste passende Zeile ausschlaggebend ist.

# TYPE  DATABASE  USER  ADDRESS        METHOD
local   all       all                  peer
host    all       all   127.0.0.1/32   scram-sha-256
host    all       all   ::1/128        scram-sha-256

Die Authentifizierungsmethoden:

• peer: nur über Unix-Sockets. Der Name des Systembenutzers muss mit dem des Datenbankbenutzers übereinstimmen; es gibt kein Passwort. Aus diesem Grund funktioniert der Befehl sudo -u postgres psql, und aus diesem Grund gibt der Befehl psql -U appuser appdb die Fehlermeldung „Peer authentication failed for user “appuser”“ aus, wenn Sie ihn nicht als Systembenutzer mit dem Namen appuser ausführen. Geben Sie in diesem Fall den Schalter -h localhost an, dann erfolgt die Verbindung über TCP mit Passwort.
• ident: Über TCP wird dieselbe Anfrage an einen Ident-Server gesendet; in der Praxis ist eine Anmeldung mit Passwort damit nicht möglich. Das eigene Paket von AlmaLinux ist standardmäßig so konfiguriert.
• scram-sha-256: Eine Passwortauthentifizierung, bei der das Passwort nicht über das Netzwerk übertragen wird und auf dem Server lediglich ein gesalzener Hash gespeichert wird. Verwenden Sie diese Methode.
• md5: die alte Passwortmethode. PostgreSQL 18 stuft sie als veraltet ein; verwenden Sie sie bei neuen Installationen nicht. Laut Dokumentation erfolgt die Authentifizierung durch PostgreSQL mit SCRAM, wenn in der Datei pg_hba.conf md5 angegeben ist, das Passwort jedoch bereits als SCRAM-Hash gespeichert ist (der Standardwert für password_encryption ist seit der Hauptversion 14 scram-sha-256; dies war auch im Test der Fall).

Wenn Sie unter AlmaLinux das Systempaket verwenden, ändern Sie die host-Zeilen von ident auf scram-sha-256 und laden Sie anschließend die Einstellungen neu:

sudo sed -i -E '/^host/ s/ident$/scram-sha-256/' /var/lib/pgsql/data/pg_hba.conf
sudo systemctl reload postgresql

Anschließend funktioniert die Anmeldung mit Passwort wie folgt:

psql -h localhost -U appuser appdb

Die Verbindungsdaten der Anwendung lauten: Host localhost oder 127.0.0.1, Port 5432, der oben genannte Datenbankname, Benutzername und Passwort; im URL-Format postgresql://appuser:jelszo@localhost:5432/appdb. In Skripten können Sie das Passwort aus der Datei ~/.pgpass (localhost:5432:appdb:appuser:jelszo, Berechtigung 600) angeben, damit es nicht in der Befehlszeile erscheint.

Fernzugriff

PostgreSQL akzeptiert standardmäßig nur Verbindungen von innerhalb des Rechners (listen_addresses = 'localhost'). Wenn die Datenbank von einer Anwendung genutzt wird, die auf demselben Server läuft, sollten Sie diese Einstellung nicht ändern. Von einem anderen Rechner aus ist der sicherere Weg der SSH-Tunnel; sollte dennoch ein direkter Zugriff erforderlich sein, müssen drei Einstellungen vorgenommen werden: die Listen-Adresse, die Regel in der Datei pg_hba.conf und die Firewall.

Der sicherere Weg: SSH-Tunnel

Der Tunnel verbindet einen Port Ihres eigenen Computers über SSH mit der Serveradresse 127.0.0.1:5432. An PostgreSQL müssen keine Einstellungen geändert werden, der Port bleibt von außen geschlossen und der Datenverkehr wird verschlüsselt übertragen:

ssh -N -L 15432:127.0.0.1:5432 felhasznalo@szerver.pelda.hu

Solange dieser Dienst läuft, können Sie auf Ihrem eigenen Rechner eine Verbindung zur Adresse localhost:15432 herstellen (mit dem Befehl psql -h localhost -p 15432 -U appuser appdb oder über einen grafischen Client wie beispielsweise DBeaver oder pgAdmin, die selbst SSH-Tunnel aufbauen können). Im Test war es somit möglich, sich von einem anderen Rechner aus mit einem Passwort und den oben genannten Zeilen in der Datei pg_hba.conf anzumelden. Wenn Sie diese Verbindung häufig nutzen, können Sie den Tunnel auch in die SSH-Konfigurationsdatei eintragen (unter LocalForward).

Direkter Zugriff

1. Listen-Adresse. Unter AlmaLinux in der Datei /var/lib/pgsql/data/postgresql.conf (bei PGDG /var/lib/pgsql/18/data/postgresql.conf), unter Ubuntu in einer neuen Datei im Verzeichnis conf.d:

echo "listen_addresses = '*'" | sudo tee /etc/postgresql/18/main/conf.d/listen.conf

Mit '*' lauscht PostgreSQL auf allen Adressen; Sie können auch eine bestimmte IP-Adresse angeben. Für die Änderung ist ein Neustart erforderlich (sudo systemctl restart postgresql); anschließend zeigt der Befehl sudo ss -ltnp | grep 5432 bereits die Adresse 0.0.0.0:5432 an (siehe: Liste der offenen Ports).

2. pg_hba.conf. Erlauben Sie dem Remote-Rechner den Zugriff, möglichst nur auf die erforderliche Datenbank, und beschränken Sie diesen Zugriff auf einen bestimmten Benutzer und eine bestimmte IP-Adresse:

host    appdb    appuser    203.0.113.10/32    scram-sha-256

Dazu reicht es aus, die Datei neu zu laden (sudo systemctl reload postgresql). Wenn für eine Verbindung kein entsprechender Eintrag vorhanden ist, lautet die Fehlermeldung wie folgt: „no pg_hba.conf entry for host “…”, user “appuser”, database “postgres”, no encryption“. Der Adressbereich 0.0.0.0/0 würde das gesamte Internet zulassen; verwenden Sie diesen nicht.

3. Firewall. Öffnen Sie Port 5432 ausschließlich für die IP-Adresse des Remote-Rechners. Unter AlmaLinux (firewalld):

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="postgresql" accept'
sudo firewall-cmd --reload

Unter Ubuntu (ufw):

sudo ufw allow from 203.0.113.10 to any port 5432 proto tcp

Falls ufw noch nicht aktiviert ist, lassen Sie zunächst SSH zu (sudo ufw allow OpenSSH), da Sie sich sonst nach dem Befehl sudo ufw enable selbst aussperren würden. Die Grundlagen der Firewall werden im Artikel zur Konfiguration der VPS-Firewall erläutert.

Verschlüsselung. Das AlmaLinux-Paket aktiviert TLS standardmäßig nicht (ssl = off), sodass die Verbindung unverschlüsselt ist; darauf weist auch der Hinweis „no encryption“ in der oben genannten Fehlermeldung hin. Das Ubuntu-Paket startet mit dem Wert ssl = on und einem selbstsignierten (Snakeoil-)Zertifikat. Für eine direkte Verbindung über das Internet richten Sie bitte ein eigenes Zertifikat ein (ssl_cert_file, ssl_key_file) und ändern Sie die Zeile in der Datei pg_hba.conf auf hostssl; alternativ können Sie auch den SSH-Tunnel weiterhin verwenden.

SELinux unter AlmaLinux

Das eigene PostgreSQL-Paket von AlmaLinux läuft unter SELinux als eingeschränkter Prozess (postgresql_t); wenn Sie daher den Port oder das Datenverzeichnis ändern, muss dies auch SELinux mitgeteilt werden. Im Test startete der Dienst nach der Einstellung port = 5433 nicht; im Protokoll wurde avc: denied { name_bind } angezeigt. Die Lösung:

sudo dnf install policycoreutils-python-utils
sudo semanage port -a -t postgresql_port_t -p tcp 5433

Bei einem anderen Datenverzeichnis (beispielsweise auf einer separaten Festplatte unter /srv/pgdata) müssen Sie in der systemd-Einheit die Variable PGDATA entsprechend anpassen und dem Verzeichnis die passende SELinux-Kennzeichnung zuweisen:

sudo systemctl edit postgresql
# in die sich öffnende Datei:
# [Service]
# Environment=PGDATA=/srv/pgdata
sudo install -d -o postgres -g postgres -m 700 /srv/pgdata
sudo semanage fcontext -a -t postgresql_db_t "/srv/pgdata(/.*)?"
sudo restorecon -R /srv/pgdata
sudo postgresql-setup --initdb
sudo systemctl start postgresql

Ohne die Kennzeichnung konnte der Dienst aufgrund des Fehlers avc: denied { getattr } nicht gestartet werden. Informationen zur Suche nach solchen Fehlern finden Sie im Artikel über „Permission denied“-Fehler in SELinux. Die Programme des PGDG-Pakets (/usr/pgsql-18/bin) erhielten im Test keine SELinux-Kennzeichnung, sodass PGDG PostgreSQL ohne Einschränkungen (unconfined_service_t) lief und auch ohne die oben genannten Schritte auf einem anderen Port oder mit einem anderen Datenverzeichnis gestartet werden konnte.

Grundlegende Konfiguration

Die Standardeinstellungen von PostgreSQL sind auf Rechner mit geringem Arbeitsspeicher ausgelegt: Im Test betrug der Wert für shared_buffers (der eigene Cache von PostgreSQL) 128MB. Die Dokumentation empfiehlt als Ausgangswert etwa 25 % des Arbeitsspeichers; auf einem Server mit 2 GB wären das beispielsweise 512 MB:

sudo -u postgres psql -c "ALTER SYSTEM SET shared_buffers = '512MB'"
sudo systemctl restart postgresql
sudo -u postgres psql -c "SHOW shared_buffers"

Der Befehl ALTER SYSTEM schreibt den Wert in die Datei postgresql.auto.conf, die Vorrang vor postgresql.conf hat und die Sie nicht manuell bearbeiten sollten. Eine Änderung der Variable shared_buffers erfordert einen Neustart, für die meisten anderen Einstellungen reicht ein Neuladen aus. Planen Sie den Arbeitsspeicher gemeinsam mit den anderen Diensten ein, damit auch für den Webserver und PHP noch genug verbleibt (siehe: Speicher erschöpft: OOM-Killer, Befehl free und Auslagerungsdatei). Für eine feinere Abstimmung (work_mem, effective_cache_size, max_connections) muss auch die Auslastung gemessen werden; dies würde den Rahmen dieses Artikels sprengen. Wenn die Anwendung häufig dieselben Daten abfragt, kann ein Redis- oder Valkey-Cache die Datenbank entlasten.

Sicherung und Wiederherstellung

Eine Datenbank wird in einem komprimierten, proprietären Format gesichert, aus dem pg_restore die Daten wiederherstellt:

sudo -u postgres pg_dump -Fc appdb -f /var/lib/pgsql/backups/appdb.dump

Unter Ubuntu befindet sich das eigene Verzeichnis des Benutzers postgres unter /var/lib/postgresql. Speichern Sie die Sicherung dort oder in einem anderen Verzeichnis, auf das der Benutzer postgres Schreibzugriff hat. Wiederherstellung in eine neue, leere Datenbank:

sudo -u postgres createdb -O appuser appdb_vissza
sudo -u postgres pg_restore -d appdb_vissza /var/lib/pgsql/backups/appdb.dump

Wenn Sie eine SQL-Textdatei benötigen (beispielsweise, um sie auf einen anderen Rechner zu übertragen oder einzusehen), komprimieren Sie bitte die Ausgabe von pg_dump und laden Sie sie mit psql wieder ein:

sudo -u postgres pg_dump appdb | gzip > appdb.sql.gz
gunzip -c appdb.sql.gz | sudo -u postgres psql -d appdb_vissza

pg_dump speichert keine Benutzer und Passwörter, sondern lediglich den Inhalt der Datenbank. Diese werden von pg_dumpall gespeichert; mit dem Schalter --globals-only werden nur die Benutzer und Berechtigungen gesichert, ohne diesen Schalter das gesamte Cluster mit allen Datenbanken:

sudo -u postgres pg_dumpall --globals-only > globals.sql
sudo -u postgres pg_dumpall | gzip > osszes.sql.gz

Im Test gelang die Wiederherstellung der oben genannten Sicherungen einschließlich der Tabellen und der Daten mit Umlauten. Die regelmäßige Sicherung können Sie über crontab planen; bewahren Sie die Sicherung zusätzlich auf einem anderen Rechner auf (siehe: Wie erstelle ich ein Backup meines VPS?).

Wechsel der Hauptversion

Unterversionen (z. B. 18.5 → 18.6) werden im Rahmen der üblichen Systemaktualisierung installiert (siehe: Systemaktualisierung mit dnf und apt); die Daten müssen dabei nicht geändert werden. Bei einem Wechsel der Hauptversion (z. B. 16 → 18) muss das Datenverzeichnis umgestellt werden. Erstellen Sie zuvor stets eine vollständige Sicherung mit pg_dumpall.

Unter Ubuntu und Debian wird dies von pg_upgradecluster durchgeführt. Im Test haben wir einen Cluster der Version 17 auf Version 18 umgestellt; zunächst muss der leere, automatisch erstellte Cluster der neuen Hauptversion gelöscht werden:

sudo pg_dropcluster 18 main --stop
sudo pg_upgradecluster -m upgrade 17 main
pg_lsclusters

Die Standardmethode (-m dump) arbeitet mit Sicherung und Wiederherstellung; die Option -m upgrade nutzt das schnellere Programm pg_upgrade. Der neue Cluster hat den Port des alten Clusters übernommen, der alte bleibt im heruntergefahrenen Zustand erhalten. Wenn alles funktioniert, kann der alte Cluster gelöscht werden: sudo pg_dropcluster 17 main.

Unter AlmaLinux 10 enthält das Paket postgresql18-upgrade den alten Server (Version 16) für pg_upgrade. Im Test hat folgende Reihenfolge funktioniert:

sudo systemctl stop postgresql
sudo dnf swap postgresql-server postgresql18-server
sudo dnf install postgresql18-upgrade
sudo PGSETUP_INITDB_OPTIONS="--no-data-checksums" postgresql-setup --upgrade
sudo systemctl start postgresql

Der Schalter --no-data-checksums ist erforderlich, da PostgreSQL 18 den neuen Cluster standardmäßig mit Daten-Prüfsummen erstellt, ältere Hauptversionen hingegen nicht; ohne diesen Schalter brach der Befehl postgresql-setup --upgrade mit der Fehlermeldung „old cluster does not use data checksums but the new one does“ ab. Beachten Sie bitte auch, dass nach der Umstellung die Dateien postgresql.conf und pg_hba.conf auf die Standardeinstellungen zurückgesetzt werden: Die alten Einstellungen und Daten werden in das Verzeichnis /var/lib/pgsql/data-old verschoben; von dort können Sie Ihre Änderungen übernehmen. Unter AlmaLinux 9 ist im Modul 18 das Paket postgresql-upgrade enthalten; diese Variante haben wir nicht getestet. Sollten Sie AlmaLinux ebenfalls auf eine Hauptversion aktualisieren, bietet Ihnen der Artikel über ELevate Unterstützung.

Welches Paket sollten Sie wählen?

Die Datenbank einer kleineren Anwendung läuft auch auf einem KVM-VPS, den sie sich mit der Webanwendung teilt, problemlos, sofern der Arbeitsspeicher so zugewiesen wird, dass sowohl dem PostgreSQL-Cache als auch der Anwendung ausreichend Speicher zur Verfügung steht. Sollte die Datenbank groß sein oder viele gleichzeitige Verbindungen bedienen, wählen Sie bitte ein Paket mit größerem Arbeitsspeicher oder stellen Sie sie auf einen separaten Server. Sollten Sie sich nicht sicher sein, welche Lösung für Ihre Anwendung geeignet ist, schreiben Sie uns – wir helfen Ihnen gerne bei der Entscheidung.