Mova sua instância do Discourse para um servidor diferente

[Discourse]

Este é um guia para mover sua instância do Discourse de um servidor para outro, incluindo todas as configurações e dados. Este guia se aplica a instâncias do Discourse auto-hospedadas que usam Docker.

Nível de usuário necessário: Administrador do Sistema

Este procedimento envolve alterações de domínio e DNS. Certifique-se de ter acesso tanto ao servidor de origem quanto ao de destino.

Este guia o orientará no processo de migração de sua instância do Discourse de um servidor para outro, garantindo que seus dados, configurações e estrutura sejam preservados.

Isenção de responsabilidade adicionada por @pfaffman 2025-09-12T05:00:00Z.

Essas instruções não funcionam bem agora porque você está usando https e Let’s Encrypt, o que exige que o novo servidor tenha o DNS apontado para ele para que possa solicitar chaves. O que eu recomendo é seguir o Mover um site Discourse para outro VPS com rsync (talvez usando --exclude postgres* e depois fazendo backup e restaurando o banco de dados pela linha de comando.) Isso é interessante, pois se você souber como, poderá ajustar seu DNS local para apontar para o novo servidor para que possa testar se está funcionando enquanto o resto da internet ainda vê o site antigo.

Resumo

Você executará as seguintes etapas principais neste guia:

1. Faça backup de sua instância atual do Discourse (servidor de origem).
2. Transfira o arquivo de backup para sua instância de destino do Discourse (servidor de destino).
3. Restaure o backup no servidor de destino.
4. Atualize as configurações de DNS (se aplicável).

Ajustando as configurações de DNS (quando necessário)

Se você estiver usando o mesmo domínio para o novo servidor, reduza o TTL (tempo de vida) em sua entrada de DNS com antecedência. Isso garante o tempo de inatividade mínimo durante a propagação dos registros de DNS atualizados. Se você for usar um novo domínio, esta etapa pode ser ignorada.

Fazendo login e preparando o servidor de origem

1. Faça login em sua instância de origem do Discourse com uma conta que tenha permissões de administrador.
2. Certifique-se de que tanto o servidor de origem quanto o de destino estejam usando:
   • A mesma versão do Discourse.
   • O mesmo conjunto de plugins.
3. Atualize a versão do Discourse em ambos os servidores visitando /admin/upgrade.

Evite restaurar um backup mais recente em uma versão mais antiga do Discourse, ou versões incompatíveis do PostgreSQL, pois isso pode causar erros.

Criando e baixando o backup

1. Navegue até /admin/backups em sua instância de origem do Discourse.
2. Clique no botão Backup para criar um backup:
   
   
3. Quando solicitado, confirme clicando em Yes (Sim).
4. Assim que o backup for concluído, vá para a aba Backup files (Arquivos de backup) e localize o backup recém-criado.
5. Clique em Download (Baixar) para receber um e-mail com um link para download. Clique no link no e-mail para salvar o arquivo de backup localmente.
   
   

Antes de prosseguir, revise seu arquivo app.yml para garantir que quaisquer configurações opcionais, como configurações de CDN, plugins instalados ou suporte a HTTPS, sejam consistentes entre os servidores de origem e destino.

Restaurando o backup no servidor de destino

Para restaurar o backup pela linha de comando, consulte a documentação relevante.

1. Faça login como administrador em sua instância de destino do Discourse.
2. Navegue até /admin/backups/settings e ative a configuração allow restore (permitir restauração).
3. Vá para /admin/backups e clique na aba Backup files (Arquivos de backup). Carregue o arquivo de backup que você baixou anteriormente clicando no botão Upload (Carregar):
   
   
4. Após o carregamento ser concluído, clique no menu ⋮ (mais opções) ao lado do backup carregado e, em seguida, clique em Restore (Restaurar):
   
   
5. Confirme clicando em Yes (Sim) quando solicitado.

O processo de restauração começará. Isso pode levar algum tempo, dependendo do tamanho do seu banco de dados. Após a conclusão do processo, você será desconectado automaticamente.

Finalizando e fazendo login

