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

[Discourse]

This guide explains how to restore a Discourse backup from the command line without using the Discourse web UI.

Required user level: Administrator

Console access required

Here’s how to restore a Discourse backup from the command line, without ever booting the Discourse web UI. This is handy when you’re moving servers.

Prerequisites

Before you start, make sure you complete the following steps:

1. Download the latest backup file from the source Discourse instance.
2. Bootstrap the destination Discourse instance by running ./discourse-setup or copying your existing app.yml.
3. Ensure the destination Discourse instance is on the latest version. Update it if necessary.

Transfer the backup

1. SSH into the destination server, or otherwise create the backup folder there:

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

2. Upload your backup file to the destination server.

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

Be sure to replace the paths, filenames, and server names with the ones you are using – but you do want the backup file to end up in:

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

You can also upload and download your Discourse backup file from popular web storage sites such as Google Drive, Dropbox, OneDrive, etc – you’ll need to look up the specific command line instructions based on your preferred web storage provider.

DO NOT CHANGE THE FILENAME OF THE BACKUP! Discourse treats the backup filename as metadata, so if you change the filename, restoring will not work. Stick with the original file name.

Replace /path/to/backup/discourse-xyz.tar.gz with the local path of your backup file, and replace <server_ip_address> with the IP address of destination server.

If Nginx is used as reverse proxy make sure all paths to the backup are readable by the container and Nginx can read the .sock file.

Restore the backup

1. Access your destination server and navigate to the Discourse folder:

cd /var/discourse

2. Enter the Discourse Docker app container:

./launcher enter app

3. Enable restore functionality:

discourse enable_restore

4. Restore the backup file:

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

5. Exit the Discourse Docker app container:

exit

Rebuild

After restoring the backup, you may choose to rebuild the destination instance to ensure all settings and configurations are applied correctly.

Now is a good time to update /var/discourse/containers/app.yml with full HTTPS, additional plugins or CDN configuration. Compare the app.yml configuration of both instances to make sure!

cd /var/discourse
./launcher rebuild app

Enable Email

When a backup is restored, outgoing mail for non-staff is disabled. You don’t want your test server, new server, or server that you just restored a backup for some other reason to start emailing your users! Change site setting “disable_emails” to re-enable email.

That’s it. Your Discourse server is successfully restored.

Last edited by @pfaffman 2025-05-18T19:32:40Z

Check document

Perform check on document:

[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 (Pushpender Singh)]

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 (Pushpender Singh)]

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 Lehtonen)]

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)