Restaurar um backup pela linha de comando

[Discourse]

Este guia explica como restaurar um backup do Discourse a partir da linha de comando sem usar a interface web do Discourse.
Nível de utilizador exigido: Administrador
Acesso ao console necessário

Veja como restaurar um backup do Discourse a partir da linha de comando, sem nunca iniciar a interface web do Discourse. Isso é útil quando você está mudando de servidor.

Pré-requisitos

Antes de começar, certifique-se de completar os seguintes passos:

1. Baixe o arquivo de backup mais recente da instância do Discourse de origem.
2. Inicialize a instância do Discourse de destino executando ./discourse-setup ou copiando seu app.yml existente.
3. Certifique-se de que a instância do Discourse de destino esteja na versão mais recente. Atualize-a, se necessário.

Transferir o backup

1. Conecte-se via SSH ao servidor de destino, ou crie a pasta de backup lá de outra forma:

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

2. Carregue seu arquivo de backup para o servidor de destino.

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

Certifique-se de substituir os caminhos, nomes de arquivos e nomes de servidor pelos que você está usando – mas você quer que o arquivo de backup termine em:

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

Você também pode carregar e baixar seu arquivo de backup do Discourse de sites populares de armazenamento na web, como Google Drive, Dropbox, OneDrive, etc. – você precisará procurar as instruções de linha de comando específicas com base no seu provedor de armazenamento na web preferido.

NÃO ALTERE O NOME DO ARQUIVO DE BACKUP! O Discourse trata o nome do arquivo de backup como metadados, portanto, se você alterar o nome do arquivo, a restauração não funcionará. Mantenha o nome de arquivo original.

Substitua /path/to/backup/discourse-xyz.tar.gz pelo caminho local do seu arquivo de backup e substitua \u003cserver_ip_address\u003e pelo endereço IP do servidor de destino.

Se o Nginx for usado como proxy reverso certifique-se de que todos os caminhos para o backup sejam legíveis pelo contêiner e que o Nginx possa ler o arquivo .sock.

Restaurar o backup

1. Acesse seu servidor de destino e navegue até a pasta do Discourse:

cd /var/discourse

2. Entre no contêiner do aplicativo Docker do Discourse:

./launcher enter app

3. Habilite a funcionalidade de restauração:

discourse enable_restore

4. Restaure o arquivo de backup:

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

Dica: Se você executar discourse restore sem um nome de arquivo, ele listará todos os arquivos de backup disponíveis.

Se a configuração backup_location do seu site estiver configurada para usar S3, mas você carregou manualmente o arquivo de backup para o sistema de arquivos local, você precisa especificar --location local:

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

Da mesma forma, use --location s3 para restaurar diretamente de um backup S3 sem baixá-lo primeiro.

5. Saia do contêiner do aplicativo Docker do Discourse:

exit

Reconstruir

Depois de restaurar o backup, você pode optar por reconstruir a instância de destino para garantir que todas as configurações e ajustes sejam aplicados corretamente.

Agora é um bom momento para atualizar /var/discourse/containers/app.yml com HTTPS completo, plugins adicionais ou configuração de CDN. Compare a configuração app.yml de ambas as instâncias para ter certeza!

cd /var/discourse
./launcher rebuild app

Habilitar E-mail

Quando um backup é restaurado, o envio de e-mails para não-membros da equipe é desabilitado. Você não quer que seu servidor de teste, novo servidor ou servidor para o qual você acabou de restaurar um backup por qualquer outro motivo comece a enviar e-mails aos seus usuários! Altere a configuração do site disable_emails para “no” para reativar o e-mail.

É isso. Seu servidor Discourse foi restaurado com sucesso.

[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 Flemming)]

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)