VPSのディスク容量を見積もる：データ・ログ・退避分を別々に足す
必要容量は、いまのデータだけでなく、更新・退避・復元の作業中に増える分も足して考える。空き容量が少ないからと、保存物の中身を確かめず削除する順序にはしない。
同じディスク上の使用量を一度ずつ数える
Dockerのvolume資料では、volumeはコンテナのライフサイクルとは独立してデータを保持する。コンテナを削除すれば全部の使用量が消える、という見積りはできない。
当サイトでは保存先を先に書き、同じ場所を二つの項目に重複して足さない表にした。DBのデータがvolumeにある場合、「DB 8 GiB」と「そのvolume 8 GiB」を別々の16 GiBにしない。
| 保存物 | いまの大きさ | 増える条件 | 保存先・容量に含めるか |
|---|---|---|---|
| OS・パッケージ | 実測 | 更新と追加導入 | ルートディスク |
| イメージ・アプリ | 実測 | 新旧版の同時保持 | Dockerの保存先 |
| DB | DBに合う方法で把握 | レコード、索引、処理 | volume等の実体を照合 |
| 添付・アップロード | 実測 | 件数とファイルサイズ | ローカルか外部か |
| ログ | 設定と実測 | 出力量と保持期間 | アプリとDockerを区別 |
| バックアップ | 保存物の実測 | 世代数・圧縮率 | 同居分と外部保管を分ける |
| 一時展開・復元先 | 手順から算出 | 更新や復元の実行中 | 作業時だけ必要な領域 |
容量の単位はそろえる。事業者のGB表示と手元のGiB表示は定義が異なる場合があるので、数字だけで引き算しない。
架空の計算例：現在28 GiBでも28 GiBでは足りない
これは計算方法の例で、当サイトや特定VPSの実測ではない。同じディスクにOS等8 GiB、イメージ6 GiB、DB 8 GiB、添付4 GiB、ログ2 GiBがあるなら、現在分は28 GiBになる。
更新時に旧版を残したまま新イメージ4 GiBを置き、別の復元先用に12 GiBを確保する手順なら、その作業時点では44 GiBになる。さらに将来の増加分と、運用上必要な余裕を検討する。「いつでも20%空ければ十分」といった固定率だけで決めず、予定する作業を置けるかで確かめる。
バックアップを外部に置く場合でも、取得時にローカルの一時ファイルを作る手順なら、その最大量は残る。逆に、直接外部へ出力する設計なら、同じ量を常時二重に足す必要があるかを確認する。
ログの設定と実測を合わせる
Dockerのjson-fileドライバーには、ファイルの大きさや保持数を制御する設定がある。設定を書いたことと、既存のコンテナへ反映されたことは別だ。公式はデーモン設定を変更しても既存コンテナには自動で反映されないと案内している。
Dockerが管理するログファイルを外から直接編集する方法を清掃手順にしない。アプリ独自のログにも別の保持設定がないか確認する。障害調査に必要な記録を残す期間は、容量節約だけで決めない。
小さなファイルが多い環境では、空きバイトだけでなくinodeの空きも確認対象になる。どの保存物が増えたのか分からないまま一括削除するのではなく、保守担当が保存先と保持方針を照合する。
容量を増やす前の出口
残すべきデータ量と作業領域が分かったら、プラン変更の条件でディスク拡張の方法を確認する。表示上のディスク容量が増えても、OS内で使える領域の拡張作業が別に必要なサービスもある。
バックアップが同じディスクにしかない場合は、容量追加とは別に保存先と復元方法を見直す。消去・故障・契約終了で元と一緒に失う構成を、空きが増えただけで解決済みにはしない。
公式資料の確認日: 2026年9月14日。