我试图在一台全新安装的 Discourse 实例上执行恢复操作，但在 CLI 中遇到了以下错误：
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 的可用空间，所以我觉得这不太可能是磁盘空间问题。您知道为什么会报这个错吗？
您知道解压后的大小吗？另外，这还没有计算索引，所以也许可以在磁盘空间更大的服务器上尝试？
你也可以检查一下磁盘分区。虽然服务器上确实有 198 GB 的可用空间，但服务器可能包含多个磁盘分区，这一点你应该知道。能否回复一下 df 命令的输出结果？
我认为数据库未压缩时大约为 40 GB。我在从另一个论坛软件导入后对论坛进行了备份，因此我原以为恢复应该没问题。之前我的磁盘空间肯定充足。我可以再增加一些磁盘空间，但我实在没想到它需要超过数据库大小三倍的容量。
所有分区都在 / 下，所以我认为那里没有问题：
嘿 @Ghan
你是从命令行还是从“Docker Manager”界面开始恢复的？
两种方法都试过了，最近一次是在命令行界面。我会尝试增加磁盘空间，然后在导入过程中观察使用情况。
我添加了 50 GB，并且已成功完成。对于数据库而言，这确实占用了大量磁盘空间。
恢复过程是否会比导入操作添加额外的索引？
它用于存储你的论坛内容。我们有 1 GB 的 Discourse 实例，也有 500 GB 的 Discourse 实例，具体取决于活动量有多大：stuck_out_tongue:
在 PostgreSQL 13 更新 主题中有一个查询可以查看每个表的大小，也许你可以尝试运行它并将结果发布到这里？
我们知道内容很多。但看起来，仅仅因为执行了备份和还原操作，空间需求就急剧增加。备份前我们有超过 100 GB 的可用空间，因此我原以为执行还原不会有问题，但还原操作所需的空间比我预期的要多得多。看来只是差了一点点。
我尝试运行查询以显示数据库中前 20 个最大的对象，但该查询已经运行了大约一个小时，我完全不知道还需要多长时间才能完成。
请检查是否仍存在备份和还原的架构文件。当备份或还原发生灾难性失败（例如空间不足）时，这些文件可能会残留。我们有一个后台作业每周清理这些文件，但您可能需要立即手动运行。
访问 /sidekiq/scheduler，搜索 Jobs::DropBackupSchema，然后点击“触发”。
如果您拥有完整备份，那么您将拥有 3 份副本：完整备份本身、其中包含的数据库转储，以及恢复后的数据库，再加上初始存在的数据库。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
