Como fazer backup e restaurar toda a pasta de aplicativo /var/discourse?

Suporte Instalação
1

Como fazer backup e restaurar toda a pasta /var/discourse?

Devido a problemas no processo usual de backup e restauração, eu me perguntei se poderia fazer backup de toda a pasta /var/discourse e reutilizá-la em outro servidor. Foi isso que fiz…

No servidor de produção:

rsync_opts="\
   --recursive \
   --links \
   --hard-links \
   --safe-links \
   --owner \
   --group \
   --perms \
   --times \
   --delete \
   --sparse \
   --compress \
   --partial \
   --rsh=ssh
"

dir=/var/discourse

rsync  $rsync_opts "$dir/" root@xx.xx.xx.xx:"/var/production-backup/$dir"

No servidor de staging:

Instale o Docker.

rsync --recursive --links --hard-links --safe-links --owner --group --perms --times --delete --sparse --compress --partial /var/production-backup/var/discourse/ /var/discourse

Mas estou recebendo 502 Bad Gateway.

Tentando investigar.

cd /var/discourse

./launcher start app

root@whonix-app:/var/www/discourse# service postgresql status
12/main (porta 5432): desligado

root@whonix-app:/var/www/discourse# service postgresql start
[....] Iniciando servidor de banco de dados PostgreSQL 12: main[....] Erro: O cluster é propriedade [FAIL do ID 116, que não existe ... falhou!
 falhou!

Acho que algumas correções:

chown -R postgres.postgres /etc/postgresql
chown -R postgres.postgres /shared/postgres_*
chown -R postgres.postgres /var/lib/postgresql
chown -R postgres.postgres /var/log/postgresql
chown -R redis.redis /etc/redis/redis.conf
chown -R redis.redis /shared/redis_data
chown -R redis.redis /var/run/redis
chown -R redis.redis /var/lib/redis
chown -R redis.redis /var/log/redis
chgrp -R ssl-cert /etc/ssl/private

Mas não ajudou.

root@whonix-app:/var/www/discourse# service postgresql start
[....] Iniciando servidor de banco de dados PostgreSQL 12: main[....] Erro: /usr/lib/postgresql/12/bin/pg_ctl /usr/lib/postgresql/12/bin/pg_ctl start -D /shared/postgres_data -l /var/log/postgresql/postgresql-12-main.log -s -o -c config_file="/etc/postgresql/12/main/postgresql.conf" saiu com status 1: 2020-05-25 10:20:10.501 UTC [603] FATAL: arquivos de banco de dados incompatíveis com o servidor 2020-05-25 10:20:10.501 UTC [603] DETAIL: O diretório de dados foi inicializado pela versão 10 do PostgreSQL, que não é compatível com esta versão 12.2 (Debian 12.2-2.pgdg100+1). pg_ctl: não foi possível iniciar o servidor. Examine o lo[FAILput. ... falhou!
 falhou!

Por que esses problemas de permissão de arquivo foram introduzidos?

Por que o PostgreSQL foi atualizado da versão 10 para a versão 12 apenas copiando toda a pasta de um servidor para outro? Devo estar fazendo algo errado.

Você poderia, por gentileza, compartilhar instruções sobre como fazer backup de todo o aplicativo Discourse em um servidor e movê-lo para outro servidor?

2

O Discourse não usa o Phabricator?

3

Erro de digitação. Queria dizer discourse. Erro corrigido. A pergunta original permanece.

4
5

Isso não move a pasta inteira /var/discourse. Estou ciente dessas instruções, mas elas não funcionam para mim. Por isso, queria um método mais “completo” de cópia exata 1 para 1 para fazer o backup.

6

Você pode desligar o container e copiar tudo para um novo servidor, excluindo os diretórios tmp, backup e cache (e acho que há outro também?). Isso deve funcionar. Fiz algo assim recentemente, acho que por um motivo semelhante.

Mas você ainda precisa resolver o problema do índice corrompido.

7

Acho que a versão do Docker está introduzindo diferenças. (O que, por sua vez, leva à falha.)

Servidor original
docker-engine 17.05.0~ce-0~debian-stretch

vs servidor mais recente (staging)
docker-engine 17.05.0~ce-0~debian-stretch

Isso resulta no servidor original tendo a versão 10 do PostgreSQL, enquanto o servidor mais recente (staging) já tem o PostgreSQL 12.

Isso é obrigatório? Existe uma maneira mais fácil? Por que seria necessário não copiar tudo exatamente como está e restaurar?

Levando a problemas de permissão que não consigo explicar. Deveria ser possível copiar sem quebrar as permissões. E também não tenho certeza se corrigi todos os problemas de permissão.

Sim, mas acho que seria muito mais seguro prosseguir com isso apenas quando eu puder pelo menos reproduzir o que ainda está funcionando agora.

8

Você não pode simplesmente “tarar” o diretório /var/discourse, movê-lo para outra máquina, descompactá-lo e iniciar o aplicativo Discourse.

Uma das principais razões é que, ao construir/inicializar o Discourse, o launcher (como me recordo de cabeça) verifica se existe um contêiner base do Discourse (imagem) e baixa a imagem Docker base do Discourse (se não existir), iniciando essa imagem Docker base em um contêiner.

Após esse git pull base, o processo de construção cria outra imagem Docker (a do aplicativo).

Ambas as imagens Docker (a imagem base e a imagem do aplicativo) não existem dentro de /var/discourse, então tarar /var/discourse é apenas uma “solução” parcial (usando esse termo de forma leve).

Essas imagens Docker do Discourse são construídas como imagens Docker e, como parte do Docker; elas não “vivem” em /var/discourse, mas são construídas lá e depois movidas para o Docker como imagens Docker.

Pode ser possível editar seu arquivo YAML do contêiner e reconstruir do zero, mas a maneira mais convencional é apenas salvar seu:

  • arquivo(s) YAML do contêiner
  • seu backup completo com uploads

E então editar seu YAML do contêiner, clonar o repositório discourse-docker e reconstruir.

Em seguida, restaure seu backup completo, incluindo uploads (pela linha de comando dentro do contêiner).

Usar o GitHub como repositório é uma solução mais limpa do que a maneira mais antiga e “unixiana” de “tarar tudo aquilo” e “mover tudo aquilo” para outro servidor. No entanto, mesmo com a “maneira unix antiga”, esse método muitas vezes não fornece uma solução completa porque há frequentemente bibliotecas compartilhadas no sistema, diretórios de usuários de bibliotecas compartilhadas e mais, que não fazem parte do diretório de distribuição, e há arquivos etc que não estão no diretório raiz da distribuição, etc.

Portanto, mesmo na maioria dos sistemas Linux modernos, usamos apt (no Ubuntu, por exemplo) para baixar o repositório. No caso do Docker do Discourse, você está baixando (e construindo) o discourse-docker para configurar o contêiner base e outro repositório do Discourse para construir o aplicativo. Assim, /var/discourse é um “local de construção” (das imagens) e um “local de compartilhamento” (dos dados, dos backups, dos arquivos estáticos públicos, etc.).

Espero que este resumo tenha sido útil de alguma pequena forma.

9

Claro, você pode copiar tudo com rsync -rav.

Você pode ter mais sorte se alterar seu aplicativo para usar o modelo do PostgreSQL 10. Mas parece que a coisa mais fácil pode ser apenas corrigir seu banco de dados no local.

10

Você pode mover a pasta, funciona sem problemas. Apenas não é o caminho preferido, pois contorna o discourse-setup e qualquer ajuste/teste que ele executa no processo.

11

No meu caso, não funcionou, pois a atualização do Docker resultou em uma versão mais recente do PostgreSQL dentro do container do Docker, o que, por sua vez, tornou o fórum inutilizável devido a problemas de migração do PostgreSQL. Tive que mudar do template do PostgreSQL para o do PostgreSQL 10.

How to backup and restore a whole /var/discourse app folder? - #8 by neounix explica os detalhes bem.

Acho que teria que fazer backup e restaurar a pasta /var/docker também. Mas até isso tem chance de falhar por causa disso:

12

Você está descendo a toca do coelho.
Se eu fosse você, focaria em resolver seu problema original com backup/restauração.

13

Talvez até um buraco de :rat: :rat: :rat:.

Concordo… com certeza…

@adrelanos

Não há “problemas” com o processo de backup/restauração. Veja este “elogio” que o próprio @neounix escreveu há alguns meses sobre esse tópico:

14

Caro @adrelanos,

Voltando à sua pergunta original no post #1 acima, sendo curioso por natureza, não fiquei realmente satisfeito com minha resposta anterior e fiz alguns testes hoje.

Em resumo, confirmei que podemos usar docker save (para os contêineres base e de aplicativo) e tar para o diretório /var/discourse, salvando, transferindo (backup) e restaurando completamente o aplicativo dessa forma.

Tenho quase certeza (99,99%) de que esse método não é oficialmente suportado, mas você merece uma resposta, então fiz esse teste para você:

Basicamente, aqui estão os passos, em resumo:

  1. Salve seus contêineres com docker save.

Por exemplo, se você estiver executando um aplicativo standalone, pode salvar o contêiner base e o de aplicativo, assim (com base na sua configuração):

docker save -o /tmp/my.discourse.docker.app.tar  discourse/base:2.0.20200512-1735

e também:

docker save -o /tmp/my.discourse.docker.app.tar local_discourse/app:latest
  1. Você também pode compactar o diretório /var/discourse, como você mencionou:
cd /var/
tar -cvzf /tmp/my.var.discourse.tar.gz discourse

e então comprima seus arquivos tar do Docker, se desejar, e arquive-os:

gzip /tmp/my.discourse.docker*.tar
  1. … e você pode mover esses arquivos para outro servidor, arquivá-los no mesmo servidor, o que quiser, inverter os passos e iniciar o aplicativo Discourse sem problemas.

Eu confirmei isso “fazendo”, apagando todas as imagens de contêiner e o diretório /var/discourse. Basicamente, eliminei tudo e reiniciei (sem necessidade de reconstruir, já que o domínio não mudou, etc.) a partir dos backups.

Por exemplo, para restaurar, você pode pegar as imagens do Docker salvas acima e carregá-las, por exemplo:

gzip -d /tmp/my.discourse.docker.app.tar.gz
docker load -i /tmp/my.discourse.docker.app.tar

gzip -d /tmp/my.discourse.docker.base.tar.gz
docker load -i /tmp/my.discourse.docker.base.tar
  1. Em seguida, extraia seu diretório original /var/discourse
cd /var
tar -xvzf /tmp/my.var.discourse.tar.gz
  1. Depois, você precisa verificar suas imagens para garantir que estejam corretamente rotuladas:
docker images
  1. e se as imagens não estiverem corretamente rotuladas, certifique-se de marcá-las corretamente, por exemplo, para sua imagem de aplicativo:
docker tag 58ffc74989af local_discourse/app:latest
  1. Então, basta fazer o seguinte:
cd /var/discourse
./launcher start app

e funciona perfeitamente. Eu testei isso (duas vezes).

Espero que isso ajude.

A título de informação: tentei esse método de duas maneiras diferentes, fazendo o método de backup acima, apagando todos os contêineres Docker, imagens e o diretório /var/discourse (destruindo totalmente tudo, a cada vez).

Em cada caso, consegui carregar minhas imagens do Docker salvas, extrair o diretório /var/discourse, executar ./launcher start app e o Discourse iniciou perfeitamente. Para provar, pude fazer um backup normal pela interface, comprovando que tudo estava correto.

Não sei se isso responde à sua pergunta (e não tenho participado da atualização ou discussões do Postgres 10 para 12); mas, em relação à sua pergunta sobre apenas compactar o aplicativo como backup e restaurá-lo, a resposta é sim, mas você deve não apenas arquivar o diretório /var/discourse, mas também docker save suas imagens.

O principal “problema” é manter o nome do repositório da imagem e as tags corretos, e você estará pronto para prosseguir.

Espero que isso responda à sua pergunta, de alguma forma, sobre:

Como fazer backup e restaurar toda a pasta /var/discourse do aplicativo?

A resposta é que você deve arquivar tanto sua pasta quanto suas imagens Docker (como no exemplo acima), usando docker save para as imagens (para backup) e docker load para restaurar.

Lembre-se de que esse método não é oficialmente suportado; mas, por curiosidade, quis ver como fazer isso sob a perspectiva do administrador de sistema e descobri que era mais fácil do que minhas respostas anteriores indicavam.

Nota 1:

Você pode querer mover todos os backups do diretório backups/default (para fora da árvore de diretórios) antes de compactar tudo em /var/discourse/ e manter esses backups (separadamente), já que esses arquivos são tão grandes…

Nota 2:

Esse tipo de backup não é suportado e, portanto, não é recomendado para a maioria dos administradores de sistema do Discourse. Recomendo que os usuários sigam o método de backup e recuperação do Discourse recomendado (e oficialmente suportado).

Mantenha a curiosidade!

Cuide-se.

Para mais detalhes, incluindo capturas de tela, veja gentilmente meu post completo aqui:

15

Essa é uma abordagem excelente! Obrigado!

Um problema no servidor de restauração.

./launcher logs app

2020-06-18 13:33:56.434 UTC [127] FATAL: data directory “/shared/postgres_data” tem propriedade incorreta
2020-06-18 13:33:56.434 UTC [127] HINT: O servidor deve ser iniciado pelo usuário que possui o diretório de dados.
./run: 3: echo: echo: erro de E/S
2020-06-18 13:33:57.448 GMT [128] LOG: ignorando arquivo de configuração ausente “/shared/postgres_data/postgresql.auto.conf”

Isso pode ser devido a algumas opções tar ausentes? Adicionei -p e -s durante a extração, mas não ajudou.

servidor original (fora do docker):

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 4096 May 25 13:16 base

servidor original (dentro do docker (./launcher enter app)):

ls -la /var/lib/postgresql/10/main/

drwx------ 5 root postgres 4096 May 25 23:28 base

servidor de restauração fora do docker:

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 71 May 25 11:16 base

servidor de restauração dentro do docker:

drwx------ 5 root postgres 41 May 25 23:28 base

./launcher rebuild app corrigiria, mas isso foge ao ponto.

Alguma ideia?

16

Acho que você quis dizer docker save -o /tmp/my.discourse.docker.base.tar discourse/base:2.0.20200512-1735, com base no seu processo de restauração. De qualquer forma, ótima explicação!

Mas, como você disse, não acho que essa seja uma abordagem oficialmente suportada (mas também não acredito que haja algo mais que possa causar erros, a menos que a equipe do Discourse comece a usar mais de uma imagem base no processo de reconstrução).

17

Parece que há o mesmo problema em:

https://meta.discourse.org/t/postgresql-12-update/151236/298?u=lucasbasquerotto

Não há uma resposta específica para esse problema na FAQ, mas talvez a equipe do Discourse adicione uma solução, considerando que mais de uma pessoa enfrentou isso. Existe uma FAQ sobre O cluster de origem não foi desligado corretamente, que pode estar relacionada ao seu problema.

18

Um método que usei e que não envolve docker save ou um tar+untar completo de /var/discourse: