I backup continuano a mettere offline il mio forum

[piffy]

Ho cicli in cui la creazione del backup sta mettendo offline il mio sito a causa di problemi di spazio.

L’ho configurato in modo da utilizzare un volume DO separato per archiviare i backup e gli upload. Il volume è di 300 GB.

Le mie impostazioni di backup:

Il problema si ripresenta da mesi. Ricevo messaggi nella casella di posta dell’amministratore riguardo al fallimento del backup (vedi sotto).

Nessuno spazio rimasto sul dispositivo

[2024-02-14 03:43:34] Finalizzazione del backup...
[2024-02-14 03:43:34] Creazione dell'archivio: elite-fourum-2024-02-14-033845-v20240204204532.tar.gz
[2024-02-14 03:43:34] Assicurarsi che l'archivio non esista già...
[2024-02-14 03:43:34] Creazione di un archivio vuoto...
[2024-02-14 03:43:34] Archiviazione del dump dei dati...
[2024-02-14 03:43:58] Archiviazione degli upload...
[2024-02-14 03:55:03] Rimozione della directory temporanea '/var/www/discourse/tmp/backups/default/2024-02-14-033845'...
[2024-02-14 03:55:03] Gzipping dell'archivio, questo potrebbe richiedere del tempo...
[2024-02-14 04:25:38] ECCEZIONE: /var/www/discourse/lib/discourse.rb:138:in `exec': Impossibile comprimere l'archivio.

gzip: /var/www/discourse/public/backups/default/elite-fourum-2024-02-14-033845-v20240204204532.tar.gz: Nessuno spazio rimasto sul 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] Eliminazione dei vecchi backup...
[2024-02-14 04:25:38] Pulizia...
[2024-02-14 04:25:38] Rimozione dei residui '.tar'...
[2024-02-14 04:25:39] Segnalazione del completamento del backup...
[2024-02-14 04:25:39] Notifica a 'system' della fine del backup...

Ma poi succede che ricevo una serie di backup parziali(?) che non mi vengono notificati, per quanto ne so. Si accumulano fino al punto in cui viene tentato di creare un nuovo backup ogni giorno e questo mette offline il mio sito contemporaneamente.

Devo accedere manualmente tramite ssh e rimuoverli perché non compaiono nella pagina /admin/backups.

So che è difficile replicare questo problema e quindi difficile da risolvere, ma mi chiedevo se ci fosse qualcosa di ovvio che sto facendo di sbagliato o se altri affrontano lo stesso problema?

[Ed_S]

La prima cosa da provare, dopo aver rimosso i file che non sono file di backup compressi, è ridurre il numero massimo di backup a 2.

Penso che in ogni caso sia meglio avere un modo per recuperare questi backup altrove, ad esempio a casa tua. Se avessi un problema con il tuo hoster e ti cancellassero l’account, ti ritroveresti senza nulla. Allo stesso modo se il tuo account fosse compromesso, e forse anche se avessero un incendio.

Una volta che avrai un modo, magari manuale, magari automatico, per ottenere copie offsite, sarai molto vicino ad avere un modo per controllare ed eliminare i frammenti.

Ho già suggerito che la dashboard dovrebbe avvisare se i file di backup non vengono letti per diversi giorni dalla loro creazione. È un controllo relativamente facile e, a mio parere, un buon proxy per verificare la presenza di una copia offsite.

Puoi anche scegliere di mettere i tuoi backup nello storage a blocchi, e potresti farlo utilizzando un provider diverso. In questo modo, avresti meno probabilità di perdere sia la tua installazione che i tuoi backup.

Penso che ci sia un lavoro in sospeso da fare che non richiederebbe sia il backup che, brevemente, il file di backup compresso, ma non vale la pena aspettarlo. Nel frattempo, hai bisogno di spazio per gli N backup che stai conservando, più 1 per il backup in fase di creazione in forma non compressa, più 1 per il backup compresso di cui hai bisogno brevemente prima che venga eliminato il più vecchio degli N.

Hai bisogno di spazio su disco per N+2 backup e, se un backup fallisce, devi eliminare i frammenti.

[pfaffman (Jay Pfaffman)]

@piffy

/var/www/discourse/tmp/

Devi assicurarti di inserire anche quella directory nella tua partizione da 300 GB. È quella che sta riempiendo il disco.

Potresti anche prendere in considerazione lo spostamento dei caricamenti su quella partizione.

[piffy]

Sai già a memoria come fare? C’è un’impostazione yml o qualcos’altro che devo cambiare?

Ho anche impostato una schermata statica offline durante la ricostruzione, quindi non so se ciò complichi le cose.

[pfaffman (Jay Pfaffman)]

Qualcosa del tipo

volumes:
  - volume:
      host: /your/big/partition/tmp
      guest: /var/www/discourse/tmp

Presumibilmente stai già facendo qualcosa di simile per mettere i backup sulla partizione grande?

@piffy

Ho anche impostato una schermata statica offline durante la ricostruzione, quindi non so se ciò complichi le cose

Lo fa. Probabilmente non è il problema, a meno che il problema non sia che continua a mostrare la pagina statica offline anche se Discourse è attivo.

[piffy]

Ho scoperto dopo aver creato questo argomento che è necessario eseguire un comando sulla console quando si espande il volume DigitalOcean. Quindi, in effetti, non stavo utilizzando tutti i miei 300 GB.

Ho risolto il problema e non ho cambiato nient’altro, e il problema si è ripresentato oggi. C’erano 2 file tar non compressi e 3 file gzip compressi quando il mio sito è andato offline.

Proverò la strategia discussa sopra la prossima volta.

Ma quello che volevo dire è che sarebbe bello avere un indicatore sull’interfaccia utente di amministrazione che ci sono backup falliti. O forse eliminare qualsiasi *.tar quando si attiva un nuovo processo di backup? In questo caso, avevo 90 GB di backup non compressi che non possono essere visti dall’interfaccia utente di amministrazione. E anche nessuna notifica DM di “backup fallito” da nessuno dei due.

[gerhard (Gerhard Schlager)]

Come sta l’utilizzo della memoria sul tuo droplet? Il processo di backup dovrebbe eseguire routine di pulizia e inviare una notifica agli amministratori in caso di errore. Ciò non accadrà se il processo viene terminato dall’out-of-memory killer.

[pfaffman (Jay Pfaffman)]

@gerhard

Ciò non accadrà se il processo viene terminato dall’out-of-memory killer.

Forse è quello che sta succedendo! Ho visto questo scenario “backup interrotti lasciano backup parziali che riempiono il disco” su alcuni siti. La mia migliore spiegazione è stata un riavvio del sistema operativo nel mezzo di un backup, ma l’ho visto anche senza riavvii del sistema operativo.

Avere il processo di backup terminato dall’out-of-memory sembra una spiegazione probabile che è sufficientemente difficile da replicare da poter spiegare questo.

. . . .

Oh. Accidenti. Un sito che ricordo avesse questo problema ha 16 GB di RAM, quindi non penso che questo lo spieghi. Su quel sito il problema è che ogni settimana circa un backup viene lasciato sul disco locale dopo che è stato (o forse non è stato) inviato a S3. Hanno anche oltre 100 GB di spazio libero sul disco, quindi ci vogliono mesi perché il problema diventi abbastanza grande da riempire il disco.

Ecco l’insieme di file che ho appena cancellato:

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 a quello, il forum che aiuto a gestire ha backup lasciati casualmente sul server invece di essere inviati a S3, e ha messo offline il forum almeno una volta.

[piffy]

Non sono sicuro se questo sia utile, ma ecco le metriche da DO

7 giorni

24 ore

Ingrandisci