12
Postgresql mit der Point in Time Recovery (PITR)
Hallo zusammen,
ich habe eine Verständnisfrage die mir die Doku von Postgresql leider noch nicht beantworten konnte.
Ich bin gerade dabei, für die Postgresql 12 die PITR Funktion zu testen.
Um dies zu ermöglichen muss man am Anfang ein Basebackup der gesamten DB machen. Aufgrundlage dieses BaseBackup wird ja dann die PITR im Falle eines Falles ausgeführt.
Meine Frage dazu:
- Bis jetzt wurde täglich ein Fullbackup aller DBs gemacht. Muss man nun die Fullbackups mit einem täglichen Basebackup ersetzen?
Auf Antworten von Profis würde ich mich sehr freuen.
LG
Winlicli
ich habe eine Verständnisfrage die mir die Doku von Postgresql leider noch nicht beantworten konnte.
Ich bin gerade dabei, für die Postgresql 12 die PITR Funktion zu testen.
Um dies zu ermöglichen muss man am Anfang ein Basebackup der gesamten DB machen. Aufgrundlage dieses BaseBackup wird ja dann die PITR im Falle eines Falles ausgeführt.
Meine Frage dazu:
- Bis jetzt wurde täglich ein Fullbackup aller DBs gemacht. Muss man nun die Fullbackups mit einem täglichen Basebackup ersetzen?
Auf Antworten von Profis würde ich mich sehr freuen.
LG
Winlicli
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1663664667
Url: https://administrator.de/contentid/1663664667
Printed on: April 19, 2024 at 04:04 o'clock
12 Comments
Latest comment
Du mußt 2 grundsätzliche Dinge unterscheiden:
a) logical Backup. diese macht du mit pg_dump(all)
b) physische Backups mit pgbasebackup
Für das physische Backup brauchst Du neben dem Basebackup dann auch noch alle WAL's, die SEIT DEM START des Basebackups angefallen sind. Tools wie Barman können bei all dem massiv helfen
Also, als Antwort auf Deine Frage: das sind 2 unterschiedliche und miteinander nicht vermischbare Backup-Strategien mit je ihren Vor- und Nachteilen.
a) logical Backup. diese macht du mit pg_dump(all)
b) physische Backups mit pgbasebackup
Für das physische Backup brauchst Du neben dem Basebackup dann auch noch alle WAL's, die SEIT DEM START des Basebackups angefallen sind. Tools wie Barman können bei all dem massiv helfen
Also, als Antwort auf Deine Frage: das sind 2 unterschiedliche und miteinander nicht vermischbare Backup-Strategien mit je ihren Vor- und Nachteilen.
1
Ja das ist richtig. Ich habe das auch alles genau so verstanden.
Die WAL Files werden ja durch das archive_command automatisch weg kopiert.
Ich Frage mich aber, ob ich das BaseBackup täglich machen müsste. Weil dann brauche ich immer nur die WAL Files, die seit dem BaseBackup entstanden sind.
Ein logisches Backup würde nach meinem Verständins dann auch nicht mehr benötigt werden, da man mit dem Basebackup + den WAL Files bereits eine Art Backup hat
Die WAL Files werden ja durch das archive_command automatisch weg kopiert.
Ich Frage mich aber, ob ich das BaseBackup täglich machen müsste. Weil dann brauche ich immer nur die WAL Files, die seit dem BaseBackup entstanden sind.
Ein logisches Backup würde nach meinem Verständins dann auch nicht mehr benötigt werden, da man mit dem Basebackup + den WAL Files bereits eine Art Backup hat
Du brauchst generell die WAL-files seit dem letzten Basebackup, egal ob Du dieses aller 5 Minuten oder aller 5 Jahre machst. Dann mußt Du Dir aber überlegen, was Du für eine Retention Policy machst, also wie lange Du Basebackups + WAL's aufhebst, und wie Du das zuverlässig einrichtest. Barman kann dabei gut helfen, haben wir (ich komme von 2ndQ und bin jetzt bei EDB) entwickelt.
Logisches Backup: Sei Dir bewußt, was der Unterschied zwischen physischem und logischem Backup ist. Wenn der Azubi beim DELETE das WHERE vergißt, willst Du vielleicht nur eine Tabelle und nicht den ganzen Cluster wiederherstellen. Beschäftige Dich also damit, wie das mit einem Basebackup+WAL in einem PITR-Szenario durchführbar ist.
Hint: es ist durchführbar.
Logisches Backup: Sei Dir bewußt, was der Unterschied zwischen physischem und logischem Backup ist. Wenn der Azubi beim DELETE das WHERE vergißt, willst Du vielleicht nur eine Tabelle und nicht den ganzen Cluster wiederherstellen. Beschäftige Dich also damit, wie das mit einem Basebackup+WAL in einem PITR-Szenario durchführbar ist.
Hint: es ist durchführbar.
1
Ich schaue mir mal das Barman an und teste es im LAB.
Das wird vermutlich dann eine Mischung einem täglichen logischem FullBackup und täglichem BaseBackup.
Das wird vermutlich dann eine Mischung einem täglichen logischem FullBackup und täglichem BaseBackup.
für logische Backups empfehle ich übrigens gern eine Kombination von pg_dump im Custom-Format aller Datenbanken plus pg_dumpall -g für die globalen Objekte ... allerdings auch nur, wenn die Größe der Datenbanken das noch zuläßt. Sprich: wenn das (tägliche) Dumpen von der Zeit her dann schon so 23:59 dauert, dann wird es, ähm, unangenehm. Mit VACUUM und so, ...
Im Bereich der MySQL gibt es so was wie XtraBackup, womit man große DBs schnell sichern kann.
Gibt es sowas auch für die PSQL?
Gibt es sowas auch für die PSQL?
pgbasebackup lockt exakt nix, also von der Seite mit XtraBackup vergleichbar oder besser, allerdings kenne ich weder MySQL noch XtraBackup wirklich. Was sind große DBs? Wir haben Kunden im 3-stelligen TB-Bereich.
was gibt es für die PSQL an Tools um die WAL Files für Menschen lesbar zu machen, damit man weis, zu welcher Uhrzeit ein bestimmter Fehler aufgetreten ist und man mit einer PITR bis vor diesem Fehler recovern kann?
pg_xlogdump, siehe auch Magnus Hagander's blog
1
Fazit für mich:
Da ich neben dem FullBackup ein BaseBackup täglich durchführen will, kann ich das BaseBackup und die WALs vom letzten Tag alle löschen und das neue BaseBackup anlegen. PSQL kopiert sich durch die Einstellung dann die WALFiles weg (dafür würde ich dann ein eigenes LVM oder ein NFS einmounten).
Bareman schaue ich mir auf jedenfall an.
Danke für die hilfreichen Antworten.
Da ich neben dem FullBackup ein BaseBackup täglich durchführen will, kann ich das BaseBackup und die WALs vom letzten Tag alle löschen und das neue BaseBackup anlegen. PSQL kopiert sich durch die Einstellung dann die WALFiles weg (dafür würde ich dann ein eigenes LVM oder ein NFS einmounten).
Bareman schaue ich mir auf jedenfall an.
Danke für die hilfreichen Antworten.
In der Praxis ist noch diese Frage entstanden:
wenn ich die PITR ausführen will bis zu einem bestimmten Zeitpunkt bevor ein DELETE passiert ist,
dann muss ich ja in die WALFiles schauen können, damit ich den fehlerhaften SQLStatement finden kann und diesen beim restoren auszuschließen.
Wie kann ich mir den diesen Zeitpunkt aus dem WAL anzeigen lassen?
Mit dem Tool pg_waldump habe ich keine Möglichkeit dazu gefunden.
Auch im Internet finde ich dazu nichts.
Hast du damit schon mal Erfahrung gemacht?
VG
wenn ich die PITR ausführen will bis zu einem bestimmten Zeitpunkt bevor ein DELETE passiert ist,
dann muss ich ja in die WALFiles schauen können, damit ich den fehlerhaften SQLStatement finden kann und diesen beim restoren auszuschließen.
Wie kann ich mir den diesen Zeitpunkt aus dem WAL anzeigen lassen?
Mit dem Tool pg_waldump habe ich keine Möglichkeit dazu gefunden.
Auch im Internet finde ich dazu nichts.
Hast du damit schon mal Erfahrung gemacht?
VG
siehe den Link, den ich bereits nannte.
1
