Khi VPS bị lỗi full disk (đầy ổ cứng), nguyên nhân chủ yếu đến từ việc các tệp tin log hệ thống phình to, dữ liệu rác trong thư mục /var, hoặc do dữ liệu cache của Docker (overlay2/volumes). Để xử lý triệt để mà không gây mất mát dữ liệu, bạn cần tuân thủ quy trình từ việc xác định chính xác phân vùng bị đầy bằng lệnh df -h, truy tìm file dung lượng lớn bằng lệnh du, và giải phóng file bị treo bởi các tiến trình (deleted files).
Các điểm chính:
- Dùng df -h và du -xhd1 để tìm thủ phạm ngốn dung lượng một cách chính xác.
- Cẩn trọng với lỗi “ảo”: lệnh df báo đầy nhưng du không thấy do các tiến trình (process) đang giữ file.
- Dọn dẹp log an toàn bằng lệnh journalctl thay vì xóa file trực tiếp (rm).
- Sử dụng lệnh docker system prune thận trọng khi dọn dẹp hệ thống container để tránh mất dữ liệu.
Thử tưởng tượng: Nửa đêm, hệ thống giám sát réo còi cảnh báo website hiển thị lỗi “502 Bad Gateway” hoặc MySQL văng thông báo tử thần “No space left on device”. Bạn nhanh chóng SSH vào server và tá hỏa nhận ra dung lượng ổ cứng đã chạm mức 100%.
Trong khoảnh khắc hoảng loạn đó, đừng vội vàng gõ lệnh rm -rf bừa bãi. Việc xóa nhầm file hệ thống hoặc database đang chạy có thể biến một sự cố hết dung lượng thành thảm họa mất hoàn toàn dữ liệu.
Bài viết này, dựa trên kinh nghiệm thực chiến quản trị hàng nghìn máy chủ ảo tại InterData, sẽ cung cấp cho bạn một checklist xử lý sự cố từ mức độ an toàn cơ bản đến “mạnh tay” nhất, giúp hệ thống hoạt động trở lại trong vài phút.
Tại sao VPS lại gặp tình trạng Full Disk (Đầy ổ cứng)?
Nguyên nhân nào khiến ổ cứng VPS Linux cạn kiệt dung lượng nhanh chóng? Dưới đây là 3 thủ phạm phổ biến nhất được ghi nhận qua các hệ thống máy chủ thực tế:
- Sự phình to của Log (Log Bloat): Theo thống kê thực tế, systemd journal có thể ngốn đến 4GB (chiếm khoảng 10% disk mặc định của các gói VPS cơ bản) nếu quản trị viên không thiết lập cấu hình giới hạn định mức lưu trữ ngay từ đầu.
- Ứng dụng lưu trữ & Docker: Nếu bạn đang chạy ứng dụng qua container, các image cũ không sử dụng và thư mục volumes không được dọn dẹp thường chiếm đến 40-50% dung lượng sau khoảng 6 tháng hoạt động liên tục.
- Lỗi tiến trình “Zombie” (Zombie process holding files): Đây là lỗi rất hay gặp. File log lớn đã bị bạn dùng lệnh rm xóa đi, nhưng service (như Nginx, MySQL) chưa được khởi động lại nên tiến trình hệ điều hành chưa giải phóng dung lượng thực tế.
Hướng dẫn 5 bước xử lý lỗi VPS bị Full Disk an toàn
Nguyên tắc cốt lõi: Tìm đúng chỗ – Xóa đúng file – Giải phóng đúng tiến trình.
Bước 1: Làm sao để xác định phân vùng (partition) nào đang bị đầy?
Trước khi xóa bất cứ thứ gì, bạn cần biết chính xác ổ đĩa nào đang kêu cứu. Hãy chạy lệnh sau:
df -h
lsblk -fLệnh df -h (Disk Filesystem – Human readable) sẽ hiển thị danh sách các phân vùng. Dưới đây là ý nghĩa các cột quan trọng bạn cần nắm rõ:
| Cột hiển thị | Ý nghĩa thực tế |
|---|---|
| Size | Tổng dung lượng của phân vùng (VD: 40G). |
| Used / Avail | Dung lượng đã sử dụng / Dung lượng còn trống. |
| Use% | Tỷ lệ phần trăm đã dùng. Nếu cột này báo 100%, đó chính là nguyên nhân gây sập dịch vụ. |
| Mounted on | Điểm mount. Thường phân vùng gốc / (root) là nơi dễ bị đầy nhất. |
Lời khuyên: Nếu bạn thấy chỉ đầy phân vùng / (root), hãy khoanh vùng tìm kiếm tập trung ở các thư mục /var, /home và đường dẫn chứa dữ liệu Docker.
Bước 2: Cách tìm chính xác thư mục hoặc file ngốn dung lượng là gì?
Khi đã xác định được phân vùng bị đầy, tiếp theo ta dùng lệnh du (Disk Usage) để “truy vết” thủ phạm. Hãy quét từ tổng quan đến chi tiết.
Để tìm Top các thư mục chiếm nhiều dung lượng nhất ở ổ root, chạy lệnh:
sudo du -xhd1 / | sort -hGhi chú chuyên môn: Việc thêm tham số -x cực kỳ quan trọng. Nó chỉ đạo lệnh du chỉ quét trên cùng một filesystem hiện tại, giúp bạn tránh “đi lạc” sang các ổ đĩa mount khác hoặc network storage, tiết kiệm rất nhiều thời gian chờ đợi.
Nếu phát hiện /var là nơi chiếm dụng lớn nhất, tiếp tục thu hẹp phạm vi:
sudo du -xhd1 /var | sort -h
Để tìm những file lớn nhất cụ thể trên toàn server (ví dụ top 20 file lớn nhất tại /var). Dưới đây là một mẫu lệnh chuẩn mực thường được các Sysadmin chia sẻ trên StackOverflow:
sudo find /var -type f -exec du -h {} + | sort -hr | head -n 20Bước 3: Giải quyết lỗi “df báo đầy nhưng du không thấy” như thế nào?
Trong quá trình vận hành hệ thống, mình từng gặp trường hợp xóa một file log Nginx nặng 20GB bằng lệnh rm, thư mục trống trơn nhưng ổ cứng vẫn báo full 100%. Đây là bài học xương máu về việc tiến trình (process) vẫn đang ‘mở’ file đó. Dù tên file không còn trên thư mục, nhưng Linux vẫn giữ khối dữ liệu (block) trên ổ cứng vì dịch vụ vẫn đang ghi log vào khoảng không vô hình.
Để kiểm tra các file ẩn (zombie) đang bị treo, hãy chạy lệnh sau:
sudo lsof / | grep deletedHệ thống sẽ liệt kê các tiến trình (kèm theo Process ID – PID) đang giữ các file đã bị báo xóa (deleted).
Để giải phóng dung lượng trong trường hợp này, bạn có 2 cách thực hiện:
Cách 1 (An toàn nhất): Khởi động lại (Restart) dịch vụ đang giữ file đó. Ví dụ nếu Nginx đang giữ file, chỉ cần chạy systemctl restart nginx là dung lượng ổ cứng sẽ lập tức trả về.
Cách 2 (Mạnh tay – Khi không thể restart service): Đôi khi bạn không thể gián đoạn một dịch vụ đang live. Lúc này, hãy can thiệp làm rỗng (truncate) file thông qua File Descriptor (FD) mà không cần xóa nó. Tìm số PID và FD từ lệnh lsof trên, sau đó chạy:
> /proc/<PID>/fd/<FD>Cơ chế: Dấu > sẽ empty (làm rỗng) nội dung file ngay lập tức, giải phóng dung lượng mà không làm crash tiến trình đang chạy.
Bước 4: Xóa systemd journal log phình to bằng cách nào?
Các hệ điều hành Linux hiện đại như Ubuntu, CentOS sử dụng systemd để quản lý log tập trung thông qua journald. Việc tích tụ log có thể chiếm nhiều Gigabyte không cần thiết.
Tuyệt đối không nên vào thư mục /var/log/journal/ để xóa thủ công các file nhị phân bằng lệnh rm, việc này có thể gây lỗi database của journald. Hãy thao tác an toàn theo cách sau.
Đầu tiên, kiểm tra xem journal đang ngốn bao nhiêu dung lượng:
journalctl --disk-usageTiếp theo, dọn dẹp journal log một cách an toàn bằng các lệnh giới hạn (theo tài liệu Systemd docs):
# Chỉ giữ lại 500MB log gần nhất
sudo journalctl --vacuum-size=500M
# Hoặc: Xóa toàn bộ log, chỉ giữ lại log của 10 ngày gần nhất
sudo journalctl --vacuum-time=10dBước 5: Dọn dẹp Docker (images/containers/volumes) ra sao cho an toàn?
Nếu server của bạn chuyên chạy Docker, rác từ các bản build lỗi, containers đã dừng, hoặc dangling images chính là nguyên nhân lớn nhất gây lỗi VPS bị full disk.
Bắt đầu bằng việc kiểm tra cấu trúc lưu trữ của Docker chiếm bao nhiêu dung lượng:
docker system dfĐể dọn rác cơ bản và tương đối an toàn (xóa container đã dừng, network không dùng, dangling images), bạn dùng lệnh:
sudo docker system prune -a -fLưu ý: Cờ -a sẽ xóa cả các images không được tham chiếu bởi bất kỳ container nào, còn cờ -f sẽ bỏ qua bước hỏi xác nhận (Y/N).
Tuyệt đối cẩn trọng với lệnh sau nếu bạn chưa hiểu rõ hệ thống:
sudo docker system prune -a -f --volumesViệc thêm tham số –volumes sẽ xóa vĩnh viễn toàn bộ các volumes lưu trữ không được gắn vào container đang chạy. Điều này đồng nghĩa với việc bạn có thể xóa sổ toàn bộ dữ liệu Database, mã nguồn hoặc hình ảnh tải lên của người dùng nếu cấu hình container bị lỗi hoặc vô tình bị tắt. Đảm bảo 100% bạn đã backup data trước khi thêm cờ volumes.
Đừng để hệ thống ngưng trệ làm mất khách hàng. Đã đến lúc nâng cấp lên hạ tầng máy chủ đời mới, tự động giải quyết các vấn đề thắt cổ chai về lưu trữ và I/O.
- ✓ Ổ cứng NVMe U.2 tốc độ siêu cao
- ✓ Tự động Backup định kỳ, an toàn dữ liệu
- ✓ Control Panel dễ quản trị, full quyền Root
- ✓ Hỗ trợ kỹ thuật chuyên sâu 24/7
Những câu hỏi thường gặp (FAQs) về lỗi VPS đầy ổ cứng
Q1: Có nên dùng lệnh `rm -rf` để dọn dẹp ổ cứng VPS đang bị đầy không?
Trả lời: Không khuyến khích. Việc xóa trực tiếp các file log đang chạy có thể gây ra lỗi treo tiến trình (zombie) như đã đề cập ở Bước 3. Hệ thống vẫn báo full disk. Hãy dùng các lệnh truncate như > filename.log hoặc cấu hình logrotate.
Q2: Làm sao để tự động ngăn chặn VPS bị full disk trong tương lai?
Trả lời: Bạn nên cấu hình logrotate cho các dịch vụ Web/DB, giới hạn thông số SystemMaxUse trong cấu hình /etc/systemd/journald.conf. Đối với môi trường container, hãy tạo một cronjob chạy docker system prune định kỳ hàng tuần.
Q3: Tôi vừa nâng cấp gói VPS thêm dung lượng rồi nhưng VPS vẫn báo đầy?
Trả lời: Đa số các nhà cung cấp cloud khi nâng cấp disk ở cấp độ phần cứng, bạn cần phải chạy thêm các lệnh resize partition trực tiếp trong hệ điều hành (như growpart và resize2fs hoặc xfs_growfs) thì phân vùng mới nhận diện được dung lượng mới.
Q4: Lỗi Inode bị full thì có giống với Disk bị full không?
Trả lời: Khác nhau hoàn toàn. Disk full là hết dung lượng lưu trữ tính bằng Byte. Còn Inode full là bạn hết “số lượng file” được phép tạo trên ổ cứng, thường do hệ thống sinh ra hàng triệu file kích thước cực nhỏ (như file session, cache). Bạn có thể kiểm tra lỗi này bằng lệnh df -i.
