Backups falham ao fazer upload para S3 várias vezes - funciona eventualmente

Suporte
,
1

Os backups para o S3 estão funcionando há vários anos. Começando há um mês, frequentemente recebo várias notificações de que o backup falhou. Então ele tenta novamente e, cerca de uma hora depois, falha novamente, então recebo uma segunda notificação e, frequentemente, até seis notificações em um único dia antes de finalmente ter sucesso.

O log da notificação indica que está falhando ao fazer o upload do arquivo tar compactado para o S3. Não consigo encontrar nenhum erro na minha conta do S3.

Log A primeira parte do log parece normal, depois: [2025-05-20 07:11:38] Finalizando backup... [2025-05-20 07:11:38] Criando arquivo: 506-investor-group-2025-05-20-070428-v20250513161753.tar.gz [2025-05-20 07:11:38] Garantindo que o arquivo não exista já... [2025-05-20 07:11:38] Criando arquivo vazio... [2025-05-20 07:11:38] Fazendo backup do despejo de dados... [2025-05-20 07:12:17] Arquivando uploads... [2025-05-20 07:15:48] Removendo o diretório tmp '/var/www/discourse/tmp/backups/default/2025-05-20-070428'... [2025-05-20 07:15:48] Compactando arquivo, isso pode levar um tempo... [2025-05-20 07:32:51] Enviando arquivo..
2

Você poderia estar ficando sem memória? Essa exceção me faz pensar que o Sidekiq (que executa os backups automáticos) está sendo encerrado pelo sistema operacional ou falhando por algum outro motivo.

Você tentou reconstruir o contêiner Docker (./launcher rebuild app) para ver se isso o corrige?

3

Acho que não. O servidor é mais do que suficiente para nossa comunidade com 16GB de RAM. top mostra 11GB de memória livre, e isso mal muda se eu acionar manualmente um backup.

Vou verificar /var/log/syslog amanhã para qualquer coisa sobre memória, kill ou OOM. (Não posso verificar hoje porque tive alguns logs verbosos não relacionados e o evento de backup sai do buffer do syslog.)

Sim, atualizei para 3.5.0.beta5-dev há alguns dias e o problema persiste.

4

Eu tenho isso em /logs. Este aviso em particular não coincidiu com o backup - verificarei isso pela manhã (os backups são feitos à noite). Mas eu não sabia que o Discourse tinha sua própria verificação de memória - pensei que você estivesse se referindo ao OOM killer. Posso aumentar o tamanho de memória permitido para o Sidekiq?

Mensagem

Sidekiq está consumindo muita memória (usando: 547.87M) para ‘ip-172-26-9-xxx-app’, reiniciando

Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_check’
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_check’
config/unicorn.conf.rb:132:in `block (2 levels) in reload’

EDIT: Eu vejo isso:

1 curtida
5

De fato, eu estava me referindo ao OOM killer. Esqueci completamente que há um limite de memória para o Sidekiq. Aumentar a memória para o Sidekiq ajudou?

6

Acredito que isso tenha resolvido - quero ver mais alguns backups noturnos limpos para ter certeza. Postarei aqui.

1 curtida
7

Sim, está resolvido. Pode fechar este tópico.

1 curtida