Cập Nhật Ubuntu Server An Toàn: Nâng Gói APT, Reboot Và Nghiệm Thu Dịch Vụ Không Đứt Quãng

Để cập nhật một máy chủ Ubuntu Server mà không biến buổi tối cuối tuần thành ca trực cứu hộ bất đắc dĩ, bạn cần tuân thủ quy trình 3 bước: khám sức khỏe hệ thống ban đầu, đọc kỹ danh sách gói dự kiến thay đổi và nghiệm thu toàn diện sau khi khởi động lại (reboot). Việc câu lệnh apt chạy hết thanh phần trăm hoàn toàn chưa đủ để khẳng định các dịch vụ nền đã nạp thư viện mới hay trang web của bạn vẫn sống khỏe sau khi máy khởi động lại. Bài viết này sẽ hướng dẫn bạn thực hiện một ca bảo trì gọn gàng, bài bản ngay trên môi trường Ubuntu 24.04.

Lưu ý quan trọng về phạm vi: chúng ta đang thực hiện cập nhật các bản vá và gói phần mềm trong cùng phiên bản hệ điều hành hiện hành (minor/security updates), hoàn toàn không phải nâng cấp nhảy vọt lên phiên bản Ubuntu mới (major release upgrade). Vào ngày 01/10/2026, máy chủ LAB-CF-02 được chúng tôi đọc thông số hiện trạng và chạy mô phỏng kế hoạch nâng cấp để làm mốc đối chiếu trước bảo trì. Đến ngày 02/10/2026, ca bảo trì thực tế mới chính thức diễn ra với 152 gói phần mềm được nâng cấp kèm theo một lần reboot toàn máy. Toàn bộ nhật ký và hình ảnh nghiệm thu thực tế đều được ghi lại chi tiết ở phần dưới của bài viết.

Chuẩn bị chốt an toàn trước khi tải gói cập nhật

Trước khi đụng vào trình quản lý gói APT, hãy đối chiếu chính xác tên máy (hostname) và địa chỉ IP của VPS, xác nhận tài khoản sudo vẫn hoạt động trơn tru và đường vào VNC Console trên bảng điều khiển của nhà cung cấp sẵn sàng tiếp ứng. Hãy sao lưu lại các tệp cấu hình quan trọng mà bạn từng chỉnh sửa tay. Nếu VPS đã chạy sẵn WordPress, việc có một bản backup đầy đủ cả mã nguồn lẫn cơ sở dữ liệu kèm theo một bản Snapshot toàn máy ảo là điều bắt buộc — bởi backup ứng dụng chỉ cứu được dữ liệu web, chứ không giúp bạn khôi phục nhanh hệ điều hành nếu chẳng may lỗi quá trình boot.

Hãy chọn khung giờ bảo trì (maintenance window) khi lưu lượng truy cập thấp nhất và máy chủ không phải gồng mình chạy các tác vụ nặng như import dữ liệu hay nén backup định kỳ. Dù thực hành trên VPS thử nghiệm thì bạn vẫn nên rèn thói quen làm việc y như trên máy thật: chuẩn bị sẵn phương án xử lý sự cố trước khi gõ lệnh đầu tiên.

Sơ đồ các bước chuẩn bị trước khi cập nhật hệ điều hành do localhost.vn biên soạn giúp bạn rà soát đầy đủ các điều kiện an toàn.

Bước 1: Ghi nhận trạng thái hệ thống và dung lượng ổ đĩa ban đầu

Mở đầu ca bảo trì, hãy chạy cụm lệnh chỉ đọc dưới đây để lấy thông số nền của máy chủ:

cat /etc/os-release
uname -r
df -hT
df -i
systemctl --failed --no-pager

