pg_dump

Kampfgummibaerlie

Datenbank-Guru
Beiträge
730
Ich bin (immernoch) kräftig am programmieren, und denke bereits weit genug zu sein, dass ich mir bereits sorgen um die Sicherung der gesamten Datenbank und der Homepage mache.

Da das mit Homepage hier nichts verloren hat, frage ich also hier nur spezifisch auf die Sicherung einer 9.4 PGSQL-Datenbank (vollständiges Backup), wenn es möglich ist (glaube ich) irgendwie mit in_time_backups zu arbeiten (glaube, irgendwie so nannte es herr Elefant ;) ), aber es geht mir im 1. Sinne darum, ein Backup der gesamten Datenbank zu haben.

Bzw. frage ich hier nach, wiesehr ich diese benötigen würde?
Gäbe es dazu irgendwelche Sicherheitschecks? (So wie Punkt 1 bis x, ob diese Methode möglich wäre)

Danke im voraus ;)
habe mich mit sowas noch nie großartig und erfolgreich beschäftigt, glaube ich war aber vor geraumer Zeit mal ein Thema von mir hier.

EDIT: Links würden mir wohl reichen :D
 
Zuletzt bearbeitet:
Werbung:
Du meinst sicherlicht PITR, Abkürzung von "Point In Time Recovery".

Es gibt prinzipiell 2 grundlegende Backup-Methoden:

  • logische Backups
  • physische Backups

Logische Backups erstellst Du ganz simple mit pg_dump bzw. pg_dumpall. pg_dump sichert eine einzelne Datenbank und kann in unterschiedlichen Formaten sichern und auch parallel sichern und wiederherstellen (kommt auf das verwendete Format an). pg_dumpall sichert auch globale Objekte wie Benutzer. Wenn Du also via pg_dump einzelne Datenbanken sicherst, solltest Du immer auch pg_dumpall mit der Option -g aufrufen, denn das sichert die globalen Objekte.

Logische Backups haben den Vorteil, auch versionsübergreifend einsetzbar zu sein, Du kannst einen Dump von 9.4 z.B. nun auch in die aktuelle Version 11 einspielen. Nachteil ist: Du hast nur einen Snapshot, der Dump enthält die Daten, wie sie zum Startzeitpunkt in der DB waren. Sprich: wenn Dein Dump um 8 startet und bis um 9 läuft und Du 8:30 was wichtiges in der DB speicherst, ist das NICHT im Dump sichtbar. PostgreSQL: Documentation: 11: Chapter 25. Backup and Restore


Physische Backups sind komplizierter zu erstellen und zu handeln, aber wenn man es richtig macht, hat man damit ein kontinuierliches Backup. Unser Barman kann das alles sehr gut. Barman
 
9.4 scheint (immernoch) die aktuellste Version für meinen Debian NAS zu sein ;)

Darf ich dich (wiedermal) ein wenig stochern wegen Barman? Ich glaube, dazu gabs eine große Doku ;)
Bin bei weitem motivierter, als vorher, wohl auch wegen dem einen oder anderem Erfolg, den ich bei diesem Anfang mache :)

Ich glaube, es gab Barman als Service für den (Debian) NAS, liege ich damit richtig? Kann mich nur dunkel an die Zeit erinnern, wann wir 2 mit sowas begonnen haben ... :/

Habe bereits den "Backup-Server" in 0 komma nichts als PG-SQL-Server (9.4) eingerichtet, sprich (weil die beiden NAS das selbe OS fahren) auch das selbe PGSQL.
Mache mal eine kurze Pause ;)
 
Ja, Barman hat eine große Doku. Wenn Du den Link folgst, findest Du diese völlig überraschend unter "Documentation". So sind halt unsere Italiener: immer für eine Überraschung gut! ;-)
 
Akretschmer, darf ich um eine 1:1 Betreuung von Ihnen bitten? ...
Ich glaube es richtig überrissen zu haben, dass man den user Barman auf dem "Backup"-Server erstellen soll, scheitere aber bei der Konfiguration, damit dieser auf den PGSQL Server zugreifen kann (sollte doch gehen, weil er allen localen Adressen vertraut? (sprich nicht nötig))

Liegt vl. auch an einer englischen Doku, womit ich mich nur selten auseinandersetze im fachlichen Bereich.
 
Werbung:
Wenn es nur um konsistente Backups geht, ist vielleicht pgBackRest auch eine Alternative.

Barman bietet ja viele nützliche Funktionen die über die reine Verwaltung von Backups hinausgehen (z.B. zur Verwaltung von Standby Servern).

Wenn man "nur" Backups machen möchte, dann ist das etwas "schlankere" pgBackRest vielleicht eine Alternative
 
Zurück
Oben