dbms und Backup

[schwedenmann]

Hallo


Im Moment beschäftige ich mich ein bißchen mit dbms und Sql und demzufolge natürlich auch mit den Fragen upgrade und backup.

Aktuell nutze ich mysqldump und pg_dumpall (die Datenbanken sing allesamt im Moment nut mit usern und Spielmaterial für meine persönliche db gefüllt ich arbeite mich gerade in mariadb-backup und pg_basebackup +und/oder barman ein.Nichts destotrotz wollte euch mal Fragen was im professionellen Umwelt primär dafür eingesetzt wird. Speziell geht es um postgresql.


mfg
schwedenmann

P.S.
Mit pg_upgrade habe ich zum Beispiel Schwierigkeiten, da ich bei meinen postgresql-Installationen das datadir nciht nach /var/lib/postgresql/main/xy lege, was dann zu Probleme führt bei pg_upgrade.

[pferdefreund]

Da meine DB nur so 1 Gb hat, mache ich da immer wieder nach Änderungen einfach einen pg_dumpall > Backupdatei und gut ist. Bei Upgrades steht ja in der Dokumentation, ob da was zu tun ist. Normalerweise nur bei Änderungen der Versionsnummer.
Da nehme ich vor dem make install wieder pg_dumpall > datei und nach dem Install ein initdb mit anschließendem psql < datei als User postgres. Mache ich schon so seit Jahren ohne irgend welche Probleme. Postgres ist für mich eine tolle Datenbank und war vor Jahren schon mysql weit überlegen - insbesondere was den sql-Standard anging und die lief bei mir auf einer Linux-Kiste mit 200 Mhz und 500 MB Ram problemlos - halt gemach aber war ja auch ein 15 Jahre alter Rechner...

[heisenberg]

Ich verwende in meinem Umfeld auch pg_dump und pg_basebackup (beides) für Postgres und mysqldump für MySQL/MariaDB.

Wenn man große Datenbanken hat, dann nimmt man da wahrscheinlich eher eine physikalische Backupmethode(z. B. Percona XtraBackup), weil damit die RestoreZeiten deutlich geringer sind. Und wenn in einer richtig grossen Umgebung die DB einen Tag oder länger steht, dann ist das richtig teuer. Der Nachteil dabei ist, dass die Version des DBMS sich nicht geändert haben darf.

Logische Backups (mysqldump) sind da pflegeleichter.

[schwedenmann]

Hallo

Also mysqldumop,pgdump und pgbasebackup sind jetzt bis auf restore getestet,daß ist der nächste Schritt.

Jetzt stehen noch barman und pgbackrest an.

Hat schon mal einer von euch mariadb-backup (bzw. mariabackup) getestet ?

Aufruf: mariabackup --backup --target-dir/meinbackupdir --user=user --password=geheim

das funktioniert bei mir nur, wenn ich diese Befehlsfolge am Rootaccount vom Os eingebe, entgegen den offiziellen docus von mariadb, wo am Prompt $ steht, also der normale useraccount.
https://mariadb.com/kb/en/full-backup-a ... riabackup/



also #mariabackup --backup --target-dir/meinbackupdir --user=user --password=geheim

Wobei --user root oder der mariadbsuperuser ist und dann eben die entsprechenden PW. Ob eine ~/.my.cnf ausgewertet wird, habe ich noch nicht getestet.


mfg
schwedenmann

Nachtrag:
Ich habe jetzt pgbackrest rudementär laufen (backup lokal incl logs + wal) aber ich hasse docus die mit der Wirklichkeit so gar nichts zu tun haben, bzw. die Tatsachen einfach übergehen und der Tester trotz Nachbau der configs auf Nase fällt.

[heisenberg]

Hallo Schwedenmann, bzw. hallo alle,

was habt Ihr für Erfahrungen mit barman und pgbackrest gemacht? Ich habe bei mir mein eigenes WAL-Archiving u. a. gescriptet. Ich habe da gerade ein Problem und vermute, dass es daran liegt, dass die Archivierung nicht asyncron läuft. D. h. wenn der Backupserver weg ist, dann blockieren die Scripte, der DB-Server hängt sich auf, d. h. ist irgendwann weg. Im Moment bin ich gerade zu faul barman und pgbackrest zu testen und dann im laufenden Betrieb zu ändern.

Grüße,
h.

[schwedenmann]

Hallo



Zu barman kann ich nichts sagen, ich habe vergeblich versucht barman zum Laufen zu bekommen, bin wahrscheinlich zu blöd dazu .

pgbackrest läuft bei mir in einer nur lokalen Minimalkonfiguration , was für meine Zwecke völlig ausreicht.
Die Konfiguration ist "relativ" einfach, 4 Zeilen in der postgresql.conf plus eine pgbackrest Konfigurationsdatei mit 2 Sektionen. Ich lasse pgbackrest per user postgres ausführen.


So sieht die Konfiguration bei mir aus.

In der postgresql.conf sind 4 Zeilen zu editieren, bzw hinzuzufügen

archive_mode=on
wal_level=replica
archive_command = 'pgbackrest —stanza=nathan64 archive-push %p'
max_wal_senders = 10

das -stanza=testing hängt vom Namen der zweiten Sektion der pgbackrestkonfiguration ab!



Die pgbackrest.conf sieht bei mir folgendermaßen aus:

[global]
repo1-path=/datenbank/backup/pgbackrest
repo1-retention-full=2
log-level-file=detail
log-level-console=info
start-fast=y
archive-check=y
archive-copy=y
compress-type=gz
repo1-retention-archive=2



[nathan64]
pg1-path=/datenbank/postgresqldata/16/main
log-path=/datenbank/backup/pgbackrest/logs
lock-path=/datenbank/backup/pgbackrest

Wie ihr sehen könnt, benutze ich keine Standardpfade (weder für postgresql, noch für pgbackrest), deshalb die 2 Zeilen in Sektion [nathan64]. Bei Verwendung der Standardpfade kann man zumindest die letzte Zeile (also lock...) weglassen.
Die Verzeichnisse für die logs muß man afaik selbst anlegen,sonst meckert pgbackrest.


Danach kann man das backup starten.

1. backup initialisieren (su + rootpaßwort, dann su postgres)
pgbackrest –stanza=nathan64 –type=full –log-level-console=info stanza-create

Wenn keine Errormeldungen erschienen sind kann man noch folgenden Befehl absetzen:
pgbackrest –stanza=nathan64 –log-level-console=info check

Das eigentlich backup wird dann so angestoßen:
pgbackrest –stanza=testing –type=full –log-level-console=info backup


Danach muß nur noch der letzte backup Befehl immer nur wiederholt werden.



mfg
schwedenmann

[whisper]

Moin, hat das einen bestimmten Grund warum niemand "im Sinne von keiner"
automysqlbackup und
autopostgresqlbackup
in die Runde wirft?
Würde mich interessieren, zumal ich bei automysqlbackup sicher bin, dass restore auch bei Serverupgrade einwandfrei funktioniert.
Ich nutze das auf dem produktiven rootserver seit mehr als 15 Jahren.

[heisenberg]

auto(MySQL|postgres)backup nutze ich eher recht selten. Ich habe mir da meine eigenen Scripte geschrieben.

Mich stört, das man bei auto...backup die Rotation nicht weg konfigurieren kann. Ich sichere hier immer nur einen Satz und den Rest erledigt das Backupsystem.

Aber so grundsätzlich sind beide Programme brauchbar. Durchaus eine Fire-and-Forget Lösung, wenn einem ein tägliches DB-Backup reicht.

---

Im konkreten Fall ging es mir eher um die Wiederherstellung im Falle eines Crashes, bis kurz vor dem Crash (Stichwort Point-in-Time-Recovery/PITR) von zwei größeren Postgres-DB-Servern. Da mache ich täglich Dumps, Basebackups und hebe die WAL-dateien für 3 Tage auf.

Ich habe da Mal die Datenmenge, die da kontinuierlich in die Transaktionsdateien geschrieben wird berechnet. Das war dann doch recht viel: ca. 20 MiB/Sek im Schnitt. Hochgerechnet auf's Jahr sind das 600 TiB.

Bzgl. der Probleme mit der Nichterreichbarkeit des Backupservers habe ich überlegt, ob ich das vorher nochmal auf dem DB-Server zwischenspeichern möchte. Das wollte ich den SSDs aber nicht zumuten. Mit der Idee, da dann einfach nochmal einen Hardlink drauf zu setzen, bin ich sehr zufrieden. Anschließend werden die WAL-Files dann von einem eigenen Skript auf den Backupservers geschaufelt.

[whisper]

auto(MySQL|postgres)backup nutze ich eher recht selten. Ich habe mir da meine eigenen Scripte geschrieben.

Mich stört, das man bei auto...backup die Rotation nicht weg konfigurieren kann. Ich sichere hier immer nur einen Satz und den Rest erledigt das Backupsystem.

Aber so grundsätzlich sind beide Programme brauchbar. Durchaus eine Fire-and-Forget Lösung, wenn einem ein tägliches DB-Backup reicht.

---

Im konkreten Fall ging es mir eher um die Wiederherstellung im Falle eines Crashes, bis kurz vor dem Crash (Stichwort Point-in-Time-Recovery/PITR) von zwei größeren Postgres-DB-Servern. Da mache ich täglich Dumps, Basebackups und hebe die WAL-dateien für 3 Tage auf.

Klar bei solchen Größenordnungen hat man ganz andere Sorgen!

[heisenberg]

Bzgl. der Probleme mit der Nichterreichbarkeit des Backupservers habe ich überlegt, ob ich das vorher nochmal auf dem DB-Server zwischenspeichern möchte. Das wollte ich den SSDs aber nicht zumuten. Mit der Idee, da dann einfach nochmal einen Hardlink drauf zu setzen, bin ich sehr zufrieden. Anschließend werden die WAL-Files dann von einem eigenen Skript auf den Backupservers geschaufelt.

Dazu nochmal einen Kommentar: Das mit dem Hardlink-setzen war dann schließlich doch nicht so gut, weil Postgres seine Transaktionsdateien in einer speziellen Art und Weise behandelt:

Es wird die konfigurierte Anzahl an WAL-Dateien angelegt und dann zyklisch überschrieben. D. h. wenn dann der Backupserver weg ist, dann hat man kein Platzproblem, weil ja nur die konfigurierte Anzahl an WAL-Dateien da ist, aber man verliert eben alle WAL-Dateien, die dann wieder überschrieben werden. D. h. das war's dann mit der Point-In-Time-Recovery. Ich habe jetzt wieder umgestellt auf Kopie der WAL-Dateien.