Restaurar una copia de seguridad desde la línea de comandos

[Discourse]

Esta guía explica cómo restaurar una copia de seguridad de Discourse desde la línea de comandos sin usar la interfaz de usuario web de Discourse.
Nivel de usuario requerido: Administrador
Se requiere acceso a la consola

Así es como se restaura una copia de seguridad de Discourse desde la línea de comandos, sin arrancar nunca la interfaz de usuario web de Discourse. Esto es útil cuando se están moviendo servidores.

Prerrequisitos

Antes de comenzar, asegúrese de completar los siguientes pasos:

1. Descargue el archivo de copia de seguridad más reciente de la instancia de Discourse de origen.
2. Configure la instancia de Discourse de destino ejecutando ./discourse-setup o copiando su app.yml existente.
3. Asegúrese de que la instancia de Discourse de destino esté en la última versión. Actualícela si es necesario.

Transferir la copia de seguridad

1. Inicie sesión mediante SSH en el servidor de destino, o cree la carpeta de copia de seguridad allí:

mkdir -p /var/discourse/shared/standalone/backups/default

2. Suba su archivo de copia de seguridad al servidor de destino.

scp /path/to/backup/backup.tar.gz root@192.168.1.1:/var/discourse/shared/standalone/backups/default

Asegúrese de reemplazar las rutas, los nombres de archivo y los nombres de servidor con los que está utilizando, pero sí desea que el archivo de copia de seguridad termine en:

/var/discourse/shared/standalone/backups/default

También puede cargar y descargar su archivo de copia de seguridad de Discourse desde sitios populares de almacenamiento web como Google Drive, Dropbox, OneDrive, etc. Necesitará buscar las instrucciones específicas de la línea de comandos en función de su proveedor de almacenamiento web preferido.

¡NO CAMBIE EL NOMBRE DEL ARCHIVO DE LA COPIA DE SEGURIDAD! Discourse trata el nombre del archivo de copia de seguridad como metadatos, por lo que si cambia el nombre del archivo, la restauración no funcionará. Quédese con el nombre de archivo original.

Reemplace /path/to/backup/discourse-xyz.tar.gz con la ruta local de su archivo de copia de seguridad y reemplace \u003cserver_ip_address\u003e con la dirección IP del servidor de destino.

Si se utiliza Nginx como proxy inverso (Running other websites on the same machine as Discourse) asegúrese de que el contenedor pueda leer todas las rutas a la copia de seguridad y que Nginx pueda leer el archivo .sock.

Restaurar la copia de seguridad

1. Acceda a su servidor de destino y navegue a la carpeta de Discourse:

cd /var/discourse

2. Ingrese al contenedor de la aplicación Docker de Discourse:

./launcher enter app

3. Habilite la funcionalidad de restauración:

discourse enable_restore

4. Restaure el archivo de copia de seguridad:

discourse restore sitename-2019-02-03-042252-v20190130013015.tar.gz

Consejo: Si ejecuta discourse restore sin un nombre de archivo, se enumerarán todos los archivos de copia de seguridad disponibles.

Si la configuración backup_location de su sitio está configurada para usar S3, pero cargó manualmente el archivo de copia de seguridad al sistema de archivos local, debe especificar --location local:

discourse restore --location local sitename-2019-02-03-042252-v20190130013015.tar.gz

De manera similar, use --location s3 para restaurar directamente desde una copia de seguridad de S3 sin descargarla primero.

5. Salga del contenedor de la aplicación Docker de Discourse:

exit

Recompilar

Después de restaurar la copia de seguridad, puede optar por reconstruir la instancia de destino para asegurar que toda la configuración y ajustes se apliquen correctamente.

Ahora es un buen momento para actualizar /var/discourse/containers/app.yml con HTTPS completo, complementos adicionales o configuración de CDN. ¡Compare la configuración de app.yml de ambas instancias para asegurarse!

cd /var/discourse
./launcher rebuild app

Habilitar el correo electrónico

Cuando se restaura una copia de seguridad, el correo saliente para los no administradores se deshabilita. ¡No querrá que su servidor de pruebas, servidor nuevo o el servidor para el que acaba de restaurar una copia de seguridad por alguna otra razón comience a enviar correos electrónicos a sus usuarios! Cambie la configuración del sitio disable_emails a “no” para volver a habilitar el correo electrónico.

Eso es todo. Su servidor Discourse se ha restaurado con éxito.

[gregcaporaso]

Estas instrucciones nos funcionaron para restaurar desde una copia de seguridad, pero tuvimos que modificar el comando discourse restore a:

discourse restore --location local sitename-2019-02-03-042252-v20190130013015.tar.gz

(mi ejemplo usa el nombre de archivo del ejemplo anterior) para que la restauración encontrara las copias de seguridad que habíamos puesto en el directorio /var/discourse/shared/standalone/backups/default (en lugar de las copias de seguridad que se almacenaban en s3).

[Isambard]

¿Es necesaria la reconstrucción después de la restauración?

Además, restauré en un nuevo servidor donde hay un proxy inverso NGINX que luego pasa a Discourse upstream. Por lo tanto, deshabilité SSL en Discourse, pero noté que durante la restauración:

Remapping 'https://example.com' to 'http://example.com'

