Discourse 上传到 S3 后未清理本地 tmp 备份

安装
,
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 日占用了空间。从管理员界面的 Discourse 备份列表中，我只看到 1 月 4 日。那么，Discourse 是否在备份但没有正确上传到 S3？这个理论的问题在于，“备份频率”在管理员配置中设置为 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
1 个赞
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
1 个赞
5

该死。那是我最好的猜测。

是的。那可能是要做的。

6

完成了。虽然不是最优雅或最令人满意的解决方案，但我猜问题解决了。

1 个赞
7

嗯，我想下次遇到这个问题的时候，我就会这么做。

2 个赞