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?
Ho trovato una discussione in un altro post riguardante qualcuno con una situazione leggermente simile. La differenza principale nel mio caso è che archiviamo i file sul server locale invece che su S3. Potrei rinunciare al backup di PostgreSQL, dato che viene già backuppato in modo indipendente, ma ho comunque bisogno di eseguire il backup di:
contenuto locale e
impostazioni di Discourse
Vorrei comunque un backup consolidato che includa db + contenuto + impostazioni in un unico luogo, ma immagino che non supportiate o non supporterete questa opzione. Pertanto, mi piacerebbe almeno ottenere contenuto + impostazioni in un pacchetto consolidato.
Postgres 11 non è supportato. Puoi cercare altrove come eseguire il ripristino tra le versioni, ma ci vorrà del lavoro per far funzionare Discourse con pg11.
Interessante e strano. Avevo letto da qualche parte che la 11 andava bene, ma a parte questo ho già un sistema distribuito alla 11 e finora non ho riscontrato errori o problemi (a parte il backup)… Ora mi hai preoccupato…
Oh, eccoci, secondo questo post PostgreSQL 11 “dovrebbe funzionare senza problemi”.
Sì. Ho due sistemi distribuiti anche su pg11. Funzionano correttamente, tranne per il fatto che sto eseguendo i backup direttamente. Ho aggiornato pg alla versione 11 nel contenitore. I backup vengono eseguiti, ma non vengono ripristinati.
Il sistema di backup di Discourse dovrebbe semplicemente avvisare e non fallire in caso di incompatibilità della versione di PostgreSQL. Ho appena provato a eseguire un backup io stesso e, poiché anch’io sto utilizzando un server PG esterno, non è stato creato alcun file tar.
È 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