Virtualization

Cách xử lý VPS bị full disk hiệu quả trên Linux

BM BizMaC Team Aug 16, 2026 11 phút đọc

SSH vào VPS, gõ lệnh mà báo No space left on device, website trả lỗi 500, database không ghi được dữ liệu. Đây là tình huống mà sysadmin nào cũng gặp ít nhất một lần: ổ đĩa đầy. Nguyên nhân thường không phải do dữ liệu website lớn bất thường, mà là log file phình to, journald tích tụ, hay container Docker chiếm hàng chục GB. Bài này sẽ hướng dẫn bạn quy trình xử lý VPS bị full disk từ chẩn đoán đến dọn dẹp, áp dụng trên Ubuntu 24.04 LTS và Debian 12.

Yêu cầu trước khi bắt đầu

  • VPS chạy Ubuntu 24.04 LTS hoặc Debian 12, có quyền root hoặc user nằm trong group sudo.
  • Truy cập SSH vào VPS. Nếu chưa chắc chắn cách kết nối, bạn có thể tham khảo bài cách đổi port SSH mặc định trên VPS Linux để nắm thao tác cơ bản.
  • Dành ít nhất 15-20 phút để thực hiện các bước dưới đây. Không vội xóa file khi chưa xác định rõ mục đích.

Vì sao VPS nhanh đầy ổ cứng hơn bạn nghĩ?

Ổ đĩa VPS thường có dung lượng không lớn, phổ biến nhất là 20 GB đến 100 GB đối với dòng NVMe. Trong khi đó, chỉ một vài thành phần sau đây đã có thể chiếm hết dung lượng: log hệ thống ghi liên tục, log ứng dụng (Nginx, PHP-FPM, MariaDB), package cache của apt, và quan trọng nhất là Docker nếu bạn chạy container. Journald của systemd cũng là thủ phạm thường bị bỏ quên, mặc định có thể chiếm tới 10% dung lượng phân vùng.

Điều nguy hiểm là khi ổ đĩa đầy, hệ thống không báo lỗi ngay lập tức mà âm thầm ghi lỗi vào log, khiến các dịch vụ chạy sai cách. Nếu bạn đang thuê VPS Linux để chạy website hoặc ứng dụng, việc kiểm tra dung lượng định kỳ là kỹ năng sống còn, không phải việc "khi nào rảnh làm". Bắt đầu xử lý ngay khi phát hiện dấu hiệu bất thường.

Bước 1 - Kiểm tra dung lượng phân vùng

Câu lệnh đầu tiên cần chạy là df -h để xem toàn bộ phân vùng đã sử dụng bao nhiêu phần trăm. Lưu ý dùng cờ -h để hiển thị theo đơn vị GB/MB cho dễ đọc.

df -h

Output mong đợi sẽ có dạng tương tự:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   38G  2.0G  95% /
tmpfs           3.9G     0  3.9G   0% /dev/shm

Nếu cột Use% ở phân vùng / hiển thị từ 90% trở lên, bạn cần hành động ngay. Tiếp theo, dùng df -i để kiểm tra inode, vì hệ thống cũng có thể hết inode do quá nhiều file nhỏ dù dung lượng chưa đầy.

df -i

Nếu cột IUse% đạt rất cao, bạn cần tìm và xóa các thư mục chứa hàng nghìn file nhỏ, ví dụ thư mục cache của PHP hoặc session. Xác định đúng phân vùng và loại hết inode hay hết dung lượng sẽ quyết định hướng xử lý tiếp theo.

Bước 2 - Tìm thư mục và file chiếm nhiều dung lượng nhất

Lệnh du (disk usage) giúp bạn tìm thư mục nào đang "ngốn" nhiều dung lượng. Chạy lệnh sau để liệt kê các thư mục con trong / sắp xếp theo kích thước giảm dần:

sudo du -xh --max-depth=1 / | sort -rh | head -20

Giải thích các cờ: -x giới hạn trong cùng một hệ thống file (không qua các phân vùng mount khác), -h hiển thị đơn vị dễ đọc, --max-depth=1 chỉ liệt kê một cấp thư mục, sort -rh sắp xếp theo dung lượng giảm dần, head -20 lấy 20 dòng đầu. Output sẽ hiện các thư mục như /var/log, /var/lib/docker hay /home với dung lượng lớn nhất.

Đi sâu hơn vào thư mục nghi vấn, ví dụ /var:

sudo du -xh --max-depth=2 /var | sort -rh | head -20

Lặp lại cho đến khi tìm ra file hoặc thư mục cụ thể. Muốn tìm nhanh các file lớn hơn 500 MB trong toàn hệ thống, dùng lệnh find:

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

