You might be using your Hong Kong VPS when suddenly the website becomes inaccessible, the database connection fails, and SSH commands return errors; upon logging in, you discover the disk is full. This scenario is particularly common with Hong Kong VPS hosting because many plans offer limited system disk space—typically ranging from 20GB to 40GB. Since bandwidth and hardware costs in Hong Kong data centers are high, providers often cut costs by skimping on disk capacity.

　　A full disk triggers a chain reaction: MySQL crashes because it cannot write temporary files, PHP-FPM fails to write session data, Nginx cannot write logs, and even SSH logins may fail. The key is to quickly identify exactly what is consuming all the disk space and then safely clear it out.

　　Step 1: Check disk usage

　　After logging into the server, first check the overall status:

df -h

　　The output lists the usage rate for each mount point. Pay particular attention to the root partition (`/`) and the `/var` partition; if usage exceeds 90%, you need to take action.

　　If `df -h` indicates that a partition is full but you cannot identify the specific directory consuming the space, use `du` to investigate level by level:

du -sh /* 2>/dev/null | sort -rh | head -20

　　This command lists the total size of each folder in the root directory, sorted from largest to smallest. `2>/dev/null` suppresses permission errors to keep the output clean.

　　Once you have identified the largest directory, drill down further:

du -sh /var/* 2>/dev/null | sort -rh | head -20

　　By drilling down layer by layer, you can quickly pinpoint the "culprit."

　　Step 2: Log files—the most common disk space killers

　　Log files are the number one reason why disk space on Hong Kong VPS instances gets filled up. Nginx, MySQL, PHP, and system logs write data silently every day; if left unchecked for just a few days, they can consume several gigabytes of space.

　　Nginx logs

du -sh /var/log/nginx/
ls -lh /var/log/nginx/

　　Nginx's `access.log` and `error.log` are notorious for growing rapidly. For high-traffic websites, it is common for `access.log` to swell to several hundred megabytes in a single day.

　　Cleanup method:

　　Do not simply delete the log files using `rm`. Since Nginx is actively writing to them, the file handles will continue to occupy disk space even after deletion, causing the `df` command to still report the disk as full. The correct approach is to clear the file contents instead:

> /var/log/nginx/access.log
> /var/log/nginx/error.log

　　A more standard approach is to configure log rotation. Edit `/etc/logrotate.d/nginx` and ensure it contains a configuration similar to this:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}

　　"rotate 7" means retaining logs for the last 7 days, with older ones automatically deleted. Enabling compression saves a significant amount of space.

　　MySQL Logs

du -sh /var/log/mysql/
ls -lh /var/log/mysql/

　　MySQL's error.log, slow.log, and general.log files can all grow quite large. In particular, if the slow query log is enabled without log rotation configured, the slow.log file can grow to several gigabytes.

　　Cleaning method:

> /var/log/mysql/slow.log
> /var/log/mysql/error.log

　　A more critical task is checking the MySQL binary logs (binlogs). These logs are used for master-slave replication and data recovery, and they are retained for a long time by default. On small-disk setups like Hong Kong VPS instances, binlogs often act as hidden "space black holes."

du -sh /var/lib/mysql/
ls -lh /var/lib/mysql/ | grep bin

　　To clean up binary logs, you need to log in to MySQL and execute:

SHOW BINARY LOGS;

PURGE BINARY LOGS BEFORE '2026-09-01 00:00:00';

PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);

　　If master-slave replication is not required, you can disable the binary log in `my.cnf` (by commenting out the `log-bin` line) and restart MySQL. However, ensure there are no dependencies from slave databases before disabling it.

　　System Log

du -sh /var/log/
journalctl --disk-usage

　　`journalctl --disk-usage` shows how much space the systemd journal occupies. Here is how to clean it up:

journalctl --vacuum-time=3d

journalctl --vacuum-size=500M

　　PHP Logs

du -sh /var/log/php*
ls -lh /var/log/php*/

