¿Cómo hacer una copia de seguridad y restaurar toda la carpeta de la aplicación /var/discourse?

Cómo hacer una copia de seguridad y restaurar toda la carpeta /var/discourse

Debido a problemas con el proceso habitual de copia de seguridad y restauración, me preguntaba si podía respaldar toda la carpeta /var/discourse y reutilizarla en otro servidor. Esto es lo que hice…

En el servidor de producción:

rsync_opts="\
   --recursive \
   --links \
   --hard-links \
   --safe-links \
   --owner \
   --group \
   --perms \
   --times \
   --delete \
   --sparse \
   --compress \
   --partial \
   --rsh=ssh
"
dir=/var/discourse
rsync  $rsync_opts "$dir/" root@xx.xx.xx.xx:"/var/production-backup/$dir"

En el servidor de staging:

Instalar Docker.

rsync --recursive --links --hard-links --safe-links --owner --group --perms --times --delete --sparse --compress --partial /var/production-backup/var/discourse/ /var/discourse

Pero obtengo un error 502 Bad Gateway.

Estoy tratando de investigar.

cd /var/discourse

./launcher start app

root@whonix-app:/var/www/discourse# service postgresql status
12/main (puerto 5432): apagado
root@whonix-app:/var/www/discourse# service postgresql start
[....] Iniciando servidor de base de datos PostgreSQL 12: main[....] Error: El clúster es propiedad del ID de grupo 116 que no existe ... fallido!
 fallido!

Adivino algunas soluciones:

chown -R postgres.postgres /etc/postgresql
chown -R postgres.postgres /shared/postgres_*
chown -R postgres.postgres /var/lib/postgresql
chown -R postgres.postgres /var/log/postgresql
chown -R redis.redis /etc/redis/redis.conf
chown -R redis.redis /shared/redis_data
chown -R redis.redis /var/run/redis
chown -R redis.redis /var/lib/redis
chown -R redis.redis /var/log/redis
chgrp -R ssl-cert /etc/ssl/private

Pero no ayudó.

root@whonix-app:/var/www/discourse# service postgresql start
[....] Iniciando servidor de base de datos PostgreSQL 12: main[....] Error: /usr/lib/postgresql/12/bin/pg_ctl /usr/lib/postgresql/12/bin/pg_ctl start -D /shared/postgres_data -l /var/log/postgresql/postgresql-12-main.log -s -o -c config_file="/etc/postgresql/12/main/postgresql.conf" salió con estado 1: 2020-05-25 10:20:10.501 UTC [603] FATAL: los archivos de la base de datos son incompatibles con el servidor 2020-05-25 10:20:10.501 UTC [603] DETALLE: El directorio de datos fue inicializado por la versión 10 de PostgreSQL, que no es compatible con esta versión 12.2 (Debian 12.2-2.pgdg100+1). pg_ctl: no se pudo iniciar el servidor. Examine la salida de registro. ... fallido!
 fallido!

¿Por qué se introducen estos problemas de permisos de archivo?

¿Por qué se actualiza PostgreSQL de la versión 10 a la versión 12 simplemente copiando toda la carpeta de un servidor a otro? Debo estar haciendo algo mal.

¿Podrían compartirme, por favor, instrucciones sobre cómo hacer una copia de seguridad completa de la aplicación Discourse en un servidor y moverla a otro?

¿Discourse no utiliza Phabricator?

1 me gusta

Error tipográfico. Me refería a Discourse. Error corregido. La pregunta original permanece.

2 Me gusta

Eso no mueve toda la carpeta /var/discourse. Conozco estas instrucciones, pero no funcionan para mí. Por eso quería un método de copia de seguridad más “completo” y exacto, como una “copia dura” 1 a 1.

Puedes apagar el contenedor y copiar todo a un nuevo servidor, excluyendo los directorios tmp, backup y cache (y creo que hay otro más). Eso debería funcionar. Lo hice recientemente, creo que por una razón similar.

Pero aún necesitas solucionar el problema del índice dañado.

2 Me gusta

