Linuxでのストレージ容量の最適化方法

長年にわたり、ディスク容量が不足した際の標準的な解決策は単純でした。それは、ストレージを増設することでした。ストレージは安価だったからです。しかし、もはやそうではありません。2025年後半以降、AIインフラの需要が世界的な生産能力を逼迫させたことを受け、NANDフラッシュの価格は急騰しています。 エンタープライズ向けSSDの契約価格は2026年第1四半期だけで85～90%上昇し、コンシューマー向けNVMeドライブの実勢価格は約2倍に跳ね上がりました。また、新たなNAND生産能力が稼働するのは2027年以降になると見込まれています。

その結果、サーバー上の1GBあたりのコストは1年前よりも高くなっており、新たなストレージを購入するよりも、既存のストレージを最適化する方がはるかに賢明な投資となります。本記事では、ディスク容量を消費している原因を特定し、不要なデータを削除し、ストレージをより効率的に使用できるようファイルシステムを設定する方法について解説します。

ディスク使用状況の確認

まず df -h を実行し、マウントされているすべてのファイルシステムの概要（総容量、使用済み容量、使用率など）を確認します。90%を超えているパーティションには注意が必要です。必要に応じて、個々のパーティションを個別に確認してください：

df -h /
df -h /boot

inodeを見落とさないようにしてください。ファイルシステムに空き領域があっても、利用可能なinodeが不足していると、同様の障害が発生します。 df -i.

もし df で利用率が100%と表示されるものの数値が合致しない場合、ゴーストファイルが存在する可能性があります。これらは削除されたものの、実行中のプロセスによってファイルハンドルが保持され続けているファイルです。プロセスがファイルハンドルを解放するまで、その領域は解放されません。以下のコマンドで特定します:

sudo lsof / | grep deleted

どのファイルシステムに負荷がかかっているかがわかったら、 du または ncduを使用してディレクトリを詳細に調査してください。簡易チェックやスクリプト作成には、 du が適しています：

du -h --max-depth=1 /var

スキャン時に -x を指定してルートからスキャンすると、単一のファイルシステム内に留まり、 /proc。リモートサーバーでの対話的な探索には、 ncdu を使用すると、サイズ順に並べ替えたりファイルを直接削除したりできる、操作しやすいテキストインターフェースが利用できます。

パッケージキャッシュ、ログ、および重複ファイルの削除

パッケージキャッシュ、ログファイル、および大容量ファイルや重複ファイルの3つの領域が、常に最も多くの空き容量を確保できる部分です。

パッケージキャッシュと孤立した依存関係

インストールや更新を行うたびに、キャッシュされたパッケージファイルが残されます。時間が経つにつれて、これらは目立たないまま蓄積されていきます。お使いのディストリビューションに応じて、これらをクリーンアップしてください：

変更内容を事前に確認するには sudo apt autoremove --dry-run。古いカーネルはUbuntuシステム上で1.5GB以上を占有する可能性があります。古いバージョンを削除する際は、常に稼働中のカーネルと、その直前のバックアップを1つ残しておくようにしてください。

Snap や Flatpak を使用している場合、これらもリビジョンやランタイムを蓄積します:

sudo snap set system refresh.retain=2
flatpak uninstall --unused

/var/log 内のログファイル

ログファイルは、最も一般的な目立たないディスク容量の浪費源です。まず、容量が大きすぎるログファイルを探してください：

du -xhd1 /var/log | sort -h
find /var/log -type f -size +100M

systemdのジャーナルについては、手動でファイルを削除するのではなく、組み込みのvacuumツールを使用してください：

sudo journalctl --vacuum-size=500M

恒久的な上限を設定するには、 /etc/systemd/journald.conf:

SystemMaxUse=500M
MaxRetentionSec=14day

サービスによってまだオープンされているアクティブなログファイルについては、 rmを使用しないでください。プロセスがファイルディスクリプタを保持している間は、空き領域が解放されません。代わりに truncate を使用してください:

sudo truncate -s 0 /var/log/syslog

大容量ファイルと重複ファイル

システム全体で 500MB を超えるファイルを検索するには:

sudo find / -type f -size +500M -exec ls -lh {} +

重複ファイルについては、 rmlint はハッシュベースの比較を使用して、重複ファイル、空のディレクトリ、および破損したシンボリックリンクを検出します。特に、同一のファイルが異なる役割を果たしている可能性のあるサーバーでは、何かを削除する前にその出力を注意深く確認してください。

ファイルシステムレベルの最適化

ファイルを整理した後、ファイルシステムを調整することで、同じハードウェアからより多くの利用可能領域を確保できます。

