Checklist bảo trì server Linux hằng tuần, hằng tháng

Bảo trì server Linux thực sự là gì

Bảo trì server Linux là một danh sách ngắn các bước kiểm tra được thực hiện theo lịch cố định, không phải một dự án có điểm kết thúc. Hằng tuần, bạn xác nhận các bản cập nhật đã được cài đặt, disk còn đủ chỗ trống, không có service nào bị dừng và job backup đã hoàn tất. Hằng tháng, bạn kiểm tra việc restore, kiểm tra thời hạn chứng chỉ, audit account và key, đồng thời xóa kernel và log cũ. Mỗi khi distribution phát hành phiên bản mới, bạn lên kế hoạch upgrade phiên bản và thực hiện lần reboot mà bạn vẫn trì hoãn.

Build server là một công việc khác, và 10 phút đầu tiên trên một VPS mới trình bày phần đó. Trang này nói về năm tiếp theo. Mỗi mục bên dưới đều nêu rõ lỗi mà bước kiểm tra đó ngăn chặn, vì một checklist không cho biết hậu quả là checklist mà mọi người sẽ âm thầm ngừng chạy.

Các command ở đây chỉ mang tính minh họa và nên được đọc trước khi chạy. Hãy đối chiếu output với server của bạn, vì giá trị được xem là ổn định của dung lượng trống hoặc số lượng process phụ thuộc vào chức năng của máy. Khi một bước kiểm tra khác nhau giữa các distribution, nội dung sẽ nói rõ. Các ví dụ dùng Debian và Ubuntu với apt. Trên họ RHEL, tooling là dnf và một số path sẽ khác.

Cách chọn lịch bảo trì Linux server mà bạn có thể duy trì

Kiểm tra hằng tuần bao quát những thứ tự thay đổi mà không cần bạn can thiệp: package, mức sử dụng disk, trạng thái service và các job đã lập lịch. Những thứ này tự thay đổi, nên một tuần là khoảng thời gian dài nhất bạn có thể để chúng không được kiểm tra.

Kiểm tra hằng tháng bao quát các vấn đề xuống cấp chậm: chứng chỉ sắp hết hạn, các account chưa được xóa và kernel tích tụ trong /boot, cùng các file log tăng vượt quy tắc rotation đã không còn khớp. Không vấn đề nào trong số này chắc chắn gây lỗi vào ngày mai. Nhưng cuối cùng tất cả đều sẽ gây lỗi.

Kiểm tra theo release phụ thuộc vào lịch phát hành. Một release của distribution là hạng mục bảo trì duy nhất có deadline bên ngoài, vì thời hạn hỗ trợ cho version hiện tại sẽ kết thúc dù bạn đã sẵn sàng hay chưa.

Đặt lịch chạy vào một khung giờ cố định: sáng thứ Hai cho lần kiểm tra hằng tuần và ngày đầu tiên của tháng cho lần kiểm tra hằng tháng. Chạy checklist “khi nào rảnh” không phải là checklist. Khi quản lý nhiều hơn một vài máy, hãy chạy các kiểm tra này từ một nơi thay vì thực hiện thủ công; đó là nội dung của quản lý nhiều Linux server từ một nơi.

Hàng tuần: các bản cập nhật có thực sự được cài đặt không?

Bật unattended-upgrades không đồng nghĩa với việc biết nó đã chạy. Service có thể bị mask, cấu hình có thể chỉ giới hạn ở một origin mà bạn không sử dụng, và một package bị giữ lại có thể làm hỏng mọi lần chạy sau đó. Cách cài đặt được trình bày trong cập nhật bảo mật tự động trên Ubuntu. Công việc hằng tuần là xác minh những gì bạn đã cài đặt thực sự hoạt động.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable là thước đo chính xác, vì nó báo cáo trạng thái hiện tại thay vì ý định cấu hình. Nếu các bản cập nhật bảo mật vẫn nằm trong danh sách đó, automation không hoạt động đúng. Hãy đọc log trước khi cho rằng máy đã được cập nhật. Một package bị ghim bằng apt-mark hold sẽ luôn bị bỏ qua và không báo cáo gì. Vì vậy, hãy kiểm tra apt-mark showhold trong cùng lượt này.

Sự cố được ngăn chặn: chạy một package đã biết có lỗ hổng trong nhiều tháng vì tin rằng các bản cập nhật đã được thực hiện tự động.