Kết quả trả về danh sách file kèm kích thước. Cách tiếp cận này an toàn hơn việc đoán mò, giúp bạn xử lý VPS bị full disk đúng trọng tâm, không xóa nhầm dữ liệu quan trọng.

Bước 3 - Dọn dẹp log hệ thống và ứng dụng

Log file là thủ phạm hàng đầu khiến VPS bị full disk. Trước tiên xem dung lượng thư mục log đang chiếm chỗ:

sudo du -sh /var/log

Nếu dung lượng lớn bất thường, hãy xem các file log lớn nhất trong đó:

sudo ls -lhS /var/log/ | head -10

Với các file log cũ có đuôi .gz (đã nén) hoặc file cũ không còn cần thiết, bạn có thể xóa trực tiếp. Tuy nhiên, thay vì xóa tay từng file, cách bền vững là cấu hình logrotate để log tự động xoay vòng và giới hạn dung lượng. File cấu hình mặc định nằm tại /etc/logrotate.conf và các file con trong /etc/logrotate.d/.

Ví dụ tạo file cấu hình cho Nginx tại /etc/logrotate.d/nginx:

sudo nano /etc/logrotate.d/nginx

Nội dung gợi ý cho từng ngày xoay, giữ lại 7 file, nén lại:

/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
}

File log hệ thống đã có cấu hình mặc định nhưng bạn có thể tăng giảm số vòng xoay. Tham khảo bài cấu hình logrotate trên VPS quản lý log hiệu quả để hiểu rõ hơn. Sau khi sửa cấu hình, kiểm tra lại bằng lệnh:

sudo logrotate -d /etc/logrotate.conf

Ở chế độ -d (debug) chỉ hiển thị những gì sẽ làm, chưa thực thi. Khi chắc chắn, bỏ cờ -d để chạy thật. Từ đó log sẽ được xoay vòng tự động, giảm nguy cơ ổ đĩa đầy trở lại.

Bước 4 - Xử lý journald của systemd

Journald là hệ thống ghi log của systemd, lưu tại /var/log/journal/. Giá trị mặc định SystemMaxUse bằng 10% dung lượng phân vùng, trên VPS 40 GB tức là có thể chiếm tới 4 GB. Con số này quá lớn so với nhu cầu thực tế. Kiểm tra dung lượng journal hiện tại:

journalctl --disk-usage

Xóa ngay toàn bộ log journal cũ hơn 3 ngày:

sudo journalctl --vacuum-time=3d

Output hiển thị số dung lượng đã giải phóng. Để giới hạn dung lượng tối đa của journal ở mức 200 MB, sửa file cấu hình:

sudo nano /etc/systemd/journald.conf

Tìm dòng #SystemMaxUse= và đổi thành:

SystemMaxUse=200M

Lưu file và khởi động lại journald:

sudo systemctl restart systemd-journald

Đây là bước quan trọng giúp xử lý VPS bị full disk tận gốc, vì journald nếu không giới hạn sẽ âm thầm "ăn" hết dung lượng trống sau một thời gian dài hoạt động.

Bước 5 - Dọn dẹp Docker nếu bạn dùng container

Nếu VPS của bạn chạy Docker (ví dụ cài n8n, WordPress, hay GitLab bằng container), dung lượng bị chiếm có thể lên tới hàng chục GB từ image, container đã dừng, volume và build cache. Kiểm tra dung lượng Docker đang dùng:

sudo docker system df

Kết quả hiển thị dung lượng của từng loại: images, containers, local volumes, build cache. Để dọn toàn bộ container đã dừng, mạng không dùng, image treo và build cache, chạy:

sudo docker system prune -a --volumes

Cờ -a xóa tất cả image không được container nào sử dụng, --volumes xóa volume không gắn với container nào. Cảnh báo: lệnh này sẽ xóa dữ liệu trong các volume không còn container tham chiếu, hãy kiểm tra kỹ trước khi chạy. Nếu chỉ muốn xóa build cache mà không đụng đến image và container, dùng:

sudo docker builder prune -f

Nếu bạn chạy ứng dụng bằng Docker Compose và muốn kiểm soát dung lượng log của container, thêm cấu hình giới hạn log vào file docker-compose.yml:

services:
  web:
    image: nginx:latest
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Cấu hình trên giới hạn mỗi file log tối đa 10 MB và chỉ giữ 3 file, giúp log container không phình to vô hạn. Bạn có thể tham khảo thêm bài cách cài Docker Compose trên VPS Linux nếu chưa rõ cấu trúc file.

Bước 6 - Dọn package cache và các file tạm

