VPS Ubuntu Bị Đầy Ổ Đĩa: Cách Tìm Nguyên Nhân Và Giải Phóng Dung Lượng An Toàn

Một VPS Ubuntu có thể vẫn còn CPU và RAM nhưng website, database hoặc Docker bắt đầu lỗi chỉ vì filesystem đã gần 100%. Khi ổ đĩa đầy, các ứng dụng không thể ghi log, tạo file tạm, cập nhật package hoặc ghi dữ liệu mới.

Sai lầm phổ biến nhất là thấy /var/log lớn rồi chạy lệnh xóa hàng loạt. Cách làm này có thể làm mất dữ liệu cần điều tra, phá cấu trúc log hoặc chỉ giải phóng được rất ít dung lượng vì nguyên nhân thật nằm ở Docker, database, cache hoặc file đã bị xóa nhưng process vẫn giữ handle.

Quy trình an toàn là: xác định filesystem đầy → xác định thư mục lớn → xác định file/process cụ thể → giải phóng có kiểm soát → xử lý nguyên nhân để lỗi không lặp lại.

Dấu hiệu VPS đang hết dung lượng

Các biểu hiện thường gặp:

• website báo lỗi 500 hoặc không ghi được session;
• MySQL/PostgreSQL không khởi động hoặc không ghi thêm dữ liệu;
• apt báo không còn chỗ trống;
• Docker container restart liên tục;
• log có lỗi No space left on device;
• upload file thất bại;
• hệ thống phản hồi chậm bất thường.

Kiểm tra nhanh:

df -h

Quan tâm cột Use% và Mounted on.

Ví dụ:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   48G  2.0G  96% /

Nếu / đã 96%, bạn nên điều tra ngay trước khi filesystem chạm 100%.

Nếu chưa quen các lệnh Linux, có thể xem bài Các lệnh Linux cơ bản cho người mới dùng VPS Ubuntu.

df và du khác nhau thế nào?

df cho biết dung lượng filesystem đang sử dụng:

df -h

du cộng kích thước file/thư mục mà nó nhìn thấy:

