Ho un sito che invia un backup di 20 GB a Wasabi S3. Funziona. Per lo più.
Ma a volte fallisce il caricamento su S3 e mantiene il file .tar.gz locale. E alla fine il disco si riempie, lasciandomi con un disco pieno, il file .tar non compresso (perché non c’era abbastanza spazio per la versione compressa) e, presto, un sito rotto perché il disco è pieno.
Prima di rinunciare a Wasabi, vorrei provare a vedere se ci sono degli indizi.
Ho controllato production.log, production.errors e i log di sidekiq e unicorn, ma non ho trovato “acku” da nessuna parte, né nel giorno in cui il backup è fallito né quando ha funzionato. Non dovrebbe esserci un log da qualche parte?
Dovresti ricevere un messaggio privato con l’output del log in caso di errore. Viene inviato direttamente a te se si tratta di un backup manuale dall’interfaccia utente, oppure al gruppo degli amministratori se si tratta di un backup automatico.
Un’eccezione durante il backup dovrebbe anche apparire in /logs e, credo, anche in uno dei file di log. Prova a cercare EXCEPTION:
Tuttavia, il fatto che vengano mantenuti i file temporanei mi fa chiedermi se Sidekiq, o addirittura Docker o l’host, vengano riavviati durante il backup. Questo spiegherebbe perché la pulizia non viene eseguita e perché non ricevi un messaggio privato.
Giusto. È molto strano. Non ho ricevuto alcun avviso di errore, nemmeno per quello in cui c’era solo un file .tar e il disco era quasi pieno (è un sito aggiornato su tests-passed).
È come se la backup location fosse stata cambiata in quei giorni, ma non c’è nulla nei log. Ricevo notifiche “riuscite” nei messaggi di amministrazione per i backup avviati dall’interfaccia web, ma nessun errore. Ho spostato backup_location in una variabile d’ambiente.