# 磁盘空间已满，无法更新 Discourse 实例
**URL:** https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229
**Category:** Self-hosting
**Created:** [2026年七月10日 00:08 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229 "2026-07-10T00:08:01Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@azhdrake](https://meta.discourse.org/u/azhdrake)
#### Post date: [2026年七月10日 00:08 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/1 "2026-07-10T00:08:01Z")
你好，
我在一台拥有 25GB 空间的服务器上运行着一个小型 Discourse 实例。目前只剩下 3.4GB 的可用空间，我不确定原因。这导致我无法进行更新。
除了 Discourse 之外，该实例上没有运行其他服务，以前也没有过。
为了释放空间，我目前已经做了以下操作：
- 删除了所有能找到的日志，包括 Discourse 日志和 `/var/log/journal` 中的日志
- 删除了除一个之外的所有 Discourse 备份
- 清理了所有旧的 Docker 镜像
- 运行了 apt-get autoclean 和 apt-get autoremove
- 确保没有遗留旧内核
我曾考虑将 PostgreSQL 数据移动到外部驱动器，但目前它不到 1GB，所以我认为这样做帮助不大。
/dev/vda1 正在占用 20GB 的空间。
我还能做些什么吗？25GB 的磁盘空间现在是否已不足以运行 Discourse？
---
### Author:  [@darkpixlz](https://meta.discourse.org/u/darkpixlz)
#### Post date: [2026年七月10日 00:11 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/2 "2026-07-10T00:11:00Z")
这主要取决于你的上传文件，但如果你的站点非常大（听起来这似乎不是问题所在），备份和 PostgreSQL 数据库也会占用空间。你的上传文件有多大？管理面板底部应该会显示相关信息。
---
### Author:  [@azhdrake](https://meta.discourse.org/u/azhdrake)
#### Post date: [2026年七月10日 00:13 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/3 "2026-07-10T00:13:53Z")
它不到 50MB，这完全不是一个大型或老旧的实例。正如我提到的，我考虑过将其移出主驱动器，但我认为这不是这里的主要问题。
---
### Author:  [@darkpixlz](https://meta.discourse.org/u/darkpixlz)
#### Post date: [2026年七月10日 00:19 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/4 "2026-07-10T00:19:29Z")
~~如果您的上传文件约为 25MB，而 PostgreSQL 数据库约为 1GB，我怀疑 Discourse 正在创建您不需要的备份。请检查您的备份保留设置（管理员 \> 设置 \> 备份），查看当前的备份（管理员 \> 备份），并删除任何不需要的备份。~~
算了。要是我记得您之前已经清理过就好了。
您可以检查常见位置中占用空间的情况：
```sh
du -sh /shared/*
du -sh /var/www/discourse/*
du -sh /var/www/discourse/public/*
```
---
### Author:  [@azhdrake](https://meta.discourse.org/u/azhdrake)
#### Post date: [2026年七月10日 00:22 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/5 "2026-07-10T00:22:57Z")
我复制了仅存的备份并将其从磁盘上移除后，将其删除。我现在只剩下 3.5 GB 的空间。
---
### Author:  [@darkpixlz](https://meta.discourse.org/u/darkpixlz)
#### Post date: [2026年七月10日 00:23 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/6 "2026-07-10T00:23:55Z")
是的，抱歉，我刚刚更新了帖子，并附上了更新后的说明。
---
### Author:  [@azhdrake](https://meta.discourse.org/u/azhdrake)
#### Post date: [2026年七月10日 00:34 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/7 "2026-07-10T00:34:34Z")
此服务器没有 `/shared/` 目录。
以下是我从 `du -sh /var/discourse/*` 得到的结果，总共只有 658M：
```plaintext
4.0K /var/discourse/LICENSE
12K /var/discourse/README.md
4.0K /var/discourse/bin
4.0K /var/discourse/cids
8.0K /var/discourse/containers
12K /var/discourse/discourse-doctor
8.0K /var/discourse/discourse-setup
368K /var/discourse/image
8.0K /var/discourse/install-discourse
28K /var/discourse/launcher
32K /var/discourse/samples
8.0K /var/discourse/scripts
657M /var/discourse/shared
180K /var/discourse/templates
```
文件系统中占用空间最大的是 `/var/lib/containerd/io.containerd.content.v1.content`，占用 2.4 GB，以及 `/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs`，占用惊人的 12 GB
---
### Author:  [@darkpixlz](https://meta.discourse.org/u/darkpixlz)
#### Post date: [2026年七月10日 00:44 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/8 "2026-07-10T00:44:28Z")
抱歉，忘了提你需要在容器内操作。你提到的那个文件来自 Docker。你可以用 `docker system df` 查看它被什么占用，如果有需要，可以用 `docker system prune` 进行全局清理，但请确保操作时 Discourse 正在运行。
---
### Author:  [@azhdrake](https://meta.discourse.org/u/azhdrake)
#### Post date: [2026年七月10日 01:02 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/9 "2026-07-10T01:02:52Z")
啊，这就说得通了。
在容器中，唯一超过 1GB 的文件是 `/var/www/discourse/vendor/bundle/ruby/`，大小为 2.1GB。
我补充一下：如果我在更新拉取之前清理镜像，空间就足够了；但当我尝试更新并再次拉取时，空间又不够了。所以新镜像几乎占用了 5GB 的空间。
---
### Author:  [@darkpixlz](https://meta.discourse.org/u/darkpixlz)
#### Post date: [2026年七月10日 02:11 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/10 "2026-07-10T02:11:55Z")
你能展示一下那个 Docker 命令的输出吗？那个目录包含了所有的 Ruby gems，这个大小在我看来并不令人担忧。
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [2026年七月10日 07:48 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/11 "2026-07-10T07:48:25Z")
确实，请展示所有输出。我不建议你在容器内部四处查看——你的问题出在系统层面，应该从那里开始排查。不要只盯着你认为可能存在问题的地方，而要纵观全局。
首先，重启系统。你需要一个干净的文件系统和一个全新的系统状态。
接下来，参考这个之前的帖子以获取详细建议：
> [@Ed\_S](#):
>
> 请发布发生情况的详细信息
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2026年七月10日 15:12 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/12 "2026-07-10T15:12:41Z")
你是否运行过
./launcher cleanup
或者以其他方式清理过 Docker？
除非是最小的论坛，否则 25GB 的空间很难够用。
---
### Author:  [@Andrew\_Rowe](https://meta.discourse.org/u/Andrew_Rowe)
#### Post date: [2026年七月10日 17:04 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/13 "2026-07-10T17:04:37Z")
> [@pfaffman](#):
>
> 除非是最小的论坛，否则 25GB 的存储空间很难够用
我的论坛是个小型论坛（基本上只有我一个人用），我使用一台 40GB 的 VPS 以确保安全，避免因为更新导致令人头疼的问题。
这是我拥有的三台 VPS 中唯一一台不使用 20GB 存储的。另外两台分别是带有 MySQL 和 PHP 后端的 HTTP 服务器，以及一台 RTMP 服务器。运行 Discourse 的那台同时也运行了 docker-mailserver，但我关闭了邮件摘要功能，因此 DMS 占用的资源非常少。
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2026年七月11日 04:05 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/14 "2026-07-11T04:05:24Z")
> [@pfaffman](#):
>
> 你有没有运行过
>
> ./launcher cleanup
>
> 或者以其他方式清理过 Docker？
这很可能能解决你的问题。
---
### Author:  [@Steven](https://meta.discourse.org/u/Steven)
#### Post date: [2026年七月11日 09:29 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/15 "2026-07-11T09:29:15Z")
为了腾出一点空间，我使用这些命令，这有助于重建过程
```plaintext
sudo apt -y autoremove && apt -y autoclean
sudo apt clean
sudo journalctl --vacuum-time=1s
```
1 和 2 清理 Ubuntu
3 清理一些日志，通常能清理出大约 3GB 的空间
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [2026年七月11日 11:09 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/16 "2026-07-11T11:09:15Z")
这在原帖中已经提到，但显然最好运行 Discourse 命令
> [@azhdrake](#):
>
> - 清理了所有旧的 Docker 镜像
---
### Author:  [@azhdrake](https://meta.discourse.org/u/azhdrake)
#### Post date: [2026年七月11日 17:16 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/17 "2026-07-11T17:16:51Z")
感谢大家的回复！抱歉之前消失了，生活中突发了一些事情，昨天我没有时间继续排查问题。
简而言之，我注意到关于这个确切问题的讨论帖非常多，因此我认为即使这次解决了，以后可能还会再遇到，所以我将我的实例迁移到了一个稍大一些的服务器上，该服务器有 35GB 的可用空间。
对于任何正在寻找解决此确切问题帮助且不想升级服务器的人：
我之前已经尝试过 `./launcher cleanup`，但它释放的空间不够。我也已经执行过
```plaintext
sudo apt -y autoremove && apt -y autoclean
sudo apt clean
sudo journalctl --vacuum-time=1s
```
但同样，这还不够。`journalctl` 中有大量的日志（对于一台 25GB 的机器来说），所以请务必检查这是否也适用于你的情况，但对我而言，这并没有提供足够的帮助。
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2026年七月13日 07:01 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/18 "2026-07-13T07:01:58Z")
> [@azhdrake](#):
>
> journalctl 里的日志非常多（对于一台 25GB 的机器来说）
没错！那会占用大量空间。我的仪表盘脚本会在空间不足时清理这些日志。我差点忘了这回事（我想是因为它是脚本自动执行的，所以使用我仪表盘的用户不会遇到问题）。
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [2026年七月13日 10:23 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/19 "2026-07-13T10:23:37Z")
> [@azhdrake](#):
>
> 于是我将实例迁移到了一台稍大一些的服务器，该服务器拥有 35GB 的存储空间。
值得一提的是，部分服务商支持直接扩容磁盘空间（例如 Scaleway 就支持）。
另一个值得尝试的方法是简单重启 VPS——有时这可以释放空间，尽管它可能已经执行了你之前做过的一些清理操作。
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [2026年七月14日 05:54 UTC](https://meta.discourse.org/t/disk-space-too-full-to-update-discourse-instance/407229/20 "2026-07-14T05:54:27Z")
> [@azhdrake](#):
>
> 简而言之，我注意到关于这个确切问题的帖子有多少，并认为即使这次解决了，问题还会再次出现，所以我将我的实例迁移到了一个稍大一点的服务器上，该服务器有 35GB 的空间。
你说得对：如果你能花更多的钱来放宽资源限制，那可以节省你的时间和精力。
不过，我认为这次我们错过了以另一种方式处理这个问题的机会：通过运行显示正在发生什么的命令，在这里分享输出，并分析情况。
这是可能的，而且作为一个主要功能，它应该是可能的，在一个小型系统上运行一个中等规模的论坛。