Discourse не удаляет локальные резервные копии из tmp после загрузки в S3

Поддержка Самостоятельное хостинг
,
1

Запущена версия 3.2.0.beta4-dev ( 86da47f58d ), но эта проблема наблюдается уже некоторое время.

Мы настроили резервное копирование для прямой загрузки в S3. Понятно, что приложение сначала сохраняет файлы в локальное хранилище, а затем загружает их в S3, что нормально. Проблема в том, что после загрузки файлы резервных копий не удаляются, из-за чего расходуются огромные объемы дискового пространства, даже если внутри резервных копий не сохраняются миниатюры.

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 *

Может ли это быть проблемой прав доступа к каталогу? Я точно не менял их.

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

Странно то, что в списке временных файлов мы видим, что место занимают резервные копии от 2, 3, 7, 8 и 9 января. В списке резервных копий Discourse в административном интерфейсе я вижу только копию от 4 января. Возможно, Discourse создает эти резервные копии, но не загружает их корректно в S3? Проблема с этой теорией в том, что параметр «Частота резервного копирования» (backup frequency) в настройках администратора установлен на 3, поэтому система вообще не должна пытаться делать резервные копии каждый день. Обратите внимание: в административном интерфейсе журнал резервного копирования пуст, записей там нет.

image
image819×108 5.76 KB

Untitled
Untitled1198×243 29.9 KB

2

Мое лучшее предположение заключается в том, что иногда сервер перезагружается до того, как успевает удалить локальный файл резервной копии.

Список резервных копий показывает то, что находится на S3, а не на вашем локальном диске.

Некто ли запускает резервное копирование вручную?

3

Хост работает без перезагрузки уже 90 дней, а Docker-контейнер — 6 недель, так что никаких фактических перезагрузок не было, если только вы не имеете в виду что-то внутри самого приложения.

Я не делаю никаких ручных резервных копий, тем более не каждый день. В cron или других местах тоже ничего нет.

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
4

Всё ещё происходит, вздох. Ладно, я запущу cron-задачу с командой find -mtime +2 -delete. Хорошие времена.

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
5

Чёрт. Это было моё лучшее предположение.

Да. Возможно, это именно то, что нужно сделать.

6

Готово. Не самое элегантное или удовлетворительное решение, но, полагаю, проблема решена.

7

Да. Думаю, в следующий раз, когда у меня возникнет такая проблема, я поступлю именно так.