Exécution de 3.2.0.beta4-dev ( 86da47f58d ) mais nous avons ce problème depuis un certain temps.
Nous avons configuré des sauvegardes pour aller directement sur S3. Naturellement, l’application les prend d’abord dans le stockage local, puis les télécharge sur S3, ce qui est normal. Le problème est qu’elle ne supprime pas chaque sauvegarde après le téléchargement, ce qui entraîne une utilisation massive de l’espace, même sans miniatures enregistrées dans les sauvegardes.
Cela pourrait-il être un problème de permissions sur le répertoire, éventuellement ? Je ne l’ai certainement pas modifié.
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
Ce qui est étrange, c’est que dans la liste des fichiers temporaires, nous voyons les 2, 3, 7, 8 et 9 janvier consommer de l’espace. Dans la liste des sauvegardes de Discourse dans l’interface d’administration, je ne vois que le 4 janvier. Donc, peut-être que Discourse prend ces sauvegardes mais ne les télécharge pas correctement sur S3 ? Le problème avec cette théorie est que la “fréquence de sauvegarde” est définie sur 3 dans la configuration d’administration, donc il ne devrait pas essayer de sauvegarder tous les jours de toute façon. Notez que les journaux de sauvegarde dans l’interface d’administration sont vides, aucun journal là-bas.
L’hôte a 90 jours de disponibilité et le conteneur Docker a 6 semaines de disponibilité, donc pas de redémarrages réels, sauf si vous parlez de quelque chose à l’intérieur de l’application.
Pas de sauvegardes manuelles de ma part, certainement pas une tous les jours. Rien dans cron non plus.
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
Ça continue, soupir. Je suppose que je vais utiliser cron pour find -mtime +2 -delete. Bons moments.
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
[quote=“Wingtip, post:3, topic:291033”]L’hôte a 90 jours de disponibilité et le conteneur Docker a 6 semaines de disponibilité, donc pas de redémarrages réels, à moins que vous ne parliez de quelque chose à l’intérieur de l’application.
[/quote]
Zut. C’était ma meilleure hypothèse.
[quote=“Wingtip, post:4, topic:291033”]Ça continue, soupir. Je suppose que je vais utiliser cron pour trouver -mtime +2 -delete. Bons moments.
[/quote]
