Zum Inhalt springen

Dies ist die mehrseitige Druckansicht dieses Abschnitts. .

Zur normalen Ansicht dieser Seite zurückkehren.

pgBackRest 2.59.3 Dokumentation

Zuverlässige Backups und Wiederherstellung für PostgreSQL — Dokumentation und Referenz zu pgBackRest.

Einführung

pgBackRest ist eine zuverlässige Lösung für Backups und Wiederherstellung mit PostgreSQL, die sich nahtlos bis zu den größten Datenbanken und Arbeitslasten skalieren lässt.

Diese Dokumentationskopie behandelt pgBackRest v2.59.3 . Versionshinweise stehen auf der Seite Versionen .

Version 2.59.3 behebt die mögliche Erzeugung schwacher Verschlüsselungsunterschlüssel und Salts. Ein Upgrade ersetzt vorhandene schwache Unterschlüssel einer Stanza nicht; Prüfungen und Abhilfemaßnahmen finden Sie unter Schwache Unterschlüssel und Salts bei der Verschlüsselung .

Wenn Ihnen pgBackRest gefällt, geben Sie uns einen Stern auf GitHub !

Neuigkeiten

4. Oktober 2026 - Schwache Unterschlüssel und Salts bei der Verschlüsselung

4. Oktober 2026 - pgBackRest 2.59.3 veröffentlicht

27. September 2026 - pgBackRest 2.59.2 veröffentlicht

Sponsoren

Ohne Sponsoring gäbe es pgBackRest nicht. Neue Funktionen zu entwickeln, Fehler zu beheben, Beiträge zu prüfen, Fragen aus der Community zu beantworten und das Projekt zu pflegen, erfordert viel Zeit. Wenn Sie pgBackRest in Ihrem Unternehmen einsetzen, ziehen Sie bitte ein Sponsoring in Betracht.

Unsere Sponsoren: AWS , Supabase , pgEdge , Tiger Data , Percona , Eon , Xata , Dalibo und Data Egret .

Wir danken unseren Sponsoren für ihre Investitionen in Open-Source-Infrastruktur, die der gesamten PostgreSQL-Community zugutekommt.

Frühere Sponsoren: Crunchy Data , Resonate .

Funktionen

Parallele Backups und Wiederherstellung

Die Komprimierung ist bei Backups meist der Engpass. pgBackRest löst dieses Problem durch parallele Verarbeitung und effizientere Komprimierungsalgorithmen wie lz4 und zstd.

Lokaler oder entfernter Betrieb

Ein eigenes Protokoll ermöglicht pgBackRest Backups, Wiederherstellung und Archivierung lokal oder über TLS/SSH mit minimalem Konfigurationsaufwand. Die Protokollschicht stellt auch eine Schnittstelle für PostgreSQL-Abfragen bereit. Dadurch ist ein Fernzugriff auf PostgreSQL nie erforderlich, was die Sicherheit erhöht.

Mehrere Repositorys

Mehrere Repositorys ermöglichen beispielsweise ein lokales Repository mit kurzer Aufbewahrungsdauer für schnelle Wiederherstellungen und ein entferntes Repository mit längerer Aufbewahrungsdauer für Redundanz und unternehmensweiten Zugriff.

Vollständige, differenzielle und inkrementelle Backups (auf Datei- oder Blockebene)

Vollständige, differenzielle und inkrementelle Backups werden unterstützt. pgBackRest ist nicht von den Problemen mit der Zeitauflösung von rsync betroffen. Differenzielle und inkrementelle Backups sind daher sicher, ohne dass für jede Datei eine Prüfsumme berechnet werden muss. Backups auf Blockebene sparen Speicherplatz, indem nur geänderte Teile von Dateien kopiert werden.

Backup-Rotation und Bereinigung des Archivs

Für vollständige und differenzielle Backups lassen sich Aufbewahrungsregeln festlegen, die beliebige Zeiträume abdecken. Das WAL-Archiv kann für alle Backups oder ausschließlich für die neuesten Backups vorgehalten werden. Im letzteren Fall bleibt das WAL, das ältere Backups in einen konsistenten Zustand versetzt, im Archiv erhalten.

Backup-Integrität

Für jede Datei im Backup werden Prüfsummen berechnet und bei einer Wiederherstellung oder Überprüfung erneut geprüft. Nach dem Kopieren der Dateien wartet das Backup, bis jedes WAL-Segment, das für die Konsistenz des Backups erforderlich ist, das Repository erreicht hat.

Backups im Repository können im selben Format wie ein gewöhnlicher PostgreSQL-Cluster gespeichert werden (einschließlich Tablespaces). Bei deaktivierter Komprimierung und aktivierten Hardlinks kann ein Snapshot eines Backups im Repository erstellt und ein PostgreSQL-Cluster direkt auf diesem Snapshot gestartet werden. Dies ist bei Datenbanken im Terabyte-Bereich vorteilhaft, deren herkömmliche Wiederherstellung viel Zeit beansprucht.

Alle Operationen verwenden fsync auf Datei- und Verzeichnisebene, um die Dauerhaftigkeit sicherzustellen.

Seitenprüfsummen

Wenn Seitenprüfsummen aktiviert sind, prüft pgBackRest die Prüfsummen jeder Datei, die während eines Backups kopiert wird. Bei einem vollständigen Backup werden alle Seitenprüfsummen geprüft, bei differenziellen und inkrementellen Backups die Prüfsummen in geänderten Dateien.

Fehlgeschlagene Prüfungen halten das Backup nicht an. Stattdessen werden Warnungen auf der Konsole und im Dateiprotokoll ausgegeben, die genau angeben, welche Seiten die Prüfung nicht bestanden haben.

Diese Funktion ermöglicht es, Beschädigungen auf Seitenebene frühzeitig zu erkennen, bevor Backups mit gültigen Kopien der Daten abgelaufen sind.

Backups fortsetzen

Ein unterbrochenes Backup kann an der Stelle fortgesetzt werden, an der es angehalten wurde. Bereits kopierte Dateien werden mit den Prüfsummen im Manifest verglichen, um ihre Integrität sicherzustellen. Da dieser Vorgang vollständig auf dem Repository-Host erfolgen kann, entlastet er den PostgreSQL-Host. Er spart zudem Zeit, da die Prüfsummenberechnung schneller ist als das Komprimieren und erneute Übertragen der Daten.

Komprimierung und Prüfsummen im Datenstrom

Komprimierung und Prüfsummenberechnung erfolgen im Datenstrom, während Dateien in das Repository kopiert werden, unabhängig davon, ob sich das Repository lokal oder auf einem entfernten Host befindet.

Liegt das Repository auf einem Repository-Host, erfolgt die Komprimierung auf dem PostgreSQL-Host. Die Dateien werden komprimiert übertragen und auf dem Repository-Host lediglich gespeichert. Bei deaktivierter Komprimierung wird für die Übertragung eine niedrige Komprimierungsstufe verwendet, um die verfügbare Bandbreite effizient zu nutzen und gleichzeitig den CPU-Aufwand zu minimieren.

Delta-Wiederherstellung

Das Manifest enthält Prüfsummen für jede Datei im Backup. Diese können die Verarbeitung bei einer Wiederherstellung erheblich beschleunigen. Bei einer Delta-Wiederherstellung werden zunächst alle Dateien entfernt, die nicht im Backup enthalten sind, und anschließend Prüfsummen für die verbleibenden Dateien berechnet. Dateien, die mit dem Backup übereinstimmen, bleiben unverändert; die übrigen Dateien werden wie gewohnt wiederhergestellt. Parallele Verarbeitung kann die Wiederherstellungszeit drastisch verkürzen.

WAL parallel und asynchron archivieren und abrufen

Eigene Befehle dienen dazu, WAL in das Archiv zu übertragen und aus dem Archiv abzurufen. Beide Befehle unterstützen parallele Verarbeitung zur Beschleunigung und arbeiten asynchron, um PostgreSQL möglichst schnell zu antworten.

Die WAL-Archivierung erkennt automatisch mehrfach übertragene WAL-Segmente und dedupliziert sie, wenn sie identisch sind. Andernfalls wird ein Fehler ausgelöst. Bei der asynchronen WAL-Archivierung kann die Übertragung an einen anderen Prozess ausgelagert werden, der WAL-Segmente für maximalen Durchsatz parallel komprimiert. Für Datenbanken mit sehr hohem Schreibvolumen kann diese Funktion entscheidend sein.

Der asynchrone WAL-Abruf hält eine lokale Warteschlange dekomprimierter WAL-Segmente vor, die zum Einspielen bereitstehen. Dadurch steht PostgreSQL das WAL schneller zur Verfügung, was die Einspielgeschwindigkeit maximiert. Verbindungen und Speichersysteme mit höherer Latenz (etwa S3) profitieren davon am meisten.

Beide Befehle stellen durch den Vergleich von PostgreSQL-Versionen und Systemkennungen sicher, dass Datenbank und Repository zueinander passen. Dadurch wird eine Fehlkonfiguration des WAL-Archivpfads praktisch ausgeschlossen.

Unterstützung für Tablespaces und Verknüpfungen

Tablespaces werden vollständig unterstützt und können bei der Wiederherstellung beliebigen neuen Speicherorten zugeordnet werden. Mit einem einzigen Befehl lassen sich auch alle Tablespaces einem gemeinsamen Speicherort zuordnen, was für Wiederherstellungen zu Entwicklungszwecken nützlich ist.

Verknüpfungen werden für jede Datei und jedes Verzeichnis im PostgreSQL-Cluster unterstützt. Bei der Wiederherstellung können alle Verknüpfungen an ihren ursprünglichen Speicherorten wiederhergestellt, einige oder alle Verknüpfungen neu zugeordnet oder einige oder alle Verknüpfungen als normale Dateien oder Verzeichnisse im Clusterverzeichnis wiederhergestellt werden.

Unterstützung für S3-, Azure- und GCS-kompatible Objektspeicher

pgBackRest-Repositorys können in S3-, Azure- und GCS-kompatiblen Objektspeichern liegen und damit praktisch unbegrenzte Kapazität und Aufbewahrung ermöglichen.

Verschlüsselung

pgBackRest kann das Repository verschlüsseln, um Backups unabhängig von ihrem Speicherort zu schützen.

Schutz vor Ransomware und Schadsoftware

Liegt das Repository auf einem versionierten Objektspeicher, kann pgBackRest dessen Zustand zu einem bestimmten Zeitpunkt lesen. Werden Backups versehentlich oder durch Schadsoftware oder Ransomware gelöscht oder beschädigt, lässt sich ein Zielzeitpunkt verwenden, um Daten aus der Zeit vor dem Schaden wiederherzustellen.

S3-, Azure- und GCS-kompatible Objektspeicher unterstützen Versionierung. Objektsperren bei S3 und vorläufiges Löschen bei GCS oder Azure können zusätzlichen Schutz vor Manipulation bieten.

Kompatibilität mit zehn PostgreSQL-Versionen

pgBackRest unterstützt zehn PostgreSQL-Versionen: die fünf unterstützten Versionen und die letzten fünf Versionen, deren Unterstützung beendet ist (EOL). So bleibt ausreichend Zeit für das Upgrade auf eine unterstützte Version.

Erste Schritte

pgBackRest soll einfach zu konfigurieren und zu betreiben sein:

Beiträge

Beiträge zu pgBackRest sind jederzeit willkommen! Unsere Richtlinien für Beiträge erläutern, wie Sie Funktionen, Verbesserungen oder Problemmeldungen beitragen können.

Unterstützung

pgBackRest ist vollständig kostenlos und quelloffen unter der MIT -Lizenz. Sie können es ohne jegliche Einschränkungen privat oder kommerziell nutzen. Fehlerberichte werden sehr ernst genommen und so schnell wie möglich bearbeitet. Bitte melden Sie Fehler hier .

Eine belastbare Strategie zur Wiederherstellung nach Ausfällen mit geeigneten Replikations- und Backup-Konzepten auszuarbeiten, kann sehr komplex und anspruchsvoll sein. Möglicherweise benötigen Sie Unterstützung bei der Architekturplanung und im laufenden Betrieb, damit Ihr Unternehmen weiterhin reibungslos arbeiten kann.

Unsere Sponsoren bieten Produkte und Dienstleistungen mit pgBackRest-Unterstützung an und können Ihnen bei der Vorsorge für und Wiederherstellung nach Ausfällen helfen.

1 - Nachrichten

Offizielle Nachrichten zum pgBackRest-Projekt, Versionsankündigungen und Neuigkeiten zur Projektpflege.

Schwache Unterschlüssel und Salts bei der Verschlüsselung

4. Oktober 2026

pgBackRest-Versionen vor 2.59.3 prüften bei der Erzeugung von Zufallsdaten für die Verschlüsselung nicht auf Fehler. Wenn OpenSSL keine Zufallsdaten vom Betriebssystem beziehen konnte, wurden Verschlüsselungsunterschlüssel und Salts aus bereits im Speicher vorhandenen Daten erzeugt, ohne einen Fehler zu melden. Nicht verschlüsselte Repositorys sind nicht betroffen.

Dieser Fehler dürfte selten auftreten. Mögliche Ursachen sind eine Sandbox oder eine seccomp-Richtlinie, die den Systemaufruf getrandom() blockiert, sowie eine ungültige OpenSSL-Konfiguration.

Besonders kritisch sind die Unterschlüssel in archive.info und backup.info. Sie werden einmalig von stanza-create erzeugt und während der gesamten Lebensdauer der Stanza verwendet. Ein Upgrade ersetzt daher einen schwachen Unterschlüssel nicht. Schwache Backup-Unterschlüssel und Salts werden entfernt, wenn Backups und WAL ablaufen.

Auswirkungen

Der WAL-Unterschlüssel wird in archive.info gespeichert, der Manifest-Unterschlüssel in backup.info. Ein schwacher Unterschlüssel lässt sich leichter erraten als ein zufälliger. Mit einem erratenen Unterschlüssel können die damit verschlüsselten Dateien ohne repo-cipher-pass entschlüsselt werden. Wie viel leichter dies ist, hängt vom Speicherinhalt ab, der je nach Plattform und Build variiert. Ein schwacher Unterschlüssel in archive.info gefährdet sämtliche WAL im Repository. Ein schwacher Unterschlüssel in backup.info gefährdet jedes Backup, da die Manifeste mit ihm verschlüsselt werden und jedes Manifest den Unterschlüssel für die Dateien seines Backups enthält. Dies betrifft auch WAL und Backups, die nach dem Upgrade hinzugefügt werden.

Der Unterschlüssel für die Dateien eines Backups wird für jedes vollständige Backup erzeugt und auch von den darauf basierenden differentiellen und inkrementellen Backups verwendet. Ein schwacher Backup-Unterschlüssel gefährdet die Dateien in all diesen Backups.

Ein schwaches Salt legt keinen Unterschlüssel offen. Dateien, die mit demselben Unterschlüssel und Salt verschlüsselt werden, verwenden denselben Schlüssel und IV. Identische Daten in diesen Dateien ergeben daher identische verschlüsselte Daten. Das Salt wird unverschlüsselt am Anfang jeder Datei gespeichert. Ein schwaches Salt kann bis zu 8 Byte zuvor im Speicher vorhandener Daten enthalten.

Unterschlüssel prüfen

Führen Sie die folgenden Befehle auf einem Host mit Zugriff auf das Repository aus und setzen Sie STANZA auf den Namen der Stanza. Ergänzen Sie die pgbackrest-Befehle um --repo, um ein anderes als das erste Repository zu prüfen.

STANZA=demo

for file in archive/$STANZA/archive.info backup/$STANZA/backup.info; do
    for key in $(pgbackrest --stanza=$STANZA repo-get $file | grep '^cipher-pass=' | grep -oE '[A-Za-z0-9+/]{64}'); do
        echo "$(printf '%s' $key | base64 -d | od -An -v -tx1 | tr -s ' ' '\n' | grep -c '^00$') $file"
    done
done

Die erste Spalte gibt die Anzahl der Nullbytes im Unterschlüssel an. Ein zufälliger Unterschlüssel enthält in weniger als einem von 25 000 000 Fällen 6 oder mehr Nullbytes. Die in Tests gefundenen schwachen Unterschlüssel enthielten hingegen 13 oder mehr. Ein Unterschlüssel mit 6 oder mehr Nullbytes sollte als schwach gelten.

OpenSSL 1.0

pgBackRest-Versionen vor 2.53 konnten mit OpenSSL 1.0 gebaut werden. Wenn es keine Zufallsdaten vom Betriebssystem beziehen kann, erzeugt es Zufallsdaten aus einem Zustand, der nicht mit Zufallsdaten initialisiert wurde. Auf diese Weise erzeugte schwache Unterschlüssel lassen sich mit der obigen Prüfung nicht erkennen.

Abhilfemaßnahmen

  • Führen Sie ein Upgrade auf pgBackRest 2.59.3 oder neuer durch. Diese Versionen melden einen Fehler, wenn keine Zufallsdaten erzeugt werden können.
  • Ist der Unterschlüssel in archive.info oder backup.info schwach, erstellen Sie die Stanza in einem neuen Repository und behalten Sie das alte Repository nur so lange, wie dessen Backups benötigt werden.
  • Erwägen Sie nach dem Upgrade ein neues vollständiges Backup, da differentielle und inkrementelle Backups den Unterschlüssel ihres vollständigen Backups verwenden.
  • Schwache Backup-Unterschlüssel und Salts werden entfernt, wenn die Backups und WAL aus der Zeit vor dem Upgrade ablaufen. Bei Backups mit langer Aufbewahrungsdauer bleiben sie bis zu deren Ablauf erhalten.

pgBackRest 2.59.3 veröffentlicht

4. Oktober 2026

Die pgBackRest-Community freut sich, die Veröffentlichung von pgBackRest 2.59.3 bekanntzugeben. Dies ist die neueste Version der zuverlässigen, einfach zu bedienenden Lösung für Backup und Wiederherstellung, die sich nahtlos bis zu den größten Datenbanken und Arbeitslasten skalieren lässt.

pgBackRest bietet umfangreiche Funktionen für die Verwaltung Ihrer Backup- und Recovery-Infrastruktur, darunter: parallele Backups und Wiederherstellungen, vollständige/differenzielle/inkrementelle Backups, blockinkrementelle Backups, mehrere Repositorys, Delta-Wiederherstellung, parallele asynchrone Archivierung, Schutz vor Malware und Ransomware, Prüfsummen für jede Datei, während des Backups geprüfte Seitenprüfsummen (sofern aktiviert), mehrere Komprimierungsverfahren, Verschlüsselung, Fortsetzung unvollständiger oder fehlgeschlagener Backups, Backups vom Standby, Unterstützung für Tablespaces und Links, Unterstützung für S3/Azure/GCS/SFTP, Entfernen abgelaufener Backups, lokalen und entfernten Betrieb über SSH oder TLS, flexible Konfiguration und vieles mehr.

pgBackRest kann aus dem PostgreSQL Yum Repository oder dem PostgreSQL APT Repository installiert werden; Pakete sind auch für viele andere Distributionen verfügbar. Der Quellcode steht unter Versionen zum Download bereit.

Fehlerbehebungen

  • Mögliche Erzeugung schwacher Verschlüsselungsunterschlüssel oder Salts behoben (j0uinim)
  • Möglichen Prüfsummenfehler beim Laden verschlüsselter Informationsdateien und Manifeste behoben (j0uinim)

Weitere Fehlerbehebungen und Verbesserungen sind in den Versionshinweisen zu 2.59.3 beschrieben.

Wichtige Hinweise

Links

Sponsoren

Diese Version wurde durch die großzügige Förderung von AWS , Supabase , pgEdge , Tiger Data , Percona , Eon , Xata , Dalibo und Data Egret ermöglicht.

pgBackRest 2.59.2 veröffentlicht

27. September 2026

Die pgBackRest-Community freut sich, die Veröffentlichung von pgBackRest 2.59.2 bekanntzugeben. Dies ist die neueste Version der zuverlässigen, einfach zu bedienenden Lösung für Backup und Wiederherstellung, die sich nahtlos bis zu den größten Datenbanken und Arbeitslasten skalieren lässt.

pgBackRest bietet umfangreiche Funktionen für die Verwaltung Ihrer Backup- und Recovery-Infrastruktur, darunter: parallele Backups und Wiederherstellungen, vollständige/differenzielle/inkrementelle Backups, blockinkrementelle Backups, mehrere Repositorys, Delta-Wiederherstellung, parallele asynchrone Archivierung, Schutz vor Malware und Ransomware, Prüfsummen für jede Datei, während des Backups geprüfte Seitenprüfsummen (sofern aktiviert), mehrere Komprimierungsverfahren, Verschlüsselung, Fortsetzung unvollständiger oder fehlgeschlagener Backups, Backups vom Standby, Unterstützung für Tablespaces und Links, Unterstützung für S3/Azure/GCS/SFTP, Entfernen abgelaufener Backups, lokalen und entfernten Betrieb über SSH oder TLS, flexible Konfiguration und vieles mehr.

pgBackRest kann aus dem PostgreSQL Yum Repository oder dem PostgreSQL APT Repository installiert werden; Pakete sind auch für viele andere Distributionen verfügbar. Der Quellcode steht unter Versionen zum Download bereit.

Neue Funktionen und Fehlerbehebungen

  • Unterstützung für PostgreSQL 19beta4 (David Steele)
  • Fehler bei einer leeren Blockzuordnung behoben, wenn eine Datei während des Backups auf die Länge null gekürzt wird (David Steele)
  • Wiederholungen von Lesevorgängen deaktiviert, wenn Filter an den Treiber übergeben werden (David Steele)
  • Seitenweises Auflisten von S3-Versionen korrigiert (David Steele)
  • Azure-Versionsheader für die SAS-Authentifizierung gesetzt (David Steele)
  • Hängenbleiben des asynchronen archive-push an einer Backup-Historiendatei mit der Größe null behoben (Andrew Kroh)
  • Befehl annotate auf einem entfernten verschlüsselten Repository korrigiert (Douglas J Hunley)

Weitere Fehlerbehebungen und Verbesserungen sind in den Versionshinweisen zu 2.59.2 beschrieben.

Wichtige Hinweise

  • PostgreSQL 19beta4 hat die Formate von pg_control und WAL geändert. Cluster und WAL aus einer früheren Beta-Version von 19 werden daher nicht mehr unterstützt. Cluster mit einer früheren Beta-Version sollten mit 19beta4 neu erstellt werden.

Links

Sponsoren

Diese Version wurde durch die großzügige Förderung von AWS , Supabase , pgEdge , Tiger Data , Percona , Eon , Xata , Dalibo und Data Egret ermöglicht.

pgBackRest 2.59.1 veröffentlicht

17. August 2026

Die pgBackRest-Community freut sich, die Veröffentlichung von pgBackRest 2.59.1 bekanntzugeben. Dies ist die neueste Version der zuverlässigen, einfach zu bedienenden Lösung für Backup und Wiederherstellung, die sich nahtlos bis zu den größten Datenbanken und Arbeitslasten skalieren lässt.

pgBackRest bietet umfangreiche Funktionen für die Verwaltung Ihrer Backup- und Recovery-Infrastruktur, darunter: parallele Backups und Wiederherstellungen, vollständige/differenzielle/inkrementelle Backups, blockinkrementelle Backups, mehrere Repositorys, Delta-Wiederherstellung, parallele asynchrone Archivierung, Schutz vor Malware und Ransomware, Prüfsummen für jede Datei, während des Backups geprüfte Seitenprüfsummen (sofern aktiviert), mehrere Komprimierungsverfahren, Verschlüsselung, Fortsetzung unvollständiger oder fehlgeschlagener Backups, Backups vom Standby, Unterstützung für Tablespaces und Links, Unterstützung für S3/Azure/GCS/SFTP, Entfernen abgelaufener Backups, lokalen und entfernten Betrieb über SSH oder TLS, flexible Konfiguration und vieles mehr.

pgBackRest kann aus dem PostgreSQL Yum Repository oder dem PostgreSQL APT Repository installiert werden; Pakete sind auch für viele andere Distributionen verfügbar. Der Quellcode steht unter Versionen zum Download bereit.

Neue Funktionen und Fehlerbehebungen

  • Unterstützung für PostgreSQL 19beta3 (Lardière Sébastien)
  • Hängenbleiben behoben, wenn der Chunk-Puffer kleiner als der Eingabepuffer ist (David Steele)
  • Neue Backup-Kennzeichnung nur mit ihrem eigenen vollständigen Backup-Satz verglichen (David Steele)
  • Von GitHub erzeugte Quellcodearchive korrigiert, in denen für den Build erforderliche Dateien fehlten (David Steele)

Weitere Fehlerbehebungen und Verbesserungen sind in den Versionshinweisen zu 2.59.1 beschrieben.

Wichtige Hinweise

  • PostgreSQL 19beta3 hat das WAL-Format geändert. WAL, das mit einer früheren Beta-Version von PostgreSQL 19 archiviert wurde, ist daher nicht mehr lesbar. Cluster mit einer früheren Beta-Version sollten mit 19beta3 neu erstellt werden.

Links

Sponsoren

Diese Version wurde durch die großzügige Förderung von AWS , Supabase , pgEdge , Tiger Data , Percona , Eon , Xata , Dalibo und Data Egret ermöglicht.

Neuer Distributions-Tarball

20. Juli 2026

Ab pgBackRest 2.59.0 enthält jede Veröffentlichung einen Distributions-Tarball, der das Bauen aus dem Quellcode vereinfacht. Anders als ein Checkout des Git-Repositorys enthält der Tarball bereits den generierten Quellcode und die fertig gerenderte Dokumentation. pgBackRest lässt sich damit ohne die Werkzeuge zur Codegenerierung oder Dokumentation bauen und installieren, die ein Repository-Checkout benötigt.

Der Tarball enthält den pgBackRest-Quellcode mit dem vorgenerierten Code, die Manpage der Befehlsreferenz, die HTML-Dokumentation und einen Smoke-Test zur Überprüfung des Builds. Er wird mit meson und ninja gebaut und benötigt nur die üblichen pgBackRest-Bibliotheken.

Der Tarball ist jeder Veröffentlichung als Datei mit dem Namen pgbackrest-{version}.tar.gz beigefügt, zusammen mit einer passenden .sha256sum-Prüfsumme. Er kann von der Seite Versionen auf GitHub heruntergeladen werden. Anweisungen zum Bauen und Testen stehen in der README.md im Tarball.

Paketbetreuer werden gebeten, den Distributions-Tarball für den Build zu verwenden, um die zusätzlichen Build-Werkzeuge zu vermeiden, die in künftigen Versionen zur Erzeugung von Code und Dokumentation erforderlich sein werden.

pgBackRest 2.59.0 veröffentlicht

20. Juli 2026

Die pgBackRest-Community freut sich, die Veröffentlichung von pgBackRest 2.59.0 bekanntzugeben. Dies ist die neueste Version der zuverlässigen, einfach zu bedienenden Lösung für Backup und Wiederherstellung, die sich nahtlos bis zu den größten Datenbanken und Arbeitslasten skalieren lässt.

pgBackRest bietet umfangreiche Funktionen für die Verwaltung Ihrer Backup- und Recovery-Infrastruktur, darunter: parallele Backups und Wiederherstellungen, vollständige/differenzielle/inkrementelle Backups, blockinkrementelle Backups, mehrere Repositorys, Delta-Wiederherstellung, parallele asynchrone Archivierung, Schutz vor Malware und Ransomware, Prüfsummen für jede Datei, während des Backups geprüfte Seitenprüfsummen (sofern aktiviert), mehrere Komprimierungsverfahren, Verschlüsselung, Fortsetzung unvollständiger oder fehlgeschlagener Backups, Backups vom Standby, Unterstützung für Tablespaces und Links, Unterstützung für S3/Azure/GCS/SFTP, Entfernen abgelaufener Backups, lokalen und entfernten Betrieb über SSH oder TLS, flexible Konfiguration und vieles mehr.

pgBackRest kann aus dem PostgreSQL Yum Repository oder dem PostgreSQL APT Repository installiert werden; Pakete sind auch für viele andere Distributionen verfügbar. Der Quellcode steht unter Versionen zum Download bereit.

Wesentliche neue Funktionen und Verbesserungen

  • Unterstützung für PostgreSQL 19 (David Steele)
  • Option archive-expire-before zum Bereinigen des WAL-Archivs hinzugefügt (Stefan Fercot)
  • Unterstützung für S3 Outposts hinzugefügt (Shiva Kumar Ambigi)
  • S3-Prozessauthentifizierung hinzugefügt (David Steele)
  • Zwischenspeicherung von Benutzern und Gruppen für eine schnellere Erstellung des Manifests hinzugefügt (Gunnar Lindholm)
  • Erneuter Verbindungsaufbau zum SFTP-Speicher, nachdem der Server eine inaktive Verbindung getrennt hat (David Steele)
  • Backup-Fortschritt je Repository zur Ausgabe des Befehls info hinzugefügt (Will Morland)
  • Stapellöschung für Azure-Speicher hinzugefügt (David Steele)
  • Prüfungen von backup.info zum Befehl verify hinzugefügt (Denis Garsh)
  • Konfiguration des S3-STS-Endpunkts ermöglicht (Simon Gratton)
  • Integration von systemd-Benachrichtigungen hinzugefügt (Andrew Jackson)
  • Fehler bei Ausführung als root, sofern allow-root nicht aktiviert ist (David Steele)
  • Asynchrones archive-push beim ersten Fehler beendet (David Steele)

Weitere Funktionen und Verbesserungen sind in den Versionshinweisen zu 2.59.0 beschrieben.

Wichtige Hinweise

  • Standardmäßig darf nur der Befehl restore als root ausgeführt werden. Mit allow-root können andere Befehle als root ausgeführt werden (dies wird jedoch nicht empfohlen).
  • Ein neuer Distributions-Tarball mit vorgenerierter Dokumentation, Manpage und Code ist jeder Veröffentlichung beigefügt, um die Paketerstellung zu vereinfachen. Weitere Informationen stehen unter Neuer Distributions-Tarball .
  • Es gibt eine neue optionale Abhängigkeit von libsystemd.

Links

Sponsoren

Diese Version wurde durch die großzügige Förderung von AWS , Supabase , pgEdge , Tiger Data , Percona , Eon , Xata , Dalibo und Data Egret ermöglicht.

pgBackRest wird fortgeführt!

18. Mai 2026

Ich freue mich, bekanntgeben zu können, dass pgBackRest fortgeführt wird! In den vergangenen Wochen hat sich eine Gruppe von Sponsoren zusammengefunden, um die weitere Entwicklung zu finanzieren. Dank ihrer Unterstützung hängt das Projekt nicht mehr von einem einzigen Sponsor ab. Das gibt pgBackRest die nötige langfristige Stabilität.

Ich möchte jedem unserer Sponsoren danken:

Amazon Web Services stellt Privatpersonen, Unternehmen und Behörden Cloud-Computing-Ressourcen nach Bedarf zur Verfügung. Nutzen Sie Rechenleistung, Speicher, Datenbanken, maschinelles Lernen und über 200 Dienste und zahlen Sie nur für das, was Sie tatsächlich nutzen. Darauf ausgelegt, mit Ihnen zu wachsen und in die Gemeinschaften zu investieren, denen wir gemeinsam angehören.

Supabase ist eine vollständige Backend-Plattform auf Basis von PostgreSQL. Sie ermöglicht es Entwicklern, Anwendungen schnell zu erstellen und zu skalieren, ohne Infrastruktur verwalten zu müssen. Sie umfasst eine Postgres-Datenbank, Benutzerauthentifizierung, Echtzeitabonnements, Dateispeicher, Edge-Funktionen und serverlose Funktionen, unterstützt von einer aktiven Open-Source-Community.

pgEdge ist eine unternehmenstaugliche Open-Source-Postgres-Plattform für AI, Hochverfügbarkeit und weitere Einsatzgebiete. Sie bietet native Werkzeuge für agentenbasierte AI und eine DBA-Arbeitsumgebung, Überwachung und Reaktion auf Vorfälle, flexible Bereitstellung und Wartung ohne Ausfallzeiten. Sie skaliert von einem einzelnen Knoten bis zu einem Active-Active-Multi-Master-System in der Cloud, vor Ort oder in vom Netz getrennten Umgebungen.

Tiger Data , die Entwickler von TimescaleDB, entwickelt die auf PostgreSQL basierende Open-Source-Zeitreihendatenbank und betreibt Tiger Cloud, eine verwaltete Plattform für Zeitreihen, Analysen und AI-Arbeitslasten. Sowohl selbstverwaltete als auch Cloud-Angebote ermöglichen es Organisationen, Zeitreihendaten in großem Umfang zu erfassen, zu speichern und zu analysieren, von Edge- bis zu zentralen Cloud-Bereitstellungen.

Percona ist ein Unternehmen für Open-Source-Datenbanksoftware, Support und Dienstleistungen, das Organisationen dabei hilft, die volle Kontrolle über ihre Dateninfrastruktur zu behalten. Mit frei verfügbarer Open-Source-Software, fachkundigem 24/7-Support und praktischer Datenbankexpertise unterstützt es Unternehmen beim sicheren und effizienten Betrieb von MySQL, PostgreSQL, MongoDB, Valkey und Redis.

Eon.io ist eine intelligente Cloud-Infrastruktur für Backup, Recovery und Datenverwaltung. Sie hilft Teams, Backups effizienter zu speichern und darauf zuzugreifen, und macht Daten für Analyse- und AI-Abläufe zugänglich. Sie bietet schnelle, granulare Recovery und deutlich geringere Speicherkosten für Postgres und datenintensive Arbeitslasten in allen Clouds, einschließlich Recovery nach versehentlichem Datenverlust und Regressionen durch AI-Agenten.

Diese Organisationen setzen auf pgBackRest, um für ihre Produkte und Kunden eine zuverlässige Disaster Recovery zu gewährleisten. Ihre Investition spiegelt die entscheidende Rolle von pgBackRest im PostgreSQL-Ökosystem wider. Ihre gemeinsame Unterstützung sichert den langfristigen Fortbestand des Projekts.

Ich freue mich darauf, die Arbeit wieder aufzunehmen. Es sind Funktionen und Optimierungen in Vorbereitung, die ich in kommenden Versionen gerne vorstellen möchte. Vielen Dank an unsere Sponsoren, die dies ermöglichen, und an die Community für ihre Geduld und Unterstützung während dieses Übergangs.

Neuigkeiten zur Projektpflege

4. Mai 2026

Nachdem ich angekündigt hatte, pgBackRest nicht mehr zu pflegen, wurde mein Posteingang mit Nachrichten überflutet. Es hat eine Weile gedauert, sie zu sichten. Viele enthielten gute Wünsche und Dank für meine Arbeit über die Jahre.

Doch bald zeichnete sich ein Muster ab. Es ist klar, dass viele pgBackRest-Nutzer, insbesondere diejenigen, die ihrerseits pgBackRest-Nutzer betreuen, eine Fortführung des Projekts mit mir als Hauptbetreuer bevorzugen würden. Das würde ich mir selbst sehr wünschen, aber nach monatelanger Suche nach Finanzierung hatte ich gerade beschlossen, dass es nicht gelingen würde.

Nun hat sich die Lage geändert, und es scheint nahezu sicher, dass ich genügend Finanzierung für die Fortführung des Projekts sichern kann. Diesmal wird pgBackRest von einer Gruppe von Sponsoren finanziert, damit eine einzelne Firmenübernahme meine Fähigkeit zur weiteren Arbeit am Projekt nicht mehr beeinträchtigt. Wir sollten auch einen weiteren Betreuer hinzunehmen können, um die Arbeit zu verteilen und für Kontinuität in der Zukunft zu sorgen.

Ich weiß, dass dies ein Schock war und große Unsicherheit herrscht. Bitte haben Sie Geduld: Die aktuelle Version von pgBackRest funktioniert, und es gibt keine offenen kritischen Fehler oder Sicherheitsprobleme. Es ist daher nicht nötig, das Projekt sofort zu forken.

Ich rechne damit, bis Ende der Woche eine verbindlichere Ankündigung machen zu können. Bitte warten Sie bis dahin ab und seien Sie versichert, dass wir aktiv daran arbeiten, pgBackRest wiederzubeleben.

pgBackRest wird nicht mehr gepflegt

27. April 2026

TL;DR: pgBackRest wird nicht mehr gepflegt. Wenn Sie einen Fork von pgBackRest erstellen, wählen Sie bitte einen neuen Namen für Ihr Projekt.

Nach reiflicher Überlegung habe ich beschlossen, die Arbeit an pgBackRest einzustellen. Diese Entscheidung ist mir nicht leichtgefallen. pgBackRest war in den vergangenen dreizehn Jahren mein Herzensprojekt. Ich hatte das Glück, während eines großen Teils dieser Zeit von Unternehmen gefördert zu werden. Es gab aber auch viele späte Abende und Wochenenden, an denen ich mit Unterstützung zahlreicher Mitwirkender daran gearbeitet habe, pgBackRest zu dem Projekt zu machen, das es heute ist. Jeder Open-Source-Entwickler weiß genau, was ich meine und wie viel vom eigenen Leben einem besonderen Projekt gewidmet wird.

Seit dem Verkauf von Crunchy Data habe ich pgBackRest weiter gepflegt und nach einer Stelle gesucht, die mir die Fortsetzung dieser Arbeit ermöglichen würde. Bisher war ich damit jedoch nicht erfolgreich. Auch meine Bemühungen um Sponsoren blieben weit hinter dem zurück, was ich brauche, um das Projekt weiterführen zu können.

Wie jeder andere muss auch ich meinen Lebensunterhalt verdienen, und das Angebot an Stellen mit Bezug zu pgBackRest ist sehr begrenzt. Ich kann nun mehr Möglichkeiten in Betracht ziehen. Diese werden mir jedoch keine Zeit für die Arbeit an pgBackRest lassen, die viel Zeit für Pflege, Fehlerbehebungen, PR-Prüfungen, das Beantworten von Issues usw. erfordert. Darin ist noch nicht einmal die Zeit für neue Funktionen enthalten, die ich besonders gerne entwickle. Statt die Arbeit schlecht und/oder sporadisch zu erledigen, halte ich einen klaren Schlussstrich für sinnvoller.

Ich gehe davon aus, dass pgBackRest irgendwann geforkt wird. Das wird aber ein neues Projekt mit neuen Betreuern sein, die sich das Vertrauen genauso erarbeiten müssen wie wir.

Nochmals vielen Dank an alle, die über die Jahre zu pgBackRest beigetragen haben. Es war mir eine Freude, mit Ihnen zusammenzuarbeiten!

2 - Benutzerhandbuch (Debian/Ubuntu)

Schrittweise Anleitung zur Einrichtung und Verwendung von pgBackRest auf Debian- und Ubuntu-Systemen.

Einführung

Dieses Benutzerhandbuch sollte von Anfang bis Ende der Reihe nach durchgearbeitet werden, da jeder Abschnitt auf dem vorherigen aufbaut. Beispielsweise setzt der Abschnitt Wiederherstellung die Einrichtung aus dem Abschnitt Schnellstart voraus. Sobald pgBackRest eingerichtet ist und läuft, können einzelne Abschnitte gezielt aufgerufen werden. Beim ersten Durcharbeiten wird jedoch empfohlen, die Reihenfolge des Benutzerhandbuchs einzuhalten.

Die Beispiele in diesem Handbuch beziehen sich auf Debian/Ubuntu und PostgreSQL 17, sollten sich aber ohne großen Aufwand auf andere Unix-Distributionen und PostgreSQL-Versionen übertragen lassen. Nur die Befehle zum Erstellen, Starten, Stoppen und Löschen von PostgreSQL-Clustern sind betriebssystemspezifisch. Die pgBackRest-Befehle sind auf allen Unix-Systemen gleich, auch wenn der Speicherort der ausführbaren Datei abweichen kann. pgBackRest soll sich über PostgreSQL-Versionen hinweg einheitlich verhalten. Dennoch gibt es zwischen den PostgreSQL-Versionen kleinere Unterschiede, die in einigen Beispielen dieses Handbuchs sichtbar werden können, etwa bei PostgreSQL-Pfad- und Dateinamen sowie Einstellungen.

Informationen zur Konfiguration und die Dokumentation von PostgreSQL sind im PostgreSQL-Handbuch zu finden.

Dieses Benutzerhandbuch verwendet einen etwas ungewöhnlichen Ansatz zur Dokumentation: Beim Erstellen der Dokumentation aus der XML-Quelle wird jeder Befehl auf einer virtuellen Maschine ausgeführt. Dadurch lässt sich mit hoher Zuverlässigkeit davon ausgehen, dass die Befehle in der angegebenen Reihenfolge korrekt funktionieren. Wo sinnvoll, wird die Ausgabe erfasst und unter dem Befehl angezeigt. Fehlende Ausgaben wurden als nicht relevant eingestuft oder weggelassen, weil sie vom beschriebenen Ablauf ablenken würden.

Alle Befehle sind für die Ausführung durch einen unprivilegierten Benutzer vorgesehen, der sudo-Rechte für die Benutzer root und postgres besitzt. Sie können auch unverändert direkt unter dem jeweiligen Benutzer ausgeführt werden; in diesem Fall können die vorangestellten sudo-Befehle entfallen.

Konzepte

Die folgenden Begriffe werden in ihrer Bedeutung für pgBackRest, PostgreSQL und dieses Benutzerhandbuch definiert.

Backup

Ein Backup ist eine konsistente Kopie eines Datenbankclusters. Es kann wiederhergestellt werden, um den Betrieb nach einem Hardwareausfall wieder aufzunehmen, eine Point-in-Time-Recovery durchzuführen oder einen neuen Standby in Betrieb zu nehmen.

Vollständiges Backup: pgBackRest kopiert den gesamten Inhalt des Datenbankclusters in das Backup. Das erste Backup eines Datenbankclusters ist immer ein vollständiges Backup. pgBackRest kann ein vollständiges Backup jederzeit direkt wiederherstellen. Für seine Konsistenz ist es auf keine Dateien außerhalb dieses vollständigen Backups angewiesen.

Differenzielles Backup: pgBackRest kopiert nur die Dateien des Datenbankclusters, die sich seit dem letzten vollständigen Backup geändert haben. Bei der Wiederherstellung eines differenziellen Backups kopiert pgBackRest alle Dateien aus dem gewählten differenziellen Backup und die zugehörigen unveränderten Dateien aus dem vorherigen vollständigen Backup. Ein differenzielles Backup benötigt weniger Speicherplatz als ein vollständiges Backup. Für seine Wiederherstellung müssen jedoch sowohl das differenzielle als auch das vollständige Backup gültig sein.

Inkrementelles Backup: pgBackRest kopiert nur die Dateien des Datenbankclusters, die sich seit dem letzten Backup geändert haben. Dieses kann ein anderes inkrementelles, ein differenzielles oder ein vollständiges Backup sein. Da ein inkrementelles Backup nur die seit dem vorherigen Backup geänderten Dateien enthält, ist es in der Regel deutlich kleiner als ein vollständiges oder differenzielles Backup. Wie beim differenziellen Backup müssen für die Wiederherstellung eines inkrementellen Backups auch andere Backups gültig sein. Da es nur die seit dem letzten Backup geänderten Dateien enthält, müssen alle vorherigen inkrementellen Backups bis zum vorherigen differenziellen Backup sowie dieses differenzielle und das vorherige vollständige Backup gültig sein. Gibt es kein differenzielles Backup, müssen alle vorherigen inkrementellen Backups bis zum vorherigen vollständigen Backup sowie das vollständige Backup selbst gültig sein; ein vollständiges Backup muss vorhanden sein.

Wiederherstellung

Bei einer Wiederherstellung wird ein Backup auf ein System kopiert, auf dem es als aktiver Datenbankcluster gestartet wird. Für eine korrekte Wiederherstellung werden die Backup-Dateien und ein oder mehrere WAL-Segmente benötigt.

Write-Ahead-Log (WAL)

Mit dem WAL stellt PostgreSQL sicher, dass keine durch Commit bestätigten Änderungen verloren gehen. Transaktionen werden sequenziell in das WAL geschrieben. Eine Transaktion gilt als bestätigt, sobald diese Schreibvorgänge dauerhaft auf dem Datenträger gespeichert sind. Anschließend schreibt ein Hintergrundprozess die Änderungen in die eigentlichen Dateien des Datenbankclusters, die auch als Heap bezeichnet werden. Nach einem Absturz wird das WAL erneut angewendet, um die Datenbank in einen konsistenten Zustand zu bringen.

Das WAL ist konzeptionell unendlich, wird in der Praxis jedoch in einzelne 16MB-Dateien, sogenannte Segmente, unterteilt. WAL-Segmente folgen der Namenskonvention 0000000100000A1E000000FE: Die ersten 8 Hexadezimalziffern stehen für die Timeline, die folgenden 16 Ziffern für die logische Sequenznummer (LSN).

Verschlüsselung

Bei der Verschlüsselung werden Daten in ein Format umgewandelt, das ohne das passende Passwort, auch Passphrase genannt, nicht lesbar ist.

pgBackRest verschlüsselt das Repository basierend auf einem vom Benutzer bereitgestellten Passwort, wodurch ein unbefugter Zugriff auf die im Repository gespeicherten Daten verhindert wird.

Upgrade von pgBackRest

Upgrade von pgBackRest von v2.x auf v2.y

Ein Upgrade von v2.x auf v2.y ist unkompliziert. Das Repository-Format hat sich nicht geändert, sodass bei den meisten Installationen lediglich die Binärdateien der neuen Version installiert werden müssen. Ein Downgrade ist ebenfalls möglich, solange keine neuen Funktionen verwendet wurden, die die ältere Version nicht unterstützt.

WICHTIG:

Die pgBackRest-Versionen auf dem lokalen und dem entfernten Host müssen exakt übereinstimmen und sollten daher gemeinsam aktualisiert werden. Bei einer Abweichung funktionieren WAL-Archivierung und Backups erst wieder, wenn die Versionen übereinstimmen. In diesem Fall wird folgender Fehler gemeldet: [ProtocolError] expected value '2.x' for greeting key 'version' but got '2.y'.

Kompilierung

Die Installation von pgBackRest aus einem Paket ist der Kompilierung aus dem Quellcode vorzuziehen. Weitere Informationen zu Paketen stehen unter Installation .

Für die Kompilierung aus dem Quellcode empfiehlt sich ein eigener Build-Host, statt direkt in der Produktionsumgebung zu kompilieren. Viele der dafür benötigten Werkzeuge sollten grundsätzlich nicht in der Produktionsumgebung installiert werden. pgBackRest besteht aus einer einzigen ausführbaren Datei, die nach der Kompilierung leicht auf einen neuen Host kopiert werden kann.

build ⇒ Version 2.59.3 von pgBackRest unter /build herunterladen

mkdir -p /build
curl -fsSL \
       https://github.com/pgbackrest/pgbackrest/releases/download/release%2F2.59.3/pgbackrest-2.59.3.tar.gz | \
       tar zx -C /build

build ⇒ Build-Abhängigkeiten installieren

sudo apt-get install python3-distutils meson gcc libpq-dev libssl-dev libxml2-dev \
       pkg-config liblz4-dev libzstd-dev libbz2-dev libz-dev libssh2-1-dev libsystemd-dev

build ⇒ pgBackRest konfigurieren und kompilieren

meson setup /build/pgbackrest /build/pgbackrest-2.59.3
ninja -C /build/pgbackrest

build ⇒ Optional Smoke-Tests ausführen, um die korrekte Kompilierung von pgBackRest zu prüfen

meson test -C /build/pgbackrest --suite smoke
ninja: Entering directory `/build/pgbackrest'
ninja: no work to do.
1/1 smoke OK               11.07s


       [filtered 7 lines of output]

Installation

Ein neuer Host namens pg-primary wird für den Demo-Cluster und die Ausführung der pgBackRest-Beispiele eingerichtet.

Die Installation von pgBackRest aus einem Paket ist der Kompilierung aus dem Quellcode vorzuziehen. Bei einer Paketinstallation sind die übrigen Anweisungen in diesem Abschnitt normalerweise nicht erforderlich. Es kann jedoch vorkommen, dass ein Paket eines der Verzeichnisse nicht anlegt oder falsche Berechtigungen vergibt. In diesem Fall kann es erforderlich sein, Verzeichnisse manuell anzulegen oder Berechtigungen anzupassen.

Debian/Ubuntu-Pakete für pgBackRest sind unter apt.postgresql.org verfügbar.

Falls für Ihre Distribution oder Version keine Pakete bereitstehen, können Sie pgBackRest aus dem Quellcode kompilieren und anschließend wie hier gezeigt manuell installieren.

pg-primary ⇒ Abhängigkeiten installieren

sudo apt-get install postgresql-client libxml2 libssh2-1

pg-primary ⇒ pgBackRest-Binärdatei vom Build-Host kopieren

sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest

pgBackRest benötigt Protokoll- und Konfigurationsverzeichnisse sowie eine Konfigurationsdatei.

pg-primary ⇒ pgBackRest-Konfigurationsdatei und Verzeichnisse erstellen

sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf

pgBackRest sollte nun ordnungsgemäß installiert sein, aber es ist ratsam, dies zu überprüfen. Falls Abhängigkeiten vergessen wurden, erhalten Sie einen Fehler, wenn Sie pgBackRest über die Befehlszeile ausführen.

pg-primary ⇒ Sicherstellen, dass die Installation erfolgreich war

sudo -u postgres pgbackrest
pgBackRest 2.59.3 - General help

Usage:
    pgbackrest [options] [command]

Commands:
    annotate        add or modify backup annotation
    archive-get     get a WAL segment from the archive
    archive-push    push a WAL segment to the archive
    backup          backup a database cluster
    check           check the configuration
    expire          expire backups that exceed retention
    help            get help
    info            retrieve information about backups
    repo-get        get a file from a repository
    repo-ls         list files in a repository
    restore         restore a database cluster
    server          pgBackRest server
    server-ping     ping pgBackRest server
    stanza-create   create the required stanza data
    stanza-delete   delete a stanza
    stanza-upgrade  upgrade a stanza
    start           allow pgBackRest processes to run
    stop            stop pgBackRest processes from running
    verify          verify contents of a repository
    version         get version

Use 'pgbackrest help [command]' for more information.

Schnellstart

Der Schnellstart-Abschnitt behandelt die grundlegende Konfiguration von pgBackRest und PostgreSQL und führt die Befehle backup, restore und info ein.

Demo-Cluster einrichten

Das Erstellen des Demo-Clusters ist optional, wird jedoch insbesondere neuen Benutzern dringend empfohlen, da die Beispielbefehle im Benutzerhandbuch auf ihn verweisen. Die Beispiele setzen voraus, dass der Demo-Cluster auf dem Standardport 5432 läuft. Der Cluster wird erst in einem späteren Abschnitt gestartet, da zuvor noch einige Einstellungen vorgenommen werden müssen.

pg-primary ⇒ Demo-Cluster erstellen

sudo -u postgres /usr/lib/postgresql/17/bin/initdb \
       -D /var/lib/postgresql/17/demo -k -A peer
sudo pg_createcluster 17 demo
Configuring already existing cluster (configuration: /etc/postgresql/17/demo, data: /var/lib/postgresql/17/demo, owner: 102:103)
Ver Cluster Port Status Owner    Data directory              Log file
17  demo    5432 down   postgres /var/lib/postgresql/17/demo /var/log/postgresql/postgresql-17-demo.log

Cluster-Stanza konfigurieren

Eine Stanza ist die Konfiguration für einen PostgreSQL-Datenbankcluster. Sie legt unter anderem seinen Speicherort, die Durchführung von Backups und die Archivierungsoptionen fest. Die meisten Datenbankserver betreiben nur einen PostgreSQL-Datenbankcluster und haben daher eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Besser ist jedoch ein Name, der die im Cluster enthaltenen Datenbanken beschreibt. Da der Name der Stanza für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

Der Name „demo“ beschreibt den Zweck dieses Clusters treffend und eignet sich daher auch als Name der Stanza.

pgBackRest muss den Speicherort des Basisdatenverzeichnisses des PostgreSQL-Clusters kennen. Der Pfad kann direkt von PostgreSQL abgefragt werden, doch bei einer Recovery steht der PostgreSQL-Prozess nicht zur Verfügung. Während eines Backups wird der für pgBackRest angegebene Wert mit dem von PostgreSQL verwendeten Pfad verglichen. Beide müssen übereinstimmen, andernfalls meldet das Backup einen Fehler. Sicherstellen, dass pg-path exakt dem von PostgreSQL gemeldeten data_directory entspricht.

Debian/Ubuntu speichert Cluster standardmäßig unter /var/lib/postgresql/[version]/[cluster], sodass sich der richtige Pfad zum Datenverzeichnis leicht bestimmen lässt.

Beim Erstellen der Datei /etc/pgbackrest/pgbackrest.conf muss dem Datenbankeigentümer, normalerweise postgres, Leseberechtigung erteilt werden.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Datenverzeichnis des PostgreSQL-Clusters konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo

Die Konfigurationsdateien von pgBackRest folgen einer Konvention ähnlich dem INI-Format von Windows. Abschnitte werden durch Text in eckigen Klammern gekennzeichnet und enthalten Schlüssel-Wert-Paare. Zeilen, die mit # beginnen, werden ignoriert und können als Kommentare verwendet werden. Kommentare nach einem Wert in derselben Zeile werden jedoch nicht unterstützt. Anführungszeichen werden nicht unterstützt; Leerraum am Anfang und Ende von Schlüsseln und Werten wird entfernt. Mehrfach vorkommende Abschnitte werden zusammengeführt.

Die Konfigurationsdateien von pgBackRest können auf mehrere Arten geladen werden:

  • config und config-include-path haben ihre Standardwerte: Die Standardkonfigurationsdatei wird geladen, sofern sie existiert. Vorhandene *.conf-Dateien im standardmäßigen Konfigurations-Include-Pfad werden angehängt.
  • Die Option config ist angegeben: Nur die angegebene Konfigurationsdatei wird geladen; sie muss existieren.
  • config-include-path ist angegeben: Die *.conf-Dateien im Konfigurations-Include-Pfad werden geladen; der Pfad muss existieren. Die Standardkonfigurationsdatei wird geladen, sofern sie existiert. Sollen nur die Dateien im angegebenen Konfigurations-Include-Pfad geladen werden, kann zusätzlich die Option --no-config übergeben werden.
  • config und config-include-path sind angegeben: Die Konfigurationsdatei wird anhand der benutzerdefinierten Werte geladen und die *.conf-Dateien im Konfigurations-Include-Pfad werden angehängt. Die Dateien müssen existieren.
  • config-path ist angegeben: Diese Einstellung überschreibt den Basispfad des Standardspeicherorts der Konfigurationsdatei und/oder den Basispfad der Standardeinstellung von config-include-path, sofern die Option config und/oder config-include-path nicht ausdrücklich gesetzt ist.

Die Dateien werden so zusammengefügt, als wären sie eine einzige große Datei; jede Datei muss jedoch für sich gültig sein. Das bedeutet, dass Abschnitte in jeder Datei angegeben werden müssen, in der sie zum Speichern eines Schlüssel-Wert-Paars benötigt werden. Die Reihenfolge ist unerheblich, doch es gilt eine Rangfolge der Abschnitte. Die Priorität ist, von der höchsten zur niedrigsten:

  • [stanza:command]
  • [stanza]
  • [global:command]
  • [global]

HINWEIS:

--config, --config-include-path und --config-path sind ausschließlich über die Befehlszeile verfügbare Optionen.

pgBackRest kann auch über Umgebungsvariablen konfiguriert werden, wie im folgenden Beispiel gezeigt. Diese Variablen gelten für Befehle wie backup , restore und archive-push .

pg-primary ⇒ log-path über die Umgebung konfigurieren

sudo -u postgres bash -c ' \
       export PGBACKREST_LOG_PATH=/path/set/by/env && \
       pgbackrest --log-level-console=error help backup log-path'
pgBackRest 2.59.3 - 'backup' command - 'log-path' option help

Path where log files are stored.

The log path provides a location for pgBackRest to store log files. Note that
if log-level-file=off then no log path is required.

current: /path/set/by/env
default: /var/log/pgbackrest

Repository erstellen

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus möglicherweise nur schwer abschätzen. Am besten werden einige Backups erstellt und die Größe der verschiedenen Backup-Typen (full/incr/diff) sowie die täglich erzeugte WAL-Menge erfasst. Das liefert eine grobe Vorstellung vom Speicherbedarf. Dieser wird sich allerdings im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

Für diese Demonstration wird das Repository auf demselben Host wie der PostgreSQL-Server gespeichert. Dies ist die einfachste Konfiguration und eignet sich für Fälle, in denen der Datenbankhost mit herkömmlicher Backup-Software gesichert wird.

pg-primary ⇒ pgBackRest-Repository erstellen

sudo mkdir -p /var/lib/pgbackrest
sudo chmod 750 /var/lib/pgbackrest
sudo chown postgres:postgres /var/lib/pgbackrest

Der Repository-Pfad muss konfiguriert werden, damit pgBackRest das Repository finden kann.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Pfad zum pgBackRest-Repository konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-path=/var/lib/pgbackrest

Es können auch mehrere Repositorys konfiguriert werden. Einzelheiten stehen unter Mehrere Repositorys .

Archivierung konfigurieren

Für das Backup eines laufenden PostgreSQL-Clusters muss die WAL-Archivierung aktiviert sein. Mit %p gibt PostgreSQL den Speicherort des zu archivierenden WAL-Segments an. Während des Backups wird mindestens ein WAL-Segment erzeugt, auch wenn keine ausdrücklichen Schreibzugriffe auf den Cluster erfolgen.

pg-primary:/etc/postgresql/17/demo/postgresql.conf ⇒ Archivierungseinstellungen konfigurieren

archive_command = 'pgbackrest --stanza=demo archive-push %p'

archive_mode = on

Nach diesen Änderungen muss der PostgreSQL-Cluster neu gestartet werden, bevor ein Backup durchgeführt wird.

pg-primary ⇒ Demo-Cluster neu starten

sudo pg_ctlcluster 17 demo restart

Die Einstellung hot_standby ist standardmäßig aktiviert und sollte auf jedem Cluster aktiviert bleiben. Jeder Cluster kann später als Standby wiederhergestellt werden, beispielsweise ein Primärserver, der nach einem Failover als Standby neu aufgebaut wird. Ohne diese Einstellung akzeptiert ein Standby keine schreibgeschützten Verbindungen.

Wenn zu erwarten ist, dass ein zu archivierendes WAL-Segment mehr als 60 Sekunden, den Standardwert, benötigt, um das pgBackRest-Repository zu erreichen, sollte die pgBackRest-Option archive-timeout erhöht werden. Diese Option ist nicht mit der PostgreSQL-Option archive_timeout identisch. Letztere erzwingt einen WAL-Segmentwechsel und ist bei Datenbanken mit längeren Phasen ohne Aktivität nützlich. Weitere Informationen zur PostgreSQL-Option archive_timeout stehen unter Write-Ahead-Log in der PostgreSQL-Dokumentation.

Für den Befehl archive-push können eigene Optionen konfiguriert werden. Beispielsweise lässt sich eine niedrigere Komprimierungsstufe festlegen, um die Archivierung zu beschleunigen, ohne die Komprimierung für Backups zu beeinflussen.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ archive-push für eine niedrigere Komprimierungsstufe konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-path=/var/lib/pgbackrest



[global:archive-push]

compress-level=3

Diese Art der Konfiguration kann für jeden Befehl verwendet werden und sich auch auf eine bestimmte Stanza beziehen, beispielsweise demo:archive-push.

Aufbewahrung konfigurieren

pgBackRest entfernt Backups anhand der Aufbewahrungsoptionen.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Aufbewahrung auf 2 vollständige Backups festlegen

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2



[global:archive-push]

compress-level=3

Weitere Informationen zur Aufbewahrung stehen im Abschnitt Aufbewahrung .

Repository-Verschlüsselung konfigurieren

Zur Demonstration der Verschlüsselung werden für das Repository ein Verschlüsselungstyp und ein Schlüssel konfiguriert. Die Verschlüsselung erfolgt immer auf der Clientseite, auch wenn der Repository-Typ, beispielsweise S3 oder ein anderer Objektspeicher, Verschlüsselung unterstützt.

Für den Schlüssel ist eine lange, zufällige Passphrase wichtig. Sie lässt sich beispielsweise mit folgendem Befehl erzeugen: openssl rand -base64 48.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Verschlüsselung des pgBackRest-Repositorys konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2



[global:archive-push]

compress-level=3

HINWEIS:

Die Verschlüsselungseinstellungen werden oben im Abschnitt [global] abgelegt, damit der Befehl info alle Stanzas lesen kann. Ohne die Option stanza liest info Verschlüsselungseinstellungen ausschließlich aus dem Abschnitt [global]. Werden die Verschlüsselungseinstellungen pro Stanza konfiguriert, ist daher die Option stanza erforderlich, um eine verschlüsselte Stanza zu lesen.

Nachdem das Repository konfiguriert und die Stanza erstellt und geprüft wurde, können die Verschlüsselungseinstellungen des Repositorys nicht mehr geändert werden.

Stanza erstellen

Zum Initialisieren der Stanza muss der Befehl stanza-create ausgeführt werden. Es wird empfohlen, nach stanza-create den Befehl check auszuführen, um sicherzustellen, dass Archivierung und Backups korrekt konfiguriert sind.

pg-primary ⇒ Stanza erstellen und Konfiguration prüfen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create
P00   INFO: stanza-create command begin 2.59.3: --exec-id=415-9c2d1500 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo
P00   INFO: stanza-create for stanza 'demo' on repo1
P00   INFO: stanza-create command end: completed successfully

Konfiguration prüfen

Der Befehl check prüft, ob pgBackRest und die Einstellung archive_command für Archivierung und Backups der angegebenen Stanza korrekt konfiguriert sind. Er versucht, alle Repositorys und Datenbanken zu prüfen, die für den Host konfiguriert sind, auf dem er ausgeführt wird. Er erkennt Fehlkonfigurationen, insbesondere bei der Archivierung, die zu unvollständigen Backups führen, weil erforderliche WAL-Segmente das Archiv nicht erreicht haben. Der Befehl kann auf dem PostgreSQL- oder dem Repository-Host ausgeführt werden. Er kann auch auf dem Standby-Host ausgeführt werden. Da pg_switch_xlog()/pg_switch_wal() auf dem Standby jedoch nicht ausgeführt werden können, prüft er dort nur die Repository-Konfiguration.

Dabei werden pg_create_restore_point('pgBackRest Archive Check') und pg_switch_xlog()/pg_switch_wal() aufgerufen, um PostgreSQL zur Archivierung eines WAL-Segments zu veranlassen.

pg-primary ⇒ Konfiguration prüfen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info check
P00   INFO: check command begin 2.59.3: --exec-id=424-7270037b --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 000000010000000000000001 successfully archived to '/var/lib/pgbackrest/archive/demo/17-1/0000000100000000/000000010000000000000001-e8eb01b8d8aaf321d368dc8edf5b559247841eb1.gz' on repo1
P00   INFO: check command end: completed successfully

Leistungsoptimierung

pgBackRest bietet mehrere Leistungsoptionen, die standardmäßig deaktiviert sind, um die Abwärtskompatibilität des Repositorys zu wahren. Beim Erstellen eines neuen Repositorys werden die folgenden Optionen jedoch empfohlen. Sie können auch mit einem vorhandenen Repository verwendet werden, allerdings können ältere pgBackRest-Versionen das Repository dann nicht mehr lesen. Diese Inkompatibilität hängt davon ab, wann die jeweilige Funktion eingeführt wurde, wie in der folgenden Liste angegeben.

  • compress-type - legt den Komprimierungsalgorithmus für die Befehle backup und archive-push fest. Der Standardwert ist gz (Gzip), empfohlen wird jedoch zst (Zstandard), da es deutlich schneller ist und eine ähnliche Komprimierung wie gz bietet. Die Option compress-type unterstützt zst seit v2.27 . Weitere Einzelheiten stehen unter Komprimierungstyp .
  • repo-bundle - fasst beim Backup kleine Dateien zusammen, um Speicherplatz zu sparen und die Befehle backup und restore zu beschleunigen, insbesondere bei Objektspeichern wie S3. Die Option repo-bundle wurde in v2.39 eingeführt. Weitere Einzelheiten stehen unter Dateibündelung .
  • repo-block - speichert bei einem diff/incr-backup nur die geänderten Teile einer Datei statt der gesamten Datei. Das spart Speicherplatz und beschleunigt das backup. Die Option repo-block wurde in v2.46 eingeführt, empfohlen wird jedoch mindestens v2.52.1 . Weitere Einzelheiten stehen unter Inkrementelle Backups auf Blockebene .

Weitere Leistungsoptionen sind standardmäßig deaktiviert, weil sie zusätzliche Konfiguration erfordern oder weil der Standardwert sicher, aber nicht optimal ist. Diese Optionen stehen in allen v2-Versionen von pgBackRest zur Verfügung.

  • process-max - legt fest, wie viele Prozesse für Befehle verwendet werden. Der Standardwert ist 1 und fast nie angemessen. Jeder Befehl verwendet process-max anders; Einzelheiten zur Verwendung stehen daher in der jeweiligen Befehlsdokumentation.
  • archive-async - archiviert WAL-Dateien stapelweise im Repository und erhöht dadurch die Archivierungsgeschwindigkeit erheblich. Die Option ist standardmäßig deaktiviert, da ein Spool-Pfad angelegt werden muss. Weitere Einzelheiten stehen unter Asynchrone Archivierung .
  • backup-standby - führt das Backup auf einem Standby statt auf dem Primärserver durch, um dessen Last zu verringern. Die Option ist standardmäßig deaktiviert, da sie zusätzliche Konfiguration und mindestens einen Standby-Host erfordert. Weitere Einzelheiten stehen unter Backup von einem Standby .

Backup durchführen

Standardmäßig wartet pgBackRest vor dem Beginn eines Backups auf den nächsten regulär geplanten Checkpoint. Je nach den PostgreSQL-Einstellungen checkpoint_timeout und checkpoint_segments kann es recht lange dauern, bis ein Checkpoint abgeschlossen ist und das Backup beginnen kann. Im Allgemeinen empfiehlt sich start-fast=y, damit das Backup sofort beginnt. Dadurch wird ein Checkpoint erzwungen. Da Backups normalerweise einmal täglich durchgeführt werden, sollte ein zusätzlicher Checkpoint die Leistung jedoch nicht spürbar beeinflussen. Bei sehr stark ausgelasteten Clustern kann es dagegen besser sein, --start-fast bei Bedarf über die Befehlszeile zu übergeben.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Schnellen Backup-Start konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

Für ein Backup des PostgreSQL-Clusters pgBackRest mit dem Befehl backup ausführen.

pg-primary ⇒ Backup des Demo-Clusters erstellen

sudo -u postgres pgbackrest --stanza=demo \
       --log-level-console=info backup
P00   INFO: backup command begin 2.59.3: --exec-id=451-67e8eca3 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo --start-fast
P00   WARN: no prior backup exists, incr backup has been changed to full
P00   INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 000000010000000000000002, lsn = 0/2000028
       [filtered 3 lines of output]
P00   INFO: check archive for segment(s) 000000010000000000000002:000000010000000000000003
P00   INFO: new backup label = 20261002-190624F
P00   INFO: full backup size = 22MB, file total = 963
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=451-67e8eca3 --log-level-console=info --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo

Standardmäßig versucht pgBackRest, ein inkrementelles Backup durchzuführen. Ein inkrementelles Backup muss jedoch auf einem vollständigen Backup basieren. Da noch keines vorhanden war, hat pgBackRest stattdessen ein vollständiges Backup erstellt.

Mit der Option type lässt sich ein vollständiges oder differenzielles Backup angeben.

pg-primary ⇒ Differenzielles Backup des Demo-Clusters erstellen

sudo -u postgres pgbackrest --stanza=demo --type=diff \
       --log-level-console=info backup
       [filtered 7 lines of output]
P00   INFO: check archive for segment(s) 000000010000000000000004:000000010000000000000005
P00   INFO: new backup label = 20261002-190624F_20261002-190626D
P00   INFO: diff backup size = 8.3KB, file total = 963
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=477-af59c897 --log-level-console=info --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo

Diesmal gab es keine Warnung, da bereits ein vollständiges Backup vorhanden war. Inkrementelle Backups können auf einem vollständigen oder differenziellen Backup basieren; differenzielle Backups müssen hingegen auf einem vollständigen Backup basieren. Ein vollständiges Backup lässt sich mit dem Befehl backup und der Option --type=full durchführen.

Bei einem Online-Backup wartet pgBackRest, bis die für die Konsistenz des Backups erforderlichen WAL-Segmente archiviert wurden. Diese Wartezeit wird durch die pgBackRest-Option archive-timeout bestimmt, deren Standardwert 60 Sekunden beträgt. Wenn die Archivierung eines einzelnen Segments bekanntermaßen länger dauert, sollte dieser Wert erhöht werden.

Backups planen

Backups können mit Werkzeugen wie cron geplant werden.

Im folgenden Beispiel werden zwei cron-Jobs eingerichtet: Vollständige Backups laufen sonntags um 6:30 Uhr morgens, differenzielle Backups montags bis samstags ebenfalls um 6:30 Uhr morgens. Wird diese crontab erstmals mitten in der Woche installiert, führt pgBackRest beim ersten Aufruf des differenziellen Jobs ein vollständiges Backup aus. Am folgenden Tag wird dann ein differenzielles Backup erstellt.

#m h   dom mon dow   command
30 06  *   *   0     pgbackrest --type=full --stanza=demo backup
30 06  *   *   1-6   pgbackrest --type=diff --stanza=demo backup

Nach dem Einrichten des Backup-Zeitplans ist es wichtig, auch die Aufbewahrung passend zu konfigurieren, damit Backups regelmäßig entfernt werden; siehe Aufbewahrung .

Backup-Informationen

Mit dem Befehl info lassen sich Informationen über Backups abrufen.

pg-primary ⇒ Informationen zum Demo-Cluster abrufen

sudo -u postgres pgbackrest info
stanza: demo
    status: ok
    cipher: aes-256-cbc

    db (current)
        wal archive min/max (17): 000000010000000000000001/000000010000000000000005

        full backup: 20261002-190624F
            timestamp start/stop: 2026-10-02 19:06:24+00 / 2026-10-02 19:06:26+00
            wal start/stop: 000000010000000000000002 / 000000010000000000000003
            database size: 22MB, database backup size: 22MB
            repo1: backup set size: 2.9MB, backup size: 2.9MB

        diff backup: 20261002-190624F_20261002-190626D
            timestamp start/stop: 2026-10-02 19:06:26+00 / 2026-10-02 19:06:28+00
            wal start/stop: 000000010000000000000004 / 000000010000000000000005
            database size: 22MB, database backup size: 8.3KB
            repo1: backup set size: 2.9MB, backup size: 448B
            backup reference total: 1 full

Der Befehl info arbeitet mit einer einzelnen Stanza oder allen Stanzas. Die standardmäßige Textausgabe bietet eine für Menschen lesbare Übersicht der Backups für die angeforderten Stanzas. Dieses Format kann sich mit jeder Version ändern.

Für maschinenlesbare Ausgabe --output=json verwenden. Die JSON-Ausgabe enthält wesentlich mehr Informationen als die Textausgabe und bleibt stabil, sofern kein Fehler gefunden wird.

Um die Ausführung zu beschleunigen, kann die Ausgabe mit --detail-level=progress auf Fortschrittsinformationen beschränkt werden. Dabei werden alle Prüfungen außer der Verfügbarkeit der Stanza übersprungen.

Jede Stanza hat einen eigenen Abschnitt. Mit der Option --stanza lässt sich die Ausgabe auf eine einzelne Stanza beschränken. Der ‘status’ gibt einen kurzen Überblick über den Zustand der Stanza. Bei ‘ok’ funktioniert pgBackRest normal. Bei mehreren Repositorys bedeutet der Status ‘mixed’, dass die Stanza in mindestens einem Repository nicht fehlerfrei ist; in diesem Fall wird ihr Zustand für jedes Repository einzeln angegeben. Tritt in einem Repository ein Fehler auf, der keinem bekannten Fehlercode entspricht, wird der Fehlercode ‘other’ verwendet und der Fehler vollständig beschrieben. ‘wal archive min/max’ zeigt das kleinste und das größte derzeit im Archiv gespeicherte WAL-Segment. Bei mehreren Repositorys bezieht sich diese Angabe auf alle Repositorys, sofern die Option --repo nicht gesetzt ist. Durch Regeln zur Archivaufbewahrung oder aus anderen Gründen können Lücken vorhanden sein.

Wenn einer dieser Befehle gerade auf dem Host läuft, erscheinen die Meldungen ‘backup/expire running’ und/oder ‘restore running’ neben der ‘status’-Angabe. Die Textausgabe enthält außerdem den Fortschritt pro Repository; in der JSON-Ausgabe wird ein ‘repo’-Array eingefügt.

Die Backups werden vom ältesten zum neuesten angezeigt. Das älteste Backup ist immer ein vollständiges Backup, gekennzeichnet durch ein F am Ende der Bezeichnung. Das neueste Backup kann vollständig, differenziell mit der Endung D oder inkrementell mit der Endung I sein.

‘timestamp start/stop’ gibt den Zeitraum an, in dem das Backup ausgeführt wurde. Mit ‘timestamp stop’ lässt sich bestimmen, welches Backup für eine Point-in-Time-Recovery verwendet werden soll. Weitere Informationen zur Point-in-Time-Recovery stehen im Abschnitt Point-in-Time-Recovery .

‘wal start/stop’ gibt den WAL-Bereich an, der benötigt wird, um die Datenbank bei der Wiederherstellung konsistent zu machen. Der Befehl backup stellt vor seinem Abschluss sicher, dass dieser WAL-Bereich im Archiv vorhanden ist.

‘database size’ ist die gesamte unkomprimierte Größe der Datenbank. ‘database backup size’ bezeichnet dagegen die tatsächlich zu sichernde Datenmenge in der Datenbank. Bei vollständigen Backups stimmen beide Werte überein.

‘repo’ gibt an, in welchem Repository sich das Backup befindet. ‘backup set size’ umfasst alle Dateien dieses Backups sowie aller referenzierten Backups im Repository, die benötigt werden, um die Datenbank aus diesem Backup wiederherzustellen. ‘backup size’ umfasst dagegen nur die Dateien dieses Backups. Bei vollständigen Backups stimmen auch diese Werte überein. Wenn in pgBackRest die Komprimierung aktiviert ist, geben die Repository-Größen die komprimierten Dateigrößen an.

‘backup reference total’ fasst die Liste der weiteren Backups zusammen, die zur Wiederherstellung dieses Backups benötigt werden. Mit der Option --set lässt sich die vollständige Referenzliste anzeigen.

Backup wiederherstellen

Backups können vor verschiedenen Ausfallszenarien schützen, insbesondere Hardwareausfällen und Datenbeschädigungen. Am einfachsten lässt sich eine Datenbeschädigung simulieren, indem eine wichtige Datei des PostgreSQL-Clusters entfernt wird.

pg-primary ⇒ Demo-Cluster stoppen und die Datei pg_control löschen

sudo pg_ctlcluster 17 demo stop
sudo -u postgres rm /var/lib/postgresql/17/demo/global/pg_control

Beim Starten des Clusters ohne diese wichtige Datei tritt ein Fehler auf.

pg-primary ⇒ Start des beschädigten Demo-Clusters versuchen

sudo pg_ctlcluster 17 demo start
Error: /usr/lib/postgresql/17/bin/pg_ctl /usr/lib/postgresql/17/bin/pg_ctl start -D /var/lib/postgresql/17/demo -l /var/log/postgresql/postgresql-17-demo.log -s -o  -c config_file="/etc/postgresql/17/demo/postgresql.conf"  exited with status 1:
postgres: could not find the database system
Expected to find it in the directory "/var/lib/postgresql/17/demo",
but could not open file "/var/lib/postgresql/17/demo/global/pg_control": No such file or directory
Examine the log output.

Zur Wiederherstellung eines Backups des PostgreSQL-Clusters pgBackRest mit dem Befehl restore ausführen. Der Cluster muss gestoppt sein, was hier bereits der Fall ist, und alle Dateien müssen aus dem PostgreSQL-Datenverzeichnis entfernt werden.

pg-primary ⇒ Alte Dateien aus dem Demo-Cluster entfernen

sudo -u postgres find /var/lib/postgresql/17/demo -mindepth 1 -delete

pg-primary ⇒ Demo-Cluster wiederherstellen und PostgreSQL starten

sudo -u postgres pgbackrest --stanza=demo restore
sudo pg_ctlcluster 17 demo start

Diesmal wurde der Cluster erfolgreich gestartet, da die Wiederherstellung die fehlende Datei pg_control ersetzt hat.

Weitere Informationen zum Befehl restore stehen im Abschnitt Wiederherstellung .

Überwachung

Die Überwachung ist ein wichtiger Bestandteil jedes Produktionssystems. Es stehen zahlreiche Werkzeuge zur Verfügung, und mit etwas Aufwand lässt sich pgBackRest mit jedem davon überwachen.

pgBackRest kann Informationen über das Repository im JSON-Format ausgeben. Dazu gehören eine Liste aller Backups jeder Stanza und Informationen zum WAL-Archiv.

In PostgreSQL

Mit dem PostgreSQL-Befehl COPY lassen sich pgBackRest-Informationen in eine Tabelle laden. Das folgende Beispiel kapselt diese Logik in einer Funktion, mit der Abfragen in Echtzeit durchgeführt werden können.

pg-primary ⇒ pgBackRest-Informationsfunktion für PostgreSQL laden

sudo -u postgres cat \
       /var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-info.sql
-- An example of monitoring pgBackRest from within PostgreSQL
--
-- Use copy to export data from the pgBackRest info command into the jsonb
-- type so it can be queried directly by PostgreSQL.

-- Create monitor schema
create schema monitor;

-- Get pgBackRest info in JSON format
create function monitor.pgbackrest_info()
    returns jsonb AS $$
declare
    data jsonb;
begin
    -- Create a temp table to hold the JSON data
    create temp table temp_pgbackrest_data (data text);

    -- Copy data into the table directly from the pgBackRest info command
    copy temp_pgbackrest_data (data)
        from program
            'pgbackrest --output=json info' (format text);

    select replace(temp_pgbackrest_data.data, E'\n', '\n')::jsonb
      into data
      from temp_pgbackrest_data;

    drop table temp_pgbackrest_data;

    return data;
end $$ language plpgsql;
sudo -u postgres psql -f \
       /var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-info.sql

Mit der Funktion monitor.pgbackrest_info() lassen sich nun der Zeitpunkt des letzten erfolgreichen Backups und das archivierte WAL einer Stanza ermitteln.

pg-primary ⇒ Zeitpunkt des letzten erfolgreichen Backups und archiviertes WAL abfragen

sudo -u postgres cat \
       /var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-query.sql
-- Get last successful backup for each stanza
--
-- Requires the monitor.pgbackrest_info function.
with stanza as
(
    select data->'name' as name,
           data->'backup'->(
               jsonb_array_length(data->'backup') - 1) as last_backup,
           data->'archive'->(
               jsonb_array_length(data->'archive') - 1) as current_archive
      from jsonb_array_elements(monitor.pgbackrest_info()) as data
)
select name,
       to_timestamp(
           (last_backup->'timestamp'->>'stop')::numeric) as last_successful_backup,
       current_archive->>'max' as last_archived_wal
  from stanza;
sudo -u postgres psql -f \
       /var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-query.sql
  name  | last_successful_backup |    last_archived_wal
--------+------------------------+--------------------------
 "demo" | 2026-10-02 19:06:28+00 | 000000010000000000000005
(1 row)

jq verwenden

jq ist ein Befehlszeilenwerkzeug, mit dem sich Daten einfach aus JSON extrahieren lassen.

pg-primary ⇒ Werkzeug jq installieren

sudo apt-get install jq

Mit jq lässt sich nun der Zeitpunkt des letzten erfolgreichen Backups einer Stanza abfragen.

pg-primary ⇒ Zeitpunkt des letzten erfolgreichen Backups abfragen

sudo -u postgres pgbackrest --output=json --stanza=demo info | \
       jq '.[0] | .backup[-1] | .timestamp.stop'
1790967988

Oder das zuletzt archivierte WAL.

pg-primary ⇒ Zuletzt archiviertes WAL abfragen

sudo -u postgres pgbackrest --output=json --stanza=demo info | \
       jq '.[0] | .archive[-1] | .max'
"000000010000000000000005"

HINWEIS:

Diese Syntax erfordert jq v1.5.

HINWEIS:

jq kann große Zahlen wie Systemkennungen runden. Die Abfragen sorgfältig testen.

Backup

Wenn mehrere Repositorys konfiguriert sind, erstellt pgBackRest das Backup im Repository mit der höchsten Priorität, beispielsweise repo1, sofern die Option --repo nicht angegeben ist.

pgBackRest hat keine integrierte Zeitplanung. Daher empfiehlt es sich, pgBackRest über cron oder einen anderen Mechanismus zur Zeitplanung auszuführen.

Weitere Einzelheiten und Beispiele stehen unter Backup durchführen .

Dateibündelung

Das Bündeln von Dateien im Repository spart Zeit beim Backup und etwas Speicherplatz im Repository. Besonders deutlich ist dies bei Repositorys auf Objektspeichern wie S3 oder auf Dateisystemen mit großen Blockgrößen. Auf Objektspeichern dauert das Erstellen einer einzelnen Datei länger, und die Speicherung sehr kleiner Dateien kann genauso viel kosten wie die größerer Dateien.

Die Dateibündelung wird mit der Option repo-bundle aktiviert.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-bundle konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

Ein vollständiges Backup ohne Dateibündelung enthält 1000+ Dateien im Backup-Pfad. Mit Bündelung wird die Gesamtzahl der Dateien erheblich reduziert. Außerdem werden leere Dateien nur im Manifest erfasst und ansonsten nicht gespeichert, während bei einem normalen Backup jede leere Datei einzeln gespeichert wird.

pg-primary ⇒ Vollständiges Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=full backup

pg-primary ⇒ Gesamtzahl der Dateien prüfen

sudo -u postgres find /var/lib/pgbackrest/backup/demo/latest/ -type f | wc -l
5

Zur Optimierung können die Optionen repo-bundle-size und repo-bundle-limit verwendet werden. Die Standardwerte sollten jedoch in den meisten Fällen optimal sein.

Dateibündelung ist im Allgemeinen effizienter, erschwert jedoch das manuelle Abrufen von Dateien aus dem Repository. Für deduplizierten Speicher ist sie möglicherweise nicht ideal, da jedes vollständige Backup die Dateien in den Bündeln anders anordnet. Bei Dateibündeln ist außerdem keine Fortsetzung nach einer Unterbrechung möglich. Daher sollte repo-bundle-limit nicht zu hoch eingestellt werden.

Inkrementelle Backups auf Blockebene

Inkrementelle Backups auf Blockebene sparen Speicherplatz, indem sie nur die seit dem vorherigen Backup geänderten Teile einer Datei statt der gesamten Datei speichern.

Die Funktion für inkrementelle Backups auf Blockebene wird mit der Option repo-block aktiviert und funktioniert am besten, wenn sie für alle Backup-Typen aktiviert ist. Auch die Dateibündelung muss aktiviert sein.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-block konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

Backup-Annotationen

Benutzer können einem Backup informative Schlüssel-Wert-Paare hinzufügen. Diese Option kann mehrfach verwendet werden, um mehrere Annotationen anzufügen.

pg-primary ⇒ Vollständiges Backup mit Annotationen durchführen

sudo -u postgres pgbackrest --stanza=demo --annotation=source="demo backup" \
       --annotation=key=value --type=full backup

Annotationen erscheinen in der Textausgabe des Befehls info, wenn mit --set ein Backup angegeben wird. In der JSON-Ausgabe erscheinen sie immer.

pg-primary ⇒ Informationen zum Demo-Cluster abrufen

sudo -u postgres pgbackrest --stanza=demo --set=20261002-190643F info
stanza: demo
    status: ok
    cipher: aes-256-cbc

    db (current)
        wal archive min/max (17): 000000020000000000000007/000000020000000000000009

        full backup: 20261002-190643F
            timestamp start/stop: 2026-10-02 19:06:43+00 / 2026-10-02 19:06:44+00
            wal start/stop: 000000020000000000000008 / 000000020000000000000009
            lsn start/stop: 0/8000028 / 0/9000050
            database size: 22MB, database backup size: 22MB
            repo1: backup size: 2.9MB
            database list: postgres (5)
            annotation(s)
                key: value
                source: demo backup

Annotationen, die mit dem Befehl backup hinzugefügt wurden, können anschließend mit dem Befehl annotate ergänzt, geändert oder entfernt werden.

pg-primary ⇒ Backup-Annotationen ändern

sudo -u postgres pgbackrest --stanza=demo --set=20261002-190643F \
       --annotation=key= --annotation=new_key=new_value annotate
sudo -u postgres pgbackrest --stanza=demo --set=20261002-190643F info
stanza: demo
    status: ok
    cipher: aes-256-cbc

    db (current)
        wal archive min/max (17): 000000020000000000000007/000000020000000000000009

        full backup: 20261002-190643F
            timestamp start/stop: 2026-10-02 19:06:43+00 / 2026-10-02 19:06:44+00
            wal start/stop: 000000020000000000000008 / 000000020000000000000009
            lsn start/stop: 0/8000028 / 0/9000050
            database size: 22MB, database backup size: 22MB
            repo1: backup size: 2.9MB
            database list: postgres (5)
            annotation(s)
                new_key: new_value
                source: demo backup

Aufbewahrung

Im Allgemeinen empfiehlt es sich, möglichst viele Backups aufzubewahren, um ein größeres Zeitfenster für die Point-in-Time-Recovery zu erhalten. Dabei müssen jedoch auch praktische Einschränkungen wie der verfügbare Speicherplatz berücksichtigt werden. Aufbewahrungsoptionen entfernen ältere Backups, sobald sie nicht mehr benötigt werden.

pgBackRest rotiert vollständige Backups anhand des Aufbewahrungstyps, der eine Anzahl oder einen Zeitraum festlegen kann. Bei einer Anzahl hängt das Entfernen nicht vom Erstellungszeitpunkt der Backups ab, sondern davon, wie viele aufbewahrt werden müssen. Differenzielle Backups werden nach Anzahl aufbewahrt, jedoch immer entfernt, wenn das vollständige Backup entfernt wird, von dem sie abhängen. Inkrementelle Backups werden durch die Aufbewahrungsregeln nie eigenständig entfernt, sondern immer zusammen mit dem zugehörigen vollständigen oder differenziellen Backup. Einzelheiten und Beispiele stehen unter Aufbewahrung vollständiger Backups und Aufbewahrung differenzieller Backups .

Archiviertes WAL wird standardmäßig für alle noch nicht entfernten Backups aufbewahrt. Diese Regel kann pro Repository mit den Optionen retention-archive geändert werden, was jedoch nicht empfohlen wird. Einzelheiten und Beispiele stehen unter Archivaufbewahrung .

Der Befehl expire wird nach jedem erfolgreichen Backup automatisch ausgeführt und kann auch vom Benutzer aufgerufen werden. Bei einem manuellen Aufruf erfolgt das Entfernen gemäß den Aufbewahrungseinstellungen jedes konfigurierten Repositorys. Wenn die Option --repo angegeben ist, wird nur das angegebene Repository bereinigt. Der Benutzer kann das Entfernen mit der Option --set auch auf einen bestimmten Backup-Satz beschränken. Sofern --repo nicht angegeben ist, werden alle Repositorys durchsucht und alle dem angegebenen Satz entsprechenden Backups entfernt. Die Regeln zur Archivaufbewahrung werden bei jedem Aufruf von expire geprüft und angewendet.

Aufbewahrung vollständiger Backups

repo1-retention-full-type bestimmt, ob die Option repo1-retention-full als Anzahl aufzubewahrender vollständiger Backups oder als Anzahl von Tagen ihrer Aufbewahrung interpretiert wird. Neue Backups müssen abgeschlossen sein, bevor Backups entfernt werden. Bei repo1-retention-full-type=count und repo1-retention-full=2 sind daher drei vollständige Backups gespeichert, bevor das älteste entfernt wird. Bei repo1-retention-full-type=time und repo1-retention-full=20 muss ein vollständiges Backup vorhanden sein, das mindestens 20 Tage alt ist, bevor Backups entfernt werden können.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-retention-full konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

Für Backups gilt repo1-retention-full=2. Derzeit gibt es jedoch nur ein vollständiges Backup, sodass beim nächsten vollständigen Backup noch keines entfernt wird.

pg-primary ⇒ Vollständiges Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=full \
       --log-level-console=detail backup
       [filtered 975 lines of output]
P00   INFO: repo1: remove expired backup 20261002-190641F
P00 DETAIL: repo1: 17-1 archive retention on backup 20261002-190643F, start = 000000020000000000000008
P00   INFO: repo1: 17-1 remove archive, start = 000000020000000000000007, stop = 000000020000000000000007
P00   INFO: expire command end: completed successfully

Archivdaten werden hingegen entfernt, da WAL-Segmente vor dem ältesten Backup erzeugt wurden. Diese sind für eine Recovery nicht nutzbar. Nur WAL-Segmente, die nach einem Backup erzeugt wurden, können für dessen Recovery verwendet werden.

pg-primary ⇒ Vollständiges Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=full \
       --log-level-console=info backup
       [filtered 11 lines of output]
P00   INFO: repo1: expire full backup 20261002-190643F
P00   INFO: repo1: remove expired backup 20261002-190643F
P00   INFO: repo1: 17-1 remove archive, start = 000000020000000000000008, stop = 00000002000000000000000A
P00   INFO: expire command end: completed successfully

Das vollständige Backup 20261002-190624F wird entfernt. Die Archivaufbewahrung richtet sich nun nach 20261002-190646F, dem jetzt ältesten vollständigen Backup.

Aufbewahrung differenzieller Backups

repo1-retention-diff auf die benötigte Anzahl differenzieller Backups setzen. Differenzielle Backups hängen nur vom vorherigen vollständigen Backup ab. Daher lässt sich ein fortlaufend erneuerter Satz differenzieller Backups für den letzten Tag oder länger erstellen. Dies ermöglicht schnelle Wiederherstellungen auf kürzlich vergangene Zeitpunkte und verringert gleichzeitig den gesamten Speicherbedarf.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-retention-diff konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=1

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

Für Backups gilt repo1-retention-diff=1, sodass zwei differenzielle Backups durchgeführt werden müssen, bevor eines entfernt wird. Zusätzlich wird ein inkrementelles Backup erstellt, um dessen Entfernung zu demonstrieren. Diese hängt hier von der Entfernung des differenziellen Backups ab.

pg-primary ⇒ Differenzielle und inkrementelle Backups durchführen

sudo -u postgres pgbackrest --stanza=demo --type=diff backup
sudo -u postgres pgbackrest --stanza=demo --type=incr backup

Ein weiteres differenzielles Backup entfernt nun das vorherige differenzielle und das inkrementelle Backup, sodass nur ein differenzielles Backup übrig bleibt.

pg-primary ⇒ Differenzielles Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=diff \
       --log-level-console=info backup
       [filtered 10 lines of output]
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=956-fb652d58 --log-level-console=info --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-diff=1 --repo1-retention-full=2 --stanza=demo
P00   INFO: repo1: expire diff backup set 20261002-190648F_20261002-190650D, 20261002-190648F_20261002-190651I
P00   INFO: repo1: remove expired backup 20261002-190648F_20261002-190651I
P00   INFO: repo1: remove expired backup 20261002-190648F_20261002-190650D
P00   INFO: expire command end: completed successfully

Archivaufbewahrung

pgBackRest entfernt archivierte WAL-Segmente automatisch beim Entfernen von Backups. Standardmäßig wird WAL für vollständige Backups anhand der Option repo1-retention-full entfernt. Um Speicherplatz zu sparen, kann es dennoch sinnvoll sein, Archivdaten früher zu entfernen. Für die differenzielle Archivaufbewahrung werden vollständige Backups wie differenzielle Backups behandelt.

Beim Entfernen von Archivdaten werden niemals WAL-Segmente entfernt, die für die Konsistenz eines Backups erforderlich sind. Point-in-Time-Recovery (PITR) funktioniert jedoch nur mit einem lückenlosen WAL-Strom. Daher ist Vorsicht geboten, wenn Archivdaten außerhalb der normalen Backup-Bereinigung besonders früh entfernt werden. Um zu ermitteln, was entfernt würde, ohne tatsächlich etwas zu entfernen, kann dem Befehl expire auf der Befehlszeile die Option dry-run übergeben werden.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-retention-diff konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=2

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

pg-primary ⇒ Differenzielles Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=diff \
       --log-level-console=info backup
       [filtered 6 lines of output]
P00   INFO: backup stop archive = 000000020000000000000017, lsn = 0/17000050
P00   INFO: check archive for segment(s) 000000020000000000000016:000000020000000000000017
P00   INFO: new backup label = 20261002-190648F_20261002-190654D
P00   INFO: diff backup size = 8.3KB, file total = 963
P00   INFO: backup command end: completed successfully
       [filtered 2 lines of output]

pg-primary ⇒ Archiv bereinigen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=detail \
       --repo1-retention-archive-type=diff --repo1-retention-archive=1 expire
P00   INFO: expire command begin 2.59.3: --exec-id=1037-f7b8ca1a --log-level-console=detail --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-archive=1 --repo1-retention-archive-type=diff --repo1-retention-diff=2 --repo1-retention-full=2 --stanza=demo
P00 DETAIL: repo1: 17-1 archive retention on backup 20261002-190646F, start = 00000002000000000000000B, stop = 00000002000000000000000B
P00 DETAIL: repo1: 17-1 archive retention on backup 20261002-190648F, start = 00000002000000000000000C, stop = 00000002000000000000000D
P00 DETAIL: repo1: 17-1 archive retention on backup 20261002-190648F_20261002-190652D, start = 000000020000000000000012, stop = 000000020000000000000013
P00 DETAIL: repo1: 17-1 archive retention on backup 20261002-190648F_20261002-190654D, start = 000000020000000000000016
P00   INFO: repo1: 17-1 remove archive, start = 00000002000000000000000E, stop = 000000020000000000000011
P00   INFO: repo1: 17-1 remove archive, start = 000000020000000000000014, stop = 000000020000000000000015
P00   INFO: expire command end: completed successfully

Zum differenziellen Backup 20261002-190648F_20261002-190652D gehören archivierte WAL-Segmente, die aufbewahrt werden müssen, um die älteren Backups konsistent zu machen, auch wenn diese mit PITR nicht weiter vorwärts abgespielt werden können. WAL-Segmente, die nach 20261002-190648F_20261002-190652D, aber vor 20261002-190648F_20261002-190654D erzeugt wurden, werden entfernt. WAL-Segmente nach dem neuen Backup 20261002-190648F_20261002-190654D bleiben erhalten und können für PITR verwendet werden.

Da vollständige Backups für die differenzielle Archivaufbewahrung als differenzielle Backups gelten, bleibt bei einem nun mit denselben Einstellungen durchgeführten vollständigen Backup nur dessen Archiv für PITR erhalten.

Wiederherstellung

Der Befehl restore wählt standardmäßig automatisch das neueste Backup aus dem ersten Repository aus, in dem Backups vorhanden sind; siehe Schnellstart – Backup wiederherstellen . Die Prüfreihenfolge der Repositorys wird durch pgbackrest.conf bestimmt; beispielsweise wird repo1 vor repo2 geprüft. Mit der Option --repo, etwa --repo=1, lässt sich ein bestimmtes Repository auswählen. Wenn ein anderes als das neueste Backup gewünscht ist, kann die Option --set angegeben werden.

Bei PITR mit --type=time oder --type=lsn muss die Zielzeit bzw. die Ziel-LSN mit der Option --target angegeben werden. Ohne --set werden die konfigurierten Repositorys der Reihe nach nach einem Backup durchsucht, dessen Endzeit vor der Zielzeit liegt bzw. dessen End-LSN kleiner oder gleich der Ziel-LSN ist. Wird kein passendes Backup gefunden, meldet pgBackRest sowohl bei --type=time als auch bei --type=lsn einen Fehler; es fällt nicht auf das neueste Backup zurück. Bei anderen PITR-Typen, z. B. xid, muss die Option --set angegeben werden, wenn das Ziel vor dem neuesten Backup liegt. Weitere Informationen und Beispiele finden Sie unter Point-in-Time-Recovery .

Replikations-Slots werden gemäß der Empfehlung von PostgreSQL nicht eingeschlossen. Weitere Informationen stehen unter Backup des Datenverzeichnisses in der PostgreSQL-Dokumentation.

Die folgenden Abschnitte stellen weitere Funktionen des Befehls restore vor.

Dateieigentümer

Wird restore unter einem anderen Benutzer als root ausgeführt, was der übliche Fall ist, gehören alle wiederhergestellten Dateien dem Benutzer und der Gruppe, unter denen pgBackRest ausgeführt wird. Gehören vorhandene Dateien einem anderen Benutzer oder einer anderen Gruppe, tritt ein Fehler auf, wenn der Eigentümer nicht auf den ausführenden Benutzer beziehungsweise die ausführende Gruppe geändert werden kann. In diesem Fall muss ein privilegierter Benutzer die Dateieigentümer anpassen, bevor die Wiederherstellung erneut versucht werden kann.

Wird restore als Benutzer root ausgeführt, versucht pgBackRest, die beim Backup im Manifest gespeicherten Eigentümer wiederherzustellen. Das Manifest speichert nur die Namen von Benutzern und Gruppen. Damit dies funktioniert, müssen auf dem Wiederherstellungshost dieselben Namen existieren. Wird ein Benutzer- oder Gruppenname lokal nicht gefunden, wird der Benutzer beziehungsweise die Gruppe des PostgreSQL-Datenverzeichnisses verwendet. Lässt sich auch dessen Benutzer oder Gruppe keinem Namen zuordnen, wird letztlich root verwendet.

Delta-Option

Unter Backup wiederherstellen im Schnellstart musste das Datenbankcluster-Verzeichnis vor der Ausführung von restore geleert werden. Mit der Option delta ermittelt pgBackRest automatisch, welche Dateien in diesem Verzeichnis erhalten bleiben können und welche aus dem Backup wiederhergestellt werden müssen. Außerdem entfernt es Dateien, die nicht im Backup-Manifest stehen, und beseitigt so abweichende Änderungen. Dazu wird für jede Datei im Datenbankcluster-Verzeichnis ein kryptografischer SHA-1 -Hash berechnet. Stimmt der SHA-1-Hash nicht mit dem im Backup gespeicherten Hash überein, wird die Datei wiederhergestellt. In Verbindung mit der Option process-max ist dieses Verfahren sehr effizient. Da der PostgreSQL-Server während der Wiederherstellung gestoppt ist, können mehr Prozesse verwendet werden als während eines Backups bei laufendem PostgreSQL-Server sinnvoll wären.

pg-primary ⇒ Demo-Cluster stoppen und Delta-Wiederherstellung durchführen

sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza=demo --delta \
       --log-level-console=detail restore
       [filtered 2 lines of output]
P00 DETAIL: check '/var/lib/postgresql/17/demo' exists
P00 DETAIL: remove 'global/pg_control' so cluster will not start if restore does not complete
P00   INFO: remove invalid files/links/paths from '/var/lib/postgresql/17/demo'
P00 DETAIL: remove invalid file '/var/lib/postgresql/17/demo/backup_label.old'
P00 DETAIL: remove invalid file '/var/lib/postgresql/17/demo/base/1/pg_internal.init'
       [filtered 769 lines of output]
P01 DETAIL: restore file /var/lib/postgresql/17/demo/base/1/113 - exists and matches backup (bundle 20261002-190648F/1/2665832, 8KB, 88.00%) checksum 1cd643347b87a472ff001ae124e4b532ce998d2f
P01 DETAIL: restore file /var/lib/postgresql/17/demo/base/1/112 - exists and matches backup (bundle 20261002-190648F/1/2665920, 8KB, 88.03%) checksum 2cbd5cf8fb22ef627eb539776c5ec7457bdb2890
P01 DETAIL: restore file /var/lib/postgresql/17/demo/PG_VERSION - exists and matches backup (bundle 20261002-190648F/1/2666008, 3B, 88.03%) checksum ad48103e4fc71796e9708cafc43adeed0d1076b7
P01 DETAIL: restore file /var/lib/postgresql/17/demo/base/5/2608_fsm - exists and matches backup (bundle 20261002-190648F/1/2666032, 24KB, 88.14%) checksum e807fe622bbfccc5e9ad7f453ecb4f0eaccb75e2
P01 DETAIL: restore file /var/lib/postgresql/17/demo/postgresql.auto.conf - exists and matches backup (bundle 20261002-190648F/1/2666272, 229B, 88.14%) checksum e1b0002d9a33d70466c5a348f4e0c1f1f80639f6
       [filtered 233 lines of output]

pg-primary ⇒ PostgreSQL neu starten

sudo pg_ctlcluster 17 demo start

Ausgewählte Datenbanken wiederherstellen

In manchen Fällen sollen gezielt einzelne Datenbanken aus einem Cluster-Backup wiederhergestellt werden. Gründe dafür können die Leistung sein oder der Wunsch, ausgewählte Datenbanken auf einen Rechner zu verschieben, dessen Speicherplatz für die Wiederherstellung des gesamten Cluster-Backups nicht ausreicht.

Zur Demonstration werden zwei Datenbanken erstellt: test1 und test2.

pg-primary ⇒ Zwei Testdatenbanken erstellen

sudo -u postgres psql -c "create database test1;"
CREATE DATABASE
sudo -u postgres psql -c "create database test2;"
CREATE DATABASE

Jede Testdatenbank wird mit Tabellen und Daten gefüllt, um zu zeigen, dass die Recovery bei einer selektiven Wiederherstellung funktioniert.

pg-primary ⇒ In jeder Datenbank eine Testtabelle erstellen

sudo -u postgres psql -c "create table test1_table (id int); \
       insert into test1_table (id) values (1);" test1
CREATE TABLE
INSERT 0 1
sudo -u postgres psql -c "create table test2_table (id int); \
       insert into test2_table (id) values (2);" test2
CREATE TABLE
INSERT 0 1

Ein neues Backup wird durchgeführt, damit pgBackRest die neuen Datenbanken kennt.

pg-primary ⇒ Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=incr backup

Ein wesentlicher Grund für die selektive Wiederherstellung ist die Einsparung von Speicherplatz. Hier wird die Größe der Datenbank test1 angezeigt, um sie nach der selektiven Wiederherstellung mit deren Speicherbelegung vergleichen zu können.

pg-primary ⇒ Speicherbelegung der Datenbank test1 anzeigen

sudo -u postgres du -sh /var/lib/postgresql/17/demo/base/32768
7.4M	/var/lib/postgresql/17/demo/base/32768

Ist die wiederherzustellende Datenbank nicht bekannt, lassen sich mit der Option set des Befehls info die im Backup-Satz enthaltenen Datenbanken ermitteln.

pg-primary ⇒ Datenbankliste des Backups anzeigen

sudo -u postgres pgbackrest --stanza=demo \
       --set=20261002-190648F_20261002-190702I info
       [filtered 12 lines of output]
            repo1: backup size: 1.9MB
            backup reference list: 20261002-190648F, 20261002-190648F_20261002-190654D
            database list: postgres (5), test1 (32768), test2 (32769)

Den Cluster stoppen und nur die Datenbank test2 wiederherstellen. Die eingebauten Datenbanken template0, template1 und postgres werden immer wiederhergestellt.

WARNUNG:

Ohne --type=immediate kann die Recovery mit einem Fehler abbrechen. Sobald Konsistenz erreicht ist, meldet PostgreSQL mit Nullen gefüllte Seiten als Fehler, auch bei einem Schreibvorgang für eine vollständige Seite. Für PostgreSQL ≥ 13 kann die Einstellung ignore_invalid_pages verwendet werden, um ungültige Seiten zu ignorieren. In diesem Fall ist es wichtig, die Protokolle nach der Recovery zu prüfen, um sicherzustellen, dass in den ausgewählten Datenbanken keine ungültigen Seiten gemeldet wurden.

pg-primary ⇒ Aus dem letzten Backup nur die Datenbank test2 wiederherstellen

sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza=demo --delta \
       --db-include=test2 --type=immediate --target-action=promote restore
sudo pg_ctlcluster 17 demo start

Nach Abschluss der Recovery enthält die Datenbank test2 alle zuvor erstellten Tabellen und Daten.

pg-primary ⇒ Erfolgreiche Recovery der Datenbank test2 zeigen

sudo -u postgres psql -c "select * from test2_table;" test2
 id
----
  2
(1 row)

Trotz erfolgreicher Recovery ist die Datenbank test1 nicht zugänglich. Sie wurde vollständig als mit Nullen gefüllte Sparse-Dateien wiederhergestellt. PostgreSQL kann WAL erfolgreich auf diese Dateien anwenden. Die Datenbank als Ganzes ist jedoch ungültig, da wichtige Dateien keine Daten enthalten. Dies ist beabsichtigt: Es verhindert die versehentliche Verwendung einer Datenbank, die möglicherweise nur unvollständige, während der WAL-Wiedergabe angewendete Daten enthält.

pg-primary ⇒ Verbindungsversuch mit der Datenbank test1 führt zu einem Fehler

sudo -u postgres psql -c "select * from test1_table;" test1
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  relation mapping file "base/32768/pg_filenode.map" contains invalid data

Da die Datenbank test1 als mit Nullen gefüllte Sparse-Dateien wiederhergestellt wird, benötigt sie nur so viel Speicherplatz wie die während der Recovery geschriebene WAL-Menge. Die während eines Backups erzeugte und bei der Recovery angewendete WAL-Menge kann beträchtlich sein, macht aber in der Regel nur einen kleinen Teil der gesamten Datenbankgröße aus. Das gilt insbesondere für große Datenbanken, bei denen diese Funktion am ehesten nützlich ist.

Die Datenbank test1 belegt bei der selektiven Wiederherstellung deutlich weniger Speicherplatz, als sie bei einer vollständigen Wiederherstellung benötigt hätte.

pg-primary ⇒ Speicherbelegung der Datenbank test1 nach der Recovery anzeigen

sudo -u postgres du -sh /var/lib/postgresql/17/demo/base/32768
8.0K	/var/lib/postgresql/17/demo/base/32768

Die einzige mögliche Aktion für die ungültige Datenbank test1 ist nun drop database. pgBackRest löscht die Datenbank nicht automatisch, da dies erst nach Abschluss der Recovery und bei zugänglichem Cluster möglich ist.

pg-primary ⇒ Datenbank test1 löschen

sudo -u postgres psql -c "drop database test1;"
DROP DATABASE

Nach dem Löschen der ungültigen Datenbank test1 bleiben nur test2 und die eingebauten Datenbanken übrig.

pg-primary ⇒ Verbleibende Datenbanken auflisten

sudo -u postgres psql -c "select oid, datname from pg_database order by oid;"
  oid  |  datname
-------+-----------
     1 | template1
     4 | template0
     5 | postgres
 32769 | test2
(4 rows)

Point-in-Time-Recovery

Unter Backup wiederherstellen im Schnellstart wurde die standardmäßige Recovery durchgeführt, die den WAL-Strom bis zu seinem Ende wiedergibt. Bei einem Hardwareausfall ist dies normalerweise die beste Wahl. Bei Datenbeschädigungen, ob durch technische Fehler oder menschliches Handeln verursacht, ist dagegen häufig eine Point-in-Time-Recovery (PITR) geeigneter.

Point-in-Time-Recovery (PITR) ermöglicht es, das WAL ausgehend von einem Backup bis zu einer bestimmten LSN, einem Zeitpunkt, einer Transaktions-ID oder einem Recovery-Punkt wiederzugeben. Für übliche Recovery-Szenarien ist die zeitbasierte Recovery wohl am nützlichsten. Ein typischer Fall ist die Wiederherstellung einer versehentlich gelöschten Tabelle oder versehentlich gelöschter Daten. Da die Recovery einer gelöschten Tabelle anschaulicher ist, wird sie hier als Beispiel verwendet. Gelöschte Daten würden jedoch genauso wiederhergestellt.

pg-primary ⇒ Tabelle mit sehr wichtigen Daten erstellen

sudo -u postgres psql -c "begin; \
       create table important_table (message text); \
       insert into important_table values ('Important Data'); \
       commit; \
       select * from important_table;"
       [filtered 4 lines of output]
    message
----------------
 Important Data
(1 row)

Es ist wichtig, die Zeit so anzugeben, wie PostgreSQL sie erfasst, und den Zeitzonenversatz einzubeziehen. Das verringert das Risiko unbeabsichtigter Zeitzonenumrechnungen und eines unerwarteten Recovery-Ergebnisses.

pg-primary ⇒ Zeit von PostgreSQL abrufen

sudo -u postgres psql -Atc "select current_timestamp"
2026-10-02 19:07:12.060959+00

Nachdem der Zeitpunkt festgehalten wurde, wird die Tabelle gelöscht. In der Praxis ist es wesentlich schwieriger als in diesem Beispiel, den genauen Zeitpunkt der Löschung zu ermitteln. Er lässt sich möglicherweise nicht exakt feststellen, doch eine Untersuchung der verfügbaren Spuren sollte eine gute Annäherung ermöglichen.

pg-primary ⇒ Wichtige Tabelle löschen

sudo -u postgres psql -c "begin; \
       drop table important_table; \
       commit; \
       select * from important_table;"
BEGIN
DROP TABLE
COMMITERROR:  relation "important_table" does not exist
LINE 1: ...le important_table;     commit;     select * from important_...
                                                             ^

Wird für die Wiederherstellung das falsche Backup gewählt, schlägt die Recovery bis zur gewünschten Zielzeit fehl. Zur Demonstration wird ein neues inkrementelles Backup durchgeführt, in dem important_table nicht existiert.

pg-primary ⇒ Inkrementelles Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=incr backup
sudo -u postgres pgbackrest info
       [filtered 38 lines of output]
            backup reference total: 1 full, 1 diff

        incr backup: 20261002-190648F_20261002-190713I
            timestamp start/stop: 2026-10-02 19:07:13+00 / 2026-10-02 19:07:14+00
            wal start/stop: 00000004000000000000001A / 00000004000000000000001A
       [filtered 2 lines of output]

Aus diesem Backup lässt sich die verlorene Tabelle nicht wiederherstellen, da PostgreSQL nur vorwärts und nicht rückwärts wiedergeben kann.

pg-primary ⇒ Recovery aus einem ungeeigneten Backup versuchen

sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza=demo --delta \
       --set=20261002-190648F_20261002-190713I --target-timeline=current \
       --type=time "--target=2026-10-02 19:07:12.060959+00" --target-action=promote restore
sudo pg_ctlcluster 17 demo start
       [filtered 13 lines of output]
LOG:  database system is ready to accept read-only connections
LOG:  redo done at 0/1A000120 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.03 s
FATAL:  recovery ended before configured recovery target was reached
LOG:  startup process (PID 1437) exited with exit code 1
LOG:  terminating any other active server processes
       [filtered 3 lines of output]

Zuverlässig ist es, pgBackRest automatisch ein Backup auswählen zu lassen, das eine Recovery bis zur Zielzeit ermöglicht, also ein Backup, das vor dem angegebenen Zeitpunkt endete.

HINWEIS:

Beim Wiederherstellungstyp xid oder name kann pgBackRest das Backup nicht automatisch auswählen.

pg-primary ⇒ Demo-Cluster auf 2026-10-02 19:07:12.060959+00 wiederherstellen

sudo -u postgres pgbackrest --stanza=demo --delta \
       --type=time "--target=2026-10-02 19:07:12.060959+00" \
       --target-action=promote restore
sudo -u postgres cat /var/lib/postgresql/17/demo/postgresql.auto.conf
       [filtered 9 lines of output]
# Recovery settings generated by pgBackRest restore on 2026-10-02 19:07:16
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
recovery_target_time = '2026-10-02 19:07:12.060959+00'
recovery_target_action = 'promote'

pgBackRest hat die Recovery-Einstellungen in postgresql.auto.conf geschrieben, sodass PostgreSQL sofort gestartet werden kann. Mit %f gibt PostgreSQL das benötigte WAL-Segment an, mit %p den Speicherort, an den es kopiert werden soll. Sobald PostgreSQL die Recovery abgeschlossen hat, existiert die Tabelle wieder und kann abgefragt werden.

pg-primary ⇒ PostgreSQL starten und prüfen, ob die wichtige Tabelle existiert

sudo pg_ctlcluster 17 demo start
sudo -u postgres psql -c "select * from important_table"
    message
----------------
 Important Data
(1 row)

Auch das PostgreSQL-Protokoll enthält wertvolle Informationen. Es nennt den Zeitpunkt und die Transaktion, bei der die Recovery gestoppt wurde, sowie den Zeitpunkt der zuletzt angewendeten Transaktion.

pg-primary ⇒ PostgreSQL-Protokollausgabe untersuchen

sudo -u postgres cat /var/log/postgresql/postgresql-17-demo.log
       [filtered 7 lines of output]
LOG:  restored log file "00000004.history" from archive
LOG:  restored log file "000000040000000000000019" from archive
LOG:  starting point-in-time recovery to 2026-10-02 19:07:12.060959+00
LOG:  restored log file "00000003.history" from archive
LOG:  redo starts at 0/19000028
       [filtered 2 lines of output]
LOG:  database system is ready to accept read-only connections
LOG:  restored log file "00000004000000000000001A" from archive
LOG:  recovery stopping before commit of transaction 748, time 2026-10-02 19:07:13.389359+00
LOG:  redo done at 0/1901CC00 system usage: CPU: user: 0.00 s, system: 0.01 s, elapsed: 0.07 s
LOG:  last completed transaction was at log time 2026-10-02 19:07:10.778316+00
LOG:  restored log file "000000040000000000000019" from archive
LOG:  selected new timeline ID: 5
       [filtered 5 lines of output]

Stanza löschen

Der Befehl stanza-delete entfernt die zu einer Stanza gehörenden Daten aus dem Repository.

WARNUNG:

Diesen Befehl mit Vorsicht verwenden: Er entfernt dauerhaft alle Backups und Archive der angegebenen Stanza aus dem pgBackRest-Repository.

Zum Löschen einer Stanza:

  • Den PostgreSQL-Cluster stoppen, der zur Stanza gehört, oder diese Vorgabe mit –force übergehen.
  • Den Befehl stop auf dem Host ausführen, auf dem stanza-delete ausgeführt werden soll.
  • Den Befehl stanza-delete ausführen.

Nach dem erfolgreichen Abschluss des Befehls ist der Benutzer dafür verantwortlich, die Stanza aus allen pgBackRest-Konfigurationsdateien und/oder Umgebungsvariablen zu entfernen.

Eine Stanza kann jeweils nur aus einem Repository gelöscht werden. Zum Löschen aus mehreren Repositorys den Befehl stanza-delete für jedes Repository wiederholen und dabei die Option --repo angeben.

pg-primary ⇒ Zu entfernenden PostgreSQL-Cluster stoppen

sudo pg_ctlcluster 17 demo stop

pg-primary ⇒ pgBackRest für die Stanza stoppen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stop
P00   INFO: stop command begin 2.59.3: --exec-id=1568-4c984637 --log-level-console=info --no-log-timestamp --stanza=demo
P00   INFO: stop command end: completed successfully

pg-primary ⇒ Stanza aus einem Repository löschen

sudo -u postgres pgbackrest --stanza=demo --repo=1 \
       --log-level-console=info stanza-delete
P00   INFO: stanza-delete command begin 2.59.3: --exec-id=1576-48368d9e --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo=1 --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo
P00   INFO: stanza-delete command end: completed successfully

Mehrere Repositorys

Es können mehrere Repositorys konfiguriert werden, wie unter S3-Unterstützung gezeigt. Ein möglicher Vorteil ist die Kombination eines lokalen Repositorys für schnelle Wiederherstellungen mit einem entfernten Repository für Redundanz.

Einige Befehle, etwa stanza-create /stanza-upgrade , arbeiten automatisch mit allen konfigurierten Repositorys. Andere, etwa stanza-delete , erfordern die Angabe eines Repositorys über die Option repo.

Ist nur repo1 konfiguriert, wird die Option repo zur Wahrung der Abwärtskompatibilität nicht benötigt. Ist dagegen ein einzelnes Repository beispielsweise als repo2 konfiguriert, ist die Option repo erforderlich. Dadurch wird verhindert, dass Befehle nicht mehr funktionieren, wenn später ein weiteres Repository hinzukommt.

Der Befehl archive-push überträgt WAL immer in das Archiv aller konfigurierten Repositorys. Ist ein Repository nicht erreichbar, wird WAL weiterhin an die anderen Repositorys übertragen. Damit dies wirksam funktioniert, muss jedoch archive-async=y aktiviert sein; andernfalls können die anderen Repositorys dem nicht erreichbaren Repository nur um ein WAL-Segment voraus sein. Kann WAL in keines der Repositorys übertragen werden, entfernt PostgreSQL es nicht aus dem Verzeichnis pg_wal. Dadurch kann der Speicherplatz des Volumes erschöpft werden.

Backups müssen für jedes Repository einzeln geplant werden. Häufig ist das erwünscht, da sich Backup-Typen und Aufbewahrung je nach Repository unterscheiden. Ebenso muss bei Wiederherstellungen ein Repository angegeben werden. Im Allgemeinen empfiehlt sich dafür ein Repository mit geringer Latenz und niedrigen Kosten, auch wenn die Recovery dadurch länger dauert. Welches Repository am effizientesten ist, lässt sich nur durch Wiederherstellungstests ermitteln.

Unterstützung für Azure-kompatible Objektspeicher

pgBackRest unterstützt Repositorys in Azure-kompatiblen Objektspeichern. Der Container für das Repository muss vorab erstellt werden; pgBackRest legt ihn nicht automatisch an. Das Repository kann im Stammverzeichnis des Containers (/) liegen. Meist empfiehlt sich jedoch ein Unterpfad, damit Objektspeicherprotokolle oder andere Daten ohne Konflikte im selben Container gespeichert werden können.

WARNUNG:

„Hierarchischer Namespace“ nicht aktivieren, da dies bei expire zu Fehlern führt.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Azure konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=2

repo1-retention-full=2

repo2-azure-account=pgbackrest

repo2-azure-container=demo-container

repo2-azure-key=YXpLZXk=

repo2-path=/demo-repo

repo2-retention-full=4

repo2-type=azure

start-fast=y



[global:archive-push]

compress-level=3

Shared Access Signatures können verwendet werden, indem die Option repo2-azure-key-type auf sas und repo2-azure-key auf das Shared-Access-Signature-Token gesetzt wird.

Die Befehle werden genauso ausgeführt, als läge das Repository auf einem lokalen Datenträger.

pg-primary ⇒ Stanza erstellen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create
P00   INFO: stanza-create command begin 2.59.3: --exec-id=1657-1f40c982 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo2-type=azure --stanza=demo
P00   INFO: stanza-create for stanza 'demo' on repo1
P00   INFO: stanza-create for stanza 'demo' on repo2
P00   INFO: stanza-create command end: completed successfully

Da das Erstellen von Dateien in Azure relativ langsam ist, verbessert die Aktivierung der Dateibündelung die Leistung von backup/restore.

pg-primary ⇒ Backup des Demo-Clusters erstellen

sudo -u postgres pgbackrest --stanza=demo --repo=2 \
       --log-level-console=info backup
P00   INFO: backup command begin 2.59.3: --exec-id=1666-1ab08562 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo=2 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-block --repo1-bundle --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo2-type=azure --stanza=demo --start-fast
P00   WARN: no prior backup exists, incr backup has been changed to full
P00   INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 00000005000000000000001B, lsn = 0/1B000028
       [filtered 3 lines of output]
P00   INFO: check archive for segment(s) 00000005000000000000001B:00000005000000000000001B
P00   INFO: new backup label = 20261002-190727F
P00   INFO: full backup size = 29.2MB, file total = 1265
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=1666-1ab08562 --log-level-console=info --no-log-timestamp --repo=2 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo2-type=azure --stanza=demo

Unterstützung für S3-kompatible Objektspeicher

pgBackRest unterstützt Repositorys in S3-kompatiblen Objektspeichern. Der Bucket für das Repository muss vorab erstellt werden; pgBackRest legt ihn nicht automatisch an. Das Repository kann im Stammverzeichnis des Buckets (/) liegen. Meist empfiehlt sich jedoch ein Unterpfad, damit Objektspeicherprotokolle oder andere Daten ohne Konflikte im selben Bucket gespeichert werden können.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ S3 konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=2

repo1-retention-full=2

repo2-azure-account=pgbackrest

repo2-azure-container=demo-container

repo2-azure-key=YXpLZXk=

repo2-path=/demo-repo

repo2-retention-full=4

repo2-type=azure

repo3-path=/demo-repo

repo3-retention-full=4

repo3-s3-bucket=demo-bucket

repo3-s3-endpoint=s3.us-east-1.amazonaws.com

repo3-s3-key=accessKey1

repo3-s3-key-secret=verySecretKey1

repo3-s3-region=us-east-1

repo3-type=s3

start-fast=y



[global:archive-push]

compress-level=3

HINWEIS:

Region und Endpunkt müssen entsprechend dem Standort des Buckets konfiguriert werden. Die hier angegebenen Werte gelten für die Region us-east-1.

Für die Ausführung von pgBackRest sollte eine Rolle erstellt werden, und die Bucket-Berechtigungen sollten möglichst restriktiv gesetzt werden. Ist die Rolle einer AWS-Instanz zugeordnet, ruft pgBackRest bei repo3-s3-key-type=auto automatisch temporäre Zugangsdaten ab. Schlüssel müssen dann nicht ausdrücklich in /etc/pgbackrest/pgbackrest.conf angegeben werden.

Diese Amazon-S3-Beispielrichtlinie beschränkt alle Lese- und Schreibzugriffe auf den Bucket und den Repository-Pfad.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::demo-bucket"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:prefix": [
                        "",
                        "demo-repo"
                    ],
                    "s3:delimiter": [
                        "/"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::demo-bucket"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "demo-repo/*"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:PutObjectTagging",
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::demo-bucket/demo-repo/*"
            ]
        }
    ]
}

Die Befehle werden genauso ausgeführt, als läge das Repository auf einem lokalen Datenträger.

pg-primary ⇒ Stanza erstellen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create
       [filtered 4 lines of output]
P00   INFO: stanza 'demo' already exists on repo2 and is valid
P00   INFO: stanza-create for stanza 'demo' on repo3
P00   INFO: stanza-create command end: completed successfully

Da das Erstellen von Dateien in S3 relativ langsam ist, verbessert die Aktivierung der Dateibündelung die Leistung von backup/restore.

pg-primary ⇒ Backup des Demo-Clusters erstellen

sudo -u postgres pgbackrest --stanza=demo --repo=3 \
       --log-level-console=info backup
P00   INFO: backup command begin 2.59.3: --exec-id=1767-6031c435 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo=3 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-block --repo1-bundle --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo2-type=azure --repo3-type=s3 --stanza=demo --start-fast
P00   WARN: no prior backup exists, incr backup has been changed to full
P00   INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 00000005000000000000001D, lsn = 0/1D000028
       [filtered 3 lines of output]
P00   INFO: check archive for segment(s) 00000005000000000000001D:00000005000000000000001D
P00   INFO: new backup label = 20261002-190741F
P00   INFO: full backup size = 29.2MB, file total = 1265
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=1767-6031c435 --log-level-console=info --no-log-timestamp --repo=3 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo2-type=azure --repo3-type=s3 --stanza=demo

SFTP-Unterstützung

pgBackRest unterstützt Repositorys auf SFTP-Hosts. SFTP-Dateiübertragungen sind relativ langsam. Daher profitieren Befehle von einer Erhöhung von process-max, um die Dateiübertragungen zu parallelisieren.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ SFTP konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

process-max=4

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=2

repo1-retention-full=2

repo2-azure-account=pgbackrest

repo2-azure-container=demo-container

repo2-azure-key=YXpLZXk=

repo2-path=/demo-repo

repo2-retention-full=4

repo2-type=azure

repo3-path=/demo-repo

repo3-retention-full=4

repo3-s3-bucket=demo-bucket

repo3-s3-endpoint=s3.us-east-1.amazonaws.com

repo3-s3-key=accessKey1

repo3-s3-key-secret=verySecretKey1

repo3-s3-region=us-east-1

repo3-type=s3

repo4-bundle=y

repo4-path=/demo-repo

repo4-sftp-host=sftp-server

repo4-sftp-host-key-hash-type=sha1

repo4-sftp-host-user=pgbackrest

repo4-sftp-private-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp

repo4-sftp-public-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp.pub

repo4-type=sftp

start-fast=y



[global:archive-push]

compress-level=3

Bei der Verwendung von SFTP ist repo4-sftp-public-key-file optional, wenn libssh2 gegen OpenSSH kompiliert wurde.

pg-primary ⇒ SSH-Schlüsselpaar für SFTP-Backups erzeugen

sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh
sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa_sftp \
       -t rsa -b 4096 -N "" -m PEM

sftp-server ⇒ Öffentlichen SFTP-Backup-Schlüssel von pg-primary nach sftp-server kopieren

sudo -u pgbackrest mkdir -m 750 -p /home/pgbackrest/.ssh
(sudo ssh root@pg-primary cat /var/lib/postgresql/.ssh/id_rsa_sftp.pub) | \
       sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys

Die Befehle werden genauso ausgeführt, als läge das Repository auf einem lokalen Datenträger.

pg-primary ⇒ Fingerprint von sftp-server zur Datei known_hosts hinzufügen, da repo4-sftp-host-key-check-type standardmäßig “strict” verwendet

ssh-keyscan -H sftp-server >> /var/lib/postgresql/.ssh/known_hosts 2>/dev/null

pg-primary ⇒ Stanza erstellen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create
       [filtered 6 lines of output]
P00   INFO: stanza 'demo' already exists on repo3 and is valid
P00   INFO: stanza-create for stanza 'demo' on repo4
P00   INFO: stanza-create command end: completed successfully

pg-primary ⇒ Backup des Demo-Clusters erstellen

sudo -u postgres pgbackrest --stanza=demo --repo=4 \
       --log-level-console=info backup
P00   INFO: backup command begin 2.59.3: --exec-id=1859-efaa8e87 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=4 --repo=4 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-block --repo1-bundle --repo4-bundle --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo4-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo4-sftp-host=sftp-server --repo4-sftp-host-key-hash-type=sha1 --repo4-sftp-host-user=pgbackrest --repo4-sftp-private-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp --repo4-sftp-public-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp.pub --repo2-type=azure --repo3-type=s3 --repo4-type=sftp --stanza=demo --start-fast
P00   WARN: option 'repo4-retention-full' is not set for 'repo4-retention-full-type=count', the repository may run out of space
            HINT: to retain full backups indefinitely (without warning), set option 'repo4-retention-full' to the maximum.
P00   WARN: no prior backup exists, incr backup has been changed to full
P00   INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 00000005000000000000001E, lsn = 0/1E000028
       [filtered 3 lines of output]
P00   INFO: check archive for segment(s) 00000005000000000000001E:00000005000000000000001F
P00   INFO: new backup label = 20261002-190759F
P00   INFO: full backup size = 29.2MB, file total = 1265
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=1859-efaa8e87 --log-level-console=info --no-log-timestamp --repo=4 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo4-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo4-sftp-host=sftp-server --repo4-sftp-host-key-hash-type=sha1 --repo4-sftp-host-user=pgbackrest --repo4-sftp-private-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp --repo4-sftp-public-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp.pub --repo2-type=azure --repo3-type=s3 --repo4-type=sftp --stanza=demo
P00   INFO: expire command end: completed successfully

Unterstützung für GCS-kompatible Objektspeicher

pgBackRest unterstützt Repositorys in GCS-kompatiblen Objektspeichern. Der Bucket für das Repository muss vorab erstellt werden; pgBackRest legt ihn nicht automatisch an. Das Repository kann im Stammverzeichnis des Buckets (/) liegen. Meist empfiehlt sich jedoch ein Unterpfad, damit Objektspeicherprotokolle oder andere Daten ohne Konflikte im selben Bucket gespeichert werden können.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ GCS konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

process-max=4

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=2

repo1-retention-full=2

repo2-azure-account=pgbackrest

repo2-azure-container=demo-container

repo2-azure-key=YXpLZXk=

repo2-path=/demo-repo

repo2-retention-full=4

repo2-type=azure

repo3-path=/demo-repo

repo3-retention-full=4

repo3-s3-bucket=demo-bucket

repo3-s3-endpoint=s3.us-east-1.amazonaws.com

repo3-s3-key=accessKey1

repo3-s3-key-secret=verySecretKey1

repo3-s3-region=us-east-1

repo3-type=s3

repo4-bundle=y

repo4-path=/demo-repo

repo4-sftp-host=sftp-server

repo4-sftp-host-key-hash-type=sha1

repo4-sftp-host-user=pgbackrest

repo4-sftp-private-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp

repo4-sftp-public-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp.pub

repo4-type=sftp

repo5-gcs-bucket=demo-bucket

repo5-gcs-key=/etc/pgbackrest/gcs-key.json

repo5-path=/demo-repo

repo5-type=gcs

start-fast=y



[global:archive-push]

compress-level=3

Bei der Ausführung in GCE repo5-gcs-key-type=auto setzen, um sich automatisch über das Dienstkonto der Instanz zu authentifizieren.

Die Befehle werden genauso ausgeführt, als läge das Repository auf einem lokalen Datenträger.

Da das Erstellen von Dateien in GCS relativ langsam ist, verbessert die Aktivierung der Dateibündelung die Leistung von backup/restore.

Zielzeit für ein Repository

Die Zielzeit legt den Zeitpunkt fest, auf dessen Stand Befehle ein Repository auf versioniertem Speicher lesen. So kann ein Befehl das Repository in seinem damaligen Zustand lesen, um Daten wiederherzustellen, die durch ein Benutzerversehen oder Schadsoftware gelöscht oder beschädigt wurden.

Versionierter Speicher wird von S3, GCS und Azure unterstützt, ist jedoch im Allgemeinen nicht standardmäßig aktiviert. Zusätzlich zur Versionierung kann es sinnvoll sein, für S3 die Objektsperre und für GCS oder Azure das vorläufige Löschen (Soft Delete) zu aktivieren.

Wenn die Option repo-target-time angegeben wird, muss auch die Option repo angegeben werden. Voraussichtlich werden nicht alle Repository-Typen Versionierung unterstützen. Außerdem ist es im Allgemeinen sinnvoll, für die Recovery gezielt ein einzelnes Repository auszuwählen.

Der Speicherzeitstempel wird darauf geprüft, ob er <= dem angegebenen Zeitstempel ist. Enthält der angegebene Zeitstempel Millisekunden, werden sie abgeschnitten.

Zur Demonstration dieser Funktion wird die Stanza demo im S3-Repository gelöscht.

pg-primary ⇒ Stanza im S3-Repository löschen

sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza=demo stop
sudo -u postgres pgbackrest --stanza=demo --repo=3 stanza-delete

Nach dem Löschen der Stanza zeigt der Befehl info das Repository in einem Fehlerzustand an.

pg-primary ⇒ Fehler bei info

sudo -u postgres pgbackrest --stanza=demo --repo=3 info
stanza: demo
    status: error (missing stanza path)

Da der Speicher versioniert ist, lässt sich das Repository jedoch zu einem Zeitpunkt vor dem Löschen der Stanza betrachten. Je nach Situation kann es schwierig sein, die Zielzeit zu ermitteln. Hier lässt sich der Löschzeitpunkt der Stanza anhand des Löschzeitpunkts von backup.info bestimmen.

pg-primary ⇒ Versionen von backup.info im Bucket auflisten

key=demo-repo/backup/demo/backup.info; \
       aws s3api list-object-versions --bucket demo-bucket \
       --prefix $key --output table \
       --query "sort_by([Versions[?Key=='$key'].{Action:'PUT', \
       Modified:LastModified,Object:Key}, \
       DeleteMarkers[?Key=='$key'].{Action:'DELETE', \
       Modified:LastModified,Object:Key}][],&Modified)"
-----------------------------------------------------------------------------
|                            ListObjectVersions                             |
+--------+----------------------------+-------------------------------------+
| Action |         Modified           |               Object                |
+--------+----------------------------+-------------------------------------+
|  PUT   |  2026-10-02T19:07:41.474Z  |  demo-repo/backup/demo/backup.info  |
|  PUT   |  2026-10-02T19:07:56.815Z  |  demo-repo/backup/demo/backup.info  |
|  DELETE|  2026-10-02T19:08:04.878Z  |  demo-repo/backup/demo/backup.info  |
+--------+----------------------------+-------------------------------------+

Der Befehl info kann nun mit einer Zielzeit ausgeführt werden, die das Repository vor dem Löschen zeigt.

pg-primary ⇒ Info mit Zielzeit

sudo -u postgres pgbackrest --stanza=demo --repo=3 \
       --repo-target-time="2026-10-02 19:07:57+00" info
       [filtered 5 lines of output]
        wal archive min/max (17): 00000005000000000000001C/00000005000000000000001D

        full backup: 20261002-190741F
            timestamp start/stop: 2026-10-02 19:07:41+00 / 2026-10-02 19:07:56+00
            wal start/stop: 00000005000000000000001D / 00000005000000000000001D
            repo3: backup set size: 3.8MB, backup size: 3.8MB

Wenn der Befehl info das benötigte Backup anzeigt, kann es mit derselben Zielzeit wiederhergestellt werden.

pg-primary ⇒ Wiederherstellung mit Zielzeit

sudo -u postgres pgbackrest --stanza=demo --repo=3 --delta \
       --repo-target-time="2026-10-02 19:07:57+00" --log-level-console=info restore
P00   INFO: restore command begin 2.59.3: --delta --exec-id=1953-a0a01a5a --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=4 --repo=3 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo5-gcs-bucket=demo-bucket --repo5-gcs-key=<redacted> --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo4-path=/demo-repo --repo5-path=/demo-repo --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo4-sftp-host=sftp-server --repo4-sftp-host-key-hash-type=sha1 --repo4-sftp-host-user=pgbackrest --repo4-sftp-private-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp --repo4-sftp-public-key-file=/var/lib/postgresql/.ssh/id_rsa_sftp.pub --repo-target-time="2026-10-02 19:07:57+00" --repo2-type=azure --repo3-type=s3 --repo4-type=sftp --repo5-type=gcs --stanza=demo
P00   INFO: repo3: restore backup set 20261002-190741F, recovery will start at 2026-10-02 19:07:41
P00   INFO: remove invalid files/links/paths from '/var/lib/postgresql/17/demo'
P00   INFO: write updated /var/lib/postgresql/17/demo/postgresql.auto.conf
       [filtered 2 lines of output]
sudo pg_ctlcluster 17 demo start

Dedizierter Repository-Host

Die unter Schnellstart beschriebene Konfiguration eignet sich für einfache Installationen. In Unternehmensumgebungen ist dagegen ein dedizierter Repository-Host üblich, auf dem Backups und WAL-Archivdateien gespeichert werden. Dadurch sind Backups und WAL-Archiv vom Datenbankserver getrennt, sodass Ausfälle des Datenbankhosts geringere Auswirkungen haben. Zusätzlich empfiehlt es sich weiterhin, den Repository-Host mit herkömmlicher Backup-Software zu sichern.

Auf PostgreSQL-Hosts muss pg1-path auf den lokalen PostgreSQL-Cluster verweisen, und pg1-host sollte nicht konfiguriert sein. Auf einem Repository-Host muss in der pgBackRest-Konfigurationsdatei die Option pg-host für die Verbindung zum Primärserver und zu gegebenenfalls vorhandenen Standby-Hosts konfiguriert sein. Nur die pgBackRest-Konfiguration des Repository-Hosts sollte mehr als einen PostgreSQL-Host kennen. Die Reihenfolge spielt keine Rolle: Beispielsweise können pg1-path/pg1-host und pg2-path/pg2-host jeweils Primärserver oder Standby bezeichnen.

Installation

Ein neuer Host namens repository wird zum Speichern der Cluster-Backups eingerichtet.

HINWEIS:

Die auf dem Repository-Host installierte pgBackRest-Version muss exakt mit der Version auf dem PostgreSQL-Host übereinstimmen.

Der Benutzer pgbackrest wird als Eigentümer des pgBackRest-Repositorys angelegt. Jeder Benutzer kann Eigentümer des Repositorys sein. Zur Vermeidung von Verwechslungen empfiehlt es sich jedoch, nicht den Benutzer postgres zu verwenden, falls dieser existiert.

HINWEIS:

Bei der Installation von pgBackRest aus einem Paket wird möglicherweise eine logrotate-Konfiguration wie /etc/logrotate.d/pgbackrest bereitgestellt, die die Protokolle über die Direktive su unter einem bestimmten Benutzer rotiert, beispielsweise su postgres postgres. Da die Dateien in /var/log/pgbackrest dem Benutzer gehören, der pgBackRest ausführt, hier pgbackrest, muss die Direktive su auf diesen Benutzer angepasst werden. Andernfalls schlägt logrotate mit einem Berechtigungsfehler fehl.

repository ⇒ Benutzer pgbackrest erstellen

sudo adduser --disabled-password --gecos "" pgbackrest

Die Installation von pgBackRest aus einem Paket ist der Kompilierung aus dem Quellcode vorzuziehen. Bei einer Paketinstallation sind die übrigen Anweisungen in diesem Abschnitt normalerweise nicht erforderlich. Es kann jedoch vorkommen, dass ein Paket eines der Verzeichnisse nicht anlegt oder falsche Berechtigungen vergibt. In diesem Fall kann es erforderlich sein, Verzeichnisse manuell anzulegen oder Berechtigungen anzupassen.

Debian/Ubuntu-Pakete für pgBackRest sind unter apt.postgresql.org verfügbar.

Falls für Ihre Distribution oder Version keine Pakete bereitstehen, können Sie pgBackRest aus dem Quellcode kompilieren und anschließend wie hier gezeigt manuell installieren.

repository ⇒ Abhängigkeiten installieren

sudo apt-get install postgresql-client libxml2 libssh2-1

repository ⇒ pgBackRest-Binärdatei vom Build-Host kopieren

sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest

pgBackRest benötigt Protokoll- und Konfigurationsverzeichnisse sowie eine Konfigurationsdatei.

repository ⇒ pgBackRest-Konfigurationsdatei und Verzeichnisse erstellen

sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown pgbackrest:pgbackrest /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown pgbackrest:pgbackrest /etc/pgbackrest/pgbackrest.conf

repository ⇒ pgBackRest-Repository erstellen

sudo mkdir -p /var/lib/pgbackrest
sudo chmod 750 /var/lib/pgbackrest
sudo chown pgbackrest:pgbackrest /var/lib/pgbackrest

Passwortloses SSH einrichten

pgBackRest kann für die Kommunikation zwischen Hosts passwortloses SSH verwenden. Alternativ ist TLS möglich; siehe TLS einrichten .

repository ⇒ Schlüsselpaar für den Host repository erstellen

sudo -u pgbackrest mkdir -m 750 /home/pgbackrest/.ssh
sudo -u pgbackrest ssh-keygen -f /home/pgbackrest/.ssh/id_rsa \
       -t rsa -b 4096 -N ""

pg-primary ⇒ Schlüsselpaar für den Host pg-primary erstellen

sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh
sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa \
       -t rsa -b 4096 -N ""

Schlüssel zwischen repository und pg-primary austauschen.

repository ⇒ Öffentlichen Schlüssel von pg-primary nach repository kopieren

(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
       echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
       sudo ssh root@pg-primary cat /var/lib/postgresql/.ssh/id_rsa.pub) | \
       sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys

pg-primary ⇒ Öffentlichen Schlüssel von repository nach pg-primary kopieren

(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
       echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
       sudo ssh root@repository cat /home/pgbackrest/.ssh/id_rsa.pub) | \
       sudo -u postgres tee -a /var/lib/postgresql/.ssh/authorized_keys

Prüfen, ob Verbindungen von repository nach pg-primary und in umgekehrter Richtung möglich sind.

repository ⇒ Verbindung von repository nach pg-primary testen

sudo -u pgbackrest ssh postgres@pg-primary

pg-primary ⇒ Verbindung von pg-primary nach repository testen

sudo -u postgres ssh pgbackrest@repository

HINWEIS:

ssh wurde so konfiguriert, dass über passwortloses ssh ausschließlich pgBackRest ausgeführt werden kann. Dies erhöht die Sicherheit, falls eines der Dienstkonten kompromittiert wird.

Konfiguration

Auf dem Repository-Host müssen Hostname und Benutzer von pg-primary sowie der Datenbankpfad konfiguriert werden. Der Primärserver wird als pg1 konfiguriert, damit später ein Standby hinzugefügt werden kann.

repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-host/pg1-host-user und pg1-path konfigurieren

[demo]

pg1-host=pg-primary

pg1-path=/var/lib/postgresql/17/demo



[global]

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

Auf dem Datenbankhost müssen Hostname und Benutzer des Repository-Hosts konfiguriert werden. Der Standardwert der Option repo1-host-user ist pgbackrest. Wenn der Benutzer postgres auf dem Repository-Host Wiederherstellungen durchführt, empfiehlt es sich, dem Benutzer postgres nicht zusätzlich die Durchführung von Backups zu erlauben. Der Benutzer postgres kann das Repository jedoch direkt lesen, wenn er derselben Gruppe wie pgbackrest angehört.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-host/repo1-host-user konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

log-level-file=detail

repo1-host=repository

Die PostgreSQL-Konfiguration ist im Abschnitt Archivierung konfigurieren beschrieben.

Die Befehle werden genauso ausgeführt wie bei einer Konfiguration mit einem einzelnen Host. Einige Befehle, etwa backup und expire, laufen jedoch auf dem Repository-Host statt auf dem Datenbankhost.

Stanza erstellen und prüfen

Die Stanza im neuen Repository erstellen.

repository ⇒ Stanza erstellen

sudo -u pgbackrest pgbackrest --stanza=demo stanza-create

Die Konfiguration sowohl auf dem Datenbankhost als auch auf dem Repository-Host prüfen. Weitere Informationen zum Befehl check stehen unter Konfiguration prüfen .

pg-primary ⇒ Konfiguration prüfen

sudo -u postgres pgbackrest --stanza=demo check

repository ⇒ Konfiguration prüfen

sudo -u pgbackrest pgbackrest --stanza=demo check

Backup durchführen

Für ein Backup des PostgreSQL-Clusters pgBackRest mit dem Befehl backup auf dem Repository-Host ausführen.

repository ⇒ Backup des Demo-Clusters erstellen

sudo -u pgbackrest pgbackrest --stanza=demo backup
P00   WARN: no prior backup exists, incr backup has been changed to full

Da auf dem Repository-Host ein neues Repository erstellt wurde, erschien die Warnung, dass das inkrementelle Backup in ein vollständiges Backup umgewandelt wurde.

Backup wiederherstellen

Zur Wiederherstellung des PostgreSQL-Clusters pgBackRest mit dem Befehl restore auf dem Datenbankhost ausführen.

pg-primary ⇒ Demo-Cluster stoppen, wiederherstellen und PostgreSQL neu starten

sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza=demo --delta restore
sudo pg_ctlcluster 17 demo start

Paralleles Backup / parallele Wiederherstellung

pgBackRest bietet parallele Verarbeitung, um die Leistung von Komprimierung und Übertragung zu verbessern. Die Anzahl der dafür verwendeten Prozesse wird mit der Option --process-max festgelegt.

Für den Befehl backup empfiehlt es sich normalerweise, höchstens 25% der verfügbaren CPUs zu verwenden. Backups müssen nicht besonders schnell laufen, solange sie regelmäßig durchgeführt werden. Der Backup-Prozess sollte die Datenbankleistung möglichst nicht beeinträchtigen.

Der Befehl restore kann und sollte alle verfügbaren CPUs verwenden, da der PostgreSQL-Cluster während einer Wiederherstellung gestoppt ist und auf dem Host normalerweise keine anderen wichtigen Arbeiten stattfinden. Enthält der Host mehrere Cluster, sollte dies bei der Festlegung der Parallelität der Wiederherstellung berücksichtigt werden.

repository ⇒ Backup mit einem einzelnen Prozess durchführen

sudo -u pgbackrest pgbackrest --stanza=demo --type=full backup

repository:/etc/pgbackrest/pgbackrest.conf ⇒ pgBackRest für mehrere backup-Prozesse konfigurieren

[demo]

pg1-host=pg-primary

pg1-path=/var/lib/postgresql/17/demo



[global]

process-max=3

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

repository ⇒ Backup mit mehreren Prozessen durchführen

sudo -u pgbackrest pgbackrest --stanza=demo --type=full backup

repository ⇒ Backup-Informationen zum Demo-Cluster abrufen

sudo -u pgbackrest pgbackrest info
stanza: demo
    status: ok
    cipher: none

    db (current)
        wal archive min/max (17): 000000070000000000000023/000000070000000000000025

        full backup: 20261002-190844F
            timestamp start/stop: 2026-10-02 19:08:44+00 / 2026-10-02 19:08:48+00
            wal start/stop: 000000070000000000000023 / 000000070000000000000023
            database size: 29.2MB, database backup size: 29.2MB
            repo1: backup set size: 3.8MB, backup size: 3.8MB

        full backup: 20261002-190850F
            timestamp start/stop: 2026-10-02 19:08:50+00 / 2026-10-02 19:08:52+00
            wal start/stop: 000000070000000000000024 / 000000070000000000000025
            database size: 29.2MB, database backup size: 29.2MB
            repo1: backup set size: 3.8MB, backup size: 3.8MB

Durch die Verwendung mehrerer Prozesse sollte das letzte Backup schneller sein. Bei sehr kleinen Backups ist der Unterschied möglicherweise kaum erkennbar. Mit zunehmender Datenbankgröße steigt jedoch auch die Zeitersparnis.

Starten und Stoppen

Wird ein Standby zu Testzwecken hochgestuft oder ein Testcluster aus einem Produktionsbackup wiederhergestellt, empfiehlt es sich, Schreibzugriffe dieser Cluster auf pgBackRest-Repositorys zu verhindern. Dies ist mit dem Befehl stop möglich.

Die schreibenden Befehle, die stop blockiert, sind archive-push, backup, expire, stanza-create und stanza-upgrade. stanza-delete ist eine Ausnahme von dieser Regel; weitere Einzelheiten stehen unter Stanza löschen .

pg-primary ⇒ Schreibende pgBackRest-Befehle stoppen

sudo -u postgres pgbackrest stop

Neue schreibende pgBackRest-Befehle werden nicht mehr ausgeführt.

repository ⇒ Backup versuchen

sudo -u pgbackrest pgbackrest --stanza=demo backup
P00   WARN: unable to check pg1: [StopError] raised from remote-0 ssh protocol on 'pg-primary': stop file exists for all stanzas
P00  ERROR: [056]: unable to find primary cluster - cannot proceed
            HINT: are all available clusters in recovery?

Mit der Option --force werden bereits laufende schreibende pgBackRest-Befehle beendet. Das schließt asynchrones archive-get ein, das jedoch erneut läuft, wenn PostgreSQL es benötigt. Ist pgBackRest bereits gestoppt, erzeugt ein erneutes Stoppen eine Warnung.

pg-primary ⇒ pgBackRest-Dienste erneut stoppen

sudo -u postgres pgbackrest stop
P00   WARN: stop file already exists for all stanzas

Mit dem Befehl start werden schreibende pgBackRest-Befehle wieder zugelassen. Schreibende Befehle, die vor dem Stoppen liefen, starten nicht automatisch erneut; sie dürfen jetzt jedoch wieder gestartet werden.

pg-primary ⇒ Schreibende pgBackRest-Befehle starten

sudo -u postgres pgbackrest start

pgBackRest kann auch für eine einzelne Stanza gestoppt werden.

pg-primary ⇒ Schreibende pgBackRest-Befehle für die Stanza demo stoppen

sudo -u postgres pgbackrest --stanza=demo stop

Neue schreibende pgBackRest-Befehle für die angegebene Stanza werden nicht mehr ausgeführt.

repository ⇒ Backup versuchen

sudo -u pgbackrest pgbackrest --stanza=demo backup
P00   WARN: unable to check pg1: [StopError] raised from remote-0 ssh protocol on 'pg-primary': stop file exists for stanza demo
P00  ERROR: [056]: unable to find primary cluster - cannot proceed
            HINT: are all available clusters in recovery?

Auch beim Starten schreibender pgBackRest-Befehle für eine einzelne Stanza muss diese angegeben werden.

pg-primary ⇒ Schreibende pgBackRest-Befehle für die Stanza demo starten

sudo -u postgres pgbackrest --stanza=demo start

Replikation

Durch Replikation lassen sich mehrere Kopien eines PostgreSQL-Clusters, sogenannte Standbys, von einem einzigen Primärserver erstellen. Standbys dienen zur Verteilung von Lesezugriffen und bieten Redundanz, falls der primäre Host ausfällt.

Installation

Ein neuer Host namens pg-standby wird für den Betrieb des Standbys eingerichtet.

Die Installation von pgBackRest aus einem Paket ist der Kompilierung aus dem Quellcode vorzuziehen. Bei einer Paketinstallation sind die übrigen Anweisungen in diesem Abschnitt normalerweise nicht erforderlich. Es kann jedoch vorkommen, dass ein Paket eines der Verzeichnisse nicht anlegt oder falsche Berechtigungen vergibt. In diesem Fall kann es erforderlich sein, Verzeichnisse manuell anzulegen oder Berechtigungen anzupassen.

Debian/Ubuntu-Pakete für pgBackRest sind unter apt.postgresql.org verfügbar.

Falls für Ihre Distribution oder Version keine Pakete bereitstehen, können Sie pgBackRest aus dem Quellcode kompilieren und anschließend wie hier gezeigt manuell installieren.

pg-standby ⇒ Abhängigkeiten installieren

sudo apt-get install postgresql-client libxml2 libssh2-1

pg-standby ⇒ pgBackRest-Binärdatei vom Build-Host kopieren

sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest

pgBackRest benötigt Protokoll- und Konfigurationsverzeichnisse sowie eine Konfigurationsdatei.

pg-standby ⇒ pgBackRest-Konfigurationsdatei und Verzeichnisse erstellen

sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf

Passwortloses SSH einrichten

pgBackRest kann für die Kommunikation zwischen Hosts passwortloses SSH verwenden. Alternativ ist TLS möglich; siehe TLS einrichten .

pg-standby ⇒ Schlüsselpaar für den Host pg-standby erstellen

sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh
sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa \
       -t rsa -b 4096 -N ""

Schlüssel zwischen repository und pg-standby austauschen.

repository ⇒ Öffentlichen Schlüssel von pg-standby nach repository kopieren

(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
       echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
       sudo ssh root@pg-standby cat /var/lib/postgresql/.ssh/id_rsa.pub) | \
       sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys

pg-standby ⇒ Öffentlichen Schlüssel von repository nach pg-standby kopieren

(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
       echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
       sudo ssh root@repository cat /home/pgbackrest/.ssh/id_rsa.pub) | \
       sudo -u postgres tee -a /var/lib/postgresql/.ssh/authorized_keys

Prüfen, ob Verbindungen von repository nach pg-standby und in umgekehrter Richtung möglich sind.

repository ⇒ Verbindung von repository nach pg-standby testen

sudo -u pgbackrest ssh postgres@pg-standby

pg-standby ⇒ Verbindung von pg-standby nach repository testen

sudo -u postgres ssh pgbackrest@repository

Hot Standby

Ein Hot Standby repliziert über das WAL-Archiv und erlaubt schreibgeschützte Abfragen.

Die pgBackRest-Konfiguration ist der von pg-primary sehr ähnlich. Es wird jedoch der Recovery-Typ standby verwendet, damit der Cluster nach Erreichen des Endes des WAL-Stroms im Recovery-Modus bleibt.

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ pgBackRest auf dem Standby konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

log-level-file=detail

repo1-host=repository

Der Demo-Cluster muss erstellt werden, damit die PostgreSQL-Konfigurationsdateien angelegt werden, auch wenn er bei der Wiederherstellung überschrieben wird.

pg-standby ⇒ Demo-Cluster erstellen

sudo pg_createcluster 17 demo

Nun kann der Standby mit dem Befehl restore erstellt werden.

WICHTIG:

Soll der Cluster hochgestuft werden, ohne zum neuen Primärserver zu werden, beispielsweise für Berichte oder Tests, die Archivierung mit --archive-mode=off oder archive_mode=off in postgresql.conf deaktivieren. Andernfalls kann WAL im Repository landen, das Wiederherstellungen erschwert.

pg-standby ⇒ Demo-Standby-Cluster wiederherstellen

sudo -u postgres pgbackrest --stanza=demo --delta --type=standby restore
sudo -u postgres cat /var/lib/postgresql/17/demo/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:06:30
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:06:56
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:07:16
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Removed by pgBackRest restore on 2026-10-02 19:08:10 # recovery_target_time = '2026-10-02 19:07:12.060959+00'
# Removed by pgBackRest restore on 2026-10-02 19:08:10 # recovery_target_action = 'promote'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:08:10
restore_command = 'pgbackrest --repo=3 --repo-target-time="2026-10-02 19:07:57+00" --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:08:37
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:09:08
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

Diese Konfiguration gilt für den Fall, dass der Standby zum Primärserver hochgestuft wird.

pg-standby:/etc/postgresql/17/demo/postgresql.conf ⇒ PostgreSQL konfigurieren

archive_command = 'pgbackrest --stanza=demo archive-push %p'

archive_mode = on

pg-standby ⇒ PostgreSQL starten

sudo pg_ctlcluster 17 demo start

Das PostgreSQL-Protokoll liefert wertvolle Informationen zur Recovery. Besonders zu beachten ist, dass der Cluster in den Standby-Modus gewechselt ist und schreibgeschützte Verbindungen annehmen kann.

pg-standby ⇒ PostgreSQL-Protokollausgabe auf Erfolgsmeldungen prüfen

sudo -u postgres cat /var/log/postgresql/postgresql-17-demo.log
       [filtered 6 lines of output]
LOG:  restored log file "00000007.history" from archive
LOG:  restored log file "000000070000000000000024" from archive
LOG:  entering standby mode
LOG:  redo starts at 0/24000028
LOG:  restored log file "000000070000000000000025" from archive
       [filtered 3 lines of output]

Eine einfache Prüfung der Replikationskonfiguration besteht darin, auf pg-primary eine Tabelle zu erstellen.

pg-primary ⇒ Neue Tabelle auf dem Primärserver erstellen

sudo -u postgres psql -c " \
       begin; \
       create table replicated_table (message text); \
       insert into replicated_table values ('Important Data'); \
       commit; \
       select * from replicated_table";
       [filtered 4 lines of output]
    message
----------------
 Important Data
(1 row)

Anschließend dieselbe Tabelle auf pg-standby abfragen.

pg-standby ⇒ Neue Tabelle auf dem Standby abfragen

sudo -u postgres psql -c "select * from replicated_table;"
ERROR:  relation "replicated_table" does not exist
LINE 1: select * from replicated_table;
                      ^

Was ist schiefgegangen? Da PostgreSQL WAL-Segmente für die Replikation aus dem Archiv abruft, werden Änderungen auf dem Standby erst sichtbar, wenn pg-primary das WAL-Segment mit diesen Änderungen in das Archiv übertragen hat.

Dies lässt sich manuell durch einen Aufruf von pg_switch_wal() auslösen. Dadurch wird das aktuelle WAL-Segment ins Archiv übertragen und ein neues WAL-Segment für weitere Änderungen erstellt.

pg-primary ⇒ pg_switch_wal() aufrufen

sudo -u postgres psql -c "select *, current_timestamp from pg_switch_wal()";
 pg_switch_wal |       current_timestamp
---------------+-------------------------------
 0/26019600    | 2026-10-02 19:09:16.993398+00
(1 row)

Nach einer kurzen Verzögerung erscheint die Tabelle nun auf pg-standby.

pg-standby ⇒ Die neue Tabelle existiert jetzt auf dem Standby; möglicherweise sind einige Versuche nötig

sudo -u postgres psql -c " \
       select *, current_timestamp from replicated_table"
    message     |       current_timestamp
----------------+-------------------------------
 Important Data | 2026-10-02 19:09:22.793715+00
(1 row)

Die Standby-Konfiguration auf Zugriff zum Repository prüfen.

pg-standby ⇒ Konfiguration prüfen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info check
P00   INFO: check command begin 2.59.3: --exec-id=654-6b53cbe6 --log-level-console=info --log-level-file=detail --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-host=repository --stanza=demo
P00   INFO: check repo1 (standby)
P00   INFO: switch wal not performed because this is a standby
P00   INFO: check command end: completed successfully

Streaming-Replikation

Streaming-Replikation verlässt sich nicht allein auf das WAL-Archiv, sondern stellt eine direkte Verbindung zum Primärserver her und wendet Änderungen an, sobald sie dort vorgenommen werden. Dadurch ist die Verzögerung zwischen Primärserver und Standby deutlich geringer.

Streaming-Replikation erfordert einen Benutzer mit Replikationsberechtigung.

pg-primary ⇒ Replikationsbenutzer erstellen

sudo -u postgres psql -c " \
       create user replicator password 'jw8s0F4' replication";
CREATE ROLE

Die Datei pg_hba.conf muss angepasst werden, damit der Standby eine Verbindung als Replikationsbenutzer herstellen darf. Die folgende IP-Adresse durch die tatsächliche IP-Adresse von pg-standby ersetzen. Nach der Änderung von pg_hba.conf muss die Konfiguration neu geladen werden.

pg-primary ⇒ Eintrag in pg_hba.conf für den Replikationsbenutzer erstellen

sudo -u postgres sh -c 'echo \
       "host    replication     replicator      172.17.0.8/32           md5" \
       >> /etc/postgresql/17/demo/pg_hba.conf'
sudo pg_ctlcluster 17 demo reload

Der Standby muss wissen, wie er den Primärserver erreicht. Daher wird die Einstellung primary_conninfo in pgBackRest konfiguriert.

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ primary_conninfo setzen

[demo]

pg1-path=/var/lib/postgresql/17/demo

recovery-option=primary_conninfo=host=172.17.0.6 port=5432 user=replicator



[global]

log-level-file=detail

repo1-host=repository

Ein Passwort kann in der Einstellung primary_conninfo angegeben werden. Eine Datei .pgpass ist jedoch flexibler und sicherer.

pg-standby ⇒ Replikationspasswort in der Datei .pgpass konfigurieren.

sudo -u postgres sh -c 'echo \
       "172.17.0.6:*:replication:replicator:jw8s0F4" \
       >> /var/lib/postgresql/.pgpass'
sudo -u postgres chmod 600 /var/lib/postgresql/.pgpass

Nun kann der Standby mit dem Befehl restore erstellt werden.

pg-standby ⇒ PostgreSQL stoppen und Demo-Standby-Cluster wiederherstellen

sudo pg_ctlcluster 17 demo stop
sudo -u postgres pgbackrest --stanza=demo --delta --type=standby restore
sudo -u postgres cat /var/lib/postgresql/17/demo/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:06:30
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:06:56
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:07:16
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Removed by pgBackRest restore on 2026-10-02 19:08:10 # recovery_target_time = '2026-10-02 19:07:12.060959+00'
# Removed by pgBackRest restore on 2026-10-02 19:08:10 # recovery_target_action = 'promote'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:08:10
restore_command = 'pgbackrest --repo=3 --repo-target-time="2026-10-02 19:07:57+00" --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:08:37
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:09:25
primary_conninfo = 'host=172.17.0.6 port=5432 user=replicator'
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

HINWEIS:

Die Einstellung primary_conninfo wurde in die Datei postgresql.auto.conf geschrieben, da sie als recovery-option in pgbackrest.conf konfiguriert war. Falls gewünscht, kann mit restore die Option --type=preserve verwendet werden, um die vorhandene Datei postgresql.auto.conf beizubehalten.

pg-standby ⇒ PostgreSQL starten

sudo pg_ctlcluster 17 demo start

Das PostgreSQL-Protokoll bestätigt den Start der Streaming-Replikation.

pg-standby ⇒ PostgreSQL-Protokollausgabe auf Erfolgsmeldungen prüfen

sudo -u postgres cat /var/log/postgresql/postgresql-17-demo.log
       [filtered 13 lines of output]
LOG:  consistent recovery state reached at 0/25000050
LOG:  database system is ready to accept read-only connections
LOG:  started streaming WAL from primary at 0/27000000 on timeline 7

Wenn nun auf pg-primary eine Tabelle erstellt wird, erscheint sie schnell auf pg-standby, ohne dass pg_switch_wal() aufgerufen werden muss.

pg-primary ⇒ Neue Tabelle auf dem Primärserver erstellen

sudo -u postgres psql -c " \
       begin; \
       create table stream_table (message text); \
       insert into stream_table values ('Important Data'); \
       commit; \
       select *, current_timestamp from stream_table";
       [filtered 4 lines of output]
    message     |       current_timestamp
----------------+-------------------------------
 Important Data | 2026-10-02 19:09:32.302145+00
(1 row)

pg-standby ⇒ Tabelle auf dem Standby abfragen

sudo -u postgres psql -c " \
       select *, current_timestamp from stream_table"
    message     |       current_timestamp
----------------+-------------------------------
 Important Data | 2026-10-02 19:09:32.491307+00
(1 row)

Mehrere Stanzas

pgBackRest unterstützt mehrere Stanzas. Am häufigsten wird dabei ein Repository-Host von mehreren Stanzas gemeinsam genutzt.

Installation

Ein neuer Host namens pg-alt wird für den Betrieb des neuen Primärservers eingerichtet.

Die Installation von pgBackRest aus einem Paket ist der Kompilierung aus dem Quellcode vorzuziehen. Bei einer Paketinstallation sind die übrigen Anweisungen in diesem Abschnitt normalerweise nicht erforderlich. Es kann jedoch vorkommen, dass ein Paket eines der Verzeichnisse nicht anlegt oder falsche Berechtigungen vergibt. In diesem Fall kann es erforderlich sein, Verzeichnisse manuell anzulegen oder Berechtigungen anzupassen.

Debian/Ubuntu-Pakete für pgBackRest sind unter apt.postgresql.org verfügbar.

Falls für Ihre Distribution oder Version keine Pakete bereitstehen, können Sie pgBackRest aus dem Quellcode kompilieren und anschließend wie hier gezeigt manuell installieren.

pg-alt ⇒ Abhängigkeiten installieren

sudo apt-get install postgresql-client libxml2 libssh2-1

pg-alt ⇒ pgBackRest-Binärdatei vom Build-Host kopieren

sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest

pgBackRest benötigt Protokoll- und Konfigurationsverzeichnisse sowie eine Konfigurationsdatei.

pg-alt ⇒ pgBackRest-Konfigurationsdatei und Verzeichnisse erstellen

sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf

Passwortloses SSH einrichten

pgBackRest kann für die Kommunikation zwischen Hosts passwortloses SSH verwenden. Alternativ ist TLS möglich; siehe TLS einrichten .

pg-alt ⇒ Schlüsselpaar für den Host pg-alt erstellen

sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh
sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa \
       -t rsa -b 4096 -N ""

Schlüssel zwischen repository und pg-alt austauschen.

repository ⇒ Öffentlichen Schlüssel von pg-alt nach repository kopieren

(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
       echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
       sudo ssh root@pg-alt cat /var/lib/postgresql/.ssh/id_rsa.pub) | \
       sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys

pg-alt ⇒ Öffentlichen Schlüssel von repository nach pg-alt kopieren

(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
       echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
       sudo ssh root@repository cat /home/pgbackrest/.ssh/id_rsa.pub) | \
       sudo -u postgres tee -a /var/lib/postgresql/.ssh/authorized_keys

Prüfen, ob Verbindungen von repository nach pg-alt und in umgekehrter Richtung möglich sind.

repository ⇒ Verbindung von repository nach pg-alt testen

sudo -u pgbackrest ssh postgres@pg-alt

pg-alt ⇒ Verbindung von pg-alt nach repository testen

sudo -u postgres ssh pgbackrest@repository

Konfiguration

Die pgBackRest-Konfiguration ist nahezu identisch mit der von pg-primary. Es wird jedoch die Stanza demo-alt verwendet, damit Backups und Archiv an einem getrennten Ort gespeichert werden.

pg-alt:/etc/pgbackrest/pgbackrest.conf ⇒ pgBackRest auf dem neuen Primärserver konfigurieren

[demo-alt]

pg1-path=/var/lib/postgresql/17/demo



[global]

log-level-file=detail

repo1-host=repository

repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-host/pg1-host-user und pg1-path konfigurieren

[demo]

pg1-host=pg-primary

pg1-path=/var/lib/postgresql/17/demo



[demo-alt]

pg1-host=pg-alt

pg1-path=/var/lib/postgresql/17/demo



[global]

process-max=3

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

Demo-Cluster einrichten

pg-alt ⇒ Demo-Cluster erstellen

sudo -u postgres /usr/lib/postgresql/17/bin/initdb \
       -D /var/lib/postgresql/17/demo -k -A peer
sudo pg_createcluster 17 demo
Configuring already existing cluster (configuration: /etc/postgresql/17/demo, data: /var/lib/postgresql/17/demo, owner: 102:103)
Ver Cluster Port Status Owner    Data directory              Log file
17  demo    5432 down   postgres /var/lib/postgresql/17/demo /var/log/postgresql/postgresql-17-demo.log

pg-alt:/etc/postgresql/17/demo/postgresql.conf ⇒ PostgreSQL-Einstellungen konfigurieren

archive_command = 'pgbackrest --stanza=demo-alt archive-push %p'

archive_mode = on

pg-alt ⇒ Demo-Cluster starten

sudo pg_ctlcluster 17 demo restart

Stanza erstellen und Konfiguration prüfen

Zum Initialisieren der Stanza muss der Befehl stanza-create ausgeführt werden. Es wird empfohlen, nach stanza-create den Befehl check auszuführen, um sicherzustellen, dass Archivierung und Backups korrekt konfiguriert sind.

pg-alt ⇒ Stanza erstellen und Konfiguration prüfen

sudo -u postgres pgbackrest --stanza=demo-alt --log-level-console=info stanza-create
P00   INFO: stanza-create command begin 2.59.3: --exec-id=386-f644abb9 --log-level-console=info --log-level-file=detail --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-host=repository --stanza=demo-alt
P00   INFO: stanza-create for stanza 'demo-alt' on repo1
P00   INFO: stanza-create command end: completed successfully
sudo -u postgres pgbackrest --log-level-console=info check
P00   INFO: check command begin 2.59.3: --exec-id=396-8c7be3ca --log-level-console=info --log-level-file=detail --no-log-timestamp --repo1-host=repository
P00   INFO: check stanza 'demo-alt'
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 000000010000000000000001 successfully archived to '/var/lib/pgbackrest/archive/demo-alt/17-1/0000000100000000/000000010000000000000001-ef9bc7e061e42fae1596a4f23d34fdb78ee324d0.gz' on repo1
P00   INFO: check command end: completed successfully

Wird der Befehl check auf dem Repository-Host ausgeführt, werden alle Stanzas geprüft.

repository ⇒ Konfiguration aller Stanzas prüfen

sudo -u pgbackrest pgbackrest --log-level-console=info check
P00   INFO: check command begin 2.59.3: --exec-id=1284-38748c52 --log-level-console=info --no-log-timestamp --repo1-path=/var/lib/pgbackrest
P00   INFO: check stanza 'demo'
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 000000070000000000000027 successfully archived to '/var/lib/pgbackrest/archive/demo/17-1/0000000700000000/000000070000000000000027-f89bb62652ecba95477379768079564b0243a0d3.gz' on repo1
P00   INFO: check stanza 'demo-alt'
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 000000010000000000000002 successfully archived to '/var/lib/pgbackrest/archive/demo-alt/17-1/0000000100000000/000000010000000000000002-de2b6314bf64b956ede5fad9e01f3d5f0200faff.gz' on repo1
P00   INFO: check command end: completed successfully

Asynchrone Archivierung

Asynchrone Archivierung wird mit der Option archive-async aktiviert. Diese aktiviert den asynchronen Betrieb sowohl für archive-push als auch für archive-get.

Ein Spool-Pfad ist erforderlich. Die Befehle speichern dort vorübergehende Daten, arbeiten jedoch recht unterschiedlich. Daher wird die Verwendung des Spool-Pfads in den jeweiligen Abschnitten ausführlich beschrieben.

pg-primary ⇒ Spool-Verzeichnis erstellen

sudo mkdir -p -m 750 /var/spool/pgbackrest
sudo chown postgres:postgres /var/spool/pgbackrest

pg-standby ⇒ Spool-Verzeichnis erstellen

sudo mkdir -p -m 750 /var/spool/pgbackrest
sudo chown postgres:postgres /var/spool/pgbackrest

Der Spool-Pfad muss konfiguriert und die asynchrone Archivierung aktiviert werden. Schon die asynchrone Archivierung allein bringt Vorteile, weil sie die Zahl der Verbindungen zu entferntem Speicher verringert. Mit process-max kann die Leistung durch Parallelisierung der Vorgänge erheblich gesteigert werden. process-max darf dabei nicht so hoch gesetzt werden, dass der normale Datenbankbetrieb beeinträchtigt wird.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Spool-Pfad und asynchrone Archivierung konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo



[global]

archive-async=y

log-level-file=detail

repo1-host=repository

spool-path=/var/spool/pgbackrest



[global:archive-get]

process-max=2



[global:archive-push]

process-max=2

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ Spool-Pfad und asynchrone Archivierung konfigurieren

[demo]

pg1-path=/var/lib/postgresql/17/demo

recovery-option=primary_conninfo=host=172.17.0.6 port=5432 user=replicator



[global]

archive-async=y

log-level-file=detail

repo1-host=repository

spool-path=/var/spool/pgbackrest



[global:archive-get]

process-max=2



[global:archive-push]

process-max=2

HINWEIS:

process-max wird in Befehlsabschnitten konfiguriert, damit die Option nicht von backup und restore verwendet wird. Dies ermöglicht auch unterschiedliche Werte für archive-push und archive-get.

Zur Demonstration wird die Streaming-Replikation unterbrochen, um PostgreSQL zum Abruf von WAL über restore_command zu zwingen.

pg-primary ⇒ Streaming-Replikation durch Änderung des Replikationspassworts unterbrechen

sudo -u postgres psql -c "alter user replicator password 'bogus'"
ALTER ROLE

pg-standby ⇒ Standby neu starten, um die Verbindung zu unterbrechen

sudo pg_ctlcluster 17 demo restart

Archivübertragung

Der asynchrone Befehl archive-push lagert die WAL-Archivierung in einen oder mehrere separate Prozesse aus, um den Durchsatz zu erhöhen. Er schaut gewissermaßen voraus und ermittelt, welche weiteren WAL-Segmente neben der aktuellen Anfrage von PostgreSQL über archive_command zur Archivierung bereitstehen. WAL-Segmente werden direkt aus dem Verzeichnis pg_xlog/pg_wal ins Archiv übertragen. archive_command meldet erst dann Erfolg, wenn das WAL-Segment sicher im Archiv gespeichert ist.

Der Spool-Pfad enthält den aktuellen Status der WAL-Archivierung. Die dort geschriebenen Statusdateien sind normalerweise leer und sollten nur minimalen Speicherplatz, höchstens einige MB, und sehr wenig IO beanspruchen. Alle Informationen in diesem Verzeichnis können neu erstellt werden. Bei einem Umzug des Clusters auf neue Hardware muss das Spool-Verzeichnis daher nicht aufbewahrt werden.

WICHTIG:

In der ursprünglichen Implementierung der asynchronen Archivierung wurden WAL-Segmente vor der Komprimierung und Übertragung in das Spool-Verzeichnis kopiert. Die neue Implementierung kopiert WAL direkt aus dem Verzeichnis pg_xlog. Wurde asynchrone Archivierung in v1.12 oder früher verwendet, vor dem Upgrade die Versionshinweise zu v1.13 sorgfältig lesen.

Mit der Datei [stanza]-archive-push-async.log lässt sich die Aktivität des asynchronen Prozesses überwachen. Ein guter Test ist die Übertragung mehrerer WAL-Segmente kurz hintereinander.

pg-primary ⇒ Parallele asynchrone Archivierung testen

sudo -u postgres psql -c " \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal();"
sudo -u postgres pgbackrest --stanza=demo --log-level-console=info check
P00   INFO: check command begin 2.59.3: --exec-id=2590-c51c0441 --log-level-console=info --log-level-file=detail --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --repo1-host=repository --stanza=demo
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 00000007000000000000002D successfully archived to '/var/lib/pgbackrest/archive/demo/17-1/0000000700000000/00000007000000000000002D-1ed494e7471557cb0563baa2af44d9e1252e424f.gz' on repo1
P00   INFO: check command end: completed successfully

Die Protokolldatei enthält nun parallele, asynchrone Aktivitäten.

pg-primary ⇒ Ergebnisse im Protokoll prüfen

sudo -u postgres cat /var/log/pgbackrest/demo-archive-push-async.log
-------------------PROCESS START-------------------
P00   INFO: archive-push:async command begin 2.59.3: [/var/lib/postgresql/17/demo/pg_wal] --archive-async --exec-id=2576-267f2388 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo
P00   INFO: push 1 WAL file(s) to archive: 000000070000000000000028
P01 DETAIL: pushed WAL file '000000070000000000000028' to the archive
P00   INFO: archive-push:async command end: completed successfully

-------------------PROCESS START-------------------
P00   INFO: archive-push:async command begin 2.59.3: [/var/lib/postgresql/17/demo/pg_wal] --archive-async --exec-id=2594-5115f5d8 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo
P00   INFO: push 5 WAL file(s) to archive: 000000070000000000000029...00000007000000000000002D
P02 DETAIL: pushed WAL file '00000007000000000000002A' to the archive
P01 DETAIL: pushed WAL file '000000070000000000000029' to the archive
P02 DETAIL: pushed WAL file '00000007000000000000002B' to the archive
P01 DETAIL: pushed WAL file '00000007000000000000002C' to the archive
P02 DETAIL: pushed WAL file '00000007000000000000002D' to the archive
P00   INFO: archive-push:async command end: completed successfully

Archivabruf

Der asynchrone Befehl archive-get hält eine lokale WAL-Warteschlange vor, um den Durchsatz zu erhöhen. Fehlt ein WAL-Segment in der Warteschlange, wird es zusammen mit genügend nachfolgenden WAL-Segmenten zum Füllen der Warteschlange aus dem Repository abgerufen. Deren maximale Größe wird durch archive-get-queue-max festgelegt. Sobald die Warteschlange weniger als halb voll ist, wird weiteres WAL zum Auffüllen abgerufen.

Der asynchrone Betrieb ist besonders nützlich in Umgebungen, die viel WAL erzeugen oder eine Verbindung mit hoher Latenz zum Repository-Speicher haben, etwa zu S3 oder anderen Objektspeichern. Bei hoher Verbindungslatenz kann es sinnvoll sein, process-max zu erhöhen.

Mit der Datei [stanza]-archive-get-async.log lässt sich die Aktivität des asynchronen Prozesses überwachen.

pg-standby ⇒ Ergebnisse im Protokoll prüfen

sudo -u postgres cat /var/log/pgbackrest/demo-archive-get-async.log
-------------------PROCESS START-------------------
P00   INFO: archive-get:async command begin 2.59.3: [000000070000000000000024, 000000070000000000000025, 000000070000000000000026, 000000070000000000000027, 000000070000000000000028, 000000070000000000000029, 00000007000000000000002A, 00000007000000000000002B] --archive-async --exec-id=871-5afe1731 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo
P00   INFO: get 8 WAL file(s) from archive: 000000070000000000000024...00000007000000000000002B
P02 DETAIL: found 000000070000000000000025 in the repo1: 17-1 archive
P01 DETAIL: found 000000070000000000000024 in the repo1: 17-1 archive
P02 DETAIL: found 000000070000000000000026 in the repo1: 17-1 archive
P01 DETAIL: found 000000070000000000000027 in the repo1: 17-1 archive
P00 DETAIL: unable to find 000000070000000000000028 in the archive
P00   INFO: archive-get:async command end: completed successfully
       [filtered 14 lines of output]
P00   INFO: archive-get:async command begin 2.59.3: [000000070000000000000028, 000000070000000000000029, 00000007000000000000002A, 00000007000000000000002B, 00000007000000000000002C, 00000007000000000000002D, 00000007000000000000002E, 00000007000000000000002F] --archive-async --exec-id=924-87ccaa43 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/17/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo
P00   INFO: get 8 WAL file(s) from archive: 000000070000000000000028...00000007000000000000002F
P02 DETAIL: found 000000070000000000000029 in the repo1: 17-1 archive
P01 DETAIL: found 000000070000000000000028 in the repo1: 17-1 archive
P02 DETAIL: found 00000007000000000000002A in the repo1: 17-1 archive
P01 DETAIL: found 00000007000000000000002B in the repo1: 17-1 archive
P02 DETAIL: found 00000007000000000000002C in the repo1: 17-1 archive
P01 DETAIL: found 00000007000000000000002D in the repo1: 17-1 archive
P00 DETAIL: unable to find 00000007000000000000002E in the archive
P00   INFO: archive-get:async command end: completed successfully
       [filtered 15 lines of output]

pg-primary ⇒ Streaming-Replikation durch Änderung des Replikationspassworts reparieren

sudo -u postgres psql -c "alter user replicator password 'jw8s0F4'"
ALTER ROLE

Backup von einem Standby

pgBackRest kann Backups auf einem Standby statt auf dem Primärserver durchführen. Dazu muss der Host pg-standby konfiguriert und die Option backup-standby aktiviert sein. Sind mehrere Standbys konfiguriert, wird der erste gefundene laufende Standby für das Backup verwendet.

repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg2-host/pg2-host-user und pg2-path konfigurieren

[demo]

pg1-host=pg-primary

pg1-path=/var/lib/postgresql/17/demo

pg2-host=pg-standby

pg2-path=/var/lib/postgresql/17/demo



[demo-alt]

pg1-host=pg-alt

pg1-path=/var/lib/postgresql/17/demo



[global]

backup-standby=y

process-max=3

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

Für das Backup werden sowohl die Datenbank auf dem Primärserver als auch die auf dem Standby benötigt. Der weitaus größte Teil der Dateien wird jedoch vom Standby kopiert, um den Primärserver zu entlasten. Die Datenbankhosts können in beliebiger Reihenfolge konfiguriert werden. pgBackRest erkennt automatisch, welcher Host der Primärserver und welcher der Standby ist.

repository ⇒ Backup des Demo-Clusters von pg2 erstellen

sudo -u pgbackrest pgbackrest --stanza=demo --log-level-console=detail backup
       [filtered 2 lines of output]
P00   INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 00000007000000000000002F, lsn = 0/2F000028
P00   INFO: wait for replay on the standby to reach 0/2F000028
P00   INFO: replay on the standby reached 0/2F000028
P00   INFO: check archive for prior segment 00000007000000000000002E
P03 DETAIL: backup file pg-standby:/var/lib/postgresql/17/demo/base/5/2658 (128KB, 8.47%) checksum 6bcdcabc7aaf3e4919655612f77833a1612baf01
P01 DETAIL: backup file pg-primary:/var/lib/postgresql/17/demo/global/pg_control (8KB, 8.99%) checksum aa003dff0afea4b06a88d00138da8e948a563345
P04 DETAIL: backup file pg-standby:/var/lib/postgresql/17/demo/base/5/1247 (120KB, 16.93%) checksum fa2fb6657bf9785e320a8a5516851de78d7a7a33
P01 DETAIL: match file from prior backup pg-primary:/var/lib/postgresql/17/demo/pg_logical/replorigin_checkpoint (8B, 16.93%) checksum 347fc8f2df71bd4436e38bd1516ccd7ea0d46532
       [filtered 1277 lines of output]

Dieses inkrementelle Backup zeigt, dass die meisten Dateien vom Host pg-standby und nur wenige vom Host pg-primary kopiert werden.

pgBackRest erstellt auf dem Standby ein Backup, das mit einem auf dem Primärserver durchgeführten Backup identisch ist. Dazu startet und beendet es das Backup auf dem Host pg-primary, kopiert die replizierten Dateien vom Host pg-standby und anschließend die wenigen übrigen Dateien von pg-primary. Damit enthält das Backup auch Protokolle und Statistiken der primären Datenbank.

Upgrade von PostgreSQL

Unmittelbar nach dem Upgrade von PostgreSQL auf eine neuere Hauptversion muss pg-path in allen pgBackRest-Konfigurationen auf den neuen Datenbankspeicherort gesetzt und der Befehl stanza-upgrade ausgeführt werden. Sind auf dem Host mehrere Repositorys konfiguriert, wird die Stanza in jedem davon aktualisiert. Ist die Datenbank offline, die Option --no-online verwenden.

Die folgenden Anweisungen sind keine umfassende Anleitung zum Upgrade von PostgreSQL. Sie skizzieren den allgemeinen Ablauf für ein Upgrade von Primärserver und Standby, um die zur Neukonfiguration von pgBackRest erforderlichen Schritte zu zeigen. Vor dem Upgrade wird ein Backup empfohlen.

pg-primary ⇒ Alten Cluster stoppen

sudo pg_ctlcluster 17 demo stop

Den alten Cluster auf dem Standby stoppen, da er aus dem gerade aktualisierten Cluster wiederhergestellt wird.

pg-standby ⇒ Alten Cluster stoppen

sudo pg_ctlcluster 17 demo stop

Den neuen Cluster erstellen und das Upgrade durchführen.

pg-primary ⇒ Neuen Cluster erstellen und Upgrade durchführen

sudo -u postgres /usr/lib/postgresql/18/bin/initdb \
       -D /var/lib/postgresql/18/demo -k -A peer
sudo pg_createcluster 18 demo
sudo -u postgres sh -c 'cd /var/lib/postgresql && \
       /usr/lib/postgresql/18/bin/pg_upgrade \
       --old-bindir=/usr/lib/postgresql/17/bin \
       --new-bindir=/usr/lib/postgresql/18/bin \
       --old-datadir=/var/lib/postgresql/17/demo \
       --new-datadir=/var/lib/postgresql/18/demo \
       --old-options=" -c config_file=/etc/postgresql/17/demo/postgresql.conf" \
       --new-options=" -c config_file=/etc/postgresql/18/demo/postgresql.conf"'
       [filtered 44 lines of output]
Checking for extension updates                                ok
Upgrade Complete
----------------
Some statistics are not transferred by pg_upgrade.
       [filtered 4 lines of output]

Die Einstellungen und den Port des neuen Clusters konfigurieren.

pg-primary:/etc/postgresql/18/demo/postgresql.conf ⇒ PostgreSQL konfigurieren

archive_command = 'pgbackrest --stanza=demo archive-push %p'

archive_mode = on

Die pgBackRest-Konfiguration auf allen Systemen so anpassen, dass sie auf den neuen Cluster verweist.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-path aktualisieren

[demo]

pg1-path=/var/lib/postgresql/18/demo



[global]

archive-async=y

log-level-file=detail

repo1-host=repository

spool-path=/var/spool/pgbackrest



[global:archive-get]

process-max=2



[global:archive-push]

process-max=2

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ pg-path aktualisieren

[demo]

pg1-path=/var/lib/postgresql/18/demo

recovery-option=primary_conninfo=host=172.17.0.6 port=5432 user=replicator



[global]

archive-async=y

log-level-file=detail

repo1-host=repository

spool-path=/var/spool/pgbackrest



[global:archive-get]

process-max=2



[global:archive-push]

process-max=2

repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-path und pg2-path aktualisieren und Backup vom Standby deaktivieren

[demo]

pg1-host=pg-primary

pg1-path=/var/lib/postgresql/18/demo

pg2-host=pg-standby

pg2-path=/var/lib/postgresql/18/demo



[demo-alt]

pg1-host=pg-alt

pg1-path=/var/lib/postgresql/17/demo



[global]

backup-standby=n

process-max=3

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

pg-primary ⇒ hba-Konfiguration kopieren

sudo cp /etc/postgresql/17/demo/pg_hba.conf \
       /etc/postgresql/18/demo/pg_hba.conf

Vor dem Start des neuen Clusters muss der Befehl stanza-upgrade ausgeführt werden.

pg-primary ⇒ Stanza aktualisieren

sudo -u postgres pgbackrest --stanza=demo --no-online \
       --log-level-console=info stanza-upgrade
P00   INFO: stanza-upgrade command begin 2.59.3: --exec-id=3025-70610f0d --log-level-console=info --log-level-file=detail --no-log-timestamp --no-online --pg1-path=/var/lib/postgresql/18/demo --repo1-host=repository --stanza=demo
P00   INFO: stanza-upgrade for stanza 'demo' on repo1
P00   INFO: stanza-upgrade command end: completed successfully

Den neuen Cluster starten und den Erfolg der Installation prüfen.

pg-primary ⇒ Neuen Cluster starten

sudo pg_ctlcluster 18 demo start

Die Konfiguration mit dem Befehl check testen.

pg-primary ⇒ Konfiguration prüfen

sudo pg_lsclusters
sudo -u postgres pgbackrest --stanza=demo check

Den alten Cluster entfernen.

pg-primary ⇒ Alten Cluster entfernen

sudo pg_dropcluster 17 demo

Die neuen PostgreSQL-Binärdateien auf dem Standby installieren und den Cluster erstellen.

pg-standby ⇒ Alten Cluster entfernen und neuen Cluster erstellen

sudo pg_dropcluster 17 demo
sudo pg_createcluster 18 demo

check auf dem Repository-Host ausführen. Die Warnung zum nicht verfügbaren Standby ist zu erwarten, da der Standby-Cluster gestoppt ist. Die Ausführung zeigt, dass der Repository-Server den Standby kennt und für den Primärserver korrekt konfiguriert ist.

repository ⇒ Konfiguration prüfen

sudo -u pgbackrest pgbackrest --stanza=demo check
P00   WARN: unable to check pg2: [DbConnectError] raised from remote-0 ssh protocol on 'pg-standby': unable to connect to 'dbname='postgres' port=5432': connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
                Is the server running locally and accepting connections on that socket?

Ein vollständiges Backup des neuen Clusters durchführen und anschließend den Standby daraus wiederherstellen. Wird incr oder diff angefordert, wird der Backup-Typ automatisch auf full geändert.

repository ⇒ Vollständiges Backup durchführen

sudo -u pgbackrest pgbackrest --stanza=demo --type=full backup

pg-standby ⇒ Demo-Standby-Cluster wiederherstellen

sudo -u postgres pgbackrest --stanza=demo --delta --type=standby restore

pg-standby ⇒ PostgreSQL starten und pgBackRest-Konfiguration prüfen

sudo pg_ctlcluster 18 demo start
sudo -u postgres pgbackrest --stanza=demo check

Nach der Wiederherstellung des Standbys kann das Backup vom Standby aktiviert werden.

repository:/etc/pgbackrest/pgbackrest.conf ⇒ Backup vom Standby wieder aktivieren

[demo]

pg1-host=pg-primary

pg1-path=/var/lib/postgresql/18/demo

pg2-host=pg-standby

pg2-path=/var/lib/postgresql/18/demo



[demo-alt]

pg1-host=pg-alt

pg1-path=/var/lib/postgresql/17/demo



[global]

backup-standby=y

process-max=3

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

3 - Benutzerhandbuch (RHEL)

Schrittweise Anleitung zur Einrichtung und Verwendung von pgBackRest auf RHEL-, Rocky- und AlmaLinux-Systemen.

Einführung

Dieses Benutzerhandbuch sollte von Anfang bis Ende der Reihe nach durchgearbeitet werden, da jeder Abschnitt auf dem vorherigen aufbaut. Beispielsweise setzt der Abschnitt Wiederherstellung die Einrichtung aus dem Abschnitt Schnellstart voraus. Sobald pgBackRest eingerichtet ist und läuft, können einzelne Abschnitte gezielt aufgerufen werden. Beim ersten Durcharbeiten wird jedoch empfohlen, die Reihenfolge des Benutzerhandbuchs einzuhalten.

Die Beispiele in diesem Handbuch beziehen sich auf RHEL und PostgreSQL 14, sollten sich aber ohne großen Aufwand auf andere Unix-Distributionen und PostgreSQL-Versionen übertragen lassen. Nur die Befehle zum Erstellen, Starten, Stoppen und Löschen von PostgreSQL-Clustern sind betriebssystemspezifisch. Die pgBackRest-Befehle sind auf allen Unix-Systemen gleich, auch wenn der Speicherort der ausführbaren Datei abweichen kann. pgBackRest soll sich über PostgreSQL-Versionen hinweg einheitlich verhalten. Dennoch gibt es zwischen den PostgreSQL-Versionen kleinere Unterschiede, die in einigen Beispielen dieses Handbuchs sichtbar werden können, etwa bei PostgreSQL-Pfad- und Dateinamen sowie Einstellungen.

Informationen zur Konfiguration und die Dokumentation von PostgreSQL sind im PostgreSQL-Handbuch zu finden.

Dieses Benutzerhandbuch verwendet einen etwas ungewöhnlichen Ansatz zur Dokumentation: Beim Erstellen der Dokumentation aus der XML-Quelle wird jeder Befehl auf einer virtuellen Maschine ausgeführt. Dadurch lässt sich mit hoher Zuverlässigkeit davon ausgehen, dass die Befehle in der angegebenen Reihenfolge korrekt funktionieren. Wo sinnvoll, wird die Ausgabe erfasst und unter dem Befehl angezeigt. Fehlende Ausgaben wurden als nicht relevant eingestuft oder weggelassen, weil sie vom beschriebenen Ablauf ablenken würden.

Alle Befehle sind für die Ausführung durch einen unprivilegierten Benutzer vorgesehen, der sudo-Rechte für die Benutzer root und postgres besitzt. Sie können auch unverändert direkt unter dem jeweiligen Benutzer ausgeführt werden; in diesem Fall können die vorangestellten sudo-Befehle entfallen.

Konzepte

Die folgenden Begriffe werden in ihrer Bedeutung für pgBackRest, PostgreSQL und dieses Benutzerhandbuch definiert.

Backup

Ein Backup ist eine konsistente Kopie eines Datenbankclusters. Es kann wiederhergestellt werden, um den Betrieb nach einem Hardwareausfall wieder aufzunehmen, eine Point-in-Time-Recovery durchzuführen oder einen neuen Standby in Betrieb zu nehmen.

Vollständiges Backup: pgBackRest kopiert den gesamten Inhalt des Datenbankclusters in das Backup. Das erste Backup eines Datenbankclusters ist immer ein vollständiges Backup. pgBackRest kann ein vollständiges Backup jederzeit direkt wiederherstellen. Für seine Konsistenz ist es auf keine Dateien außerhalb dieses vollständigen Backups angewiesen.

Differenzielles Backup: pgBackRest kopiert nur die Dateien des Datenbankclusters, die sich seit dem letzten vollständigen Backup geändert haben. Bei der Wiederherstellung eines differenziellen Backups kopiert pgBackRest alle Dateien aus dem gewählten differenziellen Backup und die zugehörigen unveränderten Dateien aus dem vorherigen vollständigen Backup. Ein differenzielles Backup benötigt weniger Speicherplatz als ein vollständiges Backup. Für seine Wiederherstellung müssen jedoch sowohl das differenzielle als auch das vollständige Backup gültig sein.

Inkrementelles Backup: pgBackRest kopiert nur die Dateien des Datenbankclusters, die sich seit dem letzten Backup geändert haben. Dieses kann ein anderes inkrementelles, ein differenzielles oder ein vollständiges Backup sein. Da ein inkrementelles Backup nur die seit dem vorherigen Backup geänderten Dateien enthält, ist es in der Regel deutlich kleiner als ein vollständiges oder differenzielles Backup. Wie beim differenziellen Backup müssen für die Wiederherstellung eines inkrementellen Backups auch andere Backups gültig sein. Da es nur die seit dem letzten Backup geänderten Dateien enthält, müssen alle vorherigen inkrementellen Backups bis zum vorherigen differenziellen Backup sowie dieses differenzielle und das vorherige vollständige Backup gültig sein. Gibt es kein differenzielles Backup, müssen alle vorherigen inkrementellen Backups bis zum vorherigen vollständigen Backup sowie das vollständige Backup selbst gültig sein; ein vollständiges Backup muss vorhanden sein.

Wiederherstellung

Bei einer Wiederherstellung wird ein Backup auf ein System kopiert, auf dem es als aktiver Datenbankcluster gestartet wird. Für eine korrekte Wiederherstellung werden die Backup-Dateien und ein oder mehrere WAL-Segmente benötigt.

Write-Ahead-Log (WAL)

Mit dem WAL stellt PostgreSQL sicher, dass keine durch Commit bestätigten Änderungen verloren gehen. Transaktionen werden sequenziell in das WAL geschrieben. Eine Transaktion gilt als bestätigt, sobald diese Schreibvorgänge dauerhaft auf dem Datenträger gespeichert sind. Anschließend schreibt ein Hintergrundprozess die Änderungen in die eigentlichen Dateien des Datenbankclusters, die auch als Heap bezeichnet werden. Nach einem Absturz wird das WAL erneut angewendet, um die Datenbank in einen konsistenten Zustand zu bringen.

Das WAL ist konzeptionell unendlich, wird in der Praxis jedoch in einzelne 16MB-Dateien, sogenannte Segmente, unterteilt. WAL-Segmente folgen der Namenskonvention 0000000100000A1E000000FE: Die ersten 8 Hexadezimalziffern stehen für die Timeline, die folgenden 16 Ziffern für die logische Sequenznummer (LSN).

Verschlüsselung

Bei der Verschlüsselung werden Daten in ein Format umgewandelt, das ohne das passende Passwort, auch Passphrase genannt, nicht lesbar ist.

pgBackRest verschlüsselt das Repository basierend auf einem vom Benutzer bereitgestellten Passwort, wodurch ein unbefugter Zugriff auf die im Repository gespeicherten Daten verhindert wird.

Upgrade von pgBackRest

Upgrade von pgBackRest von v2.x auf v2.y

Ein Upgrade von v2.x auf v2.y ist unkompliziert. Das Repository-Format hat sich nicht geändert, sodass bei den meisten Installationen lediglich die Binärdateien der neuen Version installiert werden müssen. Ein Downgrade ist ebenfalls möglich, solange keine neuen Funktionen verwendet wurden, die die ältere Version nicht unterstützt.

WICHTIG:

Die pgBackRest-Versionen auf dem lokalen und dem entfernten Host müssen exakt übereinstimmen und sollten daher gemeinsam aktualisiert werden. Bei einer Abweichung funktionieren WAL-Archivierung und Backups erst wieder, wenn die Versionen übereinstimmen. In diesem Fall wird folgender Fehler gemeldet: [ProtocolError] expected value '2.x' for greeting key 'version' but got '2.y'.

Kompilierung

Die Installation von pgBackRest aus einem Paket ist der Kompilierung aus dem Quellcode vorzuziehen. Weitere Informationen zu Paketen stehen unter Installation .

Für die Kompilierung aus dem Quellcode empfiehlt sich ein eigener Build-Host, statt direkt in der Produktionsumgebung zu kompilieren. Viele der dafür benötigten Werkzeuge sollten grundsätzlich nicht in der Produktionsumgebung installiert werden. pgBackRest besteht aus einer einzigen ausführbaren Datei, die nach der Kompilierung leicht auf einen neuen Host kopiert werden kann.

build ⇒ Version 2.59.3 von pgBackRest unter /build herunterladen

mkdir -p /build
curl -fsSL \
       https://github.com/pgbackrest/pgbackrest/releases/download/release%2F2.59.3/pgbackrest-2.59.3.tar.gz | \
       tar zx -C /build

build ⇒ Build-Abhängigkeiten installieren

sudo yum install meson gcc postgresql14-devel openssl-devel libxml2-devel \
       lz4-devel libzstd-devel bzip2-devel libssh2-devel systemd-devel

build ⇒ pgBackRest konfigurieren und kompilieren

meson setup /build/pgbackrest /build/pgbackrest-2.59.3
ninja -C /build/pgbackrest

build ⇒ Optional Smoke-Tests ausführen, um die korrekte Kompilierung von pgBackRest zu prüfen

meson test -C /build/pgbackrest --suite smoke
ninja: Entering directory `/build/pgbackrest'
ninja: no work to do.
1/1 smoke OK               10.32s

Ok:                 1
       [filtered 6 lines of output]

Installation

Ein neuer Host namens pg-primary wird für den Demo-Cluster und die Ausführung der pgBackRest-Beispiele eingerichtet.

Die Installation von pgBackRest aus einem Paket ist der Kompilierung aus dem Quellcode vorzuziehen. Bei einer Paketinstallation sind die übrigen Anweisungen in diesem Abschnitt normalerweise nicht erforderlich. Es kann jedoch vorkommen, dass ein Paket eines der Verzeichnisse nicht anlegt oder falsche Berechtigungen vergibt. In diesem Fall kann es erforderlich sein, Verzeichnisse manuell anzulegen oder Berechtigungen anzupassen.

RHEL-Pakete für pgBackRest sind unter yum.postgresql.org verfügbar.

Falls für Ihre Distribution oder Version keine Pakete bereitstehen, können Sie pgBackRest aus dem Quellcode kompilieren und anschließend wie hier gezeigt manuell installieren.

pg-primary ⇒ Abhängigkeiten installieren

sudo yum install postgresql-libs libssh2

pg-primary ⇒ pgBackRest-Binärdatei vom Build-Host kopieren

sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest

pgBackRest benötigt Protokoll- und Konfigurationsverzeichnisse sowie eine Konfigurationsdatei.

pg-primary ⇒ pgBackRest-Konfigurationsdatei und Verzeichnisse erstellen

sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf

pgBackRest sollte nun ordnungsgemäß installiert sein, aber es ist ratsam, dies zu überprüfen. Falls Abhängigkeiten vergessen wurden, erhalten Sie einen Fehler, wenn Sie pgBackRest über die Befehlszeile ausführen.

pg-primary ⇒ Sicherstellen, dass die Installation erfolgreich war

sudo -u postgres pgbackrest
pgBackRest 2.59.3 - General help

Usage:
    pgbackrest [options] [command]

Commands:
    annotate        add or modify backup annotation
    archive-get     get a WAL segment from the archive
    archive-push    push a WAL segment to the archive
    backup          backup a database cluster
    check           check the configuration
    expire          expire backups that exceed retention
    help            get help
    info            retrieve information about backups
    repo-get        get a file from a repository
    repo-ls         list files in a repository
    restore         restore a database cluster
    server          pgBackRest server
    server-ping     ping pgBackRest server
    stanza-create   create the required stanza data
    stanza-delete   delete a stanza
    stanza-upgrade  upgrade a stanza
    start           allow pgBackRest processes to run
    stop            stop pgBackRest processes from running
    verify          verify contents of a repository
    version         get version

Use 'pgbackrest help [command]' for more information.

Schnellstart

Der Schnellstart-Abschnitt behandelt die grundlegende Konfiguration von pgBackRest und PostgreSQL und führt die Befehle backup, restore und info ein.

Demo-Cluster einrichten

Das Erstellen des Demo-Clusters ist optional, wird jedoch insbesondere neuen Benutzern dringend empfohlen, da die Beispielbefehle im Benutzerhandbuch auf ihn verweisen. Die Beispiele setzen voraus, dass der Demo-Cluster auf dem Standardport 5432 läuft. Der Cluster wird erst in einem späteren Abschnitt gestartet, da zuvor noch einige Einstellungen vorgenommen werden müssen.

pg-primary ⇒ Demo-Cluster erstellen

sudo -u postgres /usr/pgsql-14/bin/initdb \
       -D /var/lib/pgsql/14/data -k -A peer

RHEL nimmt standardmäßig den Wochentag in den Namen der Protokolldatei auf. Da dies das Benutzerhandbuch etwas komplizierter macht, wird log_filename auf einen konstanten Wert gesetzt.

pg-primary:/var/lib/pgsql/14/data/postgresql.conf ⇒ log_filename setzen

log_filename = 'postgresql.log'

Cluster-Stanza konfigurieren

Eine Stanza ist die Konfiguration für einen PostgreSQL-Datenbankcluster. Sie legt unter anderem seinen Speicherort, die Durchführung von Backups und die Archivierungsoptionen fest. Die meisten Datenbankserver betreiben nur einen PostgreSQL-Datenbankcluster und haben daher eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Besser ist jedoch ein Name, der die im Cluster enthaltenen Datenbanken beschreibt. Da der Name der Stanza für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

Der Name „demo“ beschreibt den Zweck dieses Clusters treffend und eignet sich daher auch als Name der Stanza.

pgBackRest muss den Speicherort des Basisdatenverzeichnisses des PostgreSQL-Clusters kennen. Der Pfad kann direkt von PostgreSQL abgefragt werden, doch bei einer Recovery steht der PostgreSQL-Prozess nicht zur Verfügung. Während eines Backups wird der für pgBackRest angegebene Wert mit dem von PostgreSQL verwendeten Pfad verglichen. Beide müssen übereinstimmen, andernfalls meldet das Backup einen Fehler. Sicherstellen, dass pg-path exakt dem von PostgreSQL gemeldeten data_directory entspricht.

RHEL speichert Cluster standardmäßig unter /var/lib/pgsql/[version]/data, sodass sich der richtige Pfad zum Datenverzeichnis leicht bestimmen lässt.

Beim Erstellen der Datei /etc/pgbackrest/pgbackrest.conf muss dem Datenbankeigentümer, normalerweise postgres, Leseberechtigung erteilt werden.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Datenverzeichnis des PostgreSQL-Clusters konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data

Die Konfigurationsdateien von pgBackRest folgen einer Konvention ähnlich dem INI-Format von Windows. Abschnitte werden durch Text in eckigen Klammern gekennzeichnet und enthalten Schlüssel-Wert-Paare. Zeilen, die mit # beginnen, werden ignoriert und können als Kommentare verwendet werden. Kommentare nach einem Wert in derselben Zeile werden jedoch nicht unterstützt. Anführungszeichen werden nicht unterstützt; Leerraum am Anfang und Ende von Schlüsseln und Werten wird entfernt. Mehrfach vorkommende Abschnitte werden zusammengeführt.

Die Konfigurationsdateien von pgBackRest können auf mehrere Arten geladen werden:

  • config und config-include-path haben ihre Standardwerte: Die Standardkonfigurationsdatei wird geladen, sofern sie existiert. Vorhandene *.conf-Dateien im standardmäßigen Konfigurations-Include-Pfad werden angehängt.
  • Die Option config ist angegeben: Nur die angegebene Konfigurationsdatei wird geladen; sie muss existieren.
  • config-include-path ist angegeben: Die *.conf-Dateien im Konfigurations-Include-Pfad werden geladen; der Pfad muss existieren. Die Standardkonfigurationsdatei wird geladen, sofern sie existiert. Sollen nur die Dateien im angegebenen Konfigurations-Include-Pfad geladen werden, kann zusätzlich die Option --no-config übergeben werden.
  • config und config-include-path sind angegeben: Die Konfigurationsdatei wird anhand der benutzerdefinierten Werte geladen und die *.conf-Dateien im Konfigurations-Include-Pfad werden angehängt. Die Dateien müssen existieren.
  • config-path ist angegeben: Diese Einstellung überschreibt den Basispfad des Standardspeicherorts der Konfigurationsdatei und/oder den Basispfad der Standardeinstellung von config-include-path, sofern die Option config und/oder config-include-path nicht ausdrücklich gesetzt ist.

Die Dateien werden so zusammengefügt, als wären sie eine einzige große Datei; jede Datei muss jedoch für sich gültig sein. Das bedeutet, dass Abschnitte in jeder Datei angegeben werden müssen, in der sie zum Speichern eines Schlüssel-Wert-Paars benötigt werden. Die Reihenfolge ist unerheblich, doch es gilt eine Rangfolge der Abschnitte. Die Priorität ist, von der höchsten zur niedrigsten:

  • [stanza:command]
  • [stanza]
  • [global:command]
  • [global]

HINWEIS:

--config, --config-include-path und --config-path sind ausschließlich über die Befehlszeile verfügbare Optionen.

pgBackRest kann auch über Umgebungsvariablen konfiguriert werden, wie im folgenden Beispiel gezeigt. Diese Variablen gelten für Befehle wie backup , restore und archive-push .

pg-primary ⇒ log-path über die Umgebung konfigurieren

sudo -u postgres bash -c ' \
       export PGBACKREST_LOG_PATH=/path/set/by/env && \
       pgbackrest --log-level-console=error help backup log-path'
pgBackRest 2.59.3 - 'backup' command - 'log-path' option help

Path where log files are stored.

The log path provides a location for pgBackRest to store log files. Note that
if log-level-file=off then no log path is required.

current: /path/set/by/env
default: /var/log/pgbackrest

Repository erstellen

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus möglicherweise nur schwer abschätzen. Am besten werden einige Backups erstellt und die Größe der verschiedenen Backup-Typen (full/incr/diff) sowie die täglich erzeugte WAL-Menge erfasst. Das liefert eine grobe Vorstellung vom Speicherbedarf. Dieser wird sich allerdings im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

Für diese Demonstration wird das Repository auf demselben Host wie der PostgreSQL-Server gespeichert. Dies ist die einfachste Konfiguration und eignet sich für Fälle, in denen der Datenbankhost mit herkömmlicher Backup-Software gesichert wird.

pg-primary ⇒ pgBackRest-Repository erstellen

sudo mkdir -p /var/lib/pgbackrest
sudo chmod 750 /var/lib/pgbackrest
sudo chown postgres:postgres /var/lib/pgbackrest

Der Repository-Pfad muss konfiguriert werden, damit pgBackRest das Repository finden kann.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Pfad zum pgBackRest-Repository konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-path=/var/lib/pgbackrest

Es können auch mehrere Repositorys konfiguriert werden. Einzelheiten stehen unter Mehrere Repositorys .

Archivierung konfigurieren

Für das Backup eines laufenden PostgreSQL-Clusters muss die WAL-Archivierung aktiviert sein. Mit %p gibt PostgreSQL den Speicherort des zu archivierenden WAL-Segments an. Während des Backups wird mindestens ein WAL-Segment erzeugt, auch wenn keine ausdrücklichen Schreibzugriffe auf den Cluster erfolgen.

pg-primary:/var/lib/pgsql/14/data/postgresql.conf ⇒ Archivierungseinstellungen konfigurieren

archive_command = 'pgbackrest --stanza=demo archive-push %p'

archive_mode = on

log_filename = 'postgresql.log'

Nach diesen Änderungen muss der PostgreSQL-Cluster neu gestartet werden, bevor ein Backup durchgeführt wird.

pg-primary ⇒ Demo-Cluster neu starten

sudo systemctl restart postgresql-14.service

Die Einstellung hot_standby ist standardmäßig aktiviert und sollte auf jedem Cluster aktiviert bleiben. Jeder Cluster kann später als Standby wiederhergestellt werden, beispielsweise ein Primärserver, der nach einem Failover als Standby neu aufgebaut wird. Ohne diese Einstellung akzeptiert ein Standby keine schreibgeschützten Verbindungen.

Wenn zu erwarten ist, dass ein zu archivierendes WAL-Segment mehr als 60 Sekunden, den Standardwert, benötigt, um das pgBackRest-Repository zu erreichen, sollte die pgBackRest-Option archive-timeout erhöht werden. Diese Option ist nicht mit der PostgreSQL-Option archive_timeout identisch. Letztere erzwingt einen WAL-Segmentwechsel und ist bei Datenbanken mit längeren Phasen ohne Aktivität nützlich. Weitere Informationen zur PostgreSQL-Option archive_timeout stehen unter Write-Ahead-Log in der PostgreSQL-Dokumentation.

Für den Befehl archive-push können eigene Optionen konfiguriert werden. Beispielsweise lässt sich eine niedrigere Komprimierungsstufe festlegen, um die Archivierung zu beschleunigen, ohne die Komprimierung für Backups zu beeinflussen.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ archive-push für eine niedrigere Komprimierungsstufe konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-path=/var/lib/pgbackrest



[global:archive-push]

compress-level=3

Diese Art der Konfiguration kann für jeden Befehl verwendet werden und sich auch auf eine bestimmte Stanza beziehen, beispielsweise demo:archive-push.

Aufbewahrung konfigurieren

pgBackRest entfernt Backups anhand der Aufbewahrungsoptionen.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Aufbewahrung auf 2 vollständige Backups festlegen

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2



[global:archive-push]

compress-level=3

Weitere Informationen zur Aufbewahrung stehen im Abschnitt Aufbewahrung .

Repository-Verschlüsselung konfigurieren

Zur Demonstration der Verschlüsselung werden für das Repository ein Verschlüsselungstyp und ein Schlüssel konfiguriert. Die Verschlüsselung erfolgt immer auf der Clientseite, auch wenn der Repository-Typ, beispielsweise S3 oder ein anderer Objektspeicher, Verschlüsselung unterstützt.

Für den Schlüssel ist eine lange, zufällige Passphrase wichtig. Sie lässt sich beispielsweise mit folgendem Befehl erzeugen: openssl rand -base64 48.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Verschlüsselung des pgBackRest-Repositorys konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2



[global:archive-push]

compress-level=3

HINWEIS:

Die Verschlüsselungseinstellungen werden oben im Abschnitt [global] abgelegt, damit der Befehl info alle Stanzas lesen kann. Ohne die Option stanza liest info Verschlüsselungseinstellungen ausschließlich aus dem Abschnitt [global]. Werden die Verschlüsselungseinstellungen pro Stanza konfiguriert, ist daher die Option stanza erforderlich, um eine verschlüsselte Stanza zu lesen.

Nachdem das Repository konfiguriert und die Stanza erstellt und geprüft wurde, können die Verschlüsselungseinstellungen des Repositorys nicht mehr geändert werden.

Stanza erstellen

Zum Initialisieren der Stanza muss der Befehl stanza-create ausgeführt werden. Es wird empfohlen, nach stanza-create den Befehl check auszuführen, um sicherzustellen, dass Archivierung und Backups korrekt konfiguriert sind.

pg-primary ⇒ Stanza erstellen und Konfiguration prüfen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create
P00   INFO: stanza-create command begin 2.59.3: --exec-id=1200-90682d35 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo
P00   INFO: stanza-create for stanza 'demo' on repo1
P00   INFO: stanza-create command end: completed successfully

Konfiguration prüfen

Der Befehl check prüft, ob pgBackRest und die Einstellung archive_command für Archivierung und Backups der angegebenen Stanza korrekt konfiguriert sind. Er versucht, alle Repositorys und Datenbanken zu prüfen, die für den Host konfiguriert sind, auf dem er ausgeführt wird. Er erkennt Fehlkonfigurationen, insbesondere bei der Archivierung, die zu unvollständigen Backups führen, weil erforderliche WAL-Segmente das Archiv nicht erreicht haben. Der Befehl kann auf dem PostgreSQL- oder dem Repository-Host ausgeführt werden. Er kann auch auf dem Standby-Host ausgeführt werden. Da pg_switch_xlog()/pg_switch_wal() auf dem Standby jedoch nicht ausgeführt werden können, prüft er dort nur die Repository-Konfiguration.

Dabei werden pg_create_restore_point('pgBackRest Archive Check') und pg_switch_xlog()/pg_switch_wal() aufgerufen, um PostgreSQL zur Archivierung eines WAL-Segments zu veranlassen.

pg-primary ⇒ Konfiguration prüfen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info check
P00   INFO: check command begin 2.59.3: --exec-id=1233-340209f5 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 000000010000000000000001 successfully archived to '/var/lib/pgbackrest/archive/demo/14-1/0000000100000000/000000010000000000000001-dac4045f133f7305d6342d81e428e60050928bc4.gz' on repo1
P00   INFO: check command end: completed successfully

Leistungsoptimierung

pgBackRest bietet mehrere Leistungsoptionen, die standardmäßig deaktiviert sind, um die Abwärtskompatibilität des Repositorys zu wahren. Beim Erstellen eines neuen Repositorys werden die folgenden Optionen jedoch empfohlen. Sie können auch mit einem vorhandenen Repository verwendet werden, allerdings können ältere pgBackRest-Versionen das Repository dann nicht mehr lesen. Diese Inkompatibilität hängt davon ab, wann die jeweilige Funktion eingeführt wurde, wie in der folgenden Liste angegeben.

  • compress-type - legt den Komprimierungsalgorithmus für die Befehle backup und archive-push fest. Der Standardwert ist gz (Gzip), empfohlen wird jedoch zst (Zstandard), da es deutlich schneller ist und eine ähnliche Komprimierung wie gz bietet. Die Option compress-type unterstützt zst seit v2.27 . Weitere Einzelheiten stehen unter Komprimierungstyp .
  • repo-bundle - fasst beim Backup kleine Dateien zusammen, um Speicherplatz zu sparen und die Befehle backup und restore zu beschleunigen, insbesondere bei Objektspeichern wie S3. Die Option repo-bundle wurde in v2.39 eingeführt. Weitere Einzelheiten stehen unter Dateibündelung .
  • repo-block - speichert bei einem diff/incr-backup nur die geänderten Teile einer Datei statt der gesamten Datei. Das spart Speicherplatz und beschleunigt das backup. Die Option repo-block wurde in v2.46 eingeführt, empfohlen wird jedoch mindestens v2.52.1 . Weitere Einzelheiten stehen unter Inkrementelle Backups auf Blockebene .

Weitere Leistungsoptionen sind standardmäßig deaktiviert, weil sie zusätzliche Konfiguration erfordern oder weil der Standardwert sicher, aber nicht optimal ist. Diese Optionen stehen in allen v2-Versionen von pgBackRest zur Verfügung.

  • process-max - legt fest, wie viele Prozesse für Befehle verwendet werden. Der Standardwert ist 1 und fast nie angemessen. Jeder Befehl verwendet process-max anders; Einzelheiten zur Verwendung stehen daher in der jeweiligen Befehlsdokumentation.
  • archive-async - archiviert WAL-Dateien stapelweise im Repository und erhöht dadurch die Archivierungsgeschwindigkeit erheblich. Die Option ist standardmäßig deaktiviert, da ein Spool-Pfad angelegt werden muss. Weitere Einzelheiten stehen unter Asynchrone Archivierung .
  • backup-standby - führt das Backup auf einem Standby statt auf dem Primärserver durch, um dessen Last zu verringern. Die Option ist standardmäßig deaktiviert, da sie zusätzliche Konfiguration und mindestens einen Standby-Host erfordert. Weitere Einzelheiten stehen unter Backup von einem Standby .

Backup durchführen

Standardmäßig wartet pgBackRest vor dem Beginn eines Backups auf den nächsten regulär geplanten Checkpoint. Je nach den PostgreSQL-Einstellungen checkpoint_timeout und checkpoint_segments kann es recht lange dauern, bis ein Checkpoint abgeschlossen ist und das Backup beginnen kann. Im Allgemeinen empfiehlt sich start-fast=y, damit das Backup sofort beginnt. Dadurch wird ein Checkpoint erzwungen. Da Backups normalerweise einmal täglich durchgeführt werden, sollte ein zusätzlicher Checkpoint die Leistung jedoch nicht spürbar beeinflussen. Bei sehr stark ausgelasteten Clustern kann es dagegen besser sein, --start-fast bei Bedarf über die Befehlszeile zu übergeben.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Schnellen Backup-Start konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

Für ein Backup des PostgreSQL-Clusters pgBackRest mit dem Befehl backup ausführen.

pg-primary ⇒ Backup des Demo-Clusters erstellen

sudo -u postgres pgbackrest --stanza=demo \
       --log-level-console=info backup
P00   INFO: backup command begin 2.59.3: --exec-id=1327-e87cfc24 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo --start-fast
P00   WARN: no prior backup exists, incr backup has been changed to full
P00   INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 000000010000000000000002, lsn = 0/2000028
       [filtered 3 lines of output]
P00   INFO: check archive for segment(s) 000000010000000000000002:000000010000000000000003
P00   INFO: new backup label = 20261002-185647F
P00   INFO: full backup size = 25.2MB, file total = 951
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=1327-e87cfc24 --log-level-console=info --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo

Standardmäßig versucht pgBackRest, ein inkrementelles Backup durchzuführen. Ein inkrementelles Backup muss jedoch auf einem vollständigen Backup basieren. Da noch keines vorhanden war, hat pgBackRest stattdessen ein vollständiges Backup erstellt.

Mit der Option type lässt sich ein vollständiges oder differenzielles Backup angeben.

pg-primary ⇒ Differenzielles Backup des Demo-Clusters erstellen

sudo -u postgres pgbackrest --stanza=demo --type=diff \
       --log-level-console=info backup
       [filtered 7 lines of output]
P00   INFO: check archive for segment(s) 000000010000000000000004:000000010000000000000005
P00   INFO: new backup label = 20261002-185647F_20261002-185651D
P00   INFO: diff backup size = 9.2KB, file total = 951
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=1398-36e29fed --log-level-console=info --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo

Diesmal gab es keine Warnung, da bereits ein vollständiges Backup vorhanden war. Inkrementelle Backups können auf einem vollständigen oder differenziellen Backup basieren; differenzielle Backups müssen hingegen auf einem vollständigen Backup basieren. Ein vollständiges Backup lässt sich mit dem Befehl backup und der Option --type=full durchführen.

Bei einem Online-Backup wartet pgBackRest, bis die für die Konsistenz des Backups erforderlichen WAL-Segmente archiviert wurden. Diese Wartezeit wird durch die pgBackRest-Option archive-timeout bestimmt, deren Standardwert 60 Sekunden beträgt. Wenn die Archivierung eines einzelnen Segments bekanntermaßen länger dauert, sollte dieser Wert erhöht werden.

Backups planen

Backups können mit Werkzeugen wie cron geplant werden.

Im folgenden Beispiel werden zwei cron-Jobs eingerichtet: Vollständige Backups laufen sonntags um 6:30 Uhr morgens, differenzielle Backups montags bis samstags ebenfalls um 6:30 Uhr morgens. Wird diese crontab erstmals mitten in der Woche installiert, führt pgBackRest beim ersten Aufruf des differenziellen Jobs ein vollständiges Backup aus. Am folgenden Tag wird dann ein differenzielles Backup erstellt.

#m h   dom mon dow   command
30 06  *   *   0     pgbackrest --type=full --stanza=demo backup
30 06  *   *   1-6   pgbackrest --type=diff --stanza=demo backup

Nach dem Einrichten des Backup-Zeitplans ist es wichtig, auch die Aufbewahrung passend zu konfigurieren, damit Backups regelmäßig entfernt werden; siehe Aufbewahrung .

Backup-Informationen

Mit dem Befehl info lassen sich Informationen über Backups abrufen.

pg-primary ⇒ Informationen zum Demo-Cluster abrufen

sudo -u postgres pgbackrest info
stanza: demo
    status: ok
    cipher: aes-256-cbc

    db (current)
        wal archive min/max (14): 000000010000000000000001/000000010000000000000005

        full backup: 20261002-185647F
            timestamp start/stop: 2026-10-02 18:56:47+00 / 2026-10-02 18:56:50+00
            wal start/stop: 000000010000000000000002 / 000000010000000000000003
            database size: 25.2MB, database backup size: 25.2MB
            repo1: backup set size: 3.2MB, backup size: 3.2MB

        diff backup: 20261002-185647F_20261002-185651D
            timestamp start/stop: 2026-10-02 18:56:51+00 / 2026-10-02 18:56:52+00
            wal start/stop: 000000010000000000000004 / 000000010000000000000005
            database size: 25.2MB, database backup size: 9.2KB
            repo1: backup set size: 3.2MB, backup size: 864B
            backup reference total: 1 full

Der Befehl info arbeitet mit einer einzelnen Stanza oder allen Stanzas. Die standardmäßige Textausgabe bietet eine für Menschen lesbare Übersicht der Backups für die angeforderten Stanzas. Dieses Format kann sich mit jeder Version ändern.

Für maschinenlesbare Ausgabe --output=json verwenden. Die JSON-Ausgabe enthält wesentlich mehr Informationen als die Textausgabe und bleibt stabil, sofern kein Fehler gefunden wird.

Um die Ausführung zu beschleunigen, kann die Ausgabe mit --detail-level=progress auf Fortschrittsinformationen beschränkt werden. Dabei werden alle Prüfungen außer der Verfügbarkeit der Stanza übersprungen.

Jede Stanza hat einen eigenen Abschnitt. Mit der Option --stanza lässt sich die Ausgabe auf eine einzelne Stanza beschränken. Der ‘status’ gibt einen kurzen Überblick über den Zustand der Stanza. Bei ‘ok’ funktioniert pgBackRest normal. Bei mehreren Repositorys bedeutet der Status ‘mixed’, dass die Stanza in mindestens einem Repository nicht fehlerfrei ist; in diesem Fall wird ihr Zustand für jedes Repository einzeln angegeben. Tritt in einem Repository ein Fehler auf, der keinem bekannten Fehlercode entspricht, wird der Fehlercode ‘other’ verwendet und der Fehler vollständig beschrieben. ‘wal archive min/max’ zeigt das kleinste und das größte derzeit im Archiv gespeicherte WAL-Segment. Bei mehreren Repositorys bezieht sich diese Angabe auf alle Repositorys, sofern die Option --repo nicht gesetzt ist. Durch Regeln zur Archivaufbewahrung oder aus anderen Gründen können Lücken vorhanden sein.

Wenn einer dieser Befehle gerade auf dem Host läuft, erscheinen die Meldungen ‘backup/expire running’ und/oder ‘restore running’ neben der ‘status’-Angabe. Die Textausgabe enthält außerdem den Fortschritt pro Repository; in der JSON-Ausgabe wird ein ‘repo’-Array eingefügt.

Die Backups werden vom ältesten zum neuesten angezeigt. Das älteste Backup ist immer ein vollständiges Backup, gekennzeichnet durch ein F am Ende der Bezeichnung. Das neueste Backup kann vollständig, differenziell mit der Endung D oder inkrementell mit der Endung I sein.

‘timestamp start/stop’ gibt den Zeitraum an, in dem das Backup ausgeführt wurde. Mit ‘timestamp stop’ lässt sich bestimmen, welches Backup für eine Point-in-Time-Recovery verwendet werden soll. Weitere Informationen zur Point-in-Time-Recovery stehen im Abschnitt Point-in-Time-Recovery .

‘wal start/stop’ gibt den WAL-Bereich an, der benötigt wird, um die Datenbank bei der Wiederherstellung konsistent zu machen. Der Befehl backup stellt vor seinem Abschluss sicher, dass dieser WAL-Bereich im Archiv vorhanden ist.

‘database size’ ist die gesamte unkomprimierte Größe der Datenbank. ‘database backup size’ bezeichnet dagegen die tatsächlich zu sichernde Datenmenge in der Datenbank. Bei vollständigen Backups stimmen beide Werte überein.

‘repo’ gibt an, in welchem Repository sich das Backup befindet. ‘backup set size’ umfasst alle Dateien dieses Backups sowie aller referenzierten Backups im Repository, die benötigt werden, um die Datenbank aus diesem Backup wiederherzustellen. ‘backup size’ umfasst dagegen nur die Dateien dieses Backups. Bei vollständigen Backups stimmen auch diese Werte überein. Wenn in pgBackRest die Komprimierung aktiviert ist, geben die Repository-Größen die komprimierten Dateigrößen an.

‘backup reference total’ fasst die Liste der weiteren Backups zusammen, die zur Wiederherstellung dieses Backups benötigt werden. Mit der Option --set lässt sich die vollständige Referenzliste anzeigen.

Backup wiederherstellen

Backups können vor verschiedenen Ausfallszenarien schützen, insbesondere Hardwareausfällen und Datenbeschädigungen. Am einfachsten lässt sich eine Datenbeschädigung simulieren, indem eine wichtige Datei des PostgreSQL-Clusters entfernt wird.

pg-primary ⇒ Demo-Cluster stoppen und die Datei pg_control löschen

sudo systemctl stop postgresql-14.service
sudo -u postgres rm /var/lib/pgsql/14/data/global/pg_control

Beim Starten des Clusters ohne diese wichtige Datei tritt ein Fehler auf.

pg-primary ⇒ Start des beschädigten Demo-Clusters versuchen

sudo systemctl start postgresql-14.service
sudo systemctl status postgresql-14.service
postgresql-14.service - PostgreSQL 14 database server
    Loaded: loaded (/usr/lib/systemd/system/postgresql-14.service, disabled)
    Active: failed (failed)

Zur Wiederherstellung eines Backups des PostgreSQL-Clusters pgBackRest mit dem Befehl restore ausführen. Der Cluster muss gestoppt sein, was hier bereits der Fall ist, und alle Dateien müssen aus dem PostgreSQL-Datenverzeichnis entfernt werden.

pg-primary ⇒ Alte Dateien aus dem Demo-Cluster entfernen

sudo -u postgres find /var/lib/pgsql/14/data -mindepth 1 -delete

pg-primary ⇒ Demo-Cluster wiederherstellen und PostgreSQL starten

sudo -u postgres pgbackrest --stanza=demo restore
sudo systemctl start postgresql-14.service

Diesmal wurde der Cluster erfolgreich gestartet, da die Wiederherstellung die fehlende Datei pg_control ersetzt hat.

Weitere Informationen zum Befehl restore stehen im Abschnitt Wiederherstellung .

Überwachung

Die Überwachung ist ein wichtiger Bestandteil jedes Produktionssystems. Es stehen zahlreiche Werkzeuge zur Verfügung, und mit etwas Aufwand lässt sich pgBackRest mit jedem davon überwachen.

pgBackRest kann Informationen über das Repository im JSON-Format ausgeben. Dazu gehören eine Liste aller Backups jeder Stanza und Informationen zum WAL-Archiv.

In PostgreSQL

Mit dem PostgreSQL-Befehl COPY lassen sich pgBackRest-Informationen in eine Tabelle laden. Das folgende Beispiel kapselt diese Logik in einer Funktion, mit der Abfragen in Echtzeit durchgeführt werden können.

pg-primary ⇒ pgBackRest-Informationsfunktion für PostgreSQL laden

sudo -u postgres cat \
       /var/lib/pgsql/pgbackrest/doc/example/pgsql-pgbackrest-info.sql
-- An example of monitoring pgBackRest from within PostgreSQL
--
-- Use copy to export data from the pgBackRest info command into the jsonb
-- type so it can be queried directly by PostgreSQL.

-- Create monitor schema
create schema monitor;

-- Get pgBackRest info in JSON format
create function monitor.pgbackrest_info()
    returns jsonb AS $$
declare
    data jsonb;
begin
    -- Create a temp table to hold the JSON data
    create temp table temp_pgbackrest_data (data text);

    -- Copy data into the table directly from the pgBackRest info command
    copy temp_pgbackrest_data (data)
        from program
            'pgbackrest --output=json info' (format text);

    select replace(temp_pgbackrest_data.data, E'\n', '\n')::jsonb
      into data
      from temp_pgbackrest_data;

    drop table temp_pgbackrest_data;

    return data;
end $$ language plpgsql;
sudo -u postgres psql -f \
       /var/lib/pgsql/pgbackrest/doc/example/pgsql-pgbackrest-info.sql

Mit der Funktion monitor.pgbackrest_info() lassen sich nun der Zeitpunkt des letzten erfolgreichen Backups und das archivierte WAL einer Stanza ermitteln.

pg-primary ⇒ Zeitpunkt des letzten erfolgreichen Backups und archiviertes WAL abfragen

sudo -u postgres cat \
       /var/lib/pgsql/pgbackrest/doc/example/pgsql-pgbackrest-query.sql
-- Get last successful backup for each stanza
--
-- Requires the monitor.pgbackrest_info function.
with stanza as
(
    select data->'name' as name,
           data->'backup'->(
               jsonb_array_length(data->'backup') - 1) as last_backup,
           data->'archive'->(
               jsonb_array_length(data->'archive') - 1) as current_archive
      from jsonb_array_elements(monitor.pgbackrest_info()) as data
)
select name,
       to_timestamp(
           (last_backup->'timestamp'->>'stop')::numeric) as last_successful_backup,
       current_archive->>'max' as last_archived_wal
  from stanza;
sudo -u postgres psql -f \
       /var/lib/pgsql/pgbackrest/doc/example/pgsql-pgbackrest-query.sql
  name  | last_successful_backup |    last_archived_wal
--------+------------------------+--------------------------
 "demo" | 2026-10-02 18:56:52+00 | 000000010000000000000005
(1 row)

Backup

Wenn mehrere Repositorys konfiguriert sind, erstellt pgBackRest das Backup im Repository mit der höchsten Priorität, beispielsweise repo1, sofern die Option --repo nicht angegeben ist.

pgBackRest hat keine integrierte Zeitplanung. Daher empfiehlt es sich, pgBackRest über cron oder einen anderen Mechanismus zur Zeitplanung auszuführen.

Weitere Einzelheiten und Beispiele stehen unter Backup durchführen .

Dateibündelung

Das Bündeln von Dateien im Repository spart Zeit beim Backup und etwas Speicherplatz im Repository. Besonders deutlich ist dies bei Repositorys auf Objektspeichern wie S3 oder auf Dateisystemen mit großen Blockgrößen. Auf Objektspeichern dauert das Erstellen einer einzelnen Datei länger, und die Speicherung sehr kleiner Dateien kann genauso viel kosten wie die größerer Dateien.

Die Dateibündelung wird mit der Option repo-bundle aktiviert.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-bundle konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

Ein vollständiges Backup ohne Dateibündelung enthält 1000+ Dateien im Backup-Pfad. Mit Bündelung wird die Gesamtzahl der Dateien erheblich reduziert. Außerdem werden leere Dateien nur im Manifest erfasst und ansonsten nicht gespeichert, während bei einem normalen Backup jede leere Datei einzeln gespeichert wird.

pg-primary ⇒ Vollständiges Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=full backup

pg-primary ⇒ Gesamtzahl der Dateien prüfen

sudo -u postgres find /var/lib/pgbackrest/backup/demo/latest/ -type f | wc -l
5

Zur Optimierung können die Optionen repo-bundle-size und repo-bundle-limit verwendet werden. Die Standardwerte sollten jedoch in den meisten Fällen optimal sein.

Dateibündelung ist im Allgemeinen effizienter, erschwert jedoch das manuelle Abrufen von Dateien aus dem Repository. Für deduplizierten Speicher ist sie möglicherweise nicht ideal, da jedes vollständige Backup die Dateien in den Bündeln anders anordnet. Bei Dateibündeln ist außerdem keine Fortsetzung nach einer Unterbrechung möglich. Daher sollte repo-bundle-limit nicht zu hoch eingestellt werden.

Inkrementelle Backups auf Blockebene

Inkrementelle Backups auf Blockebene sparen Speicherplatz, indem sie nur die seit dem vorherigen Backup geänderten Teile einer Datei statt der gesamten Datei speichern.

Die Funktion für inkrementelle Backups auf Blockebene wird mit der Option repo-block aktiviert und funktioniert am besten, wenn sie für alle Backup-Typen aktiviert ist. Auch die Dateibündelung muss aktiviert sein.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-block konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

Backup-Annotationen

Benutzer können einem Backup informative Schlüssel-Wert-Paare hinzufügen. Diese Option kann mehrfach verwendet werden, um mehrere Annotationen anzufügen.

pg-primary ⇒ Vollständiges Backup mit Annotationen durchführen

sudo -u postgres pgbackrest --stanza=demo --annotation=source="demo backup" \
       --annotation=key=value --type=full backup

Annotationen erscheinen in der Textausgabe des Befehls info, wenn mit --set ein Backup angegeben wird. In der JSON-Ausgabe erscheinen sie immer.

pg-primary ⇒ Informationen zum Demo-Cluster abrufen

sudo -u postgres pgbackrest --stanza=demo --set=20261002-185708F info
stanza: demo
    status: ok
    cipher: aes-256-cbc

    db (current)
        wal archive min/max (14): 000000020000000000000007/000000020000000000000009

        full backup: 20261002-185708F
            timestamp start/stop: 2026-10-02 18:57:08+00 / 2026-10-02 18:57:09+00
            wal start/stop: 000000020000000000000008 / 000000020000000000000009
            lsn start/stop: 0/8000028 / 0/9000050
            database size: 25.2MB, database backup size: 25.2MB
            repo1: backup size: 3.2MB
            database list: postgres (13755)
            annotation(s)
                key: value
                source: demo backup

Annotationen, die mit dem Befehl backup hinzugefügt wurden, können anschließend mit dem Befehl annotate ergänzt, geändert oder entfernt werden.

pg-primary ⇒ Backup-Annotationen ändern

sudo -u postgres pgbackrest --stanza=demo --set=20261002-185708F \
       --annotation=key= --annotation=new_key=new_value annotate
sudo -u postgres pgbackrest --stanza=demo --set=20261002-185708F info
stanza: demo
    status: ok
    cipher: aes-256-cbc

    db (current)
        wal archive min/max (14): 000000020000000000000007/000000020000000000000009

        full backup: 20261002-185708F
            timestamp start/stop: 2026-10-02 18:57:08+00 / 2026-10-02 18:57:09+00
            wal start/stop: 000000020000000000000008 / 000000020000000000000009
            lsn start/stop: 0/8000028 / 0/9000050
            database size: 25.2MB, database backup size: 25.2MB
            repo1: backup size: 3.2MB
            database list: postgres (13755)
            annotation(s)
                new_key: new_value
                source: demo backup

Aufbewahrung

Im Allgemeinen empfiehlt es sich, möglichst viele Backups aufzubewahren, um ein größeres Zeitfenster für die Point-in-Time-Recovery zu erhalten. Dabei müssen jedoch auch praktische Einschränkungen wie der verfügbare Speicherplatz berücksichtigt werden. Aufbewahrungsoptionen entfernen ältere Backups, sobald sie nicht mehr benötigt werden.

pgBackRest rotiert vollständige Backups anhand des Aufbewahrungstyps, der eine Anzahl oder einen Zeitraum festlegen kann. Bei einer Anzahl hängt das Entfernen nicht vom Erstellungszeitpunkt der Backups ab, sondern davon, wie viele aufbewahrt werden müssen. Differenzielle Backups werden nach Anzahl aufbewahrt, jedoch immer entfernt, wenn das vollständige Backup entfernt wird, von dem sie abhängen. Inkrementelle Backups werden durch die Aufbewahrungsregeln nie eigenständig entfernt, sondern immer zusammen mit dem zugehörigen vollständigen oder differenziellen Backup. Einzelheiten und Beispiele stehen unter Aufbewahrung vollständiger Backups und Aufbewahrung differenzieller Backups .

Archiviertes WAL wird standardmäßig für alle noch nicht entfernten Backups aufbewahrt. Diese Regel kann pro Repository mit den Optionen retention-archive geändert werden, was jedoch nicht empfohlen wird. Einzelheiten und Beispiele stehen unter Archivaufbewahrung .

Der Befehl expire wird nach jedem erfolgreichen Backup automatisch ausgeführt und kann auch vom Benutzer aufgerufen werden. Bei einem manuellen Aufruf erfolgt das Entfernen gemäß den Aufbewahrungseinstellungen jedes konfigurierten Repositorys. Wenn die Option --repo angegeben ist, wird nur das angegebene Repository bereinigt. Der Benutzer kann das Entfernen mit der Option --set auch auf einen bestimmten Backup-Satz beschränken. Sofern --repo nicht angegeben ist, werden alle Repositorys durchsucht und alle dem angegebenen Satz entsprechenden Backups entfernt. Die Regeln zur Archivaufbewahrung werden bei jedem Aufruf von expire geprüft und angewendet.

Aufbewahrung vollständiger Backups

repo1-retention-full-type bestimmt, ob die Option repo1-retention-full als Anzahl aufzubewahrender vollständiger Backups oder als Anzahl von Tagen ihrer Aufbewahrung interpretiert wird. Neue Backups müssen abgeschlossen sein, bevor Backups entfernt werden. Bei repo1-retention-full-type=count und repo1-retention-full=2 sind daher drei vollständige Backups gespeichert, bevor das älteste entfernt wird. Bei repo1-retention-full-type=time und repo1-retention-full=20 muss ein vollständiges Backup vorhanden sein, das mindestens 20 Tage alt ist, bevor Backups entfernt werden können.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-retention-full konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

Für Backups gilt repo1-retention-full=2. Derzeit gibt es jedoch nur ein vollständiges Backup, sodass beim nächsten vollständigen Backup noch keines entfernt wird.

pg-primary ⇒ Vollständiges Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=full \
       --log-level-console=detail backup
       [filtered 963 lines of output]
P00   INFO: repo1: remove expired backup 20261002-185706F
P00 DETAIL: repo1: 14-1 archive retention on backup 20261002-185708F, start = 000000020000000000000008
P00   INFO: repo1: 14-1 remove archive, start = 000000020000000000000007, stop = 000000020000000000000007
P00   INFO: expire command end: completed successfully

Archivdaten werden hingegen entfernt, da WAL-Segmente vor dem ältesten Backup erzeugt wurden. Diese sind für eine Recovery nicht nutzbar. Nur WAL-Segmente, die nach einem Backup erzeugt wurden, können für dessen Recovery verwendet werden.

pg-primary ⇒ Vollständiges Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=full \
       --log-level-console=info backup
       [filtered 11 lines of output]
P00   INFO: repo1: expire full backup 20261002-185708F
P00   INFO: repo1: remove expired backup 20261002-185708F
P00   INFO: repo1: 14-1 remove archive, start = 000000020000000000000008, stop = 000000020000000000000009
P00   INFO: expire command end: completed successfully

Das vollständige Backup 20261002-185647F wird entfernt. Die Archivaufbewahrung richtet sich nun nach 20261002-185711F, dem jetzt ältesten vollständigen Backup.

Aufbewahrung differenzieller Backups

repo1-retention-diff auf die benötigte Anzahl differenzieller Backups setzen. Differenzielle Backups hängen nur vom vorherigen vollständigen Backup ab. Daher lässt sich ein fortlaufend erneuerter Satz differenzieller Backups für den letzten Tag oder länger erstellen. Dies ermöglicht schnelle Wiederherstellungen auf kürzlich vergangene Zeitpunkte und verringert gleichzeitig den gesamten Speicherbedarf.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-retention-diff konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=1

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

Für Backups gilt repo1-retention-diff=1, sodass zwei differenzielle Backups durchgeführt werden müssen, bevor eines entfernt wird. Zusätzlich wird ein inkrementelles Backup erstellt, um dessen Entfernung zu demonstrieren. Diese hängt hier von der Entfernung des differenziellen Backups ab.

pg-primary ⇒ Differenzielle und inkrementelle Backups durchführen

sudo -u postgres pgbackrest --stanza=demo --type=diff backup
sudo -u postgres pgbackrest --stanza=demo --type=incr backup

Ein weiteres differenzielles Backup entfernt nun das vorherige differenzielle und das inkrementelle Backup, sodass nur ein differenzielles Backup übrig bleibt.

pg-primary ⇒ Differenzielles Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=diff \
       --log-level-console=info backup
       [filtered 10 lines of output]
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=2641-6abf9293 --log-level-console=info --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-diff=1 --repo1-retention-full=2 --stanza=demo
P00   INFO: repo1: expire diff backup set 20261002-185713F_20261002-185715D, 20261002-185713F_20261002-185716I
P00   INFO: repo1: remove expired backup 20261002-185713F_20261002-185716I
P00   INFO: repo1: remove expired backup 20261002-185713F_20261002-185715D
P00   INFO: expire command end: completed successfully

Archivaufbewahrung

pgBackRest entfernt archivierte WAL-Segmente automatisch beim Entfernen von Backups. Standardmäßig wird WAL für vollständige Backups anhand der Option repo1-retention-full entfernt. Um Speicherplatz zu sparen, kann es dennoch sinnvoll sein, Archivdaten früher zu entfernen. Für die differenzielle Archivaufbewahrung werden vollständige Backups wie differenzielle Backups behandelt.

Beim Entfernen von Archivdaten werden niemals WAL-Segmente entfernt, die für die Konsistenz eines Backups erforderlich sind. Point-in-Time-Recovery (PITR) funktioniert jedoch nur mit einem lückenlosen WAL-Strom. Daher ist Vorsicht geboten, wenn Archivdaten außerhalb der normalen Backup-Bereinigung besonders früh entfernt werden. Um zu ermitteln, was entfernt würde, ohne tatsächlich etwas zu entfernen, kann dem Befehl expire auf der Befehlszeile die Option dry-run übergeben werden.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-retention-diff konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=2

repo1-retention-full=2

start-fast=y



[global:archive-push]

compress-level=3

pg-primary ⇒ Differenzielles Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=diff \
       --log-level-console=info backup
       [filtered 6 lines of output]
P00   INFO: backup stop archive = 000000020000000000000017, lsn = 0/17000050
P00   INFO: check archive for segment(s) 000000020000000000000016:000000020000000000000017
P00   INFO: new backup label = 20261002-185713F_20261002-185719D
P00   INFO: diff backup size = 11.5KB, file total = 951
P00   INFO: backup command end: completed successfully
       [filtered 2 lines of output]

pg-primary ⇒ Archiv bereinigen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=detail \
       --repo1-retention-archive-type=diff --repo1-retention-archive=1 expire
P00   INFO: expire command begin 2.59.3: --exec-id=2877-3548ad61 --log-level-console=detail --no-log-timestamp --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-archive=1 --repo1-retention-archive-type=diff --repo1-retention-diff=2 --repo1-retention-full=2 --stanza=demo
P00 DETAIL: repo1: 14-1 archive retention on backup 20261002-185711F, start = 00000002000000000000000A, stop = 00000002000000000000000B
P00 DETAIL: repo1: 14-1 archive retention on backup 20261002-185713F, start = 00000002000000000000000C, stop = 00000002000000000000000D
P00 DETAIL: repo1: 14-1 archive retention on backup 20261002-185713F_20261002-185717D, start = 000000020000000000000012, stop = 000000020000000000000013
P00 DETAIL: repo1: 14-1 archive retention on backup 20261002-185713F_20261002-185719D, start = 000000020000000000000016
P00   INFO: repo1: 14-1 remove archive, start = 00000002000000000000000E, stop = 000000020000000000000011
P00   INFO: repo1: 14-1 remove archive, start = 000000020000000000000014, stop = 000000020000000000000015
P00   INFO: expire command end: completed successfully

Zum differenziellen Backup 20261002-185713F_20261002-185717D gehören archivierte WAL-Segmente, die aufbewahrt werden müssen, um die älteren Backups konsistent zu machen, auch wenn diese mit PITR nicht weiter vorwärts abgespielt werden können. WAL-Segmente, die nach 20261002-185713F_20261002-185717D, aber vor 20261002-185713F_20261002-185719D erzeugt wurden, werden entfernt. WAL-Segmente nach dem neuen Backup 20261002-185713F_20261002-185719D bleiben erhalten und können für PITR verwendet werden.

Da vollständige Backups für die differenzielle Archivaufbewahrung als differenzielle Backups gelten, bleibt bei einem nun mit denselben Einstellungen durchgeführten vollständigen Backup nur dessen Archiv für PITR erhalten.

Wiederherstellung

Der Befehl restore wählt standardmäßig automatisch das neueste Backup aus dem ersten Repository aus, in dem Backups vorhanden sind; siehe Schnellstart – Backup wiederherstellen . Die Prüfreihenfolge der Repositorys wird durch pgbackrest.conf bestimmt; beispielsweise wird repo1 vor repo2 geprüft. Mit der Option --repo, etwa --repo=1, lässt sich ein bestimmtes Repository auswählen. Wenn ein anderes als das neueste Backup gewünscht ist, kann die Option --set angegeben werden.

Bei PITR mit --type=time oder --type=lsn muss die Zielzeit bzw. die Ziel-LSN mit der Option --target angegeben werden. Ohne --set werden die konfigurierten Repositorys der Reihe nach nach einem Backup durchsucht, dessen Endzeit vor der Zielzeit liegt bzw. dessen End-LSN kleiner oder gleich der Ziel-LSN ist. Wird kein passendes Backup gefunden, meldet pgBackRest sowohl bei --type=time als auch bei --type=lsn einen Fehler; es fällt nicht auf das neueste Backup zurück. Bei anderen PITR-Typen, z. B. xid, muss die Option --set angegeben werden, wenn das Ziel vor dem neuesten Backup liegt. Weitere Informationen und Beispiele finden Sie unter Point-in-Time-Recovery .

Replikations-Slots werden gemäß der Empfehlung von PostgreSQL nicht eingeschlossen. Weitere Informationen stehen unter Backup des Datenverzeichnisses in der PostgreSQL-Dokumentation.

Die folgenden Abschnitte stellen weitere Funktionen des Befehls restore vor.

Dateieigentümer

Wird restore unter einem anderen Benutzer als root ausgeführt, was der übliche Fall ist, gehören alle wiederhergestellten Dateien dem Benutzer und der Gruppe, unter denen pgBackRest ausgeführt wird. Gehören vorhandene Dateien einem anderen Benutzer oder einer anderen Gruppe, tritt ein Fehler auf, wenn der Eigentümer nicht auf den ausführenden Benutzer beziehungsweise die ausführende Gruppe geändert werden kann. In diesem Fall muss ein privilegierter Benutzer die Dateieigentümer anpassen, bevor die Wiederherstellung erneut versucht werden kann.

Wird restore als Benutzer root ausgeführt, versucht pgBackRest, die beim Backup im Manifest gespeicherten Eigentümer wiederherzustellen. Das Manifest speichert nur die Namen von Benutzern und Gruppen. Damit dies funktioniert, müssen auf dem Wiederherstellungshost dieselben Namen existieren. Wird ein Benutzer- oder Gruppenname lokal nicht gefunden, wird der Benutzer beziehungsweise die Gruppe des PostgreSQL-Datenverzeichnisses verwendet. Lässt sich auch dessen Benutzer oder Gruppe keinem Namen zuordnen, wird letztlich root verwendet.

Delta-Option

Unter Backup wiederherstellen im Schnellstart musste das Datenbankcluster-Verzeichnis vor der Ausführung von restore geleert werden. Mit der Option delta ermittelt pgBackRest automatisch, welche Dateien in diesem Verzeichnis erhalten bleiben können und welche aus dem Backup wiederhergestellt werden müssen. Außerdem entfernt es Dateien, die nicht im Backup-Manifest stehen, und beseitigt so abweichende Änderungen. Dazu wird für jede Datei im Datenbankcluster-Verzeichnis ein kryptografischer SHA-1 -Hash berechnet. Stimmt der SHA-1-Hash nicht mit dem im Backup gespeicherten Hash überein, wird die Datei wiederhergestellt. In Verbindung mit der Option process-max ist dieses Verfahren sehr effizient. Da der PostgreSQL-Server während der Wiederherstellung gestoppt ist, können mehr Prozesse verwendet werden als während eines Backups bei laufendem PostgreSQL-Server sinnvoll wären.

pg-primary ⇒ Demo-Cluster stoppen und Delta-Wiederherstellung durchführen

sudo systemctl stop postgresql-14.service
sudo -u postgres pgbackrest --stanza=demo --delta \
       --log-level-console=detail restore
       [filtered 2 lines of output]
P00 DETAIL: check '/var/lib/pgsql/14/data' exists
P00 DETAIL: remove 'global/pg_control' so cluster will not start if restore does not complete
P00   INFO: remove invalid files/links/paths from '/var/lib/pgsql/14/data'
P00 DETAIL: remove invalid file '/var/lib/pgsql/14/data/backup_label.old'
P00 DETAIL: remove invalid file '/var/lib/pgsql/14/data/base/13755/pg_internal.init'
       [filtered 996 lines of output]

pg-primary ⇒ PostgreSQL neu starten

sudo systemctl start postgresql-14.service

Ausgewählte Datenbanken wiederherstellen

In manchen Fällen sollen gezielt einzelne Datenbanken aus einem Cluster-Backup wiederhergestellt werden. Gründe dafür können die Leistung sein oder der Wunsch, ausgewählte Datenbanken auf einen Rechner zu verschieben, dessen Speicherplatz für die Wiederherstellung des gesamten Cluster-Backups nicht ausreicht.

Zur Demonstration werden zwei Datenbanken erstellt: test1 und test2.

pg-primary ⇒ Zwei Testdatenbanken erstellen

sudo -u postgres psql -c "create database test1;"
CREATE DATABASE
sudo -u postgres psql -c "create database test2;"
CREATE DATABASE

Jede Testdatenbank wird mit Tabellen und Daten gefüllt, um zu zeigen, dass die Recovery bei einer selektiven Wiederherstellung funktioniert.

pg-primary ⇒ In jeder Datenbank eine Testtabelle erstellen

sudo -u postgres psql -c "create table test1_table (id int); \
       insert into test1_table (id) values (1);" test1
CREATE TABLE
INSERT 0 1
sudo -u postgres psql -c "create table test2_table (id int); \
       insert into test2_table (id) values (2);" test2
CREATE TABLE
INSERT 0 1

Ein neues Backup wird durchgeführt, damit pgBackRest die neuen Datenbanken kennt.

pg-primary ⇒ Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=incr backup

Ein wesentlicher Grund für die selektive Wiederherstellung ist die Einsparung von Speicherplatz. Hier wird die Größe der Datenbank test1 angezeigt, um sie nach der selektiven Wiederherstellung mit deren Speicherbelegung vergleichen zu können.

pg-primary ⇒ Speicherbelegung der Datenbank test1 anzeigen

sudo -u postgres du -sh /var/lib/pgsql/14/data/base/32768
8.4M	/var/lib/pgsql/14/data/base/32768

Ist die wiederherzustellende Datenbank nicht bekannt, lassen sich mit der Option set des Befehls info die im Backup-Satz enthaltenen Datenbanken ermitteln.

pg-primary ⇒ Datenbankliste des Backups anzeigen

sudo -u postgres pgbackrest --stanza=demo \
       --set=20261002-185713F_20261002-185728I info
       [filtered 12 lines of output]
            repo1: backup size: 2.1MB
            backup reference list: 20261002-185713F, 20261002-185713F_20261002-185719D
            database list: postgres (13755), test1 (32768), test2 (32769)

Den Cluster stoppen und nur die Datenbank test2 wiederherstellen. Die eingebauten Datenbanken template0, template1 und postgres werden immer wiederhergestellt.

WARNUNG:

Ohne --type=immediate kann die Recovery mit einem Fehler abbrechen. Sobald Konsistenz erreicht ist, meldet PostgreSQL mit Nullen gefüllte Seiten als Fehler, auch bei einem Schreibvorgang für eine vollständige Seite. Für PostgreSQL ≥ 13 kann die Einstellung ignore_invalid_pages verwendet werden, um ungültige Seiten zu ignorieren. In diesem Fall ist es wichtig, die Protokolle nach der Recovery zu prüfen, um sicherzustellen, dass in den ausgewählten Datenbanken keine ungültigen Seiten gemeldet wurden.

pg-primary ⇒ Aus dem letzten Backup nur die Datenbank test2 wiederherstellen

sudo systemctl stop postgresql-14.service
sudo -u postgres pgbackrest --stanza=demo --delta \
       --db-include=test2 --type=immediate --target-action=promote restore
sudo systemctl start postgresql-14.service

Nach Abschluss der Recovery enthält die Datenbank test2 alle zuvor erstellten Tabellen und Daten.

pg-primary ⇒ Erfolgreiche Recovery der Datenbank test2 zeigen

sudo -u postgres psql -c "select * from test2_table;" test2
 id
----
  2
(1 row)

Trotz erfolgreicher Recovery ist die Datenbank test1 nicht zugänglich. Sie wurde vollständig als mit Nullen gefüllte Sparse-Dateien wiederhergestellt. PostgreSQL kann WAL erfolgreich auf diese Dateien anwenden. Die Datenbank als Ganzes ist jedoch ungültig, da wichtige Dateien keine Daten enthalten. Dies ist beabsichtigt: Es verhindert die versehentliche Verwendung einer Datenbank, die möglicherweise nur unvollständige, während der WAL-Wiedergabe angewendete Daten enthält.

pg-primary ⇒ Verbindungsversuch mit der Datenbank test1 führt zu einem Fehler

sudo -u postgres psql -c "select * from test1_table;" test1
psql: error: connection to server on socket "/run/postgresql/.s.PGSQL.5432" failed: FATAL:  relation mapping file "base/32768/pg_filenode.map" contains invalid data

Da die Datenbank test1 als mit Nullen gefüllte Sparse-Dateien wiederhergestellt wird, benötigt sie nur so viel Speicherplatz wie die während der Recovery geschriebene WAL-Menge. Die während eines Backups erzeugte und bei der Recovery angewendete WAL-Menge kann beträchtlich sein, macht aber in der Regel nur einen kleinen Teil der gesamten Datenbankgröße aus. Das gilt insbesondere für große Datenbanken, bei denen diese Funktion am ehesten nützlich ist.

Die Datenbank test1 belegt bei der selektiven Wiederherstellung deutlich weniger Speicherplatz, als sie bei einer vollständigen Wiederherstellung benötigt hätte.

pg-primary ⇒ Speicherbelegung der Datenbank test1 nach der Recovery anzeigen

sudo -u postgres du -sh /var/lib/pgsql/14/data/base/32768
8.0K	/var/lib/pgsql/14/data/base/32768

Die einzige mögliche Aktion für die ungültige Datenbank test1 ist nun drop database. pgBackRest löscht die Datenbank nicht automatisch, da dies erst nach Abschluss der Recovery und bei zugänglichem Cluster möglich ist.

pg-primary ⇒ Datenbank test1 löschen

sudo -u postgres psql -c "drop database test1;"
DROP DATABASE

Nach dem Löschen der ungültigen Datenbank test1 bleiben nur test2 und die eingebauten Datenbanken übrig.

pg-primary ⇒ Verbleibende Datenbanken auflisten

sudo -u postgres psql -c "select oid, datname from pg_database order by oid;"
  oid  |  datname
-------+-----------
     1 | template1
 13754 | template0
 13755 | postgres
 32769 | test2
(4 rows)

Point-in-Time-Recovery

Unter Backup wiederherstellen im Schnellstart wurde die standardmäßige Recovery durchgeführt, die den WAL-Strom bis zu seinem Ende wiedergibt. Bei einem Hardwareausfall ist dies normalerweise die beste Wahl. Bei Datenbeschädigungen, ob durch technische Fehler oder menschliches Handeln verursacht, ist dagegen häufig eine Point-in-Time-Recovery (PITR) geeigneter.

Point-in-Time-Recovery (PITR) ermöglicht es, das WAL ausgehend von einem Backup bis zu einer bestimmten LSN, einem Zeitpunkt, einer Transaktions-ID oder einem Recovery-Punkt wiederzugeben. Für übliche Recovery-Szenarien ist die zeitbasierte Recovery wohl am nützlichsten. Ein typischer Fall ist die Wiederherstellung einer versehentlich gelöschten Tabelle oder versehentlich gelöschter Daten. Da die Recovery einer gelöschten Tabelle anschaulicher ist, wird sie hier als Beispiel verwendet. Gelöschte Daten würden jedoch genauso wiederhergestellt.

pg-primary ⇒ Tabelle mit sehr wichtigen Daten erstellen

sudo -u postgres psql -c "begin; \
       create table important_table (message text); \
       insert into important_table values ('Important Data'); \
       commit; \
       select * from important_table;"
       [filtered 4 lines of output]
    message
----------------
 Important Data
(1 row)

Es ist wichtig, die Zeit so anzugeben, wie PostgreSQL sie erfasst, und den Zeitzonenversatz einzubeziehen. Das verringert das Risiko unbeabsichtigter Zeitzonenumrechnungen und eines unerwarteten Recovery-Ergebnisses.

pg-primary ⇒ Zeit von PostgreSQL abrufen

sudo -u postgres psql -Atc "select current_timestamp"
2026-10-02 18:57:39.575732+00

Nachdem der Zeitpunkt festgehalten wurde, wird die Tabelle gelöscht. In der Praxis ist es wesentlich schwieriger als in diesem Beispiel, den genauen Zeitpunkt der Löschung zu ermitteln. Er lässt sich möglicherweise nicht exakt feststellen, doch eine Untersuchung der verfügbaren Spuren sollte eine gute Annäherung ermöglichen.

pg-primary ⇒ Wichtige Tabelle löschen

sudo -u postgres psql -c "begin; \
       drop table important_table; \
       commit; \
       select * from important_table;"
BEGIN
DROP TABLE
COMMITERROR:  relation "important_table" does not exist
LINE 1: ...le important_table;     commit;     select * from important_...
                                                             ^

Wird für die Wiederherstellung das falsche Backup gewählt, schlägt die Recovery bis zur gewünschten Zielzeit fehl. Zur Demonstration wird ein neues inkrementelles Backup durchgeführt, in dem important_table nicht existiert.

pg-primary ⇒ Inkrementelles Backup durchführen

sudo -u postgres pgbackrest --stanza=demo --type=incr backup
sudo -u postgres pgbackrest info
       [filtered 38 lines of output]
            backup reference total: 1 full, 1 diff

        incr backup: 20261002-185713F_20261002-185741I
            timestamp start/stop: 2026-10-02 18:57:41+00 / 2026-10-02 18:57:42+00
            wal start/stop: 00000004000000000000001A / 00000004000000000000001A
       [filtered 2 lines of output]

Aus diesem Backup lässt sich die verlorene Tabelle nicht wiederherstellen, da PostgreSQL nur vorwärts und nicht rückwärts wiedergeben kann.

pg-primary ⇒ Recovery aus einem ungeeigneten Backup versuchen

sudo systemctl stop postgresql-14.service
sudo -u postgres pgbackrest --stanza=demo --delta \
       --set=20261002-185713F_20261002-185741I --target-timeline=current \
       --type=time "--target=2026-10-02 18:57:39.575732+00" --target-action=promote restore
sudo systemctl start postgresql-14.service
sudo -u postgres cat /var/lib/pgsql/14/data/log/postgresql.log
       [filtered 11 lines of output]
LOG:  database system is ready to accept read-only connections
LOG:  redo done at 0/1A000100 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.01 s
FATAL:  recovery ended before configured recovery target was reached
LOG:  startup process (PID 4045) exited with exit code 1
LOG:  terminating any other active server processes
LOG:  database system is shut down

Zuverlässig ist es, pgBackRest automatisch ein Backup auswählen zu lassen, das eine Recovery bis zur Zielzeit ermöglicht, also ein Backup, das vor dem angegebenen Zeitpunkt endete.

HINWEIS:

Beim Wiederherstellungstyp xid oder name kann pgBackRest das Backup nicht automatisch auswählen.

pg-primary ⇒ Demo-Cluster auf 2026-10-02 18:57:39.575732+00 wiederherstellen

sudo -u postgres pgbackrest --stanza=demo --delta \
       --type=time "--target=2026-10-02 18:57:39.575732+00" \
       --target-action=promote restore
sudo -u postgres cat /var/lib/pgsql/14/data/postgresql.auto.conf
       [filtered 9 lines of output]
# Recovery settings generated by pgBackRest restore on 2026-10-02 18:57:47
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
recovery_target_time = '2026-10-02 18:57:39.575732+00'
recovery_target_action = 'promote'

pgBackRest hat die Recovery-Einstellungen in postgresql.auto.conf geschrieben, sodass PostgreSQL sofort gestartet werden kann. Mit %f gibt PostgreSQL das benötigte WAL-Segment an, mit %p den Speicherort, an den es kopiert werden soll. Sobald PostgreSQL die Recovery abgeschlossen hat, existiert die Tabelle wieder und kann abgefragt werden.

pg-primary ⇒ PostgreSQL starten und prüfen, ob die wichtige Tabelle existiert

sudo systemctl start postgresql-14.service
sudo -u postgres psql -c "select * from important_table"
    message
----------------
 Important Data
(1 row)

Auch das PostgreSQL-Protokoll enthält wertvolle Informationen. Es nennt den Zeitpunkt und die Transaktion, bei der die Recovery gestoppt wurde, sowie den Zeitpunkt der zuletzt angewendeten Transaktion.

pg-primary ⇒ PostgreSQL-Protokollausgabe untersuchen

sudo -u postgres cat /var/lib/pgsql/14/data/log/postgresql.log
       [filtered 5 lines of output]
LOG:  database system was interrupted; last known up at 2026-10-02 18:57:28 UTC
LOG:  restored log file "00000004.history" from archive
LOG:  starting point-in-time recovery to 2026-10-02 18:57:39.575732+00
LOG:  restored log file "00000004.history" from archive
LOG:  restored log file "000000040000000000000019" from archive
       [filtered 2 lines of output]
LOG:  consistent recovery state reached at 0/19000100
LOG:  database system is ready to accept read-only connections
LOG:  recovery stopping before commit of transaction 743, time 2026-10-02 18:57:40.904112+00
LOG:  redo done at 0/1901E6C0 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
LOG:  last completed transaction was at log time 2026-10-02 18:57:38.228184+00
LOG:  selected new timeline ID: 5
LOG:  archive recovery complete
LOG:  database system is ready to accept connections

Stanza löschen

Der Befehl stanza-delete entfernt die zu einer Stanza gehörenden Daten aus dem Repository.

WARNUNG:

Diesen Befehl mit Vorsicht verwenden: Er entfernt dauerhaft alle Backups und Archive der angegebenen Stanza aus dem pgBackRest-Repository.

Zum Löschen einer Stanza:

  • Den PostgreSQL-Cluster stoppen, der zur Stanza gehört, oder diese Vorgabe mit –force übergehen.
  • Den Befehl stop auf dem Host ausführen, auf dem stanza-delete ausgeführt werden soll.
  • Den Befehl stanza-delete ausführen.

Nach dem erfolgreichen Abschluss des Befehls ist der Benutzer dafür verantwortlich, die Stanza aus allen pgBackRest-Konfigurationsdateien und/oder Umgebungsvariablen zu entfernen.

Eine Stanza kann jeweils nur aus einem Repository gelöscht werden. Zum Löschen aus mehreren Repositorys den Befehl stanza-delete für jedes Repository wiederholen und dabei die Option --repo angeben.

pg-primary ⇒ Zu entfernenden PostgreSQL-Cluster stoppen

sudo systemctl stop postgresql-14.service

pg-primary ⇒ pgBackRest für die Stanza stoppen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stop
P00   INFO: stop command begin 2.59.3: --exec-id=4396-32c67a63 --log-level-console=info --no-log-timestamp --stanza=demo
P00   INFO: stop command end: completed successfully

pg-primary ⇒ Stanza aus einem Repository löschen

sudo -u postgres pgbackrest --stanza=demo --repo=1 \
       --log-level-console=info stanza-delete
P00   INFO: stanza-delete command begin 2.59.3: --exec-id=4428-6f4dadb2 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --repo=1 --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo
P00   INFO: stanza-delete command end: completed successfully

Mehrere Repositorys

Es können mehrere Repositorys konfiguriert werden, wie unter S3-Unterstützung gezeigt. Ein möglicher Vorteil ist die Kombination eines lokalen Repositorys für schnelle Wiederherstellungen mit einem entfernten Repository für Redundanz.

Einige Befehle, etwa stanza-create /stanza-upgrade , arbeiten automatisch mit allen konfigurierten Repositorys. Andere, etwa stanza-delete , erfordern die Angabe eines Repositorys über die Option repo.

Ist nur repo1 konfiguriert, wird die Option repo zur Wahrung der Abwärtskompatibilität nicht benötigt. Ist dagegen ein einzelnes Repository beispielsweise als repo2 konfiguriert, ist die Option repo erforderlich. Dadurch wird verhindert, dass Befehle nicht mehr funktionieren, wenn später ein weiteres Repository hinzukommt.

Der Befehl archive-push überträgt WAL immer in das Archiv aller konfigurierten Repositorys. Ist ein Repository nicht erreichbar, wird WAL weiterhin an die anderen Repositorys übertragen. Damit dies wirksam funktioniert, muss jedoch archive-async=y aktiviert sein; andernfalls können die anderen Repositorys dem nicht erreichbaren Repository nur um ein WAL-Segment voraus sein. Kann WAL in keines der Repositorys übertragen werden, entfernt PostgreSQL es nicht aus dem Verzeichnis pg_wal. Dadurch kann der Speicherplatz des Volumes erschöpft werden.

Backups müssen für jedes Repository einzeln geplant werden. Häufig ist das erwünscht, da sich Backup-Typen und Aufbewahrung je nach Repository unterscheiden. Ebenso muss bei Wiederherstellungen ein Repository angegeben werden. Im Allgemeinen empfiehlt sich dafür ein Repository mit geringer Latenz und niedrigen Kosten, auch wenn die Recovery dadurch länger dauert. Welches Repository am effizientesten ist, lässt sich nur durch Wiederherstellungstests ermitteln.

Unterstützung für Azure-kompatible Objektspeicher

pgBackRest unterstützt Repositorys in Azure-kompatiblen Objektspeichern. Der Container für das Repository muss vorab erstellt werden; pgBackRest legt ihn nicht automatisch an. Das Repository kann im Stammverzeichnis des Containers (/) liegen. Meist empfiehlt sich jedoch ein Unterpfad, damit Objektspeicherprotokolle oder andere Daten ohne Konflikte im selben Container gespeichert werden können.

WARNUNG:

„Hierarchischer Namespace“ nicht aktivieren, da dies bei expire zu Fehlern führt.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Azure konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=2

repo1-retention-full=2

repo2-azure-account=pgbackrest

repo2-azure-container=demo-container

repo2-azure-key=YXpLZXk=

repo2-path=/demo-repo

repo2-retention-full=4

repo2-type=azure

start-fast=y



[global:archive-push]

compress-level=3

Shared Access Signatures können verwendet werden, indem die Option repo2-azure-key-type auf sas und repo2-azure-key auf das Shared-Access-Signature-Token gesetzt wird.

Die Befehle werden genauso ausgeführt, als läge das Repository auf einem lokalen Datenträger.

pg-primary ⇒ Stanza erstellen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create
P00   INFO: stanza-create command begin 2.59.3: --exec-id=4635-4a99c6c0 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo2-type=azure --stanza=demo
P00   INFO: stanza-create for stanza 'demo' on repo1
P00   INFO: stanza-create for stanza 'demo' on repo2
P00   INFO: stanza-create command end: completed successfully

Da das Erstellen von Dateien in Azure relativ langsam ist, verbessert die Aktivierung der Dateibündelung die Leistung von backup/restore.

pg-primary ⇒ Backup des Demo-Clusters erstellen

sudo -u postgres pgbackrest --stanza=demo --repo=2 \
       --log-level-console=info backup
P00   INFO: backup command begin 2.59.3: --exec-id=4667-a84748a5 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --repo=2 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-block --repo1-bundle --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo2-type=azure --stanza=demo --start-fast
P00   WARN: no prior backup exists, incr backup has been changed to full
P00   INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 00000005000000000000001B, lsn = 0/1B000028
       [filtered 3 lines of output]
P00   INFO: check archive for segment(s) 00000005000000000000001B:00000005000000000000001B
P00   INFO: new backup label = 20261002-185802F
P00   INFO: full backup size = 33.5MB, file total = 1249
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=4667-a84748a5 --log-level-console=info --no-log-timestamp --repo=2 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo2-type=azure --stanza=demo

Unterstützung für S3-kompatible Objektspeicher

pgBackRest unterstützt Repositorys in S3-kompatiblen Objektspeichern. Der Bucket für das Repository muss vorab erstellt werden; pgBackRest legt ihn nicht automatisch an. Das Repository kann im Stammverzeichnis des Buckets (/) liegen. Meist empfiehlt sich jedoch ein Unterpfad, damit Objektspeicherprotokolle oder andere Daten ohne Konflikte im selben Bucket gespeichert werden können.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ S3 konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=2

repo1-retention-full=2

repo2-azure-account=pgbackrest

repo2-azure-container=demo-container

repo2-azure-key=YXpLZXk=

repo2-path=/demo-repo

repo2-retention-full=4

repo2-type=azure

repo3-path=/demo-repo

repo3-retention-full=4

repo3-s3-bucket=demo-bucket

repo3-s3-endpoint=s3.us-east-1.amazonaws.com

repo3-s3-key=accessKey1

repo3-s3-key-secret=verySecretKey1

repo3-s3-region=us-east-1

repo3-type=s3

start-fast=y



[global:archive-push]

compress-level=3

HINWEIS:

Region und Endpunkt müssen entsprechend dem Standort des Buckets konfiguriert werden. Die hier angegebenen Werte gelten für die Region us-east-1.

Für die Ausführung von pgBackRest sollte eine Rolle erstellt werden, und die Bucket-Berechtigungen sollten möglichst restriktiv gesetzt werden. Ist die Rolle einer AWS-Instanz zugeordnet, ruft pgBackRest bei repo3-s3-key-type=auto automatisch temporäre Zugangsdaten ab. Schlüssel müssen dann nicht ausdrücklich in /etc/pgbackrest/pgbackrest.conf angegeben werden.

Diese Amazon-S3-Beispielrichtlinie beschränkt alle Lese- und Schreibzugriffe auf den Bucket und den Repository-Pfad.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::demo-bucket"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:prefix": [
                        "",
                        "demo-repo"
                    ],
                    "s3:delimiter": [
                        "/"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::demo-bucket"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "demo-repo/*"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:PutObjectTagging",
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::demo-bucket/demo-repo/*"
            ]
        }
    ]
}

Die Befehle werden genauso ausgeführt, als läge das Repository auf einem lokalen Datenträger.

pg-primary ⇒ Stanza erstellen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create
       [filtered 4 lines of output]
P00   INFO: stanza 'demo' already exists on repo2 and is valid
P00   INFO: stanza-create for stanza 'demo' on repo3
P00   INFO: stanza-create command end: completed successfully

Da das Erstellen von Dateien in S3 relativ langsam ist, verbessert die Aktivierung der Dateibündelung die Leistung von backup/restore.

pg-primary ⇒ Backup des Demo-Clusters erstellen

sudo -u postgres pgbackrest --stanza=demo --repo=3 \
       --log-level-console=info backup
P00   INFO: backup command begin 2.59.3: --exec-id=5060-13323a52 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --repo=3 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-block --repo1-bundle --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo2-type=azure --repo3-type=s3 --stanza=demo --start-fast
P00   WARN: no prior backup exists, incr backup has been changed to full
P00   INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 00000005000000000000001D, lsn = 0/1D000028
       [filtered 3 lines of output]
P00   INFO: check archive for segment(s) 00000005000000000000001D:00000005000000000000001D
P00   INFO: new backup label = 20261002-185820F
P00   INFO: full backup size = 33.5MB, file total = 1249
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=5060-13323a52 --log-level-console=info --no-log-timestamp --repo=3 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo2-type=azure --repo3-type=s3 --stanza=demo

SFTP-Unterstützung

pgBackRest unterstützt Repositorys auf SFTP-Hosts. SFTP-Dateiübertragungen sind relativ langsam. Daher profitieren Befehle von einer Erhöhung von process-max, um die Dateiübertragungen zu parallelisieren.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ SFTP konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

process-max=4

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=2

repo1-retention-full=2

repo2-azure-account=pgbackrest

repo2-azure-container=demo-container

repo2-azure-key=YXpLZXk=

repo2-path=/demo-repo

repo2-retention-full=4

repo2-type=azure

repo3-path=/demo-repo

repo3-retention-full=4

repo3-s3-bucket=demo-bucket

repo3-s3-endpoint=s3.us-east-1.amazonaws.com

repo3-s3-key=accessKey1

repo3-s3-key-secret=verySecretKey1

repo3-s3-region=us-east-1

repo3-type=s3

repo4-bundle=y

repo4-path=/demo-repo

repo4-sftp-host=sftp-server

repo4-sftp-host-key-hash-type=sha1

repo4-sftp-host-user=pgbackrest

repo4-sftp-private-key-file=/var/lib/pgsql/.ssh/id_rsa_sftp

repo4-sftp-public-key-file=/var/lib/pgsql/.ssh/id_rsa_sftp.pub

repo4-type=sftp

start-fast=y



[global:archive-push]

compress-level=3

Bei der Verwendung von SFTP ist repo4-sftp-public-key-file optional, wenn libssh2 gegen OpenSSH kompiliert wurde.

pg-primary ⇒ SSH-Schlüsselpaar für SFTP-Backups erzeugen

sudo -u postgres mkdir -m 750 -p /var/lib/pgsql/.ssh
sudo -u postgres ssh-keygen -f /var/lib/pgsql/.ssh/id_rsa_sftp \
       -t rsa -b 4096 -N "" -m PEM

sftp-server ⇒ Öffentlichen SFTP-Backup-Schlüssel von pg-primary nach sftp-server kopieren

sudo -u pgbackrest mkdir -m 750 -p /home/pgbackrest/.ssh
(sudo ssh root@pg-primary cat /var/lib/pgsql/.ssh/id_rsa_sftp.pub) | \
       sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys

Die Befehle werden genauso ausgeführt, als läge das Repository auf einem lokalen Datenträger.

pg-primary ⇒ Fingerprint von sftp-server zur Datei known_hosts hinzufügen, da repo4-sftp-host-key-check-type standardmäßig “strict” verwendet

ssh-keyscan -H sftp-server >> /var/lib/pgsql/.ssh/known_hosts 2>/dev/null

pg-primary ⇒ Stanza erstellen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create
       [filtered 6 lines of output]
P00   INFO: stanza 'demo' already exists on repo3 and is valid
P00   INFO: stanza-create for stanza 'demo' on repo4
P00   INFO: stanza-create command end: completed successfully

pg-primary ⇒ Backup des Demo-Clusters erstellen

sudo -u postgres pgbackrest --stanza=demo --repo=4 \
       --log-level-console=info backup
P00   INFO: backup command begin 2.59.3: --exec-id=5361-dd15b633 --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --process-max=4 --repo=4 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-block --repo1-bundle --repo4-bundle --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo4-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo4-sftp-host=sftp-server --repo4-sftp-host-key-hash-type=sha1 --repo4-sftp-host-user=pgbackrest --repo4-sftp-private-key-file=/var/lib/pgsql/.ssh/id_rsa_sftp --repo4-sftp-public-key-file=/var/lib/pgsql/.ssh/id_rsa_sftp.pub --repo2-type=azure --repo3-type=s3 --repo4-type=sftp --stanza=demo --start-fast
P00   WARN: option 'repo4-retention-full' is not set for 'repo4-retention-full-type=count', the repository may run out of space
            HINT: to retain full backups indefinitely (without warning), set option 'repo4-retention-full' to the maximum.
P00   WARN: no prior backup exists, incr backup has been changed to full
P00   INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 00000005000000000000001E, lsn = 0/1E000028
       [filtered 3 lines of output]
P00   INFO: check archive for segment(s) 00000005000000000000001E:00000005000000000000001F
P00   INFO: new backup label = 20261002-185837F
P00   INFO: full backup size = 33.5MB, file total = 1249
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.59.3: --exec-id=5361-dd15b633 --log-level-console=info --no-log-timestamp --repo=4 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo4-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo2-retention-full=4 --repo3-retention-full=4 --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo4-sftp-host=sftp-server --repo4-sftp-host-key-hash-type=sha1 --repo4-sftp-host-user=pgbackrest --repo4-sftp-private-key-file=/var/lib/pgsql/.ssh/id_rsa_sftp --repo4-sftp-public-key-file=/var/lib/pgsql/.ssh/id_rsa_sftp.pub --repo2-type=azure --repo3-type=s3 --repo4-type=sftp --stanza=demo
P00   INFO: expire command end: completed successfully

Unterstützung für GCS-kompatible Objektspeicher

pgBackRest unterstützt Repositorys in GCS-kompatiblen Objektspeichern. Der Bucket für das Repository muss vorab erstellt werden; pgBackRest legt ihn nicht automatisch an. Das Repository kann im Stammverzeichnis des Buckets (/) liegen. Meist empfiehlt sich jedoch ein Unterpfad, damit Objektspeicherprotokolle oder andere Daten ohne Konflikte im selben Bucket gespeichert werden können.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ GCS konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

process-max=4

repo1-block=y

repo1-bundle=y

repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

repo1-cipher-type=aes-256-cbc

repo1-path=/var/lib/pgbackrest

repo1-retention-diff=2

repo1-retention-full=2

repo2-azure-account=pgbackrest

repo2-azure-container=demo-container

repo2-azure-key=YXpLZXk=

repo2-path=/demo-repo

repo2-retention-full=4

repo2-type=azure

repo3-path=/demo-repo

repo3-retention-full=4

repo3-s3-bucket=demo-bucket

repo3-s3-endpoint=s3.us-east-1.amazonaws.com

repo3-s3-key=accessKey1

repo3-s3-key-secret=verySecretKey1

repo3-s3-region=us-east-1

repo3-type=s3

repo4-bundle=y

repo4-path=/demo-repo

repo4-sftp-host=sftp-server

repo4-sftp-host-key-hash-type=sha1

repo4-sftp-host-user=pgbackrest

repo4-sftp-private-key-file=/var/lib/pgsql/.ssh/id_rsa_sftp

repo4-sftp-public-key-file=/var/lib/pgsql/.ssh/id_rsa_sftp.pub

repo4-type=sftp

repo5-gcs-bucket=demo-bucket

repo5-gcs-key=/etc/pgbackrest/gcs-key.json

repo5-path=/demo-repo

repo5-type=gcs

start-fast=y



[global:archive-push]

compress-level=3

Bei der Ausführung in GCE repo5-gcs-key-type=auto setzen, um sich automatisch über das Dienstkonto der Instanz zu authentifizieren.

Die Befehle werden genauso ausgeführt, als läge das Repository auf einem lokalen Datenträger.

Da das Erstellen von Dateien in GCS relativ langsam ist, verbessert die Aktivierung der Dateibündelung die Leistung von backup/restore.

Zielzeit für ein Repository

Die Zielzeit legt den Zeitpunkt fest, auf dessen Stand Befehle ein Repository auf versioniertem Speicher lesen. So kann ein Befehl das Repository in seinem damaligen Zustand lesen, um Daten wiederherzustellen, die durch ein Benutzerversehen oder Schadsoftware gelöscht oder beschädigt wurden.

Versionierter Speicher wird von S3, GCS und Azure unterstützt, ist jedoch im Allgemeinen nicht standardmäßig aktiviert. Zusätzlich zur Versionierung kann es sinnvoll sein, für S3 die Objektsperre und für GCS oder Azure das vorläufige Löschen (Soft Delete) zu aktivieren.

Wenn die Option repo-target-time angegeben wird, muss auch die Option repo angegeben werden. Voraussichtlich werden nicht alle Repository-Typen Versionierung unterstützen. Außerdem ist es im Allgemeinen sinnvoll, für die Recovery gezielt ein einzelnes Repository auszuwählen.

Der Speicherzeitstempel wird darauf geprüft, ob er <= dem angegebenen Zeitstempel ist. Enthält der angegebene Zeitstempel Millisekunden, werden sie abgeschnitten.

Zur Demonstration dieser Funktion wird die Stanza demo im S3-Repository gelöscht.

pg-primary ⇒ Stanza im S3-Repository löschen

sudo systemctl stop postgresql-14.service
sudo -u postgres pgbackrest --stanza=demo stop
sudo -u postgres pgbackrest --stanza=demo --repo=3 stanza-delete

Nach dem Löschen der Stanza zeigt der Befehl info das Repository in einem Fehlerzustand an.

pg-primary ⇒ Fehler bei info

sudo -u postgres pgbackrest --stanza=demo --repo=3 info
stanza: demo
    status: error (missing stanza path)

Da der Speicher versioniert ist, lässt sich das Repository jedoch zu einem Zeitpunkt vor dem Löschen der Stanza betrachten. Je nach Situation kann es schwierig sein, die Zielzeit zu ermitteln. Hier lässt sich der Löschzeitpunkt der Stanza anhand des Löschzeitpunkts von backup.info bestimmen.

pg-primary ⇒ Versionen von backup.info im Bucket auflisten

key=demo-repo/backup/demo/backup.info; \
       aws s3api list-object-versions --bucket demo-bucket \
       --prefix $key --output table \
       --query "sort_by([Versions[?Key=='$key'].{Action:'PUT', \
       Modified:LastModified,Object:Key}, \
       DeleteMarkers[?Key=='$key'].{Action:'DELETE', \
       Modified:LastModified,Object:Key}][],&Modified)"
-------------------------------------------------------------------------------------
|                                ListObjectVersions                                 |
+--------+------------------------------------+-------------------------------------+
| Action |             Modified               |               Object                |
+--------+------------------------------------+-------------------------------------+
|  PUT   |  2026-10-02T18:58:20.631000+00:00  |  demo-repo/backup/demo/backup.info  |
|  PUT   |  2026-10-02T18:58:33.900000+00:00  |  demo-repo/backup/demo/backup.info  |
|  DELETE|  2026-10-02T18:58:45.634000+00:00  |  demo-repo/backup/demo/backup.info  |
+--------+------------------------------------+-------------------------------------+

Der Befehl info kann nun mit einer Zielzeit ausgeführt werden, die das Repository vor dem Löschen zeigt.

pg-primary ⇒ Info mit Zielzeit

sudo -u postgres pgbackrest --stanza=demo --repo=3 \
       --repo-target-time="2026-10-02 18:58:34+00" info
       [filtered 5 lines of output]
        wal archive min/max (14): 00000005000000000000001C/00000005000000000000001D

        full backup: 20261002-185820F
            timestamp start/stop: 2026-10-02 18:58:20+00 / 2026-10-02 18:58:33+00
            wal start/stop: 00000005000000000000001D / 00000005000000000000001D
            repo3: backup set size: 4.2MB, backup size: 4.2MB

Wenn der Befehl info das benötigte Backup anzeigt, kann es mit derselben Zielzeit wiederhergestellt werden.

pg-primary ⇒ Wiederherstellung mit Zielzeit

sudo -u postgres pgbackrest --stanza=demo --repo=3 --delta \
       --repo-target-time="2026-10-02 18:58:34+00" --log-level-console=info restore
P00   INFO: restore command begin 2.59.3: --delta --exec-id=5686-f718513c --log-level-console=info --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --process-max=4 --repo=3 --repo2-azure-account=<redacted> --repo2-azure-container=demo-container --repo2-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo5-gcs-bucket=demo-bucket --repo5-gcs-key=<redacted> --repo1-path=/var/lib/pgbackrest --repo2-path=/demo-repo --repo3-path=/demo-repo --repo4-path=/demo-repo --repo5-path=/demo-repo --repo3-s3-bucket=demo-bucket --repo3-s3-endpoint=s3.us-east-1.amazonaws.com --repo3-s3-key=<redacted> --repo3-s3-key-secret=<redacted> --repo3-s3-region=us-east-1 --repo4-sftp-host=sftp-server --repo4-sftp-host-key-hash-type=sha1 --repo4-sftp-host-user=pgbackrest --repo4-sftp-private-key-file=/var/lib/pgsql/.ssh/id_rsa_sftp --repo4-sftp-public-key-file=/var/lib/pgsql/.ssh/id_rsa_sftp.pub --repo-target-time="2026-10-02 18:58:34+00" --repo2-type=azure --repo3-type=s3 --repo4-type=sftp --repo5-type=gcs --stanza=demo
P00   INFO: repo3: restore backup set 20261002-185820F, recovery will start at 2026-10-02 18:58:20
P00   INFO: remove invalid files/links/paths from '/var/lib/pgsql/14/data'
P00   INFO: write updated /var/lib/pgsql/14/data/postgresql.auto.conf
       [filtered 2 lines of output]
sudo systemctl start postgresql-14.service

Dedizierter Repository-Host

Die unter Schnellstart beschriebene Konfiguration eignet sich für einfache Installationen. In Unternehmensumgebungen ist dagegen ein dedizierter Repository-Host üblich, auf dem Backups und WAL-Archivdateien gespeichert werden. Dadurch sind Backups und WAL-Archiv vom Datenbankserver getrennt, sodass Ausfälle des Datenbankhosts geringere Auswirkungen haben. Zusätzlich empfiehlt es sich weiterhin, den Repository-Host mit herkömmlicher Backup-Software zu sichern.

Auf PostgreSQL-Hosts muss pg1-path auf den lokalen PostgreSQL-Cluster verweisen, und pg1-host sollte nicht konfiguriert sein. Auf einem Repository-Host muss in der pgBackRest-Konfigurationsdatei die Option pg-host für die Verbindung zum Primärserver und zu gegebenenfalls vorhandenen Standby-Hosts konfiguriert sein. Nur die pgBackRest-Konfiguration des Repository-Hosts sollte mehr als einen PostgreSQL-Host kennen. Die Reihenfolge spielt keine Rolle: Beispielsweise können pg1-path/pg1-host und pg2-path/pg2-host jeweils Primärserver oder Standby bezeichnen.

Installation

Ein neuer Host namens repository wird zum Speichern der Cluster-Backups eingerichtet.

HINWEIS:

Die auf dem Repository-Host installierte pgBackRest-Version muss exakt mit der Version auf dem PostgreSQL-Host übereinstimmen.

Der Benutzer pgbackrest wird als Eigentümer des pgBackRest-Repositorys angelegt. Jeder Benutzer kann Eigentümer des Repositorys sein. Zur Vermeidung von Verwechslungen empfiehlt es sich jedoch, nicht den Benutzer postgres zu verwenden, falls dieser existiert.

HINWEIS:

Bei der Installation von pgBackRest aus einem Paket wird möglicherweise eine logrotate-Konfiguration wie /etc/logrotate.d/pgbackrest bereitgestellt, die die Protokolle über die Direktive su unter einem bestimmten Benutzer rotiert, beispielsweise su postgres postgres. Da die Dateien in /var/log/pgbackrest dem Benutzer gehören, der pgBackRest ausführt, hier pgbackrest, muss die Direktive su auf diesen Benutzer angepasst werden. Andernfalls schlägt logrotate mit einem Berechtigungsfehler fehl.

repository ⇒ Benutzer pgbackrest erstellen

sudo groupadd pgbackrest
sudo adduser -gpgbackrest -n pgbackrest

Die Installation von pgBackRest aus einem Paket ist der Kompilierung aus dem Quellcode vorzuziehen. Bei einer Paketinstallation sind die übrigen Anweisungen in diesem Abschnitt normalerweise nicht erforderlich. Es kann jedoch vorkommen, dass ein Paket eines der Verzeichnisse nicht anlegt oder falsche Berechtigungen vergibt. In diesem Fall kann es erforderlich sein, Verzeichnisse manuell anzulegen oder Berechtigungen anzupassen.

RHEL-Pakete für pgBackRest sind unter yum.postgresql.org verfügbar.

Falls für Ihre Distribution oder Version keine Pakete bereitstehen, können Sie pgBackRest aus dem Quellcode kompilieren und anschließend wie hier gezeigt manuell installieren.

repository ⇒ Abhängigkeiten installieren

sudo yum install postgresql-libs libssh2

repository ⇒ pgBackRest-Binärdatei vom Build-Host kopieren

sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest

pgBackRest benötigt Protokoll- und Konfigurationsverzeichnisse sowie eine Konfigurationsdatei.

repository ⇒ pgBackRest-Konfigurationsdatei und Verzeichnisse erstellen

sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown pgbackrest:pgbackrest /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown pgbackrest:pgbackrest /etc/pgbackrest/pgbackrest.conf

repository ⇒ pgBackRest-Repository erstellen

sudo mkdir -p /var/lib/pgbackrest
sudo chmod 750 /var/lib/pgbackrest
sudo chown pgbackrest:pgbackrest /var/lib/pgbackrest

Konfiguration

pgBackRest kann TLS mit Clientzertifikaten für die Kommunikation zwischen Hosts verwenden. Alternativ ist SSH möglich; siehe SSH einrichten .

pgBackRest erwartet, dass Client- und Serverzertifikate genauso wie für PostgreSQL erstellt werden. Eine ausführliche Anleitung zum Erstellen von Zertifikaten steht unter Sichere TCP/IP-Verbindungen mit TLS .

Auf dem Repository-Host müssen Hostname und Benutzer von pg-primary sowie der Datenbankpfad konfiguriert werden. Der Primärserver wird als pg1 konfiguriert, damit später ein Standby hinzugefügt werden kann.

repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-host/pg1-host-user und pg1-path konfigurieren

[demo]

pg1-host=pg-primary

pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg1-host-cert-file=/etc/pgbackrest/cert/client.crt

pg1-host-key-file=/etc/pgbackrest/cert/client.key

pg1-host-type=tls

pg1-path=/var/lib/pgsql/14/data



[global]

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

tls-server-address=*

tls-server-auth=pgbackrest-client=*

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key

Auf dem Datenbankhost müssen Hostname und Benutzer des Repository-Hosts konfiguriert werden. Der Standardwert der Option repo1-host-user ist pgbackrest. Wenn der Benutzer postgres auf dem Repository-Host Wiederherstellungen durchführt, empfiehlt es sich, dem Benutzer postgres nicht zusätzlich die Durchführung von Backups zu erlauben. Der Benutzer postgres kann das Repository jedoch direkt lesen, wenn er derselben Gruppe wie pgbackrest angehört.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ repo1-host/repo1-host-user konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

log-level-file=detail

repo1-host=repository

repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt

repo1-host-cert-file=/etc/pgbackrest/cert/client.crt

repo1-host-key-file=/etc/pgbackrest/cert/client.key

repo1-host-type=tls

tls-server-address=*

tls-server-auth=pgbackrest-client=demo

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key

Die PostgreSQL-Konfiguration ist im Abschnitt Archivierung konfigurieren beschrieben.

Die Befehle werden genauso ausgeführt wie bei einer Konfiguration mit einem einzelnen Host. Einige Befehle, etwa backup und expire, laufen jedoch auf dem Repository-Host statt auf dem Datenbankhost.

TLS-Server einrichten

Der pgBackRest-TLS-Server muss auf jedem Host konfiguriert und gestartet werden.

repository ⇒ pgBackRest-Server einrichten

sudo cat /etc/systemd/system/pgbackrest.service
[Unit]
Description=pgBackRest Server
After=network.target
StartLimitIntervalSec=0

[Service]
Type=notify
Restart=always
RestartSec=1
User=pgbackrest
ExecStart=/usr/bin/pgbackrest server
ExecStartPost=/bin/sleep 3
ExecStartPost=/bin/bash -c "[ ! -z $MAINPID ]"
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
sudo systemctl enable pgbackrest
sudo systemctl start pgbackrest

pg-primary ⇒ pgBackRest-Server einrichten

sudo cat /etc/systemd/system/pgbackrest.service
[Unit]
Description=pgBackRest Server
After=network.target
StartLimitIntervalSec=0

[Service]
Type=notify
Restart=always
RestartSec=1
User=postgres
ExecStart=/usr/bin/pgbackrest server
ExecStartPost=/bin/sleep 3
ExecStartPost=/bin/bash -c "[ ! -z $MAINPID ]"
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
sudo systemctl enable pgbackrest
sudo systemctl start pgbackrest

Stanza erstellen und prüfen

Die Stanza im neuen Repository erstellen.

repository ⇒ Stanza erstellen

sudo -u pgbackrest pgbackrest --stanza=demo stanza-create

Die Konfiguration sowohl auf dem Datenbankhost als auch auf dem Repository-Host prüfen. Weitere Informationen zum Befehl check stehen unter Konfiguration prüfen .

pg-primary ⇒ Konfiguration prüfen

sudo -u postgres pgbackrest --stanza=demo check

repository ⇒ Konfiguration prüfen

sudo -u pgbackrest pgbackrest --stanza=demo check

Backup durchführen

Für ein Backup des PostgreSQL-Clusters pgBackRest mit dem Befehl backup auf dem Repository-Host ausführen.

repository ⇒ Backup des Demo-Clusters erstellen

sudo -u pgbackrest pgbackrest --stanza=demo backup
P00   WARN: no prior backup exists, incr backup has been changed to full

Da auf dem Repository-Host ein neues Repository erstellt wurde, erschien die Warnung, dass das inkrementelle Backup in ein vollständiges Backup umgewandelt wurde.

Backup wiederherstellen

Zur Wiederherstellung des PostgreSQL-Clusters pgBackRest mit dem Befehl restore auf dem Datenbankhost ausführen.

pg-primary ⇒ Demo-Cluster stoppen, wiederherstellen und PostgreSQL neu starten

sudo systemctl stop postgresql-14.service
sudo -u postgres pgbackrest --stanza=demo --delta restore
sudo systemctl start postgresql-14.service

Paralleles Backup / parallele Wiederherstellung

pgBackRest bietet parallele Verarbeitung, um die Leistung von Komprimierung und Übertragung zu verbessern. Die Anzahl der dafür verwendeten Prozesse wird mit der Option --process-max festgelegt.

Für den Befehl backup empfiehlt es sich normalerweise, höchstens 25% der verfügbaren CPUs zu verwenden. Backups müssen nicht besonders schnell laufen, solange sie regelmäßig durchgeführt werden. Der Backup-Prozess sollte die Datenbankleistung möglichst nicht beeinträchtigen.

Der Befehl restore kann und sollte alle verfügbaren CPUs verwenden, da der PostgreSQL-Cluster während einer Wiederherstellung gestoppt ist und auf dem Host normalerweise keine anderen wichtigen Arbeiten stattfinden. Enthält der Host mehrere Cluster, sollte dies bei der Festlegung der Parallelität der Wiederherstellung berücksichtigt werden.

repository ⇒ Backup mit einem einzelnen Prozess durchführen

sudo -u pgbackrest pgbackrest --stanza=demo --type=full backup

repository:/etc/pgbackrest/pgbackrest.conf ⇒ pgBackRest für mehrere backup-Prozesse konfigurieren

[demo]

pg1-host=pg-primary

pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg1-host-cert-file=/etc/pgbackrest/cert/client.crt

pg1-host-key-file=/etc/pgbackrest/cert/client.key

pg1-host-type=tls

pg1-path=/var/lib/pgsql/14/data



[global]

process-max=3

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

tls-server-address=*

tls-server-auth=pgbackrest-client=*

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key

repository ⇒ Backup mit mehreren Prozessen durchführen

sudo -u pgbackrest pgbackrest --stanza=demo --type=full backup

repository ⇒ Backup-Informationen zum Demo-Cluster abrufen

sudo -u pgbackrest pgbackrest info
stanza: demo
    status: ok
    cipher: none

    db (current)
        wal archive min/max (14): 000000070000000000000023/000000070000000000000025

        full backup: 20261002-185937F
            timestamp start/stop: 2026-10-02 18:59:37+00 / 2026-10-02 18:59:40+00
            wal start/stop: 000000070000000000000023 / 000000070000000000000023
            database size: 33.5MB, database backup size: 33.5MB
            repo1: backup set size: 4.2MB, backup size: 4.2MB

        full backup: 20261002-185941F
            timestamp start/stop: 2026-10-02 18:59:41+00 / 2026-10-02 18:59:43+00
            wal start/stop: 000000070000000000000024 / 000000070000000000000025
            database size: 33.5MB, database backup size: 33.5MB
            repo1: backup set size: 4.2MB, backup size: 4.2MB

Durch die Verwendung mehrerer Prozesse sollte das letzte Backup schneller sein. Bei sehr kleinen Backups ist der Unterschied möglicherweise kaum erkennbar. Mit zunehmender Datenbankgröße steigt jedoch auch die Zeitersparnis.

Starten und Stoppen

Wird ein Standby zu Testzwecken hochgestuft oder ein Testcluster aus einem Produktionsbackup wiederhergestellt, empfiehlt es sich, Schreibzugriffe dieser Cluster auf pgBackRest-Repositorys zu verhindern. Dies ist mit dem Befehl stop möglich.

Die schreibenden Befehle, die stop blockiert, sind archive-push, backup, expire, stanza-create und stanza-upgrade. stanza-delete ist eine Ausnahme von dieser Regel; weitere Einzelheiten stehen unter Stanza löschen .

pg-primary ⇒ Schreibende pgBackRest-Befehle stoppen

sudo -u postgres pgbackrest stop

Neue schreibende pgBackRest-Befehle werden nicht mehr ausgeführt.

repository ⇒ Backup versuchen

sudo -u pgbackrest pgbackrest --stanza=demo backup
P00   WARN: unable to check pg1: [StopError] raised from remote-0 tls protocol on 'pg-primary': stop file exists for all stanzas
P00  ERROR: [056]: unable to find primary cluster - cannot proceed
            HINT: are all available clusters in recovery?

Mit der Option --force werden bereits laufende schreibende pgBackRest-Befehle beendet. Das schließt asynchrones archive-get ein, das jedoch erneut läuft, wenn PostgreSQL es benötigt. Ist pgBackRest bereits gestoppt, erzeugt ein erneutes Stoppen eine Warnung.

pg-primary ⇒ pgBackRest-Dienste erneut stoppen

sudo -u postgres pgbackrest stop
P00   WARN: stop file already exists for all stanzas

Mit dem Befehl start werden schreibende pgBackRest-Befehle wieder zugelassen. Schreibende Befehle, die vor dem Stoppen liefen, starten nicht automatisch erneut; sie dürfen jetzt jedoch wieder gestartet werden.

pg-primary ⇒ Schreibende pgBackRest-Befehle starten

sudo -u postgres pgbackrest start

pgBackRest kann auch für eine einzelne Stanza gestoppt werden.

pg-primary ⇒ Schreibende pgBackRest-Befehle für die Stanza demo stoppen

sudo -u postgres pgbackrest --stanza=demo stop

Neue schreibende pgBackRest-Befehle für die angegebene Stanza werden nicht mehr ausgeführt.

repository ⇒ Backup versuchen

sudo -u pgbackrest pgbackrest --stanza=demo backup
P00   WARN: unable to check pg1: [StopError] raised from remote-0 tls protocol on 'pg-primary': stop file exists for stanza demo
P00  ERROR: [056]: unable to find primary cluster - cannot proceed
            HINT: are all available clusters in recovery?

Auch beim Starten schreibender pgBackRest-Befehle für eine einzelne Stanza muss diese angegeben werden.

pg-primary ⇒ Schreibende pgBackRest-Befehle für die Stanza demo starten

sudo -u postgres pgbackrest --stanza=demo start

Replikation

Durch Replikation lassen sich mehrere Kopien eines PostgreSQL-Clusters, sogenannte Standbys, von einem einzigen Primärserver erstellen. Standbys dienen zur Verteilung von Lesezugriffen und bieten Redundanz, falls der primäre Host ausfällt.

Installation

Ein neuer Host namens pg-standby wird für den Betrieb des Standbys eingerichtet.

Die Installation von pgBackRest aus einem Paket ist der Kompilierung aus dem Quellcode vorzuziehen. Bei einer Paketinstallation sind die übrigen Anweisungen in diesem Abschnitt normalerweise nicht erforderlich. Es kann jedoch vorkommen, dass ein Paket eines der Verzeichnisse nicht anlegt oder falsche Berechtigungen vergibt. In diesem Fall kann es erforderlich sein, Verzeichnisse manuell anzulegen oder Berechtigungen anzupassen.

RHEL-Pakete für pgBackRest sind unter yum.postgresql.org verfügbar.

Falls für Ihre Distribution oder Version keine Pakete bereitstehen, können Sie pgBackRest aus dem Quellcode kompilieren und anschließend wie hier gezeigt manuell installieren.

pg-standby ⇒ Abhängigkeiten installieren

sudo yum install postgresql-libs libssh2

pg-standby ⇒ pgBackRest-Binärdatei vom Build-Host kopieren

sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest

pgBackRest benötigt Protokoll- und Konfigurationsverzeichnisse sowie eine Konfigurationsdatei.

pg-standby ⇒ pgBackRest-Konfigurationsdatei und Verzeichnisse erstellen

sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf

Hot Standby

Ein Hot Standby repliziert über das WAL-Archiv und erlaubt schreibgeschützte Abfragen.

Die pgBackRest-Konfiguration ist der von pg-primary sehr ähnlich. Es wird jedoch der Recovery-Typ standby verwendet, damit der Cluster nach Erreichen des Endes des WAL-Stroms im Recovery-Modus bleibt.

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ pgBackRest auf dem Standby konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

log-level-file=detail

repo1-host=repository

repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt

repo1-host-cert-file=/etc/pgbackrest/cert/client.crt

repo1-host-key-file=/etc/pgbackrest/cert/client.key

repo1-host-type=tls

tls-server-address=*

tls-server-auth=pgbackrest-client=demo

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key

pg-standby ⇒ pgBackRest-Server einrichten

sudo cat /etc/systemd/system/pgbackrest.service
[Unit]
Description=pgBackRest Server
After=network.target
StartLimitIntervalSec=0

[Service]
Type=notify
Restart=always
RestartSec=1
User=postgres
ExecStart=/usr/bin/pgbackrest server
ExecStartPost=/bin/sleep 3
ExecStartPost=/bin/bash -c "[ ! -z $MAINPID ]"
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
sudo systemctl enable pgbackrest
sudo systemctl start pgbackrest

Den Pfad erstellen, in dem PostgreSQL wiederhergestellt werden soll.

pg-standby ⇒ PostgreSQL-Pfad erstellen

sudo -u postgres mkdir -p -m 700 /var/lib/pgsql/14/data

Nun kann der Standby mit dem Befehl restore erstellt werden.

WICHTIG:

Soll der Cluster hochgestuft werden, ohne zum neuen Primärserver zu werden, beispielsweise für Berichte oder Tests, die Archivierung mit --archive-mode=off oder archive_mode=off in postgresql.conf deaktivieren. Andernfalls kann WAL im Repository landen, das Wiederherstellungen erschwert.

pg-standby ⇒ Demo-Standby-Cluster wiederherstellen

sudo -u postgres pgbackrest --stanza=demo --type=standby restore
sudo -u postgres cat /var/lib/pgsql/14/data/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.

# Recovery settings generated by pgBackRest restore on 2026-10-02 18:57:00
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 18:57:22
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 18:57:47
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Removed by pgBackRest restore on 2026-10-02 18:58:52 # recovery_target_time = '2026-10-02 18:57:39.575732+00'
# Removed by pgBackRest restore on 2026-10-02 18:58:52 # recovery_target_action = 'promote'

# Recovery settings generated by pgBackRest restore on 2026-10-02 18:58:52
restore_command = 'pgbackrest --repo=3 --repo-target-time="2026-10-02 18:58:34+00" --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 18:59:32
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:00:04
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

Diese Konfiguration gilt für den Fall, dass der Standby zum Primärserver hochgestuft wird.

pg-standby:/var/lib/pgsql/14/data/postgresql.conf ⇒ PostgreSQL konfigurieren

archive_command = 'pgbackrest --stanza=demo archive-push %p'

archive_mode = on

log_filename = 'postgresql.log'

pg-standby ⇒ PostgreSQL starten

sudo systemctl start postgresql-14.service

Das PostgreSQL-Protokoll liefert wertvolle Informationen zur Recovery. Besonders zu beachten ist, dass der Cluster in den Standby-Modus gewechselt ist und schreibgeschützte Verbindungen annehmen kann.

pg-standby ⇒ PostgreSQL-Protokollausgabe auf Erfolgsmeldungen prüfen

sudo -u postgres cat /var/lib/pgsql/14/data/log/postgresql.log
       [filtered 4 lines of output]
LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
LOG:  database system was interrupted; last known up at 2026-10-02 18:59:41 UTC
LOG:  entering standby mode
LOG:  restored log file "00000007.history" from archive
LOG:  restored log file "000000070000000000000024" from archive
       [filtered 3 lines of output]

Eine einfache Prüfung der Replikationskonfiguration besteht darin, auf pg-primary eine Tabelle zu erstellen.

pg-primary ⇒ Neue Tabelle auf dem Primärserver erstellen

sudo -u postgres psql -c " \
       begin; \
       create table replicated_table (message text); \
       insert into replicated_table values ('Important Data'); \
       commit; \
       select * from replicated_table";
       [filtered 4 lines of output]
    message
----------------
 Important Data
(1 row)

Anschließend dieselbe Tabelle auf pg-standby abfragen.

pg-standby ⇒ Neue Tabelle auf dem Standby abfragen

sudo -u postgres psql -c "select * from replicated_table;"
ERROR:  relation "replicated_table" does not exist
LINE 1: select * from replicated_table;
                      ^

Was ist schiefgegangen? Da PostgreSQL WAL-Segmente für die Replikation aus dem Archiv abruft, werden Änderungen auf dem Standby erst sichtbar, wenn pg-primary das WAL-Segment mit diesen Änderungen in das Archiv übertragen hat.

Dies lässt sich manuell durch einen Aufruf von pg_switch_wal() auslösen. Dadurch wird das aktuelle WAL-Segment ins Archiv übertragen und ein neues WAL-Segment für weitere Änderungen erstellt.

pg-primary ⇒ pg_switch_wal() aufrufen

sudo -u postgres psql -c "select *, current_timestamp from pg_switch_wal()";
 pg_switch_wal |       current_timestamp
---------------+-------------------------------
 0/2601E7C0    | 2026-10-02 19:00:10.880013+00
(1 row)

Nach einer kurzen Verzögerung erscheint die Tabelle nun auf pg-standby.

pg-standby ⇒ Die neue Tabelle existiert jetzt auf dem Standby; möglicherweise sind einige Versuche nötig

sudo -u postgres psql -c " \
       select *, current_timestamp from replicated_table"
    message     |       current_timestamp
----------------+-------------------------------
 Important Data | 2026-10-02 19:00:11.954843+00
(1 row)

Die Standby-Konfiguration auf Zugriff zum Repository prüfen.

pg-standby ⇒ Konfiguration prüfen

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info check
P00   INFO: check command begin 2.59.3: --exec-id=1250-e6a5e2d8 --log-level-console=info --log-level-file=detail --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --repo1-host=repository --repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt --repo1-host-cert-file=/etc/pgbackrest/cert/client.crt --repo1-host-key-file=/etc/pgbackrest/cert/client.key --repo1-host-type=tls --stanza=demo
P00   INFO: check repo1 (standby)
P00   INFO: switch wal not performed because this is a standby
P00   INFO: check command end: completed successfully

Streaming-Replikation

Streaming-Replikation verlässt sich nicht allein auf das WAL-Archiv, sondern stellt eine direkte Verbindung zum Primärserver her und wendet Änderungen an, sobald sie dort vorgenommen werden. Dadurch ist die Verzögerung zwischen Primärserver und Standby deutlich geringer.

Streaming-Replikation erfordert einen Benutzer mit Replikationsberechtigung.

pg-primary ⇒ Replikationsbenutzer erstellen

sudo -u postgres psql -c " \
       create user replicator password 'jw8s0F4' replication";
CREATE ROLE

Die Datei pg_hba.conf muss angepasst werden, damit der Standby eine Verbindung als Replikationsbenutzer herstellen darf. Die folgende IP-Adresse durch die tatsächliche IP-Adresse von pg-standby ersetzen. Nach der Änderung von pg_hba.conf muss die Konfiguration neu geladen werden.

pg-primary ⇒ Eintrag in pg_hba.conf für den Replikationsbenutzer erstellen

sudo -u postgres sh -c 'echo \
       "host    replication     replicator      172.17.0.8/32           md5" \
       >> /var/lib/pgsql/14/data/pg_hba.conf'
sudo systemctl reload postgresql-14.service

Der Standby muss wissen, wie er den Primärserver erreicht. Daher wird die Einstellung primary_conninfo in pgBackRest konfiguriert.

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ primary_conninfo setzen

[demo]

pg1-path=/var/lib/pgsql/14/data

recovery-option=primary_conninfo=host=172.17.0.6 port=5432 user=replicator



[global]

log-level-file=detail

repo1-host=repository

repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt

repo1-host-cert-file=/etc/pgbackrest/cert/client.crt

repo1-host-key-file=/etc/pgbackrest/cert/client.key

repo1-host-type=tls

tls-server-address=*

tls-server-auth=pgbackrest-client=demo

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key

Ein Passwort kann in der Einstellung primary_conninfo angegeben werden. Eine Datei .pgpass ist jedoch flexibler und sicherer.

pg-standby ⇒ Replikationspasswort in der Datei .pgpass konfigurieren.

sudo -u postgres sh -c 'echo \
       "172.17.0.6:*:replication:replicator:jw8s0F4" \
       >> /var/lib/pgsql/.pgpass'
sudo -u postgres chmod 600 /var/lib/pgsql/.pgpass

Nun kann der Standby mit dem Befehl restore erstellt werden.

pg-standby ⇒ PostgreSQL stoppen und Demo-Standby-Cluster wiederherstellen

sudo systemctl stop postgresql-14.service
sudo -u postgres pgbackrest --stanza=demo --delta --type=standby restore
sudo -u postgres cat /var/lib/pgsql/14/data/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.

# Recovery settings generated by pgBackRest restore on 2026-10-02 18:57:00
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 18:57:22
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 18:57:47
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
# Removed by pgBackRest restore on 2026-10-02 18:58:52 # recovery_target_time = '2026-10-02 18:57:39.575732+00'
# Removed by pgBackRest restore on 2026-10-02 18:58:52 # recovery_target_action = 'promote'

# Recovery settings generated by pgBackRest restore on 2026-10-02 18:58:52
restore_command = 'pgbackrest --repo=3 --repo-target-time="2026-10-02 18:58:34+00" --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 18:59:32
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

# Recovery settings generated by pgBackRest restore on 2026-10-02 19:00:18
primary_conninfo = 'host=172.17.0.6 port=5432 user=replicator'
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

HINWEIS:

Die Einstellung primary_conninfo wurde in die Datei postgresql.auto.conf geschrieben, da sie als recovery-option in pgbackrest.conf konfiguriert war. Falls gewünscht, kann mit restore die Option --type=preserve verwendet werden, um die vorhandene Datei postgresql.auto.conf beizubehalten.

RHEL speichert die Datei postgresql.conf standardmäßig im PostgreSQL-Datenverzeichnis. Daher wurde die Änderung an postgresql.conf bei der letzten Wiederherstellung überschrieben, und die Einstellung hot_standby muss erneut aktiviert werden. Alternativ kann die Datei postgresql.conf an einem anderen Ort gespeichert oder hot_standby auf dem Host pg-primary aktiviert werden, wo die Einstellung ignoriert wird.

pg-standby:/var/lib/pgsql/14/data/postgresql.conf ⇒ hot_standby aktivieren

archive_command = 'pgbackrest --stanza=demo archive-push %p'

archive_mode = on

hot_standby = on

log_filename = 'postgresql.log'

pg-standby ⇒ PostgreSQL starten

sudo systemctl start postgresql-14.service

Das PostgreSQL-Protokoll bestätigt den Start der Streaming-Replikation.

pg-standby ⇒ PostgreSQL-Protokollausgabe auf Erfolgsmeldungen prüfen

sudo -u postgres cat /var/lib/pgsql/14/data/log/postgresql.log
       [filtered 12 lines of output]
LOG:  database system is ready to accept read-only connections
LOG:  restored log file "000000070000000000000026" from archive
LOG:  started streaming WAL from primary at 0/27000000 on timeline 7

Wenn nun auf pg-primary eine Tabelle erstellt wird, erscheint sie schnell auf pg-standby, ohne dass pg_switch_wal() aufgerufen werden muss.

pg-primary ⇒ Neue Tabelle auf dem Primärserver erstellen

sudo -u postgres psql -c " \
       begin; \
       create table stream_table (message text); \
       insert into stream_table values ('Important Data'); \
       commit; \
       select *, current_timestamp from stream_table";
       [filtered 4 lines of output]
    message     |       current_timestamp
----------------+-------------------------------
 Important Data | 2026-10-02 19:00:24.428653+00
(1 row)

pg-standby ⇒ Tabelle auf dem Standby abfragen

sudo -u postgres psql -c " \
       select *, current_timestamp from stream_table"
    message     |       current_timestamp
----------------+-------------------------------
 Important Data | 2026-10-02 19:00:24.605628+00
(1 row)

Mehrere Stanzas

pgBackRest unterstützt mehrere Stanzas. Am häufigsten wird dabei ein Repository-Host von mehreren Stanzas gemeinsam genutzt.

Installation

Ein neuer Host namens pg-alt wird für den Betrieb des neuen Primärservers eingerichtet.

Die Installation von pgBackRest aus einem Paket ist der Kompilierung aus dem Quellcode vorzuziehen. Bei einer Paketinstallation sind die übrigen Anweisungen in diesem Abschnitt normalerweise nicht erforderlich. Es kann jedoch vorkommen, dass ein Paket eines der Verzeichnisse nicht anlegt oder falsche Berechtigungen vergibt. In diesem Fall kann es erforderlich sein, Verzeichnisse manuell anzulegen oder Berechtigungen anzupassen.

RHEL-Pakete für pgBackRest sind unter yum.postgresql.org verfügbar.

Falls für Ihre Distribution oder Version keine Pakete bereitstehen, können Sie pgBackRest aus dem Quellcode kompilieren und anschließend wie hier gezeigt manuell installieren.

pg-alt ⇒ Abhängigkeiten installieren

sudo yum install postgresql-libs libssh2

pg-alt ⇒ pgBackRest-Binärdatei vom Build-Host kopieren

sudo scp build:/build/pgbackrest/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest

pgBackRest benötigt Protokoll- und Konfigurationsverzeichnisse sowie eine Konfigurationsdatei.

pg-alt ⇒ pgBackRest-Konfigurationsdatei und Verzeichnisse erstellen

sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf

Konfiguration

Die pgBackRest-Konfiguration ist nahezu identisch mit der von pg-primary. Es wird jedoch die Stanza demo-alt verwendet, damit Backups und Archiv an einem getrennten Ort gespeichert werden.

pg-alt:/etc/pgbackrest/pgbackrest.conf ⇒ pgBackRest auf dem neuen Primärserver konfigurieren

[demo-alt]

pg1-path=/var/lib/pgsql/14/data



[global]

log-level-file=detail

repo1-host=repository

repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt

repo1-host-cert-file=/etc/pgbackrest/cert/client.crt

repo1-host-key-file=/etc/pgbackrest/cert/client.key

repo1-host-type=tls

tls-server-address=*

tls-server-auth=pgbackrest-client=demo-alt

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key

repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-host/pg1-host-user und pg1-path konfigurieren

[demo]

pg1-host=pg-primary

pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg1-host-cert-file=/etc/pgbackrest/cert/client.crt

pg1-host-key-file=/etc/pgbackrest/cert/client.key

pg1-host-type=tls

pg1-path=/var/lib/pgsql/14/data



[demo-alt]

pg1-host=pg-alt

pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg1-host-cert-file=/etc/pgbackrest/cert/client.crt

pg1-host-key-file=/etc/pgbackrest/cert/client.key

pg1-host-type=tls

pg1-path=/var/lib/pgsql/14/data



[global]

process-max=3

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

tls-server-address=*

tls-server-auth=pgbackrest-client=*

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key

pg-alt ⇒ pgBackRest-Server einrichten

sudo cat /etc/systemd/system/pgbackrest.service
[Unit]
Description=pgBackRest Server
After=network.target
StartLimitIntervalSec=0

[Service]
Type=notify
Restart=always
RestartSec=1
User=postgres
ExecStart=/usr/bin/pgbackrest server
ExecStartPost=/bin/sleep 3
ExecStartPost=/bin/bash -c "[ ! -z $MAINPID ]"
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
sudo systemctl enable pgbackrest
sudo systemctl start pgbackrest

Demo-Cluster einrichten

pg-alt ⇒ Demo-Cluster erstellen

sudo -u postgres /usr/pgsql-14/bin/initdb \
       -D /var/lib/pgsql/14/data -k -A peer

pg-alt:/var/lib/pgsql/14/data/postgresql.conf ⇒ PostgreSQL-Einstellungen konfigurieren

archive_command = 'pgbackrest --stanza=demo-alt archive-push %p'

archive_mode = on

log_filename = 'postgresql.log'

pg-alt ⇒ Demo-Cluster starten

sudo systemctl restart postgresql-14.service

Stanza erstellen und Konfiguration prüfen

Zum Initialisieren der Stanza muss der Befehl stanza-create ausgeführt werden. Es wird empfohlen, nach stanza-create den Befehl check auszuführen, um sicherzustellen, dass Archivierung und Backups korrekt konfiguriert sind.

pg-alt ⇒ Stanza erstellen und Konfiguration prüfen

sudo -u postgres pgbackrest --stanza=demo-alt --log-level-console=info stanza-create
P00   INFO: stanza-create command begin 2.59.3: --exec-id=929-571b66d7 --log-level-console=info --log-level-file=detail --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --repo1-host=repository --repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt --repo1-host-cert-file=/etc/pgbackrest/cert/client.crt --repo1-host-key-file=/etc/pgbackrest/cert/client.key --repo1-host-type=tls --stanza=demo-alt
P00   INFO: stanza-create for stanza 'demo-alt' on repo1
P00   INFO: stanza-create command end: completed successfully
sudo -u postgres pgbackrest --log-level-console=info check
P00   INFO: check command begin 2.59.3: --exec-id=962-2cadc106 --log-level-console=info --log-level-file=detail --no-log-timestamp --repo1-host=repository --repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt --repo1-host-cert-file=/etc/pgbackrest/cert/client.crt --repo1-host-key-file=/etc/pgbackrest/cert/client.key --repo1-host-type=tls
P00   INFO: check stanza 'demo-alt'
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 000000010000000000000001 successfully archived to '/var/lib/pgbackrest/archive/demo-alt/14-1/0000000100000000/000000010000000000000001-5cb25be2e89d0324cc2a94cbc964295204118888.gz' on repo1
P00   INFO: check command end: completed successfully

Wird der Befehl check auf dem Repository-Host ausgeführt, werden alle Stanzas geprüft.

repository ⇒ Konfiguration aller Stanzas prüfen

sudo -u pgbackrest pgbackrest --log-level-console=info check
P00   INFO: check command begin 2.59.3: --exec-id=1384-3bcda35c --log-level-console=info --no-log-timestamp --repo1-path=/var/lib/pgbackrest
P00   INFO: check stanza 'demo'
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 000000070000000000000027 successfully archived to '/var/lib/pgbackrest/archive/demo/14-1/0000000700000000/000000070000000000000027-b36b790bcf0b1a9f54bc84458117feb77853d452.gz' on repo1
P00   INFO: check stanza 'demo-alt'
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 000000010000000000000002 successfully archived to '/var/lib/pgbackrest/archive/demo-alt/14-1/0000000100000000/000000010000000000000002-c303ffb17f8a111070459593520aa35640317a38.gz' on repo1
P00   INFO: check command end: completed successfully

Asynchrone Archivierung

Asynchrone Archivierung wird mit der Option archive-async aktiviert. Diese aktiviert den asynchronen Betrieb sowohl für archive-push als auch für archive-get.

Ein Spool-Pfad ist erforderlich. Die Befehle speichern dort vorübergehende Daten, arbeiten jedoch recht unterschiedlich. Daher wird die Verwendung des Spool-Pfads in den jeweiligen Abschnitten ausführlich beschrieben.

pg-primary ⇒ Spool-Verzeichnis erstellen

sudo mkdir -p -m 750 /var/spool/pgbackrest
sudo chown postgres:postgres /var/spool/pgbackrest

pg-standby ⇒ Spool-Verzeichnis erstellen

sudo mkdir -p -m 750 /var/spool/pgbackrest
sudo chown postgres:postgres /var/spool/pgbackrest

Der Spool-Pfad muss konfiguriert und die asynchrone Archivierung aktiviert werden. Schon die asynchrone Archivierung allein bringt Vorteile, weil sie die Zahl der Verbindungen zu entferntem Speicher verringert. Mit process-max kann die Leistung durch Parallelisierung der Vorgänge erheblich gesteigert werden. process-max darf dabei nicht so hoch gesetzt werden, dass der normale Datenbankbetrieb beeinträchtigt wird.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Spool-Pfad und asynchrone Archivierung konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data



[global]

archive-async=y

log-level-file=detail

repo1-host=repository

repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt

repo1-host-cert-file=/etc/pgbackrest/cert/client.crt

repo1-host-key-file=/etc/pgbackrest/cert/client.key

repo1-host-type=tls

spool-path=/var/spool/pgbackrest

tls-server-address=*

tls-server-auth=pgbackrest-client=demo

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key



[global:archive-get]

process-max=2



[global:archive-push]

process-max=2

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ Spool-Pfad und asynchrone Archivierung konfigurieren

[demo]

pg1-path=/var/lib/pgsql/14/data

recovery-option=primary_conninfo=host=172.17.0.6 port=5432 user=replicator



[global]

archive-async=y

log-level-file=detail

repo1-host=repository

repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt

repo1-host-cert-file=/etc/pgbackrest/cert/client.crt

repo1-host-key-file=/etc/pgbackrest/cert/client.key

repo1-host-type=tls

spool-path=/var/spool/pgbackrest

tls-server-address=*

tls-server-auth=pgbackrest-client=demo

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key



[global:archive-get]

process-max=2



[global:archive-push]

process-max=2

HINWEIS:

process-max wird in Befehlsabschnitten konfiguriert, damit die Option nicht von backup und restore verwendet wird. Dies ermöglicht auch unterschiedliche Werte für archive-push und archive-get.

Zur Demonstration wird die Streaming-Replikation unterbrochen, um PostgreSQL zum Abruf von WAL über restore_command zu zwingen.

pg-primary ⇒ Streaming-Replikation durch Änderung des Replikationspassworts unterbrechen

sudo -u postgres psql -c "alter user replicator password 'bogus'"
ALTER ROLE

pg-standby ⇒ Standby neu starten, um die Verbindung zu unterbrechen

sudo systemctl restart postgresql-14.service

Archivübertragung

Der asynchrone Befehl archive-push lagert die WAL-Archivierung in einen oder mehrere separate Prozesse aus, um den Durchsatz zu erhöhen. Er schaut gewissermaßen voraus und ermittelt, welche weiteren WAL-Segmente neben der aktuellen Anfrage von PostgreSQL über archive_command zur Archivierung bereitstehen. WAL-Segmente werden direkt aus dem Verzeichnis pg_xlog/pg_wal ins Archiv übertragen. archive_command meldet erst dann Erfolg, wenn das WAL-Segment sicher im Archiv gespeichert ist.

Der Spool-Pfad enthält den aktuellen Status der WAL-Archivierung. Die dort geschriebenen Statusdateien sind normalerweise leer und sollten nur minimalen Speicherplatz, höchstens einige MB, und sehr wenig IO beanspruchen. Alle Informationen in diesem Verzeichnis können neu erstellt werden. Bei einem Umzug des Clusters auf neue Hardware muss das Spool-Verzeichnis daher nicht aufbewahrt werden.

WICHTIG:

In der ursprünglichen Implementierung der asynchronen Archivierung wurden WAL-Segmente vor der Komprimierung und Übertragung in das Spool-Verzeichnis kopiert. Die neue Implementierung kopiert WAL direkt aus dem Verzeichnis pg_xlog. Wurde asynchrone Archivierung in v1.12 oder früher verwendet, vor dem Upgrade die Versionshinweise zu v1.13 sorgfältig lesen.

Mit der Datei [stanza]-archive-push-async.log lässt sich die Aktivität des asynchronen Prozesses überwachen. Ein guter Test ist die Übertragung mehrerer WAL-Segmente kurz hintereinander.

pg-primary ⇒ Parallele asynchrone Archivierung testen

sudo -u postgres psql -c " \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal();"
sudo -u postgres pgbackrest --stanza=demo --log-level-console=info check
P00   INFO: check command begin 2.59.3: --exec-id=6864-e51531e7 --log-level-console=info --log-level-file=detail --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --repo1-host=repository --repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt --repo1-host-cert-file=/etc/pgbackrest/cert/client.crt --repo1-host-key-file=/etc/pgbackrest/cert/client.key --repo1-host-type=tls --stanza=demo
P00   INFO: check repo1 configuration (primary)
P00   INFO: check repo1 archive for WAL (primary)
P00   INFO: WAL segment 00000007000000000000002D successfully archived to '/var/lib/pgbackrest/archive/demo/14-1/0000000700000000/00000007000000000000002D-7addc4d9a1861c1b8b68300ea3a7db01fbe08ae2.gz' on repo1
P00   INFO: check command end: completed successfully

Die Protokolldatei enthält nun parallele, asynchrone Aktivitäten.

pg-primary ⇒ Ergebnisse im Protokoll prüfen

sudo -u postgres cat /var/log/pgbackrest/demo-archive-push-async.log
-------------------PROCESS START-------------------
P00   INFO: archive-push:async command begin 2.59.3: [/var/lib/pgsql/14/data/pg_wal] --archive-async --exec-id=6828-6cf1b924 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --process-max=2 --repo1-host=repository --repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt --repo1-host-cert-file=/etc/pgbackrest/cert/client.crt --repo1-host-key-file=/etc/pgbackrest/cert/client.key --repo1-host-type=tls --spool-path=/var/spool/pgbackrest --stanza=demo
P00   INFO: push 1 WAL file(s) to archive: 000000070000000000000028
P01 DETAIL: pushed WAL file '000000070000000000000028' to the archive
P00 DETAIL: statistics: {"socket.client":{"total":1},"socket.session":{"total":1},"tls.client":{"total":1},"tls.session":{"total":1}}
P00   INFO: archive-push:async command end: completed successfully

-------------------PROCESS START-------------------
P00   INFO: archive-push:async command begin 2.59.3: [/var/lib/pgsql/14/data/pg_wal] --archive-async --exec-id=6866-2a936d60 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --process-max=2 --repo1-host=repository --repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt --repo1-host-cert-file=/etc/pgbackrest/cert/client.crt --repo1-host-key-file=/etc/pgbackrest/cert/client.key --repo1-host-type=tls --spool-path=/var/spool/pgbackrest --stanza=demo
P00   INFO: push 5 WAL file(s) to archive: 000000070000000000000029...00000007000000000000002D
P02 DETAIL: pushed WAL file '00000007000000000000002A' to the archive
P01 DETAIL: pushed WAL file '000000070000000000000029' to the archive
P01 DETAIL: pushed WAL file '00000007000000000000002C' to the archive
P02 DETAIL: pushed WAL file '00000007000000000000002B' to the archive
P01 DETAIL: pushed WAL file '00000007000000000000002D' to the archive
P00 DETAIL: statistics: {"socket.client":{"total":1},"socket.session":{"total":1},"tls.client":{"total":1},"tls.session":{"total":1}}
P00   INFO: archive-push:async command end: completed successfully

Archivabruf

Der asynchrone Befehl archive-get hält eine lokale WAL-Warteschlange vor, um den Durchsatz zu erhöhen. Fehlt ein WAL-Segment in der Warteschlange, wird es zusammen mit genügend nachfolgenden WAL-Segmenten zum Füllen der Warteschlange aus dem Repository abgerufen. Deren maximale Größe wird durch archive-get-queue-max festgelegt. Sobald die Warteschlange weniger als halb voll ist, wird weiteres WAL zum Auffüllen abgerufen.

Der asynchrone Betrieb ist besonders nützlich in Umgebungen, die viel WAL erzeugen oder eine Verbindung mit hoher Latenz zum Repository-Speicher haben, etwa zu S3 oder anderen Objektspeichern. Bei hoher Verbindungslatenz kann es sinnvoll sein, process-max zu erhöhen.

Mit der Datei [stanza]-archive-get-async.log lässt sich die Aktivität des asynchronen Prozesses überwachen.

pg-standby ⇒ Ergebnisse im Protokoll prüfen

sudo -u postgres cat /var/log/pgbackrest/demo-archive-get-async.log
-------------------PROCESS START-------------------
P00   INFO: archive-get:async command begin 2.59.3: [000000070000000000000024, 000000070000000000000025, 000000070000000000000026, 000000070000000000000027, 000000070000000000000028, 000000070000000000000029, 00000007000000000000002A, 00000007000000000000002B] --archive-async --exec-id=1919-a90112cb --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --process-max=2 --repo1-host=repository --repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt --repo1-host-cert-file=/etc/pgbackrest/cert/client.crt --repo1-host-key-file=/etc/pgbackrest/cert/client.key --repo1-host-type=tls --spool-path=/var/spool/pgbackrest --stanza=demo
P00   INFO: get 8 WAL file(s) from archive: 000000070000000000000024...00000007000000000000002B
P01 DETAIL: found 000000070000000000000024 in the repo1: 14-1 archive
P02 DETAIL: found 000000070000000000000025 in the repo1: 14-1 archive
P02 DETAIL: found 000000070000000000000027 in the repo1: 14-1 archive
P01 DETAIL: found 000000070000000000000026 in the repo1: 14-1 archive
P00 DETAIL: unable to find 000000070000000000000028 in the archive
P00 DETAIL: statistics: {"socket.client":{"total":1},"socket.session":{"total":1},"tls.client":{"total":1},"tls.session":{"total":1}}
       [filtered 31 lines of output]
P00   INFO: archive-get:async command begin 2.59.3: [000000070000000000000028, 000000070000000000000029, 00000007000000000000002A, 00000007000000000000002B, 00000007000000000000002C, 00000007000000000000002D, 00000007000000000000002E, 00000007000000000000002F] --archive-async --exec-id=1976-2ef79408 --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/pgsql/14/data --process-max=2 --repo1-host=repository --repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt --repo1-host-cert-file=/etc/pgbackrest/cert/client.crt --repo1-host-key-file=/etc/pgbackrest/cert/client.key --repo1-host-type=tls --spool-path=/var/spool/pgbackrest --stanza=demo
P00   INFO: get 8 WAL file(s) from archive: 000000070000000000000028...00000007000000000000002F
P01 DETAIL: found 000000070000000000000028 in the repo1: 14-1 archive
P02 DETAIL: found 000000070000000000000029 in the repo1: 14-1 archive
P01 DETAIL: found 00000007000000000000002A in the repo1: 14-1 archive
P02 DETAIL: found 00000007000000000000002B in the repo1: 14-1 archive
P02 DETAIL: found 00000007000000000000002D in the repo1: 14-1 archive
P01 DETAIL: found 00000007000000000000002C in the repo1: 14-1 archive
P00 DETAIL: unable to find 00000007000000000000002E in the archive
P00 DETAIL: statistics: {"socket.client":{"total":1},"socket.session":{"total":1},"tls.client":{"total":1},"tls.session":{"total":1}}
       [filtered 14 lines of output]

pg-primary ⇒ Streaming-Replikation durch Änderung des Replikationspassworts reparieren

sudo -u postgres psql -c "alter user replicator password 'jw8s0F4'"
ALTER ROLE

Backup von einem Standby

pgBackRest kann Backups auf einem Standby statt auf dem Primärserver durchführen. Dazu muss der Host pg-standby konfiguriert und die Option backup-standby aktiviert sein. Sind mehrere Standbys konfiguriert, wird der erste gefundene laufende Standby für das Backup verwendet.

repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg2-host/pg2-host-user und pg2-path konfigurieren

[demo]

pg1-host=pg-primary

pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg1-host-cert-file=/etc/pgbackrest/cert/client.crt

pg1-host-key-file=/etc/pgbackrest/cert/client.key

pg1-host-type=tls

pg1-path=/var/lib/pgsql/14/data

pg2-host=pg-standby

pg2-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg2-host-cert-file=/etc/pgbackrest/cert/client.crt

pg2-host-key-file=/etc/pgbackrest/cert/client.key

pg2-host-type=tls

pg2-path=/var/lib/pgsql/14/data



[demo-alt]

pg1-host=pg-alt

pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg1-host-cert-file=/etc/pgbackrest/cert/client.crt

pg1-host-key-file=/etc/pgbackrest/cert/client.key

pg1-host-type=tls

pg1-path=/var/lib/pgsql/14/data



[global]

backup-standby=y

process-max=3

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

tls-server-address=*

tls-server-auth=pgbackrest-client=*

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key

Für das Backup werden sowohl die Datenbank auf dem Primärserver als auch die auf dem Standby benötigt. Der weitaus größte Teil der Dateien wird jedoch vom Standby kopiert, um den Primärserver zu entlasten. Die Datenbankhosts können in beliebiger Reihenfolge konfiguriert werden. pgBackRest erkennt automatisch, welcher Host der Primärserver und welcher der Standby ist.

repository ⇒ Backup des Demo-Clusters von pg2 erstellen

sudo -u pgbackrest pgbackrest --stanza=demo --log-level-console=detail backup
       [filtered 2 lines of output]
P00   INFO: execute backup start: backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 00000007000000000000002F, lsn = 0/2F000028
P00   INFO: wait for replay on the standby to reach 0/2F000028
P00   INFO: replay on the standby reached 0/2F000028
P00   INFO: check archive for prior segment 00000007000000000000002E
P01 DETAIL: backup file pg-primary:/var/lib/pgsql/14/data/log/postgresql.log (10.9KB, 0.42%) checksum dbfa988289c2ff32dcd198f19455165722870b43
P01 DETAIL: backup file pg-primary:/var/lib/pgsql/14/data/global/pg_control (8KB, 0.73%) checksum 0a793efbb7bb2e255bbb2bfac8f612bc943c7f31
P01 DETAIL: backup file pg-primary:/var/lib/pgsql/14/data/pg_hba.conf (4.5KB, 0.90%) checksum cfa97af1dab1b130f0a921fa2d10d76fe0c5f630
P01 DETAIL: match file from prior backup pg-primary:/var/lib/pgsql/14/data/current_logfiles (26B, 0.91%) checksum 78a9f5c10960f0d91fcd313937469824861795a2
P01 DETAIL: match file from prior backup pg-primary:/var/lib/pgsql/14/data/pg_logical/replorigin_checkpoint (8B, 0.91%) checksum 347fc8f2df71bd4436e38bd1516ccd7ea0d46532
       [filtered 1263 lines of output]

Dieses inkrementelle Backup zeigt, dass die meisten Dateien vom Host pg-standby und nur wenige vom Host pg-primary kopiert werden.

pgBackRest erstellt auf dem Standby ein Backup, das mit einem auf dem Primärserver durchgeführten Backup identisch ist. Dazu startet und beendet es das Backup auf dem Host pg-primary, kopiert die replizierten Dateien vom Host pg-standby und anschließend die wenigen übrigen Dateien von pg-primary. Damit enthält das Backup auch Protokolle und Statistiken der primären Datenbank.

Upgrade von PostgreSQL

Unmittelbar nach dem Upgrade von PostgreSQL auf eine neuere Hauptversion muss pg-path in allen pgBackRest-Konfigurationen auf den neuen Datenbankspeicherort gesetzt und der Befehl stanza-upgrade ausgeführt werden. Sind auf dem Host mehrere Repositorys konfiguriert, wird die Stanza in jedem davon aktualisiert. Ist die Datenbank offline, die Option --no-online verwenden.

Die folgenden Anweisungen sind keine umfassende Anleitung zum Upgrade von PostgreSQL. Sie skizzieren den allgemeinen Ablauf für ein Upgrade von Primärserver und Standby, um die zur Neukonfiguration von pgBackRest erforderlichen Schritte zu zeigen. Vor dem Upgrade wird ein Backup empfohlen.

pg-primary ⇒ Alten Cluster stoppen

sudo systemctl stop postgresql-14.service

Den alten Cluster auf dem Standby stoppen, da er aus dem gerade aktualisierten Cluster wiederhergestellt wird.

pg-standby ⇒ Alten Cluster stoppen

sudo systemctl stop postgresql-14.service

Den neuen Cluster erstellen und das Upgrade durchführen.

pg-primary ⇒ Neuen Cluster erstellen und Upgrade durchführen

sudo -u postgres /usr/pgsql-15/bin/initdb \
       -D /var/lib/pgsql/15/data -k -A peer
sudo -u postgres sh -c 'cd /var/lib/pgsql && \
       /usr/pgsql-15/bin/pg_upgrade \
       --old-bindir=/usr/pgsql-14/bin \
       --new-bindir=/usr/pgsql-15/bin \
       --old-datadir=/var/lib/pgsql/14/data \
       --new-datadir=/var/lib/pgsql/15/data \
       --old-options=" -c config_file=/var/lib/pgsql/14/data/postgresql.conf" \
       --new-options=" -c config_file=/var/lib/pgsql/15/data/postgresql.conf"'
       [filtered 41 lines of output]
Checking for extension updates                              ok
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade.
       [filtered 4 lines of output]

Die Einstellungen und den Port des neuen Clusters konfigurieren.

pg-primary:/var/lib/pgsql/15/data/postgresql.conf ⇒ PostgreSQL konfigurieren

archive_command = 'pgbackrest --stanza=demo archive-push %p'

archive_mode = on

log_filename = 'postgresql.log'

Die pgBackRest-Konfiguration auf allen Systemen so anpassen, dass sie auf den neuen Cluster verweist.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-path aktualisieren

[demo]

pg1-path=/var/lib/pgsql/15/data



[global]

archive-async=y

log-level-file=detail

repo1-host=repository

repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt

repo1-host-cert-file=/etc/pgbackrest/cert/client.crt

repo1-host-key-file=/etc/pgbackrest/cert/client.key

repo1-host-type=tls

spool-path=/var/spool/pgbackrest

tls-server-address=*

tls-server-auth=pgbackrest-client=demo

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key



[global:archive-get]

process-max=2



[global:archive-push]

process-max=2

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ pg-path aktualisieren

[demo]

pg1-path=/var/lib/pgsql/15/data

recovery-option=primary_conninfo=host=172.17.0.6 port=5432 user=replicator



[global]

archive-async=y

log-level-file=detail

repo1-host=repository

repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt

repo1-host-cert-file=/etc/pgbackrest/cert/client.crt

repo1-host-key-file=/etc/pgbackrest/cert/client.key

repo1-host-type=tls

spool-path=/var/spool/pgbackrest

tls-server-address=*

tls-server-auth=pgbackrest-client=demo

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key



[global:archive-get]

process-max=2



[global:archive-push]

process-max=2

repository:/etc/pgbackrest/pgbackrest.conf ⇒ pg1-path und pg2-path aktualisieren und Backup vom Standby deaktivieren

[demo]

pg1-host=pg-primary

pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg1-host-cert-file=/etc/pgbackrest/cert/client.crt

pg1-host-key-file=/etc/pgbackrest/cert/client.key

pg1-host-type=tls

pg1-path=/var/lib/pgsql/15/data

pg2-host=pg-standby

pg2-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg2-host-cert-file=/etc/pgbackrest/cert/client.crt

pg2-host-key-file=/etc/pgbackrest/cert/client.key

pg2-host-type=tls

pg2-path=/var/lib/pgsql/15/data



[demo-alt]

pg1-host=pg-alt

pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg1-host-cert-file=/etc/pgbackrest/cert/client.crt

pg1-host-key-file=/etc/pgbackrest/cert/client.key

pg1-host-type=tls

pg1-path=/var/lib/pgsql/14/data



[global]

backup-standby=n

process-max=3

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

tls-server-address=*

tls-server-auth=pgbackrest-client=*

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key

pg-primary ⇒ hba-Konfiguration kopieren

sudo cp /var/lib/pgsql/14/data/pg_hba.conf \
       /var/lib/pgsql/15/data/pg_hba.conf

Vor dem Start des neuen Clusters muss der Befehl stanza-upgrade ausgeführt werden.

pg-primary ⇒ Stanza aktualisieren

sudo -u postgres pgbackrest --stanza=demo --no-online \
       --log-level-console=info stanza-upgrade
P00   INFO: stanza-upgrade command begin 2.59.3: --exec-id=7454-62cfb155 --log-level-console=info --log-level-file=detail --no-log-timestamp --no-online --pg1-path=/var/lib/pgsql/15/data --repo1-host=repository --repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt --repo1-host-cert-file=/etc/pgbackrest/cert/client.crt --repo1-host-key-file=/etc/pgbackrest/cert/client.key --repo1-host-type=tls --stanza=demo
P00   INFO: stanza-upgrade for stanza 'demo' on repo1
P00   INFO: stanza-upgrade command end: completed successfully

Den neuen Cluster starten und den Erfolg der Installation prüfen.

pg-primary ⇒ Neuen Cluster starten

sudo systemctl start postgresql-15.service

Die Konfiguration mit dem Befehl check testen.

pg-primary ⇒ Konfiguration prüfen

sudo systemctl status postgresql-15.service
sudo -u postgres pgbackrest --stanza=demo check

Den alten Cluster entfernen.

pg-primary ⇒ Alten Cluster entfernen

sudo rm -rf /var/lib/pgsql/14/data

Die neuen PostgreSQL-Binärdateien auf dem Standby installieren und den Cluster erstellen.

pg-standby ⇒ Alten Cluster entfernen und neuen Cluster erstellen

sudo rm -rf /var/lib/pgsql/14/data
sudo -u postgres mkdir -p -m 700 /usr/pgsql-15/bin

check auf dem Repository-Host ausführen. Die Warnung zum nicht verfügbaren Standby ist zu erwarten, da der Standby-Cluster gestoppt ist. Die Ausführung zeigt, dass der Repository-Server den Standby kennt und für den Primärserver korrekt konfiguriert ist.

repository ⇒ Konfiguration prüfen

sudo -u pgbackrest pgbackrest --stanza=demo check
P00   WARN: unable to check pg2: [DbConnectError] raised from remote-0 tls protocol on 'pg-standby': unable to connect to 'dbname='postgres' port=5432': connection to server on socket "/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
                Is the server running locally and accepting connections on that socket?

Ein vollständiges Backup des neuen Clusters durchführen und anschließend den Standby daraus wiederherstellen. Wird incr oder diff angefordert, wird der Backup-Typ automatisch auf full geändert.

repository ⇒ Vollständiges Backup durchführen

sudo -u pgbackrest pgbackrest --stanza=demo --type=full backup

pg-standby ⇒ Demo-Standby-Cluster wiederherstellen

sudo -u postgres pgbackrest --stanza=demo --type=standby restore

pg-standby ⇒ PostgreSQL starten und pgBackRest-Konfiguration prüfen

sudo systemctl start postgresql-15.service
sudo -u postgres pgbackrest --stanza=demo check

Nach der Wiederherstellung des Standbys kann das Backup vom Standby aktiviert werden.

repository:/etc/pgbackrest/pgbackrest.conf ⇒ Backup vom Standby wieder aktivieren

[demo]

pg1-host=pg-primary

pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg1-host-cert-file=/etc/pgbackrest/cert/client.crt

pg1-host-key-file=/etc/pgbackrest/cert/client.key

pg1-host-type=tls

pg1-path=/var/lib/pgsql/15/data

pg2-host=pg-standby

pg2-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg2-host-cert-file=/etc/pgbackrest/cert/client.crt

pg2-host-key-file=/etc/pgbackrest/cert/client.key

pg2-host-type=tls

pg2-path=/var/lib/pgsql/15/data



[demo-alt]

pg1-host=pg-alt

pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt

pg1-host-cert-file=/etc/pgbackrest/cert/client.crt

pg1-host-key-file=/etc/pgbackrest/cert/client.key

pg1-host-type=tls

pg1-path=/var/lib/pgsql/14/data



[global]

backup-standby=y

process-max=3

repo1-path=/var/lib/pgbackrest

repo1-retention-full=2

start-fast=y

tls-server-address=*

tls-server-auth=pgbackrest-client=*

tls-server-ca-file=/etc/pgbackrest/cert/ca.crt

tls-server-cert-file=/etc/pgbackrest/cert/server.crt

tls-server-key-file=/etc/pgbackrest/cert/server.key

4 - Befehlsreferenz

pgBackRest-Befehlsreferenz mit allen Optionen für Backup-, Wiederherstellungs-, Archiv- und Verwaltungsvorgänge.

Einführung

Befehle führen die verschiedenen pgBackRest-Funktionen aus. Hier sind sämtliche Befehlsoptionen aufgeführt: Jede auf einen Befehl anwendbare Option wird bei diesem Befehl genannt, auch wenn sie für weitere Befehle gilt. Dazu gehören alle Optionen, die auch in pgbackrest.conf konfiguriert werden können.

Nicht boolesche Optionen aus pgbackrest.conf lassen sich über die Befehlszeile mit dem Präfix reset- auf ihren Standardwert zurücksetzen. Damit kann ein Backup direkt auf einem Repository-Host wiederhergestellt werden. Normalerweise meldet pgBackRest einen Fehler, weil es erkennt, dass sich die Datenbank auf einem entfernten Host befindet und Wiederherstellungen nicht aus der Ferne möglich sind. Mit --reset-pg1-host in der Befehlszeile ignoriert pgBackRest den entfernten Datenbank-Host und führt die Wiederherstellung lokal aus. Möglicherweise muss ein neuer Wert für --pg1-path angegeben werden, um die Wiederherstellung in einem bestimmten Pfad zu erzwingen, also nicht in dem auf dem Datenbank-Host verwendeten Pfad.

Mit dem Präfix no- lässt sich eine boolesche Option über die Befehlszeile auf false setzen.

Jede Option kann über eine Umgebungsvariable gesetzt werden. Dazu werden das Präfix PGBACKREST_ und der Optionsname in Großbuchstaben verwendet, wobei - durch _ ersetzt wird. Beispielsweise wird pg1-path zu PGBACKREST_PG1_PATH und stanza zu PGBACKREST_STANZA. Boolesche Optionen werden wie in einer Konfigurationsdatei angegeben, etwa PGBACKREST_COMPRESS="n"; Varianten mit reset-* sind nicht zulässig. Für Optionen, die mehrfach in der Befehlszeile oder einer Konfigurationsdatei angegeben werden können, werden die Werte durch Doppelpunkte getrennt, etwa PGBACKREST_DB_INCLUDE="db1:db2".

Befehlszeilenoptionen haben Vorrang vor Umgebungsvariablen; diese haben wiederum Vorrang vor Optionen aus der Konfigurationsdatei.

Informationen zu den Optionentypen finden Sie in der Einführung zur Konfiguration

Befehle

Befehl Zusammenfassung
annotate Backup-Anmerkungen nach der Erstellung des Backups hinzufügen, ändern oder entfernen.
archive-get Archivierte WAL-Segmente für Wiederherstellung, PITR oder die Recovery eines Replikats abrufen.
archive-push WAL-Segmente von PostgreSQL entgegennehmen und an die konfigurierten Repositorys übertragen.
backup Backups im Ziel-Repository erstellen (standardmäßig im Repository mit der höchsten Priorität).
check Die Backup- und Archivkonfiguration einer Stanza und die Funktionsfähigkeit der WAL-Archivierung prüfen.
expire Backups und archivierte WAL gemäß den konfigurierten Aufbewahrungsregeln entfernen.
help Allgemeine Hilfe oder Hilfe zu einem Befehl oder einer Option anzeigen.
info Status und Metadaten von Stanzas und Backups im Text- oder JSON-Format anzeigen.
repo-get Repository-Dateien für Verwaltung, Untersuchung und Tests lesen (wie cat).
repo-ls Repository-Dateien und -Pfade für Verwaltung, Untersuchung und Tests auflisten (wie ls).
restore Ein Backup wiederherstellen (standardmäßig das neueste), optional mit Point-in-Time-Recovery.
server Den pgBackRest-TLS-Server für den Zugriff auf entfernte Hosts ohne SSH ausführen.
server-ping Einen pgBackRest-TLS-Server mit einem Ping darauf prüfen, ob er Verbindungen annimmt.
stanza-create Stanza-Metadaten in allen konfigurierten Repositorys erstellen.
stanza-delete Alle Backups und Archive einer Stanza dauerhaft entfernen.
stanza-upgrade Stanza-Metadaten nach einem Upgrade auf eine neue PostgreSQL-Hauptversion aktualisieren.
start Die Ausführung von pgBackRest-Prozessen nach einem vorherigen stop wieder zulassen.
stop Neue pgBackRest-Prozesse verhindern und laufende Prozesse optional zwangsweise beenden.
verify Die Gültigkeit der Backup- und Archivdaten im Repository prüfen.
version Die installierte pgBackRest-Version anzeigen.

4.1 - Befehl für Anmerkungen (annotate)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls annotate.

Mit dem Befehl backup angegebene Anmerkungen können nachträglich mit dem Befehl annotate hinzugefügt, geändert oder entfernt werden.

Befehlsoptionen

Option für Backup-Anmerkungen (--annotation)

Das Backup mit benutzerdefinierten Schlüssel/Wert-Paaren versehen.

Benutzer können dem Backup informative Schlüssel/Wert-Paare hinzufügen. Diese Option kann mehrfach verwendet werden, um mehrere Anmerkungen hinzuzufügen.

Anmerkungen erscheinen in der Textausgabe des Befehls info, wenn mit --set ein Backup angegeben wird. In der JSON-Ausgabe erscheinen sie immer.

example: --annotation=source="Sunday backup for website database"

Option zur Auswahl des Backup-Satzes (--set)

Backup-Satz, dessen Anmerkungen bearbeitet werden sollen.

Der Backup-Satz, dessen Anmerkungen bearbeitet werden sollen.

example: --set=20150131-153358F_20150131-153401I

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Repository-Optionen

Option zur Auswahl des Repositorys (--repo)

Repository festlegen.

Legt das Repository fest, auf das ein Befehl wirken soll.

Damit kann beispielsweise eine Wiederherstellung aus einem bestimmten Repository durchgeführt werden, anstatt pgBackRest die Auswahl zu überlassen.

allowed: [1, 256]
example: --repo=1

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

4.2 - Befehl zum Abrufen aus dem Archiv (archive-get)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls archive-get.

PostgreSQL verwendet diesen Befehl, um ein Backup wiederherzustellen, PITR durchzuführen oder ein Replikat als Alternative zum Streaming aktuell zu halten. WAL-Segmente werden für die PostgreSQL-Recovery oder zur Pflege eines Replikats benötigt.

Sind mehrere Repositorys konfiguriert, werden WAL-Segmente in der Reihenfolge ihrer Priorität aus ihnen abgerufen (z. B. repo1, repo2 usw.). Im Allgemeinen sollte schnellerer oder günstigerer Speicher eine höhere Priorität erhalten. Wird mit --repo ein Repository angegeben, wird nur dieses durchsucht.

pgBackRest konfiguriert und erzeugt den Befehl archive-get während einer Wiederherstellung zur Verwendung durch PostgreSQL. Ein Beispiel finden Sie unter Point-in-Time-Recovery .

Befehlsoptionen

Option für asynchrone Archivierung (--archive-async)

WAL-Segmente asynchron übertragen und abrufen.

Aktiviert den asynchronen Betrieb für die Befehle archive-push und archive-get.

Der asynchrone Betrieb ist effizienter, da er Verbindungen wiederverwenden und parallele Verarbeitung nutzen kann. Weitere Informationen bieten die Optionen spool-path, archive-get-queue-max und archive-push-queue-max.

default: n
example: --archive-async

Option für die maximale Größe der Abrufwarteschlange (--archive-get-queue-max)

Maximale Größe der archive-get-Warteschlange von pgBackRest.

Legt die maximale Größe der archive-get-Warteschlange fest, wenn archive-async aktiviert ist. Die Warteschlange liegt im spool-path und beschleunigt die Bereitstellung von WAL für PostgreSQL.

default: 128MiB
allowed: [0B, 4PiB]
example: --archive-get-queue-max=1GiB

Option zum erneuten Abruf fehlender WAL-Segmente (--archive-missing-retry)

Abruf fehlender WAL-Segmente erneut versuchen

Ein WAL-Segment erneut abrufen, das der Befehl archive-get im asynchronen Modus zuvor als fehlend gemeldet hat. Dies verhindert, dass Meldungen einer früheren Wiederherstellung aus dem Spool-Pfad verwendet werden und möglicherweise die Recovery scheitern lassen, wenn noch kein konsistenter Zustand erreicht wurde.

Bei deaktivierter Option kann PostgreSQL zuverlässiger erkennen, wann das Ende des WAL im Archiv erreicht ist, und dann zum Streaming vom Primärserver wechseln. Bei aktivierten Wiederholungsversuchen führt ein stetiger Strom neu archivierter WAL-Segmente dazu, dass PostgreSQL weiterhin WAL aus dem Archiv abruft, statt zum Streaming zu wechseln.

Wird diese Option deaktiviert, muss sichergestellt werden, dass der Spool-Pfad der Stanza leer ist. Der Befehl restore erledigt dies automatisch, wenn der Spool-Pfad zum Zeitpunkt der Wiederherstellung konfiguriert ist. Andernfalls muss der Benutzer selbst dafür sorgen, dass der Spool-Pfad leer ist.

default: y
example: --no-archive-missing-retry

Option für das Archivierungszeitlimit (--archive-timeout)

Archivierungszeitlimit.

Maximale Wartezeit in Sekunden festlegen, bis ein einzelnes WAL-Segment das Archiv-Repository von pgBackRest erreicht. Dieses Zeitlimit gilt für die Befehle check und backup, wenn sie auf die Archivierung der WAL-Segmente warten, die für ein konsistentes Backup erforderlich sind.

default: 1m
allowed: [100ms, 1d]
example: --archive-timeout=30

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den pgBackRest-Befehl (--cmd)

pgBackRest-Befehl.

pgBackRest kann eine Befehlszeichenfolge erzeugen, etwa wenn der Befehl restore die Einstellung restore_command erzeugt. Dafür wird der Befehl verwendet, mit dem der pgBackRest-Prozess gestartet wurde, sofern nicht die Option cmd angegeben ist.

ACHTUNG:

Das Einbetten des pgBackRest-Befehls in einen Wrapper kann unvorhersehbares Verhalten verursachen und wird nicht empfohlen.

default: [path of executed pgbackrest binary]
example: --cmd=/var/lib/pgsql/bin/pgbackrest_wrapper.sh

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für die maximale Prozessanzahl (--process-max)

Maximale Anzahl der Prozesse für Komprimierung und Übertragung.

Jeder Prozess führt Komprimierung und Übertragung aus, um den Befehl zu beschleunigen. process-max jedoch nicht so hoch setzen, dass die Datenbankleistung beeinträchtigt wird.

default: 1
allowed: [1, 999]
example: --process-max=4

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für den Spool-Pfad (--spool-path)

Pfad zum Speichern vorübergehend benötigter Daten.

In diesem Pfad werden Daten für die asynchronen Befehle archive-push und archive-get gespeichert.

Der asynchrone Befehl archive-push schreibt Bestätigungen in den Spool-Pfad, wenn WAL erfolgreich im Archiv gespeichert wurde, und Fehlermeldungen bei einem Fehlschlag. So kann der Vordergrundprozess PostgreSQL schnell benachrichtigen. Die Bestätigungsdateien sind sehr klein: bei Erfolg leer, bei Fehlern wenige hundert Byte groß.

Der asynchrone Befehl archive-get hält WAL im Spool-Pfad bereit, damit es auf Anfrage von PostgreSQL sehr schnell geliefert werden kann. Das Verschieben der Dateien zu PostgreSQL ist am effizientesten, wenn der Spool-Pfad auf demselben Dateisystem wie pg_xlog/pg_wal liegt. Es wird jedoch davon abgeraten, den Spool-Pfad innerhalb des Verzeichnisses pg_xlog/pg_wal anzulegen, da dies bei PostgreSQL-Werkzeugen wie pg_rewind Probleme verursachen kann.

Die Daten im Spool-Pfad sind nicht rein temporär, da sie einen Neustart überdauern können und sollten. Ihr Verlust ist jedoch kein Problem: Für archive-push prüft pgBackRest einfach jedes WAL-Segment erneut auf sichere Archivierung; für archive-get baut es die Warteschlange neu auf.

Der Spool-Pfad ist für ein lokales POSIX-kompatibles Dateisystem vorgesehen, nicht für ein entferntes Dateisystem wie NFS oder CIFS.

default: /var/spool/pgbackrest
example: --spool-path=/backup/db/spool

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Optionen für Maintainer

Option zum Erzwingen der PostgreSQL-Version (--pg-version-force)

PostgreSQL-Version erzwingen.

Verwendet die angegebene PostgreSQL-Version statt der Version, die automatisch aus pg_control oder WAL-Headern ermittelt wird. Dies ist hauptsächlich für PostgreSQL-Forks oder Entwicklungsversionen hilfreich, deren Werte von denen der veröffentlichten Version abweichen. Die von PostgreSQL über server_version_num gemeldete Version muss mit der erzwungenen Version übereinstimmen.

WARNUNG:

Diese Option mit Vorsicht verwenden: pg_control und WAL-Header werden weiterhin im erwarteten Format der angegebenen Version gelesen, also im Format der offiziellen Open-Source-Version von PostgreSQL. Ändert der Fork oder die Entwicklungsversion das Format von Feldern, auf die pgBackRest angewiesen ist, führt dies zu unerwartetem Verhalten. Im Allgemeinen funktioniert diese Option nur dann wie erwartet, wenn der Fork alle eigenen Strukturfelder nach den standardmäßigen PostgreSQL-Feldern hinzufügt.

example: --pg-version-force=15

Repository-Optionen

Option zur Auswahl des Repositorys (--repo)

Repository festlegen.

Legt das Repository fest, auf das ein Befehl wirken soll.

Damit kann beispielsweise eine Wiederherstellung aus einem bestimmten Repository durchgeführt werden, anstatt pgBackRest die Auswahl zu überlassen.

allowed: [1, 256]
example: --repo=1

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Zielzeitpunkt des Repositorys (--repo-target-time)

Zielzeitpunkt für das Repository.

Der Zielzeitpunkt legt fest, welchen Stand des Repositorys Befehle auf versioniertem Speicher lesen. So lässt sich das Repository zu einem früheren Zeitpunkt lesen, um Daten wiederherzustellen, die versehentlich durch Benutzer oder durch Schadsoftware gelöscht oder beschädigt wurden.

S3, GCS und Azure unterstützen versionierten Speicher, aktivieren ihn aber im Allgemeinen nicht standardmäßig. Neben der Versionierung kann es sinnvoll sein, bei S3 die Objektsperre und bei GCS oder Azure das vorläufige Löschen zu aktivieren.

Wenn repo-target-time angegeben wird, muss auch die Option repo angegeben werden. Wahrscheinlich unterstützen nicht alle Repository-Typen die Versionierung. Im Allgemeinen ist es sinnvoll, für die Wiederherstellung ein einzelnes Repository auszuwählen.

Beim Vergleich werden Speicherzeitstempel berücksichtigt, die <= dem angegebenen Zeitstempel sind. Enthaltene Millisekunden werden abgeschnitten.

example: --repo-target-time=2024-08-08 12:12:12+00

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

Stanza-Optionen

Option für den PostgreSQL-Pfad (--pg-path)

PostgreSQL-Datenverzeichnis.

Dieser Pfad sollte dem von PostgreSQL gemeldeten data_directory entsprechen. Obwohl sich der Wert an verschiedenen Stellen auslesen lässt, ist eine ausdrückliche Angabe ratsam, falls diese Quellen bei einer Wiederherstellung oder einem Offline-Backup nicht verfügbar sind.

Bei jedem Online-Backup wird pg-path mit dem von PostgreSQL gemeldeten Wert verglichen. Die Option sollte daher immer aktuell sein.

example: --pg1-path=/data/db

Veralteter Name: db-path

4.3 - Befehl zum Übertragen ins Archiv (archive-push)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls archive-push.

Nimmt ein WAL-Segment von PostgreSQL entgegen und archiviert es in jedem Repository, das durch die indizierte Option repo-path definiert ist. Informationen zur Konfiguration der Repositorys finden Sie im Abschnitt Repository . Abhängig von archive-async wird das WAL-Segment sofort ins Archiv übertragen oder lokal gespeichert. Sind mehrere Repositorys konfiguriert, versucht archive-push, das Segment an möglichst viele davon zu übertragen.

archive-push ist zur Konfiguration und zum Aufruf durch PostgreSQL vorgesehen. Ein Beispiel finden Sie unter Archivierung konfigurieren .

Befehlsoptionen

Option für asynchrone Archivierung (--archive-async)

WAL-Segmente asynchron übertragen und abrufen.

Aktiviert den asynchronen Betrieb für die Befehle archive-push und archive-get.

Der asynchrone Betrieb ist effizienter, da er Verbindungen wiederverwenden und parallele Verarbeitung nutzen kann. Weitere Informationen bieten die Optionen spool-path, archive-get-queue-max und archive-push-queue-max.

default: n
example: --archive-async

Option zur Archivprüfung (--archive-check)

Vor Abschluss des Backups prüfen, ob sich die WAL-Segmente im Archiv befinden.

Prüft, ob alle für ein konsistentes Backup erforderlichen WAL-Segmente im WAL-Archiv vorhanden sind. Es empfiehlt sich, die Standardeinstellung beizubehalten, sofern keine andere Archivierungsmethode verwendet wird.

Diese Option muss aktiviert sein, wenn archive-copy aktiviert ist.

default: y
example: --no-archive-check

Option zur Prüfung des Archivierungsmodus (--archive-mode-check)

Die PostgreSQL-Einstellung archive_mode prüfen.

Diese standardmäßig aktivierte Option verbietet die PostgreSQL-Einstellung archive_mode=always.

Von einem Standby-Server übertragene WAL-Segmente können logisch mit denen des Primärservers übereinstimmen, aber andere Prüfsummen aufweisen. Zur Vermeidung von Konflikten wird empfohlen, die Archivierung aus mehreren Quellen zu unterbinden.

ACHTUNG:

Bei deaktivierter Option muss unbedingt sichergestellt werden, dass nur ein Archivierer mit dem Befehl archive-push in das Repository schreibt.

default: y
example: --no-archive-mode-check

Option für die Datenmenge pro Archivierungslauf (--archive-push-batch-size)

Maximale WAL-Menge, die pro asynchronem Lauf übertragen wird.

Im asynchronen Modus überträgt der Prozess archive-push alle bereitstehenden WAL-Segmente in einem Lauf. Da archive-push-queue-max nur zu Beginn jedes Laufs geprüft wird, kann die Warteschlange bei einem Lauf mit sehr vielen Segmenten weit über den Grenzwert hinaus wachsen, bevor sie erneut geprüft wird.

Diese Option begrenzt die pro Lauf verarbeitete WAL-Menge. Der Prozess beendet sich dadurch und wird beim nächsten archive-push neu gestartet, wobei die Warteschlange erneut geprüft wird. Kleinere Werte führen zu häufigeren Prüfungen, erfordern aber auch häufigere Starts des asynchronen Prozesses. Der Wert wird auf eine ganze Anzahl von WAL-Segmenten abgerundet; mindestens ein Segment wird jedoch immer verarbeitet.

default: 16GiB
allowed: [1MiB, 4PiB]
example: --archive-push-batch-size=1GiB

Option für die maximale Größe der Archivierungswarteschlange (--archive-push-queue-max)

Maximale Größe der PostgreSQL-Archivierungswarteschlange.

Nach Erreichen des Grenzwerts geschieht Folgendes:

  • pgBackRest meldet PostgreSQL, dass das WAL erfolgreich archiviert wurde, und wird es dann VERWERFEN.
  • Eine Warnung wird in das PostgreSQL-Protokoll geschrieben.

Dadurch wird der Archivprotokollstrom unterbrochen, und PITR ist über diesen Punkt hinaus nicht mehr möglich. Ein neues Backup ist erforderlich, um die vollständige Wiederherstellbarkeit erneut herzustellen.

Im asynchronen Modus wird die gesamte Warteschlange verworfen. So wird verhindert, dass kurzzeitig wieder einzelne WAL-Segmente archiviert werden, bevor die Grenze erneut überschritten wird.

Im asynchronen Modus wird diese Grenze nur zu Beginn jedes archive-push-Laufs geprüft. Daher kann die Warteschlange innerhalb eines Laufs darüber hinaus wachsen. archive-push-batch-size verringern, um die Warteschlange häufiger zu prüfen.

Diese Funktion soll verhindern, dass das Volume mit den Protokolldateien voll wird, da PostgreSQL dann vollständig zum Stillstand kommt. Es ist besser, das Backup zu verlieren, als PostgreSQL ausfallen zu lassen.

allowed: [0B, 4PiB]
example: --archive-push-queue-max=1TiB

Veralteter Name: archive-queue-max

Option für das Archivierungszeitlimit (--archive-timeout)

Archivierungszeitlimit.

Maximale Wartezeit in Sekunden festlegen, bis ein einzelnes WAL-Segment das Archiv-Repository von pgBackRest erreicht. Dieses Zeitlimit gilt für die Befehle check und backup, wenn sie auf die Archivierung der WAL-Segmente warten, die für ein konsistentes Backup erforderlich sind.

default: 1m
allowed: [100ms, 1d]
example: --archive-timeout=30

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den pgBackRest-Befehl (--cmd)

pgBackRest-Befehl.

pgBackRest kann eine Befehlszeichenfolge erzeugen, etwa wenn der Befehl restore die Einstellung restore_command erzeugt. Dafür wird der Befehl verwendet, mit dem der pgBackRest-Prozess gestartet wurde, sofern nicht die Option cmd angegeben ist.

ACHTUNG:

Das Einbetten des pgBackRest-Befehls in einen Wrapper kann unvorhersehbares Verhalten verursachen und wird nicht empfohlen.

default: [path of executed pgbackrest binary]
example: --cmd=/var/lib/pgsql/bin/pgbackrest_wrapper.sh

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option zur Komprimierung (--compress)

Dateikomprimierung verwenden.

Die Backup-Dateien sind mit Komprimierungswerkzeugen für die Befehlszeile kompatibel.

Diese Option ist inzwischen veraltet. Stattdessen sollte compress-type verwendet werden.

default: y
example: --no-compress

Option für die Komprimierungsstufe (--compress-level)

Komprimierungsstufe für Dateien.

Legt die Stufe für die Dateikomprimierung fest, wenn compress-type nicht none ist oder compress=y (veraltet) gilt.

default (depending on compress-type):
    bz2 - 9
    gz - 6
    lz4 - 1
    zst - 3

allow range (depending on compress-type):
    bz2 - [1, 9]
    gz - [-1, 9]
    lz4 - [-5, 12]
    zst - [-7, 22]

example: --compress-level=9

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für das Komprimierungsverfahren (--compress-type)

Komprimierungsverfahren für Dateien.

Die folgenden Komprimierungsverfahren werden unterstützt:

  • none - Keine Komprimierung
  • bz2 - bzip2-Komprimierungsformat
  • gz - gzip-Komprimierungsformat
  • lz4 - lz4-Komprimierungsformat (nicht auf allen Plattformen verfügbar)
  • zst - Zstandard-Komprimierungsformat (nicht auf allen Plattformen verfügbar)
default: gz
example: --compress-type=none

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für die maximale Prozessanzahl (--process-max)

Maximale Anzahl der Prozesse für Komprimierung und Übertragung.

Jeder Prozess führt Komprimierung und Übertragung aus, um den Befehl zu beschleunigen. process-max jedoch nicht so hoch setzen, dass die Datenbankleistung beeinträchtigt wird.

default: 1
allowed: [1, 999]
example: --process-max=4

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für den Spool-Pfad (--spool-path)

Pfad zum Speichern vorübergehend benötigter Daten.

In diesem Pfad werden Daten für die asynchronen Befehle archive-push und archive-get gespeichert.

Der asynchrone Befehl archive-push schreibt Bestätigungen in den Spool-Pfad, wenn WAL erfolgreich im Archiv gespeichert wurde, und Fehlermeldungen bei einem Fehlschlag. So kann der Vordergrundprozess PostgreSQL schnell benachrichtigen. Die Bestätigungsdateien sind sehr klein: bei Erfolg leer, bei Fehlern wenige hundert Byte groß.

Der asynchrone Befehl archive-get hält WAL im Spool-Pfad bereit, damit es auf Anfrage von PostgreSQL sehr schnell geliefert werden kann. Das Verschieben der Dateien zu PostgreSQL ist am effizientesten, wenn der Spool-Pfad auf demselben Dateisystem wie pg_xlog/pg_wal liegt. Es wird jedoch davon abgeraten, den Spool-Pfad innerhalb des Verzeichnisses pg_xlog/pg_wal anzulegen, da dies bei PostgreSQL-Werkzeugen wie pg_rewind Probleme verursachen kann.

Die Daten im Spool-Pfad sind nicht rein temporär, da sie einen Neustart überdauern können und sollten. Ihr Verlust ist jedoch kein Problem: Für archive-push prüft pgBackRest einfach jedes WAL-Segment erneut auf sichere Archivierung; für archive-get baut es die Warteschlange neu auf.

Der Spool-Pfad ist für ein lokales POSIX-kompatibles Dateisystem vorgesehen, nicht für ein entferntes Dateisystem wie NFS oder CIFS.

default: /var/spool/pgbackrest
example: --spool-path=/backup/db/spool

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Optionen für Maintainer

Option zur Prüfung der WAL-Header (--archive-header-check)

PostgreSQL-Version und -ID in WAL-Headern prüfen.

Diese standardmäßig aktivierte Option prüft den WAL-Header anhand der PostgreSQL-Version und der Systemkennung. Dadurch wird sichergestellt, dass WAL in die richtige Stanza kopiert wird. Zusätzlich wird bereits pg_control mit der Stanza abgeglichen und geprüft, ob WAL aus demselben PostgreSQL-Datenverzeichnis kopiert wird, in dem sich pg_control befindet.

Das Deaktivieren dieser Prüfung ist daher relativ sicher, sollte aber nur bei Bedarf erfolgen, etwa wenn WAL verschlüsselt ist.

default: y
example: --no-archive-header-check

Option zum Erzwingen der PostgreSQL-Version (--pg-version-force)

PostgreSQL-Version erzwingen.

Verwendet die angegebene PostgreSQL-Version statt der Version, die automatisch aus pg_control oder WAL-Headern ermittelt wird. Dies ist hauptsächlich für PostgreSQL-Forks oder Entwicklungsversionen hilfreich, deren Werte von denen der veröffentlichten Version abweichen. Die von PostgreSQL über server_version_num gemeldete Version muss mit der erzwungenen Version übereinstimmen.

WARNUNG:

Diese Option mit Vorsicht verwenden: pg_control und WAL-Header werden weiterhin im erwarteten Format der angegebenen Version gelesen, also im Format der offiziellen Open-Source-Version von PostgreSQL. Ändert der Fork oder die Entwicklungsversion das Format von Feldern, auf die pgBackRest angewiesen ist, führt dies zu unerwartetem Verhalten. Im Allgemeinen funktioniert diese Option nur dann wie erwartet, wenn der Fork alle eigenen Strukturfelder nach den standardmäßigen PostgreSQL-Feldern hinzufügt.

example: --pg-version-force=15

Repository-Optionen

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

Stanza-Optionen

Option für den PostgreSQL-Pfad (--pg-path)

PostgreSQL-Datenverzeichnis.

Dieser Pfad sollte dem von PostgreSQL gemeldeten data_directory entsprechen. Obwohl sich der Wert an verschiedenen Stellen auslesen lässt, ist eine ausdrückliche Angabe ratsam, falls diese Quellen bei einer Wiederherstellung oder einem Offline-Backup nicht verfügbar sind.

Bei jedem Online-Backup wird pg-path mit dem von PostgreSQL gemeldeten Wert verglichen. Die Option sollte daher immer aktuell sein.

example: --pg1-path=/data/db

Veralteter Name: db-path

4.4 - Backup-Befehl (backup)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls backup.

Sind mehrere Repositorys konfiguriert, erstellt pgBackRest das Backup im Repository mit der höchsten Priorität (z. B. repo1), sofern nicht die Option --repo angegeben wird.

pgBackRest besitzt keinen integrierten Zeitplaner. Daher empfiehlt sich der Aufruf über cron oder einen anderen Mechanismus zur Zeitplanung.

Weitere Einzelheiten und Beispiele finden Sie unter Ein Backup erstellen .

Befehlsoptionen

Option für Backup-Anmerkungen (--annotation)

Das Backup mit benutzerdefinierten Schlüssel/Wert-Paaren versehen.

Benutzer können dem Backup informative Schlüssel/Wert-Paare hinzufügen. Diese Option kann mehrfach verwendet werden, um mehrere Anmerkungen hinzuzufügen.

Anmerkungen erscheinen in der Textausgabe des Befehls info, wenn mit --set ein Backup angegeben wird. In der JSON-Ausgabe erscheinen sie immer.

example: --annotation=source="Sunday backup for website database"

Option zur Archivprüfung (--archive-check)

Vor Abschluss des Backups prüfen, ob sich die WAL-Segmente im Archiv befinden.

Prüft, ob alle für ein konsistentes Backup erforderlichen WAL-Segmente im WAL-Archiv vorhanden sind. Es empfiehlt sich, die Standardeinstellung beizubehalten, sofern keine andere Archivierungsmethode verwendet wird.

Diese Option muss aktiviert sein, wenn archive-copy aktiviert ist.

default: y
example: --no-archive-check

Option zum Kopieren des Archivs (--archive-copy)

Für die Konsistenz benötigte WAL-Segmente in das Backup kopieren.

Diese etwas übervorsichtige Option schützt vor beschädigten Daten im WAL-Segmentarchiv, indem sie die für die Konsistenz erforderlichen WAL-Segmente direkt im Backup speichert. Die WAL-Segmente bleiben zusätzlich im Archiv gespeichert, daher benötigt diese Option weiteren Speicherplatz.

Bei Verwendung dieser Option sollten die Befehle archive-push und backup möglichst denselben Wert für compress-type verwenden (z. B. lz4). Andernfalls müssen die WAL-Segmente mit dem für das Backup verwendeten compress-type neu komprimiert werden. Je nach der während des Backups erzeugten WAL-Menge kann dies recht aufwendig sein.

Bei der Wiederherstellung liegen die WAL-Segmente in pg_xlog/pg_wal. PostgreSQL bevorzugt diese Segmente gegenüber einem Aufruf von restore_command.

Die Option archive-check muss aktiviert sein, wenn archive-copy aktiviert ist.

default: n
example: --archive-copy

Option zur Prüfung des Archivierungsmodus (--archive-mode-check)

Die PostgreSQL-Einstellung archive_mode prüfen.

Diese standardmäßig aktivierte Option verbietet die PostgreSQL-Einstellung archive_mode=always.

Von einem Standby-Server übertragene WAL-Segmente können logisch mit denen des Primärservers übereinstimmen, aber andere Prüfsummen aufweisen. Zur Vermeidung von Konflikten wird empfohlen, die Archivierung aus mehreren Quellen zu unterbinden.

ACHTUNG:

Bei deaktivierter Option muss unbedingt sichergestellt werden, dass nur ein Archivierer mit dem Befehl archive-push in das Repository schreibt.

default: y
example: --no-archive-mode-check

Option für das Archivierungszeitlimit (--archive-timeout)

Archivierungszeitlimit.

Maximale Wartezeit in Sekunden festlegen, bis ein einzelnes WAL-Segment das Archiv-Repository von pgBackRest erreicht. Dieses Zeitlimit gilt für die Befehle check und backup, wenn sie auf die Archivierung der WAL-Segmente warten, die für ein konsistentes Backup erforderlich sind.

default: 1m
allowed: [100ms, 1d]
example: --archive-timeout=30

Option für Backups vom Standby (--backup-standby)

Backup vom Standby-Cluster erstellen.

Backups vom Standby aktivieren, um die Last auf dem Primärcluster zu verringern. Für diese Option müssen sowohl der Primär- als auch der Standby-Host konfiguriert sein.

Die folgenden Modi werden unterstützt:

  • y - Für das Backup ist ein Standby erforderlich.
  • prefer - Backup vom Standby erstellen, falls verfügbar, andernfalls vom Primärserver.
  • n - Backup ausschließlich vom Primärserver erstellen.
default: n
example: --backup-standby=y

Option für Seitenprüfsummen (--checksum-page)

Prüfsummen der Datenseiten validieren.

Weist pgBackRest an, beim Backup eines Clusters die Prüfsummen aller Datenseiten zu validieren. Diese Option wird automatisch aktiviert, wenn Datenseitenprüfsummen im Cluster aktiviert sind.

Fehler bei der Prüfsummenvalidierung brechen das Backup nicht ab. Stattdessen werden Warnungen ins Protokoll geschrieben und bei Standardeinstellungen auch auf der Konsole ausgegeben. Die Liste der ungültigen Seiten wird im Backup-Manifest gespeichert.

example: --no-checksum-page

Option zum Ausschließen von Pfaden und Dateien (--exclude)

Pfade und Dateien vom Backup ausschließen.

Alle Ausschlüsse beziehen sich auf $PGDATA. Endet der Ausschluss mit /, werden nur Dateien im angegebenen Verzeichnis ausgeschlossen. Beispielsweise schließt --exclude=junk/ alle Dateien im Verzeichnis $PGDATA/junk aus, nimmt aber das Verzeichnis selbst auf. Endet der Ausschluss nicht mit /, kann eine Datei entweder genau dem Ausschluss entsprechen oder dem Ausschluss mit angehängtem /. So schließt --exclude=junk das Verzeichnis $PGDATA/junk und alle darin enthaltenen Dateien aus.

Diese Funktion mit Vorsicht verwenden: Wichtige Inhalte lassen sich leicht versehentlich ausschließen, wodurch das Backup inkonsistent wird. Testen Sie unbedingt Ihre Wiederherstellungen!

Alle ausgeschlossenen Dateien werden zusammen mit der Ausschlussregel auf der Stufe info protokolliert. Prüfen Sie unbedingt die Liste, damit keine Dateien unerwartet ausgeschlossen werden.

HINWEIS: Ausschlüsse werden bei Delta-Wiederherstellungen nicht berücksichtigt. Alle beim Backup ausgeschlossenen Dateien und Verzeichnisse werden bei einer Delta-Wiederherstellung entfernt.

Diese Option sollte nicht verwendet werden, um PostgreSQL-Protokolle vom Backup auszuschließen. Mit der PostgreSQL-Einstellung log_directory lassen sich Protokolle außerhalb des Verzeichnisses PGDATA ablegen. Dies hat den Vorteil, dass sie nach einer Wiederherstellung erhalten bleiben können.

In der Befehlszeile oder einer Konfigurationsdatei können mehrere Ausschlüsse angegeben werden.

example: --exclude=junk/

Option zur automatischen Bereinigung (--expire-auto)

Nach einem erfolgreichen Backup automatisch den Befehl expire ausführen.

Diese Einstellung ist standardmäßig aktiviert. Beim Deaktivieren ist Vorsicht geboten: Alle Backups und Archive bleiben dann unbegrenzt erhalten, wodurch der Speicherplatz im Repository ausgehen kann. Um dies zu verhindern, muss der Befehl expire regelmäßig ausgeführt werden.

Wird expire nach einem erfolgreichen Backup automatisch ausgeführt, verwendet es die Konfiguration des Befehls backup. Optionen, die ausschließlich in einem Abschnitt für den Befehl expire stehen, etwa [global:expire], werden daher nicht angewendet. Um eine eigene Konfiguration für expire anzuwenden, diese Option deaktivieren und den Befehl expire separat ausführen.

default: y
example: --expire-auto

Option zum Erzwingen (--force)

Ein Offline-Backup erzwingen.

Zusammen mit --no-start-stop wird ein Backup auch dann ausgeführt, wenn pgBackRest davon ausgeht, dass PostgreSQL läuft. Diese Option sollte mit äußerster Vorsicht verwendet werden, da sie wahrscheinlich zu einem unbrauchbaren Backup führt.

Unter bestimmten Umständen kann ein Backup auch unter diesen Bedingungen wünschenswert sein. Stürzt beispielsweise ein Server ab und lässt sich das Volume des Datenbankclusters nur lesend einhängen, ist ein Backup auch dann sinnvoll, wenn postmaster.pid vorhanden ist. In diesem Fall wäre es besser, auf das vorherige Backup zurückzugreifen und WAL erneut einzuspielen. Möglicherweise befindet sich aber eine sehr wichtige Transaktion in einem noch nicht archivierten WAL-Segment.

default: n
example: --force

Option für den Schwellenwert zum Speichern des Manifests (--manifest-save-threshold)

Schwellenwert zum Speichern des Manifests während des Backups.

Legt fest, wie oft das Manifest während eines Backups gespeichert wird. Das Speichern ist wichtig, da das Manifest Prüfsummen enthält und eine effiziente Wiederaufnahme ermöglicht. Der tatsächlich verwendete Schwellenwert ist der größere Wert aus 1% der Backup-Größe und manifest-save-threshold.

default: 1GiB
allowed: [1B, 1TiB]
example: --manifest-save-threshold=8GiB

Option für Online-Backups (--online)

Ein Online-Backup erstellen.

Mit –no-online führt pgBackRest die Funktionen zum Starten und Stoppen des Backups auf dem Datenbankcluster nicht aus. Dazu sollte PostgreSQL heruntergefahren sein; andernfalls meldet pgBackRest einen Fehler.

Diese Option ermöglicht Offline-Backups. Das Verzeichnis pg_xlog/pg_wal wird unverändert kopiert, und archive-check wird für das Backup automatisch deaktiviert.

default: y
example: --no-online

Option zur Wiederaufnahme (--resume)

Die Wiederaufnahme eines fehlgeschlagenen Backups erlauben.

Legt fest, ob die Wiederaufnahme aktiviert ist. Sie kann die benötigte Zeit erheblich verkürzen, wenn zuvor ein Backup desselben Typs fehlgeschlagen ist. Sie erhöht jedoch die Komplexität. In Umgebungen, die diese Funktion nicht benötigen, kann es daher sinnvoll sein, sie zu deaktivieren.

default: y
example: --no-resume

Option für einen schnellen Start (--start-fast)

Einen Checkpoint erzwingen, um das Backup schnell zu starten.

Erzwingt einen Checkpoint, indem dem Parameter fast der Backup-Startfunktion der Wert y übergeben wird, sodass das Backup sofort beginnt. Andernfalls beginnt es nach dem nächsten regulären Checkpoint.

default: n
example: --start-fast

Option für den Typ (--type)

Backup-Typ.

Die folgenden Backup-Typen werden unterstützt:

  • full - Alle Dateien des Datenbankclusters werden kopiert; es bestehen keine Abhängigkeiten von vorherigen Backups.
  • incr - Inkrementelles Backup seit dem letzten erfolgreichen Backup.
  • diff - Wie ein inkrementelles Backup, aber stets auf Grundlage des letzten vollständigen Backups.
default: incr
example: --type=full

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den pgBackRest-Befehl (--cmd)

pgBackRest-Befehl.

pgBackRest kann eine Befehlszeichenfolge erzeugen, etwa wenn der Befehl restore die Einstellung restore_command erzeugt. Dafür wird der Befehl verwendet, mit dem der pgBackRest-Prozess gestartet wurde, sofern nicht die Option cmd angegeben ist.

ACHTUNG:

Das Einbetten des pgBackRest-Befehls in einen Wrapper kann unvorhersehbares Verhalten verursachen und wird nicht empfohlen.

default: [path of executed pgbackrest binary]
example: --cmd=/var/lib/pgsql/bin/pgbackrest_wrapper.sh

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option zur Komprimierung (--compress)

Dateikomprimierung verwenden.

Die Backup-Dateien sind mit Komprimierungswerkzeugen für die Befehlszeile kompatibel.

Diese Option ist inzwischen veraltet. Stattdessen sollte compress-type verwendet werden.

default: y
example: --no-compress

Option für die Komprimierungsstufe (--compress-level)

Komprimierungsstufe für Dateien.

Legt die Stufe für die Dateikomprimierung fest, wenn compress-type nicht none ist oder compress=y (veraltet) gilt.

default (depending on compress-type):
    bz2 - 9
    gz - 6
    lz4 - 1
    zst - 3

allow range (depending on compress-type):
    bz2 - [1, 9]
    gz - [-1, 9]
    lz4 - [-5, 12]
    zst - [-7, 22]

example: --compress-level=9

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für das Komprimierungsverfahren (--compress-type)

Komprimierungsverfahren für Dateien.

Die folgenden Komprimierungsverfahren werden unterstützt:

  • none - Keine Komprimierung
  • bz2 - bzip2-Komprimierungsformat
  • gz - gzip-Komprimierungsformat
  • lz4 - lz4-Komprimierungsformat (nicht auf allen Plattformen verfügbar)
  • zst - Zstandard-Komprimierungsformat (nicht auf allen Plattformen verfügbar)
default: gz
example: --compress-type=none

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das Datenbankzeitlimit (--db-timeout)

Zeitlimit für Datenbankabfragen.

Legt das Zeitlimit für Datenbankabfragen in Sekunden fest. Dazu gehören auch die Funktionen zum Starten und Stoppen des Backups, die jeweils viel Zeit benötigen können. Daher sollte das Zeitlimit hoch bleiben, sofern nicht bekannt ist, dass diese Funktionen schnell zurückkehren, etwa wenn start-fast=y gesetzt ist und bekannt ist, dass der Datenbankcluster während des Backups nur wenige WAL-Segmente erzeugt.

HINWEIS: Der Wert von db-timeout muss kleiner sein als der von protocol-timeout.

default: 30m
allowed: [100ms, 7d]
example: --db-timeout=600

Delta-Option (--delta)

Wiederherstellung oder Backup anhand von Prüfsummen durchführen.

Bei einer Wiederherstellung wird standardmäßig erwartet, dass die PostgreSQL-Daten- und Tablespace-Verzeichnisse vorhanden, aber leer sind. Diese Option führt eine Delta-Wiederherstellung anhand von Prüfsummen durch.

Bei einem Backup verwendet diese Option Prüfsummen anstelle von Zeitstempeln, um zu entscheiden, ob Dateien kopiert werden.

default: n
example: --delta

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für die maximale Prozessanzahl (--process-max)

Maximale Anzahl der Prozesse für Komprimierung und Übertragung.

Jeder Prozess führt Komprimierung und Übertragung aus, um den Befehl zu beschleunigen. process-max jedoch nicht so hoch setzen, dass die Datenbankleistung beeinträchtigt wird.

default: 1
allowed: [1, 999]
example: --process-max=4

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Optionen für Maintainer

Option zur Prüfung der Seitenheader (--page-header-check)

PostgreSQL-Seitenheader prüfen.

Diese standardmäßig aktivierte Option ergänzt Prüfungen der Seitenheader.

Das Deaktivieren dieser Option sollte vermieden werden, außer wenn es erforderlich ist, etwa bei verschlüsselten Seiten.

default: y
example: --no-page-header-check

Option zum Erzwingen der PostgreSQL-Version (--pg-version-force)

PostgreSQL-Version erzwingen.

Verwendet die angegebene PostgreSQL-Version statt der Version, die automatisch aus pg_control oder WAL-Headern ermittelt wird. Dies ist hauptsächlich für PostgreSQL-Forks oder Entwicklungsversionen hilfreich, deren Werte von denen der veröffentlichten Version abweichen. Die von PostgreSQL über server_version_num gemeldete Version muss mit der erzwungenen Version übereinstimmen.

WARNUNG:

Diese Option mit Vorsicht verwenden: pg_control und WAL-Header werden weiterhin im erwarteten Format der angegebenen Version gelesen, also im Format der offiziellen Open-Source-Version von PostgreSQL. Ändert der Fork oder die Entwicklungsversion das Format von Feldern, auf die pgBackRest angewiesen ist, führt dies zu unerwartetem Verhalten. Im Allgemeinen funktioniert diese Option nur dann wie erwartet, wenn der Fork alle eigenen Strukturfelder nach den standardmäßigen PostgreSQL-Feldern hinzufügt.

example: --pg-version-force=15

Repository-Optionen

Option zur Auswahl des Repositorys (--repo)

Repository festlegen.

Legt das Repository fest, auf das ein Befehl wirken soll.

Damit kann beispielsweise eine Wiederherstellung aus einem bestimmten Repository durchgeführt werden, anstatt pgBackRest die Auswahl zu überlassen.

allowed: [1, 256]
example: --repo=1

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für inkrementelle Backups auf Blockebene (--repo-block)

Inkrementelle Backups auf Blockebene aktivieren.

Inkrementelle Backups auf Blockebene ermöglichen feinere Abstufungen, indem Dateien in Blöcke aufgeteilt werden, die sich unabhängig voneinander sichern lassen. Dies spart Speicherplatz im Repository und kann Delta-Wiederherstellungen beschleunigen, da einzelne Blöcke abgerufen werden können, ohne die gesamte Datei aus dem Repository zu lesen.

HINWEIS: repo-bundle muss aktiviert sein, bevor repo-block aktiviert werden kann.

Die Blockgröße einer Datei wird anhand ihrer Größe und ihres Alters bestimmt. Ältere oder größere Dateien erhalten im Allgemeinen größere Blöcke. Ist eine Datei alt genug, wird sie nicht inkrementell auf Blockebene gesichert.

Inkrementelle Backups auf Blockebene sind am effizientesten, wenn sie für alle Backup-Typen einschließlich vollständiger Backups aktiviert sind. Das vollständige Backup wird dadurch etwas größer. Spätere differenzielle und inkrementelle Backups können aber die dabei erzeugten Blockzuordnungen nutzen, um Speicherplatz zu sparen.

default: n
example: --repo1-block

Option für Dateibündel im Repository (--repo-bundle)

Dateien im Repository bündeln.

Kleinere Dateien bündeln, also zusammenfassen, um die Gesamtzahl der ins Repository geschriebenen Dateien zu verringern. Weniger Dateien zu schreiben ist im Allgemeinen effizienter, insbesondere bei Objektspeichern wie S3. Außerdem werden leere Dateien nur im Manifest erfasst und ansonsten nicht gespeichert, was Zeit und Speicherplatz spart.

default: n
example: --repo1-bundle

Option für die Dateigrößengrenze beim Bündeln (--repo-bundle-limit)

Grenzwert für Dateibündel.

Größenlimit für Dateien, die in Bündel aufgenommen werden. Größere Dateien werden separat gespeichert.

Gebündelte Dateien können bei der Wiederaufnahme eines Backups nicht wiederverwendet werden. Diese Option bestimmt daher, welche Dateien sich wiederverwenden lassen: Höhere Werte führen zu weniger wiederverwendbaren Dateien.

default: 2MiB
allowed: [8KiB, 1PiB]
example: --repo1-bundle-limit=10MiB

Option für die Bündelgröße im Repository (--repo-bundle-size)

Zielgröße für Dateibündel.

Legt die angestrebte Gesamtgröße der Dateien in einem Bündel fest. Die unkomprimierte Bündelgröße kann bis zu repo-bundle-size + repo-bundle-limit betragen. Deshalb diese Option nicht auf die maximal zulässige Dateigröße des Dateisystems setzen.

Im Allgemeinen sollte diese Option nicht zu hoch gesetzt werden, da bei Wiederholungsversuchen das gesamte Bündel erneut verarbeitet werden muss.

default: 20MiB
allowed: [1MiB, 1PiB]
example: --repo1-bundle-size=10MiB

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für Hardlinks im Repository (--repo-hardlink)

Dateien zwischen Backups im Repository durch Hardlinks verbinden.

Aktiviert Hardlinks von Dateien in differenziellen und inkrementellen Backups auf die zugehörigen vollständigen Backups. Auf Dateisystemebene wirkt dadurch jedes Backup wie ein vollständiges Backup. Vorsicht: Änderungen an Dateien mit Hardlinks können alle Backups des Satzes betreffen.

default: n
example: --repo1-hardlink

Veralteter Name: hardlink

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für die Archivaufbewahrung (--repo-retention-archive)

Anzahl der Backups, für die lückenloses WAL aufbewahrt wird.

HINWEIS: WAL-Segmente, die für ein konsistentes Backup erforderlich sind, bleiben unabhängig von dieser Einstellung immer bis zum Entfernen des Backups erhalten.

Ist dieser Wert nicht gesetzt und ist repo-retention-full-type auf count gesetzt (Standardeinstellung), richtet sich die Archivbereinigung nach repo-retention-full beziehungsweise repo-retention-diff, wenn repo-retention-archive-type auf full beziehungsweise diff gesetzt ist. So wird WAL nur für bereits entfernte Backups gelöscht. Ist repo-retention-full-type auf time gesetzt, werden standardmäßig Archive entfernt, die älter sind als das älteste vollständige Backup, das nach Anwendung von repo-retention-full aufbewahrt wird.

Diese Option muss gesetzt sein, wenn repo-retention-archive-type auf incr gesetzt ist. Bei knappem Speicherplatz kann sie zusammen mit repo-retention-archive-type verwendet werden, um WAL-Segmente frühzeitig zu entfernen. Damit ist jedoch keine PITR mehr aus Backups möglich, deren WAL entfernt wurde. Dies wird daher nicht empfohlen.

allowed: [1, 9999999]
example: --repo1-retention-archive=2

Veralteter Name: retention-archive

Option für den Typ der Archivaufbewahrung (--repo-retention-archive-type)

Backup-Typ für die WAL-Aufbewahrung.

Bei full bewahrt pgBackRest Archivprotokolle für die durch repo-retention-archive festgelegte Anzahl vollständiger Backups auf. Bei diff (differenziell) werden sie für die durch repo-retention-archive festgelegte Anzahl vollständiger und differenzieller Backups aufbewahrt. War das letzte Backup vollständig, wird es für repo-retention also als differenzielles Backup gezählt. Bei incr (inkrementell) bewahrt pgBackRest Archivprotokolle für die durch repo-retention-archive festgelegte Anzahl vollständiger, differenzieller und inkrementeller Backups auf. Es wird empfohlen, die Standardeinstellung beizubehalten, bei der WAL nur zusammen mit vollständigen Backups entfernt wird.

default: full
example: --repo1-retention-archive-type=diff

Veralteter Name: retention-archive-type

Option für die Aufbewahrung differenzieller Backups (--repo-retention-diff)

Anzahl der aufzubewahrenden differenziellen Backups.

Wird ein differenzielles Backup entfernt, werden auch alle zugehörigen inkrementellen Backups entfernt. Ohne Angabe bleiben alle differenziellen Backups erhalten, bis die vollständigen Backups entfernt werden, von denen sie abhängen.

Bei der Bereinigung zählen vollständige Backups zur Anzahl der differenziellen Backups. Dadurch müssen in den meisten Fällen etwas weniger differenzielle Backups aufbewahrt werden.

allowed: [1, 9999999]
example: --repo1-retention-diff=3

Veralteter Name: retention-diff

Option für die Aufbewahrung vollständiger Backups (--repo-retention-full)

Anzahl oder Aufbewahrungsdauer vollständiger Backups.

Wird ein vollständiges Backup entfernt, werden auch alle zugehörigen differenziellen und inkrementellen Backups entfernt. Ist diese Option nicht gesetzt, wird eine Warnung ausgegeben. Für eine unbegrenzte Aufbewahrung die Option auf den Höchstwert setzen.

allowed: [1, 9999999]
example: --repo1-retention-full=2

Veralteter Name: retention-full

Option für die Art der Aufbewahrung vollständiger Backups (--repo-retention-full-type)

Art der Aufbewahrung vollständiger Backups.

Bestimmt, ob repo-retention-full einen Zeitraum in Tagen oder die Anzahl der aufzubewahrenden vollständigen Backups angibt.

Bei time werden vollständige Backups, die älter als repo-retention-full sind, aus dem Repository entfernt, wenn mindestens ein weiteres Backup vorhanden ist, dessen Alter mindestens dem Wert von repo-retention-full entspricht. Steht beispielsweise repo-retention-full auf 30 Tage und gibt es 2 vollständige Backups, eines 25 Tage und eines 35 Tage alt, wird keines entfernt. Würde das 35 Tage alte Backup entfernt, bliebe nur das 25 Tage alte übrig. Dies würde die Aufbewahrungsregel von 30 Tagen verletzen: Es muss mindestens ein 30 Tage altes Backup vorhanden sein, bevor ein älteres entfernt werden kann. Archiviertes WAL, das älter als das älteste verbleibende vollständige Backup ist, wird automatisch entfernt, sofern repo-retention-archive-type und repo-retention-archive nicht ausdrücklich gesetzt sind.

Bei count werden vollständige Backups entfernt, die über die durch repo-retention-full festgelegte Anzahl hinausgehen. Steht beispielsweise repo-retention-full auf 4 und wird ein fünftes vollständiges Backup abgeschlossen, wird das älteste entfernt, sodass die Anzahl bei 4 bleibt.

Ein Backup muss erfolgreich abgeschlossen sein, bevor es für die Aufbewahrung zählt. Steht beispielsweise repo-retention-full-type auf count und repo-retention-full auf 2, müssen 3 abgeschlossene vollständige Backups vorhanden sein, bevor das älteste entfernt wird.

default: count
example: --repo1-retention-full-type=time

Option für die Aufbewahrung des Backup-Verlaufs (--repo-retention-history)

Aufbewahrungsdauer der Manifeste im Backup-Verlauf in Tagen.

Nach Abschluss eines Backups wird eine Kopie seines Manifests im Pfad backup.history gespeichert. Standardmäßig werden diese Dateien nie entfernt, da sie für Auswertungen nützlich sind, etwa um das Wachstum von Backups und WAL im Zeitverlauf zu messen.

Mit repo-retention-history die Anzahl der Tage festlegen, für die Manifeste im Backup-Verlauf aufbewahrt werden. Noch nicht entfernte Backups bleiben stets im Verlauf erhalten. Mit repo-retention-history=0 wird der Verlauf nur für solche Backups aufbewahrt.

Wird das Verlaufsmanifest eines vollständigen Backups entfernt, werden auch die Verlaufsmanifeste aller zugehörigen differenziellen und inkrementellen Backups entfernt.

allowed: [0, 9999999]
example: --repo1-retention-history=365

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für symbolische Links im Repository (--repo-symlink)

Symbolische Links innerhalb des Repositorys erstellen.

Aktiviert das Erstellen der symbolischen Links für latest und Tablespaces. Diese Links sind vor allem nützlich, wenn Snapshots für eine Recovery direkt im Repository verwendet werden, was selten vorkommt.

Obwohl diese Funktion für die meisten Benutzer wahrscheinlich nicht nützlich ist, bleibt sie aus Kompatibilitätsgründen standardmäßig aktiviert. Bei POSIX-ähnlichen Speichern ohne Unterstützung für symbolische Links kann es jedoch sinnvoll sein, sie zu deaktivieren.

default: y
example: --no-repo1-symlink

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

Stanza-Optionen

Option für die PostgreSQL-Datenbank (--pg-database)

PostgreSQL-Datenbank.

Name der Datenbank für Verbindungen zu PostgreSQL. Meist ist der Standardwert die beste Wahl, doch manche Installationen enthalten diese Datenbank möglicherweise nicht.

Aus Kompatibilitätsgründen wird die Umgebungsvariable PGDATABASE ignoriert.

default: postgres
example: --pg1-database=backupdb

Option für den PostgreSQL-Host (--pg-host)

PostgreSQL-Host für die Ausführung auf einem entfernten System.

Für Backups, bei denen PostgreSQL-Host und Repository-Host unterschiedliche Systeme sind.

example: --pg1-host=db.domain.com

Veralteter Name: db-host

Option für die CA-Datei des PostgreSQL-Hosts (--pg-host-ca-file)

Datei mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host eine andere als die systemweite CA-Datei verwenden.

example: --pg1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des PostgreSQL-Hosts (--pg-host-ca-path)

Pfad mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --pg1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des PostgreSQL-Hosts (--pg-host-cert-file)

Zertifikatdatei für den PostgreSQL-Host.

Wird an den PostgreSQL-Host gesendet, um die Identität des Clients nachzuweisen.

example: --pg1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem PostgreSQL-Host (--pg-host-cmd)

pgBackRest-Befehl auf dem PostgreSQL-Host.

Nur erforderlich, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem PostgreSQL-Host unterschiedlich ist. Ohne Angabe wird auf dem PostgreSQL-Host derselbe Befehl wie lokal verwendet.

default: [path of executed pgbackrest binary]
example: --pg1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: db-cmd

Option für die Konfiguration des PostgreSQL-Hosts (--pg-host-config)

pgBackRest-Konfigurationsdatei auf dem Datenbank-Host.

Legt den Speicherort der Konfigurationsdatei auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn die Datei dort an einem anderen Ort liegt als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --pg1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: db-config

Option für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host (--pg-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Datenbank-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --pg1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des PostgreSQL-Hosts (--pg-host-config-path)

pgBackRest-Konfigurationspfad auf dem Datenbank-Host.

Legt den Konfigurationspfad auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --pg1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des PostgreSQL-Hosts (--pg-host-key-file)

Schlüsseldatei für den PostgreSQL-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --pg1-host-key-file=/path/to/client.key

Option für den Port des PostgreSQL-Hosts (--pg-host-port)

Port des PostgreSQL-Hosts, wenn pg-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des PostgreSQL-Hosts angeben.

HINWEIS: Bei pg-host-type=ssh gibt es keinen Standardwert für pg-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on pg-host-type):
    tls - 8432

allowed: [0, 65535]
example: --pg1-host-port=25

Veralteter Name: db-ssh-port

Option für den Protokolltyp des PostgreSQL-Hosts (--pg-host-type)

Protokolltyp für den PostgreSQL-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --pg1-host-type=tls

Option für den Benutzer auf dem PostgreSQL-Host (--pg-host-user)

Anmeldebenutzer auf dem PostgreSQL-Host, wenn pg-host gesetzt ist.

Unter diesem Benutzer läuft auch der entfernte pgBackRest-Prozess, und er baut die Verbindungen zu PostgreSQL auf. Damit dies korrekt funktioniert, sollte er Eigentümer des PostgreSQL-Datenbankclusters sein. Üblicherweise ist dies postgres, der Standardwert.

default: postgres
example: --pg1-host-user=db_owner

Veralteter Name: db-user

Option für den PostgreSQL-Pfad (--pg-path)

PostgreSQL-Datenverzeichnis.

Dieser Pfad sollte dem von PostgreSQL gemeldeten data_directory entsprechen. Obwohl sich der Wert an verschiedenen Stellen auslesen lässt, ist eine ausdrückliche Angabe ratsam, falls diese Quellen bei einer Wiederherstellung oder einem Offline-Backup nicht verfügbar sind.

Bei jedem Online-Backup wird pg-path mit dem von PostgreSQL gemeldeten Wert verglichen. Die Option sollte daher immer aktuell sein.

example: --pg1-path=/data/db

Veralteter Name: db-path

Option für den PostgreSQL-Port (--pg-port)

PostgreSQL-Port.

Port, auf dem PostgreSQL läuft. Dieser muss normalerweise nicht angegeben werden, da die meisten PostgreSQL-Cluster den Standardport verwenden.

default: 5432
allowed: [0, 65535]
example: --pg1-port=6543

Veralteter Name: db-port

Option für den PostgreSQL-Socket-Pfad (--pg-socket-path)

Pfad zum PostgreSQL-Unix-Socket.

Das beim Start von PostgreSQL angegebene Unix-Socket-Verzeichnis. pgBackRest sucht automatisch am üblichen Speicherort des Betriebssystems. Diese Einstellung ist daher normalerweise nur erforderlich, wenn das Socket-Verzeichnis ausdrücklich über unix_socket_directories in postgresql.conf geändert wurde.

example: --pg1-socket-path=/var/run/postgresql

Veralteter Name: db-socket-path

Option für den PostgreSQL-Datenbankbenutzer (--pg-user)

PostgreSQL-Datenbankbenutzer.

Datenbankbenutzername für Verbindungen zu PostgreSQL. Ohne Angabe verbindet sich pgBackRest mit dem lokalen Betriebssystembenutzer oder mit PGUSER.

example: --pg1-user=backupuser

4.5 - Prüfbefehl (check)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls check.

Der Befehl check prüft, ob pgBackRest und die Einstellung archive_command für Archivierung und Backups der angegebenen Stanza korrekt konfiguriert sind. Er versucht, alle Repositorys und Datenbanken zu prüfen, die für den Host konfiguriert sind, auf dem er läuft. Dabei erkennt er Fehlkonfigurationen, insbesondere bei der Archivierung, die zu unvollständigen Backups führen, weil erforderliche WAL-Segmente das Archiv nicht erreicht haben. Der Befehl kann auf dem PostgreSQL- oder dem Repository-Host ausgeführt werden. Auch die Ausführung auf dem Standby-Host ist möglich. Da dort jedoch pg_switch_xlog()/pg_switch_wal() nicht ausgeführt werden können, wird in diesem Fall nur die Repository-Konfiguration geprüft.

Um PostgreSQL zur Archivierung eines WAL-Segments zu zwingen, werden pg_create_restore_point('pgBackRest Archive Check') und pg_switch_xlog()/pg_switch_wal() aufgerufen.

Befehlsoptionen

Option zur Archivprüfung (--archive-check)

Vor Abschluss des Backups prüfen, ob sich die WAL-Segmente im Archiv befinden.

Prüft, ob alle für ein konsistentes Backup erforderlichen WAL-Segmente im WAL-Archiv vorhanden sind. Es empfiehlt sich, die Standardeinstellung beizubehalten, sofern keine andere Archivierungsmethode verwendet wird.

Diese Option muss aktiviert sein, wenn archive-copy aktiviert ist.

default: y
example: --no-archive-check

Option zur Prüfung des Archivierungsmodus (--archive-mode-check)

Die PostgreSQL-Einstellung archive_mode prüfen.

Diese standardmäßig aktivierte Option verbietet die PostgreSQL-Einstellung archive_mode=always.

Von einem Standby-Server übertragene WAL-Segmente können logisch mit denen des Primärservers übereinstimmen, aber andere Prüfsummen aufweisen. Zur Vermeidung von Konflikten wird empfohlen, die Archivierung aus mehreren Quellen zu unterbinden.

ACHTUNG:

Bei deaktivierter Option muss unbedingt sichergestellt werden, dass nur ein Archivierer mit dem Befehl archive-push in das Repository schreibt.

default: y
example: --no-archive-mode-check

Option für das Archivierungszeitlimit (--archive-timeout)

Archivierungszeitlimit.

Maximale Wartezeit in Sekunden festlegen, bis ein einzelnes WAL-Segment das Archiv-Repository von pgBackRest erreicht. Dieses Zeitlimit gilt für die Befehle check und backup, wenn sie auf die Archivierung der WAL-Segmente warten, die für ein konsistentes Backup erforderlich sind.

default: 1m
allowed: [100ms, 1d]
example: --archive-timeout=30

Option für Backups vom Standby (--backup-standby)

Backup vom Standby-Cluster erstellen.

Backups vom Standby aktivieren, um die Last auf dem Primärcluster zu verringern. Für diese Option müssen sowohl der Primär- als auch der Standby-Host konfiguriert sein.

Die folgenden Modi werden unterstützt:

  • y - Für das Backup ist ein Standby erforderlich.
  • prefer - Backup vom Standby erstellen, falls verfügbar, andernfalls vom Primärserver.
  • n - Backup ausschließlich vom Primärserver erstellen.
default: n
example: --backup-standby=y

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das Datenbankzeitlimit (--db-timeout)

Zeitlimit für Datenbankabfragen.

Legt das Zeitlimit für Datenbankabfragen in Sekunden fest. Dazu gehören auch die Funktionen zum Starten und Stoppen des Backups, die jeweils viel Zeit benötigen können. Daher sollte das Zeitlimit hoch bleiben, sofern nicht bekannt ist, dass diese Funktionen schnell zurückkehren, etwa wenn start-fast=y gesetzt ist und bekannt ist, dass der Datenbankcluster während des Backups nur wenige WAL-Segmente erzeugt.

HINWEIS: Der Wert von db-timeout muss kleiner sein als der von protocol-timeout.

default: 30m
allowed: [100ms, 7d]
example: --db-timeout=600

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Optionen für Maintainer

Option zum Erzwingen der PostgreSQL-Version (--pg-version-force)

PostgreSQL-Version erzwingen.

Verwendet die angegebene PostgreSQL-Version statt der Version, die automatisch aus pg_control oder WAL-Headern ermittelt wird. Dies ist hauptsächlich für PostgreSQL-Forks oder Entwicklungsversionen hilfreich, deren Werte von denen der veröffentlichten Version abweichen. Die von PostgreSQL über server_version_num gemeldete Version muss mit der erzwungenen Version übereinstimmen.

WARNUNG:

Diese Option mit Vorsicht verwenden: pg_control und WAL-Header werden weiterhin im erwarteten Format der angegebenen Version gelesen, also im Format der offiziellen Open-Source-Version von PostgreSQL. Ändert der Fork oder die Entwicklungsversion das Format von Feldern, auf die pgBackRest angewiesen ist, führt dies zu unerwartetem Verhalten. Im Allgemeinen funktioniert diese Option nur dann wie erwartet, wenn der Fork alle eigenen Strukturfelder nach den standardmäßigen PostgreSQL-Feldern hinzufügt.

example: --pg-version-force=15

Repository-Optionen

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

Stanza-Optionen

Option für die PostgreSQL-Datenbank (--pg-database)

PostgreSQL-Datenbank.

Name der Datenbank für Verbindungen zu PostgreSQL. Meist ist der Standardwert die beste Wahl, doch manche Installationen enthalten diese Datenbank möglicherweise nicht.

Aus Kompatibilitätsgründen wird die Umgebungsvariable PGDATABASE ignoriert.

default: postgres
example: --pg1-database=backupdb

Option für den PostgreSQL-Host (--pg-host)

PostgreSQL-Host für die Ausführung auf einem entfernten System.

Für Backups, bei denen PostgreSQL-Host und Repository-Host unterschiedliche Systeme sind.

example: --pg1-host=db.domain.com

Veralteter Name: db-host

Option für die CA-Datei des PostgreSQL-Hosts (--pg-host-ca-file)

Datei mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host eine andere als die systemweite CA-Datei verwenden.

example: --pg1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des PostgreSQL-Hosts (--pg-host-ca-path)

Pfad mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --pg1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des PostgreSQL-Hosts (--pg-host-cert-file)

Zertifikatdatei für den PostgreSQL-Host.

Wird an den PostgreSQL-Host gesendet, um die Identität des Clients nachzuweisen.

example: --pg1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem PostgreSQL-Host (--pg-host-cmd)

pgBackRest-Befehl auf dem PostgreSQL-Host.

Nur erforderlich, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem PostgreSQL-Host unterschiedlich ist. Ohne Angabe wird auf dem PostgreSQL-Host derselbe Befehl wie lokal verwendet.

default: [path of executed pgbackrest binary]
example: --pg1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: db-cmd

Option für die Konfiguration des PostgreSQL-Hosts (--pg-host-config)

pgBackRest-Konfigurationsdatei auf dem Datenbank-Host.

Legt den Speicherort der Konfigurationsdatei auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn die Datei dort an einem anderen Ort liegt als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --pg1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: db-config

Option für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host (--pg-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Datenbank-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --pg1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des PostgreSQL-Hosts (--pg-host-config-path)

pgBackRest-Konfigurationspfad auf dem Datenbank-Host.

Legt den Konfigurationspfad auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --pg1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des PostgreSQL-Hosts (--pg-host-key-file)

Schlüsseldatei für den PostgreSQL-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --pg1-host-key-file=/path/to/client.key

Option für den Port des PostgreSQL-Hosts (--pg-host-port)

Port des PostgreSQL-Hosts, wenn pg-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des PostgreSQL-Hosts angeben.

HINWEIS: Bei pg-host-type=ssh gibt es keinen Standardwert für pg-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on pg-host-type):
    tls - 8432

allowed: [0, 65535]
example: --pg1-host-port=25

Veralteter Name: db-ssh-port

Option für den Protokolltyp des PostgreSQL-Hosts (--pg-host-type)

Protokolltyp für den PostgreSQL-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --pg1-host-type=tls

Option für den Benutzer auf dem PostgreSQL-Host (--pg-host-user)

Anmeldebenutzer auf dem PostgreSQL-Host, wenn pg-host gesetzt ist.

Unter diesem Benutzer läuft auch der entfernte pgBackRest-Prozess, und er baut die Verbindungen zu PostgreSQL auf. Damit dies korrekt funktioniert, sollte er Eigentümer des PostgreSQL-Datenbankclusters sein. Üblicherweise ist dies postgres, der Standardwert.

default: postgres
example: --pg1-host-user=db_owner

Veralteter Name: db-user

Option für den PostgreSQL-Pfad (--pg-path)

PostgreSQL-Datenverzeichnis.

Dieser Pfad sollte dem von PostgreSQL gemeldeten data_directory entsprechen. Obwohl sich der Wert an verschiedenen Stellen auslesen lässt, ist eine ausdrückliche Angabe ratsam, falls diese Quellen bei einer Wiederherstellung oder einem Offline-Backup nicht verfügbar sind.

Bei jedem Online-Backup wird pg-path mit dem von PostgreSQL gemeldeten Wert verglichen. Die Option sollte daher immer aktuell sein.

example: --pg1-path=/data/db

Veralteter Name: db-path

Option für den PostgreSQL-Port (--pg-port)

PostgreSQL-Port.

Port, auf dem PostgreSQL läuft. Dieser muss normalerweise nicht angegeben werden, da die meisten PostgreSQL-Cluster den Standardport verwenden.

default: 5432
allowed: [0, 65535]
example: --pg1-port=6543

Veralteter Name: db-port

Option für den PostgreSQL-Socket-Pfad (--pg-socket-path)

Pfad zum PostgreSQL-Unix-Socket.

Das beim Start von PostgreSQL angegebene Unix-Socket-Verzeichnis. pgBackRest sucht automatisch am üblichen Speicherort des Betriebssystems. Diese Einstellung ist daher normalerweise nur erforderlich, wenn das Socket-Verzeichnis ausdrücklich über unix_socket_directories in postgresql.conf geändert wurde.

example: --pg1-socket-path=/var/run/postgresql

Veralteter Name: db-socket-path

Option für den PostgreSQL-Datenbankbenutzer (--pg-user)

PostgreSQL-Datenbankbenutzer.

Datenbankbenutzername für Verbindungen zu PostgreSQL. Ohne Angabe verbindet sich pgBackRest mit dem lokalen Betriebssystembenutzer oder mit PGUSER.

example: --pg1-user=backupuser

4.6 - Befehl zum Entfernen abgelaufener Backups (expire)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls expire.

pgBackRest rotiert vollständige Backups je nach Art der Aufbewahrung anhand einer Anzahl oder eines Zeitraums. Bei einer Anzahl richtet sich die Bereinigung danach, wie viele Backups aufbewahrt werden müssen, nicht nach ihrem Erstellungszeitpunkt. Differenzielle Backups werden anhand ihrer Anzahl aufbewahrt, aber immer entfernt, sobald das vollständige Backup entfernt wird, von dem sie abhängen. Inkrementelle Backups werden nie eigenständig anhand von Aufbewahrungsregeln entfernt, sondern immer zusammen mit dem zugehörigen vollständigen oder differenziellen Backup. Einzelheiten und Beispiele finden Sie unter Aufbewahrung vollständiger Backups und Aufbewahrung differenzieller Backups .

Archiviertes WAL bleibt standardmäßig für noch nicht entfernte Backups erhalten. Mit den retention-archive-Optionen lässt sich dies pro Repository ändern, was jedoch nicht empfohlen wird. Einzelheiten und Beispiele finden Sie unter Archivaufbewahrung .

Der Befehl expire läuft automatisch nach jedem erfolgreichen Backup und kann auch vom Benutzer ausgeführt werden. Bei manueller Ausführung erfolgt die Bereinigung gemäß den Aufbewahrungseinstellungen jedes konfigurierten Repositorys. Mit --repo wird nur das angegebene Repository bereinigt. Der Benutzer kann die Bereinigung mit --set auf einen bestimmten Backup-Satz begrenzen. Ohne --repo werden dabei alle Repositorys durchsucht und alle passenden Backup-Sätze entfernt. Bei jeder Ausführung von expire werden außerdem die Regeln zur Archivaufbewahrung geprüft und angewendet.

Befehlsoptionen

Option zum Entfernen älterer Archivsegmente (--archive-expire-before)

WAL-Archiv vor dem angegebenen WAL-Segment entfernen.

WAL-Segmente vor dem angegebenen Segment entfernen, jedoch nur, wenn sie von keinem aufbewahrten Backup benötigt werden. Dies sind Segmente vor dem frühesten aufzubewahrenden Backup-Satz oder beliebige Segmente, wenn das Repository kein Backup enthält. Das angegebene Segment und alle nachfolgenden bleiben erhalten. Dies entspricht dem Wert, den PostgreSQL über %r an archive_cleanup_command übergibt.

Diese Option ist vor allem für reine Archiv-Repositorys ohne Backups vorgesehen. Sie kann auch Speicherplatz im WAL-Archiv für Segmente vor dem ersten Backup freigeben, wenn die Aufbewahrungsbedingungen für vollständige Backups noch nicht erfüllt sind und deshalb keine Archivbereinigung ausgelöst wird.

example: --archive-expire-before=000000010000000000000010

Option zum Entfernen des ältesten Backup-Satzes (--oldest)

Den ältesten entfernbaren Backup-Satz entfernen.

Entfernt den ältesten vollständigen Backup-Satz, der gelöscht werden kann, wobei mindestens ein neueres vollständiges Backup verbleibt. Dies entspricht einer manuellen Verringerung der Aufbewahrungsanzahl um eins, wird aber automatisch berechnet. Alle zugehörigen differenziellen und inkrementellen Backups werden ebenfalls entfernt.

Dabei wird auch die Archivaufbewahrung vorübergehend angepasst, damit WAL für die entfernten Backups im selben Lauf gelöscht werden kann.

Ist die Aufbewahrung vollständiger Backups zeitbasiert konfiguriert (mit --repo-retention-full-type=time), verwendet --oldest für diesen Lauf eine anzahlbasierte Bereinigung.

WARNUNG:

Diese Option kann nicht mit --set kombiniert werden.

default: n
example: --oldest

Option zur Auswahl des Backup-Satzes (--set)

Zu entfernender Backup-Satz.

Der angegebene Backup-Satz, also das angegebene Backup-Label und gegebenenfalls alle davon abhängigen Backups, wird unabhängig von den Aufbewahrungsregeln entfernt. Mindestens ein vollständiges Backup muss jedoch im Repository verbleiben.

WARNUNG:

Diese Option mit äußerster Vorsicht verwenden: Für den angegebenen Backup-Satz entfernt sie dauerhaft alle Backups sowie alle Archive, die nicht für die Konsistenz eines Backups erforderlich sind, aus dem pgBackRest-Repository. Dies kann PITR unmöglich machen. Sind --repo-retention-full und/oder --repo-retention-archive konfiguriert, wird empfohlen, diese Werte während einer solchen außerplanmäßigen Bereinigung auf den Höchstwert zu setzen, um unbeabsichtigtes Entfernen von Archiven zu verhindern.

example: --set=20150131-153358F_20150131-153401I

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für einen Probelauf (--dry-run)

Einen Probelauf des Befehls ausführen.

Die Option --dry-run ist nur in der Befehlszeile verfügbar. Mit ihr lässt sich ermitteln, welche Änderungen der Befehl vornehmen würde, ohne diese tatsächlich auszuführen.

default: n
example: --dry-run

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Repository-Optionen

Option zur Auswahl des Repositorys (--repo)

Repository festlegen.

Legt das Repository fest, auf das ein Befehl wirken soll.

Damit kann beispielsweise eine Wiederherstellung aus einem bestimmten Repository durchgeführt werden, anstatt pgBackRest die Auswahl zu überlassen.

allowed: [1, 256]
example: --repo=1

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für die Archivaufbewahrung (--repo-retention-archive)

Anzahl der Backups, für die lückenloses WAL aufbewahrt wird.

HINWEIS: WAL-Segmente, die für ein konsistentes Backup erforderlich sind, bleiben unabhängig von dieser Einstellung immer bis zum Entfernen des Backups erhalten.

Ist dieser Wert nicht gesetzt und ist repo-retention-full-type auf count gesetzt (Standardeinstellung), richtet sich die Archivbereinigung nach repo-retention-full beziehungsweise repo-retention-diff, wenn repo-retention-archive-type auf full beziehungsweise diff gesetzt ist. So wird WAL nur für bereits entfernte Backups gelöscht. Ist repo-retention-full-type auf time gesetzt, werden standardmäßig Archive entfernt, die älter sind als das älteste vollständige Backup, das nach Anwendung von repo-retention-full aufbewahrt wird.

Diese Option muss gesetzt sein, wenn repo-retention-archive-type auf incr gesetzt ist. Bei knappem Speicherplatz kann sie zusammen mit repo-retention-archive-type verwendet werden, um WAL-Segmente frühzeitig zu entfernen. Damit ist jedoch keine PITR mehr aus Backups möglich, deren WAL entfernt wurde. Dies wird daher nicht empfohlen.

allowed: [1, 9999999]
example: --repo1-retention-archive=2

Veralteter Name: retention-archive

Option für den Typ der Archivaufbewahrung (--repo-retention-archive-type)

Backup-Typ für die WAL-Aufbewahrung.

Bei full bewahrt pgBackRest Archivprotokolle für die durch repo-retention-archive festgelegte Anzahl vollständiger Backups auf. Bei diff (differenziell) werden sie für die durch repo-retention-archive festgelegte Anzahl vollständiger und differenzieller Backups aufbewahrt. War das letzte Backup vollständig, wird es für repo-retention also als differenzielles Backup gezählt. Bei incr (inkrementell) bewahrt pgBackRest Archivprotokolle für die durch repo-retention-archive festgelegte Anzahl vollständiger, differenzieller und inkrementeller Backups auf. Es wird empfohlen, die Standardeinstellung beizubehalten, bei der WAL nur zusammen mit vollständigen Backups entfernt wird.

default: full
example: --repo1-retention-archive-type=diff

Veralteter Name: retention-archive-type

Option für die Aufbewahrung differenzieller Backups (--repo-retention-diff)

Anzahl der aufzubewahrenden differenziellen Backups.

Wird ein differenzielles Backup entfernt, werden auch alle zugehörigen inkrementellen Backups entfernt. Ohne Angabe bleiben alle differenziellen Backups erhalten, bis die vollständigen Backups entfernt werden, von denen sie abhängen.

Bei der Bereinigung zählen vollständige Backups zur Anzahl der differenziellen Backups. Dadurch müssen in den meisten Fällen etwas weniger differenzielle Backups aufbewahrt werden.

allowed: [1, 9999999]
example: --repo1-retention-diff=3

Veralteter Name: retention-diff

Option für die Aufbewahrung vollständiger Backups (--repo-retention-full)

Anzahl oder Aufbewahrungsdauer vollständiger Backups.

Wird ein vollständiges Backup entfernt, werden auch alle zugehörigen differenziellen und inkrementellen Backups entfernt. Ist diese Option nicht gesetzt, wird eine Warnung ausgegeben. Für eine unbegrenzte Aufbewahrung die Option auf den Höchstwert setzen.

allowed: [1, 9999999]
example: --repo1-retention-full=2

Veralteter Name: retention-full

Option für die Art der Aufbewahrung vollständiger Backups (--repo-retention-full-type)

Art der Aufbewahrung vollständiger Backups.

Bestimmt, ob repo-retention-full einen Zeitraum in Tagen oder die Anzahl der aufzubewahrenden vollständigen Backups angibt.

Bei time werden vollständige Backups, die älter als repo-retention-full sind, aus dem Repository entfernt, wenn mindestens ein weiteres Backup vorhanden ist, dessen Alter mindestens dem Wert von repo-retention-full entspricht. Steht beispielsweise repo-retention-full auf 30 Tage und gibt es 2 vollständige Backups, eines 25 Tage und eines 35 Tage alt, wird keines entfernt. Würde das 35 Tage alte Backup entfernt, bliebe nur das 25 Tage alte übrig. Dies würde die Aufbewahrungsregel von 30 Tagen verletzen: Es muss mindestens ein 30 Tage altes Backup vorhanden sein, bevor ein älteres entfernt werden kann. Archiviertes WAL, das älter als das älteste verbleibende vollständige Backup ist, wird automatisch entfernt, sofern repo-retention-archive-type und repo-retention-archive nicht ausdrücklich gesetzt sind.

Bei count werden vollständige Backups entfernt, die über die durch repo-retention-full festgelegte Anzahl hinausgehen. Steht beispielsweise repo-retention-full auf 4 und wird ein fünftes vollständiges Backup abgeschlossen, wird das älteste entfernt, sodass die Anzahl bei 4 bleibt.

Ein Backup muss erfolgreich abgeschlossen sein, bevor es für die Aufbewahrung zählt. Steht beispielsweise repo-retention-full-type auf count und repo-retention-full auf 2, müssen 3 abgeschlossene vollständige Backups vorhanden sein, bevor das älteste entfernt wird.

default: count
example: --repo1-retention-full-type=time

Option für die Aufbewahrung des Backup-Verlaufs (--repo-retention-history)

Aufbewahrungsdauer der Manifeste im Backup-Verlauf in Tagen.

Nach Abschluss eines Backups wird eine Kopie seines Manifests im Pfad backup.history gespeichert. Standardmäßig werden diese Dateien nie entfernt, da sie für Auswertungen nützlich sind, etwa um das Wachstum von Backups und WAL im Zeitverlauf zu messen.

Mit repo-retention-history die Anzahl der Tage festlegen, für die Manifeste im Backup-Verlauf aufbewahrt werden. Noch nicht entfernte Backups bleiben stets im Verlauf erhalten. Mit repo-retention-history=0 wird der Verlauf nur für solche Backups aufbewahrt.

Wird das Verlaufsmanifest eines vollständigen Backups entfernt, werden auch die Verlaufsmanifeste aller zugehörigen differenziellen und inkrementellen Backups entfernt.

allowed: [0, 9999999]
example: --repo1-retention-history=365

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für symbolische Links im Repository (--repo-symlink)

Symbolische Links innerhalb des Repositorys erstellen.

Aktiviert das Erstellen der symbolischen Links für latest und Tablespaces. Diese Links sind vor allem nützlich, wenn Snapshots für eine Recovery direkt im Repository verwendet werden, was selten vorkommt.

Obwohl diese Funktion für die meisten Benutzer wahrscheinlich nicht nützlich ist, bleibt sie aus Kompatibilitätsgründen standardmäßig aktiviert. Bei POSIX-ähnlichen Speichern ohne Unterstützung für symbolische Links kann es jedoch sinnvoll sein, sie zu deaktivieren.

default: y
example: --no-repo1-symlink

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

4.7 - Hilfebefehl (help)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls help.

Die Hilfe ist in drei Ebenen gegliedert. Ohne Angabe eines Befehls wird die allgemeine Hilfe angezeigt. Wird ein Befehl angegeben (z. B. pgbackrest help backup), erscheint eine vollständige Beschreibung des Befehls mit einer Liste der zulässigen Optionen. Wird zusätzlich eine Option angegeben (z. B. pgbackrest help backup type), erscheint eine vollständige Beschreibung dieser Option für den jeweiligen Befehl.

Befehlsoptionen

Option zur Anzeige der Hilfe (--help)

Hilfe anzeigen.

Zeigt die Hilfe auch dann an, wenn der Befehl help nicht angegeben wurde, und hat Vorrang vor der Option --version.

default: n
example: --help

Option zur Anzeige der Version (--version)

Version anzeigen.

Zeigt die Version auch dann an, wenn weder der Befehl version noch help angegeben wurde.

default: n
example: --version

4.8 - Informationsbefehl (info)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls info.

Der Befehl info arbeitet mit einer einzelnen Stanza oder allen Stanzas. Standardmäßig wird eine für Menschen lesbare Textzusammenfassung der Backups für die angeforderten Stanzas ausgegeben. Dieses Format kann sich mit jeder Version ändern.

Für maschinenlesbare Ausgabe --output=json verwenden. Die JSON-Ausgabe enthält deutlich mehr Informationen als die Textausgabe und bleibt stabil, sofern kein Fehler gefunden wird.

Für eine schnellere Ausführung die Ausgabe mit --detail-level=progress auf Fortschrittsinformationen beschränken. Dabei werden alle Prüfungen außer der Verfügbarkeit der Stanza übersprungen.

Jede Stanza hat einen eigenen Abschnitt. Mit --stanza lässt sich die Ausgabe auf eine einzelne Stanza begrenzen. Der status gibt einen kurzen Überblick über ihren Zustand. Bei ok funktioniert pgBackRest normal. Sind mehrere Repositorys vorhanden, zeigt mixed an, dass die Stanza in mindestens einem Repository nicht in einem ordnungsgemäßen Zustand ist; dieser wird dann für jedes Repository einzeln beschrieben. Tritt in einem Repository ein Fehler auf, der keinem bekannten Fehlercode entspricht, wird der Code other verwendet und der Fehler vollständig beschrieben. wal archive min/max zeigt das kleinste und größte derzeit im Archiv gespeicherte WAL-Segment. Bei mehreren Repositorys wird dies über alle Repositorys hinweg ermittelt, sofern nicht --repo gesetzt ist. Aufgrund der Archivaufbewahrungsregeln oder anderer Ursachen können Lücken bestehen.

Neben status erscheinen die Meldungen backup/expire running und/oder restore running, wenn einer dieser Befehle gerade auf dem Host läuft. In der Textausgabe wird auch der Fortschritt je Repository angezeigt; die JSON-Ausgabe enthält dafür ein Array repo.

Backups werden vom ältesten zum neuesten angezeigt. Das älteste ist immer ein vollständiges Backup, erkennbar am F am Ende seines Labels. Das neueste kann vollständig, differenziell (Endung D) oder inkrementell (Endung I) sein.

timestamp start/stop bezeichnet den Zeitraum, in dem das Backup lief. Mit timestamp stop lässt sich bestimmen, welches Backup für eine Point-in-Time-Recovery verwendet werden soll. Weitere Informationen finden Sie im Abschnitt Point-in-Time-Recovery .

wal start/stop bezeichnet den WAL-Bereich, der bei der Wiederherstellung für einen konsistenten Datenbankzustand erforderlich ist. Der Befehl backup stellt vor seinem Abschluss sicher, dass dieser Bereich im Archiv vorhanden ist.

database size ist die vollständige unkomprimierte Größe der Datenbank. database backup size ist dagegen die Datenmenge, die tatsächlich gesichert werden muss. Bei vollständigen Backups stimmen beide Werte überein.

repo gibt an, in welchem Repository dieses Backup liegt. backup set size umfasst alle Dateien dieses Backups sowie alle Dateien referenzierter Backups im Repository, die zur Wiederherstellung der Datenbank aus diesem Backup erforderlich sind. backup size umfasst nur die Dateien dieses Backups. Auch diese Werte sind bei vollständigen Backups gleich. Ist die Komprimierung in pgBackRest aktiviert, beziehen sich die Repository-Größen auf die komprimierten Dateigrößen.

backup reference total fasst die Liste zusätzlicher Backups zusammen, die zur Wiederherstellung dieses Backups benötigt werden. Mit --set lässt sich die vollständige Referenzliste anzeigen.

Befehlsoptionen

Option für den Detailgrad (--detail-level)

Detailgrad der Ausgabe.

Die folgenden Stufen werden unterstützt:

  • progress - Nur den aktuellen Fortschritt von Backup und Bereinigung ausgeben. Diese Stufe kann nicht zusammen mit --set verwendet werden.
  • full - Vollständige Informationen ausgeben.
default: full
example: --detail-level=progress

Ausgabeoption (--output)

Ausgabeformat.

Die folgenden Ausgabetypen werden unterstützt:

  • text - Für Menschen lesbare Zusammenfassung der Backup-Informationen.
  • json - Vollständige maschinenlesbare Backup-Informationen im JSON-Format.
default: text
example: --output=json

Option zur Auswahl des Backup-Satzes (--set)

Backup-Satz, zu dem Details angezeigt werden sollen.

Die Details umfassen eine vollständige Liste zusätzlicher Backups, die zur Wiederherstellung benötigt werden, die Datenbanken im Backup-Satz mit ihren OIDs (ohne Template-Datenbanken), Tablespaces mit ihren OIDs und den standardmäßigen Wiederherstellungszielen sowie symbolische Links mit den Zielen, an denen sie bei Angabe von --link-all wiederhergestellt werden.

example: --set=20150131-153358F_20150131-153401I

Option für den Typ (--type)

Nach Backup-Typ filtern.

Die Ausgabe nach einem der folgenden Backup-Typen filtern:

  • full - Nur vollständige Backups ausgeben.
  • diff - Nur differenzielle Backups ausgeben.
  • incr - Nur inkrementelle Backups ausgeben.
example: --type=full

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Repository-Optionen

Option zur Auswahl des Repositorys (--repo)

Repository festlegen.

Legt das Repository fest, auf das ein Befehl wirken soll.

Damit kann beispielsweise eine Wiederherstellung aus einem bestimmten Repository durchgeführt werden, anstatt pgBackRest die Auswahl zu überlassen.

allowed: [1, 256]
example: --repo=1

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Zielzeitpunkt des Repositorys (--repo-target-time)

Zielzeitpunkt für das Repository.

Der Zielzeitpunkt legt fest, welchen Stand des Repositorys Befehle auf versioniertem Speicher lesen. So lässt sich das Repository zu einem früheren Zeitpunkt lesen, um Daten wiederherzustellen, die versehentlich durch Benutzer oder durch Schadsoftware gelöscht oder beschädigt wurden.

S3, GCS und Azure unterstützen versionierten Speicher, aktivieren ihn aber im Allgemeinen nicht standardmäßig. Neben der Versionierung kann es sinnvoll sein, bei S3 die Objektsperre und bei GCS oder Azure das vorläufige Löschen zu aktivieren.

Wenn repo-target-time angegeben wird, muss auch die Option repo angegeben werden. Wahrscheinlich unterstützen nicht alle Repository-Typen die Versionierung. Im Allgemeinen ist es sinnvoll, für die Wiederherstellung ein einzelnes Repository auszuwählen.

Beim Vergleich werden Speicherzeitstempel berücksichtigt, die <= dem angegebenen Zeitstempel sind. Enthaltene Millisekunden werden abgeschnitten.

example: --repo-target-time=2024-08-08 12:12:12+00

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

4.9 - Befehl zum Lesen aus dem Repository (repo-get)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls repo-get.

Ähnelt dem Unix-Befehl cat, funktioniert aber mit jedem unterstützten Repository-Typ. Dieser Befehl benötigt einen vollständigen Dateinamen und ist hauptsächlich für Verwaltung, Untersuchung und Tests gedacht. Er ist kein erforderlicher Bestandteil einer normalen pgBackRest-Einrichtung.

Ist das Repository verschlüsselt, entschlüsselt repo-get die Datei automatisch. Dateien werden nicht automatisch dekomprimiert. Die Ausgabe kann jedoch per Pipe an den passenden Dekomprimierungsbefehl weitergegeben werden, etwa gzip -d.

Sind mehrere Repositorys konfiguriert, verwendet der Befehl standardmäßig das Repository mit der höchsten Priorität (z. B. repo1), sofern nicht --repo angegeben wird.

Befehlsoptionen

Option zum Ignorieren fehlender Dateien (--ignore-missing)

Eine fehlende Quelldatei ignorieren.

Bei fehlender Quelldatei mit Status 1 beenden, aber keinen Fehler auslösen.

default: n
example: --ignore-missing

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Rohdaten (--raw)

Daten nicht umwandeln.

Daten für den aktuellen Befehl nicht umwandeln, also etwa nicht verschlüsseln oder dekomprimieren.

default: n
example: --raw

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Repository-Optionen

Option zur Auswahl des Repositorys (--repo)

Repository festlegen.

Legt das Repository fest, auf das ein Befehl wirken soll.

Damit kann beispielsweise eine Wiederherstellung aus einem bestimmten Repository durchgeführt werden, anstatt pgBackRest die Auswahl zu überlassen.

allowed: [1, 256]
example: --repo=1

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Zielzeitpunkt des Repositorys (--repo-target-time)

Zielzeitpunkt für das Repository.

Der Zielzeitpunkt legt fest, welchen Stand des Repositorys Befehle auf versioniertem Speicher lesen. So lässt sich das Repository zu einem früheren Zeitpunkt lesen, um Daten wiederherzustellen, die versehentlich durch Benutzer oder durch Schadsoftware gelöscht oder beschädigt wurden.

S3, GCS und Azure unterstützen versionierten Speicher, aktivieren ihn aber im Allgemeinen nicht standardmäßig. Neben der Versionierung kann es sinnvoll sein, bei S3 die Objektsperre und bei GCS oder Azure das vorläufige Löschen zu aktivieren.

Wenn repo-target-time angegeben wird, muss auch die Option repo angegeben werden. Wahrscheinlich unterstützen nicht alle Repository-Typen die Versionierung. Im Allgemeinen ist es sinnvoll, für die Wiederherstellung ein einzelnes Repository auszuwählen.

Beim Vergleich werden Speicherzeitstempel berücksichtigt, die <= dem angegebenen Zeitstempel sind. Enthaltene Millisekunden werden abgeschnitten.

example: --repo-target-time=2024-08-08 12:12:12+00

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

4.10 - Befehl zum Auflisten des Repository-Inhalts (repo-ls)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls repo-ls.

Ähnelt dem Unix-Befehl ls, funktioniert aber mit jedem unterstützten Repository-Typ. Dieser Befehl akzeptiert einen absoluten Pfad oder einen Pfad relativ zum mit --repo-path angegebenen Repository-Pfad. Er ist hauptsächlich für Verwaltung, Untersuchung und Tests gedacht und kein erforderlicher Bestandteil einer normalen pgBackRest-Einrichtung.

Die standardmäßige Textausgabe enthält einen Dateinamen pro Zeile. Mit --output=json ist eine JSON-Ausgabe verfügbar.

Sind mehrere Repositorys konfiguriert, verwendet der Befehl standardmäßig das Repository mit der höchsten Priorität (z. B. repo1), sofern nicht --repo angegeben wird.

Befehlsoptionen

Option zum Filtern der Ausgabe (--filter)

Die Ausgabe mit einem regulären Ausdruck filtern.

Der Filter wird vor der Ausgabe auf die Datei- und Pfadnamen angewendet.

example: --filter="(F|D|I)$"

Ausgabeoption (--output)

Ausgabeformat.

Die folgenden Ausgabetypen werden unterstützt:

  • text - Einfache Liste mit einem Datei-, Link- oder Pfadnamen pro Zeile.
  • json - Detaillierte Informationen zu Dateien, Links und Pfaden im JSON-Format.

Im JSON-Format sind folgende Felder verfügbar:

  • name - Datei-, Link- oder Pfadname; bei rekursiver Auflistung einschließlich Teilpfad.
  • type - file, path oder link.
  • size - Größe in Byte (nur Dateien).
  • time - Zeitpunkt der letzten Änderung (nur Dateien).
  • destination - Linkziel (nur Links).
default: text
example: --output=json

Option für rekursive Unterpfade (--recurse)

Alle Unterpfade in die Ausgabe aufnehmen.

Alle Unterpfade und ihre Dateien werden in die Ausgabe aufgenommen.

default: n
example: --recurse

Option zum Sortieren der Ausgabe (--sort)

Die Ausgabe aufsteigend, absteigend oder gar nicht sortieren.

Die folgenden Sortierungen werden unterstützt:

  • asc - Aufsteigend sortieren.
  • desc - Absteigend sortieren.
  • none - Nicht sortieren.
default: asc
example: --sort=desc

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Repository-Optionen

Option zur Auswahl des Repositorys (--repo)

Repository festlegen.

Legt das Repository fest, auf das ein Befehl wirken soll.

Damit kann beispielsweise eine Wiederherstellung aus einem bestimmten Repository durchgeführt werden, anstatt pgBackRest die Auswahl zu überlassen.

allowed: [1, 256]
example: --repo=1

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Zielzeitpunkt des Repositorys (--repo-target-time)

Zielzeitpunkt für das Repository.

Der Zielzeitpunkt legt fest, welchen Stand des Repositorys Befehle auf versioniertem Speicher lesen. So lässt sich das Repository zu einem früheren Zeitpunkt lesen, um Daten wiederherzustellen, die versehentlich durch Benutzer oder durch Schadsoftware gelöscht oder beschädigt wurden.

S3, GCS und Azure unterstützen versionierten Speicher, aktivieren ihn aber im Allgemeinen nicht standardmäßig. Neben der Versionierung kann es sinnvoll sein, bei S3 die Objektsperre und bei GCS oder Azure das vorläufige Löschen zu aktivieren.

Wenn repo-target-time angegeben wird, muss auch die Option repo angegeben werden. Wahrscheinlich unterstützen nicht alle Repository-Typen die Versionierung. Im Allgemeinen ist es sinnvoll, für die Wiederherstellung ein einzelnes Repository auszuwählen.

Beim Vergleich werden Speicherzeitstempel berücksichtigt, die <= dem angegebenen Zeitstempel sind. Enthaltene Millisekunden werden abgeschnitten.

example: --repo-target-time=2024-08-08 12:12:12+00

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

4.11 - Befehl zur Wiederherstellung (restore)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls restore.

Der Wiederherstellungsbefehl wählt standardmäßig automatisch das neueste Backup aus dem ersten Repository, das Backups enthält (siehe Schnellstart – Ein Backup wiederherstellen ). Die Reihenfolge der Prüfung wird durch pgbackrest.conf bestimmt; beispielsweise wird repo1 vor repo2 geprüft. Mit --repo lässt sich ein bestimmtes Repository auswählen, etwa mit --repo=1. Soll ein anderes als das neueste Backup verwendet werden, kann es mit --set angegeben werden.

Bei PITR mit --type=time oder --type=lsn muss die Zielzeit bzw. die Ziel-LSN mit der Option --target angegeben werden. Ohne --set werden die konfigurierten Repositorys der Reihe nach nach einem Backup durchsucht, dessen Endzeit vor der Zielzeit liegt bzw. dessen End-LSN kleiner oder gleich der Ziel-LSN ist. Wird kein passendes Backup gefunden, meldet pgBackRest sowohl bei --type=time als auch bei --type=lsn einen Fehler; es fällt nicht auf das neueste Backup zurück. Bei anderen PITR-Typen, z. B. xid, muss die Option --set angegeben werden, wenn das Ziel vor dem neuesten Backup liegt. Weitere Informationen und Beispiele finden Sie unter Point-in-Time-Recovery .

Replikations-Slots werden gemäß der Empfehlung von PostgreSQL nicht aufgenommen. Weitere Informationen bietet Backup des Datenverzeichnisses in der PostgreSQL-Dokumentation.

Befehlsoptionen

Option für den Archivierungsmodus (--archive-mode)

Archivierung auf dem wiederhergestellten Cluster beibehalten oder deaktivieren.

Mit dieser Option lässt sich die Archivierung auf einem wiederhergestellten Cluster beibehalten oder deaktivieren. Dies ist nützlich, wenn der Cluster für bestimmte Arbeiten zum Primärserver hochgestuft werden muss, aber nicht dauerhaft der neue Primärserver werden soll. In diesem Fall ist es nicht ratsam, WAL aus diesem Cluster ins Repository zu übertragen.

Die folgenden Modi werden unterstützt:

  • off - Archivierung durch Setzen von archive_mode=off deaktivieren.
  • preserve - Die aktuelle Einstellung von archive_mode beibehalten.

HINWEIS: Diese Option ist unter PostgreSQL < 12 nicht verfügbar.

default: preserve
example: --archive-mode=off

Option zum Ausschließen von Datenbanken (--db-exclude)

Wiederherstellung unter Ausschluss der angegebenen Datenbanken.

Ausgeschlossene Datenbanken werden als Sparse-Dateien mit Nullinhalt wiederhergestellt. Dies spart Platz und ermöglicht PostgreSQL dennoch die Recovery. Danach sind diese Datenbanken nicht zugänglich, können aber mit drop database entfernt werden. Die Option --db-exclude kann mehrfach angegeben werden, um mehrere Datenbanken auszuschließen.

In Kombination mit --db-include gilt --db-exclude nur für die standardmäßigen Systemdatenbanken template0, template1 und postgres.

example: --db-exclude=db_main

Option zur Auswahl von Datenbanken (--db-include)

Nur die angegebenen Datenbanken wiederherstellen.

Mit dieser Funktion lassen sich gezielt ausgewählte Datenbanken wiederherstellen. Nicht ausdrücklich ausgewählte Datenbanken werden als Sparse-Dateien mit Nullinhalt wiederhergestellt. Dies spart Platz und ermöglicht PostgreSQL dennoch die Recovery. Danach sind die nicht ausgewählten Datenbanken nicht zugänglich, können aber mit drop database entfernt werden.

HINWEIS: Die integrierten Datenbanken template0, template1 und postgres werden immer wiederhergestellt, sofern sie nicht ausdrücklich ausgeschlossen sind.

Die Option --db-include kann mehrfach angegeben werden, um mehrere Datenbanken auszuwählen.

Weitere Informationen und Einschränkungen finden Sie unter Ausgewählte Datenbanken wiederherstellen .

example: --db-include=db_main

Option zum Erzwingen (--force)

Eine Wiederherstellung erzwingen.

Allein verwendet erzwingt diese Option das vollständige Überschreiben der PostgreSQL-Daten- und Tablespace-Pfade. In Kombination mit --delta erfolgt ein Delta-Abgleich anhand von Zeitstempel und Größe statt anhand von Prüfsummen.

default: n
example: --force

Option zur Wiederherstellung aller symbolischen Links (--link-all)

Alle symbolischen Links wiederherstellen.

Standardmäßig werden symbolisch verlinkte Verzeichnisse und Dateien als normale Verzeichnisse und Dateien in $PGDATA wiederhergestellt. Auf einem anderen System als dem Ursprungssystem des Backups ist es möglicherweise nicht sicher, symbolische Links mit ihren ursprünglichen Zielen wiederherzustellen. Diese Option stellt alle symbolischen Links genau so wieder her, wie sie auf dem Ursprungssystem des Backups vorhanden waren.

default: n
example: --link-all

Option zur Zuordnung von Linkzielen (--link-map)

Das Ziel eines symbolischen Links ändern.

Ermöglicht es, die Zieldatei oder den Zielpfad eines symbolischen Links bei der Wiederherstellung zu ändern. Dies ist bei Systemen hilfreich, deren Speicheraufteilung vom Ursprungssystem des Backups abweicht.

example: --link-map=pg_xlog=/data/xlog

Recovery-Option (--recovery-option)

Eine Option in postgresql.auto.conf oder recovery.conf setzen.

Einzelheiten zu den Optionen von postgresql.auto.conf oder recovery.conf finden Sie unter Serverkonfiguration . Wählen Sie dort unbedingt Ihre PostgreSQL-Version aus. Diese Option kann mehrfach verwendet werden.

Für PostgreSQL >= 12 werden die Optionen in postgresql.auto.conf geschrieben, für alle anderen Versionen in recovery.conf.

HINWEIS: restore_command wird automatisch erzeugt, kann aber mit dieser Option überschrieben werden. Einen eigenen restore_command mit Vorsicht angeben, da pgBackRest dafür ausgelegt ist, dies selbst zu übernehmen. Optionen für das Recovery-Ziel wie recovery_target_name und recovery_target_time werden automatisch von pgBackRest erzeugt und sollten nicht mit dieser Option gesetzt werden.

Da pgBackRest PostgreSQL nach dem Schreiben von postgresql.auto.conf oder recovery.conf nicht startet, lassen sich postgresql.auto.conf oder recovery.conf vor einem manuellen Neustart jederzeit bearbeiten und prüfen.

example: --recovery-option=primary_conninfo=db.mydomain.com

Option zur Auswahl des Backup-Satzes (--set)

Wiederherzustellender Backup-Satz.

Der wiederherzustellende Backup-Satz. Mit latest wird das neueste Backup wiederhergestellt. Andernfalls den Namen des gewünschten Backups angeben.

default: latest
example: --set=20150131-153358F_20150131-153401I

Option zur Tablespace-Zuordnung (--tablespace-map)

Einen Tablespace im angegebenen Verzeichnis wiederherstellen.

Verschiebt einen Tablespace bei der Wiederherstellung an einen neuen Speicherort. Dies ist nützlich, wenn sich die Tablespace-Pfade auf einem Replikat unterscheiden oder ein aktualisiertes System andere Einhängepunkte verwendet.

Die Speicherorte von Tablespaces werden nicht in pg_tablespace gespeichert. Deshalb können Tablespaces ohne Folgen verschoben werden. Ein Verschieben in data_directory wird jedoch nicht empfohlen und kann Probleme verursachen. Weitere hilfreiche Informationen zum Verschieben von Tablespaces bietet http://www.databasesoup.com/2013/11/moving-tablespaces.html .

example: --tablespace-map=ts_01=/db/ts_01

Option zur Zuordnung aller Tablespaces (--tablespace-map-all)

Alle Tablespaces im angegebenen Verzeichnis wiederherstellen.

Tablespaces werden standardmäßig an ihren ursprünglichen Speicherorten wiederhergestellt. Dies lässt sich mit tablespace-map für jeden Tablespace ändern. Manchmal ist es jedoch sinnvoller, alle Tablespaces auf einmal einem neuen Verzeichnis zuzuordnen. Dies ist besonders für Entwicklungs- oder Staging-Systeme nützlich, deren Speicheraufteilung vom Ursprungssystem des Backups abweichen kann.

Der angegebene Pfad dient als übergeordnetes Verzeichnis, unter dem alle Tablespaces des Backups erstellt werden.

ACHTUNG:

Tablespaces, die nach Beginn des Backups erstellt wurden, werden nicht neu zugeordnet. Ist eine Tablespace-Zuordnung erforderlich, nach dem Erstellen eines Tablespaces ein neues Backup erstellen.

example: --tablespace-map-all=/data/tablespace

Option für das Ziel (--target)

Recovery-Ziel.

Definiert das Recovery-Ziel, wenn --type auf lsn, name, xid oder time gesetzt ist. Liegt das Ziel vor dem neuesten Backup und ist --type weder time noch lsn, den Backup-Satz mit --set angeben.

example: --target=2015-01-30 14:15:11 EST

Option für die Aktion am Ziel (--target-action)

Aktion beim Erreichen des Recovery-Ziels.

Bei hot_standby=on, dem Standard seit PostgreSQL 10, steuert diese Option einheitlich, was der Cluster beim Erreichen des Ziels oder am Ende des WAL-Archivs tut.

Bei hot_standby=off unter PostgreSQL >= 12 verhält sich pause wie shutdown. Bei hot_standby=off unter PostgreSQL < 12 verhält sich pause wie promote.

Die folgenden Aktionen werden unterstützt:

  • pause - Beim Erreichen des Recovery-Ziels pausieren.
  • promote - Beim Erreichen des Recovery-Ziels zum Primärserver hochstufen und die Timeline wechseln.
  • shutdown - Beim Erreichen des Recovery-Ziels den Server herunterfahren. (PostgreSQL >= 9.5)
default: pause
example: --target-action=promote

Option zum Ausschließen des Ziels (--target-exclusive)

Unmittelbar vor dem Recovery-Ziel anhalten.

Legt fest, ob die Recovery das Ziel ausschließt; standardmäßig wird es eingeschlossen. Die Option ist nur gültig, wenn --type auf lsn, time oder xid gesetzt ist. Beispielsweise schließt --target-exclusive den Inhalt der Transaktion 1007 aus, wenn --type=xid und --target=1007 gesetzt sind. Weitere Informationen bietet die Option recovery_target_inclusive in der PostgreSQL-Dokumentation.

default: n
example: --no-target-exclusive

Option für die Ziel-Timeline (--target-timeline)

Recovery entlang einer Timeline durchführen.

Weitere Informationen bietet recovery_target_timeline in der PostgreSQL-Dokumentation.

example: --target-timeline=3

Option für den Typ (--type)

Recovery-Typ.

Die folgenden Recovery-Typen werden unterstützt:

  • default - Recovery bis zum Ende des Archivstroms durchführen.
  • immediate - Recovery nur bis zum Erreichen eines konsistenten Datenbankzustands durchführen.
  • lsn - Recovery bis zur mit --target angegebenen LSN (Log Sequence Number) durchführen. Diese Option wird nur unter PostgreSQL >= 10 unterstützt.
  • name - Recovery bis zum mit --target angegebenen Wiederherstellungspunkt durchführen.
  • xid - Recovery bis zur mit --target angegebenen Transaktions-ID durchführen.
  • time - Recovery bis zum mit --target angegebenen Zeitpunkt durchführen.
  • preserve - Die vorhandene Datei postgresql.auto.conf oder recovery.conf beibehalten.
  • standby - standby_mode=on in postgresql.auto.conf oder recovery.conf eintragen, damit der Cluster im Standby-Modus startet.
  • none - Weder postgresql.auto.conf noch recovery.conf schreiben. PostgreSQL versucht dann, mit den WAL-Segmenten in pg_xlog/pg_wal einen konsistenten Zustand zu erreichen. Die erforderlichen WAL-Segmente bereitstellen oder sie mit archive-copy in das Backup aufnehmen.

WARNUNG:

Recovery mit type=none sollte vermieden werden, da am Ende der Recovery die Timeline nicht erhöht wird. Dadurch kann PostgreSQL beispielsweise versuchen, doppelte WAL-Segmente zu archivieren. Diese werden abgelehnt, wodurch sich der Datenträger füllen und PostgreSQL mit einer Panic reagieren kann. Außerdem funktionieren Werkzeuge wie pg_rewind möglicherweise nicht korrekt oder verursachen Datenbeschädigungen.

Der standardmäßige Wiederherstellungswert für type ist bei Offline-Backups none, da bei wal_level=minimal keine Point-in-Time-Recovery möglich ist. Ein ausdrücklich gesetzter type wird jedoch berücksichtigt, da Point-in-Time-Recovery aus Offline-Backups möglich ist, solange wal_level > minimal gilt.

default: default
example: --type=xid

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: y
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den pgBackRest-Befehl (--cmd)

pgBackRest-Befehl.

pgBackRest kann eine Befehlszeichenfolge erzeugen, etwa wenn der Befehl restore die Einstellung restore_command erzeugt. Dafür wird der Befehl verwendet, mit dem der pgBackRest-Prozess gestartet wurde, sofern nicht die Option cmd angegeben ist.

ACHTUNG:

Das Einbetten des pgBackRest-Befehls in einen Wrapper kann unvorhersehbares Verhalten verursachen und wird nicht empfohlen.

default: [path of executed pgbackrest binary]
example: --cmd=/var/lib/pgsql/bin/pgbackrest_wrapper.sh

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Delta-Option (--delta)

Wiederherstellung oder Backup anhand von Prüfsummen durchführen.

Bei einer Wiederherstellung wird standardmäßig erwartet, dass die PostgreSQL-Daten- und Tablespace-Verzeichnisse vorhanden, aber leer sind. Diese Option führt eine Delta-Wiederherstellung anhand von Prüfsummen durch.

Bei einem Backup verwendet diese Option Prüfsummen anstelle von Zeitstempeln, um zu entscheiden, ob Dateien kopiert werden.

default: n
example: --delta

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für die maximale Prozessanzahl (--process-max)

Maximale Anzahl der Prozesse für Komprimierung und Übertragung.

Jeder Prozess führt Komprimierung und Übertragung aus, um den Befehl zu beschleunigen. process-max jedoch nicht so hoch setzen, dass die Datenbankleistung beeinträchtigt wird.

default: 1
allowed: [1, 999]
example: --process-max=4

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Optionen für Maintainer

Option zum Erzwingen der PostgreSQL-Version (--pg-version-force)

PostgreSQL-Version erzwingen.

Verwendet die angegebene PostgreSQL-Version statt der Version, die automatisch aus pg_control oder WAL-Headern ermittelt wird. Dies ist hauptsächlich für PostgreSQL-Forks oder Entwicklungsversionen hilfreich, deren Werte von denen der veröffentlichten Version abweichen. Die von PostgreSQL über server_version_num gemeldete Version muss mit der erzwungenen Version übereinstimmen.

WARNUNG:

Diese Option mit Vorsicht verwenden: pg_control und WAL-Header werden weiterhin im erwarteten Format der angegebenen Version gelesen, also im Format der offiziellen Open-Source-Version von PostgreSQL. Ändert der Fork oder die Entwicklungsversion das Format von Feldern, auf die pgBackRest angewiesen ist, führt dies zu unerwartetem Verhalten. Im Allgemeinen funktioniert diese Option nur dann wie erwartet, wenn der Fork alle eigenen Strukturfelder nach den standardmäßigen PostgreSQL-Feldern hinzufügt.

example: --pg-version-force=15

Repository-Optionen

Option zur Auswahl des Repositorys (--repo)

Repository festlegen.

Legt das Repository fest, auf das ein Befehl wirken soll.

Damit kann beispielsweise eine Wiederherstellung aus einem bestimmten Repository durchgeführt werden, anstatt pgBackRest die Auswahl zu überlassen.

allowed: [1, 256]
example: --repo=1

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Zielzeitpunkt des Repositorys (--repo-target-time)

Zielzeitpunkt für das Repository.

Der Zielzeitpunkt legt fest, welchen Stand des Repositorys Befehle auf versioniertem Speicher lesen. So lässt sich das Repository zu einem früheren Zeitpunkt lesen, um Daten wiederherzustellen, die versehentlich durch Benutzer oder durch Schadsoftware gelöscht oder beschädigt wurden.

S3, GCS und Azure unterstützen versionierten Speicher, aktivieren ihn aber im Allgemeinen nicht standardmäßig. Neben der Versionierung kann es sinnvoll sein, bei S3 die Objektsperre und bei GCS oder Azure das vorläufige Löschen zu aktivieren.

Wenn repo-target-time angegeben wird, muss auch die Option repo angegeben werden. Wahrscheinlich unterstützen nicht alle Repository-Typen die Versionierung. Im Allgemeinen ist es sinnvoll, für die Wiederherstellung ein einzelnes Repository auszuwählen.

Beim Vergleich werden Speicherzeitstempel berücksichtigt, die <= dem angegebenen Zeitstempel sind. Enthaltene Millisekunden werden abgeschnitten.

example: --repo-target-time=2024-08-08 12:12:12+00

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

Stanza-Optionen

Option für den PostgreSQL-Pfad (--pg-path)

PostgreSQL-Datenverzeichnis.

Dieser Pfad sollte dem von PostgreSQL gemeldeten data_directory entsprechen. Obwohl sich der Wert an verschiedenen Stellen auslesen lässt, ist eine ausdrückliche Angabe ratsam, falls diese Quellen bei einer Wiederherstellung oder einem Offline-Backup nicht verfügbar sind.

Bei jedem Online-Backup wird pg-path mit dem von PostgreSQL gemeldeten Wert verglichen. Die Option sollte daher immer aktuell sein.

example: --pg1-path=/data/db

Veralteter Name: db-path

4.12 - Server-Befehl (server)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls server.

Der pgBackRest-Server ermöglicht den Zugriff auf entfernte Hosts ohne das SSH-Protokoll.

Befehlsoptionen

Option für die TLS-Serveradresse (--tls-server-address)

TLS-Serveradresse.

IP-Adresse, an der der Server auf Client-Anfragen wartet.

default: localhost
example: --tls-server-address=*

Option für berechtigte TLS-Clients (--tls-server-auth)

Für den TLS-Server berechtigte Clients.

Der Server autorisiert Clients, indem er ihr Zertifikat prüft und dessen CN (Common Name) mit einer Liste vergleicht, die auf dem Server mit der Option tls-server-auth konfiguriert ist.

Ein Client-CN kann für beliebig viele Stanzas berechtigt werden, indem der Option tls-server-auth eine durch Kommas getrennte Liste übergeben wird. Mit tls-server-auth=client-cn=* gilt die Berechtigung für alle Stanzas. Im Client-CN dürfen keine Platzhalter angegeben werden.

example: --tls-server-auth=client-cn=stanza1,stanza2

Option für die Zertifizierungsstellen des TLS-Servers (--tls-server-ca-file)

Zertifizierungsstellen des TLS-Servers.

Prüft, ob Client-Zertifikate von einer vertrauenswürdigen Zertifizierungsstelle signiert sind.

example: --tls-server-ca-file=/path/to/server.ca

Option für das TLS-Serverzertifikat (--tls-server-cert-file)

Datei mit dem TLS-Serverzertifikat.

Wird an den Client gesendet, um die Identität des Servers nachzuweisen.

example: --tls-server-cert-file=/path/to/server.crt

Option für den TLS-Serverschlüssel (--tls-server-key-file)

Datei mit dem TLS-Serverschlüssel.

Weist nach, dass das Serverzertifikat von seinem Eigentümer gesendet wurde.

example: --tls-server-key-file=/path/to/server.key

Option für den TLS-Serverport (--tls-server-port)

TLS-Serverport.

Port, an dem der Server auf Client-Anfragen wartet.

default: 8432
allowed: [1, 65535]
example: --tls-server-port=8000

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

4.13 - Server-Ping-Befehl (server-ping)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls server-ping.

Einen pgBackRest-TLS-Server mit einem Ping darauf prüfen, ob er Verbindungen annimmt. Dabei wird nur geprüft, ob der Server reagiert; eine Authentifizierung findet nicht statt.

Wird in der Befehlszeile kein Host angegeben, wird die Option tls-server-host verwendet.

Befehlsoptionen

Option für die TLS-Serveradresse (--tls-server-address)

TLS-Serveradresse.

IP-Adresse, an der der Server auf Client-Anfragen wartet.

default: localhost
example: --tls-server-address=*

Option für den TLS-Serverport (--tls-server-port)

TLS-Serverport.

Port, an dem der Server auf Client-Anfragen wartet.

default: 8432
allowed: [1, 65535]
example: --tls-server-port=8000

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

4.14 - Befehl zum Erstellen einer Stanza (stanza-create)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls stanza-create.

Nach der Konfiguration einer Stanza in pgbackrest.conf muss stanza-create ausgeführt werden. Sind mehrere Repositorys konfiguriert, wird die Stanza in jedem erstellt. Bereits erstellte Stanzas werden übersprungen. Daher kann stanza-create jederzeit gefahrlos ausgeführt werden, auch wenn ein neues Repository konfiguriert wurde.

Weitere Informationen und ein Beispiel finden Sie unter Die Stanza erstellen .

Befehlsoptionen

Online-Option (--online)

Auf einem laufenden Cluster erstellen.

Mit –no-online verbindet sich pgBackRest beim Erstellen der Stanza nicht mit PostgreSQL.

default: y
example: --no-online

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das Datenbankzeitlimit (--db-timeout)

Zeitlimit für Datenbankabfragen.

Legt das Zeitlimit für Datenbankabfragen in Sekunden fest. Dazu gehören auch die Funktionen zum Starten und Stoppen des Backups, die jeweils viel Zeit benötigen können. Daher sollte das Zeitlimit hoch bleiben, sofern nicht bekannt ist, dass diese Funktionen schnell zurückkehren, etwa wenn start-fast=y gesetzt ist und bekannt ist, dass der Datenbankcluster während des Backups nur wenige WAL-Segmente erzeugt.

HINWEIS: Der Wert von db-timeout muss kleiner sein als der von protocol-timeout.

default: 30m
allowed: [100ms, 7d]
example: --db-timeout=600

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Optionen für Maintainer

Option zum Erzwingen der PostgreSQL-Version (--pg-version-force)

PostgreSQL-Version erzwingen.

Verwendet die angegebene PostgreSQL-Version statt der Version, die automatisch aus pg_control oder WAL-Headern ermittelt wird. Dies ist hauptsächlich für PostgreSQL-Forks oder Entwicklungsversionen hilfreich, deren Werte von denen der veröffentlichten Version abweichen. Die von PostgreSQL über server_version_num gemeldete Version muss mit der erzwungenen Version übereinstimmen.

WARNUNG:

Diese Option mit Vorsicht verwenden: pg_control und WAL-Header werden weiterhin im erwarteten Format der angegebenen Version gelesen, also im Format der offiziellen Open-Source-Version von PostgreSQL. Ändert der Fork oder die Entwicklungsversion das Format von Feldern, auf die pgBackRest angewiesen ist, führt dies zu unerwartetem Verhalten. Im Allgemeinen funktioniert diese Option nur dann wie erwartet, wenn der Fork alle eigenen Strukturfelder nach den standardmäßigen PostgreSQL-Feldern hinzufügt.

example: --pg-version-force=15

Repository-Optionen

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

Stanza-Optionen

Option für die PostgreSQL-Datenbank (--pg-database)

PostgreSQL-Datenbank.

Name der Datenbank für Verbindungen zu PostgreSQL. Meist ist der Standardwert die beste Wahl, doch manche Installationen enthalten diese Datenbank möglicherweise nicht.

Aus Kompatibilitätsgründen wird die Umgebungsvariable PGDATABASE ignoriert.

default: postgres
example: --pg1-database=backupdb

Option für den PostgreSQL-Host (--pg-host)

PostgreSQL-Host für die Ausführung auf einem entfernten System.

Für Backups, bei denen PostgreSQL-Host und Repository-Host unterschiedliche Systeme sind.

example: --pg1-host=db.domain.com

Veralteter Name: db-host

Option für die CA-Datei des PostgreSQL-Hosts (--pg-host-ca-file)

Datei mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host eine andere als die systemweite CA-Datei verwenden.

example: --pg1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des PostgreSQL-Hosts (--pg-host-ca-path)

Pfad mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --pg1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des PostgreSQL-Hosts (--pg-host-cert-file)

Zertifikatdatei für den PostgreSQL-Host.

Wird an den PostgreSQL-Host gesendet, um die Identität des Clients nachzuweisen.

example: --pg1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem PostgreSQL-Host (--pg-host-cmd)

pgBackRest-Befehl auf dem PostgreSQL-Host.

Nur erforderlich, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem PostgreSQL-Host unterschiedlich ist. Ohne Angabe wird auf dem PostgreSQL-Host derselbe Befehl wie lokal verwendet.

default: [path of executed pgbackrest binary]
example: --pg1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: db-cmd

Option für die Konfiguration des PostgreSQL-Hosts (--pg-host-config)

pgBackRest-Konfigurationsdatei auf dem Datenbank-Host.

Legt den Speicherort der Konfigurationsdatei auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn die Datei dort an einem anderen Ort liegt als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --pg1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: db-config

Option für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host (--pg-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Datenbank-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --pg1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des PostgreSQL-Hosts (--pg-host-config-path)

pgBackRest-Konfigurationspfad auf dem Datenbank-Host.

Legt den Konfigurationspfad auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --pg1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des PostgreSQL-Hosts (--pg-host-key-file)

Schlüsseldatei für den PostgreSQL-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --pg1-host-key-file=/path/to/client.key

Option für den Port des PostgreSQL-Hosts (--pg-host-port)

Port des PostgreSQL-Hosts, wenn pg-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des PostgreSQL-Hosts angeben.

HINWEIS: Bei pg-host-type=ssh gibt es keinen Standardwert für pg-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on pg-host-type):
    tls - 8432

allowed: [0, 65535]
example: --pg1-host-port=25

Veralteter Name: db-ssh-port

Option für den Protokolltyp des PostgreSQL-Hosts (--pg-host-type)

Protokolltyp für den PostgreSQL-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --pg1-host-type=tls

Option für den Benutzer auf dem PostgreSQL-Host (--pg-host-user)

Anmeldebenutzer auf dem PostgreSQL-Host, wenn pg-host gesetzt ist.

Unter diesem Benutzer läuft auch der entfernte pgBackRest-Prozess, und er baut die Verbindungen zu PostgreSQL auf. Damit dies korrekt funktioniert, sollte er Eigentümer des PostgreSQL-Datenbankclusters sein. Üblicherweise ist dies postgres, der Standardwert.

default: postgres
example: --pg1-host-user=db_owner

Veralteter Name: db-user

Option für den PostgreSQL-Pfad (--pg-path)

PostgreSQL-Datenverzeichnis.

Dieser Pfad sollte dem von PostgreSQL gemeldeten data_directory entsprechen. Obwohl sich der Wert an verschiedenen Stellen auslesen lässt, ist eine ausdrückliche Angabe ratsam, falls diese Quellen bei einer Wiederherstellung oder einem Offline-Backup nicht verfügbar sind.

Bei jedem Online-Backup wird pg-path mit dem von PostgreSQL gemeldeten Wert verglichen. Die Option sollte daher immer aktuell sein.

example: --pg1-path=/data/db

Veralteter Name: db-path

Option für den PostgreSQL-Port (--pg-port)

PostgreSQL-Port.

Port, auf dem PostgreSQL läuft. Dieser muss normalerweise nicht angegeben werden, da die meisten PostgreSQL-Cluster den Standardport verwenden.

default: 5432
allowed: [0, 65535]
example: --pg1-port=6543

Veralteter Name: db-port

Option für den PostgreSQL-Socket-Pfad (--pg-socket-path)

Pfad zum PostgreSQL-Unix-Socket.

Das beim Start von PostgreSQL angegebene Unix-Socket-Verzeichnis. pgBackRest sucht automatisch am üblichen Speicherort des Betriebssystems. Diese Einstellung ist daher normalerweise nur erforderlich, wenn das Socket-Verzeichnis ausdrücklich über unix_socket_directories in postgresql.conf geändert wurde.

example: --pg1-socket-path=/var/run/postgresql

Veralteter Name: db-socket-path

Option für den PostgreSQL-Datenbankbenutzer (--pg-user)

PostgreSQL-Datenbankbenutzer.

Datenbankbenutzername für Verbindungen zu PostgreSQL. Ohne Angabe verbindet sich pgBackRest mit dem lokalen Betriebssystembenutzer oder mit PGUSER.

example: --pg1-user=backupuser

4.15 - Befehl zum Löschen einer Stanza (stanza-delete)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls stanza-delete.

Der Befehl stanza-delete entfernt die zu einer Stanza gehörenden Daten aus dem Repository.

WARNUNG:

Diesen Befehl mit Vorsicht verwenden: Er entfernt dauerhaft alle Backups und Archive der angegebenen Stanza aus dem pgBackRest-Repository.

So löschen Sie eine Stanza:

  • Den zur Stanza gehörenden PostgreSQL-Cluster herunterfahren oder diese Anforderung mit –force übergehen.
  • Den Befehl stop auf dem Host ausführen, auf dem stanza-delete ausgeführt werden soll.
  • Den Befehl stanza-delete ausführen.

Nach erfolgreichem Abschluss muss der Benutzer die Stanza selbst aus allen pgBackRest-Konfigurationsdateien und/oder Umgebungsvariablen entfernen.

Eine Stanza kann jeweils nur aus einem Repository gelöscht werden. Zum Löschen aus mehreren Repositorys den Befehl stanza-delete für jedes Repository mit der Option --repo wiederholen.

Befehlsoptionen

Option zum Erzwingen (--force)

Das Löschen der Stanza erzwingen.

Läuft PostgreSQL für die Stanza noch, kann mit dieser Option das Löschen der Stanza aus dem Repository erzwungen werden.

default: n
example: --no-force

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das Datenbankzeitlimit (--db-timeout)

Zeitlimit für Datenbankabfragen.

Legt das Zeitlimit für Datenbankabfragen in Sekunden fest. Dazu gehören auch die Funktionen zum Starten und Stoppen des Backups, die jeweils viel Zeit benötigen können. Daher sollte das Zeitlimit hoch bleiben, sofern nicht bekannt ist, dass diese Funktionen schnell zurückkehren, etwa wenn start-fast=y gesetzt ist und bekannt ist, dass der Datenbankcluster während des Backups nur wenige WAL-Segmente erzeugt.

HINWEIS: Der Wert von db-timeout muss kleiner sein als der von protocol-timeout.

default: 30m
allowed: [100ms, 7d]
example: --db-timeout=600

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Optionen für Maintainer

Option zum Erzwingen der PostgreSQL-Version (--pg-version-force)

PostgreSQL-Version erzwingen.

Verwendet die angegebene PostgreSQL-Version statt der Version, die automatisch aus pg_control oder WAL-Headern ermittelt wird. Dies ist hauptsächlich für PostgreSQL-Forks oder Entwicklungsversionen hilfreich, deren Werte von denen der veröffentlichten Version abweichen. Die von PostgreSQL über server_version_num gemeldete Version muss mit der erzwungenen Version übereinstimmen.

WARNUNG:

Diese Option mit Vorsicht verwenden: pg_control und WAL-Header werden weiterhin im erwarteten Format der angegebenen Version gelesen, also im Format der offiziellen Open-Source-Version von PostgreSQL. Ändert der Fork oder die Entwicklungsversion das Format von Feldern, auf die pgBackRest angewiesen ist, führt dies zu unerwartetem Verhalten. Im Allgemeinen funktioniert diese Option nur dann wie erwartet, wenn der Fork alle eigenen Strukturfelder nach den standardmäßigen PostgreSQL-Feldern hinzufügt.

example: --pg-version-force=15

Repository-Optionen

Option zur Auswahl des Repositorys (--repo)

Repository festlegen.

Legt das Repository fest, auf das ein Befehl wirken soll.

Damit kann beispielsweise eine Wiederherstellung aus einem bestimmten Repository durchgeführt werden, anstatt pgBackRest die Auswahl zu überlassen.

allowed: [1, 256]
example: --repo=1

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

Stanza-Optionen

Option für die PostgreSQL-Datenbank (--pg-database)

PostgreSQL-Datenbank.

Name der Datenbank für Verbindungen zu PostgreSQL. Meist ist der Standardwert die beste Wahl, doch manche Installationen enthalten diese Datenbank möglicherweise nicht.

Aus Kompatibilitätsgründen wird die Umgebungsvariable PGDATABASE ignoriert.

default: postgres
example: --pg1-database=backupdb

Option für den PostgreSQL-Host (--pg-host)

PostgreSQL-Host für die Ausführung auf einem entfernten System.

Für Backups, bei denen PostgreSQL-Host und Repository-Host unterschiedliche Systeme sind.

example: --pg1-host=db.domain.com

Veralteter Name: db-host

Option für die CA-Datei des PostgreSQL-Hosts (--pg-host-ca-file)

Datei mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host eine andere als die systemweite CA-Datei verwenden.

example: --pg1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des PostgreSQL-Hosts (--pg-host-ca-path)

Pfad mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --pg1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des PostgreSQL-Hosts (--pg-host-cert-file)

Zertifikatdatei für den PostgreSQL-Host.

Wird an den PostgreSQL-Host gesendet, um die Identität des Clients nachzuweisen.

example: --pg1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem PostgreSQL-Host (--pg-host-cmd)

pgBackRest-Befehl auf dem PostgreSQL-Host.

Nur erforderlich, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem PostgreSQL-Host unterschiedlich ist. Ohne Angabe wird auf dem PostgreSQL-Host derselbe Befehl wie lokal verwendet.

default: [path of executed pgbackrest binary]
example: --pg1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: db-cmd

Option für die Konfiguration des PostgreSQL-Hosts (--pg-host-config)

pgBackRest-Konfigurationsdatei auf dem Datenbank-Host.

Legt den Speicherort der Konfigurationsdatei auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn die Datei dort an einem anderen Ort liegt als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --pg1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: db-config

Option für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host (--pg-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Datenbank-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --pg1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des PostgreSQL-Hosts (--pg-host-config-path)

pgBackRest-Konfigurationspfad auf dem Datenbank-Host.

Legt den Konfigurationspfad auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --pg1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des PostgreSQL-Hosts (--pg-host-key-file)

Schlüsseldatei für den PostgreSQL-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --pg1-host-key-file=/path/to/client.key

Option für den Port des PostgreSQL-Hosts (--pg-host-port)

Port des PostgreSQL-Hosts, wenn pg-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des PostgreSQL-Hosts angeben.

HINWEIS: Bei pg-host-type=ssh gibt es keinen Standardwert für pg-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on pg-host-type):
    tls - 8432

allowed: [0, 65535]
example: --pg1-host-port=25

Veralteter Name: db-ssh-port

Option für den Protokolltyp des PostgreSQL-Hosts (--pg-host-type)

Protokolltyp für den PostgreSQL-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --pg1-host-type=tls

Option für den Benutzer auf dem PostgreSQL-Host (--pg-host-user)

Anmeldebenutzer auf dem PostgreSQL-Host, wenn pg-host gesetzt ist.

Unter diesem Benutzer läuft auch der entfernte pgBackRest-Prozess, und er baut die Verbindungen zu PostgreSQL auf. Damit dies korrekt funktioniert, sollte er Eigentümer des PostgreSQL-Datenbankclusters sein. Üblicherweise ist dies postgres, der Standardwert.

default: postgres
example: --pg1-host-user=db_owner

Veralteter Name: db-user

Option für den PostgreSQL-Pfad (--pg-path)

PostgreSQL-Datenverzeichnis.

Dieser Pfad sollte dem von PostgreSQL gemeldeten data_directory entsprechen. Obwohl sich der Wert an verschiedenen Stellen auslesen lässt, ist eine ausdrückliche Angabe ratsam, falls diese Quellen bei einer Wiederherstellung oder einem Offline-Backup nicht verfügbar sind.

Bei jedem Online-Backup wird pg-path mit dem von PostgreSQL gemeldeten Wert verglichen. Die Option sollte daher immer aktuell sein.

example: --pg1-path=/data/db

Veralteter Name: db-path

Option für den PostgreSQL-Port (--pg-port)

PostgreSQL-Port.

Port, auf dem PostgreSQL läuft. Dieser muss normalerweise nicht angegeben werden, da die meisten PostgreSQL-Cluster den Standardport verwenden.

default: 5432
allowed: [0, 65535]
example: --pg1-port=6543

Veralteter Name: db-port

Option für den PostgreSQL-Socket-Pfad (--pg-socket-path)

Pfad zum PostgreSQL-Unix-Socket.

Das beim Start von PostgreSQL angegebene Unix-Socket-Verzeichnis. pgBackRest sucht automatisch am üblichen Speicherort des Betriebssystems. Diese Einstellung ist daher normalerweise nur erforderlich, wenn das Socket-Verzeichnis ausdrücklich über unix_socket_directories in postgresql.conf geändert wurde.

example: --pg1-socket-path=/var/run/postgresql

Veralteter Name: db-socket-path

Option für den PostgreSQL-Datenbankbenutzer (--pg-user)

PostgreSQL-Datenbankbenutzer.

Datenbankbenutzername für Verbindungen zu PostgreSQL. Ohne Angabe verbindet sich pgBackRest mit dem lokalen Betriebssystembenutzer oder mit PGUSER.

example: --pg1-user=backupuser

4.16 - Befehl zum Aktualisieren einer Stanza (stanza-upgrade)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls stanza-upgrade.

Unmittelbar nach einem Upgrade auf eine neuere PostgreSQL-Hauptversion muss pg-path in allen pgBackRest-Konfigurationen auf das neue Datenbankverzeichnis gesetzt und stanza-upgrade ausgeführt werden. Sind mehrere Repositorys auf dem Host konfiguriert, wird die Stanza in jedem aktualisiert. Ist die Datenbank offline, die Option --no-online verwenden.

Befehlsoptionen

Online-Option (--online)

Einen laufenden Cluster aktualisieren.

Mit –no-online verbindet sich pgBackRest beim Aktualisieren der Stanza nicht mit PostgreSQL.

default: y
example: --no-online

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das Datenbankzeitlimit (--db-timeout)

Zeitlimit für Datenbankabfragen.

Legt das Zeitlimit für Datenbankabfragen in Sekunden fest. Dazu gehören auch die Funktionen zum Starten und Stoppen des Backups, die jeweils viel Zeit benötigen können. Daher sollte das Zeitlimit hoch bleiben, sofern nicht bekannt ist, dass diese Funktionen schnell zurückkehren, etwa wenn start-fast=y gesetzt ist und bekannt ist, dass der Datenbankcluster während des Backups nur wenige WAL-Segmente erzeugt.

HINWEIS: Der Wert von db-timeout muss kleiner sein als der von protocol-timeout.

default: 30m
allowed: [100ms, 7d]
example: --db-timeout=600

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Optionen für Maintainer

Option zum Erzwingen der PostgreSQL-Version (--pg-version-force)

PostgreSQL-Version erzwingen.

Verwendet die angegebene PostgreSQL-Version statt der Version, die automatisch aus pg_control oder WAL-Headern ermittelt wird. Dies ist hauptsächlich für PostgreSQL-Forks oder Entwicklungsversionen hilfreich, deren Werte von denen der veröffentlichten Version abweichen. Die von PostgreSQL über server_version_num gemeldete Version muss mit der erzwungenen Version übereinstimmen.

WARNUNG:

Diese Option mit Vorsicht verwenden: pg_control und WAL-Header werden weiterhin im erwarteten Format der angegebenen Version gelesen, also im Format der offiziellen Open-Source-Version von PostgreSQL. Ändert der Fork oder die Entwicklungsversion das Format von Feldern, auf die pgBackRest angewiesen ist, führt dies zu unerwartetem Verhalten. Im Allgemeinen funktioniert diese Option nur dann wie erwartet, wenn der Fork alle eigenen Strukturfelder nach den standardmäßigen PostgreSQL-Feldern hinzufügt.

example: --pg-version-force=15

Repository-Optionen

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

Stanza-Optionen

Option für die PostgreSQL-Datenbank (--pg-database)

PostgreSQL-Datenbank.

Name der Datenbank für Verbindungen zu PostgreSQL. Meist ist der Standardwert die beste Wahl, doch manche Installationen enthalten diese Datenbank möglicherweise nicht.

Aus Kompatibilitätsgründen wird die Umgebungsvariable PGDATABASE ignoriert.

default: postgres
example: --pg1-database=backupdb

Option für den PostgreSQL-Host (--pg-host)

PostgreSQL-Host für die Ausführung auf einem entfernten System.

Für Backups, bei denen PostgreSQL-Host und Repository-Host unterschiedliche Systeme sind.

example: --pg1-host=db.domain.com

Veralteter Name: db-host

Option für die CA-Datei des PostgreSQL-Hosts (--pg-host-ca-file)

Datei mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host eine andere als die systemweite CA-Datei verwenden.

example: --pg1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des PostgreSQL-Hosts (--pg-host-ca-path)

Pfad mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --pg1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des PostgreSQL-Hosts (--pg-host-cert-file)

Zertifikatdatei für den PostgreSQL-Host.

Wird an den PostgreSQL-Host gesendet, um die Identität des Clients nachzuweisen.

example: --pg1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem PostgreSQL-Host (--pg-host-cmd)

pgBackRest-Befehl auf dem PostgreSQL-Host.

Nur erforderlich, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem PostgreSQL-Host unterschiedlich ist. Ohne Angabe wird auf dem PostgreSQL-Host derselbe Befehl wie lokal verwendet.

default: [path of executed pgbackrest binary]
example: --pg1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: db-cmd

Option für die Konfiguration des PostgreSQL-Hosts (--pg-host-config)

pgBackRest-Konfigurationsdatei auf dem Datenbank-Host.

Legt den Speicherort der Konfigurationsdatei auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn die Datei dort an einem anderen Ort liegt als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --pg1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: db-config

Option für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host (--pg-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Datenbank-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --pg1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des PostgreSQL-Hosts (--pg-host-config-path)

pgBackRest-Konfigurationspfad auf dem Datenbank-Host.

Legt den Konfigurationspfad auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --pg1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des PostgreSQL-Hosts (--pg-host-key-file)

Schlüsseldatei für den PostgreSQL-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --pg1-host-key-file=/path/to/client.key

Option für den Port des PostgreSQL-Hosts (--pg-host-port)

Port des PostgreSQL-Hosts, wenn pg-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des PostgreSQL-Hosts angeben.

HINWEIS: Bei pg-host-type=ssh gibt es keinen Standardwert für pg-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on pg-host-type):
    tls - 8432

allowed: [0, 65535]
example: --pg1-host-port=25

Veralteter Name: db-ssh-port

Option für den Protokolltyp des PostgreSQL-Hosts (--pg-host-type)

Protokolltyp für den PostgreSQL-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --pg1-host-type=tls

Option für den Benutzer auf dem PostgreSQL-Host (--pg-host-user)

Anmeldebenutzer auf dem PostgreSQL-Host, wenn pg-host gesetzt ist.

Unter diesem Benutzer läuft auch der entfernte pgBackRest-Prozess, und er baut die Verbindungen zu PostgreSQL auf. Damit dies korrekt funktioniert, sollte er Eigentümer des PostgreSQL-Datenbankclusters sein. Üblicherweise ist dies postgres, der Standardwert.

default: postgres
example: --pg1-host-user=db_owner

Veralteter Name: db-user

Option für den PostgreSQL-Pfad (--pg-path)

PostgreSQL-Datenverzeichnis.

Dieser Pfad sollte dem von PostgreSQL gemeldeten data_directory entsprechen. Obwohl sich der Wert an verschiedenen Stellen auslesen lässt, ist eine ausdrückliche Angabe ratsam, falls diese Quellen bei einer Wiederherstellung oder einem Offline-Backup nicht verfügbar sind.

Bei jedem Online-Backup wird pg-path mit dem von PostgreSQL gemeldeten Wert verglichen. Die Option sollte daher immer aktuell sein.

example: --pg1-path=/data/db

Veralteter Name: db-path

Option für den PostgreSQL-Port (--pg-port)

PostgreSQL-Port.

Port, auf dem PostgreSQL läuft. Dieser muss normalerweise nicht angegeben werden, da die meisten PostgreSQL-Cluster den Standardport verwenden.

default: 5432
allowed: [0, 65535]
example: --pg1-port=6543

Veralteter Name: db-port

Option für den PostgreSQL-Socket-Pfad (--pg-socket-path)

Pfad zum PostgreSQL-Unix-Socket.

Das beim Start von PostgreSQL angegebene Unix-Socket-Verzeichnis. pgBackRest sucht automatisch am üblichen Speicherort des Betriebssystems. Diese Einstellung ist daher normalerweise nur erforderlich, wenn das Socket-Verzeichnis ausdrücklich über unix_socket_directories in postgresql.conf geändert wurde.

example: --pg1-socket-path=/var/run/postgresql

Veralteter Name: db-socket-path

Option für den PostgreSQL-Datenbankbenutzer (--pg-user)

PostgreSQL-Datenbankbenutzer.

Datenbankbenutzername für Verbindungen zu PostgreSQL. Ohne Angabe verbindet sich pgBackRest mit dem lokalen Betriebssystembenutzer oder mit PGUSER.

example: --pg1-user=backupuser

4.17 - Startbefehl (start)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls start.

Wurden pgBackRest-Prozesse zuvor mit dem Befehl stop gestoppt, kann ihre Ausführung mit dem Befehl start wieder zugelassen werden. Dabei werden keine pgBackRest-Prozesse unmittelbar gestartet; sie dürfen lediglich wieder ausgeführt werden. Weitere Informationen und Beispiele finden Sie unter Starten und Stoppen .

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

4.18 - Stoppbefehl (stop)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls stop.

Verhindert die Ausführung neuer pgBackRest-Prozesse. Standardmäßig dürfen laufende Prozesse erfolgreich abgeschlossen werden. Mit der Option --force werden laufende Prozesse beendet.

pgBackRest-Prozesse geben einen Fehler zurück, wenn sie nach Abschluss des Stoppbefehls ausgeführt werden. Weitere Informationen und Beispiele finden Sie unter Starten und Stoppen .

Befehlsoptionen

Option zum Erzwingen (--force)

Das Stoppen aller pgBackRest-Prozesse erzwingen.

Diese Option sendet TERM-Signale an alle laufenden pgBackRest-Prozesse, um ein geordnetes, aber sofortiges Herunterfahren auszulösen. Sie beendet auch Prozesse, die auf einem anderen System gestartet wurden, deren entfernte Teilprozesse aber auf dem aktuellen System laufen. Wurde beispielsweise ein Backup auf dem Backup-Server gestartet, beendet stop --force auf dem Datenbankserver auch den Backup-Prozess auf dem Backup-Server.

default: n
example: --force

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: --lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

4.19 - Validierungsbefehl (verify)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls verify.

Die Validierung stellt fest, ob Backups und Archive in einem Repository gültig sind.

Befehlsoptionen

Ausgabeoption (--output)

Ausgabetyp.

Die folgenden Ausgabetypen werden unterstützt:

  • none - Keine Ausgabe zur Validierung.
  • text - Validierungsinformationen an stdout ausgeben.
default: none
example: --output=text

Option zur Auswahl des Backup-Satzes (--set)

Zu validierender Backup-Satz.

Alle Datenbank- und Archivdateien validieren, die zum angegebenen Backup-Satz gehören.

example: --set=20150131-153358F_20150131-153401I

Option für ausführliche Ausgabe (--verbose)

Ausführliche Ausgabe.

Die ausführliche Ausgabe ist standardmäßig auf false gesetzt. Es wird eine knappe Antwort mit wichtigen Informationen zu Fehlern im Repository ausgegeben. Mit true erscheinen zusätzliche Informationen darüber, was erfolgreich validiert wurde.

default: n
example: --verbose

Allgemeine Optionen

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: --allow-root

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: --buffer-size=2MiB

Option für den pgBackRest-Befehl (--cmd)

pgBackRest-Befehl.

pgBackRest kann eine Befehlszeichenfolge erzeugen, etwa wenn der Befehl restore die Einstellung restore_command erzeugt. Dafür wird der Befehl verwendet, mit dem der pgBackRest-Prozess gestartet wurde, sofern nicht die Option cmd angegeben ist.

ACHTUNG:

Das Einbetten des pgBackRest-Befehls in einen Wrapper kann unvorhersehbares Verhalten verursachen und wird nicht empfohlen.

default: [path of executed pgbackrest binary]
example: --cmd=/var/lib/pgsql/bin/pgbackrest_wrapper.sh

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: --cmd-ssh=/usr/bin/ssh

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: --compress-level-network=1

Option für die Konfigurationsdatei (--config)

pgBackRest-Konfigurationsdatei.

Mit dieser Option eine andere als die standardmäßige Konfigurationsdatei angeben.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --config=/conf/pgbackrest/pgbackrest.conf

Option für den Pfad zusätzlicher Konfigurationsdateien (--config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien.

Konfigurationsdateien mit der Endung .conf am angegebenen Speicherort werden mit der pgBackRest-Konfigurationsdatei zu einer einzigen Konfigurationsdatei zusammengefügt.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad (--config-path)

Basispfad der pgBackRest-Konfigurationsdateien.

Diese Einstellung überschreibt den standardmäßigen Basispfad der Optionen --config und --config-include-path, sofern diese nicht ausdrücklich in der Befehlszeile gesetzt werden.

Wird beispielsweise nur --config-path=/conf/pgbackrest angegeben, erhält --config den Standardwert /conf/pgbackrest/pgbackrest.conf und --config-include-path den Standardwert /conf/pgbackrest/conf.d.

default: CFGOPTDEF_CONFIG_PATH
example: --config-path=/conf/pgbackrest

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: --io-timeout=120

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: --no-neutral-umask

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: --priority=19

Option für die maximale Prozessanzahl (--process-max)

Maximale Anzahl der Prozesse für Komprimierung und Übertragung.

Jeder Prozess führt Komprimierung und Übertragung aus, um den Befehl zu beschleunigen. process-max jedoch nicht so hoch setzen, dass die Datenbankleistung beeinträchtigt wird.

default: 1
allowed: [1, 999]
example: --process-max=4

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS: Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: --protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: --no-sck-keep-alive

Option für die Stanza (--stanza)

Definiert die Stanza.

Eine Stanza ist die Konfiguration eines PostgreSQL-Datenbankclusters. Sie legt unter anderem dessen Speicherort, das Backup-Verfahren und die Archivierungsoptionen fest. Die meisten Datenbankserver haben nur einen PostgreSQL-Datenbankcluster und daher nur eine Stanza. Backup-Server haben dagegen für jeden zu sichernden Datenbankcluster eine Stanza.

Es liegt nahe, die Stanza nach dem Primärcluster zu benennen. Ein besserer Name beschreibt jedoch die im Cluster enthaltenen Datenbanken. Da der Stanza-Name für den Primärserver und alle Replikate verwendet wird, sollte er die tatsächliche Funktion des Clusters beschreiben, etwa app oder dw, statt den lokalen Clusternamen wie main oder prod zu übernehmen.

example: --stanza=main

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: --tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: --tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: --tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS: TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: --tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: --log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: --log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: --log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: --log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: --log-subprocess

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: --no-log-timestamp

Optionen für Maintainer

Option zum Erzwingen der PostgreSQL-Version (--pg-version-force)

PostgreSQL-Version erzwingen.

Verwendet die angegebene PostgreSQL-Version statt der Version, die automatisch aus pg_control oder WAL-Headern ermittelt wird. Dies ist hauptsächlich für PostgreSQL-Forks oder Entwicklungsversionen hilfreich, deren Werte von denen der veröffentlichten Version abweichen. Die von PostgreSQL über server_version_num gemeldete Version muss mit der erzwungenen Version übereinstimmen.

WARNUNG:

Diese Option mit Vorsicht verwenden: pg_control und WAL-Header werden weiterhin im erwarteten Format der angegebenen Version gelesen, also im Format der offiziellen Open-Source-Version von PostgreSQL. Ändert der Fork oder die Entwicklungsversion das Format von Feldern, auf die pgBackRest angewiesen ist, führt dies zu unerwartetem Verhalten. Im Allgemeinen funktioniert diese Option nur dann wie erwartet, wenn der Fork alle eigenen Strukturfelder nach den standardmäßigen PostgreSQL-Feldern hinzufügt.

example: --pg-version-force=15

Repository-Optionen

Option zur Auswahl des Repositorys (--repo)

Repository festlegen.

Legt das Repository fest, auf das ein Befehl wirken soll.

Damit kann beispielsweise eine Wiederherstellung aus einem bestimmten Repository durchgeführt werden, anstatt pgBackRest die Auswahl zu überlassen.

allowed: [1, 256]
example: --repo=1

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: --repo1-azure-container=pg-backup

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: --repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: --repo1-azure-uri-style=path

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: --repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: --repo1-gcs-endpoint=localhost

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: --repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: --repo1-gcs-user-project=my-project

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: --repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: --repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: --repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: --repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: --repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: --repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: --repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: --repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS: Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: --repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: --repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: --repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: --repo1-path=/backup/db/backrest

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: --repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: --repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: --repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: --repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: --repo1-s3-process-cmd=/usr/local/bin/get-credentials --repo1-s3-process-cmd=--role --repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: --repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: --no-repo1-s3-requester-pays

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: --repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: --repo1-s3-service=s3-outposts

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: --repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: --repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: --repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: --repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: --repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: --repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: --repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: --repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: --repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: --repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: --repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: --repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: --repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: --repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: --repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: --repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: --repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: --no-repo1-storage-verify-tls

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für den Zielzeitpunkt des Repositorys (--repo-target-time)

Zielzeitpunkt für das Repository.

Der Zielzeitpunkt legt fest, welchen Stand des Repositorys Befehle auf versioniertem Speicher lesen. So lässt sich das Repository zu einem früheren Zeitpunkt lesen, um Daten wiederherzustellen, die versehentlich durch Benutzer oder durch Schadsoftware gelöscht oder beschädigt wurden.

S3, GCS und Azure unterstützen versionierten Speicher, aktivieren ihn aber im Allgemeinen nicht standardmäßig. Neben der Versionierung kann es sinnvoll sein, bei S3 die Objektsperre und bei GCS oder Azure das vorläufige Löschen zu aktivieren.

Wenn repo-target-time angegeben wird, muss auch die Option repo angegeben werden. Wahrscheinlich unterstützen nicht alle Repository-Typen die Versionierung. Im Allgemeinen ist es sinnvoll, für die Wiederherstellung ein einzelnes Repository auszuwählen.

Beim Vergleich werden Speicherzeitstempel berücksichtigt, die <= dem angegebenen Zeitstempel sind. Enthaltene Millisekunden werden abgeschnitten.

example: --repo-target-time=2024-08-08 12:12:12+00

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: --repo1-type=cifs

4.20 - Versionsbefehl (version)

Referenz zu den Optionen und zum Verhalten des pgBackRest-Befehls version.

Zeigt die installierte pgBackRest-Version an.

Befehlsoptionen

Ausgabeoption (--output)

Ausgabetyp.

Die folgenden Ausgabetypen werden unterstützt:

  • text - Die installierte pgBackRest-Version als Text anzeigen.
  • num - Die installierte pgBackRest-Version als Ganzzahl anzeigen.
default: text
example: --output=num

5 - Referenz zur Konfiguration

Vollständige pgBackRest-Konfigurationsreferenz mit allen Einstellungen, einschließlich Optionen für Archivierung, Backups, Repositorys und Cloud-Speicher.

Einführung

pgBackRest lässt sich vollständig über Befehlszeilenparameter steuern. Für komplexe Installationen oder viele Optionen ist jedoch eine Konfigurationsdatei praktischer. Ihr standardmäßiger Pfad ist /etc/pgbackrest/pgbackrest.conf. Existiert dort keine Datei, wird der frühere Standardpfad /etc/pgbackrest.conf geprüft.

Die folgenden Optionentypen werden verwendet:

Zeichenfolge: Text, häufig eine Kennung, ein Passwort oder Ähnliches.

Beispiel für die Befehlszeile: --stanza=demo
Beispiel für die Konfigurationsdatei: repo1-cipher-pass=zWaf6XtpjIVZC5444yXB...

Pfad: Identifiziert einen Speicherort in einer Verzeichnisstruktur eindeutig. Pfade müssen mit / beginnen. Doppeltes // ist nicht erlaubt, und ein abschließendes / wird nicht erwartet.

Beispiel für die Befehlszeile: --repo1-path=/var/lib/pgbackrest
Beispiel für die Konfigurationsdatei: repo1-path=/var/lib/pgbackrest

Boolescher Wert: Aktiviert oder deaktiviert die Option. Nur y/n sind als Argumentwerte zulässig.

Beispiele für die Befehlszeile: --start-fast, --no-start-fast, --start-fast=y, --start-fast=n
Beispiele für die Konfigurationsdatei: start-fast=y, start-fast=n

Ganzzahl: Für Ports, Aufbewahrungsanzahlen, Wiederholungsversuche, die Anzahl zulässiger paralleler Prozesse und Ähnliches.

Beispiel für die Befehlszeile: --compress-level=3
Beispiel für die Konfigurationsdatei: pg1-port=5432

Größe: Für Puffergrößen, Speicherplatzbedarf und Ähnliches. Größen können in Byte (Standard) oder in KiB, MiB, GiB, TiB oder PiB angegeben werden; der Multiplikator ist jeweils eine Potenz von 1024. Beispielsweise kann statt 5368709120 der Wert 5GiB (oder 5GB, 5g) verwendet werden, wobei Groß- und Kleinschreibung keine Rolle spielen. Bruchwerte wie 2.5GiB sind nicht zulässig; stattdessen 2560MiB verwenden.

Beispiel für die Befehlszeile: --archive-get-queue-max=1GiB
Beispiel für die Konfigurationsdatei: buffer-size=2MiB

Zeit: Zeit in Sekunden.

Beispiel für die Befehlszeile: --io-timeout=90
Beispiel für die Konfigurationsdatei: db-timeout=600

Liste: Die Option kann mehrfach angegeben werden.

Beispiel für die Befehlszeile: --db-exclude=db1 --db-exclude=db2 --db-exclude=db5

Beispiel für die Konfigurationsdatei, jeweils in einer eigenen Zeile:

db-exclude=db1
db-exclude=db2
db-exclude=db5

Schlüssel/Wert: Die Option kann mehrfach in der Form key=value angegeben werden.

Beispiel für die Befehlszeile: --tablespace-map=ts_01=/db/ts_01 --tablespace-map=ts_02=/db/ts_02

Beispiel für die Konfigurationsdatei, jeweils in einer eigenen Zeile:

tablespace-map=ts_01=/db/ts_01
tablespace-map=ts_02=/db/ts_02

Archivierungsoptionen

Der Abschnitt archive definiert Optionen für die Befehle archive-push und archive-get.

Option für asynchrone Archivierung (--archive-async)

WAL-Segmente asynchron übertragen und abrufen.

Aktiviert den asynchronen Betrieb für die Befehle archive-push und archive-get.

Der asynchrone Betrieb ist effizienter, da er Verbindungen wiederverwenden und parallele Verarbeitung nutzen kann. Weitere Informationen bieten die Optionen spool-path, archive-get-queue-max und archive-push-queue-max.

default: n
example: archive-async=y

Option für die maximale Größe der Abrufwarteschlange (--archive-get-queue-max)

Maximale Größe der archive-get-Warteschlange von pgBackRest.

Legt die maximale Größe der archive-get-Warteschlange fest, wenn archive-async aktiviert ist. Die Warteschlange liegt im spool-path und beschleunigt die Bereitstellung von WAL für PostgreSQL.

default: 128MiB
allowed: [0B, 4PiB]
example: archive-get-queue-max=1GiB

Option zum erneuten Abruf fehlender WAL-Segmente (--archive-missing-retry)

Abruf fehlender WAL-Segmente erneut versuchen

Ein WAL-Segment erneut abrufen, das der Befehl archive-get im asynchronen Modus zuvor als fehlend gemeldet hat. Dies verhindert, dass Meldungen einer früheren Wiederherstellung aus dem Spool-Pfad verwendet werden und möglicherweise die Recovery scheitern lassen, wenn noch kein konsistenter Zustand erreicht wurde.

Bei deaktivierter Option kann PostgreSQL zuverlässiger erkennen, wann das Ende des WAL im Archiv erreicht ist, und dann zum Streaming vom Primärserver wechseln. Bei aktivierten Wiederholungsversuchen führt ein stetiger Strom neu archivierter WAL-Segmente dazu, dass PostgreSQL weiterhin WAL aus dem Archiv abruft, statt zum Streaming zu wechseln.

Wird diese Option deaktiviert, muss sichergestellt werden, dass der Spool-Pfad der Stanza leer ist. Der Befehl restore erledigt dies automatisch, wenn der Spool-Pfad zum Zeitpunkt der Wiederherstellung konfiguriert ist. Andernfalls muss der Benutzer selbst dafür sorgen, dass der Spool-Pfad leer ist.

default: y
example: archive-missing-retry=n

Option für die Datenmenge pro Archivierungslauf (--archive-push-batch-size)

Maximale WAL-Menge, die pro asynchronem Lauf übertragen wird.

Im asynchronen Modus überträgt der Prozess archive-push alle bereitstehenden WAL-Segmente in einem Lauf. Da archive-push-queue-max nur zu Beginn jedes Laufs geprüft wird, kann die Warteschlange bei einem Lauf mit sehr vielen Segmenten weit über den Grenzwert hinaus wachsen, bevor sie erneut geprüft wird.

Diese Option begrenzt die pro Lauf verarbeitete WAL-Menge. Der Prozess beendet sich dadurch und wird beim nächsten archive-push neu gestartet, wobei die Warteschlange erneut geprüft wird. Kleinere Werte führen zu häufigeren Prüfungen, erfordern aber auch häufigere Starts des asynchronen Prozesses. Der Wert wird auf eine ganze Anzahl von WAL-Segmenten abgerundet; mindestens ein Segment wird jedoch immer verarbeitet.

default: 16GiB
allowed: [1MiB, 4PiB]
example: archive-push-batch-size=1GiB

Option für die maximale Größe der Archivierungswarteschlange (--archive-push-queue-max)

Maximale Größe der PostgreSQL-Archivierungswarteschlange.

Nach Erreichen des Grenzwerts geschieht Folgendes:

  • pgBackRest meldet PostgreSQL, dass das WAL erfolgreich archiviert wurde, und wird es dann VERWERFEN.
  • Eine Warnung wird in das PostgreSQL-Protokoll geschrieben.

Dadurch wird der Archivprotokollstrom unterbrochen, und PITR ist über diesen Punkt hinaus nicht mehr möglich. Ein neues Backup ist erforderlich, um die vollständige Wiederherstellbarkeit erneut herzustellen.

Im asynchronen Modus wird die gesamte Warteschlange verworfen. So wird verhindert, dass kurzzeitig wieder einzelne WAL-Segmente archiviert werden, bevor die Grenze erneut überschritten wird.

Im asynchronen Modus wird diese Grenze nur zu Beginn jedes archive-push-Laufs geprüft. Daher kann die Warteschlange innerhalb eines Laufs darüber hinaus wachsen. archive-push-batch-size verringern, um die Warteschlange häufiger zu prüfen.

Diese Funktion soll verhindern, dass das Volume mit den Protokolldateien voll wird, da PostgreSQL dann vollständig zum Stillstand kommt. Es ist besser, das Backup zu verlieren, als PostgreSQL ausfallen zu lassen.

allowed: [0B, 4PiB]
example: archive-push-queue-max=1TiB

Veralteter Name: archive-queue-max

Option für das Archivierungszeitlimit (--archive-timeout)

Archivierungszeitlimit.

Maximale Wartezeit in Sekunden festlegen, bis ein einzelnes WAL-Segment das Archiv-Repository von pgBackRest erreicht. Dieses Zeitlimit gilt für die Befehle check und backup, wenn sie auf die Archivierung der WAL-Segmente warten, die für ein konsistentes Backup erforderlich sind.

default: 1m
allowed: [100ms, 1d]
example: archive-timeout=30

Backup-Optionen

Der Abschnitt backup definiert Einstellungen für Backups.

Option für Backup-Anmerkungen (--annotation)

Das Backup mit benutzerdefinierten Schlüssel/Wert-Paaren versehen.

Benutzer können dem Backup informative Schlüssel/Wert-Paare hinzufügen. Diese Option kann mehrfach verwendet werden, um mehrere Anmerkungen hinzuzufügen.

Anmerkungen erscheinen in der Textausgabe des Befehls info, wenn mit --set ein Backup angegeben wird. In der JSON-Ausgabe erscheinen sie immer.

example: annotation=source="Sunday backup for website database"

Option zur Archivprüfung (--archive-check)

Vor Abschluss des Backups prüfen, ob sich die WAL-Segmente im Archiv befinden.

Prüft, ob alle für ein konsistentes Backup erforderlichen WAL-Segmente im WAL-Archiv vorhanden sind. Es empfiehlt sich, die Standardeinstellung beizubehalten, sofern keine andere Archivierungsmethode verwendet wird.

Diese Option muss aktiviert sein, wenn archive-copy aktiviert ist.

default: y
example: archive-check=n

Option zum Kopieren des Archivs (--archive-copy)

Für die Konsistenz benötigte WAL-Segmente in das Backup kopieren.

Diese etwas übervorsichtige Option schützt vor beschädigten Daten im WAL-Segmentarchiv, indem sie die für die Konsistenz erforderlichen WAL-Segmente direkt im Backup speichert. Die WAL-Segmente bleiben zusätzlich im Archiv gespeichert, daher benötigt diese Option weiteren Speicherplatz.

Bei Verwendung dieser Option sollten die Befehle archive-push und backup möglichst denselben Wert für compress-type verwenden (z. B. lz4). Andernfalls müssen die WAL-Segmente mit dem für das Backup verwendeten compress-type neu komprimiert werden. Je nach der während des Backups erzeugten WAL-Menge kann dies recht aufwendig sein.

Bei der Wiederherstellung liegen die WAL-Segmente in pg_xlog/pg_wal. PostgreSQL bevorzugt diese Segmente gegenüber einem Aufruf von restore_command.

Die Option archive-check muss aktiviert sein, wenn archive-copy aktiviert ist.

default: n
example: archive-copy=y

Option zur Prüfung des Archivierungsmodus (--archive-mode-check)

Die PostgreSQL-Einstellung archive_mode prüfen.

Diese standardmäßig aktivierte Option verbietet die PostgreSQL-Einstellung archive_mode=always.

Von einem Standby-Server übertragene WAL-Segmente können logisch mit denen des Primärservers übereinstimmen, aber andere Prüfsummen aufweisen. Zur Vermeidung von Konflikten wird empfohlen, die Archivierung aus mehreren Quellen zu unterbinden.

ACHTUNG:

Bei deaktivierter Option muss unbedingt sichergestellt werden, dass nur ein Archivierer mit dem Befehl archive-push in das Repository schreibt.

default: y
example: archive-mode-check=n

Option für Backups vom Standby (--backup-standby)

Backup vom Standby-Cluster erstellen.

Backups vom Standby aktivieren, um die Last auf dem Primärcluster zu verringern. Für diese Option müssen sowohl der Primär- als auch der Standby-Host konfiguriert sein.

Die folgenden Modi werden unterstützt:

  • y - Für das Backup ist ein Standby erforderlich.
  • prefer - Backup vom Standby erstellen, falls verfügbar, andernfalls vom Primärserver.
  • n - Backup ausschließlich vom Primärserver erstellen.
default: n
example: backup-standby=y

Option für Seitenprüfsummen (--checksum-page)

Prüfsummen der Datenseiten validieren.

Weist pgBackRest an, beim Backup eines Clusters die Prüfsummen aller Datenseiten zu validieren. Diese Option wird automatisch aktiviert, wenn Datenseitenprüfsummen im Cluster aktiviert sind.

Fehler bei der Prüfsummenvalidierung brechen das Backup nicht ab. Stattdessen werden Warnungen ins Protokoll geschrieben und bei Standardeinstellungen auch auf der Konsole ausgegeben. Die Liste der ungültigen Seiten wird im Backup-Manifest gespeichert.

example: checksum-page=n

Option zum Ausschließen von Pfaden und Dateien (--exclude)

Pfade und Dateien vom Backup ausschließen.

Alle Ausschlüsse beziehen sich auf $PGDATA. Endet der Ausschluss mit /, werden nur Dateien im angegebenen Verzeichnis ausgeschlossen. Beispielsweise schließt --exclude=junk/ alle Dateien im Verzeichnis $PGDATA/junk aus, nimmt aber das Verzeichnis selbst auf. Endet der Ausschluss nicht mit /, kann eine Datei entweder genau dem Ausschluss entsprechen oder dem Ausschluss mit angehängtem /. So schließt --exclude=junk das Verzeichnis $PGDATA/junk und alle darin enthaltenen Dateien aus.

Diese Funktion mit Vorsicht verwenden: Wichtige Inhalte lassen sich leicht versehentlich ausschließen, wodurch das Backup inkonsistent wird. Testen Sie unbedingt Ihre Wiederherstellungen!

Alle ausgeschlossenen Dateien werden zusammen mit der Ausschlussregel auf der Stufe info protokolliert. Prüfen Sie unbedingt die Liste, damit keine Dateien unerwartet ausgeschlossen werden.

HINWEIS:

Ausschlüsse werden bei Delta-Wiederherstellungen nicht berücksichtigt. Alle beim Backup ausgeschlossenen Dateien und Verzeichnisse werden bei einer Delta-Wiederherstellung entfernt.

Diese Option sollte nicht verwendet werden, um PostgreSQL-Protokolle vom Backup auszuschließen. Mit der PostgreSQL-Einstellung log_directory lassen sich Protokolle außerhalb des Verzeichnisses PGDATA ablegen. Dies hat den Vorteil, dass sie nach einer Wiederherstellung erhalten bleiben können.

In der Befehlszeile oder einer Konfigurationsdatei können mehrere Ausschlüsse angegeben werden.

example: exclude=junk/

Option zur automatischen Bereinigung (--expire-auto)

Nach einem erfolgreichen Backup automatisch den Befehl expire ausführen.

Diese Einstellung ist standardmäßig aktiviert. Beim Deaktivieren ist Vorsicht geboten: Alle Backups und Archive bleiben dann unbegrenzt erhalten, wodurch der Speicherplatz im Repository ausgehen kann. Um dies zu verhindern, muss der Befehl expire regelmäßig ausgeführt werden.

Wird expire nach einem erfolgreichen Backup automatisch ausgeführt, verwendet es die Konfiguration des Befehls backup. Optionen, die ausschließlich in einem Abschnitt für den Befehl expire stehen, etwa [global:expire], werden daher nicht angewendet. Um eine eigene Konfiguration für expire anzuwenden, diese Option deaktivieren und den Befehl expire separat ausführen.

default: y
example: expire-auto=y

Option für den Schwellenwert zum Speichern des Manifests (--manifest-save-threshold)

Schwellenwert zum Speichern des Manifests während des Backups.

Legt fest, wie oft das Manifest während eines Backups gespeichert wird. Das Speichern ist wichtig, da das Manifest Prüfsummen enthält und eine effiziente Wiederaufnahme ermöglicht. Der tatsächlich verwendete Schwellenwert ist der größere Wert aus 1% der Backup-Größe und manifest-save-threshold.

default: 1GiB
allowed: [1B, 1TiB]
example: manifest-save-threshold=8GiB

Option zur Wiederaufnahme (--resume)

Die Wiederaufnahme eines fehlgeschlagenen Backups erlauben.

Legt fest, ob die Wiederaufnahme aktiviert ist. Sie kann die benötigte Zeit erheblich verkürzen, wenn zuvor ein Backup desselben Typs fehlgeschlagen ist. Sie erhöht jedoch die Komplexität. In Umgebungen, die diese Funktion nicht benötigen, kann es daher sinnvoll sein, sie zu deaktivieren.

default: y
example: resume=n

Option für einen schnellen Start (--start-fast)

Einen Checkpoint erzwingen, um das Backup schnell zu starten.

Erzwingt einen Checkpoint, indem dem Parameter fast der Backup-Startfunktion der Wert y übergeben wird, sodass das Backup sofort beginnt. Andernfalls beginnt es nach dem nächsten regulären Checkpoint.

default: n
example: start-fast=y

Allgemeine Optionen

Der Abschnitt general definiert Optionen, die mehrere Befehle gemeinsam verwenden.

Option zur Ausführung als root (--allow-root)

Die Ausführung des Befehls als Benutzer root erlauben.

Standardmäßig darf nur der Befehl restore als Benutzer root ausgeführt werden, da er die Dateieigentümer sorgfältig verwaltet. Bei anderen Befehlen besteht das Risiko, dass Dateien entstehen, die root gehören, etwa im Repository. Diese sind für den PostgreSQL-Benutzer nicht zugänglich, sodass spätere Befehle fehlschlagen.

Diese Option aktivieren, um einen Befehl dennoch als root auszuführen. Es ist jedoch deutlich besser, pgBackRest als den Benutzer auszuführen, dem das Repository und der PostgreSQL-Cluster gehören.

default: n
example: allow-root=y

Option für die Puffergröße (--buffer-size)

Puffergröße für I/O-Operationen.

Puffergröße für Kopier-, Komprimierungs-, Verschlüsselungs- und andere Operationen. Die Anzahl der verwendeten Puffer hängt von den Optionen ab. Jede Operation kann zusätzlichen Speicher benötigen; beispielsweise kann die Komprimierung mit gz weitere 256KiB Speicher beanspruchen.

Zulässige Werte sind 16KiB, 32KiB, 64KiB, 128KiB, 256KiB, 512KiB, 1MiB, 2MiB, 4MiB, 8MiB und 16MiB.

default: 1MiB
example: buffer-size=2MiB

Option für den pgBackRest-Befehl (--cmd)

pgBackRest-Befehl.

pgBackRest kann eine Befehlszeichenfolge erzeugen, etwa wenn der Befehl restore die Einstellung restore_command erzeugt. Dafür wird der Befehl verwendet, mit dem der pgBackRest-Prozess gestartet wurde, sofern nicht die Option cmd angegeben ist.

ACHTUNG:

Das Einbetten des pgBackRest-Befehls in einen Wrapper kann unvorhersehbares Verhalten verursachen und wird nicht empfohlen.

default: [path of executed pgbackrest binary]
example: cmd=/var/lib/pgsql/bin/pgbackrest_wrapper.sh

Option für den SSH-Client-Befehl (--cmd-ssh)

SSH-Client-Befehl.

Einen bestimmten SSH-Client-Befehl verwenden, wenn eine Alternative gewünscht wird oder der Befehl ssh nicht in $PATH liegt.

default: ssh
example: cmd-ssh=/usr/bin/ssh

Option zur Komprimierung (--compress)

Dateikomprimierung verwenden.

Die Backup-Dateien sind mit Komprimierungswerkzeugen für die Befehlszeile kompatibel.

Diese Option ist inzwischen veraltet. Stattdessen sollte compress-type verwendet werden.

default: y
example: compress=n

Option für die Komprimierungsstufe (--compress-level)

Komprimierungsstufe für Dateien.

Legt die Stufe für die Dateikomprimierung fest, wenn compress-type nicht none ist oder compress=y (veraltet) gilt.

default (depending on compress-type):
    bz2 - 9
    gz - 6
    lz4 - 1
    zst - 3

allow range (depending on compress-type):
    bz2 - [1, 9]
    gz - [-1, 9]
    lz4 - [-5, 12]
    zst - [-7, 22]

example: compress-level=9

Option für die Netzwerkkomprimierungsstufe (--compress-level-network)

Komprimierungsstufe für die Netzwerkübertragung.

Legt die Komprimierungsstufe für die Netzwerkübertragung fest, wenn compress-type=none gilt und der Befehl nicht auf demselben Host wie das Repository ausgeführt wird. Die Komprimierung verringert den Netzwerkverkehr. Wenn compress-type nicht none ist, wird compress-level-network ignoriert und stattdessen compress-level verwendet, damit die Datei nur einmal komprimiert wird.

default: 1
allowed: [-5, 12]
example: compress-level-network=1

Option für das Komprimierungsverfahren (--compress-type)

Komprimierungsverfahren für Dateien.

Die folgenden Komprimierungsverfahren werden unterstützt:

  • none - Keine Komprimierung
  • bz2 - bzip2-Komprimierungsformat
  • gz - gzip-Komprimierungsformat
  • lz4 - lz4-Komprimierungsformat (nicht auf allen Plattformen verfügbar)
  • zst - Zstandard-Komprimierungsformat (nicht auf allen Plattformen verfügbar)
default: gz
example: compress-type=none

Option für das Datenbankzeitlimit (--db-timeout)

Zeitlimit für Datenbankabfragen.

Legt das Zeitlimit für Datenbankabfragen in Sekunden fest. Dazu gehören auch die Funktionen zum Starten und Stoppen des Backups, die jeweils viel Zeit benötigen können. Daher sollte das Zeitlimit hoch bleiben, sofern nicht bekannt ist, dass diese Funktionen schnell zurückkehren, etwa wenn start-fast=y gesetzt ist und bekannt ist, dass der Datenbankcluster während des Backups nur wenige WAL-Segmente erzeugt.

HINWEIS:

Der Wert von db-timeout muss kleiner sein als der von protocol-timeout.

default: 30m
allowed: [100ms, 7d]
example: db-timeout=600

Delta-Option (--delta)

Wiederherstellung oder Backup anhand von Prüfsummen durchführen.

Bei einer Wiederherstellung wird standardmäßig erwartet, dass die PostgreSQL-Daten- und Tablespace-Verzeichnisse vorhanden, aber leer sind. Diese Option führt eine Delta-Wiederherstellung anhand von Prüfsummen durch.

Bei einem Backup verwendet diese Option Prüfsummen anstelle von Zeitstempeln, um zu entscheiden, ob Dateien kopiert werden.

default: n
example: delta=y

Option für das I/O-Zeitlimit (--io-timeout)

I/O-Zeitlimit.

Zeitlimit in Sekunden für Verbindungen sowie Lese- und Schreiboperationen.

Die gesamte Lese- oder Schreiboperation muss nicht innerhalb dieses Zeitlimits abgeschlossen sein, aber es muss irgendein Fortschritt erzielt werden, selbst wenn es nur ein einziges Byte ist.

default: 1m
allowed: [100ms, 1h]
example: io-timeout=120

Option für den Sperrdateipfad (--lock-path)

Pfad zum Speichern der Sperrdateien.

In diesem Pfad erstellt pgBackRest Sperrdateien, um die gleichzeitige Ausführung miteinander in Konflikt stehender Operationen zu verhindern.

default: /tmp/pgbackrest
example: lock-path=/backup/db/lock

Option für eine neutrale umask (--neutral-umask)

Eine neutrale umask verwenden.

Setzt die umask auf 0000, damit die Zugriffsrechte im Repository sinnvoll gesetzt werden. Standardmäßig erhalten Verzeichnisse den Modus 0750 und Dateien den Modus 0640.

Um stattdessen die umask des ausführenden Benutzers zu verwenden, neutral-umask=n in der Konfigurationsdatei oder --no-neutral-umask in der Befehlszeile angeben.

default: y
example: neutral-umask=n

Option für die Prozesspriorität (--priority)

Prozesspriorität festlegen.

Legt fest, welche Priorität (also welcher nice-Wert) dem Prozess vom Kernel-Scheduler zugewiesen wird. Positive Werte verringern die Priorität, negative Werte erhöhen sie. In den meisten Fällen dürfen Prozesse ihre Priorität nicht erhöhen.

allowed: [-20, 19]
example: priority=19

Option für die maximale Prozessanzahl (--process-max)

Maximale Anzahl der Prozesse für Komprimierung und Übertragung.

Jeder Prozess führt Komprimierung und Übertragung aus, um den Befehl zu beschleunigen. process-max jedoch nicht so hoch setzen, dass die Datenbankleistung beeinträchtigt wird.

default: 1
allowed: [1, 999]
example: process-max=4

Option für das Protokollzeitlimit (--protocol-timeout)

Protokollzeitlimit.

Legt in Sekunden fest, wie lange der lokale oder entfernte Prozess auf eine neue Nachricht auf der Protokollebene wartet. Dies verhindert, dass Prozesse unbegrenzt auf eine Nachricht warten.

HINWEIS:

Der Wert von protocol-timeout muss größer sein als der von db-timeout.

default: 31m
allowed: [100ms, 7d]
example: protocol-timeout=630

Option für Keep-alive (--sck-keep-alive)

Keep-alive aktivieren.

Aktiviert Keep-alive-Nachrichten auf Socket-Verbindungen.

default: y
example: sck-keep-alive=n

Option für den Spool-Pfad (--spool-path)

Pfad zum Speichern vorübergehend benötigter Daten.

In diesem Pfad werden Daten für die asynchronen Befehle archive-push und archive-get gespeichert.

Der asynchrone Befehl archive-push schreibt Bestätigungen in den Spool-Pfad, wenn WAL erfolgreich im Archiv gespeichert wurde, und Fehlermeldungen bei einem Fehlschlag. So kann der Vordergrundprozess PostgreSQL schnell benachrichtigen. Die Bestätigungsdateien sind sehr klein: bei Erfolg leer, bei Fehlern wenige hundert Byte groß.

Der asynchrone Befehl archive-get hält WAL im Spool-Pfad bereit, damit es auf Anfrage von PostgreSQL sehr schnell geliefert werden kann. Das Verschieben der Dateien zu PostgreSQL ist am effizientesten, wenn der Spool-Pfad auf demselben Dateisystem wie pg_xlog/pg_wal liegt. Es wird jedoch davon abgeraten, den Spool-Pfad innerhalb des Verzeichnisses pg_xlog/pg_wal anzulegen, da dies bei PostgreSQL-Werkzeugen wie pg_rewind Probleme verursachen kann.

Die Daten im Spool-Pfad sind nicht rein temporär, da sie einen Neustart überdauern können und sollten. Ihr Verlust ist jedoch kein Problem: Für archive-push prüft pgBackRest einfach jedes WAL-Segment erneut auf sichere Archivierung; für archive-get baut es die Warteschlange neu auf.

Der Spool-Pfad ist für ein lokales POSIX-kompatibles Dateisystem vorgesehen, nicht für ein entferntes Dateisystem wie NFS oder CIFS.

default: /var/spool/pgbackrest
example: spool-path=/backup/db/spool

Option für die Keep-alive-Anzahl (--tcp-keep-alive-count)

Anzahl der Keep-alive-Nachrichten.

Legt fest, wie viele TCP-Keep-alive-Nachrichten verloren gehen dürfen, bevor die Verbindung als unterbrochen gilt.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPCNT unterstützen.

allowed: [1, 32]
example: tcp-keep-alive-count=3

Option für die Keep-alive-Leerlaufzeit (--tcp-keep-alive-idle)

Keep-alive-Leerlaufzeit.

Legt die Zeit ohne Netzwerkaktivität in Sekunden fest, nach der das Betriebssystem eine TCP-Keep-alive-Nachricht senden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPIDLE unterstützen.

allowed: [1, 3600]
example: tcp-keep-alive-idle=60

Option für das Keep-alive-Intervall (--tcp-keep-alive-interval)

Keep-alive-Intervall.

Legt die Zeit in Sekunden fest, nach der eine nicht bestätigte TCP-Keep-alive-Nachricht erneut gesendet werden sollte.

Diese Option ist auf Systemen verfügbar, die die Socket-Option TCP_KEEPINTVL unterstützen.

allowed: [1, 900]
example: tcp-keep-alive-interval=30

Option für TLSv1.2-Cipher-Suites (--tls-cipher-12)

Zulässige TLSv1.2-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS:

TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Das Beispiel ist eine sinnvolle Wahl, sofern keine besonderen Sicherheitsanforderungen bestehen. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: tls-cipher-12=HIGH:MEDIUM:+3DES:!aNULL

Option für TLSv1.3-Cipher-Suites (--tls-cipher-13)

Zulässige TLSv1.3-Cipher-Suites.

Alle TLS-Verbindungen zwischen pgBackRest-Client und -Server sind verschlüsselt. Standardmäßig sind auch Verbindungen zu Objektspeichern wie S3 verschlüsselt.

HINWEIS:

TLSv1.2 ist das absolute Mindestsicherheitsniveau für jede Transportverbindung.

Die akzeptierten Cipher-Suites können bei Bedarf angepasst werden. Ist die Option nicht gesetzt (Standardeinstellung), gilt die Vorgabe der zugrunde liegenden OpenSSL-Bibliothek.

example: tls-cipher-13=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Protokollierungsoptionen

Der Abschnitt log definiert Einstellungen für die Protokollierung.

ACHTUNG:

Die Protokollierung auf Trace-Stufe kann Geheimnisse wie Schlüssel und Passwörter offenlegen. Mit Vorsicht verwenden!

Option für die Protokollierungsstufe der Konsole (--log-level-console)

Protokollierungsstufe für die Konsole.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: warn
example: log-level-console=error

Option für die Protokollierungsstufe der Datei (--log-level-file)

Protokollierungsstufe für die Dateiausgabe.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: info
example: log-level-file=debug

Option für die Protokollierungsstufe der Standardfehlerausgabe (--log-level-stderr)

Protokollierungsstufe für stderr.

Legt fest, welche Protokollierungsstufen an stderr statt an stdout ausgegeben werden (festgelegt durch log-level-console). Zeitstempel und Prozess werden nicht an stderr ausgegeben.

Die folgenden Protokollierungsstufen werden unterstützt:

  • off - Keine Protokollierung (nicht empfohlen)
  • error - Nur Fehler protokollieren
  • warn - Warnungen und Fehler protokollieren
  • info - Informationen, Warnungen und Fehler protokollieren
  • detail - Details, Informationen, Warnungen und Fehler protokollieren
  • debug - Debug-Meldungen, Details, Informationen, Warnungen und Fehler protokollieren
  • trace - Trace-Meldungen (sehr ausführliche Debug-Ausgaben), Debug-Meldungen, Informationen, Warnungen und Fehler protokollieren
default: off
example: log-level-stderr=error

Option für den Protokollpfad (--log-path)

Pfad, an dem Protokolldateien gespeichert werden.

In diesem Pfad speichert pgBackRest seine Protokolldateien. Bei log-level-file=off ist kein Protokollpfad erforderlich.

default: /var/log/pgbackrest
example: log-path=/backup/db/log

Option für die Protokollierung von Unterprozessen (--log-subprocess)

Protokollierung in Unterprozessen aktivieren.

Aktiviert die Dateiprotokollierung für alle von diesem Prozess erzeugten Unterprozesse mit der durch log-level-file festgelegten Protokollierungsstufe.

default: n
example: log-subprocess=y

Option für Zeitstempel im Protokoll (--log-timestamp)

Zeitstempel in der Protokollierung aktivieren.

Aktiviert Zeitstempel in der Konsolen- und Dateiprotokollierung. Diese Option wird in besonderen Situationen deaktiviert, etwa beim Erzeugen der Dokumentation.

default: y
example: log-timestamp=n

Optionen für Maintainer

Maintainer-Optionen dienen der Unterstützung von PostgreSQL-Forks. Die richtigen Einstellungen sollten vom Maintainer des Forks ermittelt und anschließend dessen Benutzern mitgeteilt werden.

WARNUNG:

Unsachgemäße Verwendung dieser Optionen kann zu unerwartetem Verhalten oder Datenbeschädigungen führen.

Es liegt in der Verantwortung des Fork-Maintainers, pgBackRest mit den erforderlichen Optionen zu testen. pgBackRest garantiert keine Kompatibilität mit Forks.

Option zur Prüfung der WAL-Header (--archive-header-check)

PostgreSQL-Version und -ID in WAL-Headern prüfen.

Diese standardmäßig aktivierte Option prüft den WAL-Header anhand der PostgreSQL-Version und der Systemkennung. Dadurch wird sichergestellt, dass WAL in die richtige Stanza kopiert wird. Zusätzlich wird bereits pg_control mit der Stanza abgeglichen und geprüft, ob WAL aus demselben PostgreSQL-Datenverzeichnis kopiert wird, in dem sich pg_control befindet.

Das Deaktivieren dieser Prüfung ist daher relativ sicher, sollte aber nur bei Bedarf erfolgen, etwa wenn WAL verschlüsselt ist.

default: y
example: archive-header-check=n

Option zur Prüfung der Seitenheader (--page-header-check)

PostgreSQL-Seitenheader prüfen.

Diese standardmäßig aktivierte Option ergänzt Prüfungen der Seitenheader.

Das Deaktivieren dieser Option sollte vermieden werden, außer wenn es erforderlich ist, etwa bei verschlüsselten Seiten.

default: y
example: page-header-check=n

Option zum Erzwingen der PostgreSQL-Version (--pg-version-force)

PostgreSQL-Version erzwingen.

Verwendet die angegebene PostgreSQL-Version statt der Version, die automatisch aus pg_control oder WAL-Headern ermittelt wird. Dies ist hauptsächlich für PostgreSQL-Forks oder Entwicklungsversionen hilfreich, deren Werte von denen der veröffentlichten Version abweichen. Die von PostgreSQL über server_version_num gemeldete Version muss mit der erzwungenen Version übereinstimmen.

WARNUNG:

Diese Option mit Vorsicht verwenden: pg_control und WAL-Header werden weiterhin im erwarteten Format der angegebenen Version gelesen, also im Format der offiziellen Open-Source-Version von PostgreSQL. Ändert der Fork oder die Entwicklungsversion das Format von Feldern, auf die pgBackRest angewiesen ist, führt dies zu unerwartetem Verhalten. Im Allgemeinen funktioniert diese Option nur dann wie erwartet, wenn der Fork alle eigenen Strukturfelder nach den standardmäßigen PostgreSQL-Feldern hinzufügt.

example: pg-version-force=15

Repository-Optionen

Der Abschnitt repository definiert Optionen zur Konfiguration des Repositorys.

Indizierung: Alle repo--Optionen sind indiziert, damit mehrere Repositorys konfiguriert werden können. Ein einzelnes Repository wird beispielsweise mit repo1-path, repo1-host usw. konfiguriert. Sind mehrere Repositorys konfiguriert und wird bei einem Befehl kein --repo angegeben, werden sie in absteigender Priorität bearbeitet, etwa repo1 vor repo2.

Die Optionen repo-retention-* legen fest, wie lange Backups aufbewahrt werden. Eine Bereinigung erfolgt erst, wenn die Anzahl abgeschlossener Backups die zulässige Aufbewahrung überschreitet. Steht also repo1-retention-full-type auf count (Standard) und repo1-retention-full auf 2, müssen 3 abgeschlossene Backups vorhanden sein, bevor das älteste entfernt wird. Steht repo1-retention-full-type auf time, gibt repo1-retention-full Tage an. Daher müssen vollständige Backups für mindestens diesen Zeitraum vorliegen, bevor eine Bereinigung erfolgen kann. Sorgen Sie stets für genügend Platz für die Aufbewahrungsanzahl + 1 Backups.

Option für das Azure-Konto des Repositorys (--repo-azure-account)

Azure-Konto des Repositorys.

Azure-Konto, in dem das Repository gespeichert wird.

example: repo1-azure-account=pg-backup

Option für den Azure-Container des Repositorys (--repo-azure-container)

Azure-Repository-Container.

Azure-Container, der das Repository speichert.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Containers gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von Azure erzeugte Inhalte im Container gespeichert werden können.

example: repo1-azure-container=pg-backup

Option für den Azure-Endpunkt des Repositorys (--repo-azure-endpoint)

Azure-Endpunkt des Repositorys.

Endpunkt für die Verbindung zum Blob-Dienst. Der Standardwert ist im Allgemeinen korrekt, sofern nicht Azure Government verwendet wird.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

default: blob.core.windows.net
example: repo1-azure-endpoint=blob.core.usgovcloudapi.net

Option für den Azure-Schlüssel des Repositorys (--repo-azure-key)

Azure-Schlüssel des Repositorys.

Je nach repo-azure-key-type ein gemeinsamer Schlüssel oder eine Signatur für gemeinsamen Zugriff.

example: repo1-azure-key=T+9+aov82qNhrcXSNGZCzm9mjd4d75/oxxOr6r1JVpgTLA==

Option für den Azure-Schlüsseltyp des Repositorys (--repo-azure-key-type)

Azure-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • shared - Gemeinsamer Schlüssel
  • sas - Signatur für gemeinsamen Zugriff
  • auto - Automatische Autorisierung mit verwalteten Azure-Identitäten
default: shared
example: repo1-azure-key-type=sas

Option für den Azure-URI-Stil des Repositorys (--repo-azure-uri-style)

Azure-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Verbindung zum account.endpoint-Host herstellen.
  • path - Verbindung zum endpoint-Host herstellen und den Kontonamen vor die URIs stellen.
default: host
example: repo1-azure-uri-style=path

Option für inkrementelle Backups auf Blockebene (--repo-block)

Inkrementelle Backups auf Blockebene aktivieren.

Inkrementelle Backups auf Blockebene ermöglichen feinere Abstufungen, indem Dateien in Blöcke aufgeteilt werden, die sich unabhängig voneinander sichern lassen. Dies spart Speicherplatz im Repository und kann Delta-Wiederherstellungen beschleunigen, da einzelne Blöcke abgerufen werden können, ohne die gesamte Datei aus dem Repository zu lesen.

HINWEIS:

repo-bundle muss aktiviert sein, bevor repo-block aktiviert werden kann.

Die Blockgröße einer Datei wird anhand ihrer Größe und ihres Alters bestimmt. Ältere oder größere Dateien erhalten im Allgemeinen größere Blöcke. Ist eine Datei alt genug, wird sie nicht inkrementell auf Blockebene gesichert.

Inkrementelle Backups auf Blockebene sind am effizientesten, wenn sie für alle Backup-Typen einschließlich vollständiger Backups aktiviert sind. Das vollständige Backup wird dadurch etwas größer. Spätere differenzielle und inkrementelle Backups können aber die dabei erzeugten Blockzuordnungen nutzen, um Speicherplatz zu sparen.

default: n
example: repo1-block=y

Option für Dateibündel im Repository (--repo-bundle)

Dateien im Repository bündeln.

Kleinere Dateien bündeln, also zusammenfassen, um die Gesamtzahl der ins Repository geschriebenen Dateien zu verringern. Weniger Dateien zu schreiben ist im Allgemeinen effizienter, insbesondere bei Objektspeichern wie S3. Außerdem werden leere Dateien nur im Manifest erfasst und ansonsten nicht gespeichert, was Zeit und Speicherplatz spart.

default: n
example: repo1-bundle=y

Option für die Dateigrößengrenze beim Bündeln (--repo-bundle-limit)

Grenzwert für Dateibündel.

Größenlimit für Dateien, die in Bündel aufgenommen werden. Größere Dateien werden separat gespeichert.

Gebündelte Dateien können bei der Wiederaufnahme eines Backups nicht wiederverwendet werden. Diese Option bestimmt daher, welche Dateien sich wiederverwenden lassen: Höhere Werte führen zu weniger wiederverwendbaren Dateien.

default: 2MiB
allowed: [8KiB, 1PiB]
example: repo1-bundle-limit=10MiB

Option für die Bündelgröße im Repository (--repo-bundle-size)

Zielgröße für Dateibündel.

Legt die angestrebte Gesamtgröße der Dateien in einem Bündel fest. Die unkomprimierte Bündelgröße kann bis zu repo-bundle-size + repo-bundle-limit betragen. Deshalb diese Option nicht auf die maximal zulässige Dateigröße des Dateisystems setzen.

Im Allgemeinen sollte diese Option nicht zu hoch gesetzt werden, da bei Wiederholungsversuchen das gesamte Bündel erneut verarbeitet werden muss.

default: 20MiB
allowed: [1MiB, 1PiB]
example: repo1-bundle-size=10MiB

Option für die Verschlüsselungspassphrase des Repositorys (--repo-cipher-pass)

Verschlüsselungspassphrase des Repositorys.

Passphrase zum Verschlüsseln und Entschlüsseln von Dateien im Repository.

HINWEIS:

Ohne die Option stanza liest der Befehl info Verschlüsselungseinstellungen nur aus dem Abschnitt global. Sind diese Einstellungen pro Stanza konfiguriert, info mit der Option stanza ausführen, um eine verschlüsselte Stanza zu lesen.

example: repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO

Option für den Verschlüsselungstyp des Repositorys (--repo-cipher-type)

Verfahren zur Verschlüsselung des Repositorys.

Folgende Verschlüsselungstypen werden unterstützt:

  • none - Das Repository ist nicht verschlüsselt
  • aes-256-cbc - Advanced Encryption Standard mit Schlüssellänge von 256 Bit

Beachten Sie, dass die Verschlüsselung immer clientseitig durchgeführt wird, selbst wenn der Repository-Typ (z. B. S3) Verschlüsselung unterstützt.

default: none
example: repo1-cipher-type=aes-256-cbc

Option für den GCS-Bucket des Repositorys (--repo-gcs-bucket)

GCS-Bucket des Repositorys.

GCS-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von GCS erzeugte Inhalte im Bucket gespeichert werden können.

example: repo1-gcs-bucket=/pg-backup

Option für den GCS-Endpunkt des Repositorys (--repo-gcs-endpoint)

GCS-Repository-Endpunkt.

Endpunkt, der zum Verbinden mit dem Speicherdienst verwendet wird. Kann aktualisiert werden, um einen lokalen GCS-Server oder einen alternativen Endpunkt zu verwenden.

default: storage.googleapis.com
example: repo1-gcs-endpoint=localhost

Option für den GCS-Schlüssel des Repositorys (--repo-gcs-key)

GCS-Schlüssel des Repositorys.

Je nach repo-gcs-key-type ein Token oder eine Dienstschlüsseldatei.

example: repo1-gcs-key=/etc/pgbackrest/gcs-key.json

Option für den GCS-Schlüsseltyp des Repositorys (--repo-gcs-key-type)

GCS-Repository-Schlüsseltyp.

Folgende Typen werden für die Autorisierung unterstützt:

  • auto - Autorisierung mithilfe des Dienstkontos der Instanz.
  • service - Dienstkonto anhand eines lokal gespeicherten Schlüssels.
  • token - Für lokale Tests, z. B. fakegcs.

Wenn repo-gcs-key-type=service ist, werden die Anmeldeinformationen erneut geladen, wenn das Authentifizierungstoken erneuert wird.

default: service
example: repo1-gcs-key-type=auto

Option für die GCS-Projekt-ID des Repositorys (--repo-gcs-user-project)

GCS-Projekt-ID.

GCS-Projekt-ID, die zur Bestimmung der Abrechnung von Anfragen verwendet wird.

example: repo1-gcs-user-project=my-project

Option für Hardlinks im Repository (--repo-hardlink)

Dateien zwischen Backups im Repository durch Hardlinks verbinden.

Aktiviert Hardlinks von Dateien in differenziellen und inkrementellen Backups auf die zugehörigen vollständigen Backups. Auf Dateisystemebene wirkt dadurch jedes Backup wie ein vollständiges Backup. Vorsicht: Änderungen an Dateien mit Hardlinks können alle Backups des Satzes betreffen.

default: n
example: repo1-hardlink=y

Veralteter Name: hardlink

Option für den Repository-Host (--repo-host)

Repository-Host bei entfernter Ausführung.

Für Backups und Archivierung auf einem lokal eingehängten Dateisystem ist diese Einstellung nicht erforderlich.

example: repo1-host=repo1.domain.com

Veralteter Name: backup-host

Option für die CA-Datei des Repository-Hosts (--repo-host-ca-file)

Datei mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host eine andere als die systemweite CA-Datei verwenden.

example: repo1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des Repository-Hosts (--repo-host-ca-path)

Pfad mit den Zertifizierungsstellen für den Repository-Host.

Für Verbindungen zum Repository-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: repo1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des Repository-Hosts (--repo-host-cert-file)

Zertifikatdatei für den Repository-Host.

Wird an den Repository-Host gesendet, um die Client-Identität zu bestätigen.

example: repo1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem Repository-Host (--repo-host-cmd)

pgBackRest-Befehl auf dem Repository-Host.

Erforderlich nur, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem Repository-Host unterschiedlich ist. Wenn nicht definiert, wird der Repository-Host-Befehl auf den gleichen Wert wie der lokale Befehl gesetzt.

default: [path of executed pgbackrest binary]
example: repo1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: backup-cmd

Option für die Konfiguration des Repository-Hosts (--repo-host-config)

pgBackRest-Konfigurationsdatei auf dem Repository-Host.

Legt den Speicherort der Konfigurationsdatei auf dem Repository-Host fest. Dies ist nur erforderlich, wenn sich die Repository-Host-Konfigurationsdatei an einem anderen Ort befindet als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: repo1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: backup-config

Option für zusätzliche Konfigurationsdateien auf dem Repository-Host (--repo-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Repository-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: repo1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des Repository-Hosts (--repo-host-config-path)

pgBackRest-Konfigurationspfad auf dem Repository-Host.

Legt den Konfigurationspfad auf dem Repository-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem Repository-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: repo1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des Repository-Hosts (--repo-host-key-file)

Schlüsseldatei für den Repository-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: repo1-host-key-file=/path/to/client.key

Option für den Port des Repository-Hosts (--repo-host-port)

Port des Repository-Hosts, wenn repo-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des Repository-Hosts angeben.

HINWEIS:

Bei repo-host-type=ssh gibt es keinen Standardwert für repo-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on repo-host-type):
    tls - 8432

allowed: [0, 65535]
example: repo1-host-port=25

Veralteter Name: backup-ssh-port

Option für den Protokolltyp des Repository-Hosts (--repo-host-type)

Protokolltyp für den Repository-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: repo1-host-type=tls

Option für den Benutzer auf dem Repository-Host (--repo-host-user)

Benutzer auf dem Repository-Host, wenn repo-host gesetzt ist.

Legt den Benutzer für Operationen auf dem Repository-Host fest. Vorzugsweise ist dies nicht postgres, sondern ein anderer Benutzer wie pgbackrest. Läuft PostgreSQL auf dem Repository-Host, kann der Benutzer postgres der Gruppe pgbackrest hinzugefügt werden. So erhält er Leserechte für das Repository, ohne dessen Inhalt versehentlich beschädigen zu können.

default: pgbackrest
example: repo1-host-user=repo-user

Veralteter Name: backup-user

Option für den Repository-Pfad (--repo-path)

Pfad zum Speichern von Backups und Archiv.

Im Repository speichert pgBackRest Backups und archiviert WAL-Segmente.

Der benötigte Speicherplatz lässt sich im Voraus oft schwer abschätzen. Am besten erstellen Sie einige Backups, erfassen die Größe verschiedener Backup-Typen (full/incr/diff) und messen die täglich erzeugte WAL-Menge. So erhalten Sie einen ungefähren Überblick über den Platzbedarf. Dieser wird sich im Laufe der Zeit mit der Entwicklung der Datenbank wahrscheinlich ändern.

default: /var/lib/pgbackrest
example: repo1-path=/backup/db/backrest

Option für die Archivaufbewahrung (--repo-retention-archive)

Anzahl der Backups, für die lückenloses WAL aufbewahrt wird.

HINWEIS:

WAL-Segmente, die für ein konsistentes Backup erforderlich sind, bleiben unabhängig von dieser Einstellung immer bis zum Entfernen des Backups erhalten.

Ist dieser Wert nicht gesetzt und ist repo-retention-full-type auf count gesetzt (Standardeinstellung), richtet sich die Archivbereinigung nach repo-retention-full beziehungsweise repo-retention-diff, wenn repo-retention-archive-type auf full beziehungsweise diff gesetzt ist. So wird WAL nur für bereits entfernte Backups gelöscht. Ist repo-retention-full-type auf time gesetzt, werden standardmäßig Archive entfernt, die älter sind als das älteste vollständige Backup, das nach Anwendung von repo-retention-full aufbewahrt wird.

Diese Option muss gesetzt sein, wenn repo-retention-archive-type auf incr gesetzt ist. Bei knappem Speicherplatz kann sie zusammen mit repo-retention-archive-type verwendet werden, um WAL-Segmente frühzeitig zu entfernen. Damit ist jedoch keine PITR mehr aus Backups möglich, deren WAL entfernt wurde. Dies wird daher nicht empfohlen.

allowed: [1, 9999999]
example: repo1-retention-archive=2

Veralteter Name: retention-archive

Option für den Typ der Archivaufbewahrung (--repo-retention-archive-type)

Backup-Typ für die WAL-Aufbewahrung.

Bei full bewahrt pgBackRest Archivprotokolle für die durch repo-retention-archive festgelegte Anzahl vollständiger Backups auf. Bei diff (differenziell) werden sie für die durch repo-retention-archive festgelegte Anzahl vollständiger und differenzieller Backups aufbewahrt. War das letzte Backup vollständig, wird es für repo-retention also als differenzielles Backup gezählt. Bei incr (inkrementell) bewahrt pgBackRest Archivprotokolle für die durch repo-retention-archive festgelegte Anzahl vollständiger, differenzieller und inkrementeller Backups auf. Es wird empfohlen, die Standardeinstellung beizubehalten, bei der WAL nur zusammen mit vollständigen Backups entfernt wird.

default: full
example: repo1-retention-archive-type=diff

Veralteter Name: retention-archive-type

Option für die Aufbewahrung differenzieller Backups (--repo-retention-diff)

Anzahl der aufzubewahrenden differenziellen Backups.

Wird ein differenzielles Backup entfernt, werden auch alle zugehörigen inkrementellen Backups entfernt. Ohne Angabe bleiben alle differenziellen Backups erhalten, bis die vollständigen Backups entfernt werden, von denen sie abhängen.

Bei der Bereinigung zählen vollständige Backups zur Anzahl der differenziellen Backups. Dadurch müssen in den meisten Fällen etwas weniger differenzielle Backups aufbewahrt werden.

allowed: [1, 9999999]
example: repo1-retention-diff=3

Veralteter Name: retention-diff

Option für die Aufbewahrung vollständiger Backups (--repo-retention-full)

Anzahl oder Aufbewahrungsdauer vollständiger Backups.

Wird ein vollständiges Backup entfernt, werden auch alle zugehörigen differenziellen und inkrementellen Backups entfernt. Ist diese Option nicht gesetzt, wird eine Warnung ausgegeben. Für eine unbegrenzte Aufbewahrung die Option auf den Höchstwert setzen.

allowed: [1, 9999999]
example: repo1-retention-full=2

Veralteter Name: retention-full

Option für die Art der Aufbewahrung vollständiger Backups (--repo-retention-full-type)

Art der Aufbewahrung vollständiger Backups.

Bestimmt, ob repo-retention-full einen Zeitraum in Tagen oder die Anzahl der aufzubewahrenden vollständigen Backups angibt.

Bei time werden vollständige Backups, die älter als repo-retention-full sind, aus dem Repository entfernt, wenn mindestens ein weiteres Backup vorhanden ist, dessen Alter mindestens dem Wert von repo-retention-full entspricht. Steht beispielsweise repo-retention-full auf 30 Tage und gibt es 2 vollständige Backups, eines 25 Tage und eines 35 Tage alt, wird keines entfernt. Würde das 35 Tage alte Backup entfernt, bliebe nur das 25 Tage alte übrig. Dies würde die Aufbewahrungsregel von 30 Tagen verletzen: Es muss mindestens ein 30 Tage altes Backup vorhanden sein, bevor ein älteres entfernt werden kann. Archiviertes WAL, das älter als das älteste verbleibende vollständige Backup ist, wird automatisch entfernt, sofern repo-retention-archive-type und repo-retention-archive nicht ausdrücklich gesetzt sind.

Bei count werden vollständige Backups entfernt, die über die durch repo-retention-full festgelegte Anzahl hinausgehen. Steht beispielsweise repo-retention-full auf 4 und wird ein fünftes vollständiges Backup abgeschlossen, wird das älteste entfernt, sodass die Anzahl bei 4 bleibt.

Ein Backup muss erfolgreich abgeschlossen sein, bevor es für die Aufbewahrung zählt. Steht beispielsweise repo-retention-full-type auf count und repo-retention-full auf 2, müssen 3 abgeschlossene vollständige Backups vorhanden sein, bevor das älteste entfernt wird.

default: count
example: repo1-retention-full-type=time

Option für die Aufbewahrung des Backup-Verlaufs (--repo-retention-history)

Aufbewahrungsdauer der Manifeste im Backup-Verlauf in Tagen.

Nach Abschluss eines Backups wird eine Kopie seines Manifests im Pfad backup.history gespeichert. Standardmäßig werden diese Dateien nie entfernt, da sie für Auswertungen nützlich sind, etwa um das Wachstum von Backups und WAL im Zeitverlauf zu messen.

Mit repo-retention-history die Anzahl der Tage festlegen, für die Manifeste im Backup-Verlauf aufbewahrt werden. Noch nicht entfernte Backups bleiben stets im Verlauf erhalten. Mit repo-retention-history=0 wird der Verlauf nur für solche Backups aufbewahrt.

Wird das Verlaufsmanifest eines vollständigen Backups entfernt, werden auch die Verlaufsmanifeste aller zugehörigen differenziellen und inkrementellen Backups entfernt.

allowed: [0, 9999999]
example: repo1-retention-history=365

Option für den S3-Bucket des Repositorys (--repo-s3-bucket)

S3-Bucket des Repositorys.

S3-Bucket, in dem das Repository gespeichert wird.

pgBackRest-Repositorys können mit repo-path=/ im Stammverzeichnis des Buckets gespeichert werden. Meist ist jedoch ein Präfix wie /repo sinnvoll, damit auch Protokolle und andere von AWS erzeugte Inhalte im Bucket gespeichert werden können.

example: repo1-s3-bucket=pg-backup

Option für den S3-Endpunkt des Repositorys (--repo-s3-endpoint)

S3-Endpunkt des Repositorys.

Der AWS-Endpunkt sollte für die ausgewählte Region gültig sein.

Für angepasste Konfigurationen oder Tests können die Optionen repo-storage-ca-file, repo-storage-ca-path, repo-storage-host, repo-storage-port und repo-storage-verify-tls hilfreich sein.

example: repo1-s3-endpoint=s3.amazonaws.com

Option für den S3-Zugriffsschlüssel des Repositorys (--repo-s3-key)

S3-Zugriffsschlüssel des Repositorys.

AWS-Schlüssel für den Zugriff auf diesen Bucket.

example: repo1-s3-key=AKIAIOSFODNN7EXAMPLE

Option für den geheimen S3-Zugriffsschlüssel des Repositorys (--repo-s3-key-secret)

Geheimer S3-Zugriffsschlüssel des Repositorys.

Geheimer AWS-Schlüssel für den Zugriff auf diesen Bucket.

example: repo1-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Option für den S3-Schlüsseltyp des Repositorys (--repo-s3-key-type)

S3-Schlüsseltyp des Repositorys.

Die folgenden Typen werden unterstützt:

  • shared - Gemeinsame Schlüssel
  • auto - Temporäre Anmeldeinformationen automatisch abrufen
  • web-id - Anmeldeinformationen für eine Web-Identität automatisch abrufen
  • pod-id - Anmeldeinformationen für eine EKS-Pod-Identität automatisch abrufen
  • process - Anmeldeinformationen durch Ausführen eines Prozesses abrufen
default: shared
example: repo1-s3-key-type=auto

Option für die KMS-Schlüssel-ID des S3-Repositorys (--repo-s3-kms-key-id)

KMS-Schlüssel für das S3-Repository.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Schlüssel des AWS Key Management Service.

example: repo1-s3-kms-key-id=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den S3-Authentifizierungsprozess (--repo-s3-process-cmd)

Befehl für den S3-Authentifizierungsprozess.

Befehl mit optionalen Argumenten zum Abrufen temporärer S3-Anmeldeinformationen. Der erste Listeneintrag ist der Befehl; die übrigen Einträge werden als Parameter übergeben.

Der Prozess muss JSON mit den Feldern AccessKeyId, SecretAccessKey, SessionToken und Expiration ausgeben. Die Anmeldeinformationen werden vor ihrem Ablauf automatisch erneuert. Einzelheiten zum Format finden Sie unter Anmeldeinformationen aus einem Prozess .

example: repo1-s3-process-cmd=/usr/local/bin/get-credentials
example: repo1-s3-process-cmd=--role
example: repo1-s3-process-cmd=my-role

Option für die S3-Region des Repositorys (--repo-s3-region)

S3-Region des Repositorys.

AWS-Region, in der der Bucket erstellt wurde.

example: repo1-s3-region=us-east-1

Option für die Kostenübernahme durch den S3-Anforderer (--repo-s3-requester-pays)

Kostenübernahme durch den Anforderer beim S3-Repository.

Aktiviert die S3-Kostenübernahme durch den Anforderer.

default: n
example: repo1-s3-requester-pays=n

Option für die S3-Rolle des Repositorys (--repo-s3-role)

S3-Rolle des Repositorys.

Name der AWS-Rolle (nicht der vollständige ARN) zum Abrufen temporärer Anmeldeinformationen bei repo-s3-key-type=auto.

example: repo1-s3-role=authrole

Option für den S3-Dienst des Repositorys (--repo-s3-service)

S3-Signaturdienst.

Der bei der SigV4-Authentifizierung verwendete S3-Signaturdienst. Für standardmäßige S3-Endpunkte ist der Standardwert s3. Bei einem S3-Outposts-Endpunkt auf s3-outposts setzen.

default: s3
example: repo1-s3-service=s3-outposts

Option für den S3-SSE-Kundenschlüssel des Repositorys (--repo-s3-sse-customer-key)

S3-SSE-Kundenschlüssel des Repositorys.

Aktiviert die serverseitige S3-Verschlüsselung mit dem angegebenen Kundenschlüssel.

example: repo1-s3-sse-customer-key=bceb4f13-6939-4be3-910d-df54dee817b7

Option für den STS-Endpunkt des S3-Repositorys (--repo-s3-sts-host)

STS-Endpunkt des S3-Repositorys.

STS-Endpunkt zum Abrufen temporärer Anmeldeinformationen, wenn repo-s3-key-type=web-id konfiguriert ist. Einen regionalen Endpunkt wie sts.us-east-1.amazonaws.com angeben, um regionales STS zu verwenden. Dies kann für GovCloud, Regionen in China oder zur Verringerung der Latenz erforderlich sein.

default: sts.amazonaws.com
example: repo1-s3-sts-host=sts.us-east-1.amazonaws.com

Option für das S3-Sicherheitstoken des Repositorys (--repo-s3-token)

S3-Sicherheitstoken des Repositorys.

AWS-Sicherheitstoken für die Verwendung mit temporären Anmeldeinformationen.

example: repo1-s3-token=AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22 ...

Option für den S3-URI-Stil des Repositorys (--repo-s3-uri-style)

S3-URI-Stil.

Folgende URI-Stile werden unterstützt:

  • host - Mit dem Host bucket.endpoint verbinden.
  • path - Mit dem Host endpoint verbinden und den Bucket den URIs voranstellen.
default: host
example: repo1-s3-uri-style=path

Option für den SFTP-Host des Repositorys (--repo-sftp-host)

SFTP-Host des Repositorys.

SFTP-Host, auf dem sich das Repository befindet.

example: repo1-sftp-host=sftprepo.domain

Option für den Fingerabdruck des SFTP-Hosts (--repo-sftp-host-fingerprint)

Fingerabdruck des SFTP-Hosts des Repositorys.

Die Erzeugung des Fingerabdrucks für den SFTP-Host des Repositorys sollte repo-sftp-host-key-hash-type entsprechen. Den Fingerabdruck mit awk '{print $2}' ssh_host_xxx_key.pub | base64 -d | (md5sum or sha1sum) -b erzeugen. Die SSH-Hostschlüssel befinden sich normalerweise im Verzeichnis /etc/ssh.

example: repo1-sftp-host-fingerprint=f84e172dfead7aeeeae6c1fdfb5aa8cf

Option für die SFTP-Hostschlüsselprüfung (--repo-sftp-host-key-check-type)

Art der SFTP-Hostschlüsselprüfung.

Die folgenden Arten der SFTP-Hostschlüsselprüfung werden unterstützt:

  • strict - pgBackRest fügt niemals automatisch Hostschlüssel zur Datei ~/.ssh/known_hosts hinzu und verweigert Verbindungen zu Hosts, deren Hostschlüssel geändert wurde oder in den Dateien mit bekannten Hosts fehlt. Bei dieser Option muss der Benutzer alle neuen Hosts manuell hinzufügen.
  • accept-new - pgBackRest fügt neue Hostschlüssel automatisch zur Datei mit bekannten Hosts des Benutzers hinzu, lässt aber keine Verbindungen zu Hosts mit geändertem Hostschlüssel zu.
  • fingerprint - pgBackRest prüft den Hostschlüssel anhand des mit repo-sftp-host-fingerprint angegebenen Fingerabdrucks.
  • none - Es wird keine Hostschlüsselprüfung durchgeführt.
default: strict
example: repo1-sftp-host-key-check-type=accept-new

Option für den Hash-Typ des SFTP-Hostschlüssels (--repo-sftp-host-key-hash-type)

Hash-Typ des SFTP-Hostschlüssels für das Repository.

Hash-Typ des SFTP-Hostschlüssels für das Repository. Legt den Hash-Typ fest, mit dem beim SSH-Verbindungsaufbau der Hashwert des Hostschlüssels des entfernten Systems berechnet wird. Neuere Versionen von libssh2 unterstützen neben md5 und sha1 auch sha256.

example: repo1-sftp-host-key-hash-type=sha256

Option für den Port des SFTP-Hosts (--repo-sftp-host-port)

Port des SFTP-Hosts für das Repository.

Port des SFTP-Hosts für das Repository.

default: 22
allowed: [1, 65535]
example: repo1-sftp-host-port=22

Option für den Benutzer auf dem SFTP-Host (--repo-sftp-host-user)

Benutzer auf dem SFTP-Host für das Repository.

Benutzer auf dem Host, auf dem das Repository gespeichert wird.

example: repo1-sftp-host-user=pg-backup

Option für die Datei bekannter SFTP-Hosts (--repo-sftp-known-host)

Datei mit bekannten SFTP-Hosts.

Datei mit bekannten Hosts, in der bei der Authentifizierung nach einem passenden SFTP-Host gesucht wird. Ohne Angabe durchsucht pgBackRest standardmäßig ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2. Sind ein oder mehrere Dateipfade konfiguriert, durchsucht pgBackRest diese nach einem passenden Eintrag. Dateipfade müssen vollständig sein oder mit einer Tilde beginnen. Die Option repo-sftp-known-host kann mehrfach angegeben werden, um mehrere Dateien mit bekannten Hosts zu durchsuchen. Für die Prüfung anhand dieser Dateien darf repo-sftp-host-fingerprint nicht angegeben sein. Siehe auch die Option repo-sftp-host-check-type.

example: repo1-sftp-known-host=/home/postgres/.ssh/known_hosts

Option für die private SFTP-Schlüsseldatei (--repo-sftp-private-key-file)

Datei mit dem privaten SFTP-Schlüssel.

Datei mit dem privaten SFTP-Schlüssel zur Authentifizierung.

example: repo1-sftp-private-key-file=~/.ssh/id_ed25519

Option für die Passphrase des privaten SFTP-Schlüssels (--repo-sftp-private-key-passphrase)

Passphrase für den privaten SFTP-Schlüssel.

Passphrase für den Zugriff auf den privaten Schlüssel. Sie kann beim Erstellen eines öffentlichen/privaten SSH-Schlüsselpaars optional vergeben werden.

example: repo1-sftp-private-key-passphrase=BeSureToGenerateAndUseASecurePassphrase

Option für die öffentliche SFTP-Schlüsseldatei (--repo-sftp-public-key-file)

Datei mit dem öffentlichen SFTP-Schlüssel.

Datei mit dem öffentlichen SFTP-Schlüssel zur Authentifizierung. Bei einer gegen OpenSSL kompilierten Version optional, bei einer gegen eine andere Bibliothek kompilierten Version erforderlich.

example: repo1-sftp-public-key-file=~/.ssh/id_ed25519.pub

Option für die CA-Datei des Repository-Speichers (--repo-storage-ca-file)

CA-Datei für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) eine andere als die systemweite CA-Datei verwenden.

example: repo1-storage-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Veraltete Namen: repo-azure-ca-file, repo-s3-ca-file

Option für den TLS-CA-Pfad des Repository-Speichers (--repo-storage-ca-path)

CA-Pfad für den Repository-Speicher.

Für Zertifikate des Speicherdienstes (z. B. S3 oder Azure) einen anderen als den systemweiten CA-Pfad verwenden.

example: repo1-storage-ca-path=/etc/pki/tls/certs

Veraltete Namen: repo-azure-ca-path, repo-s3-ca-path

Option für den Host des Repository-Speichers (--repo-storage-host)

Host des Repository-Speichers.

Mit einem anderen Host als dem Endpunkt des Speicherdienstes (z. B. S3 oder Azure) verbinden. Dies wird üblicherweise für Tests verwendet.

example: repo1-storage-host=127.0.0.1

Veraltete Namen: repo-azure-host, repo-s3-host

Option für den Port des Repository-Speichers (--repo-storage-port)

Port des Repository-Speichers.

Port für Verbindungen zum Endpunkt des Speicherdienstes (z. B. S3 oder Azure) oder zum angegebenen Host.

default: 443
allowed: [1, 65535]
example: repo1-storage-port=9000

Veraltete Namen: repo-azure-port, repo-s3-port

Option für Tags im Repository-Speicher (--repo-storage-tag)

Tags für den Repository-Speicher.

Tags angeben, die Objekten hinzugefügt werden, wenn das Repository ein Objektspeicher wie S3 ist. Die Option kann wiederholt werden, um mehrere Tags hinzuzufügen.

pgBackRest bietet keine Möglichkeit, diese Tags zu ändern. Deshalb sollten sie vor dem Ausführen von stanza-create korrekt gesetzt werden, damit die Tags im gesamten Repository einheitlich sind.

example: repo1-storage-tag=key1=value1

Option für die Upload-Blockgröße des Repository-Speichers (--repo-storage-upload-chunk-size)

Blockgröße für Uploads in den Repository-Speicher.

Objektspeicher wie S3 erlauben das Hochladen von Dateien in Blöcken, wenn die Datei zu groß für den Arbeitsspeicher ist. Auch wenn die Datei in den Arbeitsspeicher passt, ist es speichereffizienter, den für Uploads verwendeten Speicher zu begrenzen.

Eine größere Blockgröße verbessert im Allgemeinen die Leistung, da sie die Anzahl der Upload-Anfragen verringert und es ermöglicht, mehr Dateien jeweils in einer einzelnen Anfrage statt in Blöcken hochzuladen. Nachteilig ist der höhere Speicherverbrauch. Da für jeden Prozess ein eigener Blockpuffer zugewiesen werden muss, erhöhen größere Werte für process-max den gesamten Speicherverbrauch zusätzlich.

Die zulässigen Blockgrößen unterscheiden sich je nach Speichertyp und Plattform. Beispielsweise beträgt die Mindestblockgröße bei AWS S3 5MiB. Auch die Bezeichnung variiert: Bei der Suche nach Mindest- und Höchstwerten für AWS S3 nach „part size“, für GCS nach „chunk size“ und für Azure nach „block size“ suchen.

Ist eine Datei größer als 1GiB (die maximale Dateigröße, die PostgreSQL standardmäßig erzeugt), wird die Blockgröße schrittweise bis zum zulässigen Maximum erhöht, um den Datei-Upload abzuschließen.

default (depending on repo-type):
    azure - 4MiB
    gcs - 4MiB
    s3 - 5MiB

allow range (depending on repo-type):
    azure - [4MiB, 1GiB]
    gcs - [4MiB, 1GiB]
    s3 - [5MiB, 1GiB]

example: repo1-storage-upload-chunk-size=16MiB

Option zur Zertifikatprüfung des Repository-Speichers (--repo-storage-verify-tls)

Zertifikatprüfung für den Repository-Speicher.

Mit dieser Option lässt sich die Prüfung des TLS-Serverzertifikats des Speicherdienstes (z. B. S3 oder Azure) aktivieren oder deaktivieren. Die Prüfung sollte nur für Tests oder andere Situationen mit selbstsignierten Zertifikaten deaktiviert werden.

default: y
example: repo1-storage-verify-tls=n

Veraltete Namen: repo-azure-verify-tls, repo-s3-verify-ssl, repo-s3-verify-tls

Option für symbolische Links im Repository (--repo-symlink)

Symbolische Links innerhalb des Repositorys erstellen.

Aktiviert das Erstellen der symbolischen Links für latest und Tablespaces. Diese Links sind vor allem nützlich, wenn Snapshots für eine Recovery direkt im Repository verwendet werden, was selten vorkommt.

Obwohl diese Funktion für die meisten Benutzer wahrscheinlich nicht nützlich ist, bleibt sie aus Kompatibilitätsgründen standardmäßig aktiviert. Bei POSIX-ähnlichen Speichern ohne Unterstützung für symbolische Links kann es jedoch sinnvoll sein, sie zu deaktivieren.

default: y
example: repo1-symlink=n

Option für den Zielzeitpunkt des Repositorys (--repo-target-time)

Zielzeitpunkt für das Repository.

Der Zielzeitpunkt legt fest, welchen Stand des Repositorys Befehle auf versioniertem Speicher lesen. So lässt sich das Repository zu einem früheren Zeitpunkt lesen, um Daten wiederherzustellen, die versehentlich durch Benutzer oder durch Schadsoftware gelöscht oder beschädigt wurden.

S3, GCS und Azure unterstützen versionierten Speicher, aktivieren ihn aber im Allgemeinen nicht standardmäßig. Neben der Versionierung kann es sinnvoll sein, bei S3 die Objektsperre und bei GCS oder Azure das vorläufige Löschen zu aktivieren.

Wenn repo-target-time angegeben wird, muss auch die Option repo angegeben werden. Wahrscheinlich unterstützen nicht alle Repository-Typen die Versionierung. Im Allgemeinen ist es sinnvoll, für die Wiederherstellung ein einzelnes Repository auszuwählen.

Beim Vergleich werden Speicherzeitstempel berücksichtigt, die <= dem angegebenen Zeitstempel sind. Enthaltene Millisekunden werden abgeschnitten.

example: repo-target-time=2024-08-08 12:12:12+00

Option für den Repository-Typ (--repo-type)

Art des für das Repository verwendeten Speichers.

Die folgenden Repository-Typen werden unterstützt:

  • azure - Azure Blob Storage Service
  • cifs - Wie posix, deaktiviert jedoch Links und fsync für Verzeichnisse
  • gcs - Google Cloud Storage
  • posix - POSIX-konforme Dateisysteme
  • s3 - AWS Simple Storage Service
  • sftp - Secure File Transfer Protocol

Wird ein NFS-Mount als posix-Repository verwendet, gelten für pgBackRest dieselben Regeln wie in der PostgreSQL-Dokumentation beschrieben: Erstellen eines Datenbankclusters – Dateisysteme .

default: posix
example: repo1-type=cifs

Wiederherstellungsoptionen

Der Abschnitt restore definiert Einstellungen zur Wiederherstellung von Backups.

Option für den Archivierungsmodus (--archive-mode)

Archivierung auf dem wiederhergestellten Cluster beibehalten oder deaktivieren.

Mit dieser Option lässt sich die Archivierung auf einem wiederhergestellten Cluster beibehalten oder deaktivieren. Dies ist nützlich, wenn der Cluster für bestimmte Arbeiten zum Primärserver hochgestuft werden muss, aber nicht dauerhaft der neue Primärserver werden soll. In diesem Fall ist es nicht ratsam, WAL aus diesem Cluster ins Repository zu übertragen.

Die folgenden Modi werden unterstützt:

  • off - Archivierung durch Setzen von archive_mode=off deaktivieren.
  • preserve - Die aktuelle Einstellung von archive_mode beibehalten.

HINWEIS: Diese Option ist unter PostgreSQL < 12 nicht verfügbar.

default: preserve
example: archive-mode=off

Option zum Ausschließen von Datenbanken (--db-exclude)

Wiederherstellung unter Ausschluss der angegebenen Datenbanken.

Ausgeschlossene Datenbanken werden als Sparse-Dateien mit Nullinhalt wiederhergestellt. Dies spart Platz und ermöglicht PostgreSQL dennoch die Recovery. Danach sind diese Datenbanken nicht zugänglich, können aber mit drop database entfernt werden. Die Option --db-exclude kann mehrfach angegeben werden, um mehrere Datenbanken auszuschließen.

In Kombination mit --db-include gilt --db-exclude nur für die standardmäßigen Systemdatenbanken template0, template1 und postgres.

example: db-exclude=db_main

Option zur Auswahl von Datenbanken (--db-include)

Nur die angegebenen Datenbanken wiederherstellen.

Mit dieser Funktion lassen sich gezielt ausgewählte Datenbanken wiederherstellen. Nicht ausdrücklich ausgewählte Datenbanken werden als Sparse-Dateien mit Nullinhalt wiederhergestellt. Dies spart Platz und ermöglicht PostgreSQL dennoch die Recovery. Danach sind die nicht ausgewählten Datenbanken nicht zugänglich, können aber mit drop database entfernt werden.

HINWEIS:

Die integrierten Datenbanken template0, template1 und postgres werden immer wiederhergestellt, sofern sie nicht ausdrücklich ausgeschlossen sind.

Die Option --db-include kann mehrfach angegeben werden, um mehrere Datenbanken auszuwählen.

Weitere Informationen und Einschränkungen finden Sie unter Ausgewählte Datenbanken wiederherstellen .

example: db-include=db_main

Option zur Wiederherstellung aller symbolischen Links (--link-all)

Alle symbolischen Links wiederherstellen.

Standardmäßig werden symbolisch verlinkte Verzeichnisse und Dateien als normale Verzeichnisse und Dateien in $PGDATA wiederhergestellt. Auf einem anderen System als dem Ursprungssystem des Backups ist es möglicherweise nicht sicher, symbolische Links mit ihren ursprünglichen Zielen wiederherzustellen. Diese Option stellt alle symbolischen Links genau so wieder her, wie sie auf dem Ursprungssystem des Backups vorhanden waren.

default: n
example: link-all=y

Option zur Zuordnung von Linkzielen (--link-map)

Das Ziel eines symbolischen Links ändern.

Ermöglicht es, die Zieldatei oder den Zielpfad eines symbolischen Links bei der Wiederherstellung zu ändern. Dies ist bei Systemen hilfreich, deren Speicheraufteilung vom Ursprungssystem des Backups abweicht.

example: link-map=pg_xlog=/data/xlog

Recovery-Option (--recovery-option)

Eine Option in postgresql.auto.conf oder recovery.conf setzen.

Einzelheiten zu den Optionen von postgresql.auto.conf oder recovery.conf finden Sie unter Serverkonfiguration . Wählen Sie dort unbedingt Ihre PostgreSQL-Version aus. Diese Option kann mehrfach verwendet werden.

Für PostgreSQL >= 12 werden die Optionen in postgresql.auto.conf geschrieben, für alle anderen Versionen in recovery.conf.

HINWEIS:

restore_command wird automatisch erzeugt, kann aber mit dieser Option überschrieben werden. Einen eigenen restore_command mit Vorsicht angeben, da pgBackRest dafür ausgelegt ist, dies selbst zu übernehmen. Optionen für das Recovery-Ziel wie recovery_target_name und recovery_target_time werden automatisch von pgBackRest erzeugt und sollten nicht mit dieser Option gesetzt werden.

Da pgBackRest PostgreSQL nach dem Schreiben von postgresql.auto.conf oder recovery.conf nicht startet, lassen sich postgresql.auto.conf oder recovery.conf vor einem manuellen Neustart jederzeit bearbeiten und prüfen.

example: recovery-option=primary_conninfo=db.mydomain.com

Option zur Tablespace-Zuordnung (--tablespace-map)

Einen Tablespace im angegebenen Verzeichnis wiederherstellen.

Verschiebt einen Tablespace bei der Wiederherstellung an einen neuen Speicherort. Dies ist nützlich, wenn sich die Tablespace-Pfade auf einem Replikat unterscheiden oder ein aktualisiertes System andere Einhängepunkte verwendet.

Die Speicherorte von Tablespaces werden nicht in pg_tablespace gespeichert. Deshalb können Tablespaces ohne Folgen verschoben werden. Ein Verschieben in data_directory wird jedoch nicht empfohlen und kann Probleme verursachen. Weitere hilfreiche Informationen zum Verschieben von Tablespaces bietet http://www.databasesoup.com/2013/11/moving-tablespaces.html .

example: tablespace-map=ts_01=/db/ts_01

Option zur Zuordnung aller Tablespaces (--tablespace-map-all)

Alle Tablespaces im angegebenen Verzeichnis wiederherstellen.

Tablespaces werden standardmäßig an ihren ursprünglichen Speicherorten wiederhergestellt. Dies lässt sich mit tablespace-map für jeden Tablespace ändern. Manchmal ist es jedoch sinnvoller, alle Tablespaces auf einmal einem neuen Verzeichnis zuzuordnen. Dies ist besonders für Entwicklungs- oder Staging-Systeme nützlich, deren Speicheraufteilung vom Ursprungssystem des Backups abweichen kann.

Der angegebene Pfad dient als übergeordnetes Verzeichnis, unter dem alle Tablespaces des Backups erstellt werden.

ACHTUNG:

Tablespaces, die nach Beginn des Backups erstellt wurden, werden nicht neu zugeordnet. Ist eine Tablespace-Zuordnung erforderlich, nach dem Erstellen eines Tablespaces ein neues Backup erstellen.

example: tablespace-map-all=/data/tablespace

Serveroptionen

Der Abschnitt server definiert Optionen zur Konfiguration des TLS-Servers.

Option für die TLS-Serveradresse (--tls-server-address)

TLS-Serveradresse.

IP-Adresse, an der der Server auf Client-Anfragen wartet.

default: localhost
example: tls-server-address=*

Option für berechtigte TLS-Clients (--tls-server-auth)

Für den TLS-Server berechtigte Clients.

Der Server autorisiert Clients, indem er ihr Zertifikat prüft und dessen CN (Common Name) mit einer Liste vergleicht, die auf dem Server mit der Option tls-server-auth konfiguriert ist.

Ein Client-CN kann für beliebig viele Stanzas berechtigt werden, indem der Option tls-server-auth eine durch Kommas getrennte Liste übergeben wird. Mit tls-server-auth=client-cn=* gilt die Berechtigung für alle Stanzas. Im Client-CN dürfen keine Platzhalter angegeben werden.

example: tls-server-auth=client-cn=stanza1,stanza2

Option für die Zertifizierungsstellen des TLS-Servers (--tls-server-ca-file)

Zertifizierungsstellen des TLS-Servers.

Prüft, ob Client-Zertifikate von einer vertrauenswürdigen Zertifizierungsstelle signiert sind.

example: tls-server-ca-file=/path/to/server.ca

Option für das TLS-Serverzertifikat (--tls-server-cert-file)

Datei mit dem TLS-Serverzertifikat.

Wird an den Client gesendet, um die Identität des Servers nachzuweisen.

example: tls-server-cert-file=/path/to/server.crt

Option für den TLS-Serverschlüssel (--tls-server-key-file)

Datei mit dem TLS-Serverschlüssel.

Weist nach, dass das Serverzertifikat von seinem Eigentümer gesendet wurde.

example: tls-server-key-file=/path/to/server.key

Option für den TLS-Serverport (--tls-server-port)

TLS-Serverport.

Port, an dem der Server auf Client-Anfragen wartet.

default: 8432
allowed: [1, 65535]
example: tls-server-port=8000

Stanza-Optionen

Eine Stanza definiert die Backup-Konfiguration für einen bestimmten PostgreSQL-Datenbankcluster. Der Stanza-Abschnitt muss den Pfad des Datenbankclusters sowie bei einem entfernten Cluster Host und Benutzer festlegen. Außerdem können alle globalen Konfigurationsabschnitte überschrieben werden, um Stanza-spezifische Einstellungen zu definieren.

Indizierung: Alle pg--Optionen sind indiziert, damit mehrere PostgreSQL-Hosts konfiguriert werden können. Ein einzelner Primärserver wird beispielsweise mit pg1-path, pg1-port usw. konfiguriert. Wenn ein Standby konfiguriert wird, indizieren Sie die pg--Optionen auf dem Repository-Host als pg2- (z. B. pg2-host, pg2-path usw.).

Option für die PostgreSQL-Datenbank (--pg-database)

PostgreSQL-Datenbank.

Name der Datenbank für Verbindungen zu PostgreSQL. Meist ist der Standardwert die beste Wahl, doch manche Installationen enthalten diese Datenbank möglicherweise nicht.

Aus Kompatibilitätsgründen wird die Umgebungsvariable PGDATABASE ignoriert.

default: postgres
example: pg1-database=backupdb

Option für den PostgreSQL-Host (--pg-host)

PostgreSQL-Host für die Ausführung auf einem entfernten System.

Für Backups, bei denen PostgreSQL-Host und Repository-Host unterschiedliche Systeme sind.

example: pg1-host=db.domain.com

Veralteter Name: db-host

Option für die CA-Datei des PostgreSQL-Hosts (--pg-host-ca-file)

Datei mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host eine andere als die systemweite CA-Datei verwenden.

example: pg1-host-ca-file=/etc/pki/tls/certs/ca-bundle.crt

Option für den CA-Pfad des PostgreSQL-Hosts (--pg-host-ca-path)

Pfad mit den Zertifizierungsstellen für den PostgreSQL-Host.

Für Verbindungen zum PostgreSQL-Host einen anderen als den systemweiten CA-Pfad verwenden.

example: pg1-host-ca-path=/etc/pki/tls/certs

Option für die Zertifikatdatei des PostgreSQL-Hosts (--pg-host-cert-file)

Zertifikatdatei für den PostgreSQL-Host.

Wird an den PostgreSQL-Host gesendet, um die Identität des Clients nachzuweisen.

example: pg1-host-cert-file=/path/to/client.crt

Option für den Befehl auf dem PostgreSQL-Host (--pg-host-cmd)

pgBackRest-Befehl auf dem PostgreSQL-Host.

Nur erforderlich, wenn der Pfad zum pgBackRest-Befehl auf dem lokalen und dem PostgreSQL-Host unterschiedlich ist. Ohne Angabe wird auf dem PostgreSQL-Host derselbe Befehl wie lokal verwendet.

default: [path of executed pgbackrest binary]
example: pg1-host-cmd=/usr/lib/backrest/bin/pgbackrest

Veralteter Name: db-cmd

Option für die Konfiguration des PostgreSQL-Hosts (--pg-host-config)

pgBackRest-Konfigurationsdatei auf dem Datenbank-Host.

Legt den Speicherort der Konfigurationsdatei auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn die Datei dort an einem anderen Ort liegt als die lokale Konfigurationsdatei.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_FILE
example: pg1-host-config=/conf/pgbackrest/pgbackrest.conf

Veralteter Name: db-config

Option für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host (--pg-host-config-include-path)

Pfad zu zusätzlichen pgBackRest-Konfigurationsdateien auf dem Datenbank-Host.

Legt den Pfad für zusätzliche Konfigurationsdateien auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom entsprechenden lokalen Pfad abweicht.

default: CFGOPTDEF_CONFIG_PATH "/" PROJECT_CONFIG_INCLUDE_PATH
example: pg1-host-config-include-path=/conf/pgbackrest/conf.d

Option für den Konfigurationspfad des PostgreSQL-Hosts (--pg-host-config-path)

pgBackRest-Konfigurationspfad auf dem Datenbank-Host.

Legt den Konfigurationspfad auf dem PostgreSQL-Host fest. Dies ist nur erforderlich, wenn dieser Pfad auf dem PostgreSQL-Host vom lokalen Konfigurationspfad abweicht.

default: CFGOPTDEF_CONFIG_PATH
example: pg1-host-config-path=/conf/pgbackrest

Option für die Schlüsseldatei des PostgreSQL-Hosts (--pg-host-key-file)

Schlüsseldatei für den PostgreSQL-Host.

Weist nach, dass das Client-Zertifikat von seinem Eigentümer gesendet wurde.

example: pg1-host-key-file=/path/to/client.key

Option für den Port des PostgreSQL-Hosts (--pg-host-port)

Port des PostgreSQL-Hosts, wenn pg-host gesetzt ist.

Mit dieser Option einen anderen als den Standardport für das Protokoll des PostgreSQL-Hosts angeben.

HINWEIS:

Bei pg-host-type=ssh gibt es keinen Standardwert für pg-host-port. In diesem Fall wird der Port verwendet, der für den durch cmd-ssh angegebenen Befehl konfiguriert ist.

default (depending on pg-host-type):
    tls - 8432

allowed: [0, 65535]
example: pg1-host-port=25

Veralteter Name: db-ssh-port

Option für den Protokolltyp des PostgreSQL-Hosts (--pg-host-type)

Protokolltyp für den PostgreSQL-Host.

Die folgenden Protokolltypen werden unterstützt:

  • ssh - Secure Shell.
  • tls - pgBackRest-TLS-Server.
default: ssh
example: pg1-host-type=tls

Option für den Benutzer auf dem PostgreSQL-Host (--pg-host-user)

Anmeldebenutzer auf dem PostgreSQL-Host, wenn pg-host gesetzt ist.

Unter diesem Benutzer läuft auch der entfernte pgBackRest-Prozess, und er baut die Verbindungen zu PostgreSQL auf. Damit dies korrekt funktioniert, sollte er Eigentümer des PostgreSQL-Datenbankclusters sein. Üblicherweise ist dies postgres, der Standardwert.

default: postgres
example: pg1-host-user=db_owner

Veralteter Name: db-user

Option für den PostgreSQL-Pfad (--pg-path)

PostgreSQL-Datenverzeichnis.

Dieser Pfad sollte dem von PostgreSQL gemeldeten data_directory entsprechen. Obwohl sich der Wert an verschiedenen Stellen auslesen lässt, ist eine ausdrückliche Angabe ratsam, falls diese Quellen bei einer Wiederherstellung oder einem Offline-Backup nicht verfügbar sind.

Bei jedem Online-Backup wird pg-path mit dem von PostgreSQL gemeldeten Wert verglichen. Die Option sollte daher immer aktuell sein.

example: pg1-path=/data/db

Veralteter Name: db-path

Option für den PostgreSQL-Port (--pg-port)

PostgreSQL-Port.

Port, auf dem PostgreSQL läuft. Dieser muss normalerweise nicht angegeben werden, da die meisten PostgreSQL-Cluster den Standardport verwenden.

default: 5432
allowed: [0, 65535]
example: pg1-port=6543

Veralteter Name: db-port

Option für den PostgreSQL-Socket-Pfad (--pg-socket-path)

Pfad zum PostgreSQL-Unix-Socket.

Das beim Start von PostgreSQL angegebene Unix-Socket-Verzeichnis. pgBackRest sucht automatisch am üblichen Speicherort des Betriebssystems. Diese Einstellung ist daher normalerweise nur erforderlich, wenn das Socket-Verzeichnis ausdrücklich über unix_socket_directories in postgresql.conf geändert wurde.

example: pg1-socket-path=/var/run/postgresql

Veralteter Name: db-socket-path

Option für den PostgreSQL-Datenbankbenutzer (--pg-user)

PostgreSQL-Datenbankbenutzer.

Datenbankbenutzername für Verbindungen zu PostgreSQL. Ohne Angabe verbindet sich pgBackRest mit dem lokalen Betriebssystembenutzer oder mit PGUSER.

example: pg1-user=backupuser

6 - Versionshinweise

Versionsgeschichte von pgBackRest mit ausführlichem Änderungsprotokoll für jede Version.

Einleitung

pgBackRest-Versionsnummern bestehen aus zwei Teilen: Haupt- und Nebenversion. Eine Hauptversion kann die Kompatibilität mit der vorherigen Hauptversion aufheben. Die Versionen der Reihe v2 sind jedoch vollständig mit v1-Repositorys kompatibel und akzeptieren alle v1-Optionen. Nebenversionen können Fehlerbehebungen und neue Funktionen enthalten, ändern aber das Repository-Format nicht und vermeiden nach Möglichkeit Änderungen an Optionen und Benennungen. Die Dokumentation für v1 ist hier verfügbar. Die Versionshinweise können auch „Zusätzliche Hinweise“ enthalten. Änderungen in diesem Abschnitt betreffen jedoch ausschließlich die Dokumentation oder die Testsuite und haben keine direkten Auswirkungen auf die Codebasis von pgBackRest.

Dokumentierte stabile Version

Diese Spiegelung dokumentiert v2.59.3. Neuere Versionen sind in der Versionsgeschichte des Originalprojekts aufgeführt.

v2.59.3 – Versionshinweise

Fehler bei der Erzeugung von Verschlüsselungsunterschlüsseln

Veröffentlicht am 4. Oktober 2026

WICHTIGER HINWEIS: In früheren Versionen konnten bei einem Fehler beim Zugriff auf die Zufallsdaten des Systems schwache Verschlüsselungsunterschlüssel und Salts erzeugt werden. Weitere Informationen finden Sie unter Schwache Unterschlüssel und Salts bei der Verschlüsselung .

Fehlerbehebungen:

  • Möglichen Prüfsummenfehler beim Laden verschlüsselter Informationsdateien und Manifeste behoben. (Behoben von j0uinim. Geprüft von David Steele.)
  • Mögliche Erzeugung schwacher Verschlüsselungsunterschlüssel oder Salts behoben. (Behoben von j0uinim. Geprüft von David Steele, Stefan Fercot, Douglas J Hunley.)

Stabile Versionen

v2.59.2 – Versionshinweise

Unterstützung für PostgreSQL 19beta4

Veröffentlicht am 27. September 2026

Fehlerbehebungen:

  • Fehler bei einer leeren Blockzuordnung behoben, wenn eine Datei während des Backups auf die Länge null gekürzt wird. (Geprüft von Douglas J Hunley. Gemeldet von JPCOSTA78.)
  • Wiederholungen von Lesevorgängen deaktiviert, wenn Filter an den Treiber übergeben werden. (Geprüft von Douglas J Hunley. Gemeldet von megamaced.)
  • Seitenweises Auflisten von S3-Versionen korrigiert. (Geprüft von Douglas J Hunley, guruguruguru. Gemeldet von guruguruguru.)
  • Azure-Versionsheader für die SAS-Authentifizierung gesetzt. (Geprüft von Douglas J Hunley. Gemeldet von Florian Helmberger.)
  • Hängenbleiben des asynchronen archive-push an einer Backup-Historiendatei mit der Größe null behoben. (Behoben von Andrew Kroh. Geprüft von David Steele, Douglas J Hunley.)
  • Befehl annotate auf einem entfernten verschlüsselten Repository korrigiert. (Behoben von Douglas J Hunley. Geprüft von David Steele.)

Funktionen:

  • Unterstützung für PostgreSQL 19beta4.

v2.59.1 – Versionshinweise

Unterstützung für PostgreSQL 19beta3

Veröffentlicht am 17. August 2026

Fehlerbehebungen:

  • Hängenbleiben behoben, wenn der Chunk-Puffer kleiner als der Eingabepuffer ist. (Geprüft von Andrew Pogrebnoi, Douglas J Hunley. Gemeldet von crajac66.)
  • Neue Backup-Kennzeichnung nur mit ihrem eigenen vollständigen Backup-Satz verglichen. (Geprüft von Douglas J Hunley. Gemeldet von Anton Glushakov.)
  • Von GitHub erzeugte Quellcodearchive korrigiert, in denen für den Build erforderliche Dateien fehlten. (Gemeldet von aardvarkzed.)

Funktionen:

  • Unterstützung für PostgreSQL 19beta3. (Beigetragen von Lardière Sébastien. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • Ausnahme für Punkte in S3-Bucket-Namen bei repo-s3-uri-style=path dokumentiert.
  • Explizite Konfiguration von hot_standby aus dem Benutzerhandbuch entfernt.

v2.59.0 – Versionshinweise

Unterstützung für PostgreSQL 19beta2

Veröffentlicht am 20. Juli 2026

HINWEIS FÜR PAKETBETREUER: Ein neuer Distributions-Tarball vereinfacht den Build, indem er vorgenerierte HTML-Dokumentation, eine Manpage und Code bereitstellt. Der Tarball ist jeder Veröffentlichung als Datei mit dem Namen pgbackrest-{version}.tar.gz beigefügt. Einzelheiten stehen in der README.md im Tarball. Bitte verwenden Sie den neuen Distributions-Tarball, um die zusätzlichen Build-Werkzeuge zu vermeiden, die in künftigen Versionen zur Codegenerierung erforderlich sein werden. Weitere Informationen stehen unter Neuer Distributions-Tarball . HINWEIS FÜR PAKETBETREUER: Es gibt eine neue optionale Abhängigkeit von libsystemd. WICHTIGER HINWEIS: Ab dieser Version darf standardmäßig nur der Befehl restore als root ausgeführt werden. Mit allow-root können andere Befehle als root ausgeführt werden (dies wird jedoch nicht empfohlen).

Fehlerbehebungen:

  • Fehler behoben, durch den expire ein auf einem anderen Host laufendes Backup entfernte. (Geprüft von Douglas J Hunley. Gemeldet von Dmitrii.)
  • Fehler behoben, durch den archive-push-queue-max bei einem Fehler einer WAL-Datei nicht durchgesetzt wurde. (Geprüft von Stefan Fercot. Gemeldet von vut12.)
  • Fehler beim asynchronen archive-get während einer Recovery über einen Timeline-Wechsel hinweg behoben. (Geprüft von Douglas J Hunley. Gemeldet von Jimmy Yih.)
  • Möglichen Pufferüberlauf im Fehlermodul behoben. (Behoben von Christophe Pettus. Geprüft von David Steele.)
  • Zugriff auf bereits freigegebenen Speicher im parallelen Protokollclient behoben. (Geprüft von Douglas J Hunley. Gemeldet von Georgy Shelkovy.)
  • Heap-Überlauf behoben, wenn eine pg-Option ohne pg1 gesetzt wird. (Geprüft von Douglas J Hunley. Gemeldet von Naveen.)

Funktionen:

  • Unterstützung für PostgreSQL 19beta2. (Geprüft von Stefan Fercot.)
  • Option archive-expire-before zum Bereinigen des WAL-Archivs hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)
  • Stapellöschung für Azure-Speicher hinzugefügt. (Geprüft von Douglas J Hunley, Crispy.)
  • Unterstützung für S3 Outposts hinzugefügt. (Beigetragen von Shiva Kumar Ambigi. Geprüft von David Steele, Roberto Mello.)
  • S3-Prozessauthentifizierung hinzugefügt. (Geprüft von Andrew Charlton. Vorgeschlagen von Andrew Charlton.)

Verbesserungen:

  • Erneuter Verbindungsaufbau zum SFTP-Speicher, nachdem der Server eine inaktive Verbindung getrennt hat. (Geprüft von Stefan Fercot. Vorgeschlagen von mustafa0x, tisserat.)
  • Zwischenspeicherung von Benutzern und Gruppen für eine schnellere Erstellung des Manifests hinzugefügt. (Beigetragen von Gunnar Lindholm. Geprüft von David Steele.)
  • Backup-Fortschritt je Repository zur Ausgabe des Befehls info hinzugefügt. (Beigetragen von Will Morland. Geprüft von David Steele, Stefan Fercot.)
  • Prüfungen von backup.info zum Befehl verify hinzugefügt. (Beigetragen von Denis Garsh. Geprüft von David Steele, Douglas J Hunley.)
  • Konfiguration des S3-STS-Endpunkts ermöglicht. (Beigetragen von Simon Gratton. Geprüft von David Steele.)
  • archive-push-batch-size hinzugefügt, um die pro asynchronem Durchlauf übertragene WAL-Menge zu begrenzen. (Geprüft von Stefan Fercot.)
  • Asynchrones archive-push beim ersten Fehler beendet. (Geprüft von Stefan Fercot. Vorgeschlagen von Lardière Sébastien.)
  • Verarbeitung von HTTP-Antworten mit Chunked-Übertragung robuster gestaltet. (Beigetragen von Shubham. Geprüft von David Steele.)
  • Fehler bei Ausführung als root, sofern allow-root nicht aktiviert ist. (Geprüft von Douglas J Hunley.)
  • Anzahl binärer Suchen beim Erstellen des Manifests reduziert. (Beigetragen von Gunnar Lindholm. Geprüft von David Steele.)
  • Leistung bei der Positionierung innerhalb von Dateien während blockinkrementeller Delta-Wiederherstellungen verbessert. (Geprüft von David Christensen, Douglas J Hunley.)
  • Backup-Dateien der Reihe nach gebündelt, anstatt nach einer besser passenden Datei zu suchen. (Geprüft von Stefan Fercot.)
  • Zugrunde liegenden Fehler gemeldet, wenn eine Abfrage nicht abgeschlossen werden kann. (Geprüft von Andrew Pogrebnoi. Vorgeschlagen von Marco Fontana.)
  • Tatsächlichen Fehler gemeldet, wenn eine Anfrage nach S3-Zugangsdaten fehlschlägt. (Geprüft von Douglas J Hunley. Vorgeschlagen von Mitchell Grice.)
  • Fehler des Spool-Pfads von archive-push im PostgreSQL-Protokoll gemeldet. (Geprüft von Douglas J Hunley. Vorgeschlagen von Don Seiler.)
  • Bei einer nicht unterstützten Version auf ein möglicherweise veraltetes pgBackRest hingewiesen.
  • Integration von systemd-Benachrichtigungen hinzugefügt. (Beigetragen von Andrew Jackson. Geprüft von David Steele.)
  • Fehler unused parameter in meson-Compilerprüfungen unterdrückt. (Beigetragen von Jörg Plate. Geprüft von David Steele.)
  • C11 ist nun der mindestens erforderliche C-Standard. (Geprüft von Mohammad Ali Nazir Kosar.)

Verbesserungen der Dokumentation:

  • Option stanza für die Befehle repo-* als intern gekennzeichnet. (Geprüft von Stefan Fercot.)
  • Dokumentiert, dass info die Verschlüsselungseinstellungen aus dem globalen Abschnitt liest. (Geprüft von Stefan Fercot. Vorgeschlagen von Ron Johnson.)
  • Dokumentiert, dass expire-auto die Konfiguration des Befehls backup verwendet. (Geprüft von Stefan Fercot. Vorgeschlagen von Lardière Sébastien.)
  • Anpassung der logrotate-Direktive su für einen eigenen Benutzer dokumentiert. (Geprüft von Douglas J Hunley. Vorgeschlagen von lkanbus.)
  • Dokumentiert, dass Kommentare am Zeilenende in Konfigurationsdateien nicht unterstützt werden. (Geprüft von Douglas J Hunley. Vorgeschlagen von Alex Richman.)

Verbesserungen der Testsuite:

  • Gruppenkonflikte von Alpine in CI-Containern behoben. (Beigetragen von Artur Zakirov. Geprüft von David Steele.)

v2.58.0 – Versionshinweise

Verbesserungen für Objektspeicher

Veröffentlicht am 19. Januar 2026

WICHTIGER HINWEIS: Die Mindestwerte der Option repo-storage-upload-chunk-size wurden erhöht. Sie entsprechen nun den von den Anbietern zugelassenen Mindestwerten.

Fehlerbehebungen:

  • Deadlock durch Protokollierung im Signalhandler behoben. (Behoben von Maxim Michkov. Geprüft von David Steele.)

Funktionen:

  • HTTP-Unterstützung für S3, GCS und Azure. (Beigetragen von Will Morland. Geprüft von David Steele.)
  • Entfernen des ältesten vollständigen Backups unabhängig von der aktuellen Aufbewahrung ermöglicht. (Beigetragen von Stefan Fercot. Geprüft von David Steele. Vorgeschlagen von Ron Johnson.)
  • Unterstützung für verwaltete Identitäten von Azure. (Beigetragen von Moiz Ibrar, Matthew Mols. Geprüft von David Steele.)
  • Experimentelle Unterstützung für S3 EKS Pod Identity. (Beigetragen von Pierre BOUTELOUP. Geprüft von David Steele.)
  • Konfiguration von TLS-Cipher-Suites ermöglicht. (Beigetragen von Gunnar “Nick” Bluth. Geprüft von David Steele.)
  • Festlegen der Prozesspriorität ermöglicht. (Geprüft von Douglas J Hunley.)

Verbesserungen:

  • Punkte in S3-Bucket-Namen bei Verwendung pfadbasierter URIs zugelassen. (Beigetragen von Joakim Hindersson. Geprüft von David Steele.)
  • TLS >= 1.2 verlangt, sofern die Überprüfung nicht deaktiviert ist. (Geprüft von Douglas J Hunley, Gunnar “Nick” Bluth.)
  • Größe von S3/GCS/Azure-Chunks bei großen Uploads dynamisch angepasst. (Geprüft von Douglas J Hunley. Vorgeschlagen von Timothée Peignier.)
  • S3/GCS/Azure-Chunk-Größe für kleine Dateien optimiert. (Geprüft von Douglas J Hunley.)
  • Unterstützung für PostgreSQL 9.5 entfernt. (Geprüft von Douglas J Hunley.)
  • Protokollierung des Standardwerts für Optionen mit einer nicht aufgelösten Abhängigkeit verbessert. (Geprüft von Stefan Fercot.)

Verbesserungen der Dokumentation:

  • Explizite Konfiguration von max_wal_senders/wal_level aus dem Benutzerhandbuch entfernt. (Vorgeschlagen von Jamie Nguyen.)
  • Klargestellt, dass Bündelung bei Dateisystemen mit großen Blockgrößen nützlich ist. (Vorgeschlagen von Ron Johnson.)

v2.57.0 – Versionshinweise

Symbolische Links im Repository unterdrücken

Veröffentlicht am 18. Oktober 2025

Fehlerbehebungen:

  • Verschachtelung der Zeitüberschreitungen für HTTP/TLS/Sockets aufgehoben. (Geprüft von David Christensen.)
  • Möglichen Segfault in der Fehlermeldung zu Seitenprüfsummen behoben. (Behoben von Zsolt Parragi. Geprüft von David Steele.)

Funktionen:

  • Option repo-symlink hinzugefügt, um die Erstellung symbolischer Links im Repository zu unterdrücken. (Geprüft von Douglas J Hunley. Vorgeschlagen von Ron Johnson.)

Verbesserungen:

  • HTTP-Wiederholungsversuche für die Fehler 408 und 429 hinzugefügt. (Geprüft von David Christensen.)

v2.56.0 – Versionshinweise

Verbesserte Fortschrittsinformationen

Veröffentlicht am 21. Juli 2025

Fehlerbehebungen:

  • Problem beim gezielten Entfernen von Backups behoben, wenn das Repository keine Backups enthält. (Geprüft von Stefan Fercot. Gemeldet von Anup Gupta.)

Funktionen:

  • Wiederherstellungsfortschritt zur Ausgabe des Befehls info hinzugefügt. (Beigetragen von Denis Garsh, Maxim Michkov. Geprüft von David Steele.)
  • Detailstufe für die Ausgabe des Befehls info hinzugefügt, die nur den Fortschritt anzeigt. (Beigetragen von Denis Garsh. Geprüft von David Steele, Stefan Fercot.)

Verbesserungen:

  • Fehlgeschlagene Lesevorgänge auf Objektspeichern wiederholt. (Geprüft von David Christensen.)
  • Standardwerte in der Befehlszeilenhilfe korrigiert. (Geprüft von David Christensen, Chris Bandy.)

Verbesserungen der Dokumentation:

  • Diskrete Optionswerte gegebenenfalls als Liste beschrieben. (Beigetragen von Anton Kurochkin. Geprüft von David Steele.)
  • “less than” in der Hilfeausgabe für die Option archive-mode korrigiert. (Beigetragen von Anton Kurochkin. Geprüft von David Steele.)

v2.55.1 – Versionshinweise

Fehlerbehebungen

Veröffentlicht am 5. Mai 2025

Fehlerbehebungen:

  • Änderung „content-md5 auf S3 nur bei Bedarf berechnen“ zurückgenommen. (Geprüft von David Christensen. Gemeldet von Frank Brendel.)
  • Prüfung der unteren Grenzen für Optionsschlüssel korrigiert. (Geprüft von David Christensen, Wolfgang Walther. Gemeldet von Wolfgang Walther.)

v2.55.0 – Versionshinweise

Verbesserte Überprüfung und Unterstützung für PostgreSQL 18

Veröffentlicht am 21. April 2025

Fehlerbehebungen:

  • Problem bei der blockinkrementellen Wiederherstellung aus einem nicht als Standard verwendeten Repository behoben. (Geprüft von David Christensen, Aleksander Łukasz. Gemeldet von Aleksander Łukasz.)
  • recovery_target_timeline=current für PostgreSQL < 12 nicht gesetzt. (Geprüft von Stefan Fercot.)
  • Protokollierung des Archivbereichs beim Entfernen abgelaufener Daten korrigiert. (Geprüft von Stefan Fercot. Gemeldet von Aleš Zelený.)
  • Fehlermeldungen für Abfragen ohne Ergebnisse korrigiert. (Geprüft von Stefan Fercot. Gemeldet von Susantha Bathige.)

Funktionen:

  • Ziel-Timeline der Recovery überprüft. (Geprüft von Stefan Fercot.)
  • Überprüfung eines angegebenen Backups ermöglicht. (Beigetragen von Maxim Michkov. Geprüft von David Steele.)
  • Unterstützung für S3/GCS mit Kostenübernahme durch den Anforderer hinzugefügt. (Beigetragen von Timothée Peignier. Geprüft von David Steele.)
  • Unterstützung für PostgreSQL 18. (Geprüft von Stefan Fercot.)
  • Verbindungen zu PostgreSQL über abstrakte Domain-Sockets ermöglicht. (Geprüft von Chris Bandy. Vorgeschlagen von Chris Bandy.)
  • Numerische Ausgabe zum Befehl version hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)

Verbesserungen:

  • Ausführung des Backup-Befehls auf entfernten Repositorys ermöglicht. (Geprüft von Stefan Fercot.)
  • lz4 für die Protokollkomprimierung verwendet. (Geprüft von Stefan Fercot.)
  • content-md5 auf S3 nur bei Bedarf berechnet. (Geprüft von David Christensen.)
  • Warnung ausgegeben, wenn ein Wert einer Option mit mehreren Schlüsseln überschrieben wird. (Geprüft von David Christensen, Stefan Fercot.)
  • Detaillierte Protokollierung beim Entfernen abgelaufener Archivpfade hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)
  • Unterstützung für PostgreSQL 9.4 entfernt. (Geprüft von Stefan Fercot.)
  • Build mit autoconf/make entfernt. (Geprüft von David Christensen.)

Verbesserungen der Dokumentation:

  • Dokumentation zur Angabe mehrerer Stanzas mit tls-server-auth korrigiert. (Geprüft von David Christensen, Stefan Fercot. Vorgeschlagen von Terry MacAndrew.)
  • Entfernen abgelaufener inkrementeller Backups erläutert. (Geprüft von Stefan Fercot.)
  • Anforderung erläutert, dass die lokale und entfernte pgBackRest-Version übereinstimmen müssen. (Beigetragen von Greg Clough. Geprüft von David Steele.)
  • FAQ zum Export eines eigenständigen Clusters hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)
  • Einschränkung von --tablespace-map-all bei der Erstellung von Tablespaces erläutert. (Geprüft von Stefan Fercot, Christophe Courtois. Vorgeschlagen von Christophe Courtois.)
  • Verhalten von --repo-retention-full-type erläutert. (Geprüft von Antoine Beaupré. Vorgeschlagen von Antoine Beaupré.)
  • Empfehlung für Objektspeicher von --process-max auf --repo-bundle geändert. (Geprüft von Stefan Fercot.)
  • unix_socket_directory durch unix_socket_directories ersetzt. (Beigetragen von hyunkyu han. Geprüft von David Steele.)
  • Empfohlen, spool-path nicht innerhalb von pg_xlog/pg_wal abzulegen. (Geprüft von Martín Marqués, Don Seiler. Vorgeschlagen von Martín Marqués.)

v2.54.2 – Versionshinweise

Fehlerbehebung

Veröffentlicht am 20. Januar 2025

Fehlerbehebungen:

  • Problem nach dem Deaktivieren der Bündelung bei aktivierter blockinkrementeller Verarbeitung behoben. (Geprüft von David Christensen.)

Verbesserungen der Dokumentation:

  • Verhalten bei mehreren Konfigurationsdateien erläutert. (Geprüft von Paul Bierly. Vorgeschlagen von Paul Bierly.)

v2.54.1 – Versionshinweise

Fehlerbehebung

Veröffentlicht am 16. Dezember 2024

Fehlerbehebungen:

  • Problem behoben, bei dem die Befehle version/help versuchten, pgbackrest.conf zu laden. (Geprüft von Stefan Fercot. Gemeldet von Bradford Boyle, Julian.)

Verbesserungen der Testsuite:

  • Asynchrone Archivierung in Integrationstests stabilisiert. (Beigetragen von Viktor Kurilko. Geprüft von David Steele.)

v2.54.0 – Versionshinweise

Zielzeitpunkt für versionierten Speicher

Veröffentlicht am 21. Oktober 2024

HINWEIS FÜR PAKETBETREUER: Dies ist die letzte Version mit neuen Funktionen, die den Build mit autoconf/make unterstützt. Bitte wechseln Sie zu meson, falls noch nicht geschehen. Patch-Versionen von 2.54.X werden, sofern es welche gibt, weiterhin autoconf/make unterstützen.

Fehlerbehebungen:

  • Leistungsproblem bei PostgreSQL-Abfragen mit großen Datenmengen behoben. (Behoben von Thibault Vincent, David Steele. Geprüft von David Christensen, Antoine Millet. Gemeldet von Antoine Millet.)

Funktionen:

  • Lesen von Repositorys auf versioniertem Speicher zu einem Zielzeitpunkt ermöglicht. (Geprüft von Stefan Fercot, David Christensen.)
  • Angefordertes Backup vom Standby auch ohne verfügbaren Standby ermöglicht. (Geprüft von Stefan Fercot.)

Verbesserungen:

  • Liste der Backup-Referenzen für die Textausgabe des Befehls info zusammengefasst. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)
  • web-id-Token bei jeder S3-Authentifizierung erneuert. (Beigetragen von Brent Graveland. Geprüft von David Steele.)
  • Aktuelle Werte indizierter Optionen in der Hilfe korrekt angezeigt. (Geprüft von David Christensen.)
  • backup.info nur bei geändertem Inhalt gespeichert. (Geprüft von Stefan Fercot.)
  • Einschränkung beim parallelen Lesen von Dateien während der Wiederherstellung entfernt. (Geprüft von David Christensen.)
  • SFTP-Fehlermeldungen verbessert. (Beigetragen von Reid Thompson. Geprüft von David Steele.)

Neue Inhalte der Dokumentation:

  • Abschnitt zur Leistungsoptimierung zum Benutzerhandbuch hinzugefügt. (Geprüft von Stefan Fercot.)

Verbesserungen der Dokumentation:

  • Quelle für data_directory erläutert. (Beigetragen von Stefan Fercot. Geprüft von David Steele. Vorgeschlagen von Matthias.)
  • Logik verbessert, die entscheidet, wann eine Zusammenfassung kleingeschrieben werden sollte. (Vorgeschlagen von Daniel Westermann.)

v2.53.1 – Versionshinweise

Unterstützung für PostgreSQL 17

Veröffentlicht am 19. August 2024

Fehlerbehebungen:

  • Berechtigungen bei der Ausführung von restore als root korrigiert. (Geprüft von Stefan Fercot. Gemeldet von Will M.)
  • Segfault bei verzögerten Verbindungsfehlern behoben. (Geprüft von David Christensen. Gemeldet von Anton Glushakov.)
  • Prüfung auf doppelte lokale Repositorys für SFTP übersprungen. (Behoben von Reid Thompson. Geprüft von David Steele. Gemeldet von Anton Kurochkin.)

Verbesserungen:

  • Unterstützung für PostgreSQL 17.

v2.53 – Versionshinweise

Gleichzeitige Backups

Veröffentlicht am 22. Juli 2024

WICHTIGER HINWEIS: Der Standardwert der Option log-level-stderr wurde von warn auf off geändert. Dies erleichtert das Erfassen von Fehlern, wenn nur stdout umgeleitet wird. Um das bisherige Verhalten beizubehalten, setzen Sie log-level-stderr=warn. HINWEIS FÜR PAKETBETREUER: Der meson-Build benötigt nun die lz4-Bibliothek. HINWEIS FÜR PAKETBETREUER: Der meson-Build benötigt nun Compiler-Unterstützung für __builtin_clzl() und __builtin_bswap64().

Fehlerbehebungen:

  • Fehler beim Umbenennen über SFTP behoben, wenn die Datei bereits existiert. (Behoben von Reid Thompson. Geprüft von David Steele. Gemeldet von ahmed112212.)

Funktionen:

  • Gleichzeitige Backups auf unterschiedlichen Repositorys ermöglicht. (Geprüft von Reid Thompson, Stefan Fercot.)
  • Unterstützung für IP-basierte SANs bei der Validierung von TLS-Zertifikaten. (Beigetragen von David Christensen. Geprüft von David Steele.)

Verbesserungen:

  • Standardwert der Option log-level-stderr auf off gesetzt. (Geprüft von Greg Sabino Mullane, Stefan Fercot.)
  • Alternative WAL-Segmentgrößen für PostgreSQL ≤ 10 ermöglicht. (Beigetragen von Viktor Kurilko. Geprüft von David Steele.)
  • Hinweis zur Prüfung des SFTP-Autorisierungsprotokolls hinzugefügt. (Beigetragen von Vitalii Zurian. Geprüft von Reid Thompson, David Steele.)

Verbesserungen der Dokumentation:

  • Verhalten von archive-push bei mehreren Repositorys erläutert. (Geprüft von Stefan Fercot.)

v2.52.1 – Versionshinweise

Fehlerbehebung

Veröffentlicht am 25. Juni 2024

Fehlerbehebungen:

  • Problem bei Dateien behoben, die auf dem Replikat größer sind als auf dem Primärserver. (Geprüft von Stefan Fercot. Gemeldet von Nicolas Lassimonne.)

v2.52 – Versionshinweise

Unterstützung für PostgreSQL 17beta1

Veröffentlicht am 27. Mai 2024

HINWEIS FÜR PAKETBETREUER: Das Build-System von pgBackRest ist nun meson. Der Build mit autoconf/make erhält keine neuen Funktionen mehr und wird nach einigen Versionen entfernt.

Funktionen:

  • Unterstützung für GCS-Stapellöschung hinzugefügt. (Geprüft von Reid Thompson.)
  • Unterstützung für S3-Verschlüsselung mit SSE-C. (Geprüft von Tim Jones. Vorgeschlagen von Tim Jones.)
  • Unterstützung für PostgreSQL 17beta1. (Geprüft von Stefan Fercot.)

Verbesserungen:

  • Explizites Deaktivieren optionaler Abhängigkeiten bei meson-Builds ermöglicht. (Beigetragen von Michael Schout. Geprüft von David Steele.)
  • python beim meson-Build dynamisch gesucht. (Beigetragen von Michael Schout. Geprüft von David Steele.)
  • Build-Ziel pgbackrest in meson als installierbar gekennzeichnet. (Beigetragen von Bradford Boyle. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • Dokumentation zu start/stop an die tatsächliche Funktionalität angepasst. (Geprüft von Stefan Fercot.)

v2.51 – Versionshinweise

Build-System Meson

Veröffentlicht am 25. März 2024

Fehlerbehebungen:

  • Dateien mit der Länge null bei blockinkrementellen Delta-Wiederherstellungen übersprungen. (Geprüft von Sebastian Krause, René Højbjerg Larsen. Gemeldet von Sebastian Krause.)
  • Leistungsregression beim Auflisten des Speichers behoben. (Geprüft von Stephen Frost. Gemeldet von Maksym Boguk.)
  • Fortschrittsprotokollierung korrigiert, wenn sich die Dateigröße während des Backups ändert. (Geprüft von Stephen Frost. Gemeldet von samkingno.)

Verbesserungen:

  • Unterstützung für Dual-Stack-Verbindungen verbessert. (Geprüft von Stephen Frost. Vorgeschlagen von Timothée Peignier.)
  • meson zum primären Build-System gemacht. (Geprüft von Stephen Frost.)
  • Unveränderte Dateien bei inkrementellen Backups ohne Delta erkannt. (Geprüft von Stephen Frost.)
  • Ungültige Recovery bei entferntem backup_label verhindert. (Geprüft von Stephen Frost.)
  • Verarbeitung der WAL-Segmentwarteschlange von archive-push verbessert. (Geprüft von Stephen Frost.)
  • Fortsetzen von Backups auf vollständige Backups beschränkt. (Geprüft von Stephen Frost, Stefan Fercot.)
  • Fortsetzungsfunktion für blockinkrementelle Backups aktualisiert. (Geprüft von Stephen Frost.)
  • --version und --help für Version und Hilfe zugelassen. (Geprüft von Greg Sabino Mullane. Vorgeschlagen von Greg Sabino Mullane.)
  • Detaillierten Backtrace zum Build mit autoconf/make hinzugefügt. (Geprüft von Stephen Frost.)

Verbesserungen der Dokumentation:

  • Verweise auf recovery.conf aktualisiert. (Geprüft von Stefan Fercot. Vorgeschlagen von Stephen Frost.)

v2.50 – Versionshinweise

Leistungsverbesserungen und Fehlerbehebungen

Veröffentlicht am 22. Januar 2024

Fehlerbehebungen:

  • Unvollständigen Lesevorgang bei blockinkrementellen Wiederherstellungen korrigiert. (Geprüft von Stephen Frost, Brent Graveland. Gemeldet von Adol Rodriguez, Brent Graveland.)
  • Überlauf behoben, der den Backup-Fortschritt in der Ausgabe von info unterdrückte. (Behoben von Robert Donovan. Geprüft von Joe Wildish.)

Verbesserungen:

  • Unvollständige Dateien bei blockinkrementellen Delta-Wiederherstellungen beibehalten. (Geprüft von Stephen Frost.)
  • Unterstützung für alternative, beim Kompilieren festgelegte Seitengrößen hinzugefügt. (Beigetragen von Viktor Kurilko. Geprüft von David Steele.)
  • Beim Bündeln Dateien übersprungen, die während des Backups gekürzt wurden. (Beigetragen von Georgy Shelkovy. Geprüft von David Steele.)
  • Fehlermeldungen des SFTP-Speichers verbessert. (Beigetragen von Reid Thompson. Geprüft von David Steele.)

v2.49 – Versionshinweise

Unterstützung für PostgreSQL 9.3 entfernt

Veröffentlicht am 27. November 2023

Fehlerbehebungen:

  • Regression bei Wiederholungsversuchen behoben. (Geprüft von Stephen Frost. Gemeldet von Norman Adkins, Tanel Suurhans, Jordan English, Timothée Peignier.)
  • Rekursives Entfernen von Pfaden im SFTP-Speichertreiber korrigiert. (Behoben von Reid Thompson. Geprüft von Stephen Frost. Gemeldet von Luc.)

Verbesserungen:

  • Unterstützung für PostgreSQL 9.3 entfernt. (Geprüft von Stephen Frost.)

Neue Inhalte der Dokumentation:

  • Optionen für Projektbetreuer dokumentiert. (Geprüft von Stefan Fercot.)
  • Dokumentation zur Point-in-Time-Recovery für PostgreSQL >= 13 aktualisiert.

Verbesserungen der Testsuite:

  • Ausführung des Unittests config/load ohne installiertes libssh2 ermöglicht. (Beigetragen von Reid Thompson. Geprüft von David Steele. Vorgeschlagen von Wu Ning.)

v2.48 – Versionshinweise

Tags für den Repository-Speicher

Veröffentlicht am 25. September 2023

Fehlerbehebungen:

  • Problem bei der blockinkrementellen Wiederherstellung ohne Blockliste behoben. (Geprüft von Stephen Frost, Burak Yurdakul. Gemeldet von Burak Yurdakul.)

Funktionen:

  • Option --repo-storage-tag zum Erstellen von Objekt-Tags hinzugefügt. (Geprüft von Stephen Frost, Stefan Fercot, Timothée Peignier.)
  • Prüfung bekannter Hosts zum SFTP-Speichertreiber hinzugefügt. (Beigetragen von Reid Thompson. Geprüft von Stephen Frost, David Steele.)
  • Unterstützung für Dual-Stack-Verbindungen. (Geprüft von Stephen Frost.)
  • Bereits verarbeitete und gesamte Backup-Größe zur JSON-Ausgabe des Befehls info hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)

Verbesserungen:

  • check-Befehl für mehrere Stanzas. (Geprüft von Stephen Frost.)
  • Lesen von pg_control wiederholt, bis die Prüfsumme gültig ist. (Geprüft von Stefan Fercot, Stephen Frost.)
  • Prüfung der WAL-Segmente nach erfolgreichem Backup optimiert. (Geprüft von Stephen Frost.)
  • Leistung mehrteiliger Übertragungen bei GCS verbessert. (Geprüft von Reid Thompson.)
  • Ausführung des Befehls archive-get bei gestoppter Stanza ermöglicht. (Geprüft von Tom Swartz, David Christensen, Reid Thompson.)
  • Führende Tilde in Pfaden für öffentliche/private SFTP-Schlüssel akzeptiert. (Beigetragen von Reid Thompson. Geprüft von David Steele.)
  • GCS-Zugangsdaten vor der Erneuerung des Authentifizierungstokens neu geladen. (Geprüft von Stephen Frost. Vorgeschlagen von Daniel Farina.)

Fehlerbehebungen in der Dokumentation:

  • Beispiel für die Option tls-server-address in der Konfigurationsreferenz korrigiert. (Behoben von Hartmut Goebel. Geprüft von David Steele.)
  • Beispiel für die Option filter in der Befehlsreferenz korrigiert.

Verbesserungen der Testsuite:

  • Ausführung des Unittests storage/sftp ohne installiertes libssh2 ermöglicht. (Beigetragen von Reid Thompson. Geprüft von David Steele. Vorgeschlagen von Wu Ning.)

v2.47 – Versionshinweise

Leistungsverbesserungen und Fehlerbehebungen

Veröffentlicht am 24. Juli 2023

Fehlerbehebungen:

  • Blockinkrementelle Informationen im Manifest während eines Delta-Backups beibehalten. (Geprüft von Stephen Frost. Gemeldet von Francisco Miguel Biete Banon.)
  • Blockinkrementelle Dateinamen im Befehl verify korrigiert. (Geprüft von Reid Thompson. Gemeldet von Francisco Miguel Biete Banon.)
  • Unbegründetes automatisches Delta-Backup beim Backup vom Standby behoben. (Geprüft von Stephen Frost. Gemeldet von krmozejko, Don Seiler.)
  • recovery.signal für PostgreSQL >= 12 bei Recovery mit type=none übersprungen. (Geprüft von Stefan Fercot. Gemeldet von T.Anastacio.)
  • Erzeugung eindeutiger Kennzeichnungen für differenzielle/inkrementelle Backups korrigiert. (Behoben von Andrey Sokolov. Geprüft von David Steele.)
  • Zeitbasiertes Entfernen abgelaufener Archivdaten korrigiert, wenn keine Backups abgelaufen sind. (Geprüft von Stefan Fercot.)

Verbesserungen:

  • Leistung des SFTP-Speichertreibers verbessert. (Beigetragen von Stephen Frost, Reid Thompson. Geprüft von David Steele.)
  • Zeitzonenversatz zur Datums-/Zeitausgabe des Befehls info hinzugefügt. (Geprüft von Stefan Fercot, Philip Hurst. Vorgeschlagen von Philip Hurst.)
  • Fehlerbehandlung für nicht unterstützte Funktionen zentralisiert. (Geprüft von Stefan Fercot.)

Verbesserungen der Dokumentation:

  • Im Benutzerhandbuch klargestellt, dass die Installation aus Paketen bevorzugt wird. (Geprüft von Stefan Fercot. Vorgeschlagen von dr-kd.)

v2.46 – Versionshinweise

Blockinkrementelles Backup und SFTP-Speicher

Veröffentlicht am 22. Mai 2023

Funktionen:

  • Blockinkrementelles Backup. (Geprüft von John Morris, Stephen Frost, Stefan Fercot.)
  • SFTP-Unterstützung für Repository-Speicher. (Beigetragen von Reid Thompson. Geprüft von Stephen Frost, David Steele.)
  • Unterstützung für PostgreSQL 16. (Geprüft von Stefan Fercot.)

Verbesserungen:

  • Überspringen der Seitenheader-Prüfungen ermöglicht. (Geprüft von David Christensen. Vorgeschlagen von David Christensen.)
  • chown() auf Recovery-Dateien während der Wiederherstellung vermieden. (Geprüft von Stefan Fercot, Marcelo Henrique Neppel. Vorgeschlagen von Marcelo Henrique Neppel.)
  • Fehlerdetails zu Wiederholungsversuchen bei HTTP hinzugefügt.

Verbesserungen der Dokumentation:

  • Warnung zur Verwendung von Recovery mit type=none hinzugefügt. (Geprüft von Stefan Fercot.)
  • Hinweis zur Ausführung von stanza-create auf bereits erstellten Repositorys hinzugefügt.

v2.45 – Versionshinweise

Blockinkrementelles Backup (BETA)

Veröffentlicht am 20. März 2023

Fehlerbehebungen:

  • Schreiben von recovery.signal bei der Wiederherstellung von Offline-Backups standardmäßig übersprungen. (Geprüft von Stefan Fercot. Gemeldet von Marcel Borger.)

Funktionen:

  • Blockinkrementelles Backup (BETA). (Geprüft von John Morris, Stephen Frost, Stefan Fercot.)

Verbesserungen:

  • Nur einen Gruppenindex mit ausschließlich Standardwerten beibehalten. (Geprüft von Stefan Fercot.)

Verbesserungen der Dokumentation:

  • Explizite Anweisungen für Upgrades zwischen 2.x-Versionen hinzugefügt. (Beigetragen von Christophe Courtois. Geprüft von David Steele.)
  • Mit der Einführung von TLS überholte Verweise auf SSH entfernt.

v2.44 – Versionshinweise

Unterstützung für PostgreSQL 9.0/9.1/9.2 entfernt

Veröffentlicht am 30. Januar 2023

Verbesserungen:

  • Unterstützung für PostgreSQL 9.0/9.1/9.2 entfernt. (Geprüft von Stefan Fercot.)
  • Wiederherstellung mit Fehler abgebrochen, wenn kein Backup zur aktuellen PostgreSQL-Version passt. (Beigetragen von Stefan Fercot. Geprüft von David Steele. Vorgeschlagen von Soulou.)
  • Bereichsprüfung für compress-level für jeden compress-type hinzugefügt. (Geprüft von Stefan Fercot. Vorgeschlagen von gkleen, ViperRu.)

Verbesserungen der Dokumentation:

  • Warnung zur Aktivierung des „hierarchischen Namensraums“ auf Azure-Speicher hinzugefügt. (Geprüft von Stefan Fercot. Vorgeschlagen von Vojtech Galda, Pluggi, asjonos.)
  • Ersetzung von Zeilenvorschüben im Überwachungsbeispiel hinzugefügt. (Geprüft von Stefan Fercot. Vorgeschlagen von rudonx, gmustdie, Ivan Shelestov.)
  • Verhalten von target-action bei verschiedenen PostgreSQL-Versionen erläutert. (Beigetragen von Chris Bandy. Geprüft von David Steele, Anton Kurochkin, Stefan Fercot. Vorgeschlagen von Anton Kurochkin, Chris Bandy.)
  • Übersichtsseite aktualisiert und erläutert. (Geprüft von Stefan Fercot.)
  • Dunkelmodus zur Website hinzugefügt. (Vorgeschlagen von Stephen Frost.)

v2.43 – Versionshinweise

Fehlerbehebung

Veröffentlicht am 28. November 2022

Fehlerbehebungen:

  • Fehlende Referenz bei differenziellen/inkrementellen Backups korrigiert. (Geprüft von Stefan Fercot. Gemeldet von Marcel Borger, ulfedf, jaymefSO.)

Verbesserungen:

  • Hinweis hinzugefügt, wenn eine Option ohne Index angegeben wird. (Geprüft von Stefan Fercot.)

v2.42 – Versionshinweise

Fehlerbehebungen

Veröffentlicht am 22. November 2022

Fehlerbehebungen:

  • Speicherleck bei backup/restore mit Dateibündelung behoben. (Geprüft von John Morris, Oscar. Gemeldet von Oscar.)
  • Protokollfehler bei unvollständigem Lesen einer entfernten Datei behoben. (Geprüft von Stephen Frost.)

Verbesserungen:

  • Beim Bündeln keine Referenzen für Dateien mit der Länge null gespeichert. (Geprüft von Stefan Fercot.)
  • Allgemeinere Beschreibungen für pg_start_backup()/pg_stop_backup() verwendet. (Geprüft von Greg Sabino Mullane, David Christensen. Vorgeschlagen von Greg Sabino Mullane.)

Verbesserungen der Testsuite:

  • Option --psql-bin von test.pl an die Befehlszeilenhilfe angepasst. (Beigetragen von Koshi Shibagaki. Geprüft von David Steele.)

v2.41 – Versionshinweise

Backup-Anmerkungen

Veröffentlicht am 19. September 2022

Fehlerbehebungen:

  • Falsche zeitbasierte Ablaufberechnung für nicht als Standard verwendete Repositorys korrigiert. (Geprüft von Stefan Fercot. Gemeldet von Adam Brusselback.)
  • Problem beim rekursiven Auflisten von Verzeichnissen mit einem Filter behoben. (Geprüft von Stephen Frost. Gemeldet von Efremov Egor.)

Funktionen:

  • Anmerkungen als Schlüssel-Wert-Paare für Backups. (Beigetragen von Stefan Fercot. Geprüft von David Steele. Vorgeschlagen von Adam Berlin.)

Verbesserungen:

  • --set in der JSON-Ausgabe des Befehls info unterstützt. (Beigetragen von Stefan Fercot. Geprüft von David Steele. Vorgeschlagen von Anton Kurochkin.)
  • Konfiguration der Upload-Chunk-Größe für Objektspeicher ermöglicht. (Geprüft von Stefan Fercot. Vorgeschlagen von Anton Glushakov.)
  • Zeitstempel von archive.info nach erfolgreichem Backup aktualisiert. (Geprüft von Stefan Fercot. Vorgeschlagen von Alex Richman.)
  • Prüfung der Standby-Timeline hinter den Checkpoint verschoben. (Geprüft von Stefan Fercot, Keith Fiske. Vorgeschlagen von Keith Fiske.)
  • Warnmeldung beim Fortsetzen eines Backups verbessert. (Vorgeschlagen von Cynthia Shang.)

Verbesserungen der Dokumentation:

  • Absoluten Pfad für kill in pgbackrest.service hinzugefügt. (Vorgeschlagen von Don Seiler.)

v2.40 – Versionshinweise

Unterstützung für OpenSSL 3

Veröffentlicht am 18. Juli 2022

HINWEIS FÜR PAKETBETREUER: Ein experimenteller meson-Build wurde hinzugefügt. Paketbetreuer sollten jedoch auf absehbare Zeit weiterhin den Build mit autoconf/make verwenden.

Verbesserungen:

  • Unterstützung für OpenSSL 3. (Geprüft von Stephen Frost.)
  • Beim Auflisten des Inhalts eines Pfads einen Snapshot erstellt. (Geprüft von John Morris, Stephen Frost.)
  • target-timeline=current bei einer Wiederherstellung mit type=immediate erzwungen. (Geprüft von Stephen Frost.)
  • Dateien bei Delta-restore gekürzt, wenn sie größer als erwartet sind. (Geprüft von Stephen Frost.)
  • Inkrementelles Speichern des Manifests bei resume=n deaktiviert. (Beigetragen von Reid Thompson. Geprüft von David Steele.)
  • Backup-Fortschritt vor Beginn des Kopierens auf null Prozent gesetzt. (Beigetragen von Reid Thompson. Geprüft von David Steele.)
  • S3-Flag IsTruncated verwendet, um die Fortsetzung der Auflistung zu bestimmen. (Geprüft von John Morris, Soulou. Vorgeschlagen von Christian Montagne.)

Fehlerbehebungen in der Dokumentation:

  • Interne Optionen in der Konfigurationsreferenz übersprungen. (Gemeldet von Francisco Miguel Biete Banon.)

Verbesserungen der Dokumentation:

  • Link zur PostgreSQL-Konfiguration im Abschnitt zum Repository-Host hinzugefügt. (Geprüft von Stefan Fercot. Vorgeschlagen von Julien Cigar.)

Verbesserungen der Testsuite:

  • Experimentellen Meson-Build hinzugefügt. (Geprüft von Eli Schwartz, Sam Bassaly.)
  • Übergabe beliebiger Pfade an die Option --test-path ermöglicht. (Beigetragen von Andrey Sokolov. Geprüft von David Steele.)
  • Kompilierfehler behoben, wenn DEBUG_EXEC_TIME ohne DEBUG definiert ist. (Beigetragen von Andrey Sokolov. Geprüft von David Steele.)

v2.39 – Versionshinweise

Überprüfung und Dateibündelung

Veröffentlicht am 16. Mai 2022

Fehlerbehebungen:

  • Fehler behoben, bei dem eine aus FINALLY() ausgelöste Ausnahme eine Endlosschleife verursachte. (Geprüft von Stephen Frost.)
  • Bei allen Sperrfehlern einen Fehler ausgegeben, außer wenn ein anderer Prozess die Sperre hält. (Geprüft von Reid Thompson, Geir Råness. Gemeldet von Geir Råness.)

Funktionen:

  • Bündelung von Backup-Dateien zur besseren Unterstützung kleiner Dateien. (Geprüft von Reid Thompson, Stefan Fercot, Chris Bandy.)
  • Verify-Befehl zum Validieren des Inhalts eines Repositorys. (Beigetragen von Cynthia Shang, Reid Thompson. Geprüft von David Steele, Stefan Fercot.)
  • Unterstützung für PostgreSQL 15. (Geprüft von Stefan Fercot.)
  • Backup-Fortschritt in Prozent in der Ausgabe von info angezeigt. (Beigetragen von Reid Thompson. Geprüft von David Steele.)
  • Backup für den Befehl restore mit --type=lsn automatisch ausgewählt. (Beigetragen von Reid Thompson. Geprüft von Stefan Fercot, David Steele.)
  • Warnung zu vorhandenem WAL bei deaktiviertem archive-mode-check unterdrückt. (Beigetragen von Reid Thompson. Geprüft von David Steele.)
  • Unterstützung für AWS IMDSv2 hinzugefügt. (Beigetragen von Nuno Pires. Geprüft von David Steele.)

Verbesserungen:

  • Ändern der Option repo-hardlink nach einem vollständigen Backup ermöglicht. (Geprüft von Reid Thompson.)
  • Genauigkeit der Fortschrittsprotokollierung in Prozent für backup und restore erhöht. (Beigetragen von Reid Thompson. Geprüft von David Steele.)
  • Pfadvalidierung für die Befehle repo-* verbessert. (Beigetragen von Reid Thompson. Geprüft von David Steele.)
  • Befehl stop verbessert, sodass er die Option stanza berücksichtigt. (Beigetragen von Reid Thompson. Geprüft von David Steele. Vorgeschlagen von ragaoua.)
  • Fehlermeldung bei ungültigem repo-azure-key verbessert. (Beigetragen von Reid Thompson. Geprüft von David Steele. Vorgeschlagen von Seth Daniel.)
  • Hinweis zur Prüfung des Protokolls bei asynchronen Fehlern von archive-get/archive-push hinzugefügt. (Geprüft von Reid Thompson.)
  • ClockError für unerwartete Uhrabweichungen und Zeitzonenänderungen hinzugefügt. (Geprüft von Greg Sabino Mullane, Stefan Fercot. Vorgeschlagen von Greg Sabino Mullane.)
  • Dateinamenerweiterungen des historischen Manifests vor der Anzeige in der Fehlermeldung entfernt. (Geprüft von Stefan Fercot.)
  • user:group zum Berechtigungsfehler bei Sperren hinzugefügt. (Geprüft von Reid Thompson.)

Fehlerbehebungen in der Dokumentation:

  • Falschen Verweis auf stanza-update im Benutzerhandbuch korrigiert. (Behoben von Abubakar Mohammed. Geprüft von David Steele.)
  • Beispiel für die Option repo-gcs-key-type in der Konfigurationsreferenz korrigiert. (Geprüft von Reid Thompson.)
  • Beispiel für tls-server-auth korrigiert und Erläuterungen hinzugefügt. (Geprüft von Reid Thompson.)

Verbesserungen der Dokumentation:

  • Aussagen zu unterstützten Versionen in der Dokumentation vereinfacht. (Geprüft von Stefan Fercot, Reid Thompson, Greg Sabino Mullane.)
  • Beschreibungen der Optionstypen hinzugefügt. (Beigetragen von Reid Thompson. Geprüft von David Steele.)
  • FAQ zu Backup-Typen und Wiederherstellungsgeschwindigkeit hinzugefügt. (Beigetragen von David Christensen. Geprüft von Reid Thompson.)
  • Erforderlichen Basisbranch für Pull Requests dokumentiert. (Beigetragen von David Christensen. Geprüft von Reid Thompson.)

v2.38 – Versionshinweise

Kleinere Fehlerbehebungen und Verbesserungen

Veröffentlicht am 6. März 2022

WICHTIGER HINWEIS: Die vom Befehl info gemeldete Repository-Größe basiert nun vollständig auf den Daten, die pgBackRest in den Speicher geschrieben hat. Zuvor konnte pgBackRest in bestimmten Fällen erkennen, ob der Speicher zusätzliche Komprimierung anwendete. Dies wird nicht mehr unterstützt.

Fehlerbehebungen:

  • Bei Fehlern während der S3-Stapellöschung von Dateien Wiederholungsversuche durchgeführt. (Geprüft von Reid Thompson. Gemeldet von Alex Richman.)
  • Vergleich der Werte des HTTP-Headers connection ohne Beachtung der Groß-/Kleinschreibung ermöglicht. (Geprüft von Reid Thompson. Gemeldet von Rémi Vidier.)

Funktionen:

  • Unterstützung für serverseitige Verschlüsselung von AWS S3 mit KMS hinzugefügt. (Beigetragen von Christoph Berg. Geprüft von David Steele, Tharindu Amila.)
  • Option archive-missing-retry hinzugefügt. (Geprüft von Stefan Fercot.)
  • Filter für den Backup-Typ zum Befehl info hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)

Verbesserungen:

  • Bei fehlgeschlagener Seitenprüfung während backup einen Wiederholungsversuch ausgeführt. (Geprüft von Stephen Frost, David Christensen.)
  • TLS-Server behandelt, die Verbindungen nicht geordnet schließen. (Geprüft von Rémi Vidier, David Christensen, Stephen Frost.)
  • Backup-LSNs zur Ausgabe des Befehls info hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)
  • Abschließende Schrägstriche in Pfaden für repo-ls automatisch entfernt. (Beigetragen von David Christensen. Geprüft von David Steele.)
  • Bei fatalen Fehlern keine Wiederholungsversuche durchgeführt. (Geprüft von Reid Thompson.)
  • Unterstützung für PostgreSQL 8.3/8.4 entfernt. (Geprüft von Reid Thompson, Stefan Fercot.)
  • Logik zur Ermittlung zusätzlicher Dateisystemkomprimierung entfernt. (Geprüft von Reid Thompson, Stefan Fercot.)

Fehlerbehebungen in der Dokumentation:

  • Optionen repo in der TLS-Dokumentation in den Abschnitt global verschoben. (Gemeldet von Anton Kurochkin.)
  • Ungenutzte Option backup-standby aus den Stanza-Befehlen entfernt. (Gemeldet von Stefan Fercot.)
  • Tippfehler in der Hilfe und den Versionshinweisen korrigiert. (Behoben von Daniel Gustafsson. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • Prüfung auf Betriebsbereitschaft zur systemd-Dienstkonfiguration hinzugefügt. (Vorgeschlagen von Yogesh Sharma.)
  • FAQ zur Erklärung des WAL-Archivsuffixes hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)
  • Darauf hingewiesen, dass Replikationsslots nicht wiederhergestellt werden. (Beigetragen von Reid Thompson. Geprüft von David Steele, Stefan Fercot. Vorgeschlagen von Christophe Courtois.)

v2.37 – Versionshinweise

TLS-Server

Veröffentlicht am 3. Januar 2022

WICHTIGER HINWEIS: Wenn der Befehl restore kein Backup findet, das zu einem angegebenen Zielzeitpunkt passt, wird nun ein Fehler ausgelöst. Zuvor wurde eine Warnung protokolliert.

Fehlerbehebungen:

  • Delta-Link-Zuordnung von restore korrigiert, wenn der Pfad/die Datei bereits existiert. (Geprüft von Reid Thompson. Gemeldet von Younes Alhroub.)
  • Socket-Leck bei wiederholten Verbindungsversuchen behoben. (Geprüft von Reid Thompson. Gemeldet von James Coleman.)

Funktionen:

  • TLS-Server hinzugefügt. (Geprüft von Stephen Frost, Reid Thompson, Andrew L’Ecuyer.)
  • Option --cmd hinzugefügt. (Beigetragen von Reid Thompson. Geprüft von Stefan Fercot, David Steele. Vorgeschlagen von Virgile CREVON.)

Verbesserungen:

  • Archiv unmittelbar nach Beginn des Backups geprüft. (Geprüft von Reid Thompson, David Christensen.)
  • Timeline- und Checkpoint-Prüfungen zum Backup hinzugefügt. (Geprüft von Stefan Fercot, Reid Thompson.)
  • Während eines Backups geprüft, ob Cluster laufen und korrekt konfiguriert sind. (Geprüft von Stefan Fercot.)
  • Fehler ausgegeben, wenn restore kein zum Zielzeitpunkt passendes Backup findet. (Geprüft von Reid Thompson, Douglas J Hunley. Vorgeschlagen von Douglas J Hunley.)
  • Protokoll/Port in S3/Azure-Endpunkten ausgewertet. (Beigetragen von Reid Thompson. Geprüft von David Steele.)
  • Warnung hinzugefügt, wenn checkpoint_timeout größer als db-timeout ist. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)
  • HTTP-Methode zur HTTP-Fehlerausgabe hinzugefügt. (Beigetragen von Christoph Berg. Geprüft von David Steele.)
  • y/n-Argumente für boolesche Befehlszeilenoptionen zugelassen. (Beigetragen von Reid Thompson. Geprüft von David Steele.)
  • Protokollierung der Backup-Größe exakt an die Ausgabe des Befehls info angeglichen. (Beigetragen von Reid Thompson. Geprüft von David Steele. Vorgeschlagen von Mahomed Hussein.)

Verbesserungen der Dokumentation:

  • Standardwert und zulässige Werte von Größenoptionen mit passenden Einheiten angezeigt. (Geprüft von Reid Thompson.)
  • Tippfehler korrigiert und Dokumentation zur Option tablespace-map-all verbessert. (Geprüft von Reid Thompson. Vorgeschlagen von Reid Thompson.)
  • Überholte Aussage zur künftigen Unterstützung mehrerer Repositorys entfernt. (Vorgeschlagen von David Christensen.)

v2.36 – Versionshinweise

Kleinere Fehlerbehebungen und Verbesserungen

Veröffentlicht am 1. November 2021

Fehlerbehebungen:

  • “global” als Stanza-Präfix zugelassen. (Geprüft von Stefan Fercot. Gemeldet von Younes Alhroub.)
  • Segfault bei einer ungültigen GCS-Schlüsseldatei behoben. (Geprüft von Stephen Frost. Gemeldet von Henrik Feldt.)

Verbesserungen:

  • Erstellung neuer Links durch die Option link-map ermöglicht. (Geprüft von Don Seiler, Stefan Fercot, Chris Bandy. Vorgeschlagen von Don Seiler.)
  • Höchsten zulässigen Index für die Optionen pg/repo auf 256 erhöht. (Geprüft von Cynthia Shang.)
  • Authentifizierung mit WebIdentity für AWS S3 hinzugefügt. (Geprüft von James Callahan, Reid Thompson, Benjamin Blattberg, Andrew L’Ecuyer.)
  • Fehler bei der Validierung von Backup-Dateien in backup.info gemeldet. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)
  • Startzeit der Recovery zum Wiederherstellungsprotokoll von Online-Backups hinzugefügt. (Geprüft von Tom Swartz, Stefan Fercot. Vorgeschlagen von Tom Swartz.)
  • Ursprünglichen Fehler und Wiederholungsversuche beim Fehlschlagen eines lokalen Jobs gemeldet. (Geprüft von Stefan Fercot.)
  • Seitenprüfsummenfehler in der Textausgabe von info in Fehlerliste umbenannt. (Geprüft von Stefan Fercot.)
  • Hinweise zur Meldung über eine Zeitüberschreitung bei der WAL-Wiedergabe auf dem Standby hinzugefügt. (Geprüft von Cynthia Shang, Stefan Fercot. Vorgeschlagen von Leigh Downs.)

v2.35 – Versionshinweise

Binärprotokoll

Veröffentlicht am 23. August 2021

WICHTIGER HINWEIS: Die Protokollierungsstufe für kopierte Dateien in den Befehlen backup/restore wurde auf detail geändert. Dies reduziert die Ausgabemenge auf der Stufe info. Falls diese Meldungen benötigt werden, setzen Sie die Protokollierungsstufe für die Befehle backup/restore auf detail

Fehlerbehebungen:

  • Fehler beim Abschließen mehrteiliger S3-Uploads erkannt. (Geprüft von Cynthia Shang, Marco Montagna. Gemeldet von Marco Montagna, Lev Kokotov, Anderson A. Mallmann.)
  • Erkennung zyklischer symbolischer Links korrigiert. (Geprüft von Stefan Fercot. Gemeldet von Rohit Raveendran.)
  • Nur ausgewählte Optionen repo an die Gegenstelle übergeben. (Geprüft von David Christensen, Cynthia Shang. Gemeldet von Greg Sabino Mullane, David Christensen.)

Verbesserungen:

  • Binärprotokoll. (Geprüft von Cynthia Shang.)
  • Datenverzeichnis bei restore automatisch erstellt. (Beigetragen von Stefan Fercot. Geprüft von David Steele. Vorgeschlagen von Chris Bandy.)
  • restore mit --type=lsn ermöglicht. (Beigetragen von Stefan Fercot. Geprüft von Cynthia Shang. Vorgeschlagen von James Coleman.)
  • Protokollierungsstufe für durch backup/restore kopierte Dateien auf detail geändert. (Geprüft von Stefan Fercot. Vorgeschlagen von Jens Wilke.)
  • In einer Schleife gewartet, bis die Checkpoint-LSN die Wiedergabe-LSN erreicht. (Beigetragen von Stefan Fercot. Geprüft von David Steele. Vorgeschlagen von Fatih Mencutekin.)
  • Gesamte Dateianzahl bei backup und gesamte Größe/Dateianzahl bei restore protokolliert. (Geprüft von Cynthia Shang.)

Fehlerbehebungen in der Dokumentation:

  • Falsche Hostnamen im Benutzerhandbuch korrigiert. (Geprüft von Stefan Fercot. Gemeldet von Greg Sabino Mullane.)

Verbesserungen der Dokumentation:

  • Dokumentation für Mitwirkende aktualisiert und Vorlage für Pull Requests hinzugefügt. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Backup-Dokumentation im Benutzerhandbuch neu angeordnet. (Geprüft von Cynthia Shang.)
  • Verhalten von restore mit --type in der Befehlsreferenz erläutert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Tippfehler in Dokumentation und Kommentaren korrigiert. (Beigetragen von Eric Radman. Geprüft von David Steele.)

Verbesserungen der Testsuite:

  • Prüfung auf einen Testpfad innerhalb des Repository-Pfads hinzugefügt. (Geprüft von Greg Sabino Mullane. Vorgeschlagen von Greg Sabino Mullane.)
  • Statische Codeanalyse mit CodeQL hinzugefügt. (Geprüft von Cynthia Shang.)
  • Tests auf Standardmuster umgestellt. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v2.34 – Versionshinweise

Unterstützung für PostgreSQL 14

Veröffentlicht am 7. Juni 2021

Fehlerbehebungen:

  • Probleme mit übrig gebliebenen Spool-Dateien aus einem vorherigen restore behoben. (Geprüft von Cynthia Shang, Stefan Fercot, Floris van Nee. Gemeldet von Floris van Nee.)
  • Problem beim Prüfen von Links bei einer großen Anzahl von Tablespaces behoben. (Geprüft von Cynthia Shang, Avinash Vallarapu. Gemeldet von Avinash Vallarapu.)
  • Nicht mehr benötigte entfernte Verbindungen freigegeben, damit sie während restore keine Zeitüberschreitung verursachen. (Geprüft von Cynthia Shang. Gemeldet von Francisco Miguel Biete Banon.)
  • help korrigiert, wenn eine gültige Option für den angegebenen Befehl ungültig ist. (Geprüft von Stefan Fercot. Gemeldet von Cynthia Shang.)

Funktionen:

  • Unterstützung für PostgreSQL 14 hinzugefügt. (Geprüft von Cynthia Shang.)
  • Automatische GCS-Authentifizierung für GCE-Instanzen hinzugefügt. (Geprüft von Jan Wieck, Daniel Farina.)
  • Option repo-retention-history zum Entfernen abgelaufener Backup-Historien hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von Cynthia Shang, David Steele.)
  • Option db-exclude hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von Cynthia Shang.)

Verbesserungen:

  • Protokollierung beim Entfernen abgelaufener Archivdaten von der Stufe detail auf info geändert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Archiv-Spool-Pfad der Stanza bei restore entfernt. (Geprüft von Cynthia Shang, Stefan Fercot.)
  • Beim Kopieren für backup Dateien nicht atomar geschrieben und Pfade nicht synchronisiert. (Geprüft von Stephen Frost, Stefan Fercot, Cynthia Shang.)

Verbesserungen der Dokumentation:

  • Dokumentation für Mitwirkende aktualisiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele, Stefan Fercot.)
  • RHEL/CentOS-Benutzerhandbuch zu einem einzigen Dokument zusammengeführt. (Geprüft von Cynthia Shang.)
  • Klargestellt, dass repo-s3-role kein ARN ist. (Beigetragen von Isaac Yuen. Geprüft von David Steele.)

v2.33 – Versionshinweise

Unterstützung für mehrere Repositorys und GCS

Veröffentlicht am 5. April 2021

Fehlerbehebungen:

  • Optionswarnungen korrigiert, die asynchrones archive-get/archive-push störten. (Geprüft von Cynthia Shang. Gemeldet von Lev Kokotov.)
  • Speicherleck beim Kopieren des Archivs während des Backups behoben. (Geprüft von Cynthia Shang. Gemeldet von Christian ROUX, Efremov Egor.)
  • Stack-Überlauf bei der Erzeugung der Verschlüsselungspassphrase behoben. (Geprüft von Cynthia Shang. Gemeldet von bsiara.)
  • repo-ls mit / auf S3-Repositorys korrigiert. (Geprüft von Cynthia Shang. Gemeldet von Lesovsky Alexey.)

Funktionen:

  • Unterstützung für mehrere Repositorys. (Beigetragen von Cynthia Shang, David Steele. Geprüft von Stefan Fercot, Stephen Frost.)
  • GCS-Unterstützung für Repository-Speicher. (Geprüft von Cynthia Shang, Daniel Farina.)
  • Option archive-header-check hinzugefügt. (Geprüft von Stephen Frost, Cynthia Shang. Vorgeschlagen von Hans-Jürgen Schönig.)

Verbesserungen:

  • Neu erstellte Systemdatenbanken bei der selektiven Wiederherstellung eingeschlossen. (Beigetragen von Stefan Fercot. Geprüft von Cynthia Shang.)
  • content-length aus den signierten S3-Headern ausgeschlossen. (Geprüft von Cynthia Shang. Vorgeschlagen von Brian P Bockelman.)
  • Seltener verwendete Optionen für den Repository-Speicher zusammengefasst. (Geprüft von Cynthia Shang.)
  • Benutzerdefinierten Standardwert für config-path mit ./configure --with-configdir ermöglicht. (Beigetragen von Michael Schout. Geprüft von David Steele.)
  • Kopieren des Archivs während backup protokolliert. (Geprüft von Cynthia Shang, Stefan Fercot.)

Verbesserungen der Dokumentation:

  • Referenz um Links zu Beispielen im Benutzerhandbuch ergänzt. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Dokumentation zur selektiven Wiederherstellung um Einschränkungen ergänzt. (Geprüft von Cynthia Shang, Stefan Fercot.)
  • Erläuterung zu compress-type in der Dokumentation zu archive-copy hinzugefügt. (Geprüft von Cynthia Shang, Stefan Fercot.)
  • Standardwerte für compress-level je Wert von compress-type hinzugefügt. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Hinweis hinzugefügt, dass dieselben NFS-Einstellungen wie bei PostgreSQL erforderlich sind. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v2.32 – Versionshinweise

Repository-Befehle

Veröffentlicht am 8. Februar 2021

Fehlerbehebungen:

  • Fortsetzen nach teilweiser Löschung des Backups durch einen vorherigen Fortsetzungsversuch korrigiert. (Geprüft von Cynthia Shang. Gemeldet von Tom Swartz.)

Funktionen:

  • Befehl repo-ls hinzugefügt. (Geprüft von Cynthia Shang, Stefan Fercot.)
  • Befehl repo-get hinzugefügt. (Beigetragen von Stefan Fercot, David Steele. Geprüft von Cynthia Shang.)
  • Option archive-mode-check hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von David Steele, Michael Banck.)

Verbesserungen:

  • Leistung von archive-get verbessert. (Geprüft von Cynthia Shang.)

Verbesserungen der Dokumentation:

  • Dokumentation des Befehls expire verbessert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v2.31 – Versionshinweise

Kleinere Fehlerbehebungen und Verbesserungen

Veröffentlicht am 7. Dezember 2020

Fehlerbehebungen:

  • [, # und space als erstes Zeichen in Datenbanknamen zugelassen. (Geprüft von Stefan Fercot, Cynthia Shang. Gemeldet von Jefferson Alexandre.)
  • standby.signal nur unter PostgreSQL 12 erstellt, wenn der Typ von restore standby ist. (Behoben von Stefan Fercot. Geprüft von David Steele. Gemeldet von Keith Fiske.)

Funktionen:

  • Abgelaufene Historiendateien entfernt. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)
  • Seitenprüfsummenfehler in der Ausgabe text des Befehls info gemeldet. (Beigetragen von Stefan Fercot. Geprüft von Cynthia Shang.)
  • Option repo-azure-endpoint hinzugefügt. (Geprüft von Cynthia Shang, Brian Peterson. Vorgeschlagen von Brian Peterson.)
  • Option pg-database hinzugefügt. (Geprüft von Cynthia Shang.)

Verbesserungen:

  • Ausgabe des Befehls info verbessert, wenn eine Stanza angegeben ist, aber fehlt. (Beigetragen von Stefan Fercot. Geprüft von Cynthia Shang, David Steele. Vorgeschlagen von uspen.)
  • Leistung bei großen Dateilisten in den Befehlen backup/restore verbessert. (Geprüft von Cynthia Shang, Oscar.)
  • Wiederholungsversuche für das Warten in PostgreSQL beim Start eines Backups hinzugefügt. (Geprüft von Cynthia Shang. Vorgeschlagen von Vitaliy Kukharik.)

Verbesserungen der Dokumentation:

  • Dokumentation für RHEL/CentOS 6 durch RHEL/CentOS 8 ersetzt.

v2.30 – Versionshinweise

Unterstützung für PostgreSQL 13

Veröffentlicht am 5. Oktober 2020

Fehlerbehebungen:

  • Fehler mit Hinweisen ausgegeben, wenn der Backup-Benutzer pg_settings nicht lesen kann. (Geprüft von Stefan Fercot, Cynthia Shang. Gemeldet von Mohamed Insaf K.)

Funktionen:

  • Unterstützung für PostgreSQL 13. (Geprüft von Cynthia Shang.)

Verbesserungen:

  • Erkennung der PostgreSQL-Version verbessert. (Geprüft von Cynthia Shang, Stephen Frost.)
  • Fehlermeldung zum Arbeitsverzeichnis verbessert. (Geprüft von Stefan Fercot.)
  • Hinweis zum Starten der Stanza hinzugefügt, wenn das WAL-Segment nicht gefunden wird. (Beigetragen von David Christensen. Geprüft von David Steele.)
  • Hinweis bei nicht übereinstimmenden Protokollversionen hinzugefügt. (Geprüft von Cynthia Shang. Vorgeschlagen von loop-evgeny.)

Verbesserungen der Dokumentation:

  • Hinweis hinzugefügt, dass die pgBackRest-Versionen beim entfernten Betrieb übereinstimmen müssen. (Geprüft von Cynthia Shang. Vorgeschlagen von loop-evgeny.)
  • Text zum info-Befehl in die Referenz verschoben und mit dem Benutzerhandbuch verknüpft. (Geprüft von Cynthia Shang. Vorgeschlagen von Christophe Courtois.)
  • Pfad des yum-Repositorys im CentOS/RHEL-Benutzerhandbuch aktualisiert. (Beigetragen von Heath Lord. Geprüft von David Steele.)

v2.29 – Versionshinweise

Automatische S3-Zugangsdaten auf AWS

Veröffentlicht am 31. August 2020

Fehlerbehebungen:

  • Fehler beim Schließen von Prozessen local/remote unterdrückt. Da der Befehl bereits abgeschlossen ist, wäre ein Fehler kontraproduktiv. Eine Warnung weist weiterhin darauf hin, dass etwas Ungewöhnliches passiert ist. (Geprüft von Cynthia Shang. Gemeldet von argdenis.)
  • Problem mit dem Zeichen = in Datei- oder Datenbanknamen behoben. (Geprüft von Bastian Wegge, Cynthia Shang. Gemeldet von Brad Nicholson, Bastian Wegge.)

Funktionen:

  • Temporäre S3-Zugangsdaten auf AWS-Instanzen automatisch abgerufen. (Beigetragen von David Steele, Stephen Frost. Geprüft von Cynthia Shang, David Youatt, Aleš Zelený, Jeanette Bromage.)
  • Option archive-mode hinzugefügt, um die Archivierung bei der Wiederherstellung zu deaktivieren. (Geprüft von Stephen Frost. Vorgeschlagen von Stephen Frost.)

Verbesserungen:

  • Unterstützung für PostgreSQL 13 beta3. Änderungen an den Control-/Katalog-/WAL-Versionen in nachfolgenden Beta-Versionen können die Kompatibilität aufheben. pgBackRest wird jedoch mit jeder Veröffentlichung entsprechend aktualisiert.
  • Asynchrones list/remove für S3/Azure-Speicher. (Geprüft von Cynthia Shang, Stephen Frost.)
  • Speicherverbrauch bei der Erkennung nicht protokollierter Relationen während der Manifesterstellung verbessert. (Geprüft von Cynthia Shang, Stephen Frost, Brad Nicholson, Oscar. Vorgeschlagen von Oscar, Brad Nicholson.)
  • Dateideskriptoren nach dem Abspalten des asynchronen Prozesses vorsorglich geschlossen. (Geprüft von Stephen Frost, Cynthia Shang.)
  • Schließen der entfernten Backup-Verbindung bis nach der Archivprüfung verzögert. (Beigetragen von Floris van Nee. Geprüft von David Steele.)
  • Detaillierte Fehlerausgabe verbessert. (Geprüft von Cynthia Shang.)
  • TLS-Fehlermeldungen verbessert. (Geprüft von Cynthia Shang, Stephen Frost.)

Fehlerbehebungen in der Dokumentation:

  • none zur Referenz der Option compress-type hinzugefügt und Beispiel korrigiert. (Gemeldet von Ugo Bellavance, Don Seiler.)
  • Fehlenden Typ azure in der Referenz der Option repo-type hinzugefügt. (Behoben von Don Seiler. Geprüft von David Steele.)
  • Tippfehler in der Referenz der Option repo-cipher-type korrigiert. (Behoben von Don Seiler. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • Klargestellt, dass expire regelmäßig ausgeführt werden muss, wenn expire-auto deaktiviert ist. (Geprüft von Douglas J Hunley. Vorgeschlagen von Douglas J Hunley.)

v2.28 – Versionshinweise

Azure als Repository-Speicher

Veröffentlicht am 20. Juli 2020

Fehlerbehebungen:

  • Fehler behoben, durch den sich restore mit --force wie mit --force --delta verhielt. Dadurch ersetzte restore Dateien anhand von Zeitstempel und Größe, statt sie zu überschreiben. Einige Dateien, die hätten aktualisiert werden sollen, blieben deshalb unverändert. Normales restore und restore mit --delta waren von diesem Problem nicht betroffen. (Geprüft von Cynthia Shang.)

Funktionen:

  • Azure-Unterstützung für Repository-Speicher. (Geprüft von Cynthia Shang, Don Seiler.)
  • Option expire-auto hinzugefügt. Damit lässt sich das automatische Entfernen abgelaufener Daten nach einem erfolgreichen Backup deaktivieren. (Beigetragen von Stefan Fercot. Geprüft von Cynthia Shang, David Steele.)

Verbesserungen:

  • Asynchroner mehrteiliger S3-Upload. (Geprüft von Stephen Frost.)
  • Automatische Wiederholungsversuche für backup, restore, archive-get und archive-push. (Geprüft von Cynthia Shang.)
  • Abfrageparallelität in PostgreSQL-Sitzungen zur Backup-Steuerung deaktiviert. (Geprüft von Stefan Fercot.)
  • Unterstützung für PostgreSQL 13 beta2. Änderungen an den Control-/Katalog-/WAL-Versionen in nachfolgenden Beta-Versionen können die Kompatibilität aufheben. pgBackRest wird jedoch mit jeder Veröffentlichung entsprechend aktualisiert.
  • Behandlung eines ungültigen HTTP-Antwortstatus verbessert. (Geprüft von Cynthia Shang.)
  • Fehlermeldung bei fehlender Option pg1-path für den Befehl archive-get verbessert. (Geprüft von Cynthia Shang.)
  • Hinweis hinzugefügt, wenn nach einem Timeline-Wechsel ein prüfsummenbasiertes Delta aktiviert wird. (Geprüft von Matt Bunter, Cynthia Shang.)
  • PostgreSQL statt postmaster verwendet, wo es angebracht ist. (Geprüft von Cynthia Shang.)

Fehlerbehebungen in der Dokumentation:

  • Falsches Beispiel für die Option repo-retention-full-type korrigiert. (Gemeldet von Höseyin Sönmez.)
  • Interne Befehle aus der Befehlsreferenz in HTML und Manpages entfernt. (Gemeldet von Cynthia Shang.)

Verbesserungen der Dokumentation:

  • PostgreSQL-Versionen zum Erstellen der Benutzerhandbücher aktualisiert. Außerdem Versionsbereiche hinzugefügt, um anzuzeigen, dass ein Benutzerhandbuch für einen Bereich von PostgreSQL-Versionen gilt, auch wenn es für eine bestimmte Version erstellt wurde. (Geprüft von Stephen Frost.)
  • FAQ zum Entfernen eines bestimmten Backup-Satzes aktualisiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • FAQ zur Erläuterung des standardmäßigen PITR-Verhaltens aktualisiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v2.27 – Versionshinweise

Verbessertes Entfernen abgelaufener Daten und Komprimierungstreiber

Veröffentlicht am 26. Mai 2020

Fehlerbehebungen:

  • Problem bei der Prüfung behoben, ob Datei-Links in Pfad-Links enthalten sind. (Geprüft von Cynthia Shang. Gemeldet von Christophe Cavallié.)
  • pg-path1 für synchrones archive-push optional gemacht. (Geprüft von Cynthia Shang. Gemeldet von Jerome Peng.)
  • Der Befehl expire prüft nun, ob eine Stop-Datei vorhanden ist. (Behoben von Cynthia Shang. Geprüft von David Steele.)
  • Fehlenden Begründungstext in HTTP-Antworten behandelt. (Geprüft von Cynthia Shang. Gemeldet von Tenuun.)
  • Puffergröße für das Leeren des lz4-Komprimierungspuffers erhöht. (Geprüft von Cynthia Shang. Gemeldet von Eric Radman.)
  • Optionen pg-host* und repo-host* für den Befehl remote ignoriert. (Geprüft von Cynthia Shang. Gemeldet von Pavel Suderevsky.)
  • Möglicherweise fehlende Optionen pg1-* für den Befehl remote korrigiert. (Geprüft von Cynthia Shang. Gemeldet von Andrew L’Ecuyer.)

Funktionen:

  • Zeitbasierte Aufbewahrung vollständiger Backups. Die Option --repo-retention-full-type ermöglicht die Aufbewahrung vollständiger Backups anhand eines in Tagen angegebenen Zeitraums. (Beigetragen von Cynthia Shang, Pierre Ducroquet. Geprüft von David Steele.)
  • Gezieltes Entfernen von Backups. Benutzer können ein bestimmtes Backup unabhängig von den Aufbewahrungseinstellungen entfernen. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Unterstützung für Zstandard-Komprimierung. Die Einstellung compress-type=zst macht neue Backups und Archive mit früheren Versionen von pgBackRest inkompatibel; sie können damit nicht wiederhergestellt werden. (Geprüft von Cynthia Shang.)
  • Unterstützung für bzip2-Komprimierung. Die Einstellung compress-type=bz2 macht neue Backups und Archive mit früheren Versionen von pgBackRest inkompatibel; sie können damit nicht wiederhergestellt werden. (Beigetragen von Stephen Frost. Geprüft von David Steele, Cynthia Shang.)
  • Status der laufenden Befehle backup/expire zum Befehl info hinzugefügt. (Beigetragen von Stefan Fercot. Geprüft von David Steele.)

Verbesserungen:

  • WAL-Archive erst nach Erreichen des Schwellenwerts repo-retention-archive entfernt. Zuvor wurde WAL vor dem ersten vollständigen Backup nach diesem Backup entfernt. Nun bleibt es gemäß den Aufbewahrungseinstellungen erhalten. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Lokale MD5-Implementierung hinzugefügt, damit S3 bei aktiviertem FIPS funktioniert. (Geprüft von Cynthia Shang, Stephen Frost. Vorgeschlagen von Brian Almeida, John Kelly.)
  • Unterstützung für PostgreSQL 13 beta1. Änderungen an den Control-/Katalog-/WAL-Versionen in nachfolgenden Beta-Versionen können die Kompatibilität aufheben. pgBackRest wird jedoch mit jeder Veröffentlichung entsprechend aktualisiert. (Geprüft von Cynthia Shang.)
  • Standardwert von buffer-size auf 1MiB reduziert. (Geprüft von Stephen Frost.)
  • Verständlichen Fehler ausgegeben, wenn expire nicht auf dem Repository-Host ausgeführt wird. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v2.26 – Versionshinweise

Nicht blockierendes TLS

Veröffentlicht am 20. April 2020

Fehlerbehebungen:

  • Leeren Teilausdruck aus dem regulären Ausdruck für das Manifest entfernt. Dieser verursachte unter MacOS Probleme, während andere Plattformen offenbar korrekt funktionierten. (Behoben von David Raftis. Geprüft von David Steele.)

Verbesserungen:

  • Nicht blockierende TLS-Implementierung. (Geprüft von Slava Moudry, Cynthia Shang, Stephen Frost.)
  • Kopiergröße beim Backup nur für WAL-protokollierte Dateien begrenzt. Das bisherige Verhalten konnte dazu führen, dass postgresql.conf oder postgresql.auto.conf im Backup gekürzt wurden. (Geprüft von Cynthia Shang.)
  • TCP-Keepalive-Optionen konfigurierbar gemacht. (Vorgeschlagen von Marc Cousin.)
  • Option io-timeout hinzugefügt. (Geprüft von Cynthia Shang.)

v2.25 – Versionshinweise

Unterstützung für LZ4-Komprimierung

Veröffentlicht am 26. März 2020

Funktionen:

  • Unterstützung für lz4-Komprimierung hinzugefügt. Die Einstellung compress-type=lz4 macht neue Backups und Archive mit früheren Versionen von pgBackRest inkompatibel; sie können damit nicht wiederhergestellt werden. (Geprüft von Cynthia Shang.)
  • Option --dry-run zum Befehl expire hinzugefügt. Ein Probelauf zeigt, welche Backups/Archivdaten der Befehl expire entfernen würde, ohne tatsächlich etwas zu entfernen. (Beigetragen von Cynthia Shang, Luca Ferrari. Geprüft von David Steele. Vorgeschlagen von Marc Cousin.)

Verbesserungen:

  • Leistung bei der entfernten Manifesterstellung verbessert. (Vorgeschlagen von Jens Wilke.)
  • Erkennung von Keepalive-Optionen unter Linux korrigiert. (Beigetragen von Marc Cousin. Geprüft von David Steele.)
  • Host-Erkennung in configure hinzugefügt, um Flags für Sprachstandards korrekt zu setzen. (Beigetragen von Marc Cousin. Geprüft von David Steele.)
  • Optionen compress/compress-level aus Befehlen entfernt, die sie nicht nutzen. Diese Befehle (z. B. restore, archive-get) verwendeten die Komprimierungsoptionen nie, ließen sie aber in der Befehlszeile zu. Nun verursachen diese Optionen in der Befehlszeile einen Fehler. Entfernen Sie die ungenutzten Optionen, falls diese Fehler auftreten. (Geprüft von Cynthia Shang.)
  • Kopiergröße von Backup-Dateien auf die zu Beginn des Backups gemeldete Größe begrenzt. Wächst eine Datei während des Backups, wird sie durch WAL-Wiedergabe während der Recovery rekonstruiert. Die zusätzlichen Daten müssen daher nicht kopiert werden. (Geprüft von Cynthia Shang.)

v2.24 – Versionshinweise

Automatische Auswahl eines Backup-Satzes für einen Zielzeitpunkt

Veröffentlicht am 25. Februar 2020

Fehlerbehebungen:

  • Zombieprozesse in asynchronen Archivbefehlen verhindert. (Geprüft von Stephen Frost. Gemeldet von Adam Brusselback, ejberdecia.)
  • Fehler ausgegeben, wenn archive-get/archive-push/restore nicht auf einem PostgreSQL-Host ausgeführt werden. (Geprüft von Stephen Frost. Gemeldet von Jesper St John.)
  • HTTP-Inhalt bis eof gelesen, wenn Größe/Kodierung nicht angegeben sind. (Geprüft von Cynthia Shang. Gemeldet von Christian ROUX.)
  • Fortsetzen korrigiert, wenn das fortsetzbare Backup von Perl erstellt wurde. In diesem Fall sollte das fortsetzbare Backup ignoriert werden. Der C-Code konnte jedoch das von Perl geschriebene unvollständige Manifest nicht laden, da sich das Format geringfügig unterscheidet. Prüfungen hinzugefügt, um diesen Fall zu erkennen und ordnungsgemäß fortzufahren. (Gemeldet von Kacey Holston.)

Funktionen:

  • Backup-Satz bei der Wiederherstellung automatisch ausgewählt, wenn ein Zielzeitpunkt angegeben ist. Die automatische Auswahl erfolgt nur, wenn --set nicht angegeben ist. Kann kein Backup-Satz für den angegebenen Zielzeitpunkt gefunden werden, wird der neueste Backup-Satz als Standard verwendet. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

Verbesserungen:

  • Temporäre Datei pg_internal.init beim Backup übersprungen. (Geprüft von Cynthia Shang. Vorgeschlagen von Michael Paquier.)
  • Weitere Prüfungen des Manifests bei backup hinzugefügt. (Geprüft von Cynthia Shang.)

Verbesserungen der Dokumentation:

  • Verhindert, dass lock-bot Kommentare zu gesperrten Issues hinzufügt. (Vorgeschlagen von Christoph Berg.)

v2.23 – Versionshinweise

Fehlerbehebung

Veröffentlicht am 27. Januar 2020

Fehlerbehebungen:

  • Beschädigung des Manifests durch fehlende Dateien behoben. Wenn PostgreSQL während des Backups eine Datei entfernte oder diese auf dem Standby fehlte, wurde möglicherweise die nächste Datei nicht kopiert und im Manifest aktualisiert. In diesem Fall führte die Wiederherstellung des Backups zu einem Fehler. (Geprüft von Cynthia Shang. Gemeldet von Vitaliy Kukharik.)

Verbesserungen:

  • pkg-config statt xml2-config für libxml2-Build-Optionen verwendet. (Beigetragen von David Steele, Adrian Vondendriesch.)
  • Bei backup/restore geprüft, ob Prüfsummen im Manifest gesetzt sind. (Geprüft von Cynthia Shang.)

v2.22 – Versionshinweise

Fehlerbehebung

Veröffentlicht am 21. Januar 2020

Fehlerbehebungen:

  • Fehler bei der Timeline-Konvertierung behoben. Die Timeline wird benötigt, um nach einem Backup die WAL-Segmente im Archiv zu prüfen. Die Konvertierung erfolgte zur Basis 10 statt 16, was bei Timelines ≥ 0xA zu Fehlern führte. (Gemeldet von Lukas Ertl, Eric Veldhuyzen.)

v2.21 – Versionshinweise

Migration nach C abgeschlossen

Veröffentlicht am 15. Januar 2020

Fehlerbehebungen:

  • Fehler behoben, durch den asynchrone Befehle Optionen ignorierten. Die asynchronen Prozesse archive-get/archive-push luden keine Optionen aus befehlsspezifischen Konfigurationsabschnitten wie [global:archive-get]. (Geprüft von Cynthia Shang. Gemeldet von Urs Kramer.)
  • Behandlung von \ in Dateinamen korrigiert. \ wurde bei der Berechnung der Manifest-Prüfsumme nicht korrekt maskiert, wodurch das Manifest nicht geladen werden konnte. Da \ in Cluster-Dateinamen selten bis gar nicht vorkommen sollte, dürfte dies im praktischen Einsatz kein schwerwiegendes Problem sein.

Funktionen:

  • pgBackRest besteht nun vollständig aus C-Code.
  • Option pg-user hinzugefügt. Sie legt den Datenbankbenutzernamen für Verbindungen zu PostgreSQL fest. Ohne diese Angabe verbindet sich pgBackRest wie bisher mit dem lokalen Betriebssystembenutzer oder PGUSER. (Beigetragen von Mike Palmiotto. Geprüft von David Steele.)
  • Pfadbasierte URIs im S3-Treiber zugelassen.

Verbesserungen:

  • Der Befehl backup ist vollständig in C implementiert. (Geprüft von Cynthia Shang.)

v2.20 – Versionshinweise

Fehlerbehebungen

Veröffentlicht am 12. Dezember 2019

Fehlerbehebungen:

  • archive-push/archive-get bei symbolisch verknüpftem PGDATA korrigiert. Diese Befehle versuchten, cwd() als PGDATA zu verwenden. Bei symbolisch verknüpftem PGDATA wich dies jedoch vom in pgBackRest konfigurierten Pfad ab. Wenn cwd() nicht mit dem pgBackRest-Pfad übereinstimmt, wird mit chdir() in diesen Pfad gewechselt und sichergestellt, dass das nächste cwd() mit dem Ergebnis des ersten Aufrufs übereinstimmt. (Gemeldet von Stephen Frost, Milosz Suchy.)
  • Referenzliste bei der Rekonstruktion von backup.info im Befehl expire korrigiert. Da der Befehl backup noch die Perl-Version der Rekonstruktion verwendet, tritt das Problem nur auf, wenn 1) ein Backup in backup.info fehlt und 2) der Befehl expire direkt ausgeführt wird, statt wie üblich nach backup. Aufgrund dieser unwahrscheinlichen Kombination dürfte dies im praktischen Einsatz kein Problem sein.
  • Segfault bei unerwartetem EOF während der gzip-Dekomprimierung behoben. (Gemeldet von Stephen Frost.)

v2.19 – Versionshinweise

Migrationen nach C und Fehlerbehebungen

Veröffentlicht am 12. November 2019

Fehlerbehebungen:

  • Zeitüberschreitung auf der Gegenstelle bei Delta-Wiederherstellungen behoben. Bei einer Delta-Wiederherstellung eines weitgehend unveränderten Clusters konnte auf der Gegenstelle eine Zeitüberschreitung auftreten, wenn innerhalb von protocol-timeout keine Dateien aus dem Repository abgerufen wurden. Keepalives hinzugefügt, um dies zu verhindern. (Gemeldet von James Sewell, Jens Wilke.)
  • Behandlung wiederholter HTTP-Header korrigiert. Wiederholte HTTP-Header sollten wie ein einzelner kommagetrennter Header behandelt werden, statt wie bisher einen Fehler auszulösen. (Gemeldet von donicrosby.)

Verbesserungen:

  • JSON-Ausgabe des Befehls info nicht mehr zur besseren Lesbarkeit formatiert. Überwachungssysteme können JSON ohne Zeilenvorschübe leichter verarbeiten. Bei Bedarf können externe Werkzeuge wie jq die Ausgabe formatieren. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Der Befehl check ist vollständig in C implementiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • Dokumentiert, wie man zu pgBackRest beitragen kann. (Beigetragen von Cynthia Shang, David Steele.)
  • Höchste unterstützte Version für die Option auto-stop dokumentiert. (Beigetragen von Brad Nicholson. Geprüft von David Steele.)

Verbesserungen der Testsuite:

  • Verwendung des Container-Testpfads bei --vm=none korrigiert. (Vorgeschlagen von Stephen Frost.)
  • Nicht übereinstimmende Zeitzone im expect-Test korrigiert. (Vorgeschlagen von Stephen Frost.)
  • Eingebetteten libc-Code standardmäßig nicht automatisch generiert. (Vorgeschlagen von Stephen Frost.)

v2.18 – Versionshinweise

Unterstützung für PostgreSQL 12

Veröffentlicht am 1. Oktober 2019

Funktionen:

  • Unterstützung für PostgreSQL 12.
  • Option set zum Befehl info für eine detaillierte Textausgabe hinzugefügt. Die zusätzlichen Angaben umfassen Datenbanken für die selektive Wiederherstellung sowie eine Liste von Tablespaces und symbolischen Links mit ihren Standardzielen. (Beigetragen von Cynthia Shang. Geprüft von David Steele. Vorgeschlagen von Stephen Frost, ejberdecia.)
  • Wiederherstellungstyp standby hinzugefügt. Dieser fügt für PostgreSQL < 12 automatisch standby_mode=on zu recovery.conf hinzu und erstellt für PostgreSQL ≥ 12 die Datei standby.signal. Dadurch entsteht eine gemeinsame Schnittstelle für verschiedene PostgreSQL-Versionen. (Geprüft von Cynthia Shang.)

Verbesserungen:

  • Der Befehl restore ist vollständig in C implementiert. (Geprüft von Cynthia Shang.)

Verbesserungen der Dokumentation:

  • Zusammenhang zwischen db-timeout und protocol-timeout dokumentiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele. Vorgeschlagen von James Chanco Jr.)
  • Dokumentation zu Standby-Repositorys präzisiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • FAQ zur zeitbasierten Point-in-Time-Recovery hinzugefügt. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v2.17 – Versionshinweise

Migrationen nach C und Fehlerbehebungen

Veröffentlicht am 3. September 2019

Fehlerbehebungen:

  • Langsame Manifesterstellung bei sehr großen Mengen von Tabellen/Segmenten verbessert. (Gemeldet von Jens Wilke.)
  • Ausschlüsse für spezielle Dateien korrigiert. (Gemeldet von CluelessTechnologist, Janis Puris, Rachid Broum.)

Verbesserungen:

  • Die Befehle stanza-create/update/delete sind vollständig in C implementiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Die Befehle start/stop sind vollständig in C implementiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Protokollverzeichnisse/-dateien mit dem Modus 0750/0640 erstellt. (Vorgeschlagen von Damiano Albani.)

Fehlerbehebungen in der Dokumentation:

  • Installation des Pakets yum.p.o korrigiert, wenn ein benutzerdefiniertes Paket angegeben ist. (Gemeldet von Joe Ayers, John Harvey.)

Verbesserungen der Dokumentation:

  • pgBackRest als unprivilegierter Benutzer gebaut. (Vorgeschlagen von Laurenz Albe.)

v2.16 – Versionshinweise

Migrationen nach C und Fehlerbehebungen

Veröffentlicht am 5. August 2019

Fehlerbehebungen:

  • Bei S3-Fehlern RequestTimeTooSkewed Wiederholungsversuche durchgeführt, statt sofort abzubrechen. (Gemeldet von sean0101n, Tim Garton, Jesper St John, Aleš Zelený.)
  • Falsche Behandlung von transfer-encoding in der Antwort auf eine HEAD-Anfrage korrigiert. (Gemeldet von Pavel Suderevsky.)
  • Durch Optimierungen in gcc 9 aufgedeckte Verletzungen von Gültigkeitsbereichen korrigiert. (Gemeldet von Christian Lange, Ned T. Crigler.)

Funktionen:

  • Option repo-s3-port zum Festlegen eines vom Standard abweichenden S3-Dienstports hinzugefügt.

Verbesserungen:

  • Der Befehl local für backup ist vollständig in C implementiert. (Beigetragen von David Steele, Cynthia Shang.)
  • Der Befehl check ist teilweise in C implementiert. (Geprüft von Cynthia Shang.)

v2.15 – Versionshinweise

C-Implementierung von Expire

Veröffentlicht am 25. Juni 2019

Fehlerbehebungen:

  • Zu aggressives Entfernen abgelaufener Daten bei der Archivaufbewahrung korrigiert. (Behoben von Cynthia Shang. Geprüft von David Steele. Gemeldet von Mohamad El-Rifai.)

Verbesserungen:

  • Der Befehl expire ist vollständig in C implementiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Der Befehl local für die Wiederherstellung ist vollständig in C implementiert.
  • Fest codierten PostgreSQL-Benutzer entfernt, damit $PGUSER funktioniert. (Vorgeschlagen von Julian Zhang, Janis Puris.)
  • Option --prefix von configure berücksichtigt. (Vorgeschlagen von Daniel Westermann.)
  • Option repo-s3-verify-ssl in repo-s3-verify-tls umbenannt. Der neue Name wird bevorzugt, weil pgBackRest keine SSL-Protokollversion unterstützt; alle gelten als unsicher. Der alte Name wird weiterhin akzeptiert.

Verbesserungen der Dokumentation:

  • FAQ zur Dokumentation hinzugefügt. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • wal_level=replica in der Dokumentation für PostgreSQL ≥ 9.6 verwendet. (Vorgeschlagen von Patrick McLaughlin.)

v2.14 – Versionshinweise

Fehlerbehebung und Verbesserungen

Veröffentlicht am 20. Mai 2019

Fehlerbehebungen:

  • Segfault bei process-max > 8 für archive-push/archive-get behoben. (Gemeldet von Jens Wilke.)

Verbesserungen:

  • Datenbankprüfungen übersprungen, wenn stanza-delete mit force ausgeführt wird. (Beigetragen von Cynthia Shang. Geprüft von David Steele. Vorgeschlagen von hatifnatt.)
  • Skript configure zur verbesserten Unterstützung mehrerer Plattformen hinzugefügt.

Neue Inhalte der Dokumentation:

  • Benutzerhandbücher für CentOS/RHEL 6/7 hinzugefügt.

v2.13 – Versionshinweise

Fehlerbehebungen

Veröffentlicht am 18. April 2019

Fehlerbehebungen:

  • Probleme durch Lesevorgänge der Länge null für IO-Filter behoben, die diese nicht erwarteten. (Gemeldet von brunre01, Jens Wilke, Tomasz Kontusz, guruguruguru.)
  • Zuverlässigkeit der Fehlermeldungen aus Prozessen local/remote korrigiert.
  • Posix/CIFS-Fehlermeldungen korrigiert, die beim Schreiben/Synchronisieren/Schließen den falschen Dateinamen meldeten.

v2.12 – Versionshinweise

C-Implementierung von Archive Push

Veröffentlicht am 11. April 2019

WICHTIGER HINWEIS: Die neue TLS/SSL-Implementierung verbietet gemäß RFC-2818 Punkte in S3-Bucket-Namen. Diese Sicherheitskorrektur ist für eine standardkonforme Hostnamenprüfung erforderlich.

Fehlerbehebungen:

  • Probleme behoben, wenn eine Pfadoption mit / endet. (Gemeldet von Marc Cousin.)
  • Probleme behoben, wenn log-level-file=off für den Befehl archive-get gesetzt ist. (Gemeldet von Brad Nicholson.)
  • C-Code korrigiert, sodass er wie Perl das Optionsformat host:port erkennt. (Gemeldet von Kyle Nevins.)
  • Probleme mit Protokollierungsoptionen der Befehle remote/local behoben.

Verbesserungen:

  • Der Befehl archive-push ist vollständig in C implementiert.
  • Obergrenze für process-max auf 999 erhöht. (Vorgeschlagen von Rakshitha-BR.)
  • Fehlermeldung verbessert, wenn ein S3-Bucket-Name Punkte enthält.

Verbesserungen der Dokumentation:

  • Klargestellt, dass S3-kompatible Objektspeicher unterstützt werden. (Vorgeschlagen von Magnus Hagander.)

v2.11 – Versionshinweise

C-Implementierung von Archive Get

Veröffentlicht am 11. März 2019

Fehlerbehebungen:

  • Möglicherweise gekürzte WAL-Segmente bei einem Fehler während des Schreibens korrigiert. (Gemeldet von blogh.)
  • Fehlende WAL-Minimum-/Maximum-Angaben im info-Befehl bei angegebener Stanza korrigiert. (Behoben von Stefan Fercot. Geprüft von David Steele.)
  • Nicht standardkonformes JSON für von C an Perl übergebene Optionen korrigiert. (Gemeldet von Leo Khomenko.)

Verbesserungen:

  • Der Befehl archive-get ist vollständig in C implementiert.
  • Socket-Keepalive in älteren Perl-Versionen aktiviert. (Beigetragen von Marc Cousin. Geprüft von David Steele.)
  • Fehler ausgegeben, wenn Parameter an einen Befehl übergeben werden, der keine Parameter akzeptiert. (Vorgeschlagen von Jason O’Donnell.)
  • Hinweise hinzugefügt, wenn ein WAL-Segment im Archiv nicht gefunden werden kann. (Vorgeschlagen von Hans-Jürgen Schönig.)
  • Fehlermeldung verbessert, wenn der Hostname in einem Zertifikat nicht gefunden werden kann. (Vorgeschlagen von James Badger.)
  • Zusätzliche Optionen zu backup.manifest für die Fehlersuche hinzugefügt. (Beigetragen von blogh. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • Standardversion der Dokumentation auf PostgreSQL 10 aktualisiert.

v2.10 – Versionshinweise

Fehlerbehebungen

Veröffentlicht am 9. Februar 2019

Fehlerbehebungen:

  • Bisher nicht implementierte, für archive-get erforderliche Methode des S3-Treibers hinzugefügt. (Gemeldet von mibiio.)
  • Prüfung auf falsch konfiguriertes pg-path korrigiert. (Gemeldet von James Chanco Jr.)

v2.09 – Versionshinweise

Kleinere Verbesserungen und Fehlerbehebungen

Veröffentlicht am 30. Januar 2019

Fehlerbehebungen:

  • Problem behoben, bei dem mehrere asynchrone Statusdateien einen zum Abbruch führenden Fehler verursachten. (Gemeldet von Vidhya Gurumoorthi, Joe Ayers, Douglas J Hunley.)

Verbesserungen:

  • Der Befehl info ist vollständig in C implementiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Textmeldung des Befehls info vereinfacht, wenn keine Stanzas vorhanden sind. Den Repository-Pfad durch “the repository” ersetzt.
  • Flag _DARWIN_C_SOURCE zum Makefile für MacOS-Builds hinzugefügt. (Beigetragen von Douglas J Hunley. Geprüft von David Steele.)
  • Adressauflösung im C-TLS-Client auf moderne Verfahren umgestellt. (Vorgeschlagen von Bruno Friedmann.)
  • Posix-konformen Header für strcasecmp() und fd_set eingebunden. (Vorgeschlagen von ucando.)

Fehlerbehebungen in der Dokumentation:

  • Fest codierten Repository-Pfad korrigiert. (Gemeldet von Heath Lord.)

Verbesserungen der Dokumentation:

  • Klargestellt, dass Verschlüsselung immer auf der Clientseite erfolgt. (Vorgeschlagen von Bruce Burdick.)
  • Beispiele zum Einrichten eines Dokumentationshosts hinzugefügt.
  • if in Manifestvariablen, Listen und Listeneinträgen zugelassen.

v2.08 – Versionshinweise

Kleinere Verbesserungen und Fehlerbehebungen

Veröffentlicht am 2. Januar 2019

Fehlerbehebungen:

  • Abruf der S3-Objektinformationen unmittelbar nach dem Hochladen entfernt. (Gemeldet von Matt Kunkel.)
  • Typ von archive-get-queue-max auf size korrigiert. (Gemeldet von Ronan Dunklau.)
  • Fehlermeldung hinzugefügt, wenn uid/gid des aktuellen Benutzers keinem Namen zugeordnet werden können. (Gemeldet von Camilo Aguilar.)
  • Fehler ausgegeben, wenn --target-action=shutdown für PostgreSQL < 9.5 angegeben ist.

Verbesserungen:

  • TCP-Keepalives für S3-Verbindungen gesetzt. (Vorgeschlagen von Ronan Dunklau.)
  • Textausgabe des Befehls info so umgeordnet, dass das neueste Backup zuletzt ausgegeben wird. (Beigetragen von Cynthia Shang. Geprüft von David Steele. Vorgeschlagen von Ryan Lambert.)
  • Dateieigentümer nur bei Bedarf geändert.
  • Header authentication beim Ausgeben von S3-Fehlern geschwärzt. (Vorgeschlagen von Brad Nicholson.)

Verbesserungen der Dokumentation:

  • Wirkung von target-action und Unterstützung durch PostgreSQL-Versionen erläutert. (Vorgeschlagen von Keith Fiske.)
  • Klargestellt, dass Region/Endpunkt für den Bucket korrekt konfiguriert sein müssen. (Vorgeschlagen von Pritam Barhate.)
  • Dokumentation zum Erstellen der Dokumentation hinzugefügt.

v2.07 – Versionshinweise

Automatisches prüfsummenbasiertes Backup-Delta

Veröffentlicht am 16. November 2018

Fehlerbehebungen:

  • Problem behoben, bei dem archive-push-queue-max bei Verbindungsfehlern nicht berücksichtigt wurde. (Gemeldet von Lardière Sébastien.)
  • Verwendung einer festen WAL-Segmentgröße zur Feststellung einer Überschreitung von archive-push-queue-max korrigiert.
  • Fehler nach fehlgeschlagenem Öffnen der Protokolldatei behoben, wenn die Verarbeitung fortgesetzt werden sollte. (Gemeldet von vthriller.)

Funktionen:

  • Prüfsummenbasiertes Backup-Delta automatisch aktiviert, wenn Unregelmäßigkeiten wie ein Timeline-Wechsel erkannt werden. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

Verbesserungen:

  • Bei allen S3-Fehlern 5xx Wiederholungsversuche durchgeführt, statt nur bei internen Fehlern 500. (Vorgeschlagen von Craig A. James.)

v2.06 – Versionshinweise

Prüfsummenbasiertes Delta-Backup und Unterstützung für PostgreSQL 11

Veröffentlicht am 15. Oktober 2018

Fehlerbehebungen:

  • Fehlende URI-Kodierung im S3-Treiber korrigiert. (Gemeldet von Dan Farrell.)
  • Falsche Fehlermeldung für doppelte Optionen in Konfigurationsdateien korrigiert. (Gemeldet von Jesper St John.)
  • Falsch als Fehler gemeldeten Rückgabewert in der Protokollierung auf Stufe info korrigiert. Ein Rückgabecode von 1 aus archive-get wurde auf Stufe info als Fehlermeldung protokolliert; ansonsten funktionierte der Vorgang korrekt.

Funktionen:

  • Prüfsummenbasiertes Delta für inkrementelle Backups hinzugefügt. Solche Backups verwenden Prüfsummen statt Zeitstempeln, um festzustellen, ob sich Dateien geändert haben. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Unterstützung für PostgreSQL 11, einschließlich konfigurierbarer WAL-Segmentgröße.

Verbesserungen:

  • Alle Dateien in einem verknüpften Tablespace-Verzeichnis außer dem Unterverzeichnis für die aktuelle PostgreSQL-Version ignoriert. Zuvor wurde ein Fehler ausgegeben, wenn andere Dateien vorhanden waren und nicht dem PostgreSQL-Benutzer gehörten.
  • Befehl info verbessert, sodass er den Verschlüsselungstyp der Stanza anzeigt. (Beigetragen von Cynthia Shang. Geprüft von David Steele. Vorgeschlagen von Douglas J Hunley.)
  • Unterstützung für Sonderzeichen in Dateinamen verbessert.
  • Angabe der Option delta in der pgBackRest-Konfigurationsdatei ermöglicht. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • command in authorized_hosts zur Verbesserung der SSH-Sicherheit verwendet. (Vorgeschlagen von Stephen Frost, Magnus Hagander.)
  • Zulässige Werte für die Option buffer-size in der Konfigurationsreferenz aufgelistet. (Beigetragen von Cynthia Shang. Geprüft von David Steele. Vorgeschlagen von Stéphane Schildknecht.)

v2.05 – Versionshinweise

Optionen über Umgebungsvariablen und Ausschluss temporärer/nicht protokollierter Relationen

Veröffentlicht am 31. August 2018

Fehlerbehebungen:

  • Problem behoben, bei dem relative Links in $PGDATA mit falschem Pfad im Backup gespeichert werden konnten. Absolute Links waren nicht betroffen; relative Tablespace-Links wurden durch andere Prüfungen erkannt. (Gemeldet von Cynthia Shang.)
  • Unvollständig implementierte Option online aus dem Befehl check entfernt. Der Offline-Betrieb widerspricht dem Zweck dieses Befehls: zu prüfen, ob Archivierung und Backups korrekt funktionieren. (Gemeldet von Jason O’Donnell.)
  • Problem behoben, bei dem in C ausgelöste Fehler beim Aufruf aus Perl nicht protokolliert wurden. pgBackRest beendete sich ordnungsgemäß mit dem richtigen Fehlercode. Es fehlte jedoch eine Fehlermeldung zur Unterstützung der Fehlersuche. (Gemeldet von Douglas J Hunley.)
  • Problem bei mehrfacher Angabe einer booleschen Option wie delta behoben. (Gemeldet von Yogesh Sharma.)

Funktionen:

  • Festlegen beliebiger Optionen über Umgebungsvariablen ermöglicht. Dies umfasst Optionen, die zuvor nur in der Befehlszeile angegeben werden konnten, etwa stanza, sowie geheime Optionen, die nicht in der Befehlszeile angegeben werden durften, etwa repo1-s3-key-secret.
  • Dateien temporärer und nicht protokollierter Relationen (Tabellen/Indizes) vom Backup ausgeschlossen. Die Implementierung verwendet dieselbe Logik wie die PostgreSQL-Patches 8694cc96 und 920a5e50 , die diese Funktion hinzufügen. Temporäre Relationen werden ab PostgreSQL ≥ 9.0 ausgeschlossen. Nicht protokollierte Relationen werden ab PostgreSQL ≥ 9.1 ausgeschlossen, wo diese Funktion eingeführt wurde. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Ausschließen beliebiger Verzeichnisse und/oder Dateien von einem Backup ermöglicht. Ein falscher Einsatz dieser Funktion kann zu inkonsistenten Backups führen. Lesen Sie daher vor der Verwendung die Dokumentation zu --exclude sorgfältig. (Geprüft von Cynthia Shang.)
  • Option log-subprocess hinzugefügt, um die Dateiprotokollierung für Unterprozesse local und remote zu ermöglichen.
  • Unterstützung für PostgreSQL 11 Beta 3.

Verbesserungen:

  • Dateien mit Größe null im Backup-Manifest dürfen unabhängig von der Zeitstempeldifferenz auf ein vorheriges Manifest verweisen. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Leistung von asynchronem archive-get/archive-push durch direkte Prüfung der Statusdateien verbessert. (Beigetragen von Stephen Frost. Geprüft von David Steele.)
  • Fehlermeldung verbessert, wenn einem Befehl die Option stanza fehlt. (Vorgeschlagen von Sarah Conway.)

Fehlerbehebungen in der Dokumentation:

  • Ungültige Protokollierungsstufe in der Referenz der Option log-path korrigiert. (Gemeldet von Camilo Aguilar.)

Verbesserungen der Dokumentation:

  • Versuche eingestellt, Mitwirkende in release.xml nach Nach-/Vornamen zu ordnen. Die Namen wurden in den Versionshinweisen stets genau wie angegeben dargestellt. Wir versuchten jedoch, interne IDs anhand von Nach-/Vornamen zu vergeben, was schwer zu bestimmen sein kann und letztlich keinen Sinn ergibt. Angeregt durch Christophes Vortrag auf der PostgresOpen 2017: „Menschen haben keinen Primärschlüssel“. (Vorgeschlagen von Christophe Pettus.)

Verbesserungen der Testsuite:

  • Fehler ausgegeben, wenn LibC außerhalb der Testumgebung gebaut wird. LibC wird für Produktionsbuilds nicht mehr benötigt.

v2.04 – Versionshinweise

Kritischer Fehler beim Fortsetzen von Backups behoben

Veröffentlicht am 5. Juli 2018

WICHTIGER HINWEIS: Diese Version behebt einen kritischen Fehler beim Fortsetzen von Backups. Alle vor dieser Version fortgesetzten Backups sollten als inkonsistent betrachtet werden. Ein Backup wird nach einem vorherigen fehlgeschlagenen Backup fortgesetzt, sofern nicht resume=n angegeben wurde. Ein fortgesetztes Backup lässt sich an der Meldung “aborted backup of same type exists, will be cleaned to remove invalid files and resumed” im Backup-Protokoll erkennen. Wenn diese Meldung vorhanden ist, verwenden Sie weder dieses Backup noch ein anderes Backup desselben Satzes für eine Wiederherstellung. Prüfen Sie außerdem die Wiederherstellungsprotokolle darauf, ob ein fortgesetztes Backup wiederhergestellt wurde. Falls ja, können sich inkonsistente Daten im Cluster befinden.

Fehlerbehebungen:

  • Kritischen Fehler beim Fortsetzen behoben, der zu inkonsistenten Backups führte. Eine Regression in v0.82 entfernte den Zeitstempelvergleich bei der Entscheidung, welche Dateien des abgebrochenen Backups beim Fortsetzen beibehalten werden. Weitere Einzelheiten stehen im Hinweis oben. (Gemeldet von David Youatt, Yogesh Sharma, Stephen Frost.)
  • Fehler bei der selektiven Wiederherstellung behoben, wenn nur eine Benutzerdatenbank im Cluster vorhanden ist. (Behoben von Cynthia Shang. Geprüft von David Steele. Gemeldet von Nj Baliyan.)
  • Nicht ISO-8601-konformes Zeitstempelformat in S3-Autorisierungsheadern korrigiert. AWS und einige Gateways tolerierten Stundenangaben mit führenden Leerzeichen statt Nullen, andere jedoch nicht. (Behoben von Andrew Schwartz. Geprüft von David Steele.)

Funktionen:

  • Unterstützung für PostgreSQL 11 Beta 2.

Verbesserungen:

  • HTTP-Client verbessert, sodass er content-length auf 0 setzt, wenn der Server den Wert nicht angibt. S3 und Gateways setzen immer content-length oder transfer-encoding. HTTP 1.1 verlangt dies jedoch nicht, und Proxys wie HAProxy geben möglicherweise keinen der beiden Header an. (Vorgeschlagen von Adam K. Sumner.)
  • search_path = 'pg_catalog' für PostgreSQL-Verbindungen gesetzt. (Vorgeschlagen von Stephen Frost.)

Verbesserungen der Dokumentation:

  • Neuen Abschnitt zum Bauen von pgBackRest und zum Build auf einem separaten Host erstellt.
  • Beispiel einer S3-Richtlinie zur Beschränkung von Bucket-Berechtigungen hinzugefügt. (Vorgeschlagen von Douglas J Hunley, Jason O’Donnell.)

v2.03 – Versionshinweise

Bereitstellung einer einzigen ausführbaren Datei

Veröffentlicht am 22. Mai 2018

Fehlerbehebungen:

  • Möglichen Pufferüberlauf bei der Verarbeitung von Fehlermeldungen behoben. (Gemeldet von Lætitia.)
  • Setzen einer Archivschreibsperre für den synchronen Befehl archive-get korrigiert. (Gemeldet von uspen.)

Verbesserungen:

  • Exportierte C-Funktionen und Perl-Module direkt in die ausführbare pgBackRest-Datei eingebettet.
  • time_t statt __time_t zur besseren Portierbarkeit verwendet. (Vorgeschlagen von Nick Floersch.)
  • Gesamtlaufzeit in Millisekunden am Ende des Befehls ausgegeben.

v2.02 – Versionshinweise

Paralleles asynchrones Archive Get und zusätzliche Konfigurationsdateien

Veröffentlicht am 6. Mai 2018

Fehlerbehebungen:

  • Rekursive Verzeichnissynchronisierung korrigiert, wenn nur das angegebene Verzeichnis synchronisiert werden sollte. (Gemeldet von Craig A. James.)
  • Fehler “path not found” von archive-copy bei inkrementellen/differenziellen Backups behoben. (Gemeldet von yummyliu, Vitaliy Kukharik.)
  • Fehler bei der Manifesterstellung behoben, wenn zwei oder mehr Dateien in PGDATA mit demselben Verzeichnis verknüpft sind. (Gemeldet von Vitaliy Kukharik.)
  • Fehlschlagen der Delta-Wiederherstellung bei fehlender verknüpfter Datei behoben.
  • Darstellung von Schlüssel-Wert- und Listenoptionen in der Hilfe korrigiert. (Gemeldet von Clinton Adams.)

Funktionen:

  • Asynchrones, paralleles archive-get hinzugefügt. Diese Funktion hält eine Warteschlange von WAL-Segmenten vor, um die Latenz zu verringern, wenn PostgreSQL ein WAL-Segment mit restore_command anfordert.
  • Unterstützung für zusätzliche pgBackRest-Konfigurationsdateien hinzugefügt. Das Verzeichnis wird über die Option --config-include-path angegeben. Option --config-path hinzugefügt, um den Standard-Basispfad der Optionen --config und --config-include-path zu überschreiben. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Option repo-s3-token hinzugefügt, um temporäre Zugangstokens konfigurieren zu können. pgBackRest kann derzeit keine neuen Zugangsdaten anfordern. Daher muss der gesamte Befehl, etwa backup oder restore, abgeschlossen sein, bevor die Zugangsdaten ablaufen. (Beigetragen von Yogesh Sharma. Geprüft von David Steele.)

Verbesserungen:

  • Optionen archive-push-queue-max, manifest-save-threshold und buffer-size aktualisiert, sodass sie Werte in KB, MB, GB, TB oder PB mit einer Potenz von 1024 als Multiplikator akzeptieren. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Pfadsynchronisierung bei Backup/Wiederherstellung effizienter gestaltet. Das Durchsuchen des gesamten Verzeichnisses kann bei vielen kleinen Tabellen sehr aufwendig sein. Daher wird die Pfadliste im Backup-Manifest zur Synchronisierung verwendet, statt den Backup-/Wiederherstellungspfad zu durchsuchen.
  • Befehlsparameter zusätzlich zu den Befehlsoptionen in der anfänglichen info-Protokollmeldung angezeigt.
  • Option archive-queue-max in archive-push-queue-max umbenannt. Dies entspricht der neuen Option archive-get-queue-max. Der alte Optionsname wird weiterhin akzeptiert.

Fehlerbehebungen in der Dokumentation:

  • Dokumentation um 32-Bit-Unterstützung und Einschränkungen ergänzt. Die 32-Bit-Unterstützung wurde in v1.26 hinzugefügt. (Gemeldet von Viorel Tabara.)

Verbesserungen der Dokumentation:

  • Überwachungsbeispiele mit PostgreSQL und jq hinzugefügt. (Vorgeschlagen von Stephen Frost, Brian Faherty.)
  • Beispiel für die Verwendung eines Befehlsabschnitts zur Archivierungskonfiguration hinzugefügt. (Vorgeschlagen von Christophe Courtois.)
  • Beschreibung von info --output=json als experimentell aus der Dokumentation entfernt.
  • Veraltete Beschreibung der Option spool-path aktualisiert.

Neue Funktionen der Testsuite:

  • lcov für Berichte zur Abdeckung der C-Unittests verwendet. Wechsel von Devel::Cover, da es für aus gcov konvertierte Berichte keine Zweigabdeckung meldete. Eine unvollständige Zweigabdeckung eines Moduls erzeugt nun einen Fehler. Die Abdeckung der Unittests wird im Bericht nur angezeigt, wenn ihre Anweisungs- oder Zweigabdeckung unvollständig ist.

v2.01 – Versionshinweise

Kleinere Fehlerbehebungen und Verbesserungen

Veröffentlicht am 19. März 2018

Fehlerbehebungen:

  • Fehler behoben, durch den die Optionen --target-action und --recovery-option bei Wiederherstellungen mit --type=immediate als ungültig gemeldet wurden. (Gemeldet von Brad Nicholson.)
  • Sofort einen Fehler ausgegeben, wenn eine geheime Option wie repo1-s3-key in der Befehlszeile übergeben wird. Da pgBackRest geheime Optionen nicht an Unterprozesse weitergab, wurde zuvor ein unklarer Fehler ausgelöst. Der neue Fehler ist wesentlich deutlicher und enthält Hinweise zur Behebung. Die Befehlsdokumentation wurde angepasst, um geheime Optionen, die nicht in der Befehlszeile angegeben werden können, auszulassen. (Gemeldet von Brad Nicholson.)
  • Problem bei der Übergabe von --no-config an eingebettetes Perl behoben. (Gemeldet von Ibrahim Edib Kokdemir.)
  • Problem behoben, bei dem log-level-stderr > warn beim Beenden eines Prozesses local/remote einen Fehler verursachte, weil unerwartete Ausgabe auf stderr vorlag. Der Höchstwert für Prozesse local/remote ist nun error, da es für diese Prozesse keinen Grund gibt, Warnungen auszugeben. (Gemeldet von Clinton Adams.)
  • Manifesttest im Befehl check bei vorhandenen Tablespaces korrigiert. (Behoben von Cynthia Shang. Geprüft von David Steele. Gemeldet von Thomas Flatley.)

Verbesserungen:

  • Fehler ausgegeben, wenn in der Konfigurationsdatei mehrere Argumente für eine Option gesetzt werden, die keine mehreren Argumente akzeptiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Überflüssige sudo-Befehle aus src/Makefile entfernt. (Beigetragen von Adrian Vondendriesch. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • Index in Beispielen für indizierte Optionen angezeigt, also repo-* und pg-*. (Vorgeschlagen von Stephen Frost.)
  • Inhaltsverzeichnis auf der Befehlsseite vereinfacht, indem nur Befehle aufgeführt werden. (Vorgeschlagen von Stephen Frost.)
  • Verweise auf den optionalen Charakter der C-Bibliothek entfernt.

Neue Funktionen der Testsuite:

  • Paket-Builds für CentOS/RHEL hinzugefügt.
  • clang für die statische Codeanalyse verwendet. Anfangs wurden nur einige Funktionen gefunden, die mit __noreturn__ hätten gekennzeichnet werden sollen.

v2.00 – Versionshinweise

Leistungsverbesserungen bei der WAL-Archivierung

Veröffentlicht am 23. Februar 2018

Funktionen:

  • Der Befehl archive-push ist jetzt teilweise in C implementiert. Dadurch läuft der PostgreSQL-archive_command deutlich schneller, wenn er Statusmeldungen des asynchronen Archivierungsprozesses verarbeitet. (Geprüft von Cynthia Shang.)

Verbesserungen:

  • Der Befehl check prüft jetzt, ob das Backup-Manifest erstellt werden kann. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Leistung des HTTPS-Clients verbessert. Die Pufferung berücksichtigt jetzt die pending-Bytes am Socket, sofern vorhanden, statt sich ausschließlich auf select() zu verlassen. In manchen Fällen wurden die letzten Bytes erst beim Schließen der Verbindung ausgegeben.
  • Leistung beim Löschen in S3 verbessert. Die Konstante S3_BATCH_MAX war vermutlich während Tests durch den fest codierten Wert 2 ersetzt worden.
  • Jede Option, die nicht ausschließlich auf der Befehlszeile verfügbar ist, kann nun auf der Befehlszeile auf ihren Standardwert zurückgesetzt werden. Damit lassen sich Optionen aus pgbackrest.conf zurücksetzen, sodass seltener neue Konfigurationsdateien für besondere Anforderungen nötig sind.
  • Die C-Bibliothek ist jetzt erforderlich. Dadurch entfällt das bedingte Laden, und neue Bibliotheksfunktionen lassen sich leichter entwickeln.
  • Die ausführbare Datei pgbackrest ist jetzt ein C-Programm statt eines Perl-Programms. Dadurch laufen bestimmte zeitkritische Befehle wie das asynchrone archive-push schneller.
  • Für eine einheitlichere Benennung wurden db-*-Optionen in pg-* und backup-*-Optionen in repo-* umbenannt. repo-*-Optionen sind jetzt indiziert, obwohl derzeit nur ein Repository zulässig ist.

Neue Inhalte der Dokumentation:

  • Alle Cluster in der Dokumentation werden mit Prüfsummen initialisiert.

Verbesserungen der Dokumentation:

  • Veraltete Optionsnamen in der Dokumentation und Befehlszeilenhilfe aufgeführt.
  • Klargestellt, dass S3-Buckets vom Benutzer erstellt werden müssen. (Vorgeschlagen von David Youatt.)

v1.29 – Versionshinweise

Behebung eines kritischen Fehlers beim Fortsetzen von Backups

Veröffentlicht am 5. Juli 2018

WICHTIGER HINWEIS: Diese Version behebt einen kritischen Fehler beim Fortsetzen von Backups. Alle vor dieser Version fortgesetzten Backups sollten als inkonsistent betrachtet werden. Nach einem fehlgeschlagenen Backup wird dieses fortgesetzt, sofern nicht resume=n angegeben wurde. Ein fortgesetztes Backup lässt sich an der Meldung “aborted backup of same type exists, will be cleaned to remove invalid files and resumed” im Backup-Protokoll erkennen. Ist diese Meldung vorhanden, darf weder dieses Backup noch ein anderes Backup desselben Satzes zur Wiederherstellung verwendet werden. Außerdem ist in den Wiederherstellungsprotokollen zu prüfen, ob ein fortgesetztes Backup wiederhergestellt wurde. Ist dies der Fall, können inkonsistente Daten im Cluster vorliegen.

Fehlerbehebungen:

  • Kritischen Fehler beim Fortsetzen behoben, der zu inkonsistenten Backups führte. Durch eine Regression in v0.82 entfiel der Zeitstempelvergleich bei der Entscheidung, welche Dateien des abgebrochenen Backups beim Fortsetzen beibehalten werden. Einzelheiten stehen im Hinweis oben. (Gemeldet von David Youatt, Yogesh Sharma, Stephen Frost.)
  • Nicht ISO-8601-konformes Zeitstempelformat in S3-Autorisierungsheadern korrigiert. AWS und einige Gateways akzeptierten Stundenangaben mit führenden Leerzeichen statt Nullen, andere dagegen nicht. (Behoben von Andrew Schwartz. Geprüft von David Steele.)
  • Fehler behoben, bei dem Verzeichnisse rekursiv synchronisiert wurden, obwohl nur das angegebene Verzeichnis synchronisiert werden sollte. (Gemeldet von Craig A. James.)
  • Fehler behoben, bei dem die Optionen --target-action und --recovery-option bei der Wiederherstellung mit --type=immediate als ungültig gemeldet wurden. (Gemeldet von Brad Nicholson.)
  • Fehler behoben, bei dem archive-copy bei inkrementellen oder differenziellen Backups die Meldung “path not found” ausgab. (Gemeldet von yummyliu, Vitaliy Kukharik.)
  • Fehler beim Erstellen des Manifests behoben, wenn zwei oder mehr Dateien in PGDATA mit demselben Verzeichnis verknüpft sind. (Gemeldet von Vitaliy Kukharik.)
  • Fehler behoben, durch den die Delta-Wiederherstellung bei einer fehlenden verknüpften Datei scheiterte.
  • Fehler bei der selektiven Wiederherstellung behoben, wenn der Cluster nur eine Benutzerdatenbank enthält. (Behoben von Cynthia Shang. Geprüft von David Steele. Gemeldet von Nj Baliyan.)

Verbesserungen:

  • Der HTTP-Client setzt content-length jetzt auf 0, wenn der Server keinen Wert angibt. S3 und entsprechende Gateways setzen stets content-length oder transfer-encoding; HTTP 1.1 verlangt dies jedoch nicht, und Proxys wie HAProxy können beide weglassen. (Vorgeschlagen von Adam K. Sumner.)
  • Leistung des HTTPS-Clients verbessert. Die Pufferung berücksichtigt jetzt die pending-Bytes am Socket, sofern vorhanden, statt sich ausschließlich auf select() zu verlassen. In manchen Fällen wurden die letzten Bytes erst beim Schließen der Verbindung ausgegeben.
  • Leistung beim Löschen in S3 verbessert. Die Konstante S3_BATCH_MAX war vermutlich während Tests durch den fest codierten Wert 2 ersetzt worden.
  • Pfadsynchronisierung bei Backups und Wiederherstellungen effizienter gestaltet. Das gesamte Verzeichnis einzulesen, kann bei vielen kleinen Tabellen sehr aufwendig sein. Statt den Backup- oder Wiederherstellungspfad einzulesen, wird nun die Pfadliste im Backup-Manifest für die Synchronisierung verwendet. Die nicht mehr benötigte rekursive Pfadsynchronisierung wurde entfernt.

Fehlerbehebungen in der Dokumentation:

  • Dokumentation um die 32-Bit-Unterstützung und ihre Einschränkungen ergänzt. Die 32-Bit-Unterstützung wurde in v1.26 eingeführt. (Gemeldet von Viorel Tabara.)

Verbesserungen der Dokumentation:

  • Klargestellt, dass S3-Buckets vom Benutzer erstellt werden müssen. (Vorgeschlagen von David Youatt.)
  • Veraltete Beschreibung der Option spool-path aktualisiert.

v1.28 – Versionshinweise

Stanzas löschen

Veröffentlicht am 1. Februar 2018

Fehlerbehebungen:

  • Fehler behoben, durch den eine einzelne Datenbank in einem Tablespace nicht mit –db-include wiederhergestellt werden konnte. (Behoben von Cynthia Shang. Geprüft von David Steele. Gemeldet von Chiranjeevi Ravilla.)
  • Beim Abgleich von archive.info mit backup.info wird jetzt sichergestellt, dass die neueste db-id gewählt wird. Dies gewährleistet die richtige Zuordnung bei doppelten Werten für system-id und db-version, etwa nach dem Rückgängigmachen eines pg_upgrade. (Behoben von Cynthia Shang. Geprüft von David Steele. Gemeldet von Adam K. Sumner.)
  • Übermäßig ausführliche Fehlermeldung bei einem ungültigen Befehl korrigiert. (Gemeldet von Jason O’Donnell.)

Funktionen:

  • Befehl stanza-delete zum Entfernen ungenutzter Stanzas hinzugefügt. (Beigetragen von Cynthia Shang. Geprüft von David Steele. Vorgeschlagen von Magnus Hagander.)

Verbesserungen:

  • Der Befehl stanza-create gibt keinen Fehler mehr aus, wenn die Stanza bereits existiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • Dokumentation zu stanza-create --force um einen ausdrücklichen Hinweis auf die gebotene Vorsicht ergänzt. (Vorgeschlagen von Jason O’Donnell.)

v1.27 – Versionshinweise

Fehlerbehebungen und Dokumentation

Veröffentlicht am 19. Dezember 2017

Fehlerbehebungen:

  • Fehler behoben, der Meldungen über einen falschen Ausführungsort für backup und restore unterdrückte. Ist ein Backup-Host vorhanden, sollten Backups nur dort und Wiederherstellungen nur auf dem Datenbank-Host zulässig sein, sofern nicht eine alternative Konfiguration erstellt wird, die den entfernten Host ignoriert. (Gemeldet von Lardière Sébastien.)
  • Fehler behoben, durch den WAL unter PostgreSQL 10 nicht entfernt wurde. Ursache war ein fehlerhafter regulärer Ausdruck, der für alle PostgreSQL-Hauptversionen folgendes Format erwartete: X.X. (Gemeldet von Adam Brusselback.)
  • Fehler behoben, durch den --no-config nicht an Kindprozesse übergeben wurde. Diese lasen daher weiterhin die lokale Konfigurationsdatei, was unerwartetes Verhalten verursachen konnte.
  • Befehl info korrigiert, sodass "db (prior)" nicht mehr ausgegeben wird, wenn für eine frühere Version des Clusters weder Backups noch Archive vorhanden sind. (Behoben von Cynthia Shang. Geprüft von David Steele. Gemeldet von Stephen Frost.)

Neue Inhalte der Dokumentation:

  • Zusammenhang zwischen den Optionen archive-copy und archive-check dokumentiert. (Vorgeschlagen von Markus Nullmeier.)
  • Referenzdokumentation zu archive-copy verbessert.

v1.26 – Versionshinweise

Repository-Verschlüsselung

Veröffentlicht am 21. November 2017

Fehlerbehebungen:

  • Fehler behoben, der beim Wiederherstellen das Kopieren großer Manifeste scheitern lassen konnte. (Gemeldet von Craig A. James.)
  • Falschen WAL-Offset auf 32-Bit-Architekturen korrigiert. (Behoben von Javier Wilson. Geprüft von David Steele.)
  • Fehler beim Abrufen von WAL für alte Datenbankversionen behoben. Nach einem stanza-upgrade sollte es weiterhin möglich sein, Backups der vorherigen Version wiederherzustellen und mit archive-get eine Recovery durchzuführen. Allerdings prüfte archive-get nur die neueste Datenbankversion und -kennung und scheiterte deshalb. Zudem wurden Probleme bereinigt, wenn dieselbe Datenbankversion und -kennung mehrfach in der Historie vorkommt. (Behoben von Cynthia Shang. Geprüft von David Steele. Gemeldet von Clinton Adams.)
  • Fehler bei der Wiederherstellung von Gruppen behoben, die im Backup ungültig waren. Kann das Backup einer Gruppe keinen Namen zuordnen, speichert es die Gruppe im Manifest als false. Bei der Wiederherstellung verwendet es dann den Eigentümer von $PGDATA zum Setzen der Gruppe oder, falls dies nicht möglich ist, die Gruppe des aktuellen Benutzers. Diese Logik funktionierte nicht richtig: Die gewählte Gruppe überschrieb bei der Wiederherstellung den Benutzer. Dadurch blieb die Gruppe undefiniert, und der Benutzer wurde fälschlich auf die Gruppe gesetzt. (Gemeldet von Jeff McCormick.)
  • Fehler bei der Parameterübergabe an entfernte Prozesse behoben. Bei mehreren angegebenen Datenbanken wurden stets Pfad, Port und Socket-Pfad von db1 übergeben, unabhängig davon, welche Datenbank tatsächlich angesprochen wurde. (Gemeldet von uspen.)

Funktionen:

  • Unterstützung für Repository-Verschlüsselung. (Beigetragen von Cynthia Shang, David Steele.)

Verbesserungen:

  • gzip-Filter bei --compress-level-network=0 deaktiviert. Der Filter wurde mit Komprimierungsstufe 0 verwendet und verursachte dadurch Aufwand ohne Nutzen.
  • Dekomprimierung im gzip-Filter beschleunigt.

Neue Inhalte der Dokumentation:

  • Vorlage hinzugefügt, um bei Problemmeldungen von Anfang an bessere Informationen zu erhalten. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • Verwendung der Option archive-timeout verdeutlicht und ihren Unterschied zur PostgreSQL-Einstellung archive_timeout beschrieben. (Beigetragen von Cynthia Shang. Geprüft von David Steele. Vorgeschlagen von Keith Fiske.)

Neue Funktionen der Testsuite:

  • Automatisierte Tests für die 32-Bit-Architektur i386/i686.

v1.25 – Versionshinweise

Leistungsverbesserungen für S3

Veröffentlicht am 24. Oktober 2017

Fehlerbehebungen:

  • Fehler behoben, durch den benutzerdefinierte Werte für compress-level ignoriert wurden. (Gemeldet von Jens Wilke.)
  • Fehlermeldung bei überlappenden Timelines entfernt. Überlappende Timelines sind in vielen Szenarien der Point-in-Time-Recovery (PITR) zulässig. (Gemeldet von blogh.)
  • Fälle korrigiert, in denen database-id in der JSON-Ausgabe von info nicht als Ganzzahl dargestellt wurde. (Behoben von Cynthia Shang. Geprüft von David Steele. Gemeldet von Jason O’Donnell.)

Funktionen:

  • Listenabfragen in S3 beschleunigt. Ein literaler Anfangsteil des Filterausdrucks wird als Suchpräfix verwendet. Dadurch bleibt die Anfrage oft klein genug, um eine Ratenbegrenzung zu vermeiden. (Vorgeschlagen von Mihail Shvein.)

Neue Funktionen der Testsuite:

  • I/O-Leistungstests hinzugefügt.

v1.24 – Versionshinweise

Neue Backup-Ausschlüsse

Veröffentlicht am 28. September 2017

Fehlerbehebungen:

  • Fehler behoben, bei dem während der Initialisierung eines Backups vom Standby Warnungen statt Protokollmeldungen niedrigerer Priorität ausgegeben wurden. (Gemeldet von uspen.)
  • Fehler behoben, durch den einige db-*-Optionen wie db-port nicht an entfernte Prozesse übergeben wurden. (Gemeldet von uspen.)

Funktionen:

  • Inhalte von pg_snapshots, pg_serial, pg_notify und pg_dynshmem vom Backup ausgeschlossen, da sie beim Start neu erstellt werden.
  • Dateien namens pg_internal.init vom Backup ausgeschlossen, da sie beim Start neu erstellt werden.

Verbesserungen:

  • Protokolldatei erst öffnen, wenn der asynchrone Prozess vollständig vom Hauptprozess getrennt ist, damit dieser nicht ebenfalls in die Datei schreibt. (Vorgeschlagen von Jens Wilke.)

Neue Inhalte der Dokumentation:

  • Konfiguration für SSH ohne Passwort hinzugefügt.

Verbesserungen der Dokumentation:

  • In der Dokumentation „master“ gemäß der PostgreSQL-Konvention durch „primary“ ersetzt.

v1.23 – Versionshinweise

Mehrere Standbys und Unterstützung für PostgreSQL 10

Veröffentlicht am 3. September 2017

Fehlerbehebungen:

  • Fehler behoben, durch den die Komprimierung bei wachsenden Dateien abbrechen konnte. (Gemeldet von Jesper St John, Aleksandr Rogozin.)
  • Fehler behoben, durch den der lokale Prozess keine Keep-alives an den entfernten Prozess sendete. (Gemeldet von William Cox.)

Funktionen:

  • Für Backups vom Standby können bis zu sieben Standbys konfiguriert werden. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Unterstützung für PostgreSQL 10.
  • Beim Lesen von XML-Daten zusätzlich zur Übertragung in Blöcken (Chunked Encoding) auch content-length zugelassen, um die Kompatibilität mit S3-Gateways von Drittanbietern zu verbessern. (Vorgeschlagen von Victor Gdalevich.)

Verbesserungen:

  • HTTP-Zeitlimit für S3 erhöht.
  • Wiederholungen von HTTP-Anfragen hinzugefügt, um vorübergehende S3-Netzwerkfehler besser abzufangen.

Fehlerbehebungen in der Dokumentation:

  • Dokumentgenerierung korrigiert, sodass Abschnittszusammenfassungen auf der Konfigurationsseite erscheinen. (Behoben von Cynthia Shang. Geprüft von David Steele.)

v1.22 – Versionshinweise

Fehler bei S3-Wiederholungen behoben

Veröffentlicht am 9. August 2017

Fehlerbehebungen:

  • Authentifizierungsfehler bei S3-Wiederholungen behoben.

v1.21 – Versionshinweise

Verbesserte info-Ausgabe und Option für den SSH-Port

Veröffentlicht am 8. August 2017

Fehlerbehebungen:

  • Das Verzeichnis archive_status wird jetzt bei der Wiederherstellung neu erstellt, um PostgreSQL 8.3 zu unterstützen. Anders als neuere Versionen erstellt diese Version es nicht automatisch neu. (Gemeldet von Stephen Frost.)
  • Fehler behoben, durch den das leere Archivverzeichnis einer alten PostgreSQL-Version nach einem stanza-upgrade zurückbleiben konnte. (Behoben von Cynthia Shang. Geprüft von David Steele.)

Funktionen:

  • Befehl info in der Text- und JSON-Ausgabe so geändert, dass er die Archiv-ID sowie das kleinste und größte derzeit im Archiv vorhandene WAL-Segment für die aktuelle und gegebenenfalls frühere Version des Datenbankclusters anzeigt. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Optionen --backup-ssh-port und --db-ssh-port zur Unterstützung abweichender SSH-Ports hinzugefügt. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

Verbesserungen:

  • Anfrage wiederholen, wenn S3 einen internen Fehler (500) zurückgibt.

Fehlerbehebungen in der Dokumentation:

  • Beschreibung von --online entsprechend dem jeweiligen Befehlskontext korrigiert.

Neue Inhalte der Dokumentation:

  • Erstellung von /etc/pgbackrest.conf in die Anleitung zur manuellen Installation aufgenommen.

Verbesserungen der Dokumentation:

  • Repository-Optionen in der Befehls- und Befehlszeilenhilfe in einen eigenen Abschnitt verschoben. (Vorgeschlagen von Stephen Frost.)

v1.20 – Versionshinweise

Kritischen Fehler für 8.3/8.4 behoben

Veröffentlicht am 27. Juni 2017

WICHTIGER HINWEIS: PostgreSQL-Installationen der Versionen 8.3 und 8.4, die Tablespaces verwenden, sollten sofort von jeder v1-Version aktualisiert werden und ein vollständiges Backup durchführen. Ein Fehler verhinderte ausschließlich in diesen Versionen die Sicherung von Tablespaces. PostgreSQL ≥ 9.0 ist nicht betroffen.

Fehlerbehebungen:

  • Fehler behoben, der Backups von Tablespaces unter PostgreSQL ≤ 8.4 verhinderte.
  • Beim Bau der C-Bibliothek ein fehlendes Flag ergänzt. Dessen Fehlen führte auf 32-Bit-Systemen zu einer unpassenden Binärdatei. (Gemeldet von Adrian Vondendriesch.)

Funktionen:

  • Optionen s3-repo-ca-path und s3-repo-ca-file hinzugefügt, um Systeme zu unterstützen, auf denen IO::Socket::SSL CAs nicht automatisch findet, etwa RHEL7, oder um eigene CAs zu laden. (Vorgeschlagen von Scott Frazer.)

Neue Funktionen der Testsuite:

  • Dokumentations-Builds in CI aufgenommen.

v1.19 – Versionshinweise

Unterstützung für S3

Veröffentlicht am 12. Juni 2017

Fehlerbehebungen:

  • Befehl info korrigiert, sodass die angezeigten kleinsten und größten WAL-Segmente im Archiv zur aktuellen Datenbankversion gehören. (Behoben von Cynthia Shang. Geprüft von David Steele.)
  • Befehl backup korrigiert, sodass backup-standby zurückgesetzt und das Backup auf dem Primärserver fortgesetzt wird, wenn der Standby nicht konfiguriert und/oder nicht erreichbar ist. (Behoben von Cynthia Shang. Geprüft von David Steele.)
  • Fehler behoben, durch den Konfigurationswarnungen eines entfernten Prozesses Fehler im Hauptprozess auslösten. (Behoben von Cynthia Shang. Geprüft von David Steele.)

Funktionen:

  • Unterstützung für Repositorys auf Amazon S3. (Geprüft von Cynthia Shang.)

Fehlerbehebungen in der Dokumentation:

  • Ungültige Option max-archive-mb in der Konfigurationsreferenz durch archive-queue-max ersetzt.
  • Fehlendes sudo im Installationsabschnitt ergänzt. (Behoben von Lætitia. Geprüft von David Steele.)

v1.18 – Versionshinweise

Stanza-Upgrades, Refactoring und verbesserte Sperren

Veröffentlicht am 12. April 2017

Fehlerbehebungen:

  • Fehler behoben, bei dem lesende Operationen mit lokalen Arbeitsprozessen, etwa restore, Schreibsperren erzeugten, die paralleles archive-push beeinträchtigen konnten. (Gemeldet von Jens Wilke.)

Funktionen:

  • Befehl stanza-upgrade hinzugefügt, um nach einem Upgrade auf eine neue PostgreSQL-Hauptversion auch die Stanza aktualisieren zu können. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Validierung von pgbackrest.conf hinzugefügt, die bei ungültigen Optionen oder Optionen im falschen Abschnitt warnt. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

Verbesserungen:

  • Sperrkonzept vereinfacht. Jetzt hält nur der Hauptprozess Schreibsperren für archive-push und backup, statt wie bisher alle lokalen und entfernten Arbeitsprozesse.
  • Zeitstempel der Dateien in den Backup-Verzeichnissen nicht mehr an die Zeitstempel im Clusterverzeichnis angleichen. Dies diente ursprünglich zum Fortsetzen von Backups, das inzwischen mit Prüfsummen umgesetzt ist.
  • Fehlermeldung verbessert, wenn restore die Datei postmaster.pid erkennt. (Vorgeschlagen von Yogesh Sharma.)
  • Rückgabecodes im Bereich 25 bis 125 neu nummeriert, damit PostgreSQL einige davon nicht als schwerwiegende Signalfehler interpretiert. (Vorgeschlagen von Yogesh Sharma.)

v1.17 – Versionshinweise

Fehler bei Seitenprüfsummen behoben

Veröffentlicht am 13. März 2017

Fehlerbehebungen:

  • Fehler behoben, durch den neu initialisierte, aber ungenutzte Seiten Warnungen zu Seitenprüfsummen auslösten. (Gemeldet von Stephen Frost.)

v1.16 – Versionshinweise

Verbesserte Seitenprüfsummen, CI und Pakettests

Veröffentlicht am 2. März 2017

Fehlerbehebungen:

  • Fehler behoben, bei dem Tabellen über 1GB nach dem ersten Segment Warnungen zu Seitenprüfsummen ausgaben. (Gemeldet von Stephen Frost.)
  • Fehler behoben, bei dem Datenbanken mit einem vom Standard abweichenden Tablespace fälschlich warnten, dass pg_filenode.map und pg_internal.init nicht an Seitengrenzen ausgerichtet seien. (Gemeldet von blogh.)

Neue Funktionen der Testsuite:

  • Kontinuierliche Integration mit travis-ci.
  • Automatisierter Bau von Debian-Paketen für alle unterstützten Distributionen.

v1.15 – Versionshinweise

Refactoring und Fehlerbehebungen

Veröffentlicht am 13. Februar 2017

Fehlerbehebungen:

  • In v1.13 eingeführte Regression behoben, durch die Backups scheitern konnten, wenn während der Manifest-Erstellung Dateien entfernt wurden, etwa durch das Löschen von Tabellen. (Gemeldet von Navid Golpayegani.)

v1.14 – Versionshinweise

Refactoring und Fehlerbehebungen

Veröffentlicht am 13. Februar 2017

Fehlerbehebungen:

  • Fehler behoben, bei dem ein fehlgeschlagenes archive-push nicht erneut versucht wurde, sondern PostgreSQL dauerhaft Fehler erhielt, sofern die .error-Datei nicht manuell gelöscht wurde. (Gemeldet von Jens Wilke.)
  • Wettlaufsituation bei paralleler Archivierung behoben, in der das Erstellen neuer Pfade einen Fehler auslöste, wenn mehrere Prozesse dies gleichzeitig versuchten. (Gemeldet von Jens Wilke.)

Verbesserungen:

  • Ermittlung von wal archive min/max durch den Befehl info beschleunigt. (Vorgeschlagen von Jens Wilke.)

Neue Inhalte der Dokumentation:

  • Dokumentation zur asynchronen Archivierung aktualisiert, um die neue Funktionsweise und die Unterschiede zur alten Methode genauer zu beschreiben. (Vorgeschlagen von Jens Wilke.)

v1.13 – Versionshinweise

Parallele Archivierung, Stanza-Erstellung sowie verbessertes info und check

Veröffentlicht am 5. Februar 2017

WICHTIGER HINWEIS: Die neue Implementierung der asynchronen Archivierung kopiert WAL nicht mehr in eine separate Warteschlange. Nach dem Upgrade auf 1.13 noch in der alten Warteschlange vorhandenes WAL wird aufgegeben und nicht in das Repository übertragen. Um dies zu verhindern, zunächst die Archivierung mit archive_command = false anhalten. Danach die asynchrone Warteschlange mit pgbackrest --stanza=[stanza-name] archive-push leeren und warten, bis der Prozess abgeschlossen ist. Prüfen, dass die Warteschlange in [spool-path]/archive/[stanza-name]/out leer ist. Abschließend 1.13 installieren und den ursprünglichen archive_command wiederherstellen. WICHTIGER HINWEIS: Der Befehl stanza-create ist nicht mehr optional und muss ausgeführt werden, bevor Backups oder Archivierung für eine neue Stanza möglich sind. Für bereits vorhandene Stanzas muss stanza-create nicht ausgeführt werden.

Fehlerbehebungen:

  • const-Zuweisung korrigiert, die beim Kompilieren der C-Bibliothek eine Warnung auslöste. (Behoben von Adrian Vondendriesch. Geprüft von David Steele.)
  • Einige für --repo-sync fehlende Verzeichnissynchronisierungen ergänzt.
  • Fehler behoben, durch den ein fehlender Benutzer oder eine fehlende Gruppe bei der Wiederherstellung in File->owner() den Fehler “uninitialized value” auslösen konnte. (Gemeldet von Leonardo GG Avellar.)
  • Fehler behoben, bei dem Meldungen über Protokollabweichungen den erwarteten Wert nicht ausgaben.
  • Irreführende Protokollmeldung von archive-get korrigiert, die den Exit-Code 1 als ungewöhnlichen Abbruch bezeichnete.

Funktionen:

  • Verbesserte Implementierung der asynchronen Archivierung mit mehreren Prozessen.
  • stanza-create so verbessert, dass es beschädigte Repositorys in den meisten Fällen reparieren kann und robust genug ist, um verpflichtend zu werden. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • check kann jetzt auf einem Standby ausgeführt werden. Dabei erfolgen nur grundlegende Prüfungen, da pg_switch_xlog() auf einem Replikat nicht ausgeführt werden kann. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • WAL-Bereiche für Archiv und Backups zum Befehl info hinzugefügt.
  • Warnung hinzugefügt, beim Neuzuordnen von Tablespaces unter PostgreSQL < 9.2 auch pg_tablespace.spclocation zu aktualisieren. (Beigetragen von blogh. Geprüft von David Steele.)
  • Sperren auf entfernten Hosts für archive-get, restore, info und check nicht mehr voraussetzen, da diese Befehle nur lesend zugreifen. (Vorgeschlagen von Michael Vitale.)

Verbesserungen:

  • Kopfzeile der Protokolldatei erst beim Schreiben des ersten Protokolleintrags ausgeben. (Vorgeschlagen von Jens Wilke.)
  • Durch Filterung anhand der LSN zum Backup-Beginn das Risiko verringert, dass unvollständig geschriebene Seiten fälschlich Fehler bei Seitenprüfsummen melden.
  • Intel-spezifische Optimierung aus den Build-Flags der C-Bibliothek entfernt. (Beigetragen von Adrian Vondendriesch. Geprüft von David Steele.)
  • Option --lock entfernt. Sie wurde eingeführt, bevor das Sperrverzeichnis außerhalb des Repositorys liegen konnte, und ist inzwischen überholt.
  • Option --log-timestamp hinzugefügt, um Zeitstempel in Protokollen unterdrücken zu können. Sie dient hauptsächlich dazu, Filter in der automatisch erzeugten Dokumentation zu vermeiden.
  • Korrekten Fehlercode zurückgeben, wenn ein relativer Pfad nicht in einen absoluten umgewandelt werden kann. (Vorgeschlagen von Yogesh Sharma.)

Neue Inhalte der Dokumentation:

  • Option process-max im Benutzerhandbuch dokumentiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v1.12 – Versionshinweise

Seitenprüfsummen, Konfiguration und Fehlerbehebungen

Veröffentlicht am 12. Dezember 2016

WICHTIGER HINWEIS: In früheren Versionen konnten auf der Befehlszeile Optionen angegeben werden, die für den aktuellen Befehl ungültig waren, ohne einen Fehler auszulösen. Ungültige Optionen erzeugen jetzt einen Fehler. Daher ist es wichtig, die Befehlszeilenoptionen in Ihrer Umgebung sorgfältig zu prüfen, um Störungen zu vermeiden.

Fehlerbehebungen:

  • Fehler behoben, durch den für den jeweiligen Befehl ungültige Optionen ohne Fehlermeldung auf der Befehlszeile angegeben werden konnten. Die Optionen wurden ignoriert und änderten das Verhalten nicht, führten aber zu Verwirrung. Ungültige Optionen erzeugen jetzt einen Fehler. (Gemeldet von Nikhilchandra Kulkarni.)
  • Fehler behoben, durch den interne symbolische Verknüpfungen für Tablespaces im Repository nicht erstellt wurden. Dies fiel nur auf, wenn Cluster mithilfe von Dateisystem-Snapshots manuell am Speicherort gestartet werden sollten; normale Backups und Wiederherstellungen waren nicht betroffen.
  • Fehler behoben, der die Fehlerausgabe auf der Konsole vor der Initialisierung der Protokollierung verhinderte, etwa beim Einlesen von Optionen. Fehlercodes wurden weiterhin korrekt zurückgegeben; ein fehlgeschlagener Prozess erschien dadurch also nicht als erfolgreich. (Gemeldet von Adrian Vondendriesch.)
  • Fehler behoben, durch den eine auf dem Backup-Server angegebene db-port-Option nur dann korrekt an den entfernten Prozess übergeben wurde, wenn sie zur ersten konfigurierten Datenbank gehörte. (Gemeldet von Michael Vitale.)

Funktionen:

  • Option --checksum-page hinzugefügt, mit der pgBackRest Seitenprüfsummen in Datendateien validieren kann, wenn Prüfsummen unter PostgreSQL >= 9.3 aktiviert sind. Diese Funktion erfordert eine C-Bibliothek, die anfangs möglicherweise noch nicht in Betriebssystempaketen enthalten ist. Die Option wird automatisch aktiviert, wenn die Bibliothek vorhanden ist und Prüfsummen im Cluster aktiviert sind. (Vorgeschlagen von Stephen Frost.)
  • Option --repo-link hinzugefügt, um interne symbolische Verknüpfungen zu unterdrücken, wenn das Dateisystem des Repositorys sie nicht unterstützt. Dies beeinträchtigt keine pgBackRest-Funktion. Die Verknüpfung latest und die internen Tablespace-Verknüpfungen werden jedoch nicht erstellt, was das manuelle Starten von Clustern am Speicherort mittels Dateisystem-Snapshots beeinträchtigt.
  • Option --repo-sync hinzugefügt, um Verzeichnissynchronisierungen im Repository für Dateisysteme zu deaktivieren, die sie nicht unterstützen, etwa NTFS.
  • Einheitlichen Protokolleintrag hinzugefügt, der den erfolgreichen Abschluss eines Befehls meldet. Ein erfolgreiches Backup endet beispielsweise mit: INFO: backup command end: completed successfully. (Vorgeschlagen von Jens Wilke.)

Verbesserungen:

  • Zur Vereinfachung wird pg_control jetzt zusammen mit den übrigen Dateien kopiert, statt separat am Ende des Vorgangs. Der Befehl backup benötigt dieses bisherige Verhalten nicht; restore kopiert in eine temporäre Datei, die am Ende der Wiederherstellung umbenannt wird.

Fehlerbehebungen in der Dokumentation:

  • Fehler behoben, der Ausnahmen bei PDF-Builds unterdrückte.
  • In v1.10 eingeführte Regression bei Abschnittslinks behoben.

Neue Inhalte der Dokumentation:

  • Aufbewahrung in den Schnellstartabschnitt aufgenommen.

v1.11 – Versionshinweise

Fehler bei der Effizienz asynchroner Archivierung behoben

Veröffentlicht am 17. November 2016

Fehlerbehebungen:

  • Fehler behoben, durch den die asynchrone Archivierung pro Ausführung nur eine Datei statt mehrerer Dateien als Gruppe übertrug. Diese in v1.09 eingeführte Regression beeinträchtigte nur die Effizienz; alle WAL-Segmente wurden im asynchronen Modus korrekt archiviert. (Gemeldet von Stephen Frost.)

v1.10 – Versionshinweise

Stanza-Erstellung und kleinere Fehlerbehebungen

Veröffentlicht am 8. November 2016

Fehlerbehebungen:

  • Fehler behoben, durch den ein Backup scheitern konnte, wenn zwischen Backups keine Datenbankänderungen erfolgt waren und sich nur pg_control geändert hatte.
  • Fehler behoben, durch den Tablespace-Pfade mit demselben Präfix einen Fehler wegen einer ungültigen Verknüpfung auslösten. (Gemeldet von Nikhilchandra Kulkarni.)

Funktionen:

  • Befehl stanza-create hinzugefügt, um Stanzas im Repository ausdrücklich anzulegen. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

Verbesserungen:

  • Überflüssige use lib-Anweisungen aus Perl-Modulen entfernt. (Vorgeschlagen von Devrim Gündüz.)

v1.09 – Versionshinweise

Unterstützung für 9.6, Konfigurierbarkeit und Fehlerbehebungen

Veröffentlicht am 10. Oktober 2016

Fehlerbehebungen:

  • Befehl check korrigiert, sodass bei fehlendem Backup-Verzeichnis keine Fehlermeldung protokolliert wird. (Behoben von Cynthia Shang. Geprüft von David Steele.)
  • Fehlermeldung korrigiert, damit bei einem ungültigen Archivierungsbefehl dieser korrekt angezeigt wird. (Gemeldet von Jason O’Donnell.)
  • Fehler behoben, durch den der asynchrone Archivierer nicht gestartet wurde, wenn archive-push nicht genügend Platz hatte, um ein neues WAL-Segment einzureihen. Dadurch wurde die Warteschlange ohne manuellen Eingriff, etwa einen direkten Aufruf von archive-push, nie geleert. PostgreSQL erhält weiterhin Fehler, wenn der Speicherplatz für neue WAL-Segmente fehlt; der asynchrone Prozess wird jedoch trotzdem gestartet, damit schließlich wieder Platz frei wird. (Gemeldet von Jens Wilke.)
  • Zeitüberschreitung beim entfernten Prozess behoben, die auftrat, wenn ein lokaler Prozess beim Fortsetzen oder Wiederherstellen Prüfsummen berechnete, aber keine Dateien kopierte und der entfernte Prozess dadurch untätig blieb. (Gemeldet von Jens Wilke.)

Funktionen:

  • Unter PostgreSQL 9.6 werden automatisch nicht exklusive Backups verwendet.
  • Option cmd-ssh hinzugefügt, um den ssh-Client anzugeben. (Vorgeschlagen von Jens Wilke.)
  • Option log-level-stderr hinzugefügt, die steuert, ob Konsolenmeldungen an stderr oder stdout gesendet werden. Der Standardwert ist warn. Dies ändert das Verhalten gegenüber früheren Versionen, auch wenn es intuitiver sein mag. Mit log-level-stderr=off bleibt das bisherige Verhalten erhalten. (Vorgeschlagen von Sascha Biberhofer.)
  • application_name für Datenbankverbindungen auf "pgBackRest [command]" setzen. (Vorgeschlagen von Jens Wilke.)
  • Prüfen, ob archive_mode aktiviert ist, wenn die Option archive-check aktiviert ist.

Verbesserungen:

  • Fehlermeldung beim erfolglosen Anfordern der kooperativen pgBackRest-Sperre verdeutlicht, damit klar ist, dass es sich nicht um eine PostgreSQL-Backup-Sperre handelt. (Vorgeschlagen von Jens Wilke.)
  • pgBackRest-Versionsnummer in die INFO-Protokollausgabe beim Befehlsstart aufgenommen.
  • Prozess-ID in der INFO-Protokollausgabe beim Starten und Stoppen lokaler Prozesse protokolliert.

Neue Inhalte der Dokumentation:

  • Option archive-timeout im Benutzerhandbuch dokumentiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v1.08 – Versionshinweise

Fehlerbehebungen und verbesserte Protokollierung

Veröffentlicht am 14. September 2016

Fehlerbehebungen:

  • Fehler behoben, durch den lokale Prozesse nach Abschluss die Verbindung nicht trennten und später eine Zeitüberschreitung auslösen konnten. (Gemeldet von Todd Vernick.)
  • Fehler behoben, durch den die Protokollschicht beim Warten auf WAL-Segmente im Archiv eine Zeitüberschreitung auslösen konnte. (Gemeldet von Todd Vernick.)

Verbesserungen:

  • Dateiprotokollausgabe bis zum Erstellen der Datei zwischenspeichern, damit das Protokoll vollständiger ist.

v1.07 – Versionshinweise

Umstellung von Threads auf Prozesse und Fehlerbehebungen

Veröffentlicht am 7. September 2016

Fehlerbehebungen:

  • Fehler behoben, durch den Tablespaces bei einem Backup vom Standby vom Primärserver kopiert wurden.
  • Befehl check korrigiert, sodass Backup-Informationen auch auf dem entfernten Host und nicht nur lokal geprüft werden. (Behoben von Cynthia Shang. Geprüft von David Steele.)
  • Fehler behoben, durch den retention-archive bei retention-archive-type=diff nicht automatisch gesetzt wurde. Dadurch wurden Archive weniger konsequent als beabsichtigt entfernt. (Behoben von Cynthia Shang. Geprüft von David Steele.)

Funktionen:

  • Perl-Threads zur Verbesserung von Kompatibilität und Leistung durch Prozesse ersetzt.
  • Inhalte von $PGDATA/pg_replslot ausschließen, damit Replikationsslots des Primärservers nicht in das Backup gelangen.
  • archive-start und archive-stop werden jetzt auch bei archive-check=n in backup.manifest eingetragen. (Vorgeschlagen von Jens Wilke.)
  • Zusätzliche Warnungen, wenn die Einstellungen zur Archivaufbewahrung möglicherweise nicht die beabsichtigte Wirkung haben oder eine unbegrenzte Aufbewahrung erlauben. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Experimentelle Unterstützung für nicht exklusive Backups unter PostgreSQL 9.6 rc1. Änderungen der Control-, Katalog- oder WAL-Versionen in späteren Release-Kandidaten können die Kompatibilität aufheben; pgBackRest wird jedoch mit jeder Veröffentlichung entsprechend aktualisiert.

Fehlerbehebungen in der Dokumentation:

  • Kleinere Probleme bei der Reproduzierbarkeit der Dokumentation im Zusammenhang mit Binärpfaden behoben.

Neue Inhalte der Dokumentation:

  • Archivaufbewahrung dokumentiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v1.06 – Versionshinweise

Backups vom Standby und Fehlerbehebungen

Veröffentlicht am 25. August 2016

Fehlerbehebungen:

  • Fehler behoben, durch den eine Tablespace-Verknüpfung, die auf eine weitere Verknüpfung zeigte, keinen Fehler auslöste, sondern den Tablespace vollständig übersprang. (Gemeldet von Michael Vitale.)
  • Fehler behoben, durch den Optionen, die nur einen Wert zulassen sollten, mehrfach ohne Fehlermeldung in pgbackrest.conf angegeben werden konnten. (Gemeldet von Michael Vitale.)
  • Fehler behoben, durch den protocol-timeout nicht automatisch erhöht wurde, wenn db-timeout erhöht wurde. (Gemeldet von Todd Vernick.)

Funktionen:

  • Backups von einem Standby-Cluster. Zum Starten und Stoppen des Backups sowie zum Kopieren nicht replizierter Dateien ist weiterhin eine Verbindung zum Primärcluster erforderlich. Der weitaus größte Teil der Dateien wird jedoch vom Standby kopiert, um den Primärserver zu entlasten.
  • Flexiblere Datenbankkonfiguration. Primärserver und Standby können beide auf dem Backup-Server konfiguriert werden; pgBackRest erkennt automatisch, welcher der Primärserver ist. Bei einem separaten Backup-Server sind daher nach einem Failover vom Primärserver zum Standby keine Änderungen an der Backup-Konfiguration nötig.
  • Verzeichnisse vom Backup ausschließen, die PostgreSQL beim Start leert, neu erstellt oder mit Nullen füllt. Dazu gehören pgsql_tmp und pg_stat_tmp. Zusätzlich zu den bereits ausgeschlossenen Dateien backup_label.old, postmaster.opts, postmaster.pid, recovery.conf und recovery.done wird nun auch postgresql.auto.conf.tmp ausgeschlossen.
  • Experimentelle Unterstützung für nicht exklusive Backups unter PostgreSQL 9.6 beta4. Änderungen der Control-, Katalog- oder WAL-Versionen in späteren Betaversionen können die Kompatibilität aufheben; pgBackRest wird jedoch mit jeder Veröffentlichung entsprechend aktualisiert.

Verbesserungen:

  • Fehlermeldung bei der Manifest-Erstellung für Verknüpfungen verbessert, die auf weitere Verknüpfungen zeigen.
  • Fehlermeldung bei relativen Pfaden in archive-push oder archive-get um Hinweise ergänzt.
  • Backup-Protokollmeldungen verbessert, sodass erkennbar ist, von welchem Host Dateien kopiert werden.

v1.05 – Versionshinweise

Fehler bei der Prüfung von Tablespace-Verknüpfungen behoben

Veröffentlicht am 9. August 2016

Fehlerbehebungen:

  • Fehler behoben, durch den Tablespace-Pfade mit $PGDATA als Teilzeichenfolge als Unterverzeichnisse von $PGDATA erkannt wurden, obwohl sie keine waren. Auch die Prüfung relativer Pfade wurde etwas verschärft. (Gemeldet von Chris Fort.)

Neue Inhalte der Dokumentation:

  • Planung von Backups mit cron dokumentiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

Verbesserungen der Dokumentation:

  • Liste ausstehender Aufgaben von der pgBackRest-Website in das Wiki des GitHub-Repositorys verschoben. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v1.04 – Versionshinweise

Verschiedene Fehlerbehebungen

Veröffentlicht am 30. Juli 2016

Fehlerbehebungen:

  • Fehler behoben, durch den ein überflüssiger entfernter Prozess erstellt wurde. Dadurch konnten Backups oder Wiederherstellungen mit Threads eine Zeitüberschreitung und/oder einen Sperrkonflikt auslösen. (Gemeldet von Michael Vitale.)
  • Fehler behoben, durch den db-path für check nicht vorgeschrieben war. Fehlte der Wert, wurde deshalb eine Assertion statt einer verständlichen Fehlermeldung ausgelöst. (Gemeldet von Michael Vitale.)
  • Befehl check korrigiert, sodass er einen Fehler ausgibt, wenn Datenbankversion oder -kennung nicht mit dem Archiv übereinstimmen. (Behoben von Cynthia Shang. Geprüft von David Steele.)
  • Fehler behoben, durch den ein entfernter Prozess selbst einen entfernten Prozess starten konnte, wenn backup-host in der pgbackrest.conf auf dem Datenbankserver fehlte. (Gemeldet von Lardière Sébastien.)
  • Fehler behoben, durch den die Inhalte von pg_xlog gesichert wurden, wenn das Verzeichnis symbolisch verknüpft war. Dies verursachte bei der Wiederherstellung keine Probleme, verschwendete aber Speicherplatz.
  • Ungültigen log()-Aufruf in den Sperrroutinen korrigiert.

Funktionen:

  • Experimentelle Unterstützung für nicht exklusive Backups unter PostgreSQL 9.6 beta3. Änderungen der Control-, Katalog- oder WAL-Versionen in späteren Betaversionen können die Kompatibilität aufheben; pgBackRest wird jedoch mit jeder Veröffentlichung entsprechend aktualisiert.

Verbesserungen:

  • Begrüßungstexte auf SSH-Protokollverbindungen unterdrücken.
  • Fehlermeldungen entfernter Prozesse verbessert, sodass der Host erkennbar ist, auf dem der Fehler auftrat.
  • Alle Typen entfernter Prozesse setzen jetzt Sperren. Die Ausnahmen stammten aus der Zeit, als Testumgebung und pgBackRest in derselben VM liefen, und gelten nicht mehr.

Neue Inhalte der Dokumentation:

  • Erläuterung ergänzt, warum der Standardwert von backrest-user backrest ist. (Vorgeschlagen von Michael Vitale.)
  • Informationen zur Paketverfügbarkeit auf unterstützten Plattformen aktualisiert. (Vorgeschlagen von Michael Vitale.)

v1.03 – Versionshinweise

Befehl check und Fehlerbehebungen

Veröffentlicht am 2. Juli 2016

Fehlerbehebungen:

  • Fehler behoben, durch den keep-alives bei einem backup mit mehreren Threads und vielen kleinen Dateien zu kurz kommen konnten. Beim Fortsetzen von backup mit einem oder mehreren Threads sowie bei der Prüfsummenberechnung von restore fehlten sie zudem vollständig. (Gemeldet von Janice Parkinson, Chris Barber.)
  • Fehler behoben, durch den expire bei explizitem Aufruf über die Befehlszeile die Ausführung verweigerte, wenn db-host gesetzt war. Bei automatischer Ausführung von expire nach einem backup trat dies nicht auf. (Gemeldet von Chris Barber.)
  • Fehler behoben, durch den archive_command auch bei deaktiviertem archive-check validiert wurde.

Funktionen:

  • Befehl check hinzugefügt, um die korrekte pgBackRest-Konfiguration für Archivierung und Backups zu prüfen. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Option protocol-timeout hinzugefügt. Zuvor war protocol-timeout auf db-timeout + 30 Sekunden festgelegt.
  • Wenn entfernte Prozesse am Ende des Backups nicht beendet werden können, wird keine Ausnahme mehr ausgelöst. Stattdessen erscheint eine Warnung, die einen höheren Wert für protocol-timeout empfiehlt.
  • Experimentelle Unterstützung für nicht exklusive Backups unter PostgreSQL 9.6 beta2. Änderungen der Control-, Katalog- oder WAL-Versionen in späteren Betaversionen können die Kompatibilität aufheben; pgBackRest wird jedoch mit jeder Veröffentlichung entsprechend aktualisiert.

Verbesserungen:

  • Umgang mit beim Backup erfassten Benutzern und Gruppen verbessert, die auf dem Wiederherstellungshost nicht existieren. Auch der Fall, dass ein Benutzer oder eine Gruppe keinem Namen zugeordnet ist, wird ausdrücklich behandelt.
  • Optionen werden jetzt wesentlich strenger geprüft. Zuvor konnte ein Befehl eine Option verwenden, die ihm nicht ausdrücklich zugeordnet war. Dies betraf besonders backup-host und db-host, die den Ausführungsort bestimmen.

Verbesserungen der Dokumentation:

  • Festes Datum für die Dokumentation zugelassen, um reproduzierbare Builds zu ermöglichen. (Vorgeschlagen von Adrian Vondendriesch.)
  • Asynchrone Archivierung im Benutzerhandbuch dokumentiert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Empfohlener Installationsort für pgBackRest-Module ist jetzt /usr/share/perl5, da /usr/lib/perl5 in neueren Perl-Versionen aus dem Suchpfad entfernt wurde.
  • Anleitung zum Entfernen früherer pgBackRest-Versionen hinzugefügt.

v1.02 – Versionshinweise

Fehlerbehebung für Perl 5.22

Veröffentlicht am 2. Juni 2016

Fehlerbehebungen:

  • Verwendung von sprintf() an neue Einschränkungen in Perl 5.22 angepasst. Parameter, die nicht im Formatstring referenziert werden, sind nicht mehr zulässig. (Behoben von Adrian Vondendriesch. Geprüft von David Steele.)

Fehlerbehebungen in der Dokumentation:

  • Syntax korrigiert, die mit Perl 5.2X nicht kompatibel war. (Behoben von Christoph Berg, Adrian Vondendriesch. Geprüft von David Steele.)
  • Absolute Pfade für das PDF-Logo korrigiert. (Gemeldet von Adrian Vondendriesch.)

Neue Inhalte der Dokumentation:

  • Versionshinweise in Abschnitte gegliedert, um Fehlerbehebungen, Funktionen und Refactoring klar zu trennen. Ein Abschnitt „Zusätzliche Hinweise“ enthält Änderungen an Dokumentation und Testsuite, die den Kerncode nicht betreffen.
  • Erzeugung einer Handbuchseite hinzugefügt. (Beigetragen von Adrian Vondendriesch, David Steele.)
  • Das Änderungsprotokoll war der letzte Teil der Dokumentation, der nur als Markdown ausgegeben wurde. Ein Konverter ermöglicht jetzt die Ausgabe mit den Standard-Renderern. Das Änderungsprotokoll ist künftig auf der Website zu finden und wurde in „Versionen“ umbenannt. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)

v1.01 – Versionshinweise

Erweitertes info, selektive Wiederherstellung und Unterstützung für 9.6

Veröffentlicht am 17. Mai 2016

Funktionen:

  • Textausgabe von info um Zeitstempel, Größen und die Referenzliste für alle Backups erweitert. (Beigetragen von Cynthia Shang. Geprüft von David Steele.)
  • Selektive Wiederherstellung von Datenbanken aus einem Cluster-Backup ermöglicht. Wenn nur bestimmte Datenbanken wiederhergestellt werden, kann dies viel Speicherplatz und Zeit sparen. Nicht wiederhergestellte Datenbanken sind nicht zugänglich, müssen jedoch manuell gelöscht werden, damit sie aus dem gemeinsamen Katalog verschwinden. (Geprüft von Cynthia Shang, Greg Smith, Stephen Frost. Vorgeschlagen von Stephen Frost.)
  • Experimentelle Unterstützung für nicht exklusive Backups unter PostgreSQL 9.6 beta1. Änderungen der Control-, Katalog- oder WAL-Versionen in späteren Betaversionen können die Kompatibilität aufheben; pgBackRest wird jedoch mit jeder Veröffentlichung entsprechend aktualisiert. (Geprüft von Cynthia Shang.)

v1.00 – Versionshinweise

Neues Repository-Format und Konfigurationsschema, Unterstützung für Verknüpfungen

Veröffentlicht am 14. April 2016

WICHTIGER HINWEIS: Diese Version mit grundlegender Umstellung ist nicht mit älteren pgBackRest-Versionen kompatibel. Manifestformat, Speicherstruktur, Konfigurationsschema sowie Namen ausführbarer Dateien und Pfade wurden geändert. Für die Backups dieser pgBackRest-Version muss ein neues Repository erstellt werden. Das alte Repository muss noch eine Zeit lang aufbewahrt werden, falls eine Wiederherstellung nötig ist. Wiederherstellungen aus dem alten Repository erfordern die vorherige pgBackRest-Version. Dank der geänderten Namen können 1.00 und eine frühere pgBackRest-Version jedoch gleichzeitig installiert sein. Weitere Einzelheiten zu den Änderungen stehen in den folgenden Hinweisen.

Funktionen:

  • Neues Konfigurationsschema implementiert, das wesentlich einfacher zu verwenden sein sollte. Einzelheiten stehen im Benutzerhandbuch und in der Konfigurationsreferenz. Bei einer einfachen Konfiguration können jetzt alle Optionen im Abschnitt stanza stehen. Gemeinsame Optionen für mehrere Stanzas können im Abschnitt [global] stehen. Komplexere Konfigurationen können weiterhin Befehlsabschnitte nutzen; dies sollte jedoch selten nötig sein. (Vorgeschlagen von Michael Renner.)
  • repo-path bezeichnet jetzt immer das Repository für Backups und Archiv, ob lokal oder entfernt. Daher wurde repo-remote-path entfernt. Die neue Option spool-path legt einen Speicherort fest, an dem WAL-Segmente bei asynchroner Archivierung zwischengespeichert werden. Ein lokales Repository ist nicht mehr erforderlich.
  • Der Standardname der Konfigurationsdatei ist jetzt pgbackrest.conf statt pg_backrest.conf. Dies vereinheitlicht die Benennung mit anderen Änderungen und verhindert zugleich, dass beim Umstieg auf 1.00 versehentlich alte Konfigurationsdateien geladen werden. (Vorgeschlagen von Michael Renner, Stephen Frost.)
  • Standardname des Repositorys von /var/lib/backup in /var/lib/pgbackrest geändert. (Vorgeschlagen von Michael Renner, Stephen Frost.)
  • Sperrdateien liegen standardmäßig in /tmp/pgbackrest. Heute wäre /run/pgbackrest der bevorzugte Ort, würde jedoch Init-Skripte erfordern, die diese Version nicht enthält. Das Sperrverzeichnis lässt sich mit lock-path konfigurieren.
  • Protokolldateien liegen standardmäßig in /var/log/pgbackrest und erhalten keinen Datumszusatz mehr, damit sie mit logrotate verwaltet werden können. Das Protokollverzeichnis lässt sich mit log-path konfigurieren. (Vorgeschlagen von Stephen Frost.)
  • Name der ausführbaren Datei von pg_backrest in pgbackrest geändert. (Vorgeschlagen von Michael Renner, Stephen Frost.)
  • Alle aus PGDATA verknüpften Dateien und Verzeichnisse sind jetzt im Backup enthalten. Standardmäßig werden Verknüpfungen als Dateien oder Verzeichnisse direkt in PGDATA wiederhergestellt. Mit --link-all lassen sich alle Verknüpfungen an ihren ursprünglichen Speicherorten wiederherstellen. Mit --link-map lässt sich eine Verknüpfung einem neuen Speicherort zuordnen.
  • Option --tablespace entfernt und durch --tablespace-map-all ersetzt, deren Name die Funktion deutlicher beschreiben sollte.
  • Protokollstufe detail hinzugefügt, die mehr Informationen als info ausgibt, ohne so ausführlich wie debug zu sein.

Versionen vor der ersten stabilen Veröffentlichung

v0.92 – Versionshinweise

Fehler beim Repository-Pfad auf der Befehlszeile behoben

Veröffentlicht am 6. April 2016

Fehlerbehebungen:

  • Fehler behoben, durch den der Hauptprozess --repo-remote-path statt --repo-path an den entfernten Prozess übergab. Dadurch wurden Sperrdateien im Standard-Repository-Verzeichnis /var/lib/backup erstellt, was gewöhnlich zum Scheitern führte. Dies trat nur auf, wenn --repo-remote-path auf der Befehlszeile statt in pg_backrest.conf definiert war. (Gemeldet von Jan Wieck.)

v0.91 – Versionshinweise

Tablespace-Fehler behoben und kleinere Verbesserungen

Veröffentlicht am 22. März 2016

WICHTIGE FEHLERBEHEBUNG FÜR TABLESPACES: In 0.90 wurde versehentlich eine Änderung des Repository-Formats eingeführt. Dadurch war ein auf dem Datenträger gespeichertes Backup mit Tablespaces kein gültiger PostgreSQL-Cluster mehr. Dies betraf nur Benutzer, die Backups zur Wiederherstellung von PostgreSQL-Clustern direkt kopierten, statt den Befehl restore zu verwenden. Die Korrektur ist jedoch mit älteren Backups, die Tablespaces enthalten, unabhängig von der Wiederherstellungsmethode nicht kompatibel: pgBackRest meldet Fehler und verweigert die Wiederherstellung. Für alle Cluster mit Tablespaces sollten unmittelbar nach der Installation von Version 0.91 neue vollständige Backups erstellt werden. Müssen ältere Backups wiederhergestellt werden, ist eine zum Backup passende pgBackRest-Version zu verwenden.

Fehlerbehebungen:

  • In pgBackRest 0.90 eingeführte Repository-Inkompatibilität behoben. (Gemeldet von Evan Benoit.)

Funktionen:

  • global/pg_control beim Backup zuletzt kopieren.
  • .info- und .manifest-Dateien zunächst temporär schreiben, bevor sie an ihren endgültigen Speicherort verschoben und mit fsync synchronisiert werden.
  • Option --no-start-stop in --no-online umbenannt.

Neue Funktionen der Testsuite:

  • Statische Quellcodeanalyse mit Perl-Critic; derzeit wird die Stufe gentle bestanden.

v0.90 – Versionshinweise

Unterstützung für 9.5, verschiedene Verbesserungen und kleinere Fehlerbehebungen

Veröffentlicht am 7. Februar 2016

Fehlerbehebungen:

  • Fehler behoben, durch den --no-archive-check einen Konfigurationsfehler auslöste. (Gemeldet von Jason O’Donnell.)
  • Fehler behoben, durch den eine temporäre WAL-Datei nach einem Systemabsturz im ungünstigen Moment das nächste archive-push scheitern lassen konnte.
  • retention-archive kann jetzt sicher niedriger als die Backup-Aufbewahrung (retention-full oder retention-diff) eingestellt werden, ohne zusätzlich archive-copy=n anzugeben. WAL, das Backups außerhalb der Archivaufbewahrung in einen konsistenten Zustand versetzt, bleibt im Archiv erhalten. PITR ist für diese Backups außerhalb der Archivaufbewahrung allerdings nicht möglich.

Funktionen:

  • Beim Sichern und Wiederherstellen von Tablespaces bearbeitet pgBackRest nur das Unterverzeichnis für die jeweils verwendete PostgreSQL-Version. Da mehrere Versionen in einem Tablespace liegen können, insbesondere während eines binären Upgrades, verhindert dies das Kopieren überflüssiger Dateien beim Backup und das mögliche Löschen anderer Versionen bei der Wiederherstellung. Dies gilt nur für PostgreSQL >= 9.0; frühere PostgreSQL-Versionen konnten kein gemeinsames Tablespace-Verzeichnis nutzen.
  • Fehler ausgeben, wenn archive-check=y gesetzt ist, archive_command aber nicht pg_backrest ausführt. (Beigetragen von Jason O’Donnell. Geprüft von David Steele.)
  • Fehlermeldung bei fehlendem repo-path oder repo-remote-path verbessert.
  • Prüfungen für die Wiederherstellungsoptionen --delta und --force hinzugefügt, um sicherzustellen, dass das Ziel ein gültiges $PGDATA-Verzeichnis ist. pgBackRest prüft, ob PG_VERSION oder eine von einer abgebrochenen Wiederherstellung verbliebene backup.manifest vorhanden ist. Fehlen beide Dateien, werden --delta und --force deaktiviert. Die Wiederherstellung wird dennoch fortgesetzt, sofern weder im $PGDATA-Verzeichnis noch in einem Tablespace-Verzeichnis Dateien liegen; andernfalls wird sie abgebrochen.
  • Bei der Wiederherstellung mit --set=latest, dem Standardwert, wird das tatsächlich wiederhergestellte Backup protokolliert.
  • Unterstützung für partielle WAL-Segmente und die Einstellung recovery_target_action aus PostgreSQL 9.5. archive_mode = 'always' wird noch nicht unterstützt.
  • Unterstützung für die in PostgreSQL 9.4 eingeführte Recovery-Einstellung recovery_target = 'immediate'.
  • Folgende Tablespace-Prüfungen hinzugefügt: Pfade oder Dateien in pg_tblspc, relative Verknüpfungen in pg_tblspc und Tablespaces in $PGDATA. Alle drei Fälle erzeugen Fehler.

v0.89 – Versionshinweise

Zeitüberschreitungsfehler behoben und Wiederherstellung aus schreibgeschützten Repositorys

Veröffentlicht am 24. Dezember 2015

Fehlerbehebungen:

  • Fehler behoben, durch den länger laufende Backups oder Wiederherstellungen mit entferntem Zugriff und Threads eine Zeitüberschreitung auslösten. Keepalives verhindern jetzt, dass der entfernte Prozess des Hauptprozesses sein Zeitlimit überschreitet, während die entfernten Prozesse der Threads die Arbeit erledigen. Auch die Fehlermeldung bei Zeitüberschreitungen wurde verbessert, um die Fehlersuche zu erleichtern. (Gemeldet von Stephen Frost.)

Funktionen:

  • Wiederherstellungen aus einem schreibgeschützten Repository mit --no-lock und --log-level-file=off ermöglicht. --no-lock ist nur bei Wiederherstellungen zulässig.

v0.88 – Versionshinweise

Dokumentation und kleinere Fehlerbehebungen

Veröffentlicht am 22. November 2015

Fehlerbehebungen:

  • Fehler behoben, durch den start und stop die Option --config erforderten. (Gemeldet von Dmitry Didovicher.)
  • Fehler behoben, durch den Protokolldateien überschrieben statt ergänzt wurden. (Gemeldet von Stephen Frost, Dmitry Didovicher.)
  • Fehler behoben, durch den backup-user nicht optional war.

Funktionen:

  • In den Backup-Verzeichnissen des Repositorys werden keine symbolischen Verknüpfungen mehr erstellt. Diese konnten praktisch überallhin zeigen und potenziell gefährlich sein. Bei der Wiederherstellung werden symbolische Verknüpfungen weiterhin neu erstellt. (Vorgeschlagen von Stephen Frost.)
  • Aussagekräftigere Meldungen beim Entfernen abgelaufener Backups hinzugefügt. Das Entfernen vollständiger und differenzieller Backups wird jeweils in einer Zeile zusammen mit allen entfernten abhängigen Backups protokolliert.
  • Die Archivaufbewahrung wird automatisch auf die Aufbewahrung vollständiger Backups gesetzt, sofern sie nicht ausdrücklich konfiguriert ist.

Neue Inhalte der Dokumentation:

  • Benutzerhandbuch um Delta-Wiederherstellungen, das Entfernen abgelaufener Backups, dedizierte Backup-Hosts, das Starten und Stoppen von pgBackRest sowie Replikation ergänzt.

v0.87 – Versionshinweise

Website und Benutzerhandbuch

Veröffentlicht am 28. Oktober 2015

Funktionen:

  • backup_label.old und recovery.done werden jetzt von Backups ausgeschlossen.

Neue Inhalte der Dokumentation:

  • Neues Benutzerhandbuch hinzugefügt, das die Grundlagen von pgBackRest und einige fortgeschrittene Themen einschließlich PITR behandelt. Weitere Inhalte folgen, aber ein Anfang ist gemacht. (Beigetragen von David Steele, Stephen Frost. Geprüft von Michael Renner, Cynthia Shang, Eric Radman, Dmitry Didovicher.)

v0.85 – Versionshinweise

Befehle start/stop und kleinere Fehlerbehebungen

Veröffentlicht am 8. Oktober 2015

Fehlerbehebungen:

  • Fehler behoben, durch den nach einem vollständig erfolgreichen Backup oder einer Wiederherstellung dennoch ein Fehler zurückgegeben werden konnte.
  • Fehler behoben, durch den das Fortsetzen scheiterte, wenn nach einem fehlgeschlagenen Backup temporäre Dateien im Backup-Hauptverzeichnis lagen. Dies trat besonders dann auf, wenn der Backup-Prozess während des Kopierens beendet wurde.

Funktionen:

  • Befehle stop und start hinzugefügt, um pgBackRest-Prozesse auf einem System zu verhindern, auf dem PostgreSQL heruntergefahren ist oder das aus anderen Gründen ruhen soll.
  • Experimentelle Unterstützung für PostgreSQL 9.5 beta1. Änderungen der Control-Version oder WAL-Kennung in künftigen Versionen können die Kompatibilität aufheben; die Unterstützung wird jedoch mit jeder pgBackRest-Version entsprechend aktualisiert. Alle Regressionstests bestehen mit Ausnahme der Tests für --target-resume, dessen Funktion sich in 9.5 geändert hat. Für .partial-WAL-Segmente gibt es noch keine Tests.

v0.82 – Versionshinweise

Refactoring, Befehlszeilenhilfe und kleinere Fehlerbehebungen

Veröffentlicht am 14. September 2015

Fehlerbehebungen:

  • Fehler behoben, durch den fortgesetzte komprimierte Backups vorhandene Dateien nicht beibehielten.
  • Fehler behoben, durch den beim Fortsetzen sowie bei inkrementellen und differenziellen Backups nicht sichergestellt wurde, dass das vorherige Backup dieselben Einstellungen für Komprimierung und Hardlinks hatte.
  • Fehler behoben, durch den ein kaltes Backup mit --no-start-stop auf einem laufenden PostgreSQL-Cluster ohne --force gestartet werden konnte.
  • Fehler behoben, durch den ein Thread gestartet werden konnte, obwohl keiner angefordert war.
  • Fehler behoben, durch den die pgBackRest-Versionsnummer in backup.info und archive.info nach einem Upgrade oder Downgrade nicht aktualisiert wurde.
  • Fehler behoben, durch den info eine Ausnahme auslöste, wenn das Repository keine Stanzas enthielt. (Gemeldet von Stephen Frost.)
  • Fehler behoben, durch den NOTICEs von PostgreSQLs pg_stop_backup() an stderr ausgegeben wurden. (Gemeldet von Stephen Frost.)

Funktionen:

  • Experimentelle Unterstützung für PostgreSQL 9.5 alpha2. Änderungen der Control-Version oder WAL-Kennung in künftigen Versionen können die Kompatibilität aufheben; die Unterstützung wird jedoch mit jeder pgBackRest-Version entsprechend aktualisiert. Alle Regressionstests bestehen mit Ausnahme der Tests für --target-resume, dessen Funktion sich in 9.5 geändert hat. Für .partial-WAL-Segmente gibt es noch keine Tests.

Verbesserungen:

  • Option und Abschnitt recovery-setting in recovery-option umbenannt, um die pgBackRest-Namenskonventionen einheitlicher anzuwenden.
  • Dynamisches Laden von Modulen hinzugefügt, um Befehle und insbesondere die asynchrone Archivierung zu beschleunigen.

Neue Inhalte der Dokumentation:

  • Die Befehlszeilenhilfe wird jetzt aus derselben XML-Quelle wie die übrige Dokumentation erzeugt und enthält deutlich mehr Einzelheiten.

v0.80 – Versionshinweise

DBI-Unterstützung, Stabilität und Komfortfunktionen

Veröffentlicht am 9. August 2015

Fehlerbehebungen:

  • Fehler behoben, durch den info für das älteste und neueste Backup jeweils die aktuelle Uhrzeit als formatierten Zeitstempel ausgab. Nur die Ausgabe als text war betroffen; json gab die korrekten Epoch-Werte aus. (Gemeldet von Michael Renner.)
  • Protokollfehler behoben, der das Protokollieren von ssh-Fehlern, insbesondere beim Verbindungsaufbau, verhinderte.

Funktionen:

  • Das Repository wird jetzt mit einheitlichen Verzeichnis- und Dateiberechtigungen erstellt und aktualisiert. Standardmäßig wird umask auf 0000 gesetzt; dies lässt sich mit neutral-umask deaktivieren. (Vorgeschlagen von Cynthia Shang.)
  • Option stop-auto hinzugefügt, um fehlgeschlagene Backups beim Start eines neuen Backups automatisch zu stoppen.
  • Option db-timeout hinzugefügt, um die Wartezeit von pgBackRest auf die Rückkehr von pg_start_backup() und pg_stop_backup() zu begrenzen.
  • pg_control zu Beginn der Wiederherstellung entfernen und erst ganz am Ende zurückkopieren. Dies verhindert, dass PostgreSQL einen teilweise wiederhergestellten Cluster startet.
  • Prüfungen ergänzt, um die Übereinstimmung von db-path und db-port sicherzustellen. Dazu werden das vom Cluster gemeldete data_directory mit db-path und die gemeldete Version mit dem aus pg_control gelesenen Wert verglichen. Für db-socket-path wird geprüft, ob der Pfad absolut ist.
  • Experimentelle Unterstützung für PostgreSQL 9.5 alpha1. Änderungen der Control-Version oder WAL-Kennung in künftigen Versionen können die Kompatibilität aufheben; die Unterstützung wird jedoch mit jeder pgBackRest-Version entsprechend aktualisiert. Alle Regressionstests bestehen mit Ausnahme der Tests für --target-resume, dessen Funktion sich in 9.5 geändert hat. Für .partial-WAL-Segmente gibt es noch keine Tests.

Verbesserungen:

  • Für PostgreSQL-Verbindungen werden jetzt Perls DBI und DBD::Pg statt psql verwendet. Die Einstellungen cmd-psql und cmd-psql-option wurden entfernt und durch db-port und db-socket-path ersetzt. DBD::Pg gemäß der Installationsanleitung für das jeweilige Betriebssystem installieren.

Neue Funktionen der Testsuite:

  • vagrant-Testkonfigurationen für Ubuntu 14.04 und CentOS 7 hinzugefügt.

v0.78 – Versionshinweise

CPAN-Abhängigkeiten entfernt, Stabilität verbessert

Veröffentlicht am 13. Juli 2015

Verbesserungen:

  • Abhängigkeit von CPAN-Paketen für den Betrieb mit mehreren Threads entfernt. Die Pakete threads und Thread::Queue zu aktualisieren, kann weiterhin sinnvoll sein, ist aber nicht mehr erforderlich.
  • Ansteigende Wartezeiten verwenden jetzt eine Fibonacci-Folge statt einer geometrischen Folge. Dadurch wachsen sie weniger stark und bleiben dennoch angemessen.

Neue Funktionen der Testsuite:

  • vagrant-Testkonfigurationen für Ubuntu 12.04 und CentOS 6 hinzugefügt.

v0.77 – Versionshinweise

Unterstützung für CentOS/RHEL 6 und Protokollverbesserungen

Veröffentlicht am 30. Juni 2015

Funktionen:

  • Datei- und Verzeichnissynchronisierung zum Objekt File hinzugefügt, um Backups, Wiederherstellungen und Archivierung zusätzlich abzusichern. (Vorgeschlagen von Andres Freund.)
  • Unterstützung für Perl 5.10.1 und OpenSSH 5.3 hinzugefügt, die unter CentOS/RHEL 6 Standard sind. (Vorgeschlagen von Eric Radman.)
  • Fehlermeldung verbessert, wenn ein Backup ohne gesetzten archive_command und ohne --no-archive-check ausgeführt wird. (Vorgeschlagen von Eric Radman.)

v0.75 – Versionshinweise

Neues Repository-Format, Befehl info und experimentelle Unterstützung für 9.5

Veröffentlicht am 14. Juni 2015

WICHTIGER HINWEIS: Diese Version mit grundlegender Umstellung ist nicht mit älteren pgBackRest-Versionen kompatibel. Manifestformat, Speicherstruktur und Namen der Binärdateien wurden geändert. Für die Backups dieser pgBackRest-Version muss ein neues Repository erstellt werden. Das alte Repository muss noch eine Zeit lang aufbewahrt werden, falls eine Wiederherstellung nötig ist. Die Datei pg_backrest.conf hat sich nicht geändert. Verweise auf pg_backrest.pl in cron oder anderswo müssen jedoch in pg_backrest ohne die Endung .pl geändert werden.

Funktionen:

  • Befehl info hinzugefügt.
  • Die Protokollierung verwendet jetzt ungepufferte Ausgabe. Dadurch sollten Protokolldateien, in die mehrere Threads schreiben, weniger ungeordnet sein. (Vorgeschlagen von Michael Renner.)
  • Experimentelle Unterstützung für PostgreSQL 9.5. Änderungen der Control-Version oder WAL-Kennung können die Kompatibilität aufheben; die Unterstützung wird jedoch mit jeder Version aktualisiert.

Verbesserungen:

  • Effizientere Dateireihenfolge für backup. Dateien werden in absteigender Größenreihenfolge kopiert, damit am Ende nicht ein einzelner Thread eine große Datei kopieren muss. Für restore war dies bereits implementiert.

v0.70 – Versionshinweise

Stabilere Archivierung, bessere Protokollierung und Hilfe

Veröffentlicht am 1. Juni 2015

Fehlerbehebungen:

  • Fehler behoben, durch den archive-copy bei einem inkrementellen oder differenziellen Backup mit hardlink=n scheiterte. In diesem Fall existiert pg_xlog noch nicht und muss erstellt werden. (Gemeldet von Michael Renner.)
  • Fehler in der asynchronen Archivierung behoben, durch den archive-push beim Erreichen von archive-max-mb nicht korrekt 0 zurückgab. Die asynchrone Prüfung erfolgt jetzt nach der Übertragung, damit die Stoppdatei nicht zweimal entfernt werden muss. Außerdem wurden Unit-Tests für diesen Fall ergänzt und Fehlermeldungen verständlicher gestaltet. (Gemeldet von Michael Renner.)
  • Sperrfehler behoben, der mehrere gleichartige Operationen für dieselbe Stanza zulassen konnte. Die Datenintegrität schien dadurch nicht beeinträchtigt, jedoch entstanden unnötige Fehler bei der Archivierung und möglicherweise Fehler bei Backups oder Wiederherstellungen. (Gemeldet von Michael Renner.)

Funktionen:

  • Doppelte WAL-Segmente dürfen jetzt archiviert werden, wenn ihre Prüfsummen übereinstimmen. Dies ist für bestimmte Recovery-Szenarien erforderlich.
  • Kommentare und das Deaktivieren von Zeilen in pg_backrest.conf mit dem Zeichen # ermöglicht. Nur ein # als erstes Zeichen einer Zeile wird berücksichtigt. (Vorgeschlagen von Michael Renner.)
  • Protokollierung vor pg_start_backup() verbessert, damit erkennbar ist, wann das Backup auf einen Checkpoint wartet. (Vorgeschlagen von Michael Renner.)
  • Verschiedene Korrekturen an Befehlsverhalten und Protokollierung. (Geprüft von Michael Renner. Vorgeschlagen von Michael Renner.)

Verbesserungen:

  • Modul JSON durch JSON::PP ersetzt, das zum Perl-Kern gehört.

Fehlerbehebungen in der Dokumentation:

  • Verschiedene Korrekturen in der Hilfe. (Geprüft von Michael Renner. Gemeldet von Michael Renner.)

v0.65 – Versionshinweise

Verbessertes Fortsetzen und bessere Protokollierung bei der Wiederherstellung, kompakte Wiederherstellungen

Veröffentlicht am 11. Mai 2015

Fehlerbehebungen:

  • Fehler behoben, durch den kein absoluter Pfad in recovery.conf geschrieben wurde, wenn die Wiederherstellung mit einem relativen Pfad lief.

Funktionen:

  • Unterstützung für das Fortsetzen verbessert. Bereits vorhandene Dateien werden auf Änderungen geprüft; das Manifest wird häufiger gespeichert, damit Prüfsummen während des Backups erhalten bleiben. Zusätzliche Unit-Tests prüfen die einzelnen Fälle beim Fortsetzen.
  • Das Fortsetzen ist jetzt optional. Es lässt sich mit der Einstellung resume oder auf der Befehlszeile mit --no-resume deaktivieren.
  • Mehr info-Meldungen bei der Wiederherstellung. Zuvor hatten die meisten Wiederherstellungsmeldungen die Stufe debug, sodass wenig im Protokoll erschien.
  • Einstellung tablespace hinzugefügt, um Tablespaces in pg_tblspc wiederherzustellen. Dadurch entstehen kompakte Wiederherstellungen, die für Entwicklung, Staging usw. praktisch sind. Derzeit lassen sich diese Wiederherstellungen nicht sichern, da pgBackRest unter pg_tblspc ausschließlich Verknüpfungen erwartet.

v0.61 – Versionshinweise

Fehler bei unkomprimiertem entferntem Ziel behoben

Veröffentlicht am 21. April 2015

Fehlerbehebungen:

  • Pufferfehler behoben, der beim Kopieren großer, gut komprimierbarer Dateien an ein unkomprimiertes entferntes Ziel auftreten konnte. Der Fehler wurde im Dekomprimierungscode erkannt und führte zu einem fehlgeschlagenen statt einem beschädigten Backup. Erfolgreiche Backups aus früheren Versionen sollten daher nicht betroffen sein.

v0.60 – Versionshinweise

Bessere Versionsunterstützung und WAL-Verbesserungen

Veröffentlicht am 19. April 2015

Fehlerbehebungen:

  • Das Übertragen doppelter WAL-Segmente erzeugt jetzt einen Fehler. Zuvor funktionierte dies nur bei deaktivierten Prüfsummen.

Funktionen:

  • Datenbanksystemkennungen (IDs) stellen sicher, dass alle WAL-Segmente eines Archivs zusammengehören. Dies sollte Fehlkonfigurationen verhindern, bei denen WAL mehrerer Cluster in dasselbe Archiv gelangt.

Neue Funktionen der Testsuite:

  • Regressionstests funktionieren zurück bis PostgreSQL 8.3.

v0.50 – Versionshinweise

Wiederherstellung und vieles mehr

Veröffentlicht am 25. März 2015

Fehlerbehebungen:

  • Fehlerhafte Prüfsummen korrigiert; sie funktionieren jetzt bei normalen und fortgesetzten Backups. Die Erkenntnis, dass Prüfsummen und Prüfsummendeltas funktional getrennt werden sollten, hat mehrere Dinge vereinfacht. Für Prüfsummendeltas wurde Issue #28 angelegt.
  • Fehler behoben, durch den ein Backup auf Grundlage eines abgebrochenen Backups mit anderem Typ oder anderem vorherigen Backup fortgesetzt werden konnte.

Funktionen:

  • Wiederherstellungsfunktion hinzugefügt.
  • Alle Optionen können jetzt auf der Befehlszeile gesetzt werden, wodurch pg_backrest.conf optional wird.
  • Komprimierung und Dekomprimierung erfolgen jetzt ohne Threads; Prüfsumme und Größe werden im Datenstrom berechnet. Dateiprüfsummen sind damit nicht mehr optional.
  • Option --no-start-stop hinzugefügt, um Backups bei heruntergefahrenem Postgres zu ermöglichen. Ist postmaster.pid vorhanden, muss --force angegeben werden, damit das Backup startet. Läuft Postgres noch, wird dabei wahrscheinlich ein inkonsistentes Backup erstellt. Diese Option dient vor allem Unit-Tests, kann aber auch praktische Anwendungen haben.
  • Prüfsumme für backup.manifest hinzugefügt, um beschädigte oder veränderte Manifeste zu erkennen.
  • Die Verknüpfung latest zeigt immer auf das letzte Backup. Dies erhöht den Bedienkomfort und vereinfacht Wiederherstellungen.

Neue Funktionen der Testsuite:

  • Umfassendere Unit-Tests in allen Bereichen.

v0.30 – Versionshinweise

Umstrukturierung des Kerns und Unit-Tests

Veröffentlicht am 5. Oktober 2014

Neue Inhalte der Dokumentation:

  • Dringend benötigte Dokumentation hinzugefügt.

Neue Funktionen der Testsuite:

  • Recht umfassende Unit-Tests für alle grundlegenden Operationen. Hier bleibt sicher noch Arbeit, aber an Unit-Tests gibt es immer etwas zu tun.

v0.19 – Versionshinweise

Verbesserte Fehlermeldungen und Fehlerbehandlung

Veröffentlicht am 13. Mai 2014

Fehlerbehebungen:

  • Schwerwiegenden Fehler gefunden und behoben: file_copy() ignorierte standardmäßig Fehler. Zudem ließ ein Problem in file_exists() die Prüfung scheitern, obwohl die Datei existierte. Zusammen hätten diese Fehler ohne Fehlermeldung zu einem beschädigten Backup führen können, auch wenn dies sehr unwahrscheinlich ist.

v0.18 – Versionshinweise

Nicht schwerwiegenden Fehler bei fehlender Archivdatei zurückgeben

Veröffentlicht am 13. April 2014

Fehlerbehebungen:

  • archive-get gibt jetzt 1 zurück, wenn die Archivdatei fehlt, um dies von schwerwiegenden Fehlern wie gescheiterten ssh-Verbindungen oder Dateikopien zu unterscheiden. Damit erkennt PostgreSQL, dass der Archivdatenstrom regulär beendet wurde. Mögliche Lücken im Archivdatenstrom werden dabei jedoch nicht berücksichtigt. (Gemeldet von Stephen Frost.)

v0.17 – Versionshinweise

Warnung bei nicht löschbaren Archivverzeichnissen

Veröffentlicht am 3. April 2014

Fehlerbehebungen:

  • Konnte ein Archivverzeichnis, das leer sein sollte, nicht gelöscht werden, gab backrest einen Fehler aus. Eine geeignete Korrektur ist vorgesehen; vorerst wurde daraus eine Warnung, damit die Verarbeitung fortgesetzt werden kann. Dies beeinträchtigte Backups: Mitunter wurde die letzte Archivdatei nicht übertragen, wenn die erste Archivdatei in einem anderen Verzeichnis gelegen hatte und ungünstige Umstände hinzukamen.

v0.16 – Versionshinweise

RequestTTY=yes für SSH-Sitzungen

Veröffentlicht am 1. April 2014

Fehlerbehebungen:

  • RequestTTY=yes zu ssh-Sitzungen hinzugefügt, in der Hoffnung, gelegentliches Hängenbleiben zu verhindern.

v0.15 – Versionshinweise

archive-get hinzugefügt

Veröffentlicht am 29. März 2014

Funktionen:

  • Funktion archive-get zur Unterstützung von Wiederherstellungen hinzugefügt.
  • Option start-fast=y hinzugefügt, um beim Backup-Start einen Checkpoint zu erzwingen.

v0.11 – Versionshinweise

Kleinere Korrekturen

Veröffentlicht am 26. März 2014

Fehlerbehebungen:

  • Option master_stderr_discard bei SSH-Datenbankverbindungen entfernt. Es gab gelegentliches Hängenbleiben, möglicherweise im Zusammenhang mit Problemen, die ursprünglich im Dateicode auftraten. (Gemeldet von Stephen Frost.)
  • Sperrdateikonflikte bei backup und expire auf ERROR geändert. Durch Übernahme aus den Archivsperren standen sie auf DEBUG.

v0.10 – Versionshinweise

Backups und Archivierung funktionieren

Veröffentlicht am 5. März 2014

Funktionen:

  • Noch keine Wiederherstellungsfunktion, aber die Backup-Verzeichnisse sind konsistente PostgreSQL-Datenverzeichnisse. Die Dateien müssen entweder dekomprimiert werden, oder die Komprimierung muss beim Backup deaktiviert sein. Unkomprimierte Backups auf ZFS oder einem ähnlichen Dateisystem eignen sich gut, da sie lokal über einen Snapshot wiederhergestellt werden können, um logische Backups zu erstellen oder gezielt Daten wiederherzustellen.
  • Die Archivierung verwendet einen einzelnen Thread. Auf unseren Datenbanken mit mehreren Terabyte und hohem Schreibvolumen war dies bisher kein Problem. Empfohlen wird ein großes WAL-Volume oder die asynchrone Option mit einem großen, nahe gelegenen Volume.
  • Backups verwenden mehrere Threads. Die Bibliothek Net::OpenSSH scheint jedoch nicht zu 100% threadsicher zu sein und bleibt daher sehr selten in einem Thread hängen. Ein allgemeines Prozesszeitlimit behebt dies, indem der Prozess beendet wird. Ja, eine sehr unschöne Lösung.
  • Bei jedem fortgesetzten Backup gehen Prüfsummen verloren. Wird mehrfach fortgesetzt, zeichnet nur das letzte Backup Prüfsummen auf. Prüfsummen früherer Backups werden korrekt erfasst, und ein vollständiges Backup setzt alles zurück.
  • backup.manifest wird als Storable geschrieben, da Config::IniFile offenbar nicht gut mit großen Dateien umgeht. Eine Speicherung als menschenlesbarer Text ist ausdrücklich gewünscht.

Neue Inhalte der Dokumentation:

  • Überhaupt keine Dokumentation außerhalb des Codes. Abgesehen von diesen Versionshinweisen.

7 - Häufig gestellte Fragen

Häufig gestellte Fragen zu Backups, Wiederherstellung, Konfiguration und Fehlerbehebung mit pgBackRest.

Einführung

Die häufig gestellten Fragen erläutern konkrete Fragen, die im Benutzerhandbuch, in der Konfigurationsreferenz oder in der Befehlsreferenz möglicherweise nicht behandelt werden. Falls sich hier keine Einzelheiten zu Ihrem Problem finden, ist auch die Issue-Liste von pgBackRest auf GitHub eine nützliche Anlaufstelle.

Was tun bei der Fehlermeldung “could not find WAL segment”?

Dieser Fehler kann viele verschiedene Ursachen haben, darunter:

  • ein falsch konfigurierter archive_command
  • fehlerhafte pgBackRest-Konfigurationsdateien
  • Netzwerk- oder Berechtigungsprobleme
  • Konfigurationsprobleme eines Drittanbieterprodukts (z. B. S3, Swift oder Minio)
  • eine große Menge WAL in der Warteschlange für die Archivierung

Folgende Schritte werden empfohlen:

  • Den archive_command in PostgreSQL prüfen.
  • Die pgBackRest-Konfiguration auf jedem Host prüfen (z. B. gehören die pg*-Einstellungen auf den Repository-Host und die repo*-Einstellungen auf den pg-Host).
  • Den Befehl check ausführen und dabei --archive-timeout auf einen Wert über dem in der pgBackRest-Konfigurationsdatei festgelegten Wert (oder dem Standardwert) setzen, um festzustellen, ob die WAL-Warteschlange mehr Zeit zum Leeren benötigt. Erzeugt das System viel WAL, sollte die asynchrone Archivierung in Betracht gezogen werden.

Wie lässt sich ein Backup-Satz manuell löschen?

Ein vollständiger Backup-Satz kann mit der Option --set entfernt werden, wie unter Befehlsreferenz: Expire erläutert.

Wie lassen sich Optionen für jeden Befehl separat konfigurieren?

pgBackRest kann Optionen in der Konfigurationsdatei für jeden Befehl separat festlegen. Stanza für den Cluster konfigurieren beschreibt diese Funktion und die Rangfolge der Optionen.

Beispielsweise lässt sich die Option process-max für jeden Befehl optimieren:

[global]
# used where not overridden
process-max=2

[global:backup]
# more cores for backup
process-max=4

[global:restore]
# all the cores for restore
process-max=8

[global:archive-push]
# more cores for archive-push
process-max=3

[global:archive-get]
# fewer cores for archive-get
process-max=1

Darf der Name meines S3-Buckets Punkte enthalten?

RFC-2818 erlaubt nicht, dass Platzhalter auf einen Punkt (.) passen. Deshalb dürfen S3-Bucket-Namen keine Punkte enthalten. Enthält der S3-Bucket-Name Punkte, tritt ein Fehler wie “unable to find hostname ‘my.backup.bucket.s3.amazonaws.com’ in certificate common name or subject alternative names” auf.

Eine Ausnahme ist repo-s3-uri-style=path: Hier wird der Bucket der URI statt dem Host vorangestellt. Da der Bucket nicht Teil des Hostnamens ist, wird das Zertifikat allein mit dem Endpunkt abgeglichen, und Punkte im Bucket-Namen sind unproblematisch. URIs im Pfadstil werden allerdings nicht von allen S3-kompatiblen Objektspeichern unterstützt.

Wo gibt es Pakete für ältere pgBackRest-Versionen?

Das Repository apt.postgresql.org führt ein Archiv älterer Versionen . Debian hält außerdem Snapshots aller Test-Builds vor.

Warum scheitert ein Backup-Versuch bei backup-standby=y, wenn die Standby-Datenbank ausgefallen ist?

Backups vom Standby sollen in der Regel den Primärserver entlasten. Bei einem Ausfall des Standbys auf Backups vom Primärserver zu wechseln, widerspricht daher oft diesem Ziel. Den Primärserver zusätzlich zu belasten, wenn im System bereits Fehler vorliegen, wird nicht empfohlen. Backups sind nicht kritisch, solange ein hinreichend aktuelles vorhanden ist; entscheidend ist, dass die WAL-Archivierung Schritt hält. Sobald das System wieder stabil ist, bleibt genügend Zeit für ein Backup.

Ist ein Backup unbedingt erforderlich, besteht die Lösung darin, weitere Standbys bereitzustellen oder backup-standby zu entfernen. Dies lässt sich auf der Befehlszeile mit --no-backup-standby überschreiben, sodass für ein einmaliges Backup keine Neukonfiguration erforderlich ist.

Sollte das Repository auf einem Standby-Host eingerichtet werden?

Nein. Wenn Primär- und Standby-Datenbanken konfiguriert sind, sollten die pgBackRest-Konfigurationsdateien symmetrisch sein, damit Failover nahtlos funktionieren. Andernfalls müssen die Konfigurationen bei einem Failover geändert werden, oder es können weitere Probleme entstehen.

Weitere Informationen enthält der Abschnitt Dedizierter Repository-Host im Benutzerhandbuch.

Warum scheint die zeitbasierte Point-in-Time-Recovery nicht zu funktionieren?

Der häufigste Fehler bei einer zeitbasierten Point-in-Time-Recovery ist die Auswahl eines Backups, das nach der Zielzeit abgeschlossen wurde. Bei --type=time ohne die Option --set durchsucht pgBackRest die konfigurierten Repositorys nach einem Backup, das vor der mit --target= angegebenen Zeit abgeschlossen wurde. Wird kein geeignetes Backup gefunden, meldet pgBackRest einen Fehler, statt das neueste Backup wiederherzustellen. Ein nach der Zielzeit abgeschlossenes Backup kann durch WAL-Wiedergabe nicht auf diesen früheren Zeitpunkt zurückgeführt werden.

Für die Option --set zunächst den Befehl info ausführen und ein Backup auswählen, dessen Endzeitpunkt vor dem Zielzeitpunkt liegt. Bei der Wiederherstellung dann --set=BACKUP_LABEL angeben, wobei BACKUP_LABEL den gewählten Backup-Satz bezeichnet.

Weitere Informationen enthält der Abschnitt Point-in-Time-Recovery im Benutzerhandbuch.

Was bedeutet das Suffix im WAL-Archiv?

Das Suffix ist die SHA1-Prüfsumme zur Überprüfung der Dateiintegrität. Es kann nicht weggelassen werden.

Dauert die Wiederherstellung bestimmter Backup-Typen (vollständig, differenziell, inkrementell) länger?

Die verschiedenen Backup-Typen benötigen dieselbe Wiederherstellungszeit. Die Wiederherstellung ruft Dateien anhand des Backup-Manifests ab, das bei inkrementellen oder differenziellen Backups auf Dateien eines früheren Backups verweisen kann. Die Zeit für das Erstellen eines Backups kann sich je nach Backup-Typ unterscheiden. Die Datenbankgröße bestimmt hingegen die Wiederherstellungszeit, sofern Datenträger-I/O, Netzwerk-I/O usw. gleich sind.

Wie lässt sich ein Backup zur Verwendung in einer vom Netzwerk isolierten Umgebung exportieren?

pgBackRest verwendet das Repository nicht nur zum Speichern von Backups und WAL-Archiven, sondern auch für wesentliche Metadaten, die für Funktionen wie Komprimierung, Verschlüsselung und Dateibündelung erforderlich sind. Deshalb funktioniert es in der Regel nicht, lediglich ein Backup zusammen mit einer Teilmenge der WAL-Dateien zu kopieren, sofern nicht sehr spezifische und restriktive Bedingungen erfüllt sind.

Es gibt jedoch eine Alternative, wenn ein eigenständiger Export einer Datenbank erstellt werden soll, der sich beispielsweise per USB übertragen lässt. Ein Backup mit aktivierter Option --archive-copy stellt sicher, dass die erforderlichen WAL-Segmente zusammen mit dem Backup gespeichert werden. Dieses anschließend mit --type=none --pg1-path=/your/target/path wiederherstellen. Dadurch entsteht ein wiederhergestelltes PostgreSQL-Datenverzeichnis, in dem alle erforderlichen WAL-Dateien bereits in pg_wal liegen, ähnlich dem Ergebnis von pg_basebackup.

Dieses Verzeichnis kann dann auf ein anderes System kopiert werden. PostgreSQL sollte daraus eine Recovery durchführen können, ohne auf das pgBackRest-Repository zugreifen zu müssen.

Bei der Recovery dieses Backups wird die Timeline nicht gewechselt. Deshalb sollte dieser Cluster kein WAL in das ursprüngliche Repository übertragen, aus dem er exportiert wurde. Befindet sich der neue Cluster in einer vom Netzwerk isolierten Umgebung, sollte dies kein Problem darstellen.

8 - Projektmetriken

Kennzahlen zur Codeabdeckung und Qualitätsstatistiken des pgBackRest-Projekts.

Codeabdeckung

pgBackRest strebt für den C-Kerncode in /src eine vollständige Funktions-, Zweig- und Zeilenabdeckung an.

Die Funktions- und Zeilenabdeckung ist ausnahmslos vollständig.

Die Zweigabdeckung schließt Zweige innerhalb von Makros und assert()-Aufrufen aus. Makros haben eigene Unit-Tests und müssen daher nicht an jeder Stelle getestet werden, an der sie vorkommen. Für Assertions wird keine vollständige Zweigabdeckung erwartet, da sie Bedingungen prüfen, die immer wahr sein sollten.

Verzeichnis Funktionen Zweige Zeilen
build/common 32/32 (100.00%) 72/72 (100.00%) 268/268 (100.00%)
build/config 39/39 (100.00%) 564/564 (100.00%) 1142/1142 (100.00%)
build/error 6/6 (100.00%) 22/22 (100.00%) 71/71 (100.00%)
build/help 13/13 (100.00%) 138/138 (100.00%) 265/265 (100.00%)
build/postgres 8/8 (100.00%) 58/58 (100.00%) 149/149 (100.00%)
command 17/17 (100.00%) 104/104 (100.00%) 210/210 (100.00%)
command/annotate 1/1 (100.00%) 12/12 (100.00%) 31/31 (100.00%)
command/archive 14/14 (100.00%) 98/98 (100.00%) 189/189 (100.00%)
command/archive/get 10/10 (100.00%) 208/208 (100.00%) 447/447 (100.00%)
command/archive/push 12/12 (100.00%) 148/148 (100.00%) 365/365 (100.00%)
command/backup 50/50 (100.00%) 790/790 (100.00%) 1641/1641 (100.00%)
command/check 13/13 (100.00%) 106/106 (100.00%) 214/214 (100.00%)
command/control 4/4 (100.00%) 34/34 (100.00%) 48/48 (100.00%)
command/expire 11/11 (100.00%) 274/274 (100.00%) 392/392 (100.00%)
command/help 8/8 (100.00%) 178/178 (100.00%) 283/283 (100.00%)
command/info 16/16 (100.00%) 430/430 (100.00%) 748/748 (100.00%)
command/local 1/1 (100.00%) — 4/4 (100.00%)
command/remote 1/1 (100.00%) 6/6 (100.00%) 18/18 (100.00%)
command/repo 9/9 (100.00%) 110/110 (100.00%) 195/195 (100.00%)
command/restore 37/37 (100.00%) 726/726 (100.00%) 1350/1350 (100.00%)
command/server 6/6 (100.00%) 24/24 (100.00%) 81/81 (100.00%)
command/stanza 5/5 (100.00%) 106/106 (100.00%) 125/125 (100.00%)
command/verify 22/22 (100.00%) 366/366 (100.00%) 733/733 (100.00%)
common 146/146 (100.00%) 624/624 (100.00%) 1350/1350 (100.00%)
common/compress 12/12 (100.00%) 24/24 (100.00%) 80/80 (100.00%)
common/compress/bz2 13/13 (100.00%) 20/20 (100.00%) 123/123 (100.00%)
common/compress/gz 13/13 (100.00%) 26/26 (100.00%) 118/118 (100.00%)
common/compress/lz4 15/15 (100.00%) 24/24 (100.00%) 116/116 (100.00%)
common/compress/zst 13/13 (100.00%) 12/12 (100.00%) 96/96 (100.00%)
common/crypto 32/32 (100.00%) 88/88 (100.00%) 424/424 (100.00%)
common/error 33/33 (100.00%) 66/66 (100.00%) 179/179 (100.00%)
common/io 61/61 (100.00%) 182/182 (100.00%) 523/523 (100.00%)
common/io/filter 31/31 (100.00%) 92/92 (100.00%) 276/276 (100.00%)
common/io/http 58/58 (100.00%) 292/292 (100.00%) 685/685 (100.00%)
common/io/socket 28/28 (100.00%) 110/110 (100.00%) 339/339 (100.00%)
common/io/tls 37/37 (100.00%) 122/122 (100.00%) 409/409 (100.00%)
common/type 335/335 (100.00%) 922/922 (100.00%) 3123/3123 (100.00%)
config 93/93 (100.00%) 1025/1026 (99.90%) 1649/1649 (100.00%)
db 23/23 (100.00%) 94/94 (100.00%) 301/301 (100.00%)
info 48/48 (100.00%) 240/240 (100.00%) 712/712 (100.00%)
info/manifest 10/10 (100.00%) 132/132 (100.00%) 303/303 (100.00%)
postgres 36/36 (100.00%) 128/128 (100.00%) 333/333 (100.00%)
postgres/interface 4/4 (100.00%) 10/10 (100.00%) 35/35 (100.00%)
protocol 60/60 (100.00%) 266/266 (100.00%) 860/860 (100.00%)
storage 68/68 (100.00%) 304/304 (100.00%) 759/759 (100.00%)
storage/azure 26/26 (100.00%) 162/162 (100.00%) 487/487 (100.00%)
storage/cifs 2/2 (100.00%) — 6/6 (100.00%)
storage/gcs 34/34 (100.00%) 176/176 (100.00%) 574/574 (100.00%)
storage/posix 29/29 (100.00%) 165/166 (99.40%) 328/328 (100.00%)
storage/remote 40/40 (100.00%) 128/128 (100.00%) 568/568 (100.00%)
storage/s3 31/31 (100.00%) 200/200 (100.00%) 661/661 (100.00%)
storage/sftp 39/39 (100.00%) 408/408 (100.00%) 762/762 (100.00%)
GESAMT 1705/1705 (100.00%) 10616/10618 (99.98%) 25148/25148 (100.00%)

Auch die C-Unit-Testmodule in /test/src/module haben eine vollständige Funktions- und Zeilenabdeckung, sind jedoch nicht im Bericht enthalten.