Nâng cấp Ubuntu LTS trên VPS: backup, kiểm tra compatibility và rollback

Nâng cấp Ubuntu LTS trên VPS là thay đổi lớn ở cấp hệ điều hành, khác hoàn toàn với việc chạy apt update hoặc cài một package. Release upgrade có thể thay đổi kernel, system libraries, OpenSSH, PHP, database client, repository và cách service khởi động. Nếu chỉ quan tâm lệnh do-release-upgrade mà bỏ qua backup, compatibility và kế hoạch quay lui, một VPS đang chạy website production có thể mất nhiều giờ để phục hồi.

Bài này trình bày quy trình thực tế và thận trọng: xác định đường nâng cấp được hỗ trợ, lập inventory, backup dữ liệu và cấu hình, kiểm tra disk/SSH/service, thử trên snapshot hoặc staging, cập nhật release hiện tại, chạy do-release-upgrade, xử lý prompt configuration, reboot và xác minh. Phần rollback nhấn mạnh sự thật vận hành: nâng cấp release thường không có nút undo đơn giản, vì vậy snapshot/image và backup restore mới là đường lui đáng tin cậy.

1. Release upgrade khác update package thế nào?

Update package giữ nguyên Ubuntu release và cập nhật các phiên bản package trong release đó. Release upgrade chuyển toàn bộ hệ thống sang một major release kế tiếp, kéo theo thay đổi dependency, repository và cấu hình. Vì phạm vi rộng hơn, thời gian downtime, rủi ro và yêu cầu kiểm thử cũng cao hơn.

Tài liệu Ubuntu Server: How to upgrade your Ubuntu release khuyến nghị dùng LTS cho server và phân biệt rõ release upgrade với regular software updates. Đây là mốc đầu tiên trong runbook: không gọi do-release-upgrade chỉ vì có một bản package mới.

Release upgrade là quá trình chuyển sang major release kế tiếp, không phải chỉ là cập nhật package thông thường.Tóm lược từ Ubuntu Server documentation.[1]

2. Đường nâng cấp LTS được hỗ trợ

Ubuntu chỉ hỗ trợ nâng cấp trực tiếp từ một LTS sang LTS kế tiếp theo thứ tự. Không nên nhảy cóc từ một LTS cũ sang một LTS mới hơn nhiều phiên bản trong một lần. Nếu cần đi xa hơn, phải nâng cấp từng chặng, kiểm tra sau mỗi chặng và giữ backup/snapshot riêng.

# Kiểm tra release hiện tại
. /etc/os-release
lsb_release -a 2>/dev/null || true
uname -a

# Kiểm tra trạng thái package
sudo apt update
apt list --upgradable

Thời điểm mở đường nâng cấp LTS cũng quan trọng: tài liệu Ubuntu ghi rằng nâng cấp LTS kế tiếp thường chỉ sẵn sàng sau point release đầu tiên. Không dùng cờ -d trên production chỉ để ép thấy bản mới, vì đó là đường development/force upgrade và có thể đưa hệ thống vào trạng thái chưa phù hợp vận hành.

3. Inventory trước khi chạm vào production

Hãy lập inventory có thể đọc lại sau reboot: Ubuntu version, kernel, disk/mount, IP và route, user SSH, firewall, service đang chạy, port public, PHP/Node/Python, database, Docker, cron, systemd unit, repository bên thứ ba và file cấu hình đã sửa. Mục tiêu là biết chính xác “bình thường” trước upgrade để nhận ra sai lệch sau đó.

hostnamectl
cat /etc/os-release
uname -r
lsblk -f
df -hT
free -h
ip addr
ip route
sudo ss -lntup
sudo systemctl --type=service --state=running
sudo systemctl --failed

Với website Laravel hoặc Ghost, ghi lại endpoint health, phiên bản runtime, worker queue, cron, reverse proxy, TLS renewal và trạng thái database. Các bài systemd service và cron trên Linux có thể dùng làm checklist khi inventory service và lịch tự động.

4. Backup phải restore được, không chỉ tồn tại

Backup an toàn là backup có thể khôi phục trong thời gian chấp nhận được. Trước release upgrade, tạo ít nhất một bản sao ngoài VPS cho database, uploads, file cấu hình, secrets, SSH keys theo chính sách, crontab và systemd unit. Ghi timestamp, checksum nếu phù hợp và thử restore một phần trên máy/staging độc lập.

