S3へのアップロード後、Discourseがローカルの一時バックアップをクリーンアップしない

サポート インストール
,
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

奇妙なのは、tmpファイルの一覧では1月2日、3日、7日、8日、9日のものがスペースを消費しているのに、管理UIのDiscourseバックアップ一覧では1月4日のものしか表示されないことです。では、Discourseはこれらのバックアップを取得しているが、正しくS3にアップロードしていないのでしょうか？この理論の問題点は、「バックアップ頻度」が管理設定で3に設定されているため、毎日バックアップを試みるべきではないということです。管理UIのバックアップログは空で、ログはありません。

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

まだ発生しています、ため息。find -mtime +2 -delete を cron で実行するしかないようです。良い時代ですね。

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

はい。次回この問題が発生したときに、それが私がするであろうことだと思います。