まずは今週、削除ではなく使用量とタスクを照合します
Proxmox Backup Server 4.2は、公式発表によると2026年4月29日に公開されました。公開日は公式リリース情報で確認できます。データストアが満杯に近づいたら、まずpruneとガベージコレクション（GC）の実行状況を確認し、PBS側の表示とファイルシステム側の使用量を照合してください。スナップショットの一覧や重複排除の数値だけで削除対象を決めず、.chunksを手動で削除してはいけません。
この記事は、独立したPBSを管理し、データストアの使用量が増え続けているシステム管理者向けです。
複数の顧客環境を担当するMSPには、顧客ごとの保持設定と作業記録を分けて確認する方法を示します。
複数テナントのバックアップ領域を運営する小規模IDCには、保存先の種類を踏まえた容量判断の手順をまとめます。
最終更新：2026年10月28日。PBS 4.2の公開日と保守・ストレージの説明は、公式リリース情報および公式メンテナンス文書、公式ストレージ文書で照合しています。
「削除したのに空きが増えない」ときはpruneとGCを分けて見ます
pruneは、保持ルールに基づいて不要なバックアップスナップショットを整理する処理です。GCは、その結果として参照されなくなったデータチャンクを調べ、再利用されていない領域を回収する処理です。スナップショットが一覧から消えても、ディスク上の使用量がすぐ同じ割合で減るとは限りません。
そのため、「PBSのバックアップを削除したのにディスク容量が戻らない」場合は、pruneの対象と実行結果、GCの最終実行結果とエラーを別々に確認してください。pruneの実行だけでGCまで完了したと判断せず、PBS公式メンテナンス文書に沿って作業の状態を読み取ります。
「pruneとGCの違い」を判断するときは、次のように役割を分けると整理できます。
- prune：保持ルールに合わないスナップショットを整理します。
- GC：スナップショットから参照されなくなったチャンクを調べ、回収可能な領域を処理します。
- ファイルシステム：PBSの画面とは別に、保存先の実使用量と空き容量を示します。
どれか一つの表示だけでデータが不要だと決めないでください。PBSが表示するバックアップの情報と、保存先で実際に消費されている領域は、同じ指標ではありません。
役割ごとに、故障の原因と変更リスクを分けます
単独でPBSを管理している場合
pruneとGCのスケジュール、直近の開始時刻・終了状態・エラー記録を確認します。タスクが予定どおり動いていないのか、正常終了しても使用量が変わらないのかを分けて記録してください。
複数の顧客環境を担当するMSPの場合
顧客ごとに、保持ルール、タスクの実行結果、容量アラートを照合します。削除や保持期間の変更に進む前に、対象の顧客・データストア・変更内容・承認状況を作業記録に残してください。共有する保存領域では、確認が取れていないデータを一括で削除しないことが重要です。
複数テナントを運営する小規模IDCの場合
まず、datastoreがどのストレージ上にあり、どのテナントと共有されているかを確認します。テナント単位の上限やアラートがある場合は、その設定と実際の保存先の使用量を分けて見ます。容量逼迫を一台のPBS全体の問題と決めつけず、保存領域の境界を確認してください。
保存先の種類に合わせて、容量表示を読み分けます
「PBSのバックアップ領域が不足したとき、先に整理するか拡張するか」は、タスクの状態と保存先の空き容量を合わせて判断します。ファイルシステムやストレージ方式によって確認箇所が異なるため、PBS公式のストレージ文書で対象の方式と仕様を確かめてください。
| 保存先・構成 | PBS側で確認すること | 保存先側で照合すること |
|---|---|---|
| ext4、XFS上のディレクトリ | datastoreの状態、pruneとGCの実行結果 | 対象パスを含むファイルシステムの使用量と空き容量 |
| ZFS上のデータセット | datastoreの状態、保守タスクの結果 | プールとデータセットそれぞれの容量表示 |
| S3形式の保存先 | PBS 4.2での対応方式と制約、タスク結果 | オブジェクト保存先側の容量・使用量表示 |
Linuxのファイルシステムを確認する場合は、PBS公式のコマンドリファレンスと対象環境の構成を確かめたうえで、datastoreのパスに対してdf -hT /datastoreのパスを実行します。ZFSではzpool listやzfs listも確認候補になりますが、どのプール・データセットが対象かを特定してから実行してください。S3形式の場合は、ローカルのファイルシステム表示だけでは保存先全体の使用量を判断できません。
状態を照らし合わせて、先に行う処置を選びます
| 確認できた状態 | 先に行うこと | 避けること |
|---|---|---|
| pruneが未実行、または失敗している | 保持設定、スケジュール、タスクログを確認し、失敗理由を調べます | 理由を確認せずに手動削除する |
| pruneは終了しているが、GCが未実行・失敗している | GCの状態とエラー、保存先の空き容量、公式の保守手順を確認します | GCが終わっていない段階で容量が戻ったと判断する |
| PBSと保存先の両方で空き容量が不足している | データの保護状態と復旧手段を確認し、安全な整理または容量追加を計画します | 作業可能な空き領域があると決めつけて変更を始める |
| GCを実行できず、追加操作の余地も確認できない | 保存先別の公式手順と復旧条件を確認し、変更前に保守時間と復旧経路を確保します | .chunksを移動・削除して空きを作ろうとする |
PBS datastoreの状態と実際のファイルシステム使用量が食い違う場合は、処置を急がず、保存先の種類、タスクログ、対象パスを照合してください。2026年9月22日の公式フォーラムにある容量不足の個別相談は、特定環境の事例です。PBS 4.2全体に共通する不具合や原因の証明として扱うことはできません。
変更前後に、確認項目を一つずつ記録します
次の項目を完了してから、整理や拡張に進みます。
- [ ] 対象のPBS datastoreと保存先の種類を特定しました。
- [ ] pruneのスケジュール、保持設定、直近の成功・失敗を確認しました。
- [ ] GCのスケジュール、直近の結果、エラー記録を確認しました。
- [ ] PBS側の使用状況と、ファイルシステムまたは保存先側の使用量を照合しました。
- [ ] 変更対象の顧客・テナント、対象データ、承認者を記録しました。
- [ ] 作業前のバックアップ保護状態、保守時間、復旧手段を確認しました。
- [ ] 変更後にpruneとGCの結果、保存先の空き容量、次回バックアップの成否を確認する担当を決めました。
PBSのコマンドやタスクの状態表示を確認するときは、適用中のバージョンに合う公式コマンドリファレンスを参照してください。ストレージ構成を変更する作業では、先に復旧できる状態を確保し、保存先の仕様に合った手順と保守時間を用意します。特に容量が逼迫しているときは、ログや設定を保存してから作業内容を決めてください。
作業後は、pruneとGCのタスク結果、PBSのdatastore表示、保存先の実使用量を改めて照合します。その後のバックアップが予定どおり完了したことも確認してください。必要容量は、実際のバックアップ増加量と保持ルールから見積もります。単独のフォーラム投稿で示された使用量や増加率を、別の環境の基準にしないでください。
容量が足りないときは、バックアップ先の設計も見直します
現在の保存先が共有型の仮想サーバーの場合、共有ストレージの容量や性能が他の利用者の状況に左右されることがあり、ディスク構成の変更にも契約上の制約が生じる場合があります。PBSを独立したバックアップ先に置き、ディスク構成や保守手順を自分で管理したいなら、専有のAMD物理サーバーも比較対象になります。ただし、物理サーバーのレンタルはPBSの運用代行やバックアップサービスではないため、冗長化と機外バックアップは別途計画が必要です。
実際のバックアップ増加量、保持ルール、ストレージ方式を先に整理し、必要なディスク構成と帯域が現行の選択肢に合うかをOVN Cloudのサーバー構成案内で確認してください。料金と契約期間は月額プランの案内で照合できます。PBSの領域が不足したからといって、直ちに拡張するのではなく、原因と復旧条件を確認したうえで独立サーバーを比較するのが安全です。