sudo du -sh /* 2>/dev/null

Hai số có thể không giống nhau. Nếu df báo đầy nhưng du không tìm thấy đủ dữ liệu, hãy nghĩ tới:

• file đã bị xóa nhưng process vẫn mở;
• filesystem reserved blocks;
• mount point chồng lên thư mục cũ;
• snapshot/layer đặc thù của nền tảng.

Bước 1: tìm thư mục lớn nhất

Bắt đầu từ root:

sudo du -xhd1 / 2>/dev/null | sort -h

Tùy chọn -x giúp không đi sang filesystem khác.

Nếu /var lớn:

sudo du -xhd1 /var 2>/dev/null | sort -h

Nếu /home lớn:

sudo du -xhd1 /home 2>/dev/null | sort -h

Tiếp tục đi sâu cho tới khi xác định được thư mục bất thường.

Các vị trí hay tăng nhanh:

• /var/log — log hệ thống và ứng dụng;
• /var/lib/docker — image, container layer, volume;
• /var/lib/mysql — MySQL data;
• /var/lib/postgresql — PostgreSQL data;
• /var/cache — cache package/ứng dụng;
• /home — backup, upload, source code;
• /tmp — file tạm.

Bước 2: tìm file lớn

Tìm các file lớn hơn 1 GB trong cùng filesystem:

sudo find / -xdev -type f -size +1G -printf '%s %p\n' 2>/dev/null | sort -n

Nếu hệ thống không hỗ trợ -printf như mong đợi, có thể dùng:

sudo find / -xdev -type f -size +1G -ls 2>/dev/null

Đừng xóa file chỉ vì nó lớn. Hãy xác định nó thuộc ứng dụng nào và có thể phục hồi hay không.

Trường hợp 1: systemd journal quá lớn

Kiểm tra dung lượng journal:

journalctl --disk-usage

Xem các log gần đây:

sudo journalctl -p warning --since "24 hours ago"

Nếu journal chiếm quá nhiều, có thể vacuum theo kích thước:

sudo journalctl --vacuum-size=500M

Hoặc theo thời gian:

sudo journalctl --vacuum-time=14d

journalctl --vacuum-* chỉ xóa journal archived cũ theo điều kiện, an toàn hơn nhiều so với tự tay rm file trong /var/log/journal.

Sau đó nên cấu hình giới hạn lâu dài trong /etc/systemd/journald.conf, ví dụ:

SystemMaxUse=1G
RuntimeMaxUse=200M

Sau khi sửa:

sudo systemctl restart systemd-journald

Chọn mức giới hạn phù hợp với dung lượng VPS và yêu cầu lưu log của bạn.

Trường hợp 2: log text trong /var/log tăng bất thường

Kiểm tra:

sudo du -sh /var/log/* 2>/dev/null | sort -h

Nếu một file log rất lớn, đọc phần cuối:

sudo tail -n 100 /var/log/ten-file.log

Mục tiêu là tìm nguyên nhân log spam, ví dụ:

• ứng dụng crash loop;
• bot request liên tục;
• service lỗi cấu hình;
• database lặp cảnh báo;
• firewall hoặc auth log tăng nhanh.

Không nên rm file log đang được service sử dụng nếu chưa hiểu cơ chế rotate.

Với log do logrotate quản lý, kiểm tra:

sudo logrotate -d /etc/logrotate.conf

Tùy chọn -d chỉ debug, không thực hiện rotate thực tế.

Trường hợp 3: Docker chiếm nhiều dung lượng

Nếu /var/lib/docker lớn, kiểm tra:

docker system df

Liệt kê container:

docker ps -a

Liệt kê image:

docker images

Một lệnh dọn phổ biến là:

docker system prune

Lệnh này có thể xóa container đã dừng, network không dùng và dangling image. Hãy đọc kỹ danh sách và xác nhận trước.

Không chạy docker system prune -a --volumes một cách máy móc trên production. Tùy chọn --volumes có thể xóa volume không còn được container tham chiếu, và đó có thể là dữ liệu bạn vẫn cần.

Nếu nguyên nhân là log JSON của container, kiểm tra file lớn:

sudo find /var/lib/docker/containers -name '*-json.log' -size +500M -ls 2>/dev/null

Về lâu dài, cấu hình log rotation cho Docker daemon, ví dụ:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "20m",
    "max-file": "5"
  }
}

Lưu tại /etc/docker/daemon.json, validate JSON trước khi restart Docker. Việc restart Docker có thể ảnh hưởng container, nên thực hiện trong maintenance window.

Nếu bạn đang dùng Docker trên VPS, có thể đọc thêm bài Cài Docker trên VPS Ubuntu.

Trường hợp 4: APT cache và package cũ

Kiểm tra cache:

sudo du -sh /var/cache/apt

Dọn package cache:

sudo apt clean

Dọn dependency không còn cần:

sudo apt autoremove

Hãy đọc danh sách package mà autoremove đề xuất trước khi xác nhận, đặc biệt trên server có driver/kernel/module đặc thù.

Trường hợp 5: file đã xóa nhưng dung lượng chưa được trả lại

Đây là tình huống rất hay gây nhầm lẫn.

Một process đang mở file log 20 GB. Bạn chạy rm file đó. Tên file biến mất khỏi thư mục, nhưng process vẫn giữ file descriptor nên filesystem chưa giải phóng dung lượng.

Kiểm tra file deleted nhưng vẫn được mở:

sudo lsof +L1

Hoặc:

sudo lsof | grep '(deleted)'

Nếu thấy process giữ file rất lớn, cách an toàn thường là restart/reload service tương ứng trong thời điểm phù hợp để process đóng file descriptor.

Ví dụ:

sudo systemctl restart ten-service

Không kill process production tùy tiện chỉ để giải phóng dung lượng. Xác định tác động trước.

Trường hợp 6: inode đầy dù còn GB trống

Filesystem có thể hết inode vì hàng triệu file nhỏ.

Kiểm tra:

df -ih

Nếu IUse% gần 100%, cần tìm thư mục có số lượng file bất thường.

Ví dụ:

sudo find /var -xdev -type f | wc -l

Một số nguyên nhân:

• session file không được dọn;
• mail queue;
• cache ứng dụng;
• build artifact;
• log tách thành vô số file nhỏ.

Giải quyết nguyên nhân sinh file thay vì chỉ xóa một lần.

Trường hợp 7: database chiếm dung lượng

Nếu /var/lib/mysql hoặc /var/lib/postgresql lớn, không xóa trực tiếp file dữ liệu.

Với database, cần xác định:

• database/table nào lớn;
• binary log/WAL có giữ quá lâu không;
• backup có bị lưu nhầm trong data directory không;
• retention đã cấu hình đúng chưa.

Nếu MySQL chậm hoặc tăng dữ liệu nhanh, bài Cài MySQL trên VPS Ubuntu có thể giúp bạn kiểm tra service và cấu trúc trước khi tối ưu sâu hơn.

Trường hợp 8: backup nằm ngay trên cùng ổ hệ thống

Rất nhiều VPS tự backup bằng cách tạo .tar.gz mỗi ngày trong /root/backup hoặc /home/backup nhưng không có retention.

Kiểm tra:

sudo find / -xdev -type f \( -name '*.tar.gz' -o -name '*.zip' -o -name '*.sql' \) -size +500M -ls 2>/dev/null

Backup nằm cùng ổ với dữ liệu gốc không bảo vệ bạn khỏi lỗi ổ đĩa hoặc mất VPS. Nên có bản sao ở storage khác và chính sách retention rõ ràng.

HUONG CLOUD đã có bài về backup VPS bằng Restic nếu bạn muốn xây dựng quy trình backup có phiên bản và đích lưu riêng.

Giải phóng dung lượng theo thứ tự an toàn

Khi filesystem đang rất sát 100%, ưu tiên các bước ít rủi ro:

1. dọn APT cache;
2. vacuum journal archived;
3. xóa file tạm đã xác định rõ;
4. dọn image/container Docker không còn dùng sau khi kiểm tra;
5. xử lý log rotation;
6. xử lý file deleted-but-open bằng restart service có kiểm soát;
7. mở rộng disk nếu dữ liệu hợp lệ thực sự đã vượt capacity.

Không nên bắt đầu bằng lệnh kiểu:

sudo rm -rf /var/log/*

Đây là thao tác nguy hiểm và có thể phá permission, file socket, audit trail hoặc cơ chế logging.

Sau khi dọn, kiểm tra lại

Chạy:

df -h
df -ih

Sau đó xác nhận các service quan trọng:

systemctl --failed

Và kiểm tra website/database/container.

Nếu vừa restart service, xem log gần nhất để chắc chắn hệ thống không tiếp tục tạo log bất thường.

Thiết lập cảnh báo trước khi ổ đầy

Đừng đợi tới 100% mới xử lý.

Các ngưỡng tham khảo vận hành:

• 70–80%: bắt đầu theo dõi xu hướng;
• 85–90%: điều tra và lên kế hoạch dọn/mở rộng;
• trên 95%: rủi ro gián đoạn cao nếu dữ liệu tiếp tục tăng.

Ngưỡng phù hợp phụ thuộc workload. Database lớn có thể cần nhiều free space hơn để compaction, temporary table hoặc migration.

Nếu bạn đã dùng Uptime Kuma, có thể kết hợp thêm công cụ thu metric như Node Exporter/Prometheus để theo dõi disk usage chi tiết theo thời gian. Xem thêm bài Cài Uptime Kuma giám sát VPS và website.

FAQ

Vì sao df báo đầy nhưng du không thấy dữ liệu tương ứng?

Nguyên nhân phổ biến là file đã bị xóa nhưng process vẫn mở. Dùng sudo lsof +L1 để kiểm tra.

Có nên xóa toàn bộ /var/log để lấy dung lượng không?

Không. Nên xác định log nào tăng bất thường, xử lý bằng journal vacuum hoặc logrotate và sửa nguyên nhân sinh log.

docker system prune có an toàn không?

An toàn tương đối nếu bạn hiểu tài nguyên nào sẽ bị xóa. Luôn đọc danh sách trước khi xác nhận và đặc biệt cẩn thận với -a và --volumes.

Ổ đĩa 100% có làm MySQL hỏng không?

Có thể gây lỗi ghi dữ liệu, crash hoặc khiến recovery phức tạp hơn. Nếu database quan trọng, tránh thao tác xóa file data trực tiếp và ưu tiên giải phóng dung lượng ở khu vực ít rủi ro trước.

Dọn xong nhưng vài ngày sau lại đầy thì sao?

Bạn mới xử lý triệu chứng. Cần đo tốc độ tăng, xác định nguồn phát sinh, cấu hình retention/log rotation và thiết lập cảnh báo.

Kết luận

Khi VPS Ubuntu bị đầy ổ đĩa, đừng bắt đầu bằng xóa file hàng loạt. Hãy dùng df để xác định filesystem, du/find để tìm dữ liệu lớn, journalctl cho journal, docker system df cho Docker và lsof +L1 cho file đã xóa nhưng còn mở.

Sau khi giải phóng dung lượng, bước quan trọng hơn là ngăn lỗi lặp lại bằng retention, log rotation, monitoring và backup đúng cách.

Nếu workload của bạn tăng ổn định và dung lượng hợp lệ đã vượt khả năng hiện tại, có thể tham khảo các gói VPS trên HUONG CLOUD để chọn mức tài nguyên phù hợp hơn thay vì liên tục dọn dữ liệu cần thiết.

Nguồn tham khảo

• systemd journalctl manual — vacuum options: https://www.freedesktop.org/software/systemd/man/latest/journalctl.html
• Docker Docs — Configure logging drivers: https://docs.docker.com/engine/logging/configure/
• Docker Docs — json-file logging driver: https://docs.docker.com/engine/logging/drivers/json-file/
• lsof manual: https://man7.org/linux/man-pages/man8/lsof.8.html