2026 PostgreSQL 14 升级，pg_upgrade 磁盘要预留多少？

数据目录看起来不大，真正执行升级时才发现目标盘空间不够；或者选了省空间的方式，才发现旧集群不能直接作为回退方案。

结论｜适合按实际文件布局核算，不适合套用固定倍数。先盘点数据目录、表空间、WAL 的位置和各自文件系统，再按 copy、link 或目标环境支持的 clone 计算迁移期间的空间与回退风险。若空间不够，不要只为省盘仓促选择 link；应先确认机外备份可恢复，并在隔离环境演练。

负责 PostgreSQL 14 生产实例的 DBA：要在支持截止前确认升级的磁盘条件与迁移方式。
规划数据库服务器的 SaaS 技术负责人：要判断现有存储是否足够、是否需要调整资源。
参与迁移的后端或平台工程师：要了解 link、copy、clone 对空间和回退的影响。

最后更新于 2026 年 11 月 5 日，数据核实自 PostgreSQL 官方版本支持政策及 pg_upgrade 文档。截至该日，官方支持政策列明 PostgreSQL 14 将于 2026 年 11 月 12 日停止支持。这个日期意味着应提前安排并验证迁移，不代表要等到截止日当天切换。(PostgreSQL 版本支持政策)

PostgreSQL 14 pg_upgrade 磁盘空间的实际盘点

数据库逻辑大小不能直接等同于需要准备的磁盘容量。实际文件分布还包括 WAL、集群文件和表空间；迁移时，新集群、临时文件和持续写入也可能占用不同的挂载点。PostgreSQL 的数据目录布局包含 pg_wal，表空间则可能位于数据目录以外，所以只查看主数据目录会漏算存储需求。(PostgreSQL 文件布局说明)

先记录每个路径和它所在的文件系统，再查看实际占用与剩余空间。可在数据库中查询表空间位置和占用：

SELECT spcname, pg_tablespace_location(oid) AS location
FROM pg_tablespace;

SELECT spcname, pg_size_pretty(pg_tablespace_size(oid)) AS used
FROM pg_tablespace;

随后在操作系统侧逐个核对数据目录、表空间目录和 WAL 路径：

df -h /实际数据目录 /实际表空间目录 /实际WAL目录
du -sh /实际数据目录 /实际表空间目录 /实际WAL目录

df 显示对应文件系统的可用空间，du 汇总路径下的文件占用。两者都要结合迁移期间的业务写入、WAL 保留和临时文件位置判断；表空间位置与占用可以通过 PostgreSQL 提供的管理函数查询。(PostgreSQL 管理函数文档)

不要把 pg_upgrade --check 当作容量测试。它用于检查集群兼容性、迁移条件，并提示可能需要人工处理的事项；检查通过不代表目标盘空间足够，也不能证明备份可以恢复。若计划使用 link 或 clone，运行检查时还要指定相应模式，让工具执行模式相关的检查。(PostgreSQL 18 pg_upgrade 文档)

按磁盘条件选择迁移模式

同盘空间紧张时评估 link

link 通过硬链接复用数据文件，减少复制数据文件的额外空间需求。它要求旧、新数据目录位于同一文件系统；表空间和 pg_wal 可以位于其他文件系统。新集群启动后，旧集群不能再作为未变化的原状副本直接访问，因此 link 不是没有回退代价的省空间选项。(PostgreSQL 17 pg_upgrade 文档)

如果新集群尚未启动，失败后的处置可能与已经启动并写入后的情况不同。迁移计划要写明当前执行阶段、旧数据状态和应用切换步骤，不能只写“失败就切回旧库”。

只有在目录确实满足同一文件系统的条件、模式检查通过、机外备份已经恢复验证，并且回退步骤在隔离环境演练过时，才应把 link 纳入生产方案。如果备份只确认生成成功，却没有实际恢复过，空间压力不应成为跳过恢复验证的理由。

空间充足时比较 copy 与 clone

copy 是默认方式，会把数据文件复制到新集群。预算时，应按各自所在文件系统核算旧集群保留、新集群生成、WAL 与临时文件的峰值占用，而不是只看整机剩余容量。

clone 使用文件系统克隆，能够在受支持的环境中避免普通文件复制的空间行为，同时保留旧集群；但不能据此假设任何操作系统和文件系统都能使用。应按目标 PostgreSQL 版本的官方文档核实支持条件，并在实际环境运行带相应模式参数的检查。官方资料没有给出可适用于所有实例的统一预留倍数。

表格要按实际挂载点填写，不能把全机剩余空间当作一个可以任意调度的存储池。表空间是 PostgreSQL 在文件系统中放置数据库对象文件的位置，目录规划要与集群整体备份和恢复方案一起核对。(PostgreSQL 表空间文档)

迁移到独立目标环境时分别核算两端

迁移到另一台服务器时，源端与目标端是不同的容量预算：切换确认前，源端要能继续运行并保留；目标端要容纳新集群；临时文件与 WAL 则计入它们实际所在的文件系统。若采用其他迁移路径，也要把该路径所需的临时副本、日志和同步空间单独列出，不能用源端的可用空间抵扣目标端需求。

如果业务在迁移过程中仍持续写入，隔离环境的演练也要覆盖备份、迁移、追平变更和应用切换。容量结论应来自本团队的数据布局和迁移流程实测，而不是套用其他用户的数据库大小。PostgreSQL 官方备份文档列出 SQL 导出、文件系统级备份和连续归档等不同方式，应根据所选方案验证恢复流程。(PostgreSQL 备份与恢复文档)

用清单验证容量与回退

逐项完成下面的检查，再决定是否可以安排生产切换：

• [ ] 记录实际 PGDATA、配置文件、各表空间和 pg_wal 的路径，并标明所在文件系统。
• [ ] 使用操作系统工具盘点各路径的实际占用和可用空间，再用 PostgreSQL 查询交叉核对数据库与表空间占用。
• [ ] 明确目标集群目录和迁移模式，逐个挂载点核算迁移各阶段的旧集群、新集群、WAL 与临时文件占用。
• [ ] 查阅目标 PostgreSQL 大版本的 pg_upgrade 文档，核实 copy、link 或 clone 的限制，并带所选模式运行 pg_upgrade --check。
• [ ] 在生产变更前制作机外备份，在隔离环境实际恢复，确认备份可用且应用切换步骤可执行。
• [ ] 使用接近生产的数据布局演练迁移，记录每个挂载点的峰值占用；空间仍不足时，调整迁移路径或目标资源。
• [ ] 书面确认回退条件、旧集群保留安排和回退前的数据状态，避免把“保留旧目录”误当作完整恢复方案。

备份、旧集群保留和目标集群容量是三种不同的保障，不能互相替代。软 RAID 或复制也不能代替机外备份；文件系统级备份要求以完整数据库集群为单位处理，若数据目录、WAL 与表空间分布在不同文件系统，还必须考虑各处数据的一致性。必须实际演练恢复，而不是只确认备份任务结束。(PostgreSQL 文件系统级备份文档)

对照盘位检查服务器规划

容量清单能够说明需要多少存储，却不能单独推导迁移会花多久或性能会提升多少。先确认现有盘位能否容纳目标目录、旧集群保留和备份安排；如果机内空间不足，再比较调整迁移模式与安排独立目标环境的风险和成本。

XFP Cloud 配置页面列明默认 2 × 1TB NVMe 直连，可选加装 2TB NVMe，最多加装 2 块；具体选配价格以页面为准。这些是产品容量信息，不构成数据库容量或迁移性能承诺。默认盘没有硬件 RAID，若需要冗余，需自行规划软 RAID 或复制，并另行保留机外备份。可在服务器配置页面核对盘位与选配，在计费说明查看计费周期。迁移预算仍须依据本机实测的文件布局填写，不应把产品盘位直接等同于数据库可用容量。