Hãy nhìn thật kỹ vào dung lượng trống trên phân vùng gốc / và đặc biệt là phân vùng /boot (nếu máy chủ của bạn tách riêng phân vùng này) cùng tỷ lệ sử dụng inode. Một trong những tai nạn kinh điển nhất khi nâng cấp Ubuntu là ổ đĩa bị đầy ngay giữa lúc hệ thống đang giải nén gói linux-image (kernel mới) hoặc đang đóng gói lại tệp initramfs, khiến máy chủ rơi vào cảnh “chết lâm sàng” ở lần khởi động kế tiếp. Nếu thấy thiếu dung lượng do tồn đọng nhiều bản kernel cũ, tuyệt đối không dùng lệnh rm xóa bừa các tệp trong /boot! Hãy dùng công cụ chuẩn của hệ thống như apt autoremove để dọn dẹp sạch sẽ mà không làm hỏng cấu trúc GRUB bootloader.

Đồng thời, hãy ghi nhớ danh sách các dịch vụ đang hoạt động trên máy để làm cơ sở đối chiếu sau khi cập nhật xong. Nếu VPS của bạn mới ở chặng đầu của lộ trình và chỉ mới cài mỗi OpenSSH (chưa cài NGINX, PHP-FPM hay MariaDB), thì việc hệ thống báo “unit not found” khi hỏi thăm các dịch vụ web là chuyện hoàn toàn bình thường, đừng hoảng hốt tưởng vừa cập nhật hỏng máy nhé.

Bước 2: Làm mới danh mục gói (Metadata) và chạy mô phỏng kế hoạch

lab_apt_plan_ready=no
sudo apt update &&
  apt list --upgradable &&
  apt-get -s upgrade &&
  lab_apt_plan_ready=yes

Nhiều anh em mới vào nghề hay nhầm lẫn giữa hai lệnh đầu tiên: thực chất apt update chỉ làm nhiệm vụ tải bảng danh mục phiên bản mới nhất từ các kho chứa (repositories) về máy chứ chưa hề nâng cấp bất kỳ phần mềm nào. Chuỗi lệnh trên được nối bằng toán tử && để đảm bảo hễ một mắt xích báo lỗi là dừng lại ngay. Nếu bạn gặp cảnh báo sai chữ ký GPG, lỗi phân giải tên miền kho chứa hoặc tải danh mục dở dang, hãy giữ biến cờ lab_apt_plan_ready=no, xử lý dứt điểm lỗi kết nối rồi mới chạy lại Bước 2. Tuyệt đối không dùng các cờ ép buộc bỏ qua xác thực chữ ký bảo mật từ những nguồn không rõ ràng.

Lệnh mô phỏng apt-get -s upgrade (cờ -s nghĩa là simulate/dry-run) cực kỳ lợi hại: nó cho bạn xem trước toàn bộ kịch bản những gói nào sẽ được nâng cấp mà không chạm vào một byte dữ liệu thật nào trên đĩa. Nếu bạn thấy một vài gói nằm trong danh sách “kept back” (bị giữ lại chưa nâng ngay), đừng vội vàng gõ lệnh ép buộc kiểu full-upgrade hay dist-upgrade. Rất có thể đó là cơ chế Phased Updates (triển khai bản cập nhật theo từng đợt nhỏ để nghe ngóng lỗi) của Ubuntu hoặc do gói đó đòi hỏi cài thêm phụ thuộc mới. Hãy tìm hiểu rõ nguyên nhân trước khi quyết định.

Bước 3: Chạy cập nhật tương tác trong khung giờ bảo trì

Sau khi đã đọc kỹ bản kế hoạch mô phỏng, xác nhận có đủ bản sao lưu và sẵn sàng đường Console, bạn hãy chạy khối lệnh nâng cấp ngay trong phiên shell vừa thực hiện Bước 2:

if [ "${lab_apt_plan_ready:-no}" = yes ]; then
  sudo apt upgrade
else
  printf '%s\n' 'Dừng: cần hoàn tất và kiểm tra lại bước 2 trước.' >&2
fi