Hàng tuần: dung lượng trống của disk và inode

Filesystem root đầy có thể làm hỏng những thứ tưởng như không liên quan đến disk. Database từ chối ghi, việc ghi log dừng lại, quá trình nâng cấp package dừng ở trạng thái cấu hình dở dang, và trên một số hệ thống bạn không thể mở session mới vì hệ thống không ghi được các file của chính nó.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i là phần mà hầu hết mọi người bỏ qua. Inode là các cấu trúc có số lượng cố định dùng để lưu metadata của file. Filesystem có thể hết inode trong khi df -h vẫn báo còn trống hàng gigabyte. Khi đó thao tác ghi sẽ thất bại với No space left on device dù kết quả hiển thị vẫn còn dung lượng trống. Lần đầu gặp lỗi này thường mất cả giờ để tìm nguyên nhân. Hàng triệu file nhỏ, chẳng hạn do mail queue bị kẹt hoặc thư mục session không được dọn dẹp, là nguyên nhân phổ biến.

du -xh chỉ hoạt động trên một filesystem, đúng với nhu cầu trên máy chủ có bind mount hoặc storage gắn ngoài. Trên Docker host, nguyên nhân thường nằm ở image layer và volume không còn dùng. Có thể dọn chúng như mô tả trong dọn dung lượng Docker trên VPS.

Dung lượng trống cho biết capacity. Storage bên dưới có thể hỏng theo lịch riêng, nên cần kiểm tra riêng như mô tả trong monitoring tình trạng disk trên VPS.

Hàng tuần: Có gì đã dừng mà không báo cho bạn?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Một unit bị crash và chạm giới hạn restart sẽ ở trạng thái failed và cứ nằm đó mà không báo. Không có email nào thông báo cho bạn. list-timers hữu ích hơn ở chỗ này: lệnh cho biết thời điểm mỗi timer chạy lần cuối và thời điểm chạy tiếp theo. Vì vậy, nếu giá trị LAST cũ hơn chính khoảng thời gian của timer, job đó đã không chạy.

Hãy đọc journal của unit trước khi restart bằng journalctl -u <unit> -n 100 --no-pager. Restart chỉ xóa triệu chứng. Sau đó bạn sẽ không có lý do để kiểm tra lại cho đến khi lỗi tương tự xảy ra vào thời điểm tệ hơn.

Lỗi mà cách này giúp ngăn chặn: một monitoring agent, queue worker hoặc backup service đã ngừng hoạt động từ một memory spike xảy ra 3 tuần trước.

Hàng tuần: job backup có thực sự hoàn tất không?

Backup được lên lịch và backup đã hoàn tất là hai việc khác nhau. Chỉ backup đã hoàn tất mới có thể dùng để khôi phục. Hãy kiểm tra trạng thái hoàn tất.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

Hãy xác nhận hai điều. Lần chạy gần nhất thoát với mã 0. Archive mới nhất vẫn còn mới và có kích thước gần với mức bạn dự kiến. File backup đột nhiên chỉ còn bằng một phần mười kích thước thông thường là một dump bị lỗi nhưng vẫn ghi được file. Đây là dạng lỗi backup nguy hiểm nhất vì mọi bước phía sau vẫn trông như bình thường.

Nếu script của bạn pipe dump vào một compressor, hãy thêm set -o pipefail ở đầu script. Nếu không có tùy chọn này, exit status của pipeline sẽ là exit status của compressor. Compressor đã chạy thành công: nó chỉ nén thông báo lỗi. Khi đó job sẽ báo thành công mỗi đêm, đồng thời ghi ra một archive nhỏ không chứa dữ liệu.

Hàng tháng: khôi phục backup ở nơi khác

Đây là mục mà hầu hết mọi người bỏ qua, nhưng nó quyết định các mục còn lại trong danh sách có thực sự hữu ích hay không.

Hãy khôi phục vào một máy khác hoặc một container mới, không bao giờ khôi phục đè lên dữ liệu đang chạy. Sau đó mở dữ liệu đã khôi phục và xác nhận dữ liệu là thật. Đếm số dòng trong một bảng. Mở một tài liệu. Đăng nhập vào ứng dụng đã khôi phục. Quá trình giải nén hoàn tất chỉ chứng minh archive có thể đọc được, không chứng minh thêm điều gì.

