我的备份一直在 /var/discourse/shared/standalone/backups/default 目录中堆积，尽管它们已经上传到 Amazon S3。
这是我的 Discourse 设置：
Discourse 备份：
S3 存储桶中的备份：
以及 /var/discourse/shared/standalone/backups/default 的内容：
这种情况已经持续了很长时间——我的日历里有每月删除这些残留文件的提醒。备份日志为空：“尚无日志…” 并且错误日志中也没有指向 Amazon S3 问题的条目。
Discourse 会定期更新，目前是 2.9.0.beta14。
这是标准安装，对吗？操作系统（或其他东西）有没有可能在上传过程中终止备份进程？因为即使备份失败，本地文件也应该在进程结束时被删除。
是的，在 DigitalOcean 虚拟机上进行了标准安装，使用的是 Ubuntu 16.04.7 LTS。相关的日志文件在哪里？
我曾使用过一个 S3 兼容服务，有时会导致备份保留在本地驱动器上，但这种情况是间歇性的。
你可以查看 /var/discourse/shared/standalone/logs/rails/production.log。它只是运行了一个命令行备份，看看是否有这种行为。
生产日志只保留一周，因此较旧的“未删除”备份会超出此范围，但我会留意将来的备份。日志中唯一的备份错误条目是 11/30 的日志中的这个：
Started GET “/.env.backup” for 3.236.147.46 at 2022-11-29 19:15:57 +0000
ActionController::RoutingError (No route matches [GET] “/.env.backup”)
我在 /var/discourse/shared/standalone/backups/default 中看到了一个新的未删除的备份，但 production.log 中没有任何内容。production_errors.log 中也没有。我还能去哪里查看？
附注：我从命令行运行了一个备份，备份已成功删除 - 我会再试几次，看看是否会在此处出现错误。
无法通过 CLI 成功重现未删除的本地备份，但它确实会每周发生一两次，就在夜间备份期间。我也没在 production.log 中看到任何备份日志输出。您确定它写在那里吗，@pfaffman？
我认为应该是的。当我遇到类似的“某个其他S3服务”问题时，我在Discourse或他们的服务中都找不到错误。然后我放弃了，换了别的东西。但你使用的是AWS，S3，真正的服务，所以我很惊讶。
我试着像这样查找：
grep -r "Output file is stored on S3" /var/discourse
因为这句话是 CLI 备份输出的最后一行，但什么也没找到。
服务器是否可能因为主机操作系统自动更新而重启？这些更新可能会在上传到 S3 过程中发生。你们的操作系统日志中有相关记录吗？也许可以将 backup_time_of_day 站点设置重置为默认值或另一个时间，看看问题是否会消失。
不，当前的正常运行时间为 36 天。我曾怀疑 DigitalOcean 实例的备份同时运行可能是原因，但这每周只发生一次，而我的未删除备份的发生频率比这更高。
我将尝试一个不同的 backup_time_of_day。它被设置为 2:00 UTC，所以我们来看看默认的 3:30 UTC 是否会有任何不同。
哦！这真是个好主意。这可以解释了。我敢打赌就是这样。而午夜是备份和重启的好时机。这并不能完全解释为什么当我切换到另一个服务时问题就消失了，但也许我的运气变好了，或者我切换到的服务更快了之类的。
哦。糟糕。
十六天后，这似乎是解决方案——不再有未删除的备份。我不知道是什么导致了冲突，但现在已经不重要了。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.