# Ví dụ inventory cấu hình và dữ liệu cần đưa vào backup
sudo tar -czf /tmp/etc-critical.tgz /etc/nginx /etc/ssh /etc/systemd/system 2>/dev/null
crontab -l > /tmp/user-crontab.txt
sudo crontab -l > /tmp/root-crontab.txt
sudo ss -lntup > /tmp/listening-before.txt

# Database: dùng công cụ dump phù hợp engine và policy
# mysqldump --single-transaction ... > backup.sql

Không đưa password thật vào script hoặc chat. Với database lớn, kiểm tra thời gian dump/restore và dung lượng cần thiết; với file upload, kiểm tra cả owner, permission và symlink. Nếu hosting provider có snapshot VPS, snapshot là lớp rollback hệ thống; nhưng vẫn nên có logical backup vì snapshot có thể phụ thuộc nhà cung cấp hoặc không thuận tiện khi cần trích một bảng/file.

5. Kiểm tra compatibility và repository bên thứ ba

Third-party repositories và PPA là nguồn gây lỗi phổ biến vì package có thể chưa hỗ trợ release mới. Hãy liệt kê chúng, đọc compatibility matrix của nhà cung cấp, kiểm tra phiên bản PHP/Node/database và xác định repository nào sẽ được vô hiệu hóa. Không bật lại PPA cũ một cách mù quáng sau upgrade.

grep -RhsE '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
apt-mark showhold
sudo dpkg --audit
sudo apt-get check
php -v 2>/dev/null || true
node --version 2>/dev/null || true

Nếu ứng dụng phụ thuộc extension native, image library, database driver hoặc binary ngoài package manager, hãy dựng một máy thử cùng release đích và cài lại từ đầu. Một upgrade thành công ở cấp OS chưa có nghĩa là ứng dụng production tương thích; compatibility phải được kiểm tra ở cả runtime, dependency và dữ liệu.

6. Cập nhật release hiện tại trước khi upgrade

Ubuntu yêu cầu hệ thống hiện tại được cập nhật đầy đủ trước release upgrade. Theo tài liệu chính thức, chạy apt update rồi dist-upgrade, đồng thời xử lý package bị hold hoặc phased update. Nếu file /run/reboot-required tồn tại, reboot trước khi bắt đầu chặng release upgrade.

sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
apt list --upgradable
test -e /run/reboot-required && echo "reboot required"
sudo reboot

Chỉ reboot khi bạn có console hoặc SSH recovery path phù hợp và đã thông báo downtime. Sau reboot, kiểm tra lại SSH, disk, service và package manager. Không nên bắt đầu do-release-upgrade trong trạng thái còn package dependency hỏng hoặc filesystem gần đầy; bài Linux disk full là checklist hữu ích để kiểm tra dung lượng trước khi tải hàng gigabyte package.

7. Chạy do-release-upgrade đúng cách

Trên Ubuntu Server và cloud image, công cụ được khuyến nghị là sudo do-release-upgrade. Hãy chạy trong maintenance window, có console dự phòng và người theo dõi tương tác. Công cụ sẽ chạy preflight summary trước khi thay đổi; hãy đọc số package được remove/install/upgrade, dung lượng download và cảnh báo trước khi xác nhận.

sudo apt install update-manager-core
sudo do-release-upgrade

Không dùng -d cho production để ép nâng cấp lên development release. Khi quá trình bắt đầu tải và cài, không nên đóng SSH hoặc reboot cưỡng bức. Nếu SSH có nguy cơ timeout, hãy dùng console của nhà cung cấp hoặc một phiên tmux/screen theo chính sách, nhưng vẫn phải theo dõi prompt và log thay vì bỏ mặc tiến trình.

8. Prompt configuration file: giữ hay dùng bản mới?

Trong upgrade, package có thể phát hiện file cấu hình đã bị bạn chỉnh sửa trong khi maintainer phát hành một bản mới. Prompt thường cho phép giữ bản hiện tại, cài bản maintainer, xem diff hoặc mở shell. Quyết định phải dựa trên diff và runbook; giữ bản cũ có thể bỏ mất directive cần cho release mới, còn nhận bản mới có thể làm mất cấu hình production.