Khi APT liệt kê danh sách các gói sẽ nâng cấp cùng tổng dung lượng tải về, hãy dành 30 giây đọc lướt qua một lượt trước khi bấm phím xác nhận. Với những người quản trị cẩn thận, việc giữ nguyên chế độ hỏi đáp tương tác (không truyền cờ -y tự động đồng ý tất cả) là một thói quen rất đáng quý. Trong quá trình cài đặt, nếu hệ thống bật hộp thoại hỏi bạn muốn xử lý thế nào với một tệp cấu hình đã bị chỉnh sửa trước đó (chẳng hạn sshd_config hay cloud.cfg), hãy chọn chức năng xem bản so sánh (diff) rồi mới quyết định: nếu nhắm mắt chọn bản mới của nhà phát triển (maintainer version), mọi tinh chỉnh riêng của bạn sẽ bay màu; ngược lại, giữ khư khư bản cũ cũng cần xem có bỏ lỡ tham số mới quan trọng nào không.

Tương tự, trên Ubuntu 24.04, công cụ needrestart sẽ tự động phát hiện các dịch vụ đang dùng thư viện cũ trong RAM và hỏi bạn có muốn khởi động lại chúng ngay lập tức hay không. Hãy đối chiếu với kế hoạch bảo trì của bạn để xác nhận. Trong suốt lúc APT đang giải nén và cấu hình gói, tuyệt đối không bấm Ctrl+C hay đóng ngang cửa sổ Terminal. Nếu mạng chập chờn, việc sử dụng công cụ giữ phiên như tmux hoặc screen sẽ là cứu cánh tuyệt vời.

Một lưu ý sống còn khác: nếu bạn gõ lệnh mà gặp thông báo “Could not get lock /var/lib/dpkg/lock-frontend”, nghĩa là tiến trình cập nhật tự động ngầm (unattended-upgrades) của Ubuntu đang làm việc. Hãy kiên nhẫn pha tách trà đợi nó chạy xong. Đừng bao giờ nghe theo các mẹo trên mạng mà gõ lệnh xóa file lock! Việc xóa file khóa trong khi tiến trình nền vẫn đang ghi dữ liệu chẳng khác nào tháo chốt cửa khi người bên trong đang sửa ống nước — cơ sở dữ liệu gói dpkg sẽ bị hỏng nặng ngay lập tức.

Sơ đồ luồng thao tác trong khung giờ bảo trì do localhost.vn biên soạn để minh họa các bước kiểm soát rủi ro.

Bước 4: Kiểm tra cờ báo hiệu cần khởi động lại máy chủ (Reboot)

test -f /var/run/reboot-required && cat /var/run/reboot-required
test -f /var/run/reboot-required.pkgs && cat /var/run/reboot-required.pkgs
systemctl --failed --no-pager

Khi các gói hệ thống cốt lõi như nhân Linux (kernel), thư viện glibc hay systemd được cập nhật, Ubuntu sẽ tự động tạo ra tệp đánh dấu /var/run/reboot-required kèm danh sách các gói tạo ra yêu cầu đó trong reboot-required.pkgs. Dù bạn vừa tải về bản kernel mới tinh, câu lệnh uname -r vẫn sẽ hiển thị phiên bản kernel cũ đang nằm trong bộ nhớ cho đến khi máy chủ thực sự được khởi động lại.

Trước khi gõ lệnh khởi động lại, hãy rà soát nhanh một vòng cuối: mình đang đứng ở đúng con VPS cần reboot chứ không phải gõ nhầm vào cửa sổ máy chủ khác, rule mở cổng SSH trên UFW vẫn còn nguyên, và không có tiến trình ghi cơ sở dữ liệu nào đang chạy dở. Khi mọi thứ đã sẵn sàng, hãy chạy lệnh:

sudo reboot

Ngay sau khi nhấn Enter, kết nối SSH hiện tại bị ngắt là hiện tượng hoàn toàn bình thường. Bạn hãy mở giao diện Cloud Panel hoặc màn hình Console để quan sát quá trình tắt/bật máy, chờ khoảng 30 giây đến một phút rồi mới thử kết nối lại. Tuyệt đối đừng sốt ruột bấm nút Reboot liên thanh trên bảng điều khiển chỉ vì mới qua 10 giây mà chưa thấy máy trả lời ping.

Bước 5: Đăng nhập lại sau Reboot và nghiệm thu toàn bộ dịch vụ

