VPS Disk Full? Linux Disk Cleanup & Expansion Guide (2026)

Everyone who's had a disk suddenly fill up knows the feeling:

The website starts throwing 500s
MySQL says it can't write
Even SSH login lags (because it can't write to ~/.bash_history either)

What's worse: you delete files for ages, and df -h is still 100%.

The workflow below is what I usually use for firefighting, and the goal is clear: first pinpoint "who ate the space," then decide whether to clean, migrate, or expand.

1) Don't panic first—confirm where exactly you're "full"

Check capacity first:

df -hT

Focus on three columns:

Use%: whether a particular mount point (like / or /var) blew up on its own
Type: ext4 / xfs / overlay (Docker) affects how you expand later
Mounted on: don't clean a data disk as if it were the system disk—cleaning the wrong disk is even more awkward

Then check inodes (a very common pitfall):

df -ih

If there's still capacity left but inodes are at 100%, the symptoms are exactly the same as a full disk. Common causes: cache directories, temp directories, small-file explosions (like some logs rotating by the second).

2) Locate the big consumers: who's actually taking up space

I usually scan down from the root directory, finding the "largest layer" first.

# 统计 / 下一级目录占用（可按需换成 /var、/home、/opt）
sudo du -xh --max-depth=1 / | sort -h | tail -n 20

If you want to save time, just use ncdu (highly recommended to install):

# Debian/Ubuntu
sudo apt-get update && sudo apt-get install -y ncdu

# 交互式查看
sudo ncdu /

The advantage of ncdu: you don't have to guess "is it this directory?"—it puts the largest files/directories right in front of you.

3) You deleted files but space didn't come back? It's probably "deleted but still held by a process"

Typical scenario:

You deleted a huge log
The service is still writing to that log (the file handle wasn't closed)
df looks completely unchanged

Find it with this:

sudo lsof +L1

If the output shows deleted but the file size is huge, that's basically it.

The fix is simple:

Most reliable: restart the corresponding service (Nginx / PHP-FPM / MySQL / your app)
Don't want to restart: make the process reopen the file (for example, some services support logrotate's copytruncate or sending a USR1 signal)

Most of the time, restarting the service is the fastest firefighting.

4) The most common "disk killers," ranked by hit rate

4.1 Docker: images, containers, logs, build cache

If you use Docker, take a look first:

docker system df

Clean up (start with the "safe" stuff):

# 删除没用的构建缓存
docker builder prune -f

# 删除没用的镜像/容器/网络（不会删正在跑的容器）
docker system prune -af

# 如果你确定不需要旧 volume（慎用）
docker volume prune -f

By the way: for many people, a full disk isn't images—it's container logs.

# 看看某个容器日志有多大
sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail -n 20

If logs really blew up, it's recommended to configure log rotation for Docker (a long-term solution).

4.2 System logs / journal

# 看 journal 占用
sudo journalctl --disk-usage

# 只保留 7 天（示例）
sudo journalctl --vacuum-time=7d

# 或者限制到 1G
sudo journalctl --vacuum-size=1G

4.3 Web / application logs

The two most common directories:

/var/log/nginx/
/var/log/apache2/

Quickly find the largest:

sudo du -sh /var/log/* | sort -h | tail -n 20

If you're just firefighting, compress/delete historical logs first (don't touch files currently being written, to avoid the pitfall in section 3).

4.4 apt cache + old kernels

# 清缓存
sudo apt-get clean

# 删没用的依赖
sudo apt-get autoremove --purge -y

4.5 Temp directory explosion (/tmp)

sudo du -sh /tmp/* 2>/dev/null | sort -h | tail -n 20

When "some task crashed" and filled up temp files, this one usually makes it obvious at a glance.

5) Inodes really are full: how to handle it

First find where small files are concentrated:

# 找出 /var 下面小文件数量最多的目录
sudo find /var -xdev -type f 2>/dev/null | awk -F/ '{print $1"/"$2"/"$3"/"$4}' | sort | uniq -c | sort -nr | head

Common culprits:

Some service frantically writing small logs
A cache directory with no TTL
Temp files never cleaned up

The cleanup approach is simple: delete the "regenerable" (cache/tmp), keep the "non-regenerable" (data/uploads/databases).

6) Still not enough after cleanup? Then expand (capacity + filesystem together)

Before expanding, confirm: did you actually expand the disk in the cloud console, or do you just "want to expand"?

6.1 First look at the current disk/partition layout

lsblk -f

# 也可以看分区表
sudo fdisk -l

You need to figure out:

Whether it's the same disk (like /dev/vda or /dev/sda)
Which partition your filesystem is mounted on (like /dev/vda1)
Whether there's LVM (if you see lvm2_member, that's a different path)

6.2 The most common scenario: ext4 + growpart + resize2fs

# 安装 growpart（Debian/Ubuntu）
sudo apt-get update && sudo apt-get install -y cloud-guest-utils

# 把第 1 号分区扩到整块盘（示例：/dev/vda1）
sudo growpart /dev/vda 1

# 扩文件系统（ext4）
sudo resize2fs /dev/vda1

# 验证
df -hT

6.3 If it's XFS

XFS can't use resize2fs; do it like this:

# 先 growpart 扩分区
sudo growpart /dev/vda 1

# 然后对挂载点扩（假设挂载点是 /）
sudo xfs_growfs /

df -hT

6.4 If you use LVM (somewhat common, but once you hit it you have to go this route)

# 扩物理卷
sudo pvresize /dev/vda1

# 看逻辑卷路径
sudo lvdisplay

# 扩逻辑卷（示例：把所有空闲都加给 root）
sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv

# ext4
sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

# xfs（如果是 xfs）
# sudo xfs_growfs /

If you're not familiar with expansion, I suggest saving the output of lsblk -f before you start—don't mess up the partition table while firefighting.

7) Small actions to "firefight less in the future"

7.1 Set up a simple disk alert

The most basic way: cron + threshold alert.

cat >/usr/local/bin/disk-alert.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

THRESHOLD=85
MOUNT=${1:-/}

usep=$(df -P "$MOUNT" | awk 'NR==2 {gsub(/%/,"",$5); print $5}')
if [ "$usep" -ge "$THRESHOLD" ]; then
  echo "[disk-alert] $MOUNT usage=${usep}%" >&2
fi
EOF
chmod +x /usr/local/bin/disk-alert.sh

7.2 Make logs "shrink themselves"

Nginx/Apache: make sure logrotate is running
Application logs: don't write endlessly to one file; rotate daily and keep 7-14 days
Docker: enable log rotation (don't let json logs become several GB)

My personal firefighting order (really fast)

df -hT / df -ih: confirm whether it's capacity full or inode full
du -xh --max-depth=1 or ncdu: find the largest directory
lsof +L1: rule out "deleted but not released"
Focus on checking /var/log, Docker, journal, cache
Not enough after cleanup: expand + growpart + resize2fs / xfs_growfs

If you follow this order, you basically won't take detours.

# 删除没用的构建缓存 docker builder prune -f # 删除没用的镜像/容器/网络（不会删正在跑的容器） docker system prune -af # 如果你确定不需要旧 volume（慎用） docker volume prune -f

# 安装 growpart（Debian/Ubuntu） sudo apt-get update && sudo apt-get install -y cloud-guest-utils # 把第 1 号分区扩到整块盘（示例：/dev/vda1） sudo growpart /dev/vda 1 # 扩文件系统（ext4） sudo resize2fs /dev/vda1 # 验证 df -hT

# 扩物理卷 sudo pvresize /dev/vda1 # 看逻辑卷路径 sudo lvdisplay # 扩逻辑卷（示例：把所有空闲都加给 root） sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv # ext4 sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv # xfs（如果是 xfs） # sudo xfs_growfs /

cat >/usr/local/bin/disk-alert.sh <<'EOF' #!/usr/bin/env bash set -euo pipefail THRESHOLD=85 MOUNT=${1:-/} usep=$(df -P "$MOUNT" | awk 'NR==2 {gsub(/%/,"",$5); print $5}') if [ "$usep" -ge "$THRESHOLD" ]; then echo "[disk-alert] $MOUNT usage=${usep}%" >&2 fi EOF chmod +x /usr/local/bin/disk-alert.sh

1) Don't panic first—confirm where exactly you're "full"

2) Locate the big consumers: who's actually taking up space

3) You deleted files but space didn't come back? It's probably "deleted but still held by a process"

4) The most common "disk killers," ranked by hit rate

4.1 Docker: images, containers, logs, build cache

4.2 System logs / journal

4.3 Web / application logs

4.4 apt cache + old kernels

4.5 Temp directory explosion (/tmp)

5) Inodes really are full: how to handle it

6) Still not enough after cleanup? Then expand (capacity + filesystem together)

6.1 First look at the current disk/partition layout

6.2 The most common scenario: ext4 + growpart + resize2fs

6.3 If it's XFS

6.4 If you use LVM (somewhat common, but once you hit it you have to go this route)

7) Small actions to "firefight less in the future"

7.1 Set up a simple disk alert

7.2 Make logs "shrink themselves"

My personal firefighting order (really fast)

Loading…

1) Don't panic first—confirm where exactly you're "full"

2) Locate the big consumers: who's actually taking up space

3) You deleted files but space didn't come back? It's probably "deleted but still held by a process"

4) The most common "disk killers," ranked by hit rate

4.1 Docker: images, containers, logs, build cache

4.2 System logs / journal

4.3 Web / application logs

4.4 apt cache + old kernels

4.5 Temp directory explosion (/tmp)

5) Inodes really are full: how to handle it

6) Still not enough after cleanup? Then expand (capacity + filesystem together)

6.1 First look at the current disk/partition layout

6.2 The most common scenario: ext4 + growpart + resize2fs

6.3 If it's XFS

6.4 If you use LVM (somewhat common, but once you hit it you have to go this route)

7) Small actions to "firefight less in the future"

7.1 Set up a simple disk alert

7.2 Make logs "shrink themselves"

My personal firefighting order (really fast)