Estou tentando migrar minha instância do Discourse para um novo servidor. Como tenho espaço limitado no servidor, quero primeiro\n\nComo posso pausar a otimização de imagens após o upload inicial do banco de dados e restaurá-la.\n\nAssim, posso verificar se a restauração foi bem-sucedida, excluir o arquivo de backup e depois.\n\nMeu arquivo de backup tem cerca de 200 GB com a configuração desmarcada Incluir miniaturas geradas nos backups. Desativar isso tornará os backups menores, mas exigirá um novo processamento de todas as postagens após uma restauração.\n\nPortanto, vou ficar sem espaço em disco se minha instância mantiver o arquivo de backup e começar a otimizar as imagens.
Se precisar de mais espaço, você precisa de mais espaço.
Mas talvez você queira usar o rsync para as imagens e restaurar apenas o banco de dados. Dessa forma, você não terá duas cópias de todos os uploads (e não precisará criar miniaturas novamente).
Obrigado por tentar ajudar.
Eu tentei, mas não tinha certeza por que meu restauro não deu certo.
Meu principal problema é que minha instância antiga ficou presa na versão 12 do PostgreSQL, não encontrei uma maneira de atualizá-la e tentei migrar para uma nova instância limpa.
Você sabe se é possível restaurar apenas o banco de dados em uma instalação nova?
Quando tentei, a instância apenas começou a retornar o código de erro 500 e tive que começar tudo de novo.
O que eu faria seria seguir o Mover um site Discourse para outro VPS com rsync, exceto que não copiaria os arquivos do postgres.
Em seguida, faria um backup apenas do banco de dados e o restauraria. Você fará o rsync do backup também e o restaurará a partir da linha de comando.
Esta é uma versão muito antiga, imagino? A restauração parece ter sido concluída com sucesso?
1 curtida
Obrigado pela ajuda.
Sim, mas para uma restauração direta usando a interface web e o procedimento esperado, você precisa de mais de 4x o tamanho livre do seu arquivo de backup.
Veja como:
- Carregue o arquivo de backup (ou use rsync em
/var/discourse/shared/standalone/backups/default) - Uma vez que a restauração é inicializada, o arquivo de backup.gz é copiado para
/var/discourse/shared/standalone/tmp/restores/ - Durante a restauração, o arquivo de backup na pasta
/var/discourse/shared/standalone/tmp/restores/é descompactado - Da pasta tmp, os uploads são copiados para o local nativo e o dump SQL é inserido no banco de dados pg.
Como consegui restaurar com sucesso.
Durante o processo de restauração, assim que o Discourse copiou o arquivo da pasta de restauração para a pasta temporária, eu deletei o arquivo de backup original carregado via SSH.
Mais uma vez, quando o Discourse terminou com as inserções SQL e o rsync stat copiou os arquivos descompactados da pasta tmp para /var/discourse/shared/standalone/uploads/, eu deletei manualmente o arquivo bakupxxx.tar.gz na pasta temporária via SSH sem interromper o processo de restauração.
Uma vez que minha instância estava online e o rsync terminou, eu executei:
rm -rf /var/discourse/shared/standalone/tmp/restores/default/*
Se o seu processo de restauração de backup grande parecer travado e a instância retornar o código de erro 500 pela web (aconteceu comigo duas vezes), você pode verificar o processo de restauração entrando no aplicativo:
cd /var/discourse
./launcher enter app
ps aux | grep restore
Também, como a restauração do meu banco de dados demorou muito:
cd /var/discourse
./launcher enter app
watch -n 10 “sudo -u postgres psql discourse -c \“SELECT now(), state, query FROM pg_stat_activity WHERE state != ‘idle’;””
Me ajudou a monitorar o progresso da restauração do banco de dados, para ver se a restauração ainda estava ativa.
Essa é uma ótima solução! Se mais alguém encontrar isso, acho que fazer um restore apenas do banco de dados teria funcionado e seria um pouco mais fácil, mas fico feliz que você tenha conseguido resolver!
1 curtida