Backups continuam derrubando meu fórum

[piffy]

Tenho passado por ciclos em que a criação de backup está derrubando meu site devido a problemas de espaço.

Configurei para usar um volume separado do DO para armazenar os backups e uploads. O volume tem 300 GB.

Minhas configurações de backup:

O problema tem se repetido por meses. Receberei mensagens sobre falha no backup na caixa de entrada do administrador (veja abaixo).

Sem espaço no dispositivo

[2024-02-14 03:43:34] Finalizando backup...
[2024-02-14 03:43:34] Criando arquivo: elite-fourum-2024-02-14-033845-v20240204204532.tar.gz
[2024-02-14 03:43:34] Garantindo que o arquivo ainda não exista...
[2024-02-14 03:43:34] Criando arquivo vazio...
[2024-02-14 03:43:34] Arquivando dump de dados...
[2024-02-14 03:43:58] Arquivando uploads...
[2024-02-14 03:55:03] Removendo o diretório temporário '/var/www/discourse/tmp/backups/default/2024-02-14-033845'...
[2024-02-14 03:55:03] Gzipping o arquivo, isso pode levar algum tempo...
[2024-02-14 04:25:38] EXCEPTION: /var/www/discourse/lib/discourse.rb:138:in `exec': Falha ao comprimir o arquivo.

gzip: /var/www/discourse/public/backups/default/elite-fourum-2024-02-14-033845-v20240204204532.tar.gz: Sem espaço no dispositivo

[2024-02-14 04:25:38] /var/www/discourse/lib/discourse.rb:172:in `execute_command'
/var/www/discourse/lib/discourse.rb:138:in `exec'
/var/www/discourse/lib/discourse.rb:34:in `execute_command'
/var/www/discourse/lib/backup_restore/backuper.rb:253:in `create_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:40:in `run'
/var/www/discourse/lib/backup_restore.rb:13:in `backup!'
/var/www/discourse/app/jobs/regular/create_backup.rb:10:in `execute'
/var/www/discourse/app/jobs/base.rb:297:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-5.0.0/lib/rails_multisite/connection_management.rb:82:in `with_connection'
/var/www/discourse/app/jobs/base.rb:284:in `block in perform'
/var/www/discourse/app/jobs/base.rb:280:in `each'
/var/www/discourse/app/jobs/base.rb:280:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
[2024-02-14 04:25:38] Deletando backups antigos...
[2024-02-14 04:25:38] Limpando coisas...
[2024-02-14 04:25:38] Removendo sobras de '.tar'...
[2024-02-14 04:25:39] Marcando backup como concluído...
[2024-02-14 04:25:39] Notificando 'system' sobre o fim do backup...

Mas então o que acontece é que recebo uma série de backups parcialmente(?) completos sobre os quais não sou notificado, pelo que sei. Eles se acumulam até o ponto em que uma nova tentativa de backup é feita todos os dias e derruba meu site ao mesmo tempo.

Tenho que fazer SSH manualmente e removê-los porque eles não aparecem na página /admin/backups.

Sei que é difícil replicar esse problema e, portanto, difícil de corrigir, mas eu estava me perguntando se há algo óbvio que estou fazendo de errado ou se outros enfrentam o mesmo problema?

[Ed_S]

Primeira coisa a tentar, após remover as partes que não são arquivos de backup compactados, é reduzir o número máximo de backups para 2.

Acho que, em qualquer caso, é melhor ter alguma forma de buscar esses backups em outro lugar - sua casa, por exemplo. Se você tivesse um problema com seu provedor e eles excluíssem sua conta, você ficaria sem nada. Da mesma forma, se sua conta fosse comprometida, e talvez também se eles tivessem um incêndio.

Uma vez que você tenha alguma forma - talvez manual, talvez automática - de obter cópias externas, você estará muito perto de ter uma forma de verificar e excluir fragmentos.

Já sugeri antes que o painel de controle deve alertar se os arquivos de backup não foram lidos por vários dias desde sua criação. Essa é uma verificação relativamente fácil e, na minha opinião, um bom indicador para verificar se há uma cópia externa.

Você também pode optar por colocar seus backups em armazenamento de blocos, e você poderia fazer isso usando um provedor diferente. Assim, seria menos provável que você perdesse tanto sua instalação quanto seus backups.

Acho que há um trabalho pendente há muito tempo que não exigiria ter tanto o backup quanto brevemente o arquivo de backup compactado, mas não vale a pena esperar por isso. Enquanto isso, você precisa de espaço para os N backups que está retendo, mais 1 para o backup que está sendo feito em forma não compactada, mais 1 para o backup compactado que você precisa brevemente antes que o mais antigo dos N seja excluído.

Você precisa de espaço em disco para N+2 backups e, se um backup falhar, você precisa excluir as partes.

[pfaffman (Jay Pfaffman)]

@piffy

/var/www/discourse/tmp/

Você precisa ver que também colocou esse diretório na sua partição de 300 GB. É essa que está enchendo o disco.

Você também pode considerar mover os uploads para essa partição.

[piffy]

Você sabe de cor como fazer isso? Existe uma configuração yml ou algo que eu precise mudar?

Também configurei para ter uma tela offline estática durante a reconstrução, então não sei se isso complica as coisas.

[pfaffman (Jay Pfaffman)]

Algo como

volumes:
  - volume:
      host: /sua/grande/partição/tmp
      guest: /var/www/discourse/tmp

Presumivelmente, você já está fazendo algo assim para colocar os backups na partição grande?

@piffy

Eu também configurei para ter uma tela offline estática ao reconstruir, então não sei se isso complica as coisas

Complica. Provavelmente não é o problema, a menos que o problema seja que ele continua mostrando a página offline estática, mesmo que o Discourse esteja ativo.

[piffy]

Descobri depois de criar este tópico que é necessário executar um comando no console ao expandir o volume do DigitalOcean. Portanto, efetivamente, eu não estava usando todos os meus 300 GB.

Corrigi isso e não mudei mais nada, e o problema ocorreu novamente hoje. Havia 2 arquivos tar descompactados e 3 compactados com gzip quando meu site saiu do ar.

Tentarei a estratégia discutida acima a seguir.

Mas o que eu queria dizer é que seria bom ter um indicador na interface do administrador de que existem backups com falha. Ou talvez limpar qualquer *.tar ao acionar um novo processo de backup? Neste caso, eu tinha 90 GB de backups descompactados que não podem ser vistos na interface do administrador. E também nenhuma DM de “backup falhou” de nenhum dos dois.

[gerhard (Gerhard Schlager)]

Como está o uso de memória no seu droplet? O processo de backup deve executar rotinas de limpeza e enviar uma notificação aos administradores quando falhar. Isso não acontecerá se o processo for encerrado pelo out-of-memory killer.

[pfaffman (Jay Pfaffman)]

@gerhard

Isso não acontecerá se o processo for encerrado pelo “out-of-memory killer”.

Talvez seja isso que está acontecendo! Já vi esse cenário de “backups interrompidos deixam backups parciais que preenchem o disco” em alguns sites. Minha melhor explicação tem sido uma reinicialização do sistema operacional no meio de um backup, mas já vi isso acontecer sem reinicializações do sistema operacional.

Ter o processo de backup sendo encerrado por falta de memória parece uma explicação provável que é suficientemente difícil de replicar para explicar isso.

. . . .

Ah. Droga. Um site que me lembro de ter tido esse problema tem 16GB de RAM, então não acho que isso explique. Nesse site, o problema é que toda semana ou mais um backup é deixado no disco local depois de ser (ou talvez não seja) enviado para o S3. Eles também têm mais de 100GB de espaço livre em disco, então leva meses para o problema se tornar grande o suficiente para que o disco fique cheio.

Aqui está o conjunto de arquivos que acabei de excluir:

forum-2024-03-11-123904-v20240202052058.tar.gz
forum-2024-03-09-123159-v20240202052058.tar.gz                           
forum-2024-03-07-123727-v20240202052058.tar.gz                           
forum-2024-03-05-123019-v20240202052058.tar.gz
forum-2024-03-03-123934-v20240202052058.tar.gz  

[Firepup650 (Firepup Sixfifty)]

+1 para isso, o fórum que ajudo a gerenciar aleatoriamente deixa backups no servidor em vez de enviá-los para o S3, e isso derrubou o fórum pelo menos uma vez.

[piffy]

Não sei se isso é útil, mas aqui estão as métricas do DO

7 dias

24h

Ampliar