Các công cụ repository có cơ chế xác minh riêng: restic check --read-data-subset=5% và borg check --verify-data đọc dữ liệu đã lưu thay vì chỉ đọc index. Hãy chạy các lệnh này và xem chúng như smoke test, không phải công cụ thay thế. Việc xác minh kiểm tra xem các byte có còn nguyên hay không. Việc khôi phục kiểm tra xem các byte đó có đúng là dữ liệu mà ứng dụng cần hay không.

Có 2 chi tiết mà nhiều người chỉ rút kinh nghiệm sau khi gặp sự cố. Hãy kiểm tra passphrase giải mã trên một máy chưa có key trong agent, vì backup mà bạn không thể giải mã thì không phải là backup. Đồng thời đo thời gian khôi phục, vì khoảng thời gian đó là recovery time thực tế của bạn, và thời điểm thường phát hiện ra điều này là trong lúc hệ thống đang gặp sự cố.

Hàng tháng: chứng chỉ nào sắp hết hạn?

Tự động gia hạn có thể âm thầm bị lỗi. Timer của certbot có thể gia hạn file trên ổ đĩa, trong khi web server vẫn cung cấp chứng chỉ cũ trong bộ nhớ vì deploy hook dùng để reload service không chạy. Vì vậy, hãy kiểm tra từ bên ngoài máy chủ xem server đang cung cấp chứng chỉ nào.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Flag -servername thiết lập SNI (server name indication). Flag này bắt buộc trên mọi địa chỉ lưu trữ nhiều site. Nếu không, bạn sẽ nhận chứng chỉ mặc định thay vì chứng chỉ của mình. Nếu certbot được cài từ snap, timer có tên khác. Vì vậy, hãy tìm theo từ khóa thay vì giả định tên unit.

Đừng quên các chứng chỉ hoàn toàn không có cơ chế tự động hóa: chứng chỉ của mail server, VPN hoặc certificate authority nội bộ. Đây là những chứng chỉ thường hết hạn vào cuối tuần. Browser và client sẽ từ chối chúng ngay thay vì chỉ hiển thị cảnh báo.

Hàng tháng: người dùng, quyền sudo và SSH key

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T in cấu hình hiệu lực sau khi đã gộp mọi Include. Đây là cấu hình mà daemon thực sự sẽ sử dụng. Các image Ubuntu gần đây có các file drop-in trong /etc/ssh/sshd_config.d/. Những file này có thể ghi đè file chính, nên chỉ đọc sshd_config có thể khiến bạn hiểu ngược hoàn toàn. Trên họ RHEL, group quản trị là wheel thay vì sudo, nên hãy điều chỉnh dòng getent.

Sau đó đọc trực tiếp các file authorized_keys. Quyền truy cập được cấp bằng key, không phải bằng account. Vì vậy, một key do contractor đã nghỉ việc từ sáu tháng trước để lại vẫn là một login hoạt động mà không danh sách user nào phát hiện được. Key có trường comment. Hãy sử dụng trường này và xóa mọi key mà bạn không thể xác định thuộc về ai.

Để xem lịch sử đăng nhập, journalctl -t sshd --since "30 days ago" | grep -i accepted khớp theo mã định danh syslog thay vì tên unit. Điều này quan trọng vì Ubuntu 24.04 kích hoạt SSH thông qua socket. Do đó, mỗi kết nối được ghi log dưới một unit riêng được tạo cho từng kết nối, và journalctl -u ssh đơn thuần có thể bỏ sót chúng.

Hàng tháng: kernel cũ và phân vùng /boot đầy

/boot thường là một phân vùng riêng chỉ vài trăm megabyte trên image VPS mặc định. Mỗi lần cập nhật kernel, hệ thống thêm một image và một initramfs vào phân vùng này. Khi phân vùng đầy, lần nâng cấp tiếp theo sẽ lỗi giữa chừng và để lại các package chưa được cấu hình. Đây là tình trạng không nên bất ngờ gặp vào ngày thứ Sáu.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r trước tiên, luôn thực hiện bước này: lệnh cho biết kernel đang chạy ngay lúc này, và kernel đó phải được giữ lại dù bạn xóa bất cứ thứ gì. apt autoremove xử lý trường hợp thông thường trên Debian và Ubuntu, vì các kernel được đánh dấu là tự động cài đặt và kernel hiện tại được bảo vệ. Các trường hợp đặc biệt, như kernel được cài thủ công hoặc /boot đã đầy đến mức chặn cả apt, được trình bày trong xóa kernel cũ trên Ubuntu.