# Sau khi upgrade, tìm file .dpkg và thay đổi còn tồn đọng
sudo find /etc -type f \( -name '*.dpkg-dist' -o -name '*.dpkg-old' \) -print
sudo dpkg --audit
sudo apt-get check

Với SSH, nginx, PHP-FPM, database hoặc systemd unit, hãy lưu bản trước upgrade và so sánh diff sau upgrade. Không copy toàn bộ file cấu hình cũ vào release mới mà không đọc directive đã deprecated. Nếu đang ở console, ghi lại lựa chọn đã chọn và lý do để người khác có thể audit.

9. Reboot và xác minh sau upgrade

Ubuntu chưa được xem là upgraded hoàn tất cho đến khi reboot xong. Sau reboot, xác minh theo thứ tự từ nền tảng đến ứng dụng: version, kernel, network, DNS, SSH, firewall, disk, systemd failed units, reverse proxy, runtime, database, queue, cron, TLS và endpoint thực tế.

cat /etc/os-release
uname -r
uptime
systemctl is-system-running
sudo systemctl --failed
sudo ss -lntup
sudo journalctl -b -p warning..alert --no-pager
sudo systemctl status nginx --no-pager
curl -fsS https://example.com/health || true

Đừng chỉ kiểm tra HTTP 200 ở homepage. Hãy thử login hoặc một endpoint read-only, truy vấn database nhẹ, job queue, upload file tạm và cron probe nếu ứng dụng có các chức năng đó. Kiểm tra cả log mới bằng journalctl và log ứng dụng; lỗi dependency đôi khi chỉ lộ ra khi request đi qua một code path cụ thể.

10. Rollback thực tế: snapshot, restore hay rebuild?

Release upgrade không có một lệnh downgrade đáng tin cậy cho mọi package và cấu hình. Nếu upgrade hỏng, rollback thực tế thường là khôi phục snapshot/image của VPS, restore backup vào máy mới, hoặc rebuild server từ image chuẩn rồi deploy lại ứng dụng và dữ liệu. Chọn phương án nào phụ thuộc RTO, kích thước dữ liệu và khả năng của nhà cung cấp VPS.

• Snapshot rollback nhanh nhưng phụ thuộc provider, trạng thái snapshot và thời điểm snapshot.
• Logical backup linh hoạt hơn khi chỉ cần restore database, file hoặc cấu hình.
• Rebuild sạch phù hợp khi OS đã drift hoặc upgrade để lại dependency khó kiểm soát.
• DNS hoặc load balancer cần kế hoạch chuyển traffic nếu dùng server thay thế.

Hãy diễn tập ít nhất một lần: tạo VPS tạm, restore database và uploads, cài runtime, bật service, kiểm tra endpoint rồi đo thời gian. Rollback chỉ có giá trị khi người trực ca biết chạy và dữ liệu sau restore có thể xác minh.

11. Checklist nâng cấp Ubuntu LTS trên VPS

1. Xác định release hiện tại, release đích và đường nâng cấp LTS tuần tự được hỗ trợ.
2. Đọc release notes và compatibility của PHP, Node.js, database, web server, Docker và PPA.
3. Ghi inventory service, port, user, mount, cron, systemd unit, TLS và health endpoint.
4. Tạo snapshot/image và backup ngoài VPS cho database, uploads, secrets, config và lịch tự động.
5. Kiểm tra dung lượng, inode, package hold, dependency lỗi và repository bên thứ ba.
6. Chạy apt update và dist-upgrade trên release hiện tại; reboot nếu được yêu cầu.
7. Chạy do-release-upgrade trong maintenance window với console dự phòng; không dùng -d production.
8. Đọc từng prompt cấu hình và lưu lại quyết định giữ bản cũ hay nhận bản mới.
9. Reboot rồi kiểm tra version, kernel, SSH, network, service, database, queue, cron, TLS và endpoint.
10. Nếu không đạt, kích hoạt snapshot/restore/rebuild theo runbook và ghi nhận nguyên nhân.

12. Kết luận

Nâng cấp Ubuntu LTS an toàn là một thay đổi có kiểm soát, không phải lệnh chạy một lần. Đường nâng cấp đúng, backup restore được, compatibility rõ, console dự phòng và checklist sau reboot quan trọng hơn việc cố rút ngắn vài phút. Khi rollback đã được diễn tập trước, bạn có thể nâng cấp VPS chủ động hơn mà không biến một lỗi package thành downtime không đoán trước.