Creo que la versión de Docker está introduciendo diferencias. (Lo que luego lleva al fallo.)

Servidor original
docker-engine 17.05.0~ce-0~debian-stretch

vs servidor más nuevo (entorno de pruebas)
docker-engine 17.05.0~ce-0~debian-stretch

Esto resulta en que el servidor original tiene la versión de PostgreSQL 10, mientras que el servidor más nuevo (entorno de pruebas) ya tiene PostgreSQL 12.

¿Es eso obligatorio? ¿Hay alguna forma más sencilla? ¿Por qué sería necesario no copiar todo tal cual y restaurar?

Lo que lleva a problemas de permisos que no puedo explicar. Debería ser posible copiar sin romper los permisos. Además, tampoco estoy seguro de haber solucionado todos los problemas de permisos.

Sí, pero creo que sería mucho más seguro proceder con eso solo cuando pueda al menos reproducir lo que aún funciona ahora.

No puedes simplemente “comprimir con tar” el directorio /var/discourse, moverlo a otra máquina, descomprimirlo y arrancar la aplicación Discourse.

Una de las razones principales es que, al construir/inicializar Discourse, el lanzador (según recuerdo de memoria) verifica si existe un contenedor base de Discourse (imagen) y descarga la imagen Docker base de Discourse (si no existe), para luego iniciar ese contenedor con la imagen base.

Después de ese git pull base, el proceso de construcción crea otra imagen Docker (la de la aplicación).

Ambas imágenes Docker (la imagen base y la imagen de la aplicación) no residen dentro de /var/discourse, por lo que comprimir /var/discourse con tar solo ofrece una solución parcial (usando este término con cierta flexibilidad).

Estas imágenes Docker de Discourse se construyen como imágenes Docker y forman parte de Docker; no “viven” en /var/discourse, sino que se construyen allí y luego se mueven a Docker como imágenes.

Podría ser posible editar tu archivo YAML del contenedor y reconstruir desde cero, pero la forma más convencional es simplemente guardar:

  • los archivos YAML del contenedor
  • tu copia de seguridad completa con las subidas

y luego editar tu archivo YAML del contenedor, clonar el repositorio discourse-docker y reconstruir.

Después, restaura tu copia de seguridad completa, incluidas las subidas (desde la línea de comandos dentro del contenedor).

Usar GitHub como repositorio es una solución más limpia que el antiguo método “unix” de “comprimir todo el maldito asunto” y “mover todo el maldito asunto” a otro servidor. Sin embargo, incluso con el “antiguo método unix”, este enfoque a menudo no ofrece una solución completa, ya que frecuentemente hay librerías compartidas en el sistema, directorios de usuarios con librerías compartidas y más, que no forman parte del directorio de distribución, además de archivos en /etc que no están en el directorio raíz de la distribución, etc.

Así que, incluso en la mayoría de los sistemas Linux modernos, usamos apt (en Ubuntu, por ejemplo) para obtener el repositorio. En el caso de Discourse con Docker, estás obteniendo (y construyendo) discourse-docker para configurar el contenedor base y otro repositorio de Discourse para construir la aplicación. Por lo tanto, /var/discourse es un “lugar para construir” (las imágenes) y un “lugar para compartir” (los datos, las copias de seguridad, los archivos estáticos públicos, etc.).

Espero que este resumen haya sido útil de alguna pequeña manera.

2 Me gusta

Claro, puedes copiarlo todo con rsync -rav.

Es posible que tengas más suerte si cambias tu aplicación para que use la plantilla de PostgreSQL 10. Pero parece que lo más sencillo podría ser simplemente reparar tu base de datos in situ.

4 Me gusta

Sí, puedes mover la carpeta, funciona sin problemas. Solo que no es la ruta preferida, ya que evita discourse-setup y cualquier ajuste o prueba que ejecute en el proceso.

2 Me gusta

En mi caso no funcionó, ya que la actualización de Docker resultó en una versión más reciente de PostgreSQL dentro del contenedor, lo que provocó que el foro dejara de ser usable debido a problemas de migración de PostgreSQL. Tuve que cambiar de la plantilla de PostgreSQL 10.

How to backup and restore a whole /var/discourse app folder? - #8 by neounix explica los detalles de manera clara.

Supongo que tendría que hacer una copia de seguridad y restaurar también la carpeta /var/docker. Pero incluso eso tiene la posibilidad de fallar debido a esto:

Estás metiéndote en un problema complejo. Si fuera tú, me centraría en resolver tu problema original con la copia de seguridad y la restauración.

4 Me gusta

Quizás incluso un agujero de :rat: :rat: :rat:.

De acuerdo… sin duda…

@adrelanos

No hay “problemas” con el proceso de copia de seguridad y restauración. Mira este “elogio” que tu servidor @neounix escribió hace unos meses sobre este tema:

1 me gusta

Estimado @adrelanos,

Volviendo a tu pregunta original en el mensaje #1 de arriba, siendo curioso por naturaleza, no quedé realmente satisfecho con mi respuesta anterior y realicé algunas pruebas hoy.

En resumen, acabo de confirmar que podemos usar docker save (para los contenedores base y de la aplicación) y tar para el directorio /var/discourse, y así guardar, transferir (respaldar) y restaurar completamente la aplicación.

Estoy casi seguro (99.99%) de que este método no está soportado oficialmente, pero mereces una respuesta, así que lo probé por ti:

Básicamente, aquí están los pasos, en resumen:

  1. Guarda tus contenedores con docker save.

Por ejemplo, si estás ejecutando una aplicación independiente, puedes guardar los contenedores base y de la aplicación de la siguiente manera (basado en tu configuración):

docker save -o /tmp/my.discourse.docker.app.tar  discourse/base:2.0.20200512-1735

y también:

docker save -o /tmp/my.discourse.docker.app.tar local_discourse/app:latest  
  1. También puedes comprimir con tar el directorio /var/discourse, como mencionaste:
cd /var/
tar -cvzf /tmp/my.var.discourse.tar.gz discourse

y luego comprimir con gzip tus archivos tar de docker si lo deseas y archivarlos:

gzip /tmp/my.discourse.docker*.tar
  1. … y puedes mover estos archivos a otro servidor, archivarlos en el mismo servidor, lo que quieras, invertir los pasos y reiniciar la aplicación Discourse sin problemas.

Acabo de confirmar esto “haciéndolo”, y eliminando todas las imágenes de contenedores y el directorio /var/discourse. Básicamente, borré todo y reinicié (no es necesario reconstruir ya que el dominio no cambió, etc.) desde las copias de seguridad.

Por ejemplo, para restaurar, puedes tomar las imágenes de docker guardadas anteriores y cargar las imágenes, por ejemplo:

gzip -d /tmp/my.discourse.docker.app.tar.gz
docker load -i /tmp/my.discourse.docker.app.tar

gzip -d /tmp/my.discourse.docker.base.tar.gz
docker load -i /tmp/my.discourse.docker.base.tar
  1. Luego, descomprime tu directorio original /var/discourse
cd /var
tar -xvzf /tmp/my.var.discourse.tar.gz
  1. A continuación, debes revisar tus imágenes para asegurarte de que estén etiquetadas correctamente:
docker images
  1. y si las imágenes no están etiquetadas correctamente, asegúrate de etiquetarlas correctamente, por ejemplo para tu imagen de aplicación:
docker tag 58ffc74989af local_discourse/app:latest
  1. Luego, simplemente haz esto:
cd /var/discourse
./launcher start app

y funciona perfectamente. Acabo de probarlo (dos veces).

Espero que esto ayude.

Por si acaso (FWIW): Probé este método de dos maneras diferentes, realizando el método de copia de seguridad anterior, eliminando todos los contenedores de docker, las imágenes y el directorio /var/discourse (destruyendo todo por completo, cada vez).

En cada caso, pude cargar mis imágenes de docker guardadas, descomprimir el directorio /var/discourse, ejecutar ./launcher start app y Discourse se inició sin problemas; y para demostrarlo, pude hacer una copia de seguridad normal desde la interfaz de usuario, probando que todo estaba bien.

