Khởi động lại (reboot) VPS có thể là một bước bảo trì cần thiết theo kế hoạch, một biện pháp dập lửa tạm thời trong lúc xử lý sự cố khẩn cấp, nhưng cũng có thể là thao tác tai hại xóa sạch toàn bộ dấu vết điều tra nguyên nhân gốc rễ. Sự khác biệt giữa một quyết định chuyên nghiệp và một hành động cảm tính nằm ở lý do reboot và sự chuẩn bị trước khi gửi lệnh.
Trong thực tế vận hành máy chủ, thao tác reboot được chia thành 3 kịch bản rõ rệt:
- Reboot theo kế hoạch (Planned Maintenance): Cần nạp nhân Linux mới (kernel update), cập nhật CPU microcode hoặc áp dụng các cấu hình mạng/hệ điều hành tầng thấp. Trường hợp này luôn có khung giờ bảo trì được ấn định trước và checklist kiểm thử rõ ràng.
- Reboot để giảm thiểu thiệt hại (Mitigation trong Incident): Toàn bộ dịch vụ trên máy chủ đang bị gián đoạn nghiêm trọng, các biện pháp can thiệp hẹp (như reload/restart từng service) đều không hiệu quả và lợi ích của việc đưa website hoạt động trở lại lớn hơn rủi ro mất mát dữ liệu tạm thời.
- Reboot cưỡng bức (Hard Reboot / Power Cycle): Chỉ áp dụng khi hệ điều hành đã mất hoàn toàn khả năng phản hồi (kernel panic, treo I/O cứng) và không thể thực hiện quy trình shutdown bình thường qua SSH hay Web Console.
Nếu VPS vẫn còn kết nối được và bạn chưa nắm rõ điều gì đang diễn ra bên dưới, hãy dành vài phút để thu thập bằng chứng. Reboot có thể giúp website phản hồi trở lại ngay lúc đó, nhưng không đồng nghĩa với việc sự cố đã được giải quyết tận gốc.
Khi nào reboot là quyết định kỹ thuật chính xác?
1. Sau khi cập nhật hệ thống cần nạp kernel mới
Một bản cập nhật kernel chỉ thực sự phát huy tác dụng bảo mật sau khi máy chủ khởi động lại và boot vào chính phiên bản kernel mới đó. Tương tự, các bản vá liên quan đến CPU microcode, bootloader (GRUB) hay thư viện hệ thống cốt lõi (glibc, systemd) cũng thường yêu cầu reboot để làm mới hoàn toàn không gian bộ nhớ.
Trên Ubuntu Server, bạn có thể kiểm tra xem hệ thống có đang chờ reboot hay không bằng lệnh:
test -f /var/run/reboot-required && cat /var/run/reboot-required
uname -rThông báo này là cơ sở để bạn lên lịch bảo trì vào khung giờ thấp điểm, không phải lý do để gõ lệnh reboot ngay lập tức giữa giờ làm việc. Bạn cần đảm bảo trình quản lý gói apt đã kết thúc hoàn toàn, các service không ở trạng thái lỗi và bạn nắm chắc máy chủ sẽ boot lên bằng kernel nào.
Dịch vụ Canonical Livepatch có thể hỗ trợ vá nóng một số lỗ hổng kernel nghiêm trọng mà không cần khởi động lại máy ngay. Tuy nhiên, Livepatch không thể thay thế toàn bộ các cập nhật hệ thống định kỳ. Vì vậy, máy chủ vẫn cần được lên lịch reboot định kỳ có kiểm soát như đã nêu trong bài Cách cập nhật Ubuntu Server an toàn.
2. Khi cần xác nhận toàn bộ chu trình khởi động (Boot Path)
Sau khi thay đổi các cấu hình hạ tầng quan trọng như bảng phân vùng gắn ổ đĩa (/etc/fstab), cấu hình mạng tĩnh (netplan), quy tắc firewall hoặc kích hoạt các service tự chạy cùng hệ thống (systemctl enable), cách duy nhất để kiểm chứng cấu hình có hoạt động tự động khi xảy ra sự cố cúp điện hay không là chủ động reboot máy chủ.
Một lần reboot theo kế hoạch giúp bạn xác nhận:
- Kernel và initramfs khởi động trơn tru.
- Toàn bộ các ổ đĩa dữ liệu và phân vùng swap được mount chính xác.
- Quy tắc firewall (UFW/iptables) và card mạng nhận đúng địa chỉ IP.
- Nginx, database, Docker daemon và các ứng dụng tự động khởi động đúng theo thứ tự phụ thuộc.
- Các biến môi trường, secret và volume cần thiết được nạp đầy đủ.
Đừng để đến lúc nhà cung cấp đám mây bảo trì phần cứng đột xuất mới phát hiện ra website của bạn không thể tự chạy lại vì ai đó đã khởi động service thủ công bằng tay từ 6 tháng trước mà quên cấu hình systemctl enable.
3. Khi sự cố production ảnh hưởng nghiêm trọng và mất kiểm soát
Trong các sự cố vận hành (Incident), việc reboot là chấp nhận được nếu:
- Máy chủ mất phản hồi diện rộng, việc SSH cực kỳ chập chờn hoặc không thể mở được tiến trình mới do cạn kiệt process table / PID.
- Toàn bộ ngăn xếp mạng (network stack) hoặc hệ thống tệp tin gặp lỗi phân tầng khiến các container và service đồng loạt bị treo.
- Việc khởi động lại từng dịch vụ riêng lẻ không mang lại kết quả và thời gian gián đoạn dịch vụ của doanh nghiệp đang kéo dài vượt ngưỡng chấp nhận.
Trong tình huống này, mục tiêu số một là khôi phục dịch vụ cho người dùng trước. Sau khi website đã lên, việc điều tra nguyên nhân gốc rễ sẽ dựa vào log của lần boot trước đó.
Khi nào chưa nên reboot?
1. Chỉ một dịch vụ đơn lẻ gặp trục trặc
Nếu chỉ có Nginx báo lỗi 502, Node.js bị crash hoặc một container Docker rơi vào trạng thái Restarting trong khi hệ điều hành, RAM, đĩa cứng và SSH vẫn hoạt động mượt mà, giải pháp đúng đắn là khởi động lại đúng dịch vụ đó:
sudo systemctl restart nginx
# Hoặc với container
docker compose restart backendKhởi động lại một tiến trình đơn lẻ có phạm vi ảnh hưởng (blast radius) rất nhỏ, không làm ngắt kết nối database của các ứng dụng khác và không làm đứt đoạn các phiên kết nối mạng của hệ điều hành.
2. Tải CPU hoặc RAM cao nhưng chưa rõ nguyên nhân
Mức sử dụng CPU 100% hay RAM gần hết không phải lý do để reboot ngay lập tức. Nếu bạn vẫn truy cập được vào máy qua SSH, hãy bỏ ra 2-3 phút để xác định tiến trình nào đang chiếm dụng tài nguyên bằng htop hoặc top.
Reboot sẽ tạm thời giải phóng bộ nhớ và làm trống CPU. Nhưng nếu nguyên nhân là một câu truy vấn SQL quét hàng triệu dòng hoặc một đoạn code lặp vô tận, thì chỉ 5 phút sau khi máy chủ bật lên, lượng người dùng truy cập sẽ lại đẩy máy chủ về đúng trạng thái treo như cũ. Hãy làm theo hướng dẫn trong bài VPS CPU 100%: cách tìm tiến trình gây tải mà không vội reboot.
3. Trình quản lý gói hoặc Database Migration đang chạy
Tuyệt đối không reboot máy chủ khi lệnh apt upgrade, dpkg, tiến trình migration cơ sở dữ liệu hoặc tác vụ tạo bản sao lưu (backup) đang diễn ra. Việc ngắt nguồn máy chủ giữa chừng khi các tệp tin nhị phân hoặc bảng dữ liệu đang được ghi đè sẽ gây hỏng cơ sở dữ liệu (database corruption) hoặc làm hỏng bộ quản lý gói của hệ điều hành, dẫn tới việc máy chủ không thể boot lại bình thường.
4. Nghi ngờ máy chủ bị xâm phạm an ninh
Nếu máy chủ xuất hiện các dấu hiệu bị tấn công (mã độc tống tiền, tiến trình đào coin lạ, tài khoản quản trị bị thay đổi), hãy dừng ngay việc reboot. Việc khởi động lại máy chủ sẽ xóa sạch toàn bộ các tiến trình độc hại đang chạy trong bộ nhớ RAM, xóa bảng kết nối mạng của hacker và làm mất các bằng chứng điều tra an ninh số quan trọng. Trong trường hợp này, hãy cô lập card mạng của VPS ở tầng Cloud Firewall để ngăn chặn kẻ tấn công trước khi tiến hành điều tra.
5 câu hỏi cần tự trả lời trước khi gửi lệnh reboot
- Reboot để áp dụng thay đổi cấu hình hay chỉ để trốn tránh việc tìm lỗi?
- Có thể xử lý bằng một hành động hẹp hơn (reload cấu hình, restart 1 service, dừng 1 cronjob) hay không?
- Cơ sở dữ liệu và hàng đợi (queue) đã ở trạng thái an toàn để dừng chưa?
- Bạn có chắc chắn máy chủ sẽ boot lại thành công không (dung lượng phân vùng
/bootcòn trống, cấu hình mạng và SSH hợp lệ, tài khoản Web Console sẵn sàng)? - Sau khi máy chủ khởi động lại, bạn sẽ kiểm tra những tiêu chí kỹ thuật nào để khẳng định website đã hoạt động bình thường?
Những dữ liệu sống còn cần lưu lại trước khi reboot
Nếu máy chủ vẫn còn phản hồi qua terminal, hãy chạy nhanh các lệnh sau để xuất dữ liệu ra một tệp nhật ký tạm thời:
1. Dấu vết thời gian và trạng thái hệ thống
# Lưu thông tin thời gian hoạt động và kernel
uptime > /tmp/crash_report.txt
uname -r >> /tmp/crash_report.txt
# Kiểm tra các service đang ở trạng thái lỗi
systemctl --failed >> /tmp/crash_report.txt2. Tiến trình chiếm dụng CPU và bộ nhớ
# Lưu top 10 tiến trình tốn CPU và RAM nhất
ps aux --sort=-%cpu | head -n 15 >> /tmp/crash_report.txt
ps aux --sort=-%mem | head -n 15 >> /tmp/crash_report.txt
# Kiểm tra tình trạng bộ nhớ và swap
free -h >> /tmp/crash_report.txt3. Kiểm tra dấu hiệu OOM Killer và lỗi hệ thống
# Trích xuất 50 dòng log kernel gần nhất tìm dấu hiệu Out of Memory
sudo dmesg -T | grep -i -E 'oom|killed process' | tail -n 50 >> /tmp/crash_report.txt4. Kiểm tra dung lượng ổ đĩa và phân vùng boot
df -h >> /tmp/crash_report.txtNếu phân vùng / hoặc /boot bị đầy 100%, máy chủ rất có thể sẽ bị kẹt ở màn hình boot (Kernel Panic hoặc Read-only Filesystem). Bạn cần dọn bớt các kernel cũ hoặc tệp tin rác trước khi reboot.
Các kỹ thuật điều tra và xử lý sự cố trong 30 phút đầu tiên đã được chuẩn hóa trong bài Quy trình 30 phút đầu khi website production gặp sự cố.
Chuẩn bị đường lui trước khi khởi động lại
Trước khi thực hiện lệnh, hãy đảm bảo bạn có đầy đủ các yếu tố bảo hiểm:
- Thông tin đăng nhập trang quản trị đám mây: Luôn mở sẵn trang quản lý VPS (Cloud Console) của nhà cung cấp để có thể truy cập Web Console (VNC/Serial Console) ngay lập tức nếu máy chủ bị mất kết nối SSH sau khi boot.
- Bản sao lưu dữ liệu gần nhất: Đảm bảo hệ thống đã có bản backup gần nhất hợp lệ theo đúng chiến lược backup cho VPS nhỏ.
- Phân biệt giữa Reboot và Stop/Start: Trên một số nền tảng đám mây (như AWS EC2 hoặc một số nhà cung cấp VPS giá rẻ), lệnh
rebootsẽ giữ nguyên địa chỉ IP công cộng và phần cứng ảo hóa. Nhưng nếu bạn chọn nhầmStoprồiStart, máy chủ có thể bị chuyển sang cụm máy chủ vật lý khác và địa chỉ IP công cộng (Public IP) có thể bị thay đổi nếu bạn không gán IP tĩnh (Elastic IP).
Quy trình thực hiện Graceful Reboot
Thay vì dùng các lệnh thô bạo như reboot -f hay bấm nút "Force Reset" trên web console của nhà cung cấp, hãy luôn sử dụng lệnh chuẩn của systemd:
sudo systemctl rebootLệnh này sẽ gửi tín hiệu kết thúc nhẹ nhàng (SIGTERM) tới toàn bộ các tiến trình đang chạy, cho phép cơ sở dữ liệu (MySQL, PostgreSQL) có thời gian xả dữ liệu từ RAM xuống đĩa (flush buffers), ngắt các kết nối mạng an toàn và unmount các hệ thống tệp tin trước khi ngắt nguồn.
Sau khi gõ lệnh, terminal của bạn sẽ bị ngắt kết nối. Đừng sốt ruột gửi liên tiếp các lệnh cưỡng bức trên trang web quản lý đám mây nếu máy chưa lên lại sau 30 giây. Quá trình kiểm tra tệp tin (fsck), khởi tạo card mạng và nạp cloud-init thường mất từ 1 đến 3 phút tùy cấu hình VPS.
4 bước kiểm tra toàn diện sau khi máy chủ hoạt động trở lại
Khi kết nối SSH đã thông suốt, bạn cần thực hiện tuần tự 4 bước kiểm tra sau:
1. Kiểm tra trạng thái hệ điều hành và phân vùng
# Xác nhận kernel mới đã được nạp
uname -r
# Đảm bảo không có dịch vụ hệ thống nào bị fail
systemctl --failed
# Kiểm tra dung lượng đĩa và các điểm mount
df -h2. Kiểm tra dịch vụ mạng và ứng dụng
- Xác nhận Nginx/Apache đang lắng nghe đúng cổng:
sudo ss -tulpn | grep -E '80|443' - Kiểm tra trạng thái kết nối của database:
sudo systemctl status mysql(hoặc postgresql) - Nếu dùng Docker, đảm bảo toàn bộ container đã chạy ổn định:
docker ps - Kiểm tra các worker xử lý queue và tác vụ cronjob nền.
3. Kiểm tra trải nghiệm thực tế từ bên ngoài
Mở trình duyệt ở chế độ ẩn danh hoặc sử dụng một mạng Internet khác để kiểm tra trực tiếp:
- Truy cập tên miền chính: kiểm tra mã phản hồi HTTP 200 và chứng chỉ SSL hợp lệ.
- Thử nghiệm các tính năng nghiệp vụ cốt lõi: đăng nhập tài khoản, tìm kiếm dữ liệu, thêm giỏ hàng hoặc gửi form liên hệ.
- Kiểm tra tỷ lệ lỗi và độ trễ trên hệ thống giám sát đã trở về mức bình thường hay chưa theo tiêu chuẩn tại bài Nên monitoring những gì trên một VPS chạy website?.
4. Đọc lại nhật ký log của lần boot trước
Nếu hệ điều hành của bạn bật tính năng lưu trữ log vĩnh viễn (persistent journald), bạn hoàn toàn có thể đọc lại các thông báo lỗi ngay trước thời điểm máy chủ bị sập bằng lệnh:
# Liệt kê danh sách các lần boot
journalctl --list-boots
# Đọc log cảnh báo của lần boot ngay trước đó (-1)
journalctl -b -1 -p warning -n 100Điều này cung cấp bằng chứng vô giá để bạn tìm ra nguyên nhân gốc rễ và xử lý triệt để trong các ngày tiếp theo.
Checklist tóm tắt quy trình reboot VPS an toàn
- ☐ Mục tiêu reboot rõ ràng (cập nhật kernel hoặc khôi phục sự cố khẩn cấp).
- ☐ Đã loại trừ khả năng giải quyết bằng biện pháp hẹp hơn (reload service, restart container).
- ☐ Không có tiến trình cập nhật hệ điều hành (
apt) hoặc database migration nào đang chạy. - ☐ Đã sao lưu dữ liệu gần nhất và xuất nhanh các thông số tải (
/tmp/crash_report.txt). - ☐ Phân vùng
/bootvà/còn trống dung lượng. - ☐ Tài khoản Web Console trên trang quản trị đám mây luôn sẵn sàng đề phòng mất kết nối SSH.
- ☐ Sử dụng lệnh graceful reboot chuẩn:
sudo systemctl reboot. - ☐ Sau khi máy lên: kiểm tra kernel mới,
systemctl --failed, các cổng mạng đang lắng nghe. - ☐ Đã kiểm thử luồng người dùng thực tế trên website từ mạng bên ngoài.
- ☐ Đã tra cứu log của lần boot trước (
journalctl -b -1) để ghi nhận nguyên nhân và lên kế hoạch phòng ngừa.
Reboot VPS là một công cụ mạnh mẽ trong hộp đồ nghề của người quản trị hệ thống, nhưng nó chỉ phát huy hiệu quả tối đa khi được sử dụng có kỷ luật và có kiểm soát.
