- Xử lý VPS bị full disk/inode: chẩn đoán và dọn dẹp an toàn
- Vps full disk: 1. Phân biệt full disk và full inode: hai bệnh, một triệu chứng
- Vps full disk: 2. Chẩn đoán full disk: tìm "thủ phạm" ngốn dung lượng
- Vps full disk: 3. Chẩn đoán full inode: đếm file thay vì đo dung lượng
- 4. Dọn dẹp an toàn nhóm 1: cache và file tạm của hệ thống
- 5. Dọn dẹp an toàn nhóm 2: log của web server và database
- 6. Xử lý full inode: dọn session, cache nhỏ và mail spool
- 7. Khi dọn dẹp không đủ: nâng cấp ổ đĩa và kiến trúc lại
- 8. Phòng ngừa: để không bao giờ phải cấp cứu lúc 2 giờ sáng
- 9. Checklist xử lý nhanh khi VPS báo hết dung lượng
- Kết luận
- Câu hỏi thường gặp
Xử lý VPS bị full disk/inode: chẩn đoán và dọn dẹp an toàn
Website đột nhiên báo lỗi 500, không upload được file, database không ghi được dữ liệu mới — nhưng kiểm tra thì ổ cứng... vẫn còn trống hàng GB? Rất có thể VPS của bạn đang gặp tình trạng VPS full disk hoặc cạn kiệt inode, hai "căn bệnh" phổ biến nhất khiến máy chủ Linux "đứng hình" dù nhìn qua tưởng vẫn còn tài nguyên. Bài viết này hướng dẫn bạn chẩn đoán chính xác và dọn dẹp an toàn từng bước.
Vps full disk: 1. Phân biệt full disk và full inode: hai bệnh, một triệu chứng
Điều khiến nhiều người bối rối là cả hai tình trạng đều báo cùng một lỗi: No space left on device. Nhưng bản chất hoàn toàn khác nhau, và cách chữa cũng khác nhau.
- Định nghĩa nhanh: Full disk là hết dung lượng vật lý (ổ cứng đầy 100%, thường do backup/log lớn). Full inode là hết chỉ mục quản lý file (mỗi file tốn 1 inode) — không tạo file mới được dù ổ cứng còn trống.
- Triệu chứng full disk:
df -hbáoUse%đạt 100% ở phân vùng/. - Triệu chứng full inode:
df -hbáo còn trống nhiều nhưngdf -ibáoIUse%đạt 100%. - Vì sao phải phân biệt: Dọn dẹp sai hướng (xóa file lớn trong khi bệnh là full inode) sẽ không giải quyết được gì mà còn có nguy cơ xóa nhầm dữ liệu quan trọng.
Vps full disk: 2. Chẩn đoán full disk: tìm "thủ phạm" ngốn dung lượng
Khi đã xác định df -h báo đầy, bước tiếp theo là tìm ra thư mục hoặc file nào đang chiếm nhiều dung lượng nhất. Lệnh du (disk usage) là công cụ đắc lực nhất cho việc này.
Bắt đầu từ thư mục gốc để có bức tranh tổng thể:
du -sh /* 2>/dev/null | sort -rh | head -n 10
Lệnh này liệt kê 10 thư mục "nặng" nhất ở cấp gốc. Thông thường /var (log, database, mail) hoặc /home (dữ liệu website, backup) sẽ là nghi phạm hàng đầu. Khi đã khoanh vùng được thư mục, đào sâu thêm một cấp:
du -sh /var/* 2>/dev/null | sort -rh | head -n 10
- Tìm file đơn lẻ dung lượng lớn: Đôi khi thủ phạm là một vài file backup
.tar.gzbị quên. Lệnhfind / -type f -size +500M -exec ls -lh {} \;sẽ lôi chúng ra ánh sáng. - Kiểm tra file đã xóa nhưng vẫn bị giữ: Nếu tiến trình đang ghi vào file log mà bạn xóa file đó, dung lượng chưa được giải phóng. Dùng
lsof | grep deletedđể phát hiện, rồi khởi động lại dịch vụ liên quan. - Đừng vội xóa: Giai đoạn chẩn đoán chỉ để "nhìn", chưa "chạm". Ghi lại danh sách các vị trí nặng nhất trước khi quyết định dọn dẹp ở các bước sau.

Vps full disk: 3. Chẩn đoán full inode: đếm file thay vì đo dung lượng
Với full inode, du không giúp ích nhiều vì vấn đề không phải dung lượng mà là số lượng file. Bạn cần các lệnh "đếm" thay vì "đo".
Lệnh cơ bản nhất để xem tình trạng inode từng phân vùng:
df -ih
(Cờ -i hiển thị thông tin inode, -h hiển thị số lượng dạng dễ đọc như K, M.) Chú ý các cột Inodes (tổng số), IUsed (đã dùng), IFree (còn trống) và IUse% (tỷ lệ đã dùng). Phân vùng / báo 100% là lúc hệ thống chặn tạo file mới.
- Tìm thư mục "đẻ" nhiều file nhất: Đếm số file trong các thư mục nghi vấn để tìm "thủ phạm" ngốn inode.
- Nghi phạm kinh điển: session PHP hết hạn không được dọn (đặc biệt khi garbage collector của PHP không chạy đúng), cache ứng dụng sinh hàng triệu file nhỏ, mail queue/spool tồn đọng, log rotate hỏng tạo vô số file log nhỏ.
- Kiểm tra file ẩn: Đừng quên các file ẩn (bắt đầu bằng dấu chấm) và thư mục tạm
/tmp,/var/tmp— nơi nhiều ứng dụng "xả rác" mà không tự dọn.
4. Dọn dẹp an toàn nhóm 1: cache và file tạm của hệ thống
Đây là nhóm dọn dẹp an toàn nhất, gần như không có rủi ro mất dữ liệu nếu làm đúng. Hãy bắt đầu từ đây trước khi đụng đến bất kỳ thứ gì khác.
Dọn cache của trình quản lý gói: Mỗi lần cài đặt phần mềm, Ubuntu/Debian lưu file .deb vào cache, CentOS/AlmaLinux lưu .rpm. Xóa chúng rất an toàn:
apt-get clean
apt-get autoremove -y
(hoặc yum clean all trên CentOS/AlmaLinux). Lệnh autoremove còn gỡ các gói phụ thuộc không còn cần thiết.
- Dọn journal log của systemd: Journald có thể phình tới vài GB. Giới hạn chỉ giữ log 3 ngày gần nhất:
journalctl --vacuum-time=3d, hoặc giới hạn tổng dung lượng 100MB:journalctl --vacuum-size=100M. - Dọn thư mục tạm: Xóa file cũ trong
/tmpvà/var/tmp(chỉ xóa file cũ hơn vài ngày, tránh lúc hệ thống đang chạy tác vụ quan trọng):find /tmp -type f -atime +7 -delete. - Dọn cache ứng dụng đúng cách: Dùng công cụ của chính ứng dụng (ví dụ lệnh clear cache của framework) thay vì
rm -rfthủ công.
5. Dọn dẹp an toàn nhóm 2: log của web server và database
Log là "thủ phạm" phổ biến nhất gây full disk trên VPS chạy website, đặc biệt sau các đợt traffic tăng đột biến hoặc khi website bị bot quét liên tục khiến access log phình to trong vài giờ.
- Log web server (Nginx/Apache): access log và error log nằm trong
/var/log/nginxhoặc/var/log/apache2. Đừngrmtrực tiếp file đang được ghi — hãy làm trống bằngtruncate -s 0hoặc cấu hình logrotate để tự xoay vòng. - Log MySQL/MariaDB: Binary log và slow query log có thể chiếm hàng chục GB. Kiểm tra và cấu hình thời gian lưu binary log hợp lý (ví dụ 7 ngày), purge các bản cũ sau khi đã đảm bảo backup đầy đủ.
- Log PHP-FPM và ứng dụng: Các file log của PHP, Laravel, Node.js trong
/var/loghoặc thư mục ứng dụng cũng cần được xoay vòng — nhiều framework có cơ chế log rotation tích hợp, hãy bật nó lên. - Đừng xóa log khi đang điều tra sự cố: Nếu VPS đầy disk ngay sau sự cố bảo mật, log là bằng chứng quý giá. Sao lưu log ra nơi khác trước khi dọn, hoặc giữ lại log 24–48 giờ gần nhất.
6. Xử lý full inode: dọn session, cache nhỏ và mail spool
Dọn full inode đòi hỏi sự cẩn thận cao hơn vì bạn sẽ xóa hàng loạt file — chỉ cần sai một đường dẫn là có thể xóa nhầm dữ liệu quan trọng.
- Session PHP hết hạn (nguyên nhân số 1): tùy panel mà session nằm ở vị trí khác nhau (ví dụ
/var/lib/php/sessionsvới PHP-FPM). Xóa file session cũ hơn 2 ngày:find <đường-dẫn> -name 'sess_*' -mtime +2 -delete. - Cache ứng dụng: Một số plugin/cache sinh hàng triệu file nhỏ. Dùng chức năng clear cache của chính ứng dụng/plugin thay vì xóa thủ công — an toàn hơn và đảm bảo ứng dụng tái tạo cache đúng cách.
- Mail spool tồn đọng: Nếu VPS gửi mail, hàng đợi có thể tích tụ hàng nghìn email không gửi được. Kiểm tra bằng
postqueue -p(Postfix), xóa mail rác/bounce cũ sau khi xác nhận. - Xóa hàng loạt file hiệu quả: Với thư mục chứa hàng trăm nghìn file, lệnh
rm *có thể báo lỗi "argument list too long". Dùngfind ... -deletethay thế — vừa hiệu quả vừa tránh lỗi.
7. Khi dọn dẹp không đủ: nâng cấp ổ đĩa và kiến trúc lại
Có những trường hợp dọn dẹp chỉ là giải pháp tạm thời: database tăng trưởng đều đặn mỗi tháng, website thêm hàng nghìn sản phẩm với ảnh chất lượng cao, hoặc log bắt buộc phải lưu dài ngày theo yêu cầu tuân thủ. Khi đó, "dọn" mãi không phải là đáp án — cần nâng cấp.
- Nâng cấp ổ đĩa trực tiếp: mua thêm SSD gắn vào máy chủ mà không cần cài lại hệ điều hành. VPS SunCloud nâng cấp linh hoạt từ 50GB đến 3TB (giá tham khảo tại thời điểm viết, xem giá mới nhất tại suncloud.vn).
- Tách dữ liệu ra ổ riêng: Gắn thêm ổ đĩa và chuyển thư mục nặng (như
/var/lib/mysqlhoặc thư mục upload) sang ổ mới — vừa tăng dung lượng vừa cải thiện I/O vì tải được phân tán. - Dùng object storage cho file tĩnh: Ảnh, video, file download nên đưa lên object storage (như Sun Drive) thay vì để trên ổ đĩa VPS — giảm áp lực cả về dung lượng lẫn inode, lại dễ mở rộng không giới hạn.
- Kiến trúc lại khi đến ngưỡng: Nếu VPS phải nâng cấp liên tục, hãy cân nhắc tách database ra máy chủ riêng hoặc chuyển sang Cloud Server linh hoạt hơn, thay vì "vá" từng chỗ.
8. Phòng ngừa: để không bao giờ phải cấp cứu lúc 2 giờ sáng
Ca cấp cứu nào cũng có thể phòng tránh được bằng vài biện pháp đơn giản thiết lập một lần và hưởng lợi mãi mãi.
- Giám sát và cảnh báo sớm: thiết lập cảnh báo tự động khi
Use%hoặcIUse%vượt 80% — bằng cron script gửi qua Telegram/email hoặc công cụ giám sát tích hợp trong portal của nhà cung cấp. - Tự động hóa dọn dẹp định kỳ: Đưa các lệnh dọn an toàn vào cron chạy hàng tuần:
apt-get clean,journalctl --vacuum-time=7d, xóa file trong/tmpcũ hơn 7 ngày, xoay vòng log. - Cấu hình logrotate ngay khi dựng máy: Đừng đợi đến khi đầy disk mới nhớ ra. Mọi VPS mới đều nên có logrotate cho web server, database và ứng dụng ngay từ ngày đầu.
- Backup trước khi dọn dẹp mạo hiểm: Với các thao tác xóa hàng loạt, hãy đảm bảo có bản backup gần nhất. SunCloud backup tự động hàng tuần cho Cloud Server và VPS — "lưới an toàn" cho mọi ca dọn dẹp.
9. Checklist xử lý nhanh khi VPS báo hết dung lượng
Khi sự cố đang diễn ra và website đã sập, bạn cần một quy trình nhanh gọn thay vì đọc cả bài hướng dẫn dài. Dưới đây là checklist xử lý trong 15 phút.
- Checklist 15 phút: Phút 0–3: chạy
df -h/df -ixác định bệnh. Phút 3–8: dùngdu/đếm file khoanh vùng. Phút 8–13: dọn cache, journal log, file tạm. Phút 13–15: kiểm tra lại, khởi động lại dịch vụ, xác minh website. - Nếu website chưa lên: kiểm tra log lỗi của web server và database — có thể dịch vụ cần khởi động lại thủ công sau khi hết disk, hoặc có vấn đề khác ngoài dung lượng.
- Ghi lại toàn bộ quá trình: lưu lại các lệnh đã chạy và kết quả — vừa để rút kinh nghiệm, vừa để báo cáo nếu cần hỗ trợ từ nhà cung cấp.
- Khi vượt quá khả năng: đừng ngần ngại gọi hỗ trợ kỹ thuật của nhà cung cấp. Đội ngũ SunCloud trực 24/7/365 qua hotline 083 979 3434 có thể hỗ trợ chẩn đoán và xử lý sự cố kịp thời.
| Tình trạng | Lệnh chẩn đoán | Dấu hiệu | Hướng xử lý |
|---|---|---|---|
| Full disk | df -h |
Cột Use% đạt 100% |
Tìm file/thư mục lớn bằng du, dọn log, cache, file tạm |
| Full inode | df -i |
IUse% 100% dù Use% còn thấp |
Dọn session PHP, cache nhỏ, mail spool tồn đọng |
| File đã xóa vẫn chiếm chỗ | lsof \| grep deleted |
du và df chênh lệch lớn |
Khởi động lại dịch vụ đang giữ file |

Kết luận
Xử lý VPS full disk hay full inode không khó nếu đi đúng trình tự: chẩn đoán bằng df -h/df -i trước, khoanh vùng bằng du hoặc đếm file, dọn từ nhóm an toàn nhất (cache, file tạm, log đã xoay vòng) rồi mới đến nhóm nhạy cảm — và luôn backup trước khi xóa hàng loạt. Quan trọng không kém là giám sát cảnh báo ở ngưỡng 80% và tự động dọn dẹp định kỳ.
Nếu VPS của bạn thường xuyên "kêu cứu" vì hết dung lượng, có lẽ đã đến lúc nâng cấp cấu hình hoặc tách dữ liệu ra lưu trữ chuyên biệt. Liên hệ SunCloud qua hotline 083 979 3434 hoặc suncloud.vn để được tư vấn gói VPS/Cloud Server SSD Enterprise mở rộng linh hoạt, backup tự động hàng tuần, hỗ trợ 24/7/365.
Câu hỏi thường gặp
Vì sao df -h báo còn trống mà hệ thống vẫn báo hết dung lượng?
Đây là dấu hiệu full inode: df -h đo dung lượng còn trống, nhưng hệ thống đã cạn inode. Chạy df -i kiểm tra — nếu IUse% đạt 100%, hãy dọn bớt số lượng file (session, cache nhỏ, mail spool).
Xóa file log đang được ghi có giải phóng dung lượng ngay không?
Không, nếu tiến trình vẫn giữ file đó mở. Trên Linux, dung lượng chỉ được giải phóng khi tiến trình đóng file.
Dọn dẹp session PHP có làm người dùng bị đăng xuất không?
Có thể. Xóa file session sẽ khiến người dùng đang đăng nhập bị đăng xuất và phải đăng nhập lại.
Bao lâu nên dọn dẹp VPS một lần?
Tác vụ an toàn (cache package, journal log, file tạm) nên tự động chạy hàng tuần bằng cron. Với log và session, tần suất tùy lưu lượng website — traffic cao có thể cần dọn vài ngày một lần.
Nâng cấp ổ đĩa VPS có mất dữ liệu không?
Thông thường không. Việc mở rộng ổ đĩa trên nền tảng ảo hóa hiện đại diễn ra trực tuyến mà không cần cài lại hệ điều hành hay di chuyển dữ liệu.
Inode có thể tăng được không?
Inode được cấp khi tạo hệ thống file và thường không tăng trực tiếp được. Giải pháp: dọn bớt file rác, hoặc tạo lại phân vùng với mật độ inode cao hơn (cần lên kế hoạch di chuyển dữ liệu).