Trên Ubuntu/Debian, apt lưu các package đã tải về trong /var/cache/apt/archives. Sau khi cài đặt xong, chúng không còn cần thiết. Dọn bằng lệnh:

sudo apt clean

Xóa các package cũ không còn dùng nữa (autoremove) giúp gỡ các thư viện phụ thuộc không ai sử dụng:

sudo apt autoremove --purge -y

Các file tạm trong /tmp cũng có thể chiếm chỗ. Xem dung lượng trước:

sudo du -sh /tmp

Nếu lớn, bạn có thể xóa các file cũ hơn 1 ngày trong /tmp (không xóa toàn bộ vì một số ứng dụng đang dùng):

sudo find /tmp -type f -mtime +1 -delete

Đây là các bước an toàn, không ảnh hưởng đến dữ liệu ứng dụng. Sau khi dọn xong, chạy lại df -h để xác nhận dung lượng đã được giải phóng.

Kiểm tra lại sau khi dọn dẹp

Sau khi hoàn tất các bước trên, chạy lại lệnh kiểm tra tổng quan:

df -h

Lúc này cột Use% của phân vùng / sẽ giảm xuống đáng kể. Nếu vẫn còn trên 85%, bạn cần xem lại các thư mục /home hoặc /var/lib để tìm dữ liệu ứng dụng chiếm chỗ, ví dụ database của MariaDB/PostgreSQL nằm trong /var/lib/mysql hoặc /var/lib/postgresql. Với trường hợp database quá lớn, bạn cần cân nhắc nâng cấp gói VPS Linux NVMe có dung lượng lớn hơn thay vì cố xóa dữ liệu.

Nếu VPS của bạn chạy website WordPress, hãy kiểm tra thư mục uploads có thể chứa hàng GB ảnh chưa nén. Kết hợp với việc xử lý log, bạn sẽ có một hệ thống sạch sẽ và bền vững. Đừng quên kiểm tra định kỳ mỗi tuần một lần để phát hiện sớm dấu hiệu bất thường.

Câu hỏi thường gặp

Làm sao để biết file nào đang chiếm nhiều dung lượng nhất trên VPS?

Dùng lệnh sudo du -xh --max-depth=1 / | sort -rh | head -20 để liệt kê các thư mục lớn, sau đó đào sâu từng cấp. Lệnh sudo find / -xdev -type f -size +500M -exec ls -lh {} \; giúp tìm nhanh các file lớn hơn 500 MB trên toàn hệ thống.

Xóa file log trực tiếp có an toàn không?

Xóa file log cũ (đuôi .gz hoặc đã xoay vòng) là an toàn. Tuy nhiên không nên xóa file log đang được ứng dụng ghi, vì tiến trình vẫn giữ file descriptor và dung lượng không được giải phóng ngay. Tốt hơn là dùng logrotate cấu hình xoay vòng và giới hạn số file giữ lại.

Vì sao sau khi xóa file, dung lượng vẫn không tăng?

Nguyên nhân phổ biến là một tiến trình đang giữ file đã xóa. Kiểm tra bằng lệnh sudo lsof | grep deleted để tìm các file đã xóa nhưng vẫn bị tiến trình giữ. Khởi động lại dịch vụ hoặc tiến trình đó sẽ giải phóng dung lượng.

Có nên tắt journald để tiết kiệm dung lượng không?

Không nên, vì journald chứa log quan trọng phục vụ chẩn đoán sự cố. Thay vào đó hãy giới hạn dung lượng tối đa bằng cách đặt SystemMaxUse=200M trong file /etc/systemd/journald.conf.

Docker chiếm bao nhiêu dung lượng là bình thường?

Không có con số cố định. Một image n8n hoặc GitLab có thể nặng từ 1-2 GB, build cache có thể lên tới vài GB. Chạy docker system df để xem chi tiết, và dọn docker builder prune -f định kỳ để tránh cache tích tụ.

Khi nào nên nâng cấp dung lượng VPS thay vì dọn dẹp?

Khi sau khi dọn dẹp toàn bộ mà dung lượng vẫn trên 85% do dữ liệu thật (database, file upload, source code) chiếm chỗ. Lúc này nâng cấp lên gói có dung lượng lớn hơn là giải pháp bền vững, tránh phải xóa dữ liệu cần thiết.

Bài viết liên quan

Lưu ý: Bài viết mang tính tham khảo, tổng hợp kiến thức chung. Mỗi hệ thống, hạ tầng và nhu cầu có đặc thù riêng, nên kiểm thử trong môi trường an toàn và tham vấn kỹ sư trước khi triển khai thực tế.