Hàng tháng: mức tăng của log và systemd journal

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug là chế độ chạy thử và không ghi gì, nên an toàn khi chạy trên máy chủ đang hoạt động. Bạn nên chạy lệnh này vì quy tắc rotation khớp theo đường dẫn: một ứng dụng đã thay đổi vị trí log trong quá trình nâng cấp sẽ không còn được quy tắc riêng của nó áp dụng, và file đó sẽ tiếp tục tăng không giới hạn cho đến khi làm đầy disk.

systemd giới hạn dung lượng journal, nhưng theo một phần của filesystem thay vì một con số do bạn chỉ định. Đặt SystemMaxUse= trong /etc/systemd/journald.conf rồi restart systemd-journald nếu muốn giới hạn cụ thể. sudo journalctl --vacuum-time=14d giải phóng dung lượng ngay lập tức và chỉ là thao tác một lần, không phải policy, nên hãy dùng cùng với thay đổi cấu hình.

Mỗi bản phát hành: lần reboot bạn cứ trì hoãn

Một package kernel đã được cập nhật trên disk không có nghĩa là kernel đang chạy đã được cập nhật. Trước khi reboot, máy vẫn chạy kernel cũ. Live patching, nếu có, cũng chỉ xử lý được một phần các bản sửa lỗi.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

File cờ đó là quy ước của Debian và Ubuntu, được các package script ghi vào. Hệ thống thuộc họ RHEL không tạo file này. Ở đó, câu hỏi tương đương được trả lời bằng needs-restarting -r, lấy thông tin từ dnf-utils. needrestart, được cài mặc định trên các image Ubuntu server gần đây, kiểm tra ở mức thấp hơn kernel: lệnh này liệt kê các process vẫn đang map một library đã bị thay thế trên disk. Vì vậy, bản OpenSSL đã được patch sẽ chưa có hiệu lực cho đến khi các service sử dụng nó được restart.

Hãy lên lịch reboot thay vì né tránh. Trong /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; và Unattended-Upgrade::Automatic-Reboot-Time "03:00";, hãy giao việc quyết định reboot cho thời điểm bạn đã chọn. Reboot có kế hoạch cũng là cách duy nhất để kiểm tra máy có khởi động lại được hay không, vì một entry fstab bị hỏng hoặc một service bạn chưa từng enable sẽ chỉ lộ ra trong lúc boot.

Theo từng bản phát hành: lập kế hoạch nâng cấp bản phân phối

Các bản phát hành Ubuntu LTS có 5 năm hỗ trợ tiêu chuẩn, còn các bản phát hành interim có 9 tháng hỗ trợ. Vì vậy, lựa chọn này quyết định khối lượng công việc nâng cấp của bạn trong nhiều năm. So sánh đó được trình bày trong LTS và bản phát hành interim trên máy chủ.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade đọc file đó, còn Prompt=lts giới hạn thao tác ở các lần chuyển từ LTS sang LTS. Đường nâng cấp LTS-to-LTS thường mở từ bản point release đầu tiên của phiên bản mới thay vì ngay ngày phát hành. Vì vậy, hãy kiểm tra máy của bạn được đề xuất nâng cấp lên phiên bản nào, thay vì lập kế hoạch theo một ngày bạn tự giả định. Cách thực hiện việc nâng cấp được trình bày trong nâng cấp Ubuntu 24.04 lên 26.04.

Hãy dự phòng 3 tháng. Tạo một snapshot và kiểm tra việc khôi phục snapshot đó. Liệt kê các apt repository bên thứ ba của bạn; quá trình nâng cấp sẽ vô hiệu hóa chúng, và mỗi repository cần có target mới cho bản phát hành mới. Hãy quyết định phương án rollback trước khi bắt đầu. Tính đến August 2026, Ubuntu 24.04 LTS được hỗ trợ tiêu chuẩn đến April 2029, nên đây là vấn đề lập lịch chứ không phải tình huống khẩn cấp.

Những việc nên tự động hóa và những việc nên giữ thủ công

