Questo succede da molto tempo: ho un promemoria mensile nel mio calendario per eliminare questi file residui. I log dei backup sono vuoti: “Nessun log ancora…” e nessun elemento nei log di errore indica problemi con Amazon S3.
Discourse viene aggiornato regolarmente ed è attualmente alla versione 2.9.0.beta14.
Questa è un’installazione standard, vero? C’è la possibilità che il sistema operativo (o qualcos’altro) stia interrompendo il processo di backup durante il caricamento? Perché anche in caso di errore di backup, il file locale dovrebbe essere eliminato alla fine del processo.
Ho utilizzato per un po’ un servizio compatibile con S3 che a volte lasciava i backup sul disco locale, ma era intermittente.
Dovresti controllare in /var/discourse/shared/standalone/logs/rails/production.log. Eseguiva semplicemente un backup da riga di comando e vedeva se aveva il comportamento desiderato.
I log di produzione risalgono solo a una settimana fa, quindi i backup più vecchi “non eliminati” escono da quell’intervallo, ma terrò d’occhio quelli futuri. L’unica voce di errore di backup è stata questa nel log del 30/11:
Started GET \"/.env.backup\" for 3.236.147.46 at 2022-11-29 19:15:57 +0000
ActionController::RoutingError (No route matches [GET] \"/.env.backup\")
Vedo un nuovo backup non eliminato in /var/discourse/shared/standalone/backups/default ma nulla in production.log. Nemmeno in production_errors.log. Dove altro potrei cercare?
P.S. Ho eseguito un backup dalla CLI e il backup è stato rimosso con successo - proverò ancora un paio di volte per vedere se riesco a ottenere un errore lì.
Non sto avendo successo nel riprodurre il backup locale non eliminato tramite CLI, ma continua a verificarsi una o due volte alla settimana durante il backup notturno. Inoltre, non vedo alcun output del log di backup in production.log. Sei sicuro che sia lì che viene scritto, @pfaffman?
Penso di sì. Quando ho avuto un problema simile con un altro servizio S3, non sono riuscito a trovare errori né in Discourse né nel loro servizio. Ho rinunciato e sono passato a qualcos’altro. Ma tu stai usando AWS, S3, la cosa vera, quindi sono piuttosto sorpreso.
Ho provato a cercare in questo modo: grep -r "Output file is stored on S3" /var/discourse
poiché quella frase è l’ultima riga dell’output del backup della CLI, ma non viene trovato nulla.
C’è la possibilità che il server si riavvii a causa degli aggiornamenti automatici del sistema operativo host? Potrebbero verificarsi durante il caricamento su S3. C’è qualcosa nei log del tuo sistema operativo? Forse reimpostare l’impostazione del sito backup_time_of_day al valore predefinito o a un’ora diversa e vedere se il problema scompare.
No, l’uptime attuale è di 36 giorni. Avevo sospettato che il backup del droplet DigitalOcean in esecuzione contemporaneamente potesse essere la causa, ma questo avviene una volta alla settimana e i miei backup non eliminati si verificano più frequentemente di così.
Proverò un backup_time_of_day diverso. Era impostato su 2:00 UTC, quindi vedremo se l’impostazione predefinita 3:30 UTC farà la differenza.
OOOOH! Questa è bella. Spiegherebbe tutto. Scommetto che è così. E la notte fonda è un buon momento sia per i backup che per i riavvii. Non spiega del tutto perché il problema sia scomparso quando sono passato a un servizio diverso, ma forse la mia fortuna è cambiata, o quello a cui sono passato era più veloce o qualcosa del genere.
Sedici giorni dopo, sembra che questa fosse la soluzione: niente più backup non eliminati. Non so cosa stesse causando il conflitto, ma ora non ha più importanza.
