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?
Sí, encontré una discusión en otro post sobre alguien que tiene una situación ligeramente comparable. La gran diferencia en mi caso es que almacenamos los archivos en el servidor local en lugar de en S3. Podría prescindir de hacer copias de seguridad de PostgreSQL, ya que se respalda de forma independiente; sin embargo, aún necesito respaldar:
el contenido local y
la configuración de Discourse
Aún me gustaría tener una copia de seguridad consolidada con la base de datos, el contenido y la configuración en un solo lugar, pero supongo que no lo soportan o no lo harán, por lo que me gustaría al menos lograr que el contenido y la configuración estén en un paquete consolidado.
Postgres 11 no es compatible. Puedes buscar en otros lugares cómo restaurar entre versiones, pero será necesario realizar cierto trabajo para que Discourse funcione con pg11.
Interesante y extraño. Había leído en algún lugar que la 11 estaba bien, pero aparte de eso, tengo un sistema ya desplegado en la 11 y hasta ahora no he visto ningún error ni problema (salvo la copia de seguridad)… Ahora me has preocupado…
Sí. Tengo dos sistemas desplegados en pg11 también. Funcionan bien, excepto porque estoy haciendo copias de seguridad directamente. Actualicé pg a la versión 11 en el contenedor. Realizan las copias de seguridad, pero no pueden restaurarlas.
El sistema de copias de seguridad de Discourse debería simplemente advertir y no fallar si hay una incompatibilidad de versiones de PostgreSQL. Acabo de intentar hacer una copia de seguridad yo mismo y, como yo también estoy usando un servidor PG externo, no se creó ningún archivo tarball en absoluto.
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