Khi VPS báo đầy ổ cứng, hãy xác định hệ thống tệp nào đang thiếu chỗ trước khi xóa dữ liệu. Tài liệu GNU Coreutils phân biệt df, công cụ báo dung lượng của hệ thống tệp, với du, công cụ thống kê dung lượng theo thư mục. Ngoài ra, Red Hat lưu ý rằng tệp đã xóa vẫn có thể chiếm chỗ nếu tiến trình còn giữ nó mở. Vì vậy, quy trình dưới đây bắt đầu bằng đo đạc, rồi mới chọn cách dọn phù hợp.

1. Chuẩn bị quyền truy cập và phương án khôi phục

Hướng dẫn dùng cú pháp GNU/Linux; phần journal dành cho máy dùng systemd, phần APT chỉ dành cho hệ thống sử dụng trình quản lý gói này. Trước khi thao tác, hãy chuẩn bị tài khoản có quyền sudo, giữ phiên SSH hiện tại và kiểm tra khả năng truy cập console của nhà cung cấp. Khuyến nghị sao lưu dữ liệu quan trọng ra nơi khác, xác nhận bản sao đọc được và ghi lại những thay đổi dự định thực hiện. Không coi ổ đang đầy là nơi duy nhất lưu bản sao.

Các lệnh dưới đây là hướng dẫn, không phải kết quả đã chạy trên VPS của bạn. Chỉ thực hiện nhánh dọn dẹp khi đã xác định đúng đối tượng. Đặc biệt, đừng dùng lệnh xóa hàng loạt trong thư mục ứng dụng hoặc cơ sở dữ liệu. Với log cần giữ để điều tra sự cố, hãy sao lưu trước: thao tác vacuum của journal sẽ xóa các tệp lưu trữ cũ, không cung cấp chức năng hoàn tác.

Minh họa 1. Chuẩn bị quyền truy cập và phương án khôi phục
Minh họa mục 1: 1. Chuẩn bị quyền truy cập và phương án khôi phục. Không phải ảnh chụp hệ thống thực tế.

2. Xác định hệ thống tệp thiếu dung lượng hoặc inode

Chạy lần lượt:

df -hT

df -i

Theo trang hướng dẫn df của GNU Coreutils, -h hiển thị kích thước dễ đọc, -T bổ sung loại hệ thống tệp và -i chuyển sang thống kê inode. Đối chiếu điểm gắn kết với nơi ứng dụng lưu dữ liệu; có thể dùng df -hT /var để xem hệ thống tệp chứa đường dẫn này. Ghi lại dung lượng khả dụng và lượng inode còn trống làm mốc so sánh sau khi xử lý.

Đọc hai bảng riêng biệt: bảng dung lượng phản ánh các khối lưu trữ, còn bảng inode phản ánh một loại tài nguyên khác của hệ thống tệp. Nếu inode gần cạn, hãy chuyển sang thống kê inode theo thư mục ở bước tiếp theo thay vì chỉ tìm tệp lớn. Đây là bước chỉ đọc; không cần khôi phục cấu hình. Trước khi tiếp tục, cần xác định được chính xác điểm gắn kết đang có vấn đề.

Minh họa 2. Xác định hệ thống tệp thiếu dung lượng hoặc inode
Minh họa mục 2: 2. Xác định hệ thống tệp thiếu dung lượng hoặc inode. Không phải ảnh chụp hệ thống thực tế.

3. Khoanh vùng thư mục chiếm nhiều tài nguyên

Nếu hệ thống tệp gốc là nơi cần kiểm tra, chạy:

sudo du -xhd1 /

Nếu /var là điểm gắn kết riêng đang đầy, thay đường dẫn bằng /var. Tài liệu du giải thích -x bỏ qua thư mục nằm trên hệ thống tệp khác, -h hiển thị kích thước dễ đọc và -d1 giới hạn độ sâu hiển thị. Sau khi thấy nhánh lớn, lặp lại lệnh với chính đường dẫn đó, chẳng hạn sudo du -xhd1 /var.

Với nhánh kiểm tra inode, dùng:

sudo du --inodes -x -d1 /var

Thay /var bằng đường dẫn đã xác định ở bước 2. Mục tiêu là tìm thư mục cần kiểm tra tiếp, không tự động kết luận rằng nó có thể xóa. Chẳng hạn, nếu dữ liệu ứng dụng chiếm phần lớn, hãy tra chính sách lưu trữ của ứng dụng trước. Không bỏ qua thông báo lỗi quyền truy cập rồi coi tổng thống kê là đầy đủ.

Minh họa 3. Khoanh vùng thư mục chiếm nhiều tài nguyên
Minh họa mục 3: 3. Khoanh vùng thư mục chiếm nhiều tài nguyên. Không phải ảnh chụp hệ thống thực tế.

4. Kiểm tra tệp đã xóa nhưng tiến trình còn giữ mở

Nếu đã xóa tệp mà dung lượng chưa giảm, kiểm tra bằng lsof khi công cụ này có sẵn:

sudo lsof +L1

Tài liệu lsof xác định +L1 là bộ lọc tệp đang mở đã bị gỡ liên kết. Đối chiếu tên tiến trình, PID và đường dẫn hoặc thiết bị với hệ thống tệp đang đầy. Theo tài liệu unlink của Linux, tệp mất liên kết cuối cùng nhưng còn được mở sẽ tồn tại đến khi bộ mô tả tệp cuối cùng đóng.