Khi kết nối lại vào VPS, hãy đảm bảo trình khách SSH xác nhận đúng dấu vân tay máy chủ (host fingerprint) như cũ. Một đợt nâng cấp gói thông thường hoàn toàn không bao giờ làm thay đổi Host Key của máy chủ; nếu thấy cảnh báo đổi khóa định danh, bạn phải kiểm tra lại ngay lập tức.

whoami
hostname
uname -r
uptime
systemctl --failed --no-pager
systemctl status ssh.service ssh.socket --no-pager

Lúc này, uptime sẽ báo thời gian hoạt động mới chỉ vài phút và uname -r sẽ hiển thị phiên bản kernel mới nhất nếu đợt cập nhật vừa rồi có nâng cấp nhân hệ điều hành. Xin nhắc lại một chi tiết nhỏ: trên Ubuntu 24.04 dùng socket activation, việc bạn vừa đăng nhập SSH thành công đã chứng minh đường truyền hoàn hảo, đừng thấy một unit phụ trợ báo inactive mà tưởng lầm SSH bị lỗi.

Nếu VPS đang vận hành website WordPress, quy trình nghiệm thu bắt buộc phải đi sâu tới tầng ứng dụng: kiểm tra cú pháp nginx -t, xác nhận trạng thái của nginx, đúng phiên bản php-fpm cùng mariadb, sau đó mở trình duyệt truy cập thực tế vào trang chủ, bài viết con, hình ảnh media và trang đăng nhập quản trị. Chỉ khi toàn bộ trang web phản hồi mượt mà, ổ đĩa ghi đọc bình thường và không có một dịch vụ nào nằm trong danh sách systemctl --failed, ca bảo trì của bạn mới chính thức khép lại thành công.

Sơ đồ danh mục nghiệm thu sau khi máy chủ khởi động lại do localhost.vn biên soạn.

Hiểu đúng về cơ chế cập nhật tự động (Unattended Upgrades)

Mặc định, Ubuntu Server cài sẵn dịch vụ unattended-upgrades để tự động tải và vá các lỗ hổng bảo mật quan trọng. Tuy nhiên, việc nó cập nhật từ những kho chứa nào, chạy vào mấy giờ và có tự động reboot máy chủ lúc nửa đêm hay không hoàn toàn phụ thuộc vào các tệp cấu hình trong /etc/apt/apt.conf.d/. Ngoài ra, nếu sau này bạn thêm các kho chứa bên thứ ba (như kho NGINX hoặc PHP Ondrej), mặc định unattended-upgrades sẽ không tự động nâng cấp các gói ngoại lai đó đâu.

Đối với các máy chủ đang chạy website quan trọng, bạn nên đọc kỹ cấu hình trong /etc/apt/apt.conf.d/50unattended-upgrades để nắm rõ chính sách tự khởi động lại (Unattended-Upgrade::Automatic-Reboot), tránh cảnh hệ thống tự ý reboot đúng giờ cao điểm. Hãy đồng bộ cấu hình này với lịch trực và quy trình bảo trì thực tế của đội ngũ vận hành.

Hồ sơ khảo sát trước bảo trì trên máy chủ LAB-CF-02 (01/10/2026)

Vào lúc 04:05:36 ngày 01/10/2026 (giờ Việt Nam), máy chủ LAB-CF-02 đang chạy Ubuntu 24.04 với nhân 6.8.0-40-generic. Chúng tôi thực hiện lượt đọc thông số nền và chạy thử mô phỏng nâng cấp gói, thu được kết quả chi tiết như bảng sau:

Sáu gói nằm trong diện “kept back” (giữ lại) bao gồm: fwupd, linux-headers-generic, linux-headers-virtual, linux-image-virtual, linux-virtual và sosreport. Vì lệnh apt-mark showhold trả về rỗng, chúng ta biết chắc các gói này không phải do quản trị viên khóa tay, mà do cơ chế phụ thuộc gói mới hoặc chính sách phát hành theo đợt của Ubuntu.

