Discourse non pulisce i backup locali tmp dopo il caricamento su S3

Installazione
,
1

In esecuzione 3.2.0.beta4-dev ( 86da47f58d ) ma abbiamo questo problema da un po’ di tempo.

Abbiamo configurato i backup per andare direttamente su S3. Comprensibilmente, l’applicazione li porta prima nello storage locale e poi li carica su S3, il che va bene. Il problema è che non elimina ogni backup dopo averlo caricato, portando a un enorme utilizzo dello spazio anche senza miniature salvate all’interno dei backup.

root@forum:/var/discourse/shared/standalone/tmp/backups/default# du -sh
57G     .
root@forum:/var/discourse/shared/standalone/tmp/backups/default# du -k
7073520 ./2023-12-28-063845
8040176 ./2023-12-29-063923
8521220 ./2024-01-08-063857
4909616 ./2023-12-24-064434
4918056 ./2024-01-07-064325
7079136 ./2024-01-03-064430
7077984 ./2024-01-02-063855
2949660 ./2024-01-09-063708
59088404        .
root@forum:/var/discourse/shared/standalone/tmp/backups/default# rm -Rf *

Potrebbe trattarsi di un problema di permessi sulla directory, forse? Certamente non l’ho modificata.

root@forum:/var/discourse/shared/standalone/tmp/backups# ls -la
total 12
drwxr-xr-x 3 mas www-data 4096 Nov 23 06:44 .
drwxr-xr-x 4 mas www-data 4096 Nov 22 04:57 ..
drwxr-xr-x 2 mas www-data 4096 Jan  9 15:35 default

La cosa strana è che dall’elenco dei file temporanei, vediamo che i giorni 2, 3, 7, 8 e 9 gennaio consumano spazio. Dall’elenco dei backup di Discourse nell’interfaccia di amministrazione, vedo solo il 4 gennaio. Quindi forse Discourse sta effettuando quei backup ma non li sta caricando correttamente su S3? Il problema con questa teoria è che la “frequenza dei backup” è impostata su 3 nella configurazione di amministrazione, quindi non dovrebbe nemmeno tentare di eseguire il backup ogni giorno. Nota che i log dei backup nell’interfaccia di amministrazione sono vuoti, nessun log lì.

image
image819×108 5.76 KB

Untitled
Untitled1198×243 29.9 KB

2

La mia migliore spiegazione è che a volte il server si riavvia prima di poter eliminare il file di backup locale.

L’elenco dei backup mostra ciò che è su S3, non sul tuo disco locale.

Qualcuno sta eseguendo manualmente un backup?

3

L’host ha un uptime di 90 giorni e il container Docker ha un uptime di 6 settimane, quindi nessun riavvio effettivo, a meno che tu non stia parlando di qualcosa all’interno dell’applicazione.

Nessun backup manuale da parte mia, certamente non uno ogni singolo giorno. Niente in cron ecc. nemmeno.

root@forum:/# uptime
 17:20:56 up 90 days,  1:52,  4 users,  load average: 0.81, 1.71, 1.81
root@forum:/# docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED       STATUS       PORTS                                                                      NAMES
d8bc34250454   local_discourse/app   “/sbin/boot”   6 weeks ago   Up 6 weeks   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   app
1 Mi Piace
4

Succede ancora, sospiro. Suppongo che userò cron per find -mtime +2 -delete. Bei tempi.

root@forum:/var/discourse/shared/standalone/tmp/backups/default# du -sh
14G     .
root@forum:/var/discourse/shared/standalone/tmp/backups/default# ls -la
total 16
drwxr-xr-x 4 mas www-data 4096 Jan 16 06:56 .
drwxr-xr-x 3 mas www-data 4096 Nov 23 06:44 ..
drwxr-xr-x 2 mas www-data 4096 Jan 14 06:38 2024-01-14-063807
drwxr-xr-x 2 mas www-data 4096 Jan 15 06:43 2024-01-15-064337
1 Mi Piace
5

Dannazione. Era la mia migliore ipotesi.

Sì. Potrebbe essere quello che devi fare.

6

Fatto. Non la soluzione più elegante o soddisfacente, ma immagino che il problema sia risolto.

1 Mi Piace
7

Sì. Penso che farò così la prossima volta che avrò questo problema.

2 Mi Piace