Cuando intento ejecutar copias de seguridad del sistema, obtengo: “La copia de seguridad falló. Por favor, revise los registros”.
El registro informa: pg_dump: [archiver (db)] conexión a la base de datos "discoursedb" falló: no se pudo conectar al servidor: Conexión rechazada
Creo que pueden estar involucrados dos problemas:
El servidor remoto se ejecuta en un puerto no estándar.
El PostgreSQL remoto se ejecuta en una versión más reciente de PSQL.
Cuando entro a la aplicación (/var/discourse/launcher enter app) y ejecuto una copia de seguridad manual, noté que inicialmente, sin la definición del puerto, obtuve exactamente el mismo error:
$ pg_dump -h 123.456.789.101 -U username -W -F t discourse_db > discourse_db_backup.tar
Contraseña:
pg_dump: [archiver (db)] conexión a la base de datos "discourse_db" falló: no se pudo conectar al servidor: Conexión rechazada
¿Está el servidor ejecutándose en el host "123.456.789.101" y aceptando
conexiones TCP/IP en el puerto 5432?
Eso se resolvió fácilmente (EXCEPTO que no sé cómo forzar a Discourse a usar el puerto correcto en las copias de seguridad), sin embargo, el siguiente problema fue un poco más preocupante: estamos usando una versión más reciente de PSQL en el servidor de base de datos:
$ pg_dump -h 123.456.789.101 -p 45678 -U username -W -F t discourse_db > discourse_db_backup.tar
Contraseña:
pg_dump: versión del servidor: 11.5 (Ubuntu 11.5-3.pgdg18.04+1); versión de pg_dump: 10.10 (Debian 10.10-1.pgdg100+1)
pg_dump: abortando debido a una discrepancia en la versión del servidor
¿Qué se puede hacer en tal situación? ¿Existe una manera de que la copia de seguridad del sistema funcione en este caso, o Discourse y la base de datos PostgreSQL deben respaldarse por separado?
Si esta última es la única opción, ¿cuál es la forma CORRECTA de respaldar al menos los datos? ¿Existe un mecanismo cohesivo preferido disponible para realizar ambas acciones al mismo tiempo sin tener que escribir un nuevo script para ello?
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.
Me sucedió el mismo problema. Moví la base de datos de postgresql a un servidor separado y comencé a recibir un error de copia de seguridad. Encontré la solución eliminando y reinstalando postgresql en docker en el servidor principal.
cd /var/discourse
./launcher enter app
apt-get remove postgresql-client-common
apt-get update
sudo apt-get install postgresql