Ative a configuração oculta para incluir uploads S3 nos backups

:bookmark: Este guia explica como habilitar uma configuração oculta no Discourse para incluir uploads do Amazon S3 (Simple Storage Service) em seus backups.

O Discourse tem a capacidade de armazenar uploads de mídia no Amazon S3 para escalabilidade e confiabilidade. No entanto, esses uploads não são incluídos em backups por padrão.

Este guia abrange a habilitação de uma configuração oculta para incluir uploads do S3 em backups, com opções para configurá-lo via console Rails ou arquivo app.yml.

Usando o Console Rails

Para habilitar a inclusão de uploads do S3 em backups via console Rails, você pode seguir estas etapas:

  1. Acesse seu servidor Discourse via SSH.
  2. Entre no contêiner Docker do Discourse executando:
cd /var/discourse
./launcher enter app
  1. Inicie o console Rails:
rails c
  1. Habilite a configuração executando:
SiteSetting.include_s3_uploads_in_backups = true
  1. Saia do console e do contêiner digitando:
exit
exit

Essa alteração entra em vigor imediatamente. Nenhuma ação adicional é necessária.

Modificando o Arquivo app.yml

Você também pode fazer essa alteração adicionando e modificando o arquivo app.yml na seção env:.

  1. Acesse o diretório do contêiner do aplicativo Discourse:
cd /var/discourse
  1. Abra o arquivo app.yml localizado em containers:
nano containers/app.yml
  1. Na seção env:, adicione a linha:
DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true
  1. Salve o arquivo e saia do editor.
  2. Aplique as alterações reconstruindo o aplicativo:
./launcher rebuild app

Para que essa alteração tenha efeito, você precisa executar o comando ./launcher rebuild app para que a configuração seja aplicada.

9 curtidas

Não é suficiente destruir e reiniciar o contêiner?

1 curtida

Eu acho que você não precisa destruir e reiniciar é o suficiente. Confirmarei mais tarde.

De qualquer forma, obrigado @pfaffman pelo seu outro howto guia que usei como modelo para este.

2 curtidas

Tenho certeza de que você precisa destruir e iniciar para alterar as variáveis de ambiente aplicadas ao contêiner.

Claro, se eles fizeram atualizações com o gerenciador do Docker, elas serão perdidas quando o contêiner for destruído, e é por isso que a reconstrução é a recomendação mais segura. Talvez seja melhor recomendar a reconstrução, pois é a mais à prova de falhas.

3 curtidas

Por que essa configuração aqui não é suficiente para incluir todos os uploads no backup:
image

Isso incluirá os uploads locais, mas não baixará arquivos que estão no s3 para inclusão no backup.

1 curtida

Ok. Eu não sabia.
Mas qual a diferença entre ‘Local Uploads’ e a pasta “Files Stored in S3 ‘Uploads’”?

Além disso, embora eu ainda não tenha alterado a configuração em web_only ou no console do rails, como dito acima, mas apenas escolhi a configuração mencionada aqui.

Mas ainda assim, quando executei o backup, há apenas 10 minutos, ele mostrou como se tivesse baixado milhares de arquivos (que presumo que só poderiam estar no meu bucket de armazenamento aws s3, e a própria palavra ‘Download’ significa que está baixando da pasta remota do bucket S3).
Também está mostrando que Falhou ao baixar muitos, muitos arquivos. Então presumi que, se esses arquivos estivessem no servidor de nuvem local, por que ele deixaria de incluir esses arquivos no backup? Veja esta captura de tela:

Se você configurou Configurar um provedor de armazenamento de objetos compatível com S3 para uploads e moveu seus uploads locais para o S3, então seus uploads estão lá. Eles não são copiados porque assume-se que o S3 é copiado e o download deles é caro e geralmente desnecessário.

Se você precisar retirá-los do S3 (como se estivesse hospedado em discourse.org e estivesse se mudando para outra hospedagem), você precisará de um backup que inclua os arquivos armazenados no S3.

Por que você quer baixar seus arquivos do S3?

Sim, parece que está falhando ao baixar os arquivos do S3. Minha suposição é que ele não baixou nenhum deles, embora seja possível que seu disco esteja cheio, talvez (eu esperaria um erro de disco cheio, mas talvez não?).

1 curtida

Obrigado. De novo.

Sendo o meu um site muito, muito pequeno, pagar alguns dólares, que aumentam a cada mês com pequenas atualizações, todo mês para o armazenamento Aws S3 está se mostrando um pouco impraticável para mim. Vou mudar a localização dos ‘Uploads’ (e talvez da pasta ‘backup’ também) para outro provedor como Google One Drive, iDrive, Hetzner, etc. alternativas baratas.
Agora descubro que mesmo os diferentes tipos de armazenamento da Aws (do mais ativo para o tipo de arquivamento), se eu os tivesse escolhido sabiamente no início, custariam apenas metade pela mesma quantidade/número de arquivos.

Mas eu faria isso agora.

1 curtida

Quando escolhi armazenar meus ‘uploads’ de mídia no bucket S3 da AWS anos atrás, naquele momento (tanto quanto tenho certeza) TAMBÉM MOVIMENTOU todas as mídias existentes enviadas pelos usuários para o S3.

Além disso, verifiquei agora em minha pasta /var/discourse/shared/web_only/uploads/default/optimized/1X, ela tem apenas 63 arquivos png e /var/discourse/shared/web_only/uploads/default/original/1X tem apenas 3. (Exceto 1x, nenhuma outra pasta semelhante existe na pasta ‘uploads ou default’.

Além disso, ainda não alterei nenhuma opção no console rails ou no arquivo Yml para incluir uploads S3 em meus backups. Então, por que ele está mostrando que baixou tantos ‘Uploads de Mídia’ DO S3!!!
E falhou em baixar tantos arquivos enviados? Captura de tela aqui.

Além disso, minha pasta de uploads no S3 tem cerca de 3 gb (32k arquivos), enquanto os logs de backup mostraram que ele baixou apenas cerca de 3,2k (10% do total).

Muito confuso.

Existe algum OUTRO comando rails para ter certeza se essa opção não foi ativada anos atrás, quando mudei para a AWS S3?

Qualquer explicação será útil.