Pg_dump-Backup-Fehler für Remote-PgSQL – Port- und Versionsunterschiede; welche Optionen gibt es?

Wenn ich versuche, System-Backups auszuführen, erhalte ich folgende Meldung: „Das Backup ist fehlgeschlagen. Bitte überprüfen Sie die Protokolle."
Im Protokoll steht: pg_dump: [archiver (db)] connection to database "discoursedb" failed: could not connect to server: Connection refused

Ich vermute, dass hier zwei Probleme vorliegen:

  1. Der Remote-Server läuft auf einem nicht standardmäßigen Port.
  2. Der Remote-PostgreSQL-Server verwendet eine neuere PSQL-Version.

Wenn ich in die App eintrete (/var/discourse/launcher enter app) und ein manuelles Backup durchführe, stellte ich fest, dass ich zunächst ohne Portangabe exakt denselben Fehler erhielt:

$ pg_dump -h 123.456.789.101 -U username -W -F t discourse_db > discourse_db_backup.tar  
Password:  
pg_dump: [archiver (db)] connection to database "discourse_db" failed: could not connect to server: Connection refused  
\tIst der Server auf dem Host „123.456.789.101" aktiv und akzeptiert er  
\tTCP/IP-Verbindungen auf Port 5432?  

Das war leicht zu beheben (AUSSER ich weiß nicht, wie ich Discourse zwingen kann, den richtigen Port für Backups zu verwenden). Das nächste Problem war jedoch etwas besorgniserregender: Wir verwenden auf dem Datenbankserver eine neuere Version von PSQL:

$ pg_dump -h 123.456.789.101 -p 45678 -U username -W -F t discourse_db > discourse_db_backup.tar  
Password:  
pg_dump: server version: 11.5 (Ubuntu 11.5-3.pgdg18.04+1); pg_dump version: 10.10 (Debian 10.10-1.pgdg100+1)  
pg_dump: Abbruch wegen Inkonsistenz der Serverversion  

Was kann in einer solchen Situation unternommen werden? Gibt es eine Möglichkeit, funktionierende System-Backups in diesem Fall zu realisieren, oder müssen Discourse und die PostgreSQL-Datenbank separat gesichert werden?

Falls Letzteres die einzige Option ist, was ist der KORREKTE Weg, zumindest die Daten zu sichern? Gibt es eine bevorzugte, zusammenhängende Methode, um beides gleichzeitig durchzuführen, ohne ein neues Skript dafür schreiben zu müssen?

I did find some discussion in another post regarding someone who has a slightly comparable situation. The big difference in my case is that we store files on the local server vs S3. I could forego backing up PostgreSQL since that is backed up independently, however I do still need to back up:

  • local content and
  • Discourse settings

I still would like a consolidated backup with the db + content + settings all in one place, but I’m guessing you don’t/won’t support that and thus I’d like to at least get content + settings into a consolidated package.

1 „Gefällt mir“

Postgres 11 isn’t supported. You can look elsewhere for how to restore between versions, but it’ll be some work to get discourse to work with pg11.

Interesting and odd. I had read somewhere that 11 was alright, but aside from that I have a system already deployed to 11 and have not seen any errors or problems (aside from backup) thus far… Now you have me worried…

Oh, here we go, according to this post PostgreSQL 11 "should just work."

Yes. I’ve got two systems deployed on pg11 too. They are working fine except I’m doing backups directly. I upgraded pg to 11 in the container. They’ll make backups but not restore them.

4 „Gefällt mir“

The Discourse backup system should simply warn and not fail if there is a PostgreSQL version mismatch. I just tried to make a backup myself and because I too am using an external PG server, no tarball was created at all.

Das gleiche Problem ist mir auch passiert. Ich habe die PostgreSQL-Datenbank auf einen separaten Server verschoben und bekam eine Backup-Fehlermeldung. Ich fand die Lösung, indem ich PostgreSQL auf dem Hauptserver in Docker gelöscht und neu installiert habe.

cd /var/discourse
./launcher enter app
apt-get remove postgresql-client-common
apt-get update
sudo apt-get install postgresql

Detail: Discourse yedekleme pg_dump hatası ve çözümü: pg_dump: error: server version: 12|13|14|15|*; pg_dump version: 12|13|14|15|* - Veritabanı Yönetim Sistemleri - Soru Cevap