Khi đọc cấu hình tự động cập nhật, hệ thống ghi nhận Update-Package-Lists=1 và Unattended-Upgrade=1, trong khi tham số tự động reboot không được bật tường minh. Cả hai tệp cờ báo hiệu reboot-required đều chưa xuất hiện tại thời điểm 04:05 sáng ngày 01/10. Lượt khảo sát này hoàn toàn giữ nguyên trạng thái hệ thống để chuẩn bị cho ca bảo trì thực sự vào ngày hôm sau.

Nhật ký ca cập nhật 152 gói và Reboot thực tế ngày 02/10/2026

Trong khung giờ 11:07–11:09 ngày 02/10/2026 (giờ Việt Nam), chúng tôi bước vào ca bảo trì thực tế trên LAB-CF-02. Khám sức khỏe đầu giờ cho thấy phân vùng gốc còn trống khoảng 37,2 GB, phân vùng boot còn 739 MB, mọi dịch vụ hoạt động bình thường và danh sách gói ghim (hold) trống rỗng. Tiến trình nền unattended-upgr chỉ đang nằm chờ tín hiệu hệ thống chứ không hề giữ khóa apt/dpkg.

Sau khi chạy lệnh làm mới chỉ mục apt-get -o APT::Update::Error-Mode=any update thành công (mã thoát 0), lệnh mô phỏng apt-get -s upgrade trên bộ danh mục mới nhất báo cáo có 152 gói cần nâng cấp, 0 gói cài mới, 0 gói xóa và 6 gói giữ lại. (Sở dĩ con số giảm từ 334 của ngày hôm trước xuống 152 là do tiến trình bảo mật tự động của Ubuntu đã âm thầm xử lý một phần các bản vá trong đêm).

Để đảm bảo an toàn tuyệt đối trước khi nhấn nút nâng cấp, chúng tôi tạm dừng hai dịch vụ PHP-FPM và MariaDB, đồng bộ dữ liệu xuống đĩa (sync) rồi tạo một bản Snapshot mới cho máy chủ trên bảng điều khiển CloudFly (dung lượng ghi nhận 5,96 GB, trạng thái active, giao diện lúc tạo hiển thị mức phí 0đ/GB/giờ tại thời điểm quan sát), sau đó bật lại các dịch vụ web. Song song đó, một bộ sao lưu thủ công gồm toàn bộ mã nguồn, tệp cấu hình và 2 tệp dump SQL của các trang WordPress thử nghiệm (tổng dung lượng 253.638.653 byte) cũng được đóng gói, kiểm tra mã băm SHA và lưu trữ bảo mật. Lưu ý khách quan: chúng tôi tạo Snapshot để làm phao cứu sinh dự phòng chứ chưa chạy thử nghiệm khôi phục (restore) bản Snapshot này.

Tiếp theo, chúng tôi chạy lệnh apt-get upgrade ở chế độ tương tác trực tiếp. Sau khi đối chiếu danh sách 152 gói khớp hoàn toàn với bước mô phỏng, quản trị viên nhập y xác nhận: APT tải về 84,1 MB gói cài đặt và dung lượng đĩa chỉ tăng thêm 1.369 kB. Giữa quá trình cài đặt, hệ thống dừng lại hỏi ý kiến về tệp cấu hình /etc/cloud/cloud.cfg. Qua bước đối chiếu nội dung thay đổi, chúng tôi nhận thấy bản mới từ nhà phát triển có chỉnh sửa danh sách module và thiết lập tài khoản root, nên đã quyết định chọn N để giữ nguyên tệp cấu hình hiện hành của máy chủ. Đây là quyết định dựa trên việc đọc hiểu thay đổi thực tế, không phải thói quen nhắm mắt bấm N cho mọi trường hợp.