ext4の予約領域の削減

デフォルトでは、ext4はファイルシステムの5%をルート用に予約しています。2TBのデータパーティションの場合、100GBが未使用のまま放置されることになります。データパーティションがルートファイルシステムではない専用サーバーでは、これを安全に削減できます：

sudo tune2fs -m 1 /dev/sdXn

これにより、予約領域が1%に設定されます。これはほとんどのユースケースで十分です。変更を確認するには、 tune2fs -l /dev/sdXn.

Btrfsの透過的圧縮

Btrfsは、ext4やXFSにはない透過的なファイル圧縮をサポートしています。 compress=zstd オプションでマウントすると、書き込み時にデータが自動的に圧縮されます。ZSTDは速度と圧縮率のバランスに優れています。ファイルの種類が混在するワークロードでは、 compress-force=zstd を使用すると、ヒューリスティックでは通常スキップされるファイルも圧縮されるため、さらに10～20%の容量削減が可能です。

Btrfsボリューム上の既存データを圧縮するには：

btrfs filesystem defragment -czstd /path/to/dir

スナップショットやリフレリンクが存在するボリュームでは、この操作に注意が必要です。デフラグを行うとコピーオンライトの関係が破綻し、かえってディスク使用量が増加する可能性があります。

インスタントコピー用のリリンク

XFSとBtrfsの両方がリリンクをサポートしています。リリンクは、一方のコピーが変更されるまで物理ブロックを共有するファイルコピーを作成します。これは、ストレージ使用量を倍増させることなく、VMディスクイメージやコンテナレイヤーをクローンするのに役立ちます：

cp --reflink=always source.img clone.img

LVM シンプロビジョニング

LVMのシンプロビジョニングを使用すると、物理的に存在する容量よりも多くの論理領域を割り当てることができ、データが書き込まれる際にのみ実際のディスク領域を消費します。これは、それぞれ独自の論理ボリュームを必要とする複数のVMやコンテナを実行しているが、それらがすべて同時にボリュームを埋めるわけではない場合に有用です。

シンプールが枯渇するのを防ぐには、 /etc/lvm/lvm.conf で thin_pool_autoextend_threshold を thin_pool_autoextend_percent.

ストレージメンテナンスの自動化

手動でのクリーンアップは一度きりの作業です。自動化されたクリーンアップは、現在から次回ログインするまでの間、ディスクを健全な状態に保ちます。 systemd 可能な限りタイマーを使用してください cron 可能な限り使用してください。これらは出力を journalctl 自動的に出力し、 Persistent=true 再起動後に実行されなかった処理を補完します。

Dockerには特に注意が必要です。コンテナのログは、目立った警告なしに膨れ上がる可能性があります。 /etc/docker/daemon.jsonを設定します。 max-size および max-file を log-opts キーの下でとを設定し、個々のコンテナがディスク容量を使い果たすのを防ぎます。

予防的な監視を行うには、2段階のアラートシステムを設定しましょう。ディスク使用率が80%に達した時点で警告を、90%に達した時点で重大なアラートを発するようにします。ディスク使用量を1時間ごとに記録することで、増加傾向を追跡し、パーティションが容量上限に達する時期を予測できます:

0 * * * * df --output=source,size,used,pcent >> /var/log/disk_usage.csv

もう1つの安全策として、 /var, /tmp、および /home を別々のパーティションにマウントしてください。これにより、制御不能なログやユーザーデータがルートファイルシステムを消費し、システム全体がクラッシュするのを防ぐことができます。

1ギガバイトを最大限に活用する

ストレージ価格の高騰が続いており、2027年に新しいNAND生産ラインが稼働するまでは改善が見込めないため、既存のストレージを最適化することは単なるベストプラクティスにとどまりません。それは実質的なコスト削減につながります。そのアプローチはシンプルです：

• 以下のツールを使用してディスク使用状況を監査する df, du、そして ncdu を使用してディスク使用状況を監査してください。
• パッケージキャッシュのクリア、ログのローテーション、重複データの削除を行い、即座に空き容量を確保します。
• ファイルシステムをチューニングします。ext4の予約ブロックを減らす、Btrfsの圧縮を有効にする、あるいはLVMのシンプロビジョニングを使用して、同じハードウェアからより多くのパフォーマンスを引き出します。
• systemd タイマーを使用してメンテナンスを自動化し、監査の合間もディスクをクリーンな状態に保ちます。
• 使用状況の傾向を監視し、80% と 90% の時点でアラートを設定して、問題を早期に発見します。

高性能な NVMe ストレージを備えた専用サーバーインフラストラクチャが必要な場合は、FDC の専用サーバーが最適です。