我学到了一些可能对他人有帮助的东西。
背景： 如其他地方所述，我的 Discourse 安装托管在一个 VPS 上，该 VPS 的磁盘空间不足以完成升级。起初，我点击了管理控制面板中的“升级”。升级失败，GUI 再也无法正常工作。之后，我登录到 VPS 的控制台并执行了著名的 ./launcher rebuild app 命令。该命令也从未成功完成：我的磁盘存储空间已严重不足。为了获得更多空间并控制预算，我决定将整个设置迁移到一个新的 VPS，并更换一家托管公司。保存宝贵的网站数据是重中之重。
失败： 两种最明显的备份方法都行不通：
- 我最初的升级尝试破坏了基于 Web 的 GUI，因此无法访问管理控制面板并从中启动备份；
- 尝试进入 Docker 容器并为其执行一些 shell 命令也无效。推荐的命令是
/var/discourse/launcher enter app。但是，至少在我的情况下，launcher 脚本会在允许我进入之前尝试重建应用程序，而重建一直失败，因此该命令甚至没有给我一个容器，更不用说其中的 shell 了。
成功： 我几乎要放弃了，但却收到了一个惊喜。在我的小型 VM 的命令行上工作时，我输入了 docker ps，发现有一个名为 app 的活动容器。Docker 有一种直接进入正在运行的容器的方法：命令是 docker exec -it app bash。
进入容器后，我得以继续操作：我发出了 discourse backup 命令，等待了几分钟，然后将 <backup>.tar.gz 文件复制到一个安全的新位置。有了最新的备份，就可以完成将我的设置迁移到新家园的工作了。（在这些论坛上还有其他帖子介绍了如何执行此操作。）
这里的关键点是，上述用于进入容器的 docker 命令有效，即使特定于 Discourse 的 ./launcher 命令无效。
感谢这个优秀产品的发明者和维护者。
3 个赞
感谢您的询问。
在我试图让原始设置正常工作的那些天里，我认为我已经尽了一切可能来收回空间，当然包括 ./launcher cleanup，但还有更多……卸载旧内核、清除 apt 缓存、放弃非必需软件等等。
在我决定迁移整个站点并投入大量时间进行此过程后，我想知道是否可以做得更多……但那时我已失去了进一步研究的动力。（参见“沉没成本谬误”。）具体来说，我即将放弃的 VPS 的标称磁盘大小为 25G。其中大约 19G 分配给了 /var/lib/docker/overlay2 目录。我运行的唯一 docker 容器是 Discourse 及其关联的 Mail-receiver。经验表明，尽管 Discourse 功能强大，但它应该能够在磁盘空间少于 19G 的情况下运行。但互联网搜索似乎表明，更改 overlay2 目录内部是不安全的，因此我在那个点上感到停滞了。
在我全新的设置中，/var/lib/docker/overlay2 目录占用了 13G。仍然很大。
我选择 Discourse 来运行我的小型爱好网站上的论坛，希望它能“正常工作”——也就是说，它将非常容易管理，而无需学习一堆新东西。这似乎在很大程度上是正确的，如果一个人拥有足够（过多？）的资源可以分配的话。
我的新计划是盲目地希望 overlay2 目录不会随着时间的推移而增长，并吞没我新 VPS 上的 50G 磁盘。如果您（或其他人）知道如何控制 docker 和 Discourse 动态组合的大小，我很想听听。这将是我最近几天所学到的其他知识的一个很好的总结。再次感谢。
Ed_S
(Ed S)
4
很高兴您能够自行解决问题。我运行着两个小型论坛，一个关于 20G 存储，另一个关于 25G。我确实需要花费大量时间和创造力来维持它们的运行。但我也似乎一直在使用（并发布关于）同一套策略。请参见下文。
Discourse 的开发优化目标并非在低成本硬件上运行——尽管它在我受限的环境中勉强能够继续运行。希望它能长久运行下去。
在小型存储环境中工作的关键在于衡量正在发生的事情——我经常看到人们猜测可能发生的事情。我的方法将始终从
更多信息，或许可以搜索我的帖子，关键词包括 prune 和 journalctl 以及 kernel。
2 个赞