❤️ AZDIGI chính thức cập nhật hệ thống blog mới hoàn chỉnh. Tuy nhiên có thể một số bài viết bị sai lệch hình ảnh, hãy ấn nút Báo cáo bài viết ở cuối bài để AZDIGI cập nhật trong thời gian nhanh nhất. Chân thành cám ơn.

Máy chủ VPS của bạn bắt đầu có những dấu hiệu bất thường: website load chậm, dịch vụ đột nhiên ngừng hoạt động, database báo lỗi khi ghi dữ liệu, hay không thể upload file lên server. Nhiều khả năng VPS của bạn đã hết dung lượng ổ cứng.

Khi VPS đầy ổ cứng, các service quan trọng sẽ không thể ghi dữ liệu mới. Nginx hoặc Apache không ghi được log, MySQL không thể tạo temporary files, PHP sessions lỗi, và website có thể hiện lỗi 500. Thậm chí bạn cũng không thể SSH vào server để kiểm tra

ℹ️ Bài này sẽ hướng dẫn cách chẩn đoán, tìm nguyên nhân và dọn dẹp dung lượng VPS một cách an toàn.

Kiểm tra dung lượng ổ cứng hiện tại

Công cụ giám sát VPS command line

Lệnh df -h: kiểm tra tổng quan

Đầu tiên, dùng lệnh df -h để xem tình trạng tất cả partition:

df -h

Output mẫu khi VPS gần đầy:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   37G  1.2G  97% /
/dev/vda2       100M   85M   15M  85% /boot
tmpfs           1.0G     0  1.0G   0% /dev/shm
/dev/vda3        20G   18G  1.5G  90% /var

⚠️ Cột quan trọng nhất là Use%. Khi partition chính (/) hoặc /var đạt trên 90%, bạn cần hành động ngay.

Giải thích các cột:

  • Filesystem: tên partition
  • Size: tổng dung lượng
  • Used: đã dùng
  • Avail: còn trống
  • Use%: phần trăm đã dùng
  • Mounted on: mount point

Chú ý đặc biệt / (partition gốc) và /var (chứa logs, database, cache).

Lệnh df -i: kiểm tra inodes

Đôi khi VPS “đầy” nhưng df -h vẫn hiện còn dung lượng. Nguyên nhân có thể là hết inodes:

df -i
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 2614000    7440  100% /
/dev/vda2        25688      45   25643    1% /boot
/dev/vda3      1310720  985000  325720   75% /var

Khi cột IUse% đạt 100%, partition đã hết inodes dù còn dung lượng. Tình trạng này xảy ra khi có quá nhiều file nhỏ (session files, cache files, log entries).

Tìm thư mục và file lớn nhất

Netdata dashboard VPS

Top 10 thư mục chiếm dung lượng nhất

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

Output mẫu:

8.5G    /var
4.2G    /usr
3.1G    /home
2.8G    /opt
850M    /tmp
420M    /boot
180M    /etc
45M     /root
12M     /bin
8.0M    /sbin

Lệnh này cho biết thư mục nào đang “ăn” dung lượng nhiều nhất. Thường thì /var, /home, /tmp là những ứng viên hàng đầu.

Drill down vào thư mục /var

/var thường là thủ phạm chính, hãy khoan sâu vào:

