Sicherungs- und Notfallwiederherstellungsdienst für PostgreSQL
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
PostgreSQL ist ein leistungsstarkes, objektrelationales Open-Source-Datenbanksystem, das die SQL-Sprache verwendet und erweitert. Es bietet viele Funktionen, mit denen sich die kompliziertesten Datenlasten sicher speichern und skalieren lassen.
Von Backup and DR verwendete PostgreSQL-Sicherungs-API
Sicherungen auf Volumeebene (Linux-Änderungsblock-Tracking und LVM-Snapshot): Beim Ausführen von Sicherungen mit Linux-Änderungsblock-Tracking und LVM-Snapshot werden die PostgreSQL-Befehle pg_start_backup(label) und pg_stop_backup() verwendet.
Vollständige und inkrementelle (traditionelle dateibasierte) Sicherungen: Für die Sicherung und Notfallwiederherstellung werden die PostgreSQL-Befehle für dateibasierte Sicherungen pg_dump verwendet. Der Befehl pg_dump bietet keine Option zum Erfassen inkrementeller Änderungen an einer Datenbank. Daher ist jede Sicherung ein Datenbankdump.
Bei der Wiederherstellung der Datenbank wird der Datenbereich physisch überschrieben.
PostgreSQL-Protokollsicherung: Bei einer Protokollsicherung kopiert Backup and DR alle PostgreSQL-WALs (WriteAheadLog) physisch. Zum Löschen von Protokollen verwendet Backup and DR einen Befehl auf Betriebssystemebene.
Funktionsweise: Volumebasierte Sicherungen für Sicherung und Notfallwiederherstellung mit Linux CBT
In der Bitmap werden nur geänderte Blöcke erfasst: keine Copy-on-Writes, keine ‑I/O-intensiven Vorgänge.
In den folgenden Schritten wird der Prozess für die Datensicherung und -wiederherstellung beschrieben:
Der Sicherungs- und Notfallwiederherstellungs-Agent verwendet CBT, um geänderte Blöcke im Datenbankdatenbereich zu verfolgen.
Der Agent ruft die Datenbank-API auf, um die Datenbank für die Datensicherung einzufrieren oder anzuhalten.
Der Agent erstellt einen LVM-Snapshot des Datenbankdatenbereichs und synthetisiert eine Bitmap.
Der Kundenservicemitarbeiter ruft die Datenbank-API auf, um die Datenbank zu entsperren.
Der Agent kopiert geänderte Blöcke in die Sicherungs-/Wiederherstellungsanwendung, die dann den Snapshot löscht und die Sicherung katalogisiert.
Die Appliance erstellt einen internen Snapshot und synthetisiert eine virtuelle Vollsicherung zu einem bestimmten Zeitpunkt.
Für die Datenwiederherstellung stellt die Sicherung und Notfallwiederherstellung sofort ein überschreibbares Staging-Laufwerk bereit und stellt die Datenbank online.
Der Befehl „quiesce“ oder „unquiesce“ wird für einen Snapshot-Job auf Volumeebene auf dem primären ausgeführt:
In den folgenden Schritten wird beschrieben, wie Sie Daten mithilfe von dateibasierten Sicherungs-Images sichern und wiederherstellen:
Der Sicherungs- und Notfallwiederherstellungs-Agent wird auf dem Datenbankserver bereitgestellt.
Bereitstellungslaufwerk auf dem Datenbankserver bereitstellen.
Führen Sie eine vollständige Sicherung mit dem Befehl „dump backup“ aus und schreiben Sie die Sicherung auf das bereitgestellte Laufwerk.
Für die Sicherung und Notfallwiederherstellung wird ein interner Snapshot erstellt.
Log-Sicherungen werden auf ähnliche Weise direkt aus dem Dateisystem nach einem von Ihnen konfigurierten Zeitplan durchgeführt.
Für die Datenwiederherstellung wird der Staging-Speicherplatz von „Sicherung und Notfallwiederherstellung“ sofort auf dem Datenbankserver bereitgestellt und der Datenbankwiederherstellungsvorgang gestartet.
Nach der Wiederherstellung der Datenbank können Protokolle zu einem beliebigen Zeitpunkt abgespielt werden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (UTC)."],[[["\u003cp\u003ePostgreSQL is an open-source object-relational database system that uses SQL for storing and scaling complex data workloads.\u003c/p\u003e\n"],["\u003cp\u003eBackup and DR utilizes PostgreSQL's \u003ccode\u003epg_start_backup\u003c/code\u003e and \u003ccode\u003epg_stop_backup\u003c/code\u003e commands for volume-level backups with Linux change block tracking and LVM snapshots.\u003c/p\u003e\n"],["\u003cp\u003eFor file-based backups, Backup and DR employs the \u003ccode\u003epg_dump\u003c/code\u003e command, which performs full database dumps as it lacks the capability for incremental change capture.\u003c/p\u003e\n"],["\u003cp\u003eBackup and DR agents track changes, freeze the database via API, create snapshots, and copy changed blocks for volume-based backup, and they use file-based backups directly from the file system.\u003c/p\u003e\n"],["\u003cp\u003eDatabase quiescing (freezing) and unquiescing commands differ between primary and standby nodes, as well as across PostgreSQL versions (9.x vs. 10.x and later).\u003c/p\u003e\n"]]],[],null,["# Backup and DR Service for PostgreSQL\n\nPostgreSQL is a powerful, open source object-relational database system\nthat uses and extends the SQL language combined with many features that\nsafely store and scale the most complicated data workloads.\n\nPostgreSQL backup API used by Backup and DR\n-------------------------------------------\n\n- **Volume level (Linux change block tracking and LVM snapshot) backups** :\n Backup and DR uses the PostgreSQL `pg_start_backup(label)` and\n `pg_stop_backup()` commands when performing backups with Linux change block\n tracking and LVM snapshot.\n\n- **Full+Incremental (file-based traditional) backups** : Backup and DR\n uses the PostgreSQL `pg_dump` file-based backups commands. The `pg_dump`\n command doesn't have an option to capture incremental changes of a\n database, so each backup is a full database dump backup.\n\n Restore of the database recovers the database by physically\n overwriting the data area.\n- **PostgreSQL log backup** : During a log backup, Backup and DR\n physically copies all the PostgreSQL WALs (`WriteAheadLog`). To purge logs,\n Backup and DR uses an OS-level command.\n\nHow it works: Backup and DR volume-based backup with Linux CBT\n--------------------------------------------------------------\n\nOnly changed blocks are tracked in the bitmap: no copy-on-writes, no\nI/O-intensive operations.\n\nThe following steps describe the process for data backup and recovery:\n\n1. The Backup and DR agent has CBT to track changed blocks in the database data\n area.\n\n2. The agent calls the database API to freeze or pause database for data backup.\n\n3. Agent creates LVM snapshot of database data area and synthesizes a bitmap.\n\n4. Agent call to database API to unfreeze database.\n\n5. Agent copies changed blocks to backup/recovery appliance, which then deletes\n the snapshot and catalogs the backup.\n\n6. The appliance issues an internal snapshot and synthesizes a point-in-time\n virtual full backup.\n\n7. For data recovery, Backup and DR instantly mounts a rewritable staging disk\n and brings the database online.\n\nThe quiesce or unquiesce command is run on the **primary** for a volume-level\nsnapshot job: \n\n select pg_start_backup(\u003clabel\u003e);\n select pg_stop_backup();\n\nThe quiesce and unquiesce commands are run on a **standby node** for a\nvolume-level snapshot job:\n\nIf PostgreSQL version is 10.x or later: \n\n select pg_wal_replay_pause();\n select pg_wal_replay_resume();\n\nIf PostgreSQL version is 9.x: \n\n select pg_xlog_replay_pause();\n select pg_xlog_replay_resume();\n\nHow it works: file-based backup\n-------------------------------\n\nThe following steps describe the process for how to perform data backup and\nrecovery with file-based backup images:\n\n1. Backup and DR agent is deployed in the database server.\n\n2. Mount staging disk on the database server.\n\n3. Invoke full backup using the dump backup command, writing the backup\n to the mounted disk.\n\n4. Backup and DR takes an internal snapshot.\n Log backups are done in a similar fashion directly from the file-system at\n any schedule that you configure.\n\n5. For data recovery, Backup and DR instantly mounts the staging disk\n to the database server and initiates the database restore operation.\n Logs can be played to any point in time after the database is restored.\n\n | **Note:** The `pg_dump` API doesn't have an option to capture incremental changes of a database, so each backup is a full database dump backup.\n\nWhat's next\n-----------\n\n[Prepare the database for Backup and DR](/backup-disaster-recovery/docs/configuration/otherdb-prep-database)\n\nOther documentation for Backup and DR for PostgreSQL\n----------------------------------------------------\n\n- [Backup and DR for PostgreSQL](/backup-disaster-recovery/docs/concepts/postgresql-intro)\n- [Prepare the database for Backup and DR](/backup-disaster-recovery/docs/configuration/otherdb-prep-database)\n- [Add a PostgreSQL database host and discover databases](/backup-disaster-recovery/docs/configuration/otherdb-add-host)\n- [Define policy templates and resource profiles](/backup-disaster-recovery/docs/create-plan/create-template)\n- [Set application details and settings](/backup-disaster-recovery/docs/backup/app-details-settings-otherdb)\n- [Check staging disk format and backup method](/backup-disaster-recovery/docs/backup/backup-method-staging-disk-otherdb)\n- [Protect the PostgreSQL database and its logs](/backup-disaster-recovery/docs/backup/otherdb-protect)\n- [Mount a PostgreSQL database](/backup-disaster-recovery/docs/access-data/otherdb-mounts)\n- [Recover PostgreSQL Backups](/backup-disaster-recovery/docs/restore-data/otherdb-restore)\n- [Create a PostgreSQL Backup and DR Workflow](/backup-disaster-recovery/docs/access-data/otherdb-workflow)"]]
