Quando provo a eseguire i backup di sistema, ricevo: “Il backup non è riuscito. Controlla i log.”
Il log riporta: pg_dump: [archiver (db)] connessione al database "discoursedb" fallita: impossibile connettersi al server: Connection refused
Credo che ci siano due problemi in gioco:
Il server remoto è in esecuzione su una porta non standard.
Il PostgreSQL remoto esegue una versione PSQL più recente.
Quando accedo all’app (/var/discourse/launcher enter app) ed eseguo un backup manuale, ho notato che inizialmente, senza la definizione della porta, ho ottenuto esattamente lo stesso errore:
$ pg_dump -h 123.456.789.101 -U username -W -F t discourse_db > discourse_db_backup.tar
Password:
pg_dump: [archiver (db)] connessione al database "discourse_db" fallita: impossibile connettersi al server: Connection refused
È il server in esecuzione sull'host "123.456.789.101" e accetta
connetioni TCP/IP sulla porta 5432?
Quindi questo è stato risolto facilmente (ECCEZIONE: non so come forzare Discourse a utilizzare la porta corretta nei backup), tuttavia il problema successivo era un po’ più preoccupante, ovvero stiamo utilizzando una versione più recente di PSQL sul server del database:
$ pg_dump -h 123.456.789.101 -p 45678 -U username -W -F t discourse_db > discourse_db_backup.tar
Password:
pg_dump: versione del server: 11.5 (Ubuntu 11.5-3.pgdg18.04+1); versione di pg_dump: 10.10 (Debian 10.10-1.pgdg100+1)
pg_dump: interruzione a causa di una discrepanza nella versione del server
Cosa si può fare in una situazione del genere? Esiste un modo per rendere funzionante il backup di sistema in questo caso, oppure Discourse e il database PostgreSQL devono essere backupati separatamente?
Se quest’ultima è l’unica opzione, qual è il modo CORRETTO per eseguire il backup almeno dei dati? Esiste un meccanismo coerente preferito per eseguire entrambi contemporaneamente senza dover scrivere uno script nuovo per farlo?
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.
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…
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.
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.
È successo lo stesso problema anche a me. Ho spostato il database postgresql su un server separato e ho iniziato a ricevere un errore di backup. Ho trovato la soluzione eliminando e reinstallando postgresql in docker sul server principale.
cd /var/discourse
./launcher enter app
apt-get remove postgresql-client-common
apt-get update
sudo apt-get install postgresql