　　PHP-FPM slow logs and error logs can also consume significant disk space; the correct way to clear them is to empty their contents rather than deleting the files themselves.

　　Step 3: Backup files—the second-largest disk space consumer

　　Many webmasters configure automatic backups on their servers, storing the backup files on the local disk. Over time, these backup files can fill up the disk completely.

　　Common locations for backup files

find /var/www -name "*.sql" -o -name "*.tar.gz" -o -name "*.zip" 2>/dev/null | head -20
du -sh /www/backup/
du -sh /backup/ /home/backup/ 2>/dev/null

　　Cleanup Strategy

　　First, verify the integrity of the backups. Do not delete anything immediately; confirm that the latest backup is valid before cleaning up the old ones.

ls -lht /www/backup/ | head -20

　　Retain backups from the last 3–7 days and delete older ones:

find /www/backup/ -type f -mtime +7 -delete

　　Long-term strategy: Upload backups to remote object storage; do not keep backups on the local disk. If local backups reside on the same disk as the server, a disk failure will destroy both the server and the backups.

　　Step 4: Other common sources of storage consumption

　　Caches and temporary files

du -sh /tmp/ /var/tmp/ /var/cache/

　　/tmpA large number of temporary files may have accumulated in the directory; clean them up:

rm -rf /tmp/*

　　Note: Do not delete the `/tmp` directory itself; delete only its contents.

　　Docker Usage

　　If Docker is running on the server:

docker system df

　　Check the disk space used by images, containers, and volumes. Cleanup:

docker system prune -a
docker volume prune

　　Website Upload Directory

　　If using WordPress or another CMS, check the upload directory:

du -sh /var/www/website/wp-content/uploads/

　　On some websites, the `uploads` directory can grow to tens of gigabytes due to users uploading large numbers of images or attachments. You cannot simply delete this directory; instead, consider migrating uploaded files to object storage or integrating a CDN to reduce local disk usage.

　　Email Queue

　　If the server is running an email service:

mailq
du -sh /var/spool/mail/ /var/mail/

　　When the mail queue backs up, it can be cleared:

postsuper -d ALL

　　Step 5: Verification after cleanup

　　After the cleanup is complete, verify that the disk space has been freed:

df -h

　　If space has indeed been freed up, double-check that critical services are functioning correctly:

systemctl status nginx
systemctl status mysql
systemctl status php-fpm

　　Note: If you use `rm` instead of `> file` to clear log files, `df` might show that disk space has not been freed (because the file handle is still held by a process). To resolve this, restart the process holding the file, or use `lsof | grep deleted` to identify the deleted-but-still-held files and then restart the corresponding service.

　　Preventive measures: Avoid running out of disk space again

　　Configure log rotation. Set up `logrotate` for Nginx, MySQL, and PHP logs, specifying retention periods and compression.

　　Do not store backups locally. Transfer backup files directly to remote object storage, keeping only the last 1–2 days' worth locally.

　　Monitor disk usage. Write a simple monitoring script to send an email alert when disk usage exceeds 80%:

#!/bin/bash
THRESHOLD=80
CURRENT=$(df / | grep / | awk '{print $5}' | sed 's/%//')
if [ $CURRENT -gt $THRESHOLD ]; then
    echo "Disk usage is ${CURRENT}%, exceeding the threshold" | mail -s "Disk Alert" admin@your-email.com
fi

　　Add it to cron to run once daily.

　　Perform regular cleanup. Make it a habit to log in to the server weekly and run `df -h` and `du -sh /*` to spot potential issues early.

　　Hong Kong VPS instances generally have limited disk space, and a full disk can trigger a cascading system failure. The troubleshooting process is straightforward: check overall usage with `df` → pinpoint the source layer-by-layer using `du` → clear out logs, backups, and caches → verify that space has been freed → and configure log rotation and monitoring to prevent recurrence. Crucially, avoid deleting files blindly; in particular, never use `rm` to delete a log file that is currently being written to—clearing its contents is the correct approach.