No estoy seguro si esto responde a tu pregunta (y no he participado en la actualización o discusiones de Postgres 10 a 12); pero con respecto a tu pregunta de simplemente comprimir la aplicación como copia de seguridad y restaurarla, la respuesta es , pero debes no solo archivar el directorio /var/discourse, sino que también debes docker save tus imágenes.

El principal “problema” es mantener correctos el nombre del repositorio de imágenes y las etiquetas, y deberías estar listo para funcionar.

Espero que esto responda, de alguna pequeña manera, a tu pregunta sobre:

¿Cómo hacer una copia de seguridad y restaurar toda la carpeta de la aplicación /var/discourse?

La respuesta es que debes archivar tanto tu carpeta como tus imágenes de docker (como en el ejemplo anterior) usando docker save para las imágenes (para hacer la copia de seguridad) y docker load para restaurar.

Ten en cuenta que este método no está oficialmente soportado; pero por curiosidad, quise ver cómo hacerlo desde la perspectiva del administrador del sistema, y descubrí que era más fácil de lo que mis respuestas anteriores indicaban.

Nota 1:

Quizás quieras mover todas las copias de seguridad de tu directorio backups/default (fuera del árbol de directorios) antes de comprimir todo en /var/discourse/ y mantener esas copias de seguridad (por separado), ya que esos archivos son tan grandes…

Nota 2:

Este tipo de copia de seguridad no está soportado y, por lo tanto, no se recomienda para la mayoría de los administradores de sistemas de Discourse. Recomiendo que los usuarios sigan el método de copia de seguridad y recuperación de Discourse recomendado (y oficialmente soportado).

¡Mantente Curioso!

Cuídate.


Para más detalles, incluyendo capturas de pantalla, por favor consulta mi publicación completa aquí:

6 Me gusta

¡Esta es una excelente aproximación! ¡Gracias!

Un problema en el servidor de restauración.

./launcher logs app

2020-06-18 13:33:56.434 UTC [127] FATAL: el directorio de datos “/shared/postgres_data” tiene una propiedad incorrecta
2020-06-18 13:33:56.434 UTC [127] HINT: el servidor debe ser iniciado por el usuario que posee el directorio de datos.
./run: 3: echo: echo: error de E/S
2020-06-18 13:33:57.448 GMT [128] LOG: omitiendo el archivo de configuración inexistente “/shared/postgres_data/postgresql.auto.conf”


Eso podría deberse a alguna opción tar faltante? Añadí -p y -s durante la extracción pero no ayudó.

servidor original (fuera de docker):

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 4096 May 25 13:16 base

servidor original (dentro de docker (./launcher enter app)):

ls -la /var/lib/postgresql/10/main/

drwx------ 5 root postgres 4096 May 25 23:28 base


servidor de restauración fuera de docker:

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 71 May 25 11:16 base

servidor de restauración dentro de docker:

drwx------ 5 root postgres 41 May 25 23:28 base


./launcher rebuild app lo solucionaría, pero eso no es el punto.

¿Alguna idea?

Creo que quisiste decir docker save -o /tmp/my.discourse.docker.base.tar discourse/base:2.0.20200512-1735, basándote en tu proceso de restauración. De todos modos, ¡muy buena explicación!

Pero, como dijiste, no creo que este sea un enfoque oficialmente respaldado (aunque tampoco creo que haya algo más que pueda causar errores, a menos que el equipo de Discourse comience a usar más de una imagen base en el proceso de reconstrucción).

Parece que hay el mismo problema en:

https://meta.discourse.org/t/postgresql-12-update/151236/298?u=lucasbasquerotto

No hay una respuesta específica para este problema en las preguntas frecuentes, pero quizás el equipo de Discourse agregue una solución, considerando que más de una persona lo ha experimentado. Existe una pregunta frecuente sobre El clúster de origen no se apagó correctamente, que podría estar relacionada con tu problema.

1 me gusta

Un método que utilicé y que no implica un docker save ni un tar+untar completo de /var/discourse: