ディスクの空きは見えているのに、pg_upgradeで新旧クラスタを置けるか判断できない。
結論：一律の必要容量や固定倍率はありません。 データディレクトリ、表領域、WALの場所を確認し、copy・link・対応環境でのcloneごとに容量と切り戻し条件を見積もってください。容量を節約するためだけにlinkを選ぶのではなく、先にバックアップを復元できることを確認し、難しければ独立した移行先で検証します。
この内容は、本番のPostgreSQL 14を保守するDBAや、アップグレード用の保存領域を判断したいSaaS技術責任者向けです。
移行作業を担当するバックエンド・基盤エンジニアも、モードごとの容量と旧クラスタの扱いを確認できます。
最終更新：2026年11月4日。 PostgreSQL公式のバージョン対応表と、pg_upgradeの公式ドキュメントで日付・各モードの説明を確認しています。PostgreSQL 14のサポート終了日は2026年11月12日と記載されています。公式のサポート状況を確認し、予定を組んでください。
最初に保存領域の配置を洗い出す
データベースの論理サイズや、データディレクトリひとつの使用量だけでは、移行に必要な空き容量を判断できません。表領域が別のマウント先にある場合や、WALをデータ領域とは異なる場所に置いている場合は、それぞれのファイルシステムの空きも確認します。PostgreSQLのファイル配置に関する説明と表領域の管理方法を参照し、実際の配置を記録してください。
確認には、稼働中クラスタの設定とファイルシステムの両方を使います。たとえば、データディレクトリはSHOW data_directory;で調べ、表領域はpg_tablespace_locationなどで実際の場所を確認します。dfでファイルシステムの空き容量を見たうえで、ディレクトリごとの使用量も照合します。
- [ ] データディレクトリの場所と使用量を記録した
- [ ] 表領域ごとの保存先と使用量を調べた
- [ ] WALの配置先を調べ、使用量と空き容量を確認した
- [ ] 移行先のデータディレクトリと、利用する表領域の配置を決めた
- [ ] バックアップ先を移行先とは別に確保し、復元できることを確かめた
- [ ] copy、link、cloneのどれを使うか、容量だけでなく復旧条件も含めて決めた
pg_upgrade --checkは実行前の適合性確認に使えますが、選択した方法で必要なディスク容量が確保されていると保証するものではありません。オプションの役割はpg_upgradeの公式説明で確認し、空き容量の見積もりは別に行ってください。
空きが少ない同一ファイルシステムではlinkの条件を確かめる
同じ保存領域に新旧クラスタを置く計画で、copy分の容量を確保しにくい場合は、linkが候補になります。linkは既存のデータファイルを再利用し、コピーを作らずに移行する方式です。ただし、移行元・移行先のクラスタ配置が、選択した方式のファイルシステム条件を満たすかを公式文書で確認しなければなりません。
容量を抑えられても、切り戻しが簡単になるわけではありません。新クラスタの起動後に旧クラスタを移行前と同じ状態で使えると見なさず、アプリケーションの切り替えや復旧の手順を先に決めます。復旧可能なバックアップがない、または実際の復元試験が済んでいないなら、空き容量だけを理由に本番でlinkを選ばないでください。
旧クラスタを保ちたい場合はcopyとcloneを比較する
旧クラスタを保持した状態で新クラスタを準備したいなら、copyを基準に容量を検討します。copyではデータファイルを新しいクラスタ側に用意するため、移行中に旧・新両方を置く領域が必要です。実際に必要な量はデータ配置や表領域の構成などで変わるため、固定倍率を当てはめず、移行前に各保存先の使用量と空き容量を実測してください。
cloneは、対応するファイルシステム機能を利用してデータファイルを複製する方式です。容量や旧クラスタの扱いに利点がある場合もありますが、どのOS・ファイルシステムでも使えるわけではありません。サーバー環境と対象バージョンの条件をPostgreSQLのpg_upgrade文書で照合し、使えることを確認するまでは、必要容量の計画にcloneを前提として組み込まないでください。
| 移行状況 | 容量の考え方 | 旧クラスタと復旧上の注意 |
|---|---|---|
| 同じ保存領域で容量に余裕がない | linkが条件に合うか確認し、ファイルシステム条件を照合します | 新クラスタ起動後の旧クラスタの扱いを確認し、復元できるバックアップを用意します |
| 旧クラスタを残し、移行先も用意できる | copyに必要な新クラスタ分と、旧クラスタの保存領域を別々に見積もります | 旧クラスタを保つだけで切り戻し完了とはせず、アプリケーション切り替えも手順化します |
| 対応ファイルシステムを利用できる | cloneの利用条件を確認してから容量見積もりに反映します | 対応可否を実環境で検証し、バックアップを別に確保します |
独立した移行先では両端と一時領域を別々に見積もる
別サーバーや別ストレージへ移す場合、移行元の空き容量を移行先の容量として数えないでください。移行元に残すデータ、移行先に作るクラスタ、移行中に生成・保持するWALや一時ファイルを分けて記録します。別の移行方式を使う場合も、その方式で必要となる一時コピーやログの領域を追加します。
見積もりは、実際の保存先ごとに表にして管理すると確認しやすくなります。移行元を消さずに保持する期間や、復旧用バックアップをどこへ置くかも含め、同じファイルシステムに複数の用途が集中していないかを確かめてください。コピーや同期が完了したように見えても、復元確認が済む前に移行元を片付けるのは避けます。
容量と切り戻しを隔離環境で検証する
本番作業前に、実データの配置を反映した隔離環境で移行を試します。ここで確認するのは、単にコマンドが完了するかではありません。コピーや一時ファイルを含め、各ファイルシステムの空きがどのように変化したか、選択したモードの条件を満たすか、切り替え後に必要な復旧手順を実行できるかを記録します。
アップグレード前のバックアップ、旧クラスタの保持、移行先クラスタの領域は、それぞれ目的が異なります。バックアップは別の場所に保管し、復元まで試してください。PostgreSQLのバックアップと復旧に関する説明およびファイルシステムレベルのバックアップの説明も参照し、ファイルの複製やソフトウェアRAIDを、機外バックアップの代わりにしないようにします。
切り戻しの手順には、どのクラスタを使うかだけでなく、アプリケーションの接続先を戻す操作と、復旧後のデータ整合性の確認も含めます。linkの制約やバックアップからの復元手順を隔離環境で確認できないなら、本番の切り替えは保留し、copyを含む別の計画や独立した移行先を検討します。
容量に関するよくある疑問
よくある疑問
pg_upgrade用に確保する空き容量に、決まった倍率はありますか？
ありません。データディレクトリの使用量だけでなく、表領域やWALの配置、移行先の構成、選ぶモードを確認します。copyで新旧を同じ保存先に置く場合と、別環境へ移す場合では必要な場所が異なります。隔離環境で同じ手順を試し、ファイルシステムごとの空き容量の変化を記録してください。
linkなら容量が少なくても、失敗後に旧クラスタへ簡単に戻せますか？
linkはファイルを再利用してコピーを抑えますが、そのことは切り戻しを保証しません。新クラスタ起動後に旧クラスタをそのまま使えると決めつけず、公式文書の制約と実環境の状態を確認します。バックアップの復元試験、アプリケーション切り替えの逆手順、旧データの保全方法を準備できない場合は、linkだけに依存しない移行計画にします。
copyとlinkのうち、どちらを優先すればよいですか？
旧クラスタを保持したまま新クラスタを作る容量を確保でき、復旧時に移行前の状態を使いたいなら、copyを基準に検討できます。容量が厳しい場合も、linkを選ぶ前に復旧条件とファイルシステム要件を確かめます。対応環境ならcloneも候補ですが、サポート条件を確認して実際の構成で試すことが前提です。
--checkが成功すれば、移行に必要なディスク容量も足りていますか？
いいえ。--checkは移行の互換性などを確認するためのもので、必要容量が足りることを保証しません。移行元・移行先のデータ領域、表領域、WALと一時領域を個別に調べ、使用するモードで必要となる配置を確認します。チェック成功後も、空き容量の確認とバックアップの復元試験は別途行ってください。
予定を確定する前に実際の保存領域を照合する
容量不足への対処を、linkへの変更だけに絞らないでください。共有型の仮想サーバーでは、CPUやストレージの利用条件が他の利用者と共有される場合があり、ディスク構成や容量の調整にも制約が生じることがあります。一方、独占型のAMD物理サーバーを選んでも、バックアップや復旧の責任がなくなるわけではなく、データ損失を防ぐ保証にもなりません。
移行先の容量を確保しつつ、専有ハードウェア上でデータベースを長期運用する必要があるなら、XFP CloudのAMD物理サーバーも候補として、実際の提供内容と保存領域を照合してください。利用できるディスク構成や追加条件はサーバー構成の案内で確認できます。月単位などの支払い条件も比較に含める場合は、請求額の計算方法を確認し、データディレクトリ、表領域、WAL、移行モード、復元試験の結果を整理してください。容量と復旧条件がそろうまでは本番切り替えを確定しないことが安全です。
よくある質問
PostgreSQL 14からpg_upgradeする場合、空き容量はどう見積もればよいですか？
一律の倍率では決められません。旧クラスタのデータ領域だけでなく、別の場所にある表領域とWAL、移行先クラスタの配置、バックアップ先をそれぞれ確認します。copyなら旧・新クラスタの共存を見込み、linkなら容量を抑えられる一方で旧クラスタへの切り戻しに制約が出るため、実際の配置で検証してください。
pg_upgradeのlinkモードを使ったあと、問題が起きたら旧クラスタに戻せますか？
linkモードはデータファイルを複製せずに再利用するため、移行先の起動後は旧クラスタをそのまま独立して使えるとは限りません。新クラスタを起動する前に、バックアップの復元可能性とアプリケーションの切り替え手順を確認し、切り戻しに必要な別の復旧手段を用意します。空き容量だけを理由に本番で選ぶのは避けてください。
PostgreSQLの大規模バージョンアップでは、copyとlinkのどちらが安全ですか？
どちらが安全かは、容量よりも切り戻し要件と復旧手段で判断します。copyは旧クラスタを残したまま新しいデータファイルを作るため、両方を置く容量が必要です。linkはファイル再利用で必要容量を抑えられますが、起動後の旧クラスタ利用に制約があります。運用環境に適合するならcloneも候補ですが、ファイルシステム側の対応を先に確かめます。
pg_upgradeのcheckオプションで、ディスク不足も事前に分かりますか？
いいえ。--checkはアップグレード前の互換性などを確認するためのオプションで、実際の配置で必要になる空き容量を保証するものではありません。データディレクトリ、表領域、WALの場所を個別に調べ、選択する移行方式で必要となる領域を見積もってください。チェックが成功しても、容量確認や復旧試験は別に必要です。