'docker system prune -a' は実行しても安全ですか？

停止中のコンテナ、使われていないネットワーク、宙に浮いたビルドキャッシュ、そして稼働中のコンテナが使っていないすべてのイメージを削除します。--volumes を付けない限りデータは残ります。--volumes を付けると未使用のボリュームも消え、停止中のデータベースコンテナのボリュームも未使用扱いになります。確信がなければこのフラグは付けないでください。

巨大なログファイルを消したのに、df ではディスクがいっぱいのままです。なぜ？

稼働中のプロセスがまだそのファイルを開いているため、カーネルが領域を解放していません。'lsof +L1' で見つけて、そのサービスを再起動してください。次からは使用中のログを消すのではなく、'truncate -s 0 file' で中身を空にしましょう。

空き容量はどのくらい残すべきですか？

少なくとも 10〜15%。データベース、パッケージ更新、Docker の pull には一時的な領域が必要で、100% 埋まったディスクは書き込み途中のデータベースを壊すことがあります。

再インストールせずにディスクを増やせますか？

はい。上位プランへのアップグレードでディスクはその場で拡張され、データも残ります。Nano は 15 GB、Micro は 25 GB、Small は 35 GB、Medium は 45 GB です。アップグレード時にサーバーは一度再起動します。

小さな VPS を埋めるのはたいてい何ですか？

私たちの経験では、Docker のイメージとビルドキャッシュ、systemd の journal、誰もローテーションしないアプリのログ、そして /root に置き忘れたデータベースのダンプやバックアップアーカイブです。

VPS のディスク容量を壊さずに空ける方法

VPS のディスクがいっぱい？du と ncdu で容量を食っているものを探し、apt キャッシュ、journal、Docker の残骸、ログをデータを失わずに片付けます。

「No space left on device」は決して都合のいいときには出てきません。データベースは書き込みを受け付けなくなり、apt はアップグレードを終えられず、Docker は今まさに必要なイメージの pull を拒否します。朗報は、小さな VPS なら犯人はほぼ必ず 5 つのうちのどれかで、2 分で見つけられることです。

1. どれくらいひどいのか？

df -h /
df -i /

1 行目は使用済みの容量を示します。2 行目は inode です。容量には余裕があるのに inode が 100% に達しているなら、何百万もの小さなファイル（セッションファイル、メールキュー、キャッシュディレクトリ）を抱えています。問題は別でも、症状は同じです。

2. 大きいものを探す

ツリーを上からたどり、サイズ順に並べます。

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

-x は 1 つのファイルシステムにとどまるので、/proc に迷い込みません。そのあと一番大きいものの中へ潜っていきます。対話的に見て回るなら ncdu のほうがずっと快適です。

apt install -y ncdu
ncdu -x /

矢印キーで移動、d で削除。最後のキーには気をつけてください。

3. すぐ効く対策

以下は Ubuntu や Debian のどのサーバーでも安全です。

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

apt autoremove は古いカーネルも片付けます。多くの人が驚くのが systemd の journal で、放っておくと数 GB まで膨らみます。恒久的に上限を設けるには、/etc/systemd/journald.conf に SystemMaxUse=200M を設定し、systemctl restart systemd-journald を実行します。

4. Docker の残骸

Docker を使っているなら、まずここを確認します。古いイメージとビルドキャッシュはデプロイのたびに積み上がります。

docker system df
docker image prune -a
docker builder prune

docker image prune -a は、稼働中のどのコンテナも使っていないイメージを削除します。たいていはそれで問題ありませんが、次のデプロイでまた pull されます。

危険なのは docker system prune -a --volumes です。ボリュームにはデータが入っていて、停止中のコンテナにつながったボリュームは未使用とみなされます。こうしてデータベースを失う人がいます。フォーラムの回答からこれを貼り付けないでください。

もうひとつの隠れた容量泥棒はコンテナのログです。/etc/docker/daemon.json で上限を設けます。

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

設定後に Docker を再起動します。上限はそれ以降に作られたコンテナにしか適用されないので、ログの多いコンテナは docker compose up -d --force-recreate で作り直します。

5. ログと忘れられたファイル

ディスク全体から大きなファイルを探します。

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

よく見つかるもの：半年前の backup.tar.gz が /root に、誰かがダウンロードするつもりだったデータベースのダンプ、一度もローテーションされていないアプリのログ。

サービスがまだ書き込んでいるログは rm で消さず、中身を空にします。

truncate -s 0 /var/log/myapp/app.log

すでに消してしまって容量が戻らないなら、どこかのプロセスがまだ開いたままです。

lsof +L1

そこに表示されたサービスを再起動すれば容量が戻ります。

片付けだけでは足りないとき

データそのものが本物のこともあります。増え続けるデータベース、ユーザーのアップロード、モデルファイル。その場合の誠実な解決策はディスクを増やすことです。プランをアップグレードすればディスクはその場で拡張され、すべて残ります。Nano は 15 GB、Micro は 25 GB、Small は 35 GB、Medium は 45 GB。サーバーは一度だけ再起動します。詳細はプランのドキュメントにあります。

静かに容量を食うものがもうひとつ、swap ファイルです。swap のガイドに従ったなら、その 1〜2 GB は意図的に確保したものです。Docker が最大の消費者なら、Docker インストールガイドと Compose スタックのガイドでイメージの増えすぎを抑える方法を紹介しています。

これらすべてを防ぐ習慣：初日に journal と Docker のログに上限を設けること。設定 2 行で、「ディスクがいっぱい」はほとんど起きなくなります。