如果现有方案是共享云实例，可能受共享计算资源、云盘 IOPS 按档计费或存储目录布局限制；确实需要独享计算和直连 NVMe，并愿意自行负责数据库备份与恢复时，XFP Cloud 的 AMD 物理机可以作为目标环境候选。独享服务器不等于数据安全，容量与恢复条件尚未演练通过前，不建议安排生产切换。

常见问题

PostgreSQL 14 用 pg_upgrade，额外空间怎么估？

没有适用于所有实例的固定预留倍数。按文件系统盘点旧数据目录、表空间、WAL、目标目录和临时路径，再依据迁移模式计算各阶段峰值占用。数据库逻辑大小可以交叉核对，但不能代替对实际目录与可用空间的测量。

link 模式能省空间吗？升级失败后旧集群还能直接启动吗？

link 通过硬链接复用数据文件，减少数据文件复制需求，但新旧数据目录必须位于同一文件系统。新集群启动后，旧集群不再是可直接启动的原状回退副本。生产使用前，应确认机外备份可恢复，并演练回退步骤。

PostgreSQL 大版本升级选 copy 还是 link？

若目标文件系统能容纳新旧集群并存，且需要保留旧集群作为更清晰的回退边界，可优先评估默认 copy。空间紧张时再评估 link，但须接受新集群启动后旧集群回退受限的条件。clone 仅适用于目标系统和文件系统支持的环境，也需要先检查和演练。

pg_upgrade --check 会替我检查磁盘够不够吗？

不要把 --check 当作磁盘容量保证。它检查集群兼容性和所选模式的相关条件，也会列出需要人工处理的事项。即使检查通过，也应分别核对数据目录、表空间、WAL 和目标路径所在文件系统的可用空间，并计算迁移期间的额外占用。

确定 PostgreSQL 14 的数据目录、表空间、WAL 位置和迁移模式后，再对照 XFP Cloud 的实际盘位核对目标存储。若当前方案受共享资源争用、云盘 IOPS 费用或存储布局限制，而业务确实需要独享计算与直连 NVMe，可进一步评估 XFP Cloud 的服务器配置。在容量和备份恢复条件未经验证前，不建议切换生产数据库。

常见问题

1. PostgreSQL 14 用 pg_upgrade，额外空间怎么估？

   没有适用于所有实例的固定预留倍数。先按文件系统盘点旧数据目录、表空间、WAL、目标目录与临时路径，再根据迁移模式计算各阶段的峰值占用。数据库逻辑大小可作交叉核对，但不能替代对实际目录和可用空间的测量。

2. pg_upgrade 的 link 模式能省空间吗？升级失败后旧集群还能直接启动吗？

   link 模式通过硬链接复用数据文件，减少复制数据文件所需的额外空间，但新旧数据目录必须位于同一文件系统。新集群启动后，旧集群不再是可直接启动的原状回退副本。生产使用前，应验证机外备份可恢复，并演练回退步骤。

3. PostgreSQL 大版本升级用 copy 还是 link 更稳妥？

   如果目标文件系统能容纳旧、新集群并存，且回退时希望保留未被共享修改的旧集群，可优先评估默认 copy。空间紧张时再评估 link，同时接受新集群启动后旧集群回退受限的条件。clone 仅适用于目标系统和文件系统支持的环境，也须先做模式检查和演练。

4. pg_upgrade --check 会检查磁盘空间够不够吗？

   不要把 --check 当作磁盘容量保证。它用于检查集群兼容性及所选迁移模式的相关条件，也能列出需要人工处理的事项。即使检查通过，也要用文件系统工具分别核对数据目录、表空间、WAL 和目标路径所在挂载点的可用空间，并计算迁移期间的额外占用。