du -sh /var/* 2>/dev/null | sort -rh
5.2G    /var/log
1.8G    /var/lib
1.2G    /var/cache
380M    /var/www
125M    /var/tmp
45M     /var/spool

Tìm file lớn trên 500MB

find / -type f -size +500M 2>/dev/null
/var/log/nginx/access.log
/var/lib/mysql/ibdata1
/home/backup/database_backup_old.sql
/tmp/core.12345

Để xem chi tiết hơn với dung lượng:

find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null
-rw-r--r-- 1 root root 2.1G Mar 15 10:30 /var/log/nginx/access.log
-rw-r----- 1 mysql mysql 1.8G Mar 15 14:22 /var/lib/mysql/ibdata1
-rw-r--r-- 1 root root 850M Feb 20 08:15 /home/backup/database_old.sql
-rw------- 1 root root 650M Mar 14 22:45 /tmp/core.9876

Xem thêm: Tìm thư mục lớn trên VPS nhanh chóng với ncdu

Các “thủ phạm” thường gặp

Giám sát uptime VPS

/var/log: log files phình to

Log files là nguyên nhân phổ biến nhất. Những file hay gây vấn đề:

  • access.log / error.log: Nginx/Apache logs
  • syslog: system logs
  • mysql.log: MySQL query logs
  • mail.log: email server logs
  • auth.log: authentication logs

Kiểm tra log files lớn:

du -sh /var/log/* | sort -rh | head -5

/var/lib/mysql: database lớn

MySQL data directory chứa:

  • ibdata1: InnoDB shared tablespace
  • mysql-bin.xxxxx: Binary logs
  • Database folders: chứa .frm, .ibd files

/tmp: temporary files không được dọn

PHP sessions, temporary uploads, core dumps có thể tích lũy trong /tmp.

/home hoặc /var/www: backup cũ, file upload

User directories thường chứa:

  • Database backups cũ
  • File uploads từ web app
  • Source code backups
  • Compressed archives

/var/cache: package cache

APT package cache có thể chiếm vài GB:

du -sh /var/cache/apt/

Core dump files

Khi application crash, có thể tạo core dump files rất lớn:

find / -name "core.*" -type f -exec ls -lh {} \; 2>/dev/null

Dọn dẹp an toàn

So sánh công cụ giám sát VPS

Cấu hình logrotate

Logrotate tự động xoay vòng và nén log files. Kiểm tra cấu hình:

cat /etc/logrotate.conf
ls /etc/logrotate.d/

Tạo cấu hình cho Nginx:

# /etc/logrotate.d/nginx
/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 644 www-data www-data
    sharedscripts
    postrotate
        systemctl reload nginx
    endscript
}

Xoá nội dung log mà không restart service

Thay vì xoá file log (có thể làm service lỗi), hãy xoá nội dung:

# Xoá nội dung nhưng giữ file
truncate -s 0 /var/log/nginx/access.log
truncate -s 0 /var/log/nginx/error.log
truncate -s 0 /var/log/syslog

Hoặc dùng cách khác:

> /var/log/nginx/access.log
echo "" > /var/log/syslog

Giới hạn systemd journal

Systemd journal có thể chiếm nhiều dung lượng. Giới hạn về 100MB:

journalctl --vacuum-size=100M

Cấu hình giới hạn vĩnh viễn trong /etc/systemd/journald.conf:

SystemMaxUse=100M
SystemMaxFileSize=10M

Sau đó restart journald:

systemctl restart systemd-journald

Dọn package cache

# Xoá package cache
apt clean

# Xoá packages không cần thiết apt autoremove

# Xoá packages orphaned apt autoremove --purge

Xoá backup và file tạm cũ

# Tìm và xoá backup cũ hơn 30 ngày
find /home -name "*.sql" -type f -mtime +30 -delete
find /var/www -name "*.tar.gz" -type f -mtime +30 -delete
# Xoá file trong /tmp cũ hơn 7 ngày
find /tmp -type f -mtime +7 -delete

Xoá core dump files

find / -name "core.*" -type f -delete 2>/dev/null

MySQL binary logs

Nếu MySQL binary logging bật, logs có thể tích lũy:

# Xem binary logs hiện tại
mysql -u root -p -e "SHOW BINARY LOGS;"
# Xoá logs cũ hơn 3 ngày
mysql -u root -p -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);"

Phòng ngừa đầy ổ cứng

Cấu hình logrotate cho tất cả services

Đảm bảo mọi service quan trọng đều có logrotate:

# MySQL
/var/log/mysql/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl reload mysql
    endscript
}

Cron job monitor disk usage

Tạo script cảnh báo khi disk usage > 80%:

#!/bin/bash
# /usr/local/bin/disk_monitor.sh

THRESHOLD=80 EMAIL="admin@yourdomain.com"

df -h | grep -vE '^Filesystem|tmpfs|cdrom' | awk '{ print $5 " " $1 }' | while read output; do usage=$(echo $output | awk '{ print $1}' | sed 's/%//g') partition=$(echo $output | awk '{ print $2 }') if [ $usage -ge $THRESHOLD ]; then echo "WARNING: Partition $partition is ${usage}% full" | mail -s "Disk Space Alert" $EMAIL fi done

Thêm vào crontab:

# Kiểm tra mỗi giờ
0 * * * * /usr/local/bin/disk_monitor.sh

Tách partition riêng cho /var

Khi setup VPS mới, nên tách /var ra partition riêng. Điều này giúp:

  • Logs không làm đầy partition gốc
  • Dễ monitor và quản lý
  • Database và web files không ảnh hưởng lẫn nhau

Cấu hình giới hạn log size

Trong /etc/rsyslog.conf hoặc service config:

# Giới hạn size mỗi log file
$RotateSize 100M
$RotateCount 5

Vấn đề inodes đầy

Hiểu về inodes

Inode là cấu trúc dữ liệu lưu metadata của file. Mỗi file/folder cần 1 inode. Khi hết inodes, không tạo được file mới dù còn dung lượng.

Kiểm tra chi tiết inodes

# Xem inode usage của từng thư mục
for i in /*; do echo $i; find $i -xdev -type f | wc -l; done 2>/dev/null

Nguyên nhân hết inodes

  • Session files (PHP, web frameworks)
  • Cache files nhỏ nhiều
  • Log files được split thành nhiều file nhỏ
  • Email queue files

Giải quyết hết inodes

# Tìm thư mục có nhiều file nhất
find / -xdev -printf '%h' 2>/dev/null | sort | uniq -c | sort -k 1 -n

# Xoá session files cũ find /var/lib/php/sessions -type f -mtime +30 -delete

# Xoá cache files find /tmp -type f -name "sess_*" -mtime +1 -delete

Dọn dẹp nâng cao

Docker images và containers

Nếu dùng Docker:

# Xoá containers stopped
docker container prune -f

# Xoá images không dùng docker image prune -a -f

# Xoá volumes không dùng docker volume prune -f

# Xoá everything không dùng docker system prune -a -f

Node.js node_modules

Nếu có nhiều Node.js projects:

find / -name "node_modules" -type d -exec du -sh {} + 2>/dev/null | sort -rh

PHP Composer cache

# Xoá Composer cache
composer clear-cache
# Hoặc xoá thủ công
rm -rf ~/.composer/cache/

Xử lý khẩn cấp khi VPS hoàn toàn đầy

Khi không SSH được

Dùng VNC console hoặc rescue mode từ control panel của nhà cung cấp để đăng nhập vào VPS không qua SSH.

Giải phóng dung lượng khẩn cấp

# Xoá log files lớn nhất ngay lập tức
> /var/log/nginx/access.log
> /var/log/syslog
> /var/log/kern.log

# Dọn /tmp rm -rf /tmp/*

# Dọn package cache apt clean

Kiểm tra processes đang ghi file

# Tìm processes đang ghi dữ liệu nhiều
lsof +L1
iotop -o

Tại sao VPS vẫn báo đầy dù df -h hiện còn dung lượng?

Có thể VPS hết inodes chứ không hết dung lượng. Dùng ‘df -i’ để kiểm tra. Nếu cột IUse% = 100%, cần xoá bớt file nhỏ thay vì file lớn.

Có an toàn khi xoá file log không?

Nên dùng ‘truncate -s 0’ thay vì ‘rm’ để xoá nội dung nhưng giữ file. Cách này không làm service bị lỗi khi ghi log.

Logrotate đã cấu hình nhưng log vẫn không rotate?

Kiểm tra quyền file, format cấu hình logrotate, và chạy test: ‘logrotate -d /etc/logrotate.d/nginx’. Có thể service không reload properly sau khi rotate.

Sau khi dọn xong có cần restart VPS không?

Thường không cần restart. Chỉ restart các service liên quan nếu chúng có vấn đề. Dùng ‘systemctl status’ để kiểm tra tình trạng services.

Làm sao phân biệt file quan trọng và file có thể xoá?

File trong /var/log có thể truncate, file trong /tmp có thể xoá, backup files cũ (.sql, .tar.gz) có thể xoá, core dump files có thể xoá. KHÔNG xoá file trong /etc, /usr, /bin, /sbin. Luôn backup trước khi xoá.

Chia sẻ:
Bài viết đã được kiểm duyệt bởi AZDIGI Team

Về tác giả

Trần Thắng

Trần Thắng

Chuyên gia tại AZDIGI với nhiều năm kinh nghiệm trong lĩnh vực web hosting và quản trị hệ thống.

Hơn 10 năm phục vụ 80.000+ khách hàng

Bắt đầu dự án web của bạn với AZDIGI