# 恢复失败 - 检查磁盘可用空间

**URL:** <https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783>\
**Category:** Self-hosting\
**Tags:** server-resources\
**Created:** [2020年十二月19日 04:25 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783 "2020-12-19T04:25:57Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ghan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ghan/32/177964_2.png) [@Ghan](https://meta.discourse.org/u/Ghan)\
**Post date:** [2020年十二月19日 04:25 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/1 "2020-12-19T04:25:57Z")

</div>

我试图在一台全新安装的 Discourse 实例上执行恢复操作，但在 CLI 中遇到了以下错误：

```plaintext
ERROR: could not extend file "base/16384/17011337": wrote only 4096 of 8192 bytes at block 15860
HINT: Check free disk space.
EXCEPTION: psql failed: HINT: Check free disk space.

```

我尝试恢复的备份文件大小为 22 GB（已压缩为 gz 格式），而服务器上还有 198 GB 的可用空间，所以我觉得这不太可能是磁盘空间问题。您知道为什么会报这个错吗？

---

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [2020年十二月19日 05:08 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/2 "2020-12-19T05:08:32Z")

</div>

您知道解压后的大小吗？另外，这还没有计算索引，所以也许可以在磁盘空间更大的服务器上尝试？

---

<div class="post-metadata">

**Author:** ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)\
**Post date:** [2020年十二月19日 05:17 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/3 "2020-12-19T05:17:10Z")

</div>

> [@Ghan](#):
>
> 我尝试恢复的备份文件是 22 GB（压缩的 gz 格式），而服务器上有 198 GB 的可用空间，所以我觉得这不太可能是磁盘空间问题。你知道为什么会报这个错吗？

你也可以检查一下磁盘分区。虽然服务器上确实有 198 GB 的可用空间，但服务器可能包含多个磁盘分区，这一点你应该知道。能否回复一下 `df` 命令的输出结果？

---

<div class="post-metadata">

**Author:** ![Ghan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ghan/32/177964_2.png) [@Ghan](https://meta.discourse.org/u/Ghan)\
**Post date:** [2020年十二月19日 05:45 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/4 "2020-12-19T05:45:42Z")

</div>

我认为数据库未压缩时大约为 40 GB。我在从另一个论坛软件导入后对论坛进行了备份，因此我原以为恢复应该没问题。之前我的磁盘空间肯定充足。我可以再增加一些磁盘空间，但我实在没想到它需要超过数据库大小三倍的容量。

所有分区都在 / 下，所以我认为那里没有问题：

 ![](https://global.discourse-cdn.com/meta/original/3X/3/3/33a1a3a49ac84250d6a7bbe0b7eda42fe250a9f3.png)

---

<div class="post-metadata">

**Author:** ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)\
**Post date:** [2020年十二月19日 13:08 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/5 "2020-12-19T13:08:32Z")

</div>

> [@Ghan](#):
>
> 所有内容都分区在 / 上，所以我认为那里没有问题：

嘿 @Ghan

你是从命令行还是从“Docker Manager”界面开始恢复的？

---

<div class="post-metadata">

**Author:** ![Ghan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ghan/32/177964_2.png) [@Ghan](https://meta.discourse.org/u/Ghan)\
**Post date:** [2020年十二月19日 16:15 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/6 "2020-12-19T16:15:14Z")

</div>

两种方法都试过了，最近一次是在命令行界面。我会尝试增加磁盘空间，然后在导入过程中观察使用情况。

---

<div class="post-metadata">

**Author:** ![Ghan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ghan/32/177964_2.png) [@Ghan](https://meta.discourse.org/u/Ghan)\
**Post date:** [2020年十二月19日 22:40 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/7 "2020-12-19T22:40:34Z")

</div>

我添加了 50 GB，并且已成功完成。对于数据库而言，这确实占用了大量磁盘空间。

恢复过程是否会比导入操作添加额外的索引？

---

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [2020年十二月19日 22:59 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/8 "2020-12-19T22:59:58Z")

</div>

> [@Ghan](#):
>
> 我增加了 50 GB，并且成功完成了。对于数据库来说，这确实占用了很多磁盘空间。

它用于存储你的论坛内容。我们有 1 GB 的 Discourse 实例，也有 500 GB 的 Discourse 实例，具体取决于活动量有多大：stuck\_out\_tongue:

在 [PostgreSQL 13 更新](https://meta.discourse.org/t/postgresql-13-update/172563) 主题中有一个查询可以查看每个表的大小，也许你可以尝试运行它并将结果发布到这里？

---

<div class="post-metadata">

**Author:** ![Ghan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ghan/32/177964_2.png) [@Ghan](https://meta.discourse.org/u/Ghan)\
**Post date:** [2020年十二月20日 00:13 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/9 "2020-12-20T00:13:45Z")

</div>

我们知道内容很多。但看起来，仅仅因为执行了备份和还原操作，空间需求就急剧增加。备份前我们有超过 100 GB 的可用空间，因此我原以为执行还原不会有问题，但还原操作所需的空间比我预期的要多得多。看来只是差了一点点。

我尝试运行查询以显示数据库中前 20 个最大的对象，但该查询已经运行了大约一个小时，我完全不知道还需要多长时间才能完成。

---

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [2020年十二月20日 03:29 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/10 "2020-12-20T03:29:28Z")

</div>

> [@Ghan](#):
>
> 但看起来仅执行备份和还原操作就导致空间需求激增。

请检查是否仍存在备份和还原的架构文件。当备份或还原发生灾难性失败（例如空间不足）时，这些文件可能会残留。我们有一个后台作业每周清理这些文件，但您可能需要立即手动运行。

访问 `/sidekiq/scheduler`，搜索 `Jobs::DropBackupSchema`，然后点击“触发”。

---

<div class="post-metadata">

**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\
**Post date:** [2020年十二月20日 04:11 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/11 "2020-12-20T04:11:50Z")

</div>

如果您拥有完整备份，那么您将拥有 3 份副本：完整备份本身、其中包含的数据库转储，以及恢复后的数据库，再加上初始存在的数据库。

---

<div class="post-metadata">

**Author:** ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)\
**Post date:** [2021年一月19日 04:12 UTC](https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783/12 "2021-01-19T04:12:01Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