Red Hat khuyến nghị đóng tiến trình liên quan một cách có kiểm soát để giải phóng phần dung lượng này. Trước khi làm, xác định đúng dịch vụ và chuẩn bị khoảng gián đoạn phù hợp; tránh khởi động lại hàng loạt hoặc tác động vào SSH đang dùng. Sau đó chạy lại lsof và df để kiểm chứng. Không áp dụng thủ thuật cắt tệp qua /proc nếu chưa hiểu tác động: Red Hat cảnh báo cách này có thể khiến ứng dụng hoạt động không nhất quán.

Minh họa 4. Kiểm tra tệp đã xóa nhưng tiến trình còn giữ mở
Minh họa mục 4: 4. Kiểm tra tệp đã xóa nhưng tiến trình còn giữ mở. Không phải ảnh chụp hệ thống thực tế.

5. Dọn cache gói APT nếu đó là nguồn chiếm chỗ

Chỉ thực hiện bước này trên máy dùng APT. Đo trước bằng:

sudo du -sh /var/cache/apt/archives

Nếu quyết định bỏ các gói tải về đang lưu cục bộ, chạy sudo apt-get clean. Theo Debian, clean dọn kho tệp gói đã tải xuống trong thư mục archives và partial, giữ lại tệp khóa. Có thể chọn sudo apt-get autoclean thay thế nếu chỉ muốn dọn các tệp gói không còn tải được từ nguồn.

Đo lại cùng thư mục và chạy df trên hệ thống tệp tương ứng. Phân biệt thao tác này với autoremove: Debian mô tả autoremove là gỡ những gói được cài tự động nhưng không còn cần thiết. Vì vậy, không thêm autoremove vào chuỗi lệnh dọn cache theo thói quen. Nếu cần giữ bộ cài để phục hồi ngoại tuyến, hãy sao lưu chúng trước; clean không có thao tác khôi phục cache đã xóa.

Minh họa 5. Dọn cache gói APT nếu đó là nguồn chiếm chỗ
Minh họa mục 5: 5. Dọn cache gói APT nếu đó là nguồn chiếm chỗ. Không phải ảnh chụp hệ thống thực tế.

6. Thu gọn journal sau khi quyết định thời gian lưu log

Với máy dùng systemd, đo journal bằng:

sudo journalctl --disk-usage

Nếu đã lưu riêng log cần thiết và chấp nhận xóa lịch sử cũ, ví dụ thu gọn phần lưu trữ về dưới 200M bằng:

sudo journalctl --rotate --vacuum-size=200M

200M là giá trị minh họa, cần chọn theo nhu cầu điều tra và dung lượng thực tế. Tài liệu systemd cho biết rotate chuyển tệp đang hoạt động sang lưu trữ trước khi vacuum xử lý chúng.

Chạy lại journalctl --disk-usage để kiểm tra. Không kết luận lệnh thất bại chỉ vì tổng vẫn vượt 200M: phép đo gồm cả journal đang hoạt động, trong khi vacuum chỉ xóa journal lưu trữ. Việc xóa lịch sử không thể hoàn tác bằng cách đổi lại tham số; muốn đọc lại phải có bản sao giữ từ trước. Bước này cũng không đại diện cho việc dọn mọi loại log của ứng dụng.

Minh họa 6. Thu gọn journal sau khi quyết định thời gian lưu log
Minh họa mục 6: 6. Thu gọn journal sau khi quyết định thời gian lưu log. Không phải ảnh chụp hệ thống thực tế.

7. Đặt giới hạn journal và kiểm chứng sau dọn

Để kiểm soát journal lưu bền vững, cân nhắc một tệp cấu hình riêng tại /etc/systemd/journald.conf.d/90-storage-limit.conf với nội dung minh họa:

[Journal]

SystemMaxUse=300M

SystemKeepFree=1G

Theo tài liệu journald.conf, hai tùy chọn lần lượt giới hạn dung lượng journal và đặt mức cần chừa cho mục đích khác; journald tuân theo ràng buộc chặt hơn. Chúng áp dụng cho journal lưu bền vững, còn journal trong /run dùng các tùy chọn Runtime tương ứng.

Sao lưu cấu hình hiện có và đối chiếu cấu hình ghi đè trước khi áp dụng theo quy trình systemd của bản phân phối. Nếu cần hoàn tác, khôi phục tệp cũ hoặc gỡ đúng tệp vừa tạo rồi áp dụng lại; thao tác này không phục hồi log đã bị xóa. Cuối cùng, chạy lại df -hT, df -i và phép đo thư mục ban đầu. Nên lưu các mốc đo để theo dõi: mục tiêu kiểm chứng là tài nguyên khả dụng tăng trên đúng hệ thống tệp và ứng dụng vẫn hoạt động theo kiểm tra của người quản trị.

Minh họa 7. Đặt giới hạn journal và kiểm chứng sau dọn
Minh họa mục 7: 7. Đặt giới hạn journal và kiểm chứng sau dọn. Không phải ảnh chụp hệ thống thực tế.

Nguồn tham khảo

manpages.debian.org (5 tài liệu)
man7.org (4 tài liệu)
access.redhat.com (1 tài liệu)
debian.org (1 tài liệu)
freedesktop.org (2 tài liệu)