Đúng 11:17:39, quá trình nâng cấp kết thúc trọn vẹn với mã thoát 0. Tổng cộng 152 gói phần mềm được lên đời, không có bất kỳ gói nào bị gỡ bỏ; mã băm (SHA hash) của các tệp cấu hình NGINX, SSH, cloud.cfg cùng mã nguồn WordPress đều giữ nguyên vẹn. Trong log xuất hiện một dòng cảnh báo từ gói GRUB EFI rằng không ghi được biến môi trường EFI; tuy nhiên, qua kiểm tra thực tế máy ảo này đang khởi động theo chuẩn BIOS (i386-pc) truyền thống, nhánh cập nhật GRUB BIOS đã báo thành công và lệnh kiểm tra cú pháp grub-script-check trả về mã 0 an toàn. Nhờ phân tích đúng bản chất kiến trúc khởi động, chúng ta hoàn toàn yên tâm tiến hành reboot mà không cần can thiệp sửa chữa bootloader một cách mù quáng.

Đúng 11:18:34, lệnh reboot được gửi đi. Chỉ mất đúng 26 giây, vào lúc 11:19:00, phiên kết nối SSH mới đã đăng nhập lại thành công với đúng dấu vân tay máy chủ đã ghim. Mã boot ID đã thay đổi và nhân hệ điều hành đang chạy chính thức chuyển từ 6.8.0-40-generic lên 6.8.0-142-generic (bản kernel 142 này vốn đã được tải sẵn về máy từ trước ca bảo trì và nay chính thức được nạp vào RAM sau cú reboot). Kết quả nghiệm thu hậu bảo trì: toàn bộ cụm NGINX, PHP 8.3-FPM, MariaDB và SSH socket đều active xanh mượt, không có dịch vụ nào lỗi, dpkg --audit sạch bóng, trang web thử nghiệm trả mã HTTPS 200 với chứng chỉ TLS hợp lệ và tệp cờ reboot-required đã tự động biến mất.

Ảnh chụp thực tế trang Thông tin Máy chủ (Site Health Info) bên trong quản trị WordPress lúc 11:19:28 ngày 02/10/2026 (UTC+7), ngay sau khi máy chủ khởi động lại: dòng Kiến trúc Linux hiển thị rõ nhân mới 6.8.0-142-generic chạy cùng NGINX và PHP-FPM. Bấm vào ảnh để xem kích thước đầy đủ.

Ảnh chụp giao diện bài viết WordPress mở bằng trình duyệt ở chế độ khách (không đăng nhập) trên máy tính để bàn: đường dẫn tĩnh (permalink) hoạt động trơn tru và trả về mã trạng thái HTTPS 200 sau đợt reboot.

Ảnh chụp cùng bài viết trên khung nhìn thiết bị di động (chiều rộng 390px) trong đợt nghiệm thu hậu bảo trì, xác nhận giao diện hiển thị chuẩn xác và không bị vỡ bố cục.

Bên cạnh việc kiểm tra giao diện khách, chúng tôi cũng đăng nhập vào trang quản trị WordPress để kiểm tra thông số máy chủ rồi thực hiện đăng xuất (logout) để xác nhận phiên làm việc đóng lại đúng chuẩn về biểu mẫu đăng nhập. Đáng chú ý, phiên bản PHP-FPM vẫn giữ ở mức 8.3.6 và NGINX ở mức 1.24.0 — điều này minh họa rõ rằng việc nhân Linux nhảy số phiên bản không đồng nghĩa mọi phần mềm trên máy đều đổi số hiệu. Sau khi hoàn tất mọi bước nghiệm thu, bản Snapshot tạm thời ngày 02/10 cùng các tệp backup phục vụ ca bảo trì đã được đối chiếu mã băm và dọn dẹp gọn gàng để giải phóng tài nguyên.

Xử lý sự cố thường gặp và phương án khôi phục (Rollback)

Nếu chẳng may quá trình nâng cấp bị gián đoạn giữa chừng, việc đầu tiên bạn cần làm là bình tĩnh chép lại nguyên văn dòng thông báo lỗi đầu tiên xuất hiện trên màn hình, kiểm tra ngay dung lượng trống bằng df -h và xem trạng thái gói bằng dpkg --audit. Tuyệt đối không vội vàng gõ lệnh reboot khi biết chắc quá trình cấu hình gói kernel hoặc bootloader đang bị treo dở dang. Nếu nguyên nhân do đầy ổ đĩa, hãy dọn dẹp các tệp log cũ hoặc cache gói cài đặt (apt clean) trước khi chạy lệnh hoàn tất cấu hình dpkg --configure -a.

