Backup de emergência - linha direta para o comando do container

Aprendi algo que pode ajudar outras pessoas.

Contexto: Conforme detalhado em outro lugar, minha instalação do Discourse estava hospedada em um VPS cujo disco era muito pequeno para concluir uma atualização. Primeiro, cliquei em “Atualizar” no painel de controle de administração. A atualização falhou e a interface gráfica nunca mais funcionou. Depois disso, acessei o console do meu VPS e executei o famoso comando ./launcher rebuild app. Isso também nunca foi concluído: eu havia ficado decisivamente sem espaço em disco. Para obter mais espaço e manter o orçamento, decidi mover toda a minha configuração para um novo VPS com uma empresa de hospedagem diferente. Salvar os dados preciosos do site era uma alta prioridade.

Falhas: Os dois métodos mais óbvios para fazer um backup não funcionaram:

  • minha tentativa original de atualização quebrou a interface gráfica baseada na web, então não havia como acessar o painel de controle de administração e iniciar um backup a partir dele; e
  • tentar entrar no contêiner docker e executar alguns comandos shell também não funcionou. O comando recomendado para isso é /var/discourse/launcher enter app. Mas, pelo menos no meu caso, o script launcher tentaria reconstruir o aplicativo antes de me deixar entrar nele, e as reconstruções estavam falhando consistentemente, então este comando nunca me deu um contêiner, muito menos um shell dentro dele.

Sucesso: Eu estava prestes a desistir quando tive uma surpresa agradável. Trabalhando na linha de comando da minha pequena VM, digitei docker ps e descobri que havia um contêiner ativo chamado app. E o docker tem uma maneira direta de entrar em um contêiner em execução: o comando é docker exec -it app bash.

Dentro do contêiner, consegui progredir: emiti o comando discourse backup, esperei alguns minutos e depois copiei o arquivo <backup>.tar.gz para um local seguro. Com um backup atual em mãos, foi possível concluir a migração da minha configuração para sua nova casa. (Existem outros tópicos nesses fóruns mostrando como fazer isso.)

O ponto principal aqui é que o comando docker acima para entrar no contêiner funcionou, mesmo quando o comando específico do Discourse ./launcher não funcionou.

Obrigado aos inventores e mantenedores deste excelente produto.

3 curtidas

Você tentou

./launcher cleanup

Ou excluir alguns backups?

1 curtida

Obrigado por perguntar.

Durante os dias em que tentei fazer minha configuração original funcionar, pensei ter feito tudo o que era possível para recuperar espaço, certamente incluindo ./launcher cleanup, mas também muito mais… removendo kernels antigos, limpando o cache do apt, descartando software não essencial, etc., etc.

Depois que me comprometi a mover todo o meu site e dediquei muito tempo ao processo, me perguntei se poderia ter feito mais… mas já havia perdido o ânimo para investigar mais a fundo. (cf. “falácia do custo irrecuperável”.) Para ser específico, o VPS que estou prestes a abandonar tinha um tamanho nominal de disco de 25G. Cerca de 19G disso era dedicado ao diretório /var/lib/docker/overlay2. E os únicos contêineres docker que eu estava executando eram o Discourse e seu receptor de e-mail associado. A experiência sugere que o Discourse, por mais poderoso que seja, deveria ser capaz de rodar com muito menos de 19G no disco. Mas as buscas na internet pareciam indicar que fazer alterações dentro do diretório overlay2 era inseguro, então me senti travado naquele ponto.

Na minha nova configuração, o diretório /var/lib/docker/overlay2 ocupa 13G. Ainda enorme.

Escolhi o Discourse para rodar os fóruns em meu site de hobby em pequena escala na esperança de que ele “simplesmente funcionasse” – ou seja, que seria super simples de administrar sem aprender um monte de coisas novas. Isso parece estar em grande parte correto, se tivermos recursos suficientes (excessivos?) para alocar.

Meu novo plano é esperar cegamente que o diretório overlay2 não cresça com o tempo e inunde o disco de 50G no meu novo VPS. Se você (ou qualquer outra pessoa) souber como manter o tamanho da dupla dinâmica docker e Discourse sob controle, adoraria saber. Seria uma boa conclusão para o resto do aprendizado que fiz nos últimos dias. Obrigado novamente.

Fico feliz que você tenha conseguido se salvar. Eu administro dois pequenos fóruns, um sobre armazenamento de 20G e outro sobre 25G. Tenho que usar bastante tempo e engenhosidade às vezes para mantê-los funcionando. Mas também pareço continuar usando (e postando sobre) o mesmo conjunto de táticas. Veja abaixo.

O desenvolvimento do Discourse otimiza para outras coisas além de rodar em hardware de custo mínimo - embora ele quase consiga continuar funcionando para mim em meu ambiente restrito. Que continue assim por muito tempo.

A chave para trabalhar em configurações de pouco armazenamento é medir o que está acontecendo - com muita frequência vejo pessoas adivinhando o que pode estar acontecendo. Minha abordagem sempre começará com

Para mais informações, talvez procure minhas postagens por prune e journalctl e kernel.

2 curtidas