Lorsque j’essaie d’exécuter des sauvegardes système, j’obtiens le message : « La sauvegarde a échoué. Veuillez consulter les journaux. »
Le journal indique : pg_dump: [archiver (db)] la connexion à la base de données « discoursedb » a échoué : impossible de se connecter au serveur : Connexion refusée
Je pense qu’il y a deux problèmes en jeu :
Le serveur distant fonctionne sur un port non standard.
Le PostgreSQL distant exécute une version plus récente de PSQL.
Lorsque j’entre dans l’application (/var/discourse/launcher enter app) et que j’exécute une sauvegarde manuelle, j’ai remarqué que, initialement sans définition de port, j’obtenais exactement la même erreur :
$ pg_dump -h 123.456.789.101 -U username -W -F t discourse_db > discourse_db_backup.tar
Mot de passe :
pg_dump: [archiver (db)] la connexion à la base de données « discourse_db » a échoué : impossible de se connecter au serveur : Connexion refusée
\tLe serveur est-il en cours d'exécution sur l'hôte « 123.456.789.101 » et accepte-t-il
\tles connexions TCP/IP sur le port 5432 ?
Cela a donc été facilement résolu (SAUF que je ne sais pas comment forcer Discourse à utiliser le bon port lors des sauvegardes), mais le problème suivant était un peu plus préoccupant : nous utilisons une version plus récente de PSQL sur le serveur de base de données :
$ pg_dump -h 123.456.789.101 -p 45678 -U username -W -F t discourse_db > discourse_db_backup.tar
Mot de passe :
pg_dump: version du serveur : 11.5 (Ubuntu 11.5-3.pgdg18.04+1) ; version de pg_dump : 10.10 (Debian 10.10-1.pgdg100+1)
pg_dump : abandon en raison d'une incompatibilité de version du serveur
Que peut-on faire dans une telle situation ? Existe-t-il un moyen de rendre la sauvegarde système fonctionnelle dans ce cas, ou faut-il sauvegarder Discourse et la base de données PostgreSQL séparément ?
Si la seconde option est la seule possible, quelle est la BONNE méthode pour sauvegarder au moins les données ? Existe-t-il un mécanisme cohérent préféré permettant de faire les deux en même temps sans avoir à écrire un nouveau script pour cela ?
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.
Le même problème m’est arrivé. J’ai déplacé la base de données postgresql sur un serveur séparé et j’ai commencé à recevoir une erreur de sauvegarde. J’ai trouvé la solution en supprimant et en réinstallant postgresql dans docker sur le serveur principal.
cd /var/discourse
./launcher enter app
apt-get remove postgresql-client-common
apt-get update
sudo apt-get install postgresql