Trong tình huống xấu nhất khi máy chủ không thể khởi động lên sau lệnh reboot, hãy mở ngay giao diện VNC Console trên bảng điều khiển của nhà cung cấp để nhìn tận mắt thông báo lỗi trên màn hình khởi động (chẳng hạn lỗi Kernel Panic hay kẹt ở menu GRUB). Tại menu GRUB, bạn thường có thể chọn dòng “Advanced options for Ubuntu” để khởi động tạm vào phiên bản Kernel cũ vẫn còn lưu trên máy. Lưu ý đừng bao giờ bấm nút Rebuild / Reinstall OS trên bảng điều khiển trừ khi bạn chấp nhận xóa trắng toàn bộ máy chủ để dựng lại từ đầu!

Trong thế giới Linux, việc hạ cấp (downgrade) hàng trăm gói phần mềm cùng lúc qua APT là điều cực kỳ rủi ro và hầu như không khả thi. Do đó, phương án khôi phục (rollback) đáng tin cậy nhất luôn là quay về bản Snapshot đã chụp ngay trước ca bảo trì, hoặc dựng lại máy mới từ các bản sao lưu cấu hình và dữ liệu đã được chuẩn bị kỹ lưỡng.

Câu hỏi thường gặp (FAQ)

Lệnh apt update và apt upgrade khác nhau ở điểm nào?

Hãy hình dung apt update giống như việc bạn cầm thực đơn mới nhất của nhà hàng lên đọc xem hôm nay có món gì mới và giá cả ra sao (làm mới danh mục gói từ máy chủ kho chứa). Còn apt upgrade mới là lúc đầu bếp thực sự mang nguyên liệu ra nấu và dọn món mới lên bàn cho bạn (tải gói mới về và cài đặt đè lên phiên bản cũ).

Có phải cứ chạy apt upgrade xong là bắt buộc phải reboot máy chủ không?

Không phải lúc nào cũng cần. Nếu đợt cập nhật chỉ nâng cấp các công cụ nhỏ hoặc dịch vụ thông thường (như curl, git, nginx), bạn chỉ cần khởi động lại đúng dịch vụ đó là xong. Bạn chỉ thực sự cần reboot toàn bộ VPS khi cập nhật nhân hệ điều hành (linux-kernel) hoặc các thư viện nền tảng mà mọi tiến trình đều phụ thuộc, khiến hệ thống sinh ra tệp cờ /var/run/reboot-required.

Tôi có nên tiện tay chạy luôn lệnh do-release-upgrade không?

Tuyệt đối không làm việc đó một cách ngẫu hứng! Lệnh do-release-upgrade dùng để nâng cấp toàn bộ hệ điều hành lên một thế hệ mới (ví dụ từ Ubuntu 22.04 lên 24.04), kéo theo sự thay đổi hàng loạt phiên bản PHP, thư viện hệ thống và cú pháp cấu hình. Công việc đó đòi hỏi một kế hoạch kiểm thử tương thích riêng biệt chứ không nằm trong quy trình bảo trì định kỳ hàng tuần.

Tài liệu tham khảo và bước tiếp theo

Tài liệu chính thức về Quản lý gói phần mềm trên Ubuntu (Package Management) và Cập nhật tự động (Automatic Updates) đã được chúng tôi đối chiếu lại vào ngày 02/10/2026; tài liệu Ubuntu OpenSSH Server giữ mốc tham chiếu ngày 30/09/2026. Khi áp dụng cho máy chủ của mình, bạn hãy chọn một khung giờ vắng khách, chụp sẵn Snapshot hoặc sao lưu dữ liệu, chạy mô phỏng theo Bước 2 rồi mới tiến hành nâng cấp và nghiệm thu toàn diện sau khi khởi động lại. Mời bạn tiếp tục theo dõi các bài hướng dẫn kế tiếp trong lộ trình cài đặt WordPress trên VPS từ A đến Z.