Hãy tự động hóa những quyết định bạn đã đưa ra: cập nhật bảo mật, xoay vòng log, gia hạn chứng chỉ và các job backup. Cũng hãy tự động hóa việc cảnh báo, vì một kiểm tra phụ thuộc vào việc bạn nhớ thực hiện sẽ không chạy lúc 2am. Một hệ thống monitor bên ngoài, chẳng hạn như tự host hệ thống monitor trạng thái bằng Uptime Kuma, sẽ phát hiện vấn đề mà không script nào chạy trên máy có thể báo cáo: máy chủ không thể truy cập được.

Hãy giữ 2 việc ở chế độ thủ công: kiểm tra restore và audit tài khoản. Cả 2 đều cần một người quyết định kết quả có đúng hay không. Nếu bạn muốn xem trạng thái máy trong trình duyệt thay vì terminal, Cockpit và Webmin trong quản trị server so sánh 2 web console phổ biến này.

Bản thân cơ chế tự động hóa cũng cần được kiểm tra. Vì vậy, mục đầu tiên hằng tuần trong danh sách này là xác minh updater. Cơ chế tự động hóa bị lỗi mà không báo cáo còn tệ hơn không có cơ chế tự động hóa, vì nó đồng thời loại bỏ cả việc phát hiện lỗi và thói quen kiểm tra.

Toàn bộ checklist ở một chỗ

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Tôi nên bảo trì máy chủ Linux bao lâu một lần?

Hàng tuần đối với những thứ tự thay đổi: trạng thái cập nhật, dung lượng trống của disk và inode, các unit bị fail, và việc backup job đã hoàn tất hay chưa. Hàng tháng đối với những vấn đề tích tụ chậm: kiểm tra restore, thời hạn chứng chỉ, audit account và SSH key, kernel cũ, mức tăng trưởng của log. Thực hiện một lần sau mỗi bản phát hành của distribution để nâng cấp phiên bản và reboot vào kernel hiện tại. Trên một máy chủ đang hoạt động bình thường, lần kiểm tra hàng tuần chỉ mất vài phút. Đó là lý do nên thực hiện hàng tuần thay vì chờ đến khi có dấu hiệu bất thường.

Tại sao phải kiểm tra restore nếu backup job báo thành công?

Vì job chỉ báo exit status của chính nó, và status đó có thể là thành công trong khi archive không dùng được. Một dump được pipe vào compressor mà không có set -o pipefail sẽ trả về status của compressor. Vì vậy, dump bị fail nhưng chỉ tạo ra một thông báo lỗi vẫn có thể exit với mã 0 và ghi ra một file nhỏ. Hãy restore sang một máy khác, mở dữ liệu và đếm một đối tượng nào đó. Quá trình restore cũng tự đo thời gian, và khoảng thời gian đó mới là thời gian khôi phục thực tế của bạn.

Tôi có phải reboot sau mỗi lần cập nhật kernel không?

Bạn phải reboot trước khi kernel mới trở thành kernel đang chạy. Trên Debian và Ubuntu, sự tồn tại của /var/run/reboot-required cho biết một package đã yêu cầu reboot, còn /var/run/reboot-required.pkgs cho biết package nào yêu cầu. Trên họ RHEL, file đó không tồn tại; needs-restarting -r từ dnf-utils trả lời câu hỏi tương tự. Hãy đặt một khoảng thời gian reboot tự động trong /etc/apt/apt.conf.d/50unattended-upgrades thay vì trì hoãn vô thời hạn, vì một máy chưa reboot trong một năm không chỉ đang chạy kernel cũ mà còn có boot path chưa được kiểm thử.

Những kiểm tra nào trong số này có thể tự động hóa an toàn?

Hãy tự động hóa những tác vụ đã có sẵn quyết định: security update, log rotation, gia hạn chứng chỉ và backup theo lịch. Đồng thời tự động hóa cả việc gửi thông báo, để bạn nhận được thông tin khi một unit bị fail hoặc disk sắp đầy mà không cần người chạy lệnh thủ công. Hãy thực hiện thủ công restore test và audit key, vì mỗi việc đều cần người đánh giá kết quả có đúng hay không. Sau đó thêm một kiểm tra cho chính cơ chế tự động hóa, vì updater fail trong im lặng trông không khác gì hệ thống đang hoạt động bình thường.