备份一直在导致我的论坛崩溃

[piffy]

我一直在经历备份创建因空间不足而导致网站瘫痪的周期。

我已经设置好，使用单独的 DO 卷来存储备份和上传。该卷为 300GB。

我的备份设置：

这个问题已经持续数月了。我会在管理员收件箱中收到关于备份失败的消息（见下文）。

设备上没有剩余空间

[2024-02-14 03:43:34] 正在完成备份...
[2024-02-14 03:43:34] 创建存档：elite-fourum-2024-02-14-033845-v20240204204532.tar.gz
[2024-02-14 03:43:34] 确保存档尚不存在...
[2024-02-14 03:43:34] 创建空存档...
[2024-02-14 03:43:34] 正在归档数据转储...
[2024-02-14 03:43:58] 正在归档上传...
[2024-02-14 03:55:03] 正在删除临时目录 '/var/www/discourse/tmp/backups/default/2024-02-14-033845'...
[2024-02-14 03:55:03] 正在压缩存档，这可能需要一段时间...
[2024-02-14 04:25:38] EXCEPTION: /var/www/discourse/lib/discourse.rb:138:in `exec': Failed to gzip archive.

gzip: /var/www/discourse/public/backups/default/elite-fourum-2024-02-14-033845-v20240204204532.tar.gz: 设备上没有剩余空间

[2024-02-14 04:25:38] /var/www/discourse/lib/discourse.rb:172:in `execute_command'
/var/www/discourse/lib/discourse.rb:138:in `exec'
/var/www/discourse/lib/discourse.rb:34:in `execute_command'
/var/www/discourse/lib/backup_restore/backuper.rb:253:in `create_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:40:in `run'
/var/www/discourse/lib/backup_restore.rb:13:in `backup!'
/var/www/discourse/app/jobs/regular/create_backup.rb:10:in `execute'
/var/www/discourse/app/jobs/base.rb:297:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-5.0.0/lib/rails_multisite/connection_management.rb:82:in `with_connection'
/var/www/discourse/app/jobs/base.rb:284:in `block in perform'
/var/www/discourse/app/jobs/base.rb:280:in `each'
/var/www/discourse/app/jobs/base.rb:280:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
[2024-02-14 04:25:38] 正在删除旧备份...
[2024-02-14 04:25:38] 正在清理...
[2024-02-14 04:25:38] 正在删除 '.tar' 剩余文件...
[2024-02-14 04:25:39] 正在将备份标记为完成...
[2024-02-14 04:25:39] 正在通知 'system' 备份结束...

但随后会发生的是，我收到一系列不完整的备份，据我所知我没有收到通知。它们会累积，直到每天尝试创建一个新备份，同时导致我的网站瘫痪。

我必须手动 SSH 登录并删除它们，因为它们没有显示在 /admin/backups 页面上。

我知道这个问题很难复制，因此很难修复，但我想知道我是否有什么明显做错的地方，或者其他人是否也面临同样的问题？

[Ed_S]

在尝试了删除非压缩备份文件的部分之后，首先要尝试的是将最大备份数减少到 2。

我认为，无论如何，最好有一种方法可以将这些备份获取到其他地方——例如您的家中。如果您的主机出现问题并且他们删除了您的帐户，您将一无所有。同样，如果您的帐户被盗用，甚至可能发生火灾。

一旦您有了某种方法——可能是手动，也可能是自动——来获取异地副本，您就非常接近于能够检查和删除碎片了。

我以前曾建议过，仪表板应该在备份文件创建后几天内未被读取时发出警告。这是一个相对容易的检查，在我看来，这是检查异地副本的一个很好的代理。

您还可以选择将备份放入块存储中，并且可以使用不同的提供商来执行此操作。这样，您丢失安装和备份的可能性就会降低。

我认为有一些长期待办的工作要做，这些工作不需要同时拥有备份和短暂的压缩备份文件，但它不值得等待。在此期间，您需要为正在保留的 N 个备份腾出空间，再加上 1 个用于以未压缩形式创建的备份，再加上 1 个用于在 N 中最早的备份被删除之前短暂需要的压缩备份。

您需要 N+2 个备份的磁盘空间，如果备份失败，您需要删除这些部分。

[pfaffman (Jay Pfaffman)]

@piffy

/var/www/discourse/tmp/

您还需要将该目录放在 300GB 分区上。那个分区正在填满磁盘。

您也可以考虑将上传移动到该分区。

[piffy]

您能马上告诉我怎么做吗？有没有一个 yml 设置或者我需要更改的其他东西？

我还将其设置为在重建时显示静态离线屏幕，所以我不知道这是否会使事情复杂化。

[pfaffman (Jay Pfaffman)]

类似这样

volumes:
  - volume:
      host: /your/big/partition/tmp
      guest: /var/www/discourse/tmp

你可能已经在做类似的事情，以便将备份放到大分区上？

@piffy

我还将其设置为在重建时显示静态离线屏幕，所以我不知道这是否会使事情复杂化

是的，这会。这可能不是问题所在，除非问题在于尽管 Discourse 已经启动，但它仍然显示静态离线页面。

[piffy]

我发现，在我创建这个主题后，当我扩展我的 DigitalOcean 卷时，需要在控制台上运行一个命令。所以实际上我并没有使用我全部的 300GB。

我修复了这个问题，没有做任何其他更改，今天问题又出现了。当我的网站宕机时，有 2 个未解压的 tar 文件和 3 个 gzip 压缩的文件。

我将尝试上面讨论的策略。

但我想说的是，在管理界面上有一个指示器表明备份失败了会很好。或者在触发新的备份过程时清除任何 *.tar 文件？在这种情况下，我有 90GB 的未解压备份，这些备份无法从管理界面看到。而且也没有收到任何“备份失败”的私信。

[gerhard (Gerhard Schlager)]

您的 droplet 上的内存使用情况如何？备份过程应该运行清理例程，并在失败时向管理员发送通知。如果进程被“内存不足”杀手终止，这种情况就不会发生。

[pfaffman (Jay Pfaffman)]

@gerhard

如果进程被内存不足的杀手终止，这种情况就不会发生。

也许这就是正在发生的事情！我见过这种“中断的备份会留下填满磁盘的部分备份”的情况在一些网站上发生。我最好的解释是在备份过程中操作系统重启，但我见过没有操作系统重启的情况……

备份进程被内存不足终止似乎是一个可能的原因，而且足够难以复制，可以解释这一点。

. . . .

哦。糟糕。我记得有一个有这个问题的网站有 16GB 的内存，所以我不认为这能解释它。在该网站上，问题在于每周左右都会有一个备份被留在本地磁盘上，尽管它已经被推送到 S3（或者可能没有）。他们还有 100GB 以上的可用磁盘空间，所以需要几个月的时间，问题才会变得足够大，以至于磁盘被填满。

这是我刚刚删除的文件集：

forum-2024-03-11-123904-v20240202052058.tar.gz
forum-2024-03-09-123159-v20240202052058.tar.gz                           
forum-2024-03-07-123727-v20240202052058.tar.gz                           
forum-2024-03-05-123019-v20240202052058.tar.gz
forum-2024-03-03-123934-v20240202052058.tar.gz  

[Firepup650 (Firepup Sixfifty)]

我也赞同，我帮忙运行的论坛有时会将备份留在服务器上，而不是推送到 S3，这至少导致论坛宕机过一次。

[piffy]

不确定这是否有帮助，但这是来自 DO 的指标

7 天

24 小时

放大