¿Está esto reasignando todos los enlaces internos? ¿Es tan simple deshacer esto como discourse remap http://example.com https://example.com?

[pfaffman (Jay Pfaffman)]

@Isambard

¿Es necesaria la reconstrucción después de la restauración?

No.

@Isambard

¿Se están reasignando todos los enlaces internos?

Parece que sí. Sí, puedes reasignarlos.

Deberías establecer la variable force_https.

[pinder99 (Raza shield)]

si la copia de seguridad es de 15 GB, ¿cuánto espacio se necesita para restaurar?

[pfaffman (Jay Pfaffman)]

¿Es solo la base de datos o también las subidas?

Probablemente 3-5 veces más.

[pinder99 (Raza shield)]

es base de datos + carga de 15 GB, tengo 20 GB de espacio en un disco duro de 60 GB pero la restauración falla cada vez, ¿necesito al menos 50-60 GB de espacio para restaurar?

[pfaffman (Jay Pfaffman)]

Necesitas suficiente espacio para la copia de seguridad, las cargas y la base de datos sin comprimir.

Podrías intentar restaurar primero una copia de seguridad solo de la base de datos y luego copiar las cargas manualmente con rsync.

[Ethsim2 (Ethan)]

He verificado mi cuenta de administrador en el autoalojamiento y he subido una copia de seguridad de .sql.gz, no una de .tar.gz.

La restauración en la interfaz de usuario no es útil, así que la realicé desde “Restaurar la copia de seguridad” en la línea de comandos, obteniendo [FAILED] al final del proceso de discourse restore. ¿Podría el archivo de entrada de un alojamiento oficial ser .tar.gz y causar que el proceso falle?

Mi alojamiento oficial tiene unos días y mi autoalojamiento comenzó a funcionar correctamente hoy después de cambiar los valores SMTP en container.yml.

[pfaffman (Jay Pfaffman)]

Necesitarás incluir qué error obtuviste. El nombre del archivo tiene información de versión, así que si has renombrado el archivo, probablemente necesitarás nombrarlo de nuevo, cambiando solo las palabras al principio del nombre del archivo.

[helmi]

¿Existe alguna documentación para discourse restore en alguna parte? ya que parece haber un interruptor --location local y supongo que también habría uno para S3?

Estoy buscando restaurar desde copias de seguridad ubicadas en S3 y evitar tener que descargarlas manualmente de antemano.

EDIT: ni me acuerdo. Acabo de descubrir que discourse restore --location s3 $filename parece funcionar perfectamente.

[Jagster (Jakke Flemming)]

Como he habilitado S3 en app.yml, un simple discourse restore <nombre_archivo> funcionó perfectamente.

Creo que si buscas backup restore s3 encontrarás la publicación correcta.

[Ethsim2 (Ethan)]

Hola, he completado este proceso utilizando s3(-cli) como mi scp y un cambio en el proveedor de correo saliente de MailGun a Brevo

Desde la restauración, no encuentro una forma de eliminar el banner.

[Moin]

[quote=“Discourse, post:1, topic:122710”]
El proceso de restauración configura automáticamente la opción desactivar correos electrónicos a

[pfaffman (Jay Pfaffman)]

@Moin

La forma más sencilla de eliminar el banner es habilitar los correos electrónicos en la configuración del sitio.

¡Correcto! ¡También podrías ocultarlo con CSS!

[Moin]

Verdadero. Fui un poco cauteloso al recomendar esto porque tuve que pensar en Air theme hides "outgoing email disabled" warning

[pfaffman (Jay Pfaffman)]

@Moin

Fui un poco cauteloso al recomendar esto porque tuve que pensar en el tema Air oculta la advertencia de “correo saliente deshabilitado”

Cada vez que restauras una copia de seguridad, el correo electrónico se deshabilita automáticamente para los no miembros del personal. Me imagino que esto se agregó al código solo un par de veces después de que se realizó una restauración en un servidor de prueba que comenzó a inundar a sus usuarios con notificaciones para un servidor del que no debían tener conocimiento.

Actualicé el OP en consecuencia:

@Discourse

Habilitar correo electrónico

Cuando se restaura una copia de seguridad, el correo saliente para los no miembros del personal se deshabilita. ¡No querrás que tu servidor de prueba, servidor nuevo o servidor para el que acabas de restaurar una copia de seguridad por alguna otra razón comience a enviar correos electrónicos a tus usuarios! Cambia la configuración del sitio “disable_emails” para volver a habilitar el correo electrónico.

[thoka (Thomas Kalka)]

Nota para el tutorial:

Si restaura copias de seguridad regularmente con fines de prueba y su servidor de prueba está configurado correctamente, para enviar correos electrónicos a un servicio de depuración de correo electrónico (como GitHub - maildev/maildev: 📫 SMTP Server + Web Interface for viewing and testing emails during development.) es posible que desee habilitar los correos electrónicos mediante scripting:

docker exec -it app /bin/bash --login \
-c "rails runner 'SiteSetting.disable_emails=\"no\";'"

[pfaffman (Jay Pfaffman)]

En ese caso, quizás quieras configurar DISCOURSE_DISABLE_EMAILS como no en tu app.yml. (y también DISCOURSE_ENABLE_RESTORE para facilitar la restauración)