適合：沒有適用所有 PostgreSQL 14 實例的固定磁碟預留倍數；先盤點資料目錄、表空間與 WAL 位置，再依 copy、link 或受支援的 clone 模式核算空間和回退風險。不適合：只看資料庫邏輯大小，或只因空間不足就倉促選 link。若目標模式所需空間無法確認，先驗證機外備份可還原，並考慮在獨立目標環境演練。
本文適合負責 PostgreSQL 14 生產資料庫、正安排升級的 DBA；
也適合需要確認現有儲存是否足夠的 SaaS 技術負責人；
參與遷移的後端或平台工程師，可據此判斷不同模式的空間及回退代價。
最後更新於 2026-11-04；停止支援日期核實自 PostgreSQL 官方版本支援政策，模式限制核實自 PostgreSQL 18 pg_upgrade 文件。
先把 PostgreSQL 14 pg_upgrade 磁碟空間拆成實際位置
截至 2026-11-04，官方支援政策列明 PostgreSQL 14 的支援截止日期為 2026-11-12。這是安排升級的時效依據，並不代表所有資料庫都應採用相同的升級路徑或磁碟預留量。PostgreSQL 版本支援頁列出各主要版本的支援狀態。
規劃時，不要以資料庫邏輯大小或單一 du 結果直接推算所需空間。資料庫檔案可能分布在 PGDATA、外置表空間及獨立掛載的 WAL 位置；此外，舊叢集、目標叢集和遷移期間新增的檔案，未必落在同一個檔案系統。PostgreSQL 的檔案配置說明與表空間文件可用來確認資料位置及表空間路徑。
先為每個掛載點分別整理以下資訊：
- 來源叢集的 PGDATA 實際佔用量及所在檔案系統。
- 每個非預設表空間的目錄、佔用量及所在檔案系統。
pg_wal實際位置；若它指向另一個掛載點，需獨立計算。- 目標叢集目錄及其所在檔案系統。
- 遷移期間可能新增的臨時檔案、WAL 與其他寫入量。
- 舊叢集是否要保留、機外備份放置位置，以及所選模式的回退限制。
可以先用 du -sh 檢視各資料路徑，再以 df -h 查詢該路徑所在檔案系統的可用空間。兩個指令回答的問題不同：前者看目錄佔用，後者看掛載點餘量；表空間和 WAL 在不同掛載點時，應逐個檢查，而非只檢查 PGDATA。
依遷移情境比較 copy、link 與 clone
pg_upgrade --check 是相容性檢查的一環，不是磁碟容量核准。升級前應以目標大版本對應的官方文件核對模式限制；例如 PostgreSQL 17 與 18 的 pg_upgrade 文件及PostgreSQL 18 文件分別說明其支援選項與行為。不要只因 --check 通過，就推定磁碟空間足夠。
| 模式或情境 | 空間如何估算 | 舊叢集與回退考量 | 適合的條件 |
|---|---|---|---|
| copy | 估算目標端新檔案及遷移期間額外寫入；若新舊叢集同時放在同一檔案系統，須確認兩者並存時仍有足夠可用區塊。 | 較容易把舊叢集保留作為回退依據，但仍須確認切換前後的操作流程及資料狀態。 | 儲存空間足夠，而且希望保留舊叢集一段時間。 |
| link | 硬連結重用資料檔，通常不需為這些檔案再配置一份完整副本；仍須為其他新增檔案、WAL 等留出空間。 | 新叢集啟動後，舊叢集不能再按原樣使用；不能把 link 當作保留舊叢集的低成本回退方案。 | 空間有限、符合檔案系統條件，且已接受回退限制並有可還原的機外備份。 |
| clone | 不應直接當成普通 copy 或 link 的同義詞；需確認目標版本文件所列的支援條件與實際檔案系統能力，再估算配置空間。 | 保留舊檔案的便利性取決於受支援的複製機制及實際執行結果，須先在相同環境驗證。 | 作業系統與檔案系統支援所需機制，且測試已確認工作流程可用。 |
| 獨立目標環境 | 分別計算來源端保留量、目標端新叢集、臨時檔案與 WAL；來源端餘量不能代替目標端容量。 | 兩端分開安排可避免混淆各自容量，但仍要設計切換、同步與回復流程。 | 來源機器餘量不足，或需要在隔離環境先演練遷移。 |
copy 會建立目標叢集資料檔，不能把來源目錄現有佔用量誤當成「已經包含目標副本」；若兩套叢集放在同一檔案系統，應把並存需求逐項列入預算。link 則透過硬連結重用檔案，但新舊資料目錄需符合官方文件列出的檔案系統條件；空間上的節省並不代表遷移不需要餘裕，也不提供無條件回退。
clone 的行為與限制會依目標版本、作業系統及檔案系統支援而異。只有在目標環境確認相關複製機制可用，並以相同的資料配置做過演練後，才把它納入正式容量計畫；「檔案看起來複製很快」不是適用於所有環境的保證。
空間不足時先看 link 的條件與代價
同一個檔案系統已經放不下 copy 所需的新舊叢集時，link 可能減少資料檔案重複配置，但不能只看這一點就決定採用。首先要確認新舊資料目錄符合該目標版本 pg_upgrade 文件中的檔案系統要求，再檢查 link 後仍會新增或寫入的目錄和檔案有沒有空間。
更重要的是，link 會影響回退方式。新叢集啟動後，舊叢集不能再照原樣存取；若切換後發現應用程式、資料或操作流程有問題，不能假設只要停掉新叢集，就能毫無條件地重新啟動舊叢集。應先定義回退依據：可還原的機外備份、切換前的資料狀態，以及明確的應用程式切回步驟。
若希望保留舊叢集作為回退準備，copy 或獨立目標環境可能更符合需求，但前提是各自的檔案系統有足夠空間。clone 也不能略過環境驗證。資料量、掛載方式或目標檔案系統不同時，其他團隊的空間經驗不應直接套用。
按每個掛載點核算來源、目標與臨時用量
可以用「每個檔案系統分開盤點」取代不可靠的資料庫大小倍數。對每個掛載點，先記錄來源資料目前佔用量與實際可用空間，再依選定模式估算會新增的配置；若目標目錄、表空間或 WAL 位於其他掛載點，便各自建立一筆計算，不把來源端的餘量算到目標端。
估算至少要涵蓋三類需求：
- 目標資料檔：copy 需要核算新叢集資料檔；link 則要確認重用檔案以外的新增配置；clone 必須依已確認的檔案系統行為核算。
- 遷移期間寫入：列出臨時檔案、目標端 WAL，以及遷移期間應用程式是否仍會產生寫入。若資料寫入不能停止，應在測試環境量度該流程下的實際增量，而不是套用他人的容量數字。
- 備份與保留：分清升級前備份存放在哪裡、舊叢集是否保留，以及目標叢集本身需要的空間。備份在機外時，不等於來源或目標磁碟可忽略其餘需求。
若表空間分散在不同位置，可透過 PostgreSQL 的表空間資訊確認位置；管理函式與相關欄位可查閱官方管理函式文件。檔案系統層級備份也有其適用前提，應依照官方備份與復原文件及檔案系統層級備份說明規劃，不能把一份未驗證的檔案複製當成已完成復原保障。
用可勾選清單完成升級前容量核對
以下清單可以直接用於變更審查；任何一項無法確認，都先不要把生產切換日期視為已具備容量條件。
- [ ] 記錄 PGDATA 路徑、實際佔用量與所在檔案系統。
- [ ] 列出所有外置表空間路徑，逐一記錄其檔案系統與可用空間。
- [ ] 確認
pg_wal實際位置；若在獨立掛載點，分開核算其餘量。 - [ ] 按目標版本文件核對所選 copy、link 或 clone 模式的限制。
- [ ] 對每個目標掛載點計算新資料檔、臨時檔案與遷移期間 WAL 的預期新增空間。
- [ ] 若要用 link，確認檔案系統條件，並把「新叢集啟動後舊叢集不能按原樣使用」寫入回退方案。
- [ ] 確認升級前備份存放於機外，並實際演練還原，而非只確認備份工作顯示成功。
- [ ] 在隔離環境以相同資料位置及遷移模式執行流程，記錄實際佔用變化與切換步驟。
- [ ] 若空間不足，先比較調整遷移模式與遷往獨立目標環境的風險；未完成核算前不以縮減備份或跳過回退準備解決容量問題。
獨立目標環境不等於自動縮短升級時間
把目標叢集放到另一台伺服器，可以讓來源端與目標端的磁碟容量分開管理，也便於在隔離環境測試資料位置與切換步驟；但這不代表升級一定更快，也不能用來源機器的可用空間代替目標機器容量。採用不同遷移路徑時，仍須獨立計算臨時副本、同步期間的日誌及目標端寫入空間。
儲存冗餘與備份也要分開看。軟體 RAID 或複製可以作為資料可用性設計的一部分，不能代替放在機外且已實際驗證可還原的備份；獨享伺服器同樣不代表資料不會遺失。若現有方案無法提供所需磁碟餘量，應先比較調整遷移路徑的代價與另設獨立目標環境的風險，再安排生產切換。
常見問題
pg_upgrade 的磁碟空間應怎麼估？
沒有適用所有實例的固定倍數。請先按檔案系統盤點 PGDATA、外置表空間、WAL 與目標目錄，再計算遷移模式會新增的配置，並分列臨時檔案與 WAL 成長。完成估算後，仍應在隔離環境驗證，不能把邏輯資料庫大小直接當成實際磁碟需求。
pg_upgrade 的 link 模式省空間後，升級失敗能直接回退嗎？
不能這樣假設。link 會重用資料檔案，但啟動新叢集後，舊叢集不能再按原樣使用；同時，新舊目錄還要符合官方文件的檔案系統條件。若考慮 link，先確認機外備份可以還原，並把應用程式切回及資料復原步驟實際演練。
PostgreSQL 大版本升級該選 copy 還是 link？
需要保留舊叢集、而且磁碟足以容納新舊資料時，可把 copy 納入評估；空間不足時，link 可能減少資料檔案的重複配置，但會限制原樣使用舊叢集的回退方式。clone 則要先確認目標版本、作業系統和檔案系統支援，不能單憑名稱推定適用。
pg_upgrade --check 會驗證磁碟是否足夠嗎？
不會把它當成容量保證。--check 用於升級前相容性檢查；可用空間仍須按實際資料路徑、表空間、WAL 位置及目標模式另外核算。即使檢查通過，也要確認每個相關掛載點有足夠空間，並在生產切換前驗證備份可還原。
先確認容量與還原條件，再安排伺服器
若現有方案的磁碟無法容納目標資料、新叢集並存或遷移期間的寫入，就不要只為了省空間匆忙選 link；而若備份還原及回退步驟尚未驗證，也不應直接安排生產切換。共享雲端主機可能受同機工作負載影響，磁碟容量與配置方式也未必符合資料庫遷移需要；是否改用獨享 AMD 物理伺服器，應按實際儲存布局、使用期間與總成本評估。
先整理資料目錄、表空間、WAL 位置與預計採用的遷移模式，再參考 XFP Cloud 伺服器建置資訊核對實際可用的存儲選項；若需比較租用週期與費用，請以XFP Cloud 租用費用說明為準。只有在容量、備份還原與切換流程都得到確認後，才適合把獨享伺服器納入正式升級方案。
常見問題
PostgreSQL 14 使用 pg_upgrade，磁碟應如何估算？
沒有適用所有資料庫的固定預留倍數。先逐一記錄 PGDATA、外置表空間、WAL 實際位置與目標目錄所在檔案系統，再依 copy、link 或受支援的 clone 模式估算會新增的實際配置空間；另列遷移期間臨時檔案與 WAL 成長，並以隔離環境驗證。
pg_upgrade 的 link 模式省下空間後，還能直接切回舊叢集嗎？
link 模式以硬連結重用資料檔，降低複製所需的額外空間，但新舊資料目錄必須符合官方文件的檔案系統條件。新叢集啟動後，舊叢集不能再照原狀使用，因此 link 不等於可無成本回退；正式升級前應確認機外備份能還原，並先演練切換與回復程序。
PostgreSQL 大版本升級選 copy 還是 link 比較合適？
若磁碟可容納新舊叢集並存，而且需要在升級後保留舊叢集作為回退依據，copy 通常較容易安排這項保留，但仍須核算各檔案系統的實際可用空間。link 適合空間受限且已接受其回退限制的情況；clone 則須先確認作業系統與檔案系統支援。
pg_upgrade --check 會替我確認磁碟空間足夠嗎？
--check 用於檢查升級相容性等項目，不應視為目標磁碟容量保證。請另外以資料目錄、表空間、WAL 與目標位置逐項盤點，查看各掛載點可用區塊，並針對選定的遷移模式核算新增配置空間；正式切換前還要驗證備份可還原。