1. Faça login em sua instância de destino do Discourse com suas credenciais de administrador.
2. Se o site foi feito backup usando HTTPS, certifique-se de que o HTTPS esteja ativado no novo servidor. Se não estiver configurado corretamente, use o console do Rails para desativar temporariamente a configuração “force https” (forçar https).
3. Reative quaisquer configurações opcionais editando o arquivo app.yml e reconstruindo sua instância. Isso pode incluir:
   • Ativação do suporte a CDN.
   • Instalação de plugins adicionais.
   • Configuração de HTTPS.

Problemas comuns e soluções

O arquivo de backup não está restaurando

• Verifique se as versões do Discourse e do PostgreSQL correspondem entre os servidores de origem e de destino.

Impossível fazer login após a restauração (com HTTPS ativado)

• Use o console do Rails para desativar force_https temporariamente executando:

  SiteSetting.force_https = false
  

[bayardo.rivas]

Este guia ainda é válido 11 anos depois?

Estou executando meu Discourse no Ubuntu e quero atualizar o sistema operacional de 20.04 LTS para 24.04 LTS com o mínimo de tempo de inatividade. Está na AWS.

[merefield (Robert)]

@bayardo.rivas

ainda válido 11 anos depois?

Isso é um pouco pessimista

@Discourse

Última edição por @SaraDev 2024-11-21T00:47:52Z

[Jagster (Jakke Flemming)]

Ou é… realista? Ou seja, por causa desse tipo de coisas:

@Discourse

Verifique se as versões do Discourse e do PostgreSQL correspondem entre os servidores de origem e destino.

[bayardo.rivas]

Acho válido se preocupar e perguntar se isso é como a documentação. Recentemente, atualizei meu fórum Discourse e tive alguns problemas que quebraram o sistema, eu estava apenas atualizando de uma versão para a mais recente. Algo sobre novos plugins que agora estão no sistema principal do Discourse.

Acho que mudar para uma instância diferente com um sistema operacional mais novo é uma grande mudança. Se eu for tentar essa abordagem, gostaria de ter todo o feedback possível.

Agradeço quaisquer comentários úteis. Obrigado.

[merefield (Robert)]

Este guia está um pouco fora do escopo dessa alteração específica.

[bayardo.rivas]

obrigado pelos seus comentários.

[Gunnar (Gunnar Helliesen)]

Se você ainda estiver no Ubuntu 20.04, você está usando Docker e aufs?

Se sim, você deve ler isto antes de prosseguir:

Docker Upgrade Removed AUFS Storage Driver, Killed Discourse

I run a Discourse forum installation on Ubuntu 20.04.6 LTS. The Docker image uses AUFS for storage. Today, I installed upgrades via sudo apt upgrade. Now the Discourse forum is no longer accessible, and it appears to be because a Docker upgrade removed the AUFS storage driver. I see plenty of guides to configuring Docker to use Overlay2 instead, but I don’t see any guidance on how to migrate my existing Discourse installation to use Overlay2, especially now that I can’t start Docker to mount m…

[pfaffman (Jay Pfaffman)]

Acredito que sim, embora eu não tenha olhado com muita atenção. Não. O novo site falhará em obter chaves do Let’s Encrypt se o DNS não apontar para ele. Portanto, você precisaria fazer backup, transferir o backup, mudar o DNS para o novo servidor e, em seguida, reconstruir.

Se você quiser minimizar o tempo de inatividade, o que recomendo é Mover um site Discourse para outro VPS com rsync. Isso copia suas chaves SSL para que o novo servidor esteja pronto quando você reconstruir.

A menos que você já tenha atualizado para o Postgres 15 (e talvez mesmo assim), o que eu recomendaria (o que eu faço) é --exclude postgres*, reconstruir e, em seguida, fazer backup do site principal e restaurar esse backup no novo servidor. Quando isso for restaurado, mude o DNS. As instruções do rsync pedem para você desligar o banco de dados para que possa copiar os arquivos brutos do banco de dados. Existem alguns casos em que isso não funcionará muito bem, então, na maioria das vezes, faço um backup apenas do banco de dados e o restaure.

EDIT: Adicionei isso ao OP.

@\"Discourse

\n### Aviso adicionado por @pfaffman 2025-09-12T05:00:00Z.\n\nEstas instruções não funcionam bem agora porque você está usando https e let’s encrypt, que exigem que o novo servidor tenha o DNS apontado para ele para que possa solicitar chaves. O que eu recomendo é seguir o Mover um site Discourse para outro VPS com rsync (talvez usando --exclude postgres* e, em seguida, fazendo backup e restaurando o banco de dados da linha de comando.) Isso é elegante, pois se você souber como, pode ajustar seu DNS local para apontar para o novo servidor para que possa testar se funciona enquanto o resto da internet ainda vê o site antigo.\n

[nathank (Nathan Kershaw)]

Obrigado, Jay! Eu me perguntei por que fiquei um pouco preso com a questão de URL / DNS / LetsEncrypt no passado (recente) ao tentar seguir as instruções no OP.

No final, consegui usando um subdomínio para o novo site, garantindo que meu site restaurado no novo servidor estivesse funcionando e, em seguida, fazendo uma troca rápida de DNS / URLs. Mas tudo isso foi um pouco precário / doloroso (especialmente o jogo de “remap whack-a-mole” depois!).

Agora faz sentido por que precisei fazer tudo isso. E é bom saber que o rsync pode contornar alguns dos pontos problemáticos.

Acho que algumas instruções claras aqui realmente ajudariam os outros, pois é um pouco confuso no momento - e não tenho certeza da melhor maneira de fazer isso no futuro. Seu aviso poderia ser incorporado ao OP como uma reescrita (talvez por @SaraDev?).

[pfaffman (Jay Pfaffman)]

@nathank

Eu me perguntei por que fiquei um pouco preso com toda a questão de URL / DNS / LetsEncrypt no passado (recente) ao tentar seguir as instruções no OP.

É por isso que sugeri não seguir estas instruções.

@nathank

Acho que algumas instruções claras aqui realmente ajudariam outras pessoas, pois no momento está um pouco confuso.

Acho que ignorar ou excluir estas instruções e seguir o tópico rsync que eu linkei é o que ajudaria as pessoas.

Estou perdendo alguma coisa?

[Ethsim2 (Ethan)]

Apenas adicionando um caso extremo de migração com o qual me deparei aqui, caso ajude alguém.

Me deparei com um caso extremo do Let’s Encrypt/SSL ao mover uma instância standalone do Discourse para um novo VPS, então escrevi o diagnóstico exato e as etapas de recuperação, caso sejam úteis para qualquer outra pessoa seguindo este guia.

No meu caso, o nginx dentro do app não iniciava porque ambos os arquivos .cer em /var/discourse/shared/standalone/ssl/ haviam se tornado arquivos de zero bytes:

PEM_read_bio_X509_AUX() failed

A reconstrução tentou emitir o certificado novamente e, após várias tentativas, atingi o limite de taxa de certificados do Let’s Encrypt. Copiar os arquivos de certificado ainda válidos do servidor antigo não foi suficiente, pois iniciar o app os substituiu por arquivos de zero bytes novamente.

O que acabou corrigindo o problema foi parar o app e copiar tanto o diretório funcional /var/discourse/shared/standalone/ssl/ quanto o estado correspondente do /var/discourse/shared/standalone/letsencrypt/ do servidor antigo, e depois iniciar o container novamente.

Documentei a sequência completa aqui:

server_migration_diagnosing_standard_ssl.md

Estas são notas de diagnóstico/recuperação desta migração em particular, e não uma substituição para a documentação oficial de migração ou HTTPS.

Há também um tópico mais antigo no Meta cobrindo o modo de falha relacionado de .cer vazio:

Let's Encrypt - arquivos *.cer vazios

Não consigo me conectar a uma nova instalação padrão de 30 minutos. AWS Lightsail, 2 GB de memória, Ubuntu 18.04 LTS x64 com a porta :443 aberta. O problema é que os arquivos *.cer do Let’s Encrypt estão vazios. Por quê? Logs do nginx root:/var/log/nginx# ls -ltrh -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 error.letsencrypt.log -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 access.letsencrypt.log -rw-r–r-- 1 www-data www-data 1.8M Dec 6 08:19 error.log tail error.log PEM_read_bio_…