From 84% to 57%: A Step‑by‑Step Server Disk Cleanup

The root partition /dev/vda2 is 40 GB and 32 GB (84 % used), risking database writes, log failures, and container start‑ups. A three‑phase method is used: locate space consumers, clean low‑risk items, and prevent further growth.

Step 1 – Locate space consumers

List top‑level directory sizes on the same filesystem: sudo du -xhd1 / 2>/dev/null | sort -hr The -x flag prevents crossing mount points, keeping the result consistent with df -h /. If /var appears large, drill down: sudo du -xhd1 /var 2>/dev/null | sort -hr Typical large directories are /var/lib/docker, /var/log, application log folders, temporary files, and old backups. In this case Docker occupied the most space, freeing several gigabytes after cleanup.

Step 2 – Low‑risk cleanup

Clear APT caches:

sudo apt clean
sudo apt autoremove

Inspect system logs without deleting them: sudo du -sh /var/log/* If journald consumes much space, prune by age:

sudo journalctl --disk-usage
sudo journalctl --vacuum-time=7d

For oversized traditional log files, truncate instead of deleting to keep the file descriptor open:

sudo truncate -s 0 /var/log/syslog
sudo truncate -s 0 /var/log/kern.log

Truncation should be done only after confirming the logs are no longer needed.

Step 3 – Focused Docker cleanup

Check Docker storage usage: docker system df If images, stopped containers, or build cache dominate, run:

docker system prune -af
docker builder prune -af

Do not add --volumes indiscriminately, because Docker volumes may hold databases, uploaded files, or other persistent data.

List volumes first: docker volume ls Inspect a specific volume’s size:

sudo du -sh /var/lib/docker/volumes/<volume_name>/_data

Remove only confirmed‑unused volumes:

docker volume rm <volume_name>

Step 4 – Prevent Docker log bloat

Edit /etc/docker/daemon.json to limit the default json-file driver:

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

Restart Docker (schedule during low‑traffic periods because the restart affects running containers): sudo systemctl restart docker The new limits affect newly created or recreated containers; existing containers may need recreation to apply the settings.

Step 5 – Clean application logs

Find large application logs (over 100 MB):

sudo find /app -name "*.log" -size +100M -exec ls -lh {} \;

After confirming they can be cleared, truncate them: sudo truncate -s 0 /app/logs/app.log Long‑term, configure log rotation (e.g., Python’s RotatingFileHandler, system logrotate, or Docker log limits).

Step 6 – Find other large files

Search for files larger than 100 MB on the root filesystem while staying on the same device:

sudo find / -xdev -type f -size +100M -exec ls -lh {} \; 2>/dev/null | head -20

Typical candidates are old archives, temporary backups, core dumps, and expired packages. Unknown files, especially database files or Docker volume data, should not be deleted.

Step 7 – Long‑term strategy

If the root disk remains only 40 GB and Docker usage is heavy, migrate Docker’s data directory to a separate data disk (e.g., /data).

Mount the new data disk.

Stop Docker: sudo systemctl stop docker Rsync the current Docker directory: sudo rsync -aqxP /var/lib/docker/ /data/docker/ Edit /etc/docker/daemon.json to set "data-root": "/data/docker" (retain the log‑driver settings from Step 4).

Start Docker and verify containers.

This migration carries higher risk; ensure the data disk is correctly mounted and the copy is complete before restarting containers.

Verification

After cleanup, re‑check root usage: df -h / and Docker usage: docker system df The utilization dropped from 84 % to roughly 60 %, confirming the effectiveness of the cleanup. Ongoing prevention includes limiting Docker logs, scheduling regular docker system df checks, configuring log rotation, setting disk‑usage alerts, and moving Docker and application data off the system partition.