Restaurar um backup a partir da linha de comando

[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 instruções funcionaram para restaurarmos a partir do backup, mas tivemos que modificar o comando discourse restore para:

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

(meu exemplo usa o nome do arquivo do exemplo acima) para que a restauração encontrasse os backups que colocamos no diretório /var/discourse/shared/standalone/backups/default (em oposição aos backups que estavam armazenados no s3).

[Isambard]

A reconstrução após a restauração é necessária?

Além disso, restaurei para um novo servidor onde há um proxy reverso NGINX que, em seguida, encaminha para o Discourse upstream. Portanto, desativei o SSL no Discourse, mas notei que durante a restauração:

Remapeando 'https://example.com' para 'http://example.com'

Isso está remapeando todos os links internos? É tão simples desfazer isso quanto discourse remap http://example.com https://example.com?

[pfaffman (Jay Pfaffman)]

@Isambard

A reconstrução após a restauração é necessária?

Não.

@Isambard

Isso está remapeando todos os links internos?

Parece que sim. Sim, você pode remapeá-los.

Você deve definir a variável force_https.

[pinder99 (Pushpender Singh)]

se o backup for de 15 GB, quanto espaço é necessário para restaurar?

[pfaffman (Jay Pfaffman)]

Isso é apenas o banco de dados ou uploads também?

Provavelmente 3-5x mais.

[pinder99 (Pushpender Singh)]

é banco de dados + upload de 15 GB, tenho 20 GB de espaço em um HD de 60 GB, mas a restauração falha todas as vezes, preciso de pelo menos 50-60 GB de espaço para restaurar?

[pfaffman (Jay Pfaffman)]

Você precisa de espaço suficiente para o backup, os uploads e o banco de dados descompactado.

Você pode tentar restaurar primeiro um backup somente do banco de dados e, em seguida, copiar os uploads manualmente com rsync.

[Ethsim2 (Ethan)]

Verifiquei minha conta de administrador em auto-hospedagem e fiz o upload de um backup .sql.gz, não um .tar.gz.

Restaurar na interface do usuário não é útil, então realizei a partir de “Restaurar o backup” na linha de comando, obtendo [FAILED] no final do processo discourse restore. O arquivo de entrada de uma hospedagem oficial ser .tar.gz pode fazer o processo passar?

Minha hospedagem oficial tem alguns dias e minha auto-hospedagem começou a funcionar corretamente hoje após alterar os valores SMTP em container.yml.

[pfaffman (Jay Pfaffman)]

Você precisará incluir qual erro obteve. O nome do arquivo tem informações de versão nele, então, se você renomeou o arquivo, provavelmente precisará renomeá-lo de volta, alterando apenas as palavras no início do nome do arquivo.

[helmi]

Existe alguma documentação para discourse restore em algum lugar? já que parece haver uma opção --location local, presumo que também haveria uma para S3?

Estou procurando restaurar backups localizados no S3 e evitar ter que baixá-los manualmente com antecedência.

EDIT: esquece. Acabei de descobrir que discourse restore --location s3 $filename funciona muito bem.

[Jagster (Jakke Lehtonen)]

Como habilitei o S3 em app.yml, um simples discourse restore <filename> funcionou perfeitamente.

Acho que se você pesquisar por backup restore s3, encontrará o post correto.

[Ethsim2 (Ethan)]

Olá, concluí este processo usando s3(-cli) como meu scp e uma mudança no provedor de e-mail de saída de MailGun para Brevo

Desde a restauração, não consigo encontrar uma maneira de remover o banner?

[Moin]

@Discourse

O processo de restauração define automaticamente a configuração desabilitar e-mails como “não-staff”, para que os e-mails não sejam enviados aos usuários do seu site até que você esteja pronto.

A maneira mais fácil de remover o banner é habilitar os e-mails nas configurações do site

[pfaffman (Jay Pfaffman)]

@Moin

A maneira mais fácil de remover o banner é habilitar os e-mails nas configurações do site

Certo. Você também poderia escondê-lo com CSS!

[Moin]

Verdadeiro. Fiquei um pouco cauteloso ao recomendar isso porque tive que pensar em Air theme hides "outgoing email disabled" warning

[pfaffman (Jay Pfaffman)]

@Moin

Fiquei um pouco cauteloso ao recomendar isso porque tive que pensar em tema Air oculta aviso de “email de saída desativado”

Toda vez que você restaura um backup, o email é automaticamente desativado para não-funcionários. Imagino que isso foi adicionado ao código apenas algumas vezes após uma restauração ter sido feita em um servidor de teste que começou a inundar seus usuários com notificações para um servidor que eles não deveriam saber que existia.

Atualizei o OP de acordo:

@Discourse

Habilitar Email

Quando um backup é restaurado, o email de saída para não-funcionários é desativado. Você não vai querer que seu servidor de teste, servidor novo ou servidor para o qual você acabou de restaurar um backup por qualquer outro motivo comece a enviar emails para seus usuários! Altere a configuração do site “disable_emails” para reativar o email.

[thoka (Thomas Kalka)]

Nota para o guia de como fazer:

Se você restaura backups regularmente para fins de teste e seu servidor de teste está configurado corretamente, para enviar e-mails para um serviço de depuração de e-mail (como GitHub - maildev/maildev: 📫 SMTP Server + Web Interface for viewing and testing emails during development.), você pode querer habilitar e-mails via script:

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

[pfaffman (Jay Pfaffman)]

Nesse caso, você pode querer definir DISCOURSE_DISABLE_EMAILS como não no seu app.yml. (e também DISCOURSE_ENABLE_RESTORE para facilitar a restauração)