Checklist WordPress ngày đầu Go-Live: Backup, phân quyền và kịch bản Rollback an toàn

Phạm vi thực hành: Toàn bộ thao tác được thực hiện trên Ubuntu 24.04 LTS tại máy chủ VPS thử nghiệm riêng biệt, lấy tên minh họa là lab-cf02.localhost.vn. Nguyên tắc bất di bất dịch: bạn chỉ chạm vào tài sản hạ tầng do chính mình quản lý. Các hạng mục về Backup, Restore và bảo toàn dữ liệu phát sinh mới đã có số liệu thực nghiệm trên lab, được tách bạch rõ ràng với những điều kiện bàn giao chưa hoàn tất ở bảng tổng kết cuối bài. Máy lab này đóng vai trò môi trường diễn tập kỹ thuật, chưa phải một website thương mại đã nghiệm thu hoàn chỉnh.

Nhiều anh em kỹ thuật có thói quen thở phào nhẹ nhõm ngay khoảnh khắc trỏ DNS xong và thấy trang chủ hiện lên mượt mà. Nhưng thực tế phũ phàng là lúc website vừa mở cửa đón khách cũng chính là lúc rủi ro vận hành bắt đầu rình rập: mail thông báo có đi không, quyền truy cập đang nằm trong tay những ai, và nhỡ tay cập nhật lỗi thì lấy gì cứu? Một Checklist WordPress ngày đầu rõ ràng sẽ giúp bạn chốt toàn bộ các bài kiểm tra sống còn và phân công trách nhiệm minh bạch chỉ trong một buổi bàn giao gọn gàng.

Ghi mốc bắt đầu vận hành

Việc đầu tiên của một người làm hạ tầng chỉn chu không phải là lao vào gõ lệnh, mà là lập hồ sơ khai sinh cho hệ thống. Hãy ghi chép đầy đủ: tên miền chính thức, thông tin VPS hoặc site đang quản lý, thời điểm chính xác mở truy cập (Go-Live), phiên bản cụ thể của WordPress, PHP, MariaDB, danh sách theme/plugin đang kích hoạt và tên người chịu trách nhiệm chính. Lưu ý sống còn: tài liệu chia sẻ chung chỉ được phép ghi nơi lưu trữ khóa bí mật (secret manager/vault) cùng danh sách nhân sự có thẩm quyền trích xuất theo quy trình nội bộ, tuyệt đối không dán mật khẩu hay credential trần trụi vào file văn bản.

Song song đó, hãy định danh ngay những luồng dữ liệu động bắt đầu nảy sinh từ giây phút mở site: bài viết mới, tệp media vừa tải lên, lượt gửi form liên hệ, tài khoản thành viên mới đăng ký, đơn hàng thương mại điện tử hoặc lịch đặt hẹn. Đây chính là những tài sản dễ bay màu nhất nếu bạn thực hiện Rollback thiếu suy nghĩ. Cùng chạy WordPress trên một cấu hình VPS y hệt nhau, nhưng một trang landing page giới thiệu công ty tĩnh lặng sẽ có bài toán khôi phục hoàn toàn khác biệt so với một cửa hàng trực tuyến đang nổ đơn từng phút.

Sơ đồ quy trình do đội ngũ localhost.vn biên soạn nhằm tóm tắt tư duy bàn giao; không phải ảnh chụp màn hình hay bằng chứng thực thi từ máy lab.

1. Backup đủ thành phần và có bản ngoài máy

Một sai lầm kinh điển của người mới quản trị VPS là cứ thấy có file nén dung lượng vài trăm MB là yên tâm đi ngủ. Hãy đối chiếu kỹ xem bộ Backup của bạn đã gom đủ bộ tứ bất khả phân ly chưa: mã nguồn WordPress, thư mục wp-content (chứa uploads, theme, plugin), cơ sở dữ liệu MariaDB và các file cấu hình hệ thống để dựng lại máy chủ từ con số không. Nhớ kỹ nhé: chỉ giữ bản dump Database thì khôi phục xong bài viết sẽ toàn khung ảnh rỗng; ngược lại, chỉ nén mỗi đống file trên đĩa mà quên xuất SQL thì toàn bộ bài vở, đơn hàng nằm trong MariaDB coi như bốc hơi. Bạn cần đóng dấu thời gian (timestamp) cho từng thành phần để biết chắc chúng thuộc cùng một mốc nhất quán (consistency point) hay đang lệch pha nhau.

Đối với bản sao lưu đặt ngoài VPS (offsite backup), hãy quy định rõ ai có quyền truy cập và chính sách giữ lại (retention policy) kéo dài bao lâu. Tuyệt đối tránh thói quen tiện tay ném file nén .tar.gz hay .zip ngay trong /var/www: nếu VPS gặp sự cố hỏng ổ cứng thì bản sao lưu cũng chôn theo máy, chưa kể nguy cơ khách vãng lai hoặc bot dò ra đường dẫn và tải trọn bộ dữ liệu của bạn về làm kỷ niệm. Vì bản sao lưu chứa cả mật khẩu băm lẫn dữ liệu cá nhân của khách hàng, việc mã hóa (encryption) và siết chặt quyền đọc là yêu cầu bắt buộc chứ không phải tùy chọn thêm cho đẹp.

Nếu bạn sử dụng WP-CLI để thao tác, hãy xuất Database ra một thư mục độc lập nằm hẳn bên ngoài web root theo đúng quy chuẩn sao lưu đã thiết kế. Đừng quên rà soát dung lượng đĩa còn trống, quyền sở hữu thư mục và trạng thái ghi dữ liệu trước khi bấm Enter chạy lệnh. Các bài tiếp theo trong cẩm nang sẽ mổ xẻ sâu về tính nhất quán, đóng gói archive và quy trình Restore chi tiết; nhưng ngay trong ngày đầu tiên, bạn bắt buộc phải trả lời được câu hỏi: bản sao lưu mới nhất đang nằm ở đâu và khi cần thì kéo về bằng cách nào.

2. Xác nhận phục hồi, không chỉ tạo backup

Trong giới SysAdmin có một định luật bất hủ: một bản sao lưu chưa từng được khôi phục thử thành công thì chỉ là “Backup của Schrödinger” — nó vừa tồn tại vừa vô dụng cho đến khi thảm họa thực sự ập đến. Hãy bốc ngẫu nhiên một bản Backup cụ thể từ danh sách lưu trữ, tải về, giải nén archive và đọc thử file SQL dump bằng đúng bộ công cụ bạn dự định dùng lúc cấp cứu. Bước tiếp theo là dựng một môi trường Staging hoặc thư mục độc lập thứ hai để diễn tập Restore thực tế, trong đó nhớ khóa chặt đường gửi mail ra ngoài và chặn mọi luồng traffic production. Sau khi dựng xong, hãy vào tận nơi kiểm tra bài viết, hình ảnh, chức năng đăng nhập và các luồng nghiệp vụ cốt lõi.

Trong lúc diễn tập, hãy bấm đồng hồ đo tổng thời gian khôi phục thực tế (hướng tới chỉ số RTO) và tính toán lượng dữ liệu tối đa có thể bị rơi rớt dựa trên độ trễ của chu kỳ sao lưu (chỉ số RPO). Nếu bạn chưa từng tự tay chạy xong quy trình khôi phục này, hãy dũng cảm ghi vào biên bản trạng thái “chưa xác minh phục hồi”. Một dòng thông báo cronjob hay tác vụ upload trả về mã thoát exit code 0 chỉ báo hiệu file đã bay lên kho lưu trữ, chứ hoàn toàn không đảm bảo file đó đủ sức cứu sống website của bạn lúc nửa đêm.

Điểm lại hồ sơ thực nghiệm ngày 01/10 trên máy LAB-CF-02, chúng ta đã thực hiện hai đợt Restore độc lập: đợt lúc 12:21 sử dụng bộ sao lưu giữ sẵn trên VPS; đợt lúc 12:36 kéo bản Backup đã mã hóa về máy Mac, giải mã rồi đẩy ngược lên lại để dựng một trang WordPress hoàn toàn mới trong thư mục và Database tách biệt trên cùng VPS. Cả hai lần đều đã xác minh trang chủ, cấu trúc permalink và luồng đăng nhập quản trị thông qua HTTP client. Tuy nhiên, do bộ dữ liệu gốc lúc đó có 0 bản ghi attachment và tệp trong thư mục uploads chỉ là file văn bản gắn nhãn thử nghiệm, bài toán khôi phục thư viện ảnh (Media Library) thực tế vẫn cần được đánh dấu là chưa nghiệm thu. Ngoài ra, vì chưa đo trọn vẹn từ khâu phát hiện sự cố, xin cấp quyền, khởi tạo VPS mới cho đến lúc bàn giao, chúng ta vẫn chưa chốt được con số RTO cuối cùng.

Vào lúc 13:21:03–08 ngày 01/10, một phép thử SQL độc lập khác đã sử dụng trình khách MariaDB native để nạp bản dump vào một Database tạm thời. Kết quả đối chiếu cho thấy toàn bộ 12 bảng đều khớp hoàn toàn về cấu trúc lẫn số dòng bản ghi, mã băm (hash) của các trường nội dung bài viết trùng khớp tuyệt đối và lệnh CHECK TABLE trả về trạng thái OK trên mọi bảng. Đây là mảnh ghép chứng minh tầng cơ sở dữ liệu toàn vẹn, nhưng tất nhiên nó chỉ bổ trợ chứ không thay thế cho việc khởi chạy ứng dụng WordPress hoàn chỉnh hay xác minh kho lưu trữ ngoài máy.

Ảnh chụp màn hình console thực tế từ phiên chạy lúc 13:21:16 ngày 01/10/2026 (UTC+7), ghi lại kết quả giám sát trình khách MariaDB thực thi trực tiếp. Đợt chạy này chuyên trách kiểm định tầng SQL và dọn dẹp Database tạm ngay sau đó; bức ảnh không dùng để tuyên bố rằng ứng dụng WordPress đã chạy trực tiếp trên Database ấy hay chứng minh quy trình offsite. Toàn bộ vùng hiển thị giữ nguyên pixel gốc kèm logo nhận diện; bạn có thể bấm vào ảnh để phóng to.

3. Rà tài khoản và quyền

Sau giai đoạn dựng web vội vã, danh sách người dùng thường rất lộn xộn. Hãy mở ngay trang quản trị WordPress để rà soát toàn bộ các tài khoản đang giữ quyền Administrator cùng những tài khoản tạo ra chỉ để test tính năng. Nguyên tắc vàng là mỗi cá nhân phải sử dụng một định danh riêng biệt; nhân sự chỉ làm nhiệm vụ viết bài hoặc biên tập nội dung thì chỉ cấp đúng vai trò Editor/Author, tuyệt đối không phát chẩn quyền Admin cho tiện. Với những tài khoản không còn nhu cầu sử dụng, hãy thu hồi hoặc xóa bỏ, nhưng nhớ gán lại quyền sở hữu các bài viết cũ sang tài khoản biên tập chính thức trước khi bấm nút xác nhận xóa.

Ở tầng hệ điều hành, hãy rà soát danh sách tài khoản có quyền sudo và toàn bộ các khóa trong authorized_keys của SSH để đảm bảo khớp với biên bản bàn giao. Nếu phát hiện một SSH key lạ hoắc không rõ lai lịch, hãy truy tìm chủ nhân và mục đích sử dụng trước khi thẳng tay cắt bỏ. Tương tự, với các API token kết nối dịch vụ DNS, gửi mail transactional (SMTP/API) hay kho lưu trữ Backup, bạn cần lập bảng theo dõi phạm vi quyền hạn, ngày hết hạn, người nắm giữ và quy trình thu hồi khẩn cấp khi có sự thay đổi nhân sự vận hành.

Tiếp theo, hãy đối chiếu phân quyền hệ thống tệp của wp-config.php, thư mục mã nguồn và nhánh uploads theo đúng chuẩn mực bảo mật ở bài 40. Hãy quét sạch các di sản nguy hiểm thường bị bỏ quên trong web root sau quá trình dev như file info.php, bản xuất .sql, gói nén .zip hoặc các file wp-config.php.bak. Đừng quên rà soát cả các bản sao lưu nội bộ lẫn kho lưu trữ ngoài máy, bởi khóa bí mật một khi đã lọt vào gói Backup thì cũng cần được bảo vệ nghiêm ngặt không kém gì máy chủ đang chạy.

Để bạn dễ hình dung, dưới đây là kết quả rà soát ở chế độ chỉ đọc (read-only) lúc 14:02:36 ngày 01/10 trên máy lab: tài khoản tutorial mang định danh UID/GID 1000 và nằm trong nhóm sudo; thư mục gốc cá nhân đặt quyền 750, thư mục .ssh khóa ở mức 700, còn tệp authorized_keys giữ chuẩn 600, tất cả đều thuộc quyền sở hữu của tutorial:tutorial. Chính sách thực thi sudo hiện rõ (ALL : ALL) ALL và hoàn toàn không bật cờ NOPASSWD. Lưu ý rằng đây là ảnh chụp hiện trạng kỹ thuật của tài khoản lab, chưa phải biên bản nghiệm thu bàn giao quyền quản trị cho chủ đầu tư.

Ảnh chụp console thực tế lúc 14:03:16 ngày 01/10/2026 (UTC+7), phản ánh kết quả truy vấn trạng thái chỉ đọc thực hiện lúc 14:02:36. Hình ảnh đã ẩn nội dung chuỗi khóa công khai và không phải là bằng chứng của thao tác thu hồi khóa hay thử nghiệm đăng nhập SSH mới. Dữ liệu ảnh được giữ nguyên độ phân giải gốc kèm logo; hãy nhấp vào ảnh để xem chi tiết.

Sơ đồ minh họa bốn trụ cột vận hành do localhost.vn thiết kế; không phải ảnh chụp màn hình hệ thống hay bằng chứng thực nghiệm trên lab.

4. Chốt lịch cập nhật có người theo dõi

Một hệ thống bị bỏ mặc không cập nhật sớm muộn cũng thành mồi ngon cho bot quét lỗ hổng, nhưng cập nhật bừa bãi không quy trình lại là con đường ngắn nhất dẫn tới màn hình trắng (White Screen of Death). Hãy phân công đích danh ai là người chịu trách nhiệm nâng cấp gói hệ điều hành Ubuntu, ai lo phần WordPress core, plugin và theme. Một chu trình chuẩn mực luôn đi theo thứ tự: đọc kỹ changelog xem có thay đổi gây gãy (breaking changes) nào không, tạo bản Backup mới nhất, thử nghiệm trước trên môi trường Staging nếu bản cập nhật lớn, tiến hành nâng cấp từng nhóm nhỏ rồi thực hiện smoke test ngay lập tức. Bạn hoàn toàn có thể bật tính năng tự động cập nhật (auto-update) cho các bản vá nhỏ, nhưng bắt buộc phải cấu hình kênh báo lỗi và có người rà soát lại giao diện sau khi hệ thống tự chạy.

Ngay trong ngày đầu tiên vận hành, hãy mạnh dạn dọn dẹp những plugin cài vào chỉ vì tâm lý “để đó mai mốt chắc sẽ dùng”. Mỗi thành phần giữ lại trên site đều cần được ghi rõ nguồn gốc cài đặt và phương thức cập nhật. Đặc biệt với các gói theme hoặc plugin trả phí (commercial/pro), hãy làm rõ ai đang giữ tài khoản bản quyền (license key) và thời hạn gia hạn là khi nào; rất nhiều website vẫn chạy bình thường cho đến khi phát hiện lỗ hổng bảo mật nghiêm trọng nhưng không tài nào tải được bản vá chỉ vì thẻ thanh toán gia hạn license đã hết hạn từ năm ngoái.

Hãy thiết lập lịch trình cố định để áp dụng các bản vá bảo mật định kỳ thay vì trì hoãn vô thời hạn. Kinh nghiệm xương máu của các đàn anh đi trước là hãy luôn chọn khung giờ cập nhật khi đội ngũ kỹ thuật đang tỉnh táo và sẵn sàng xử lý sự cố (đừng bao giờ bấm Update vào chiều thứ Sáu hoặc ngay trước kỳ nghỉ lễ dài ngày mà quản trị viên chính sắp tắt máy đi du lịch).

5. Quan sát site từ bên ngoài và từ VPS

Đừng chỉ nhìn website từ bên trong mạng nội bộ. Hãy đóng vai một người dùng bình thường truy cập vào URL chính thức, đọc thử một bài viết, điền form liên hệ và kiểm tra trang đăng nhập từ mạng bên ngoài. Đồng thời, trên cửa sổ dòng lệnh của VPS, hãy điểm danh nhanh tình trạng sức khỏe của ổ cứng, bộ nhớ RAM và các tiến trình cốt lõi:

df -h
free -h
systemctl is-active nginx php8.3-fpm mariadb

Những câu lệnh trên đóng vai trò như chiếc ống nghe của bác sĩ: chúng cho bạn biết nhịp đập tức thời của máy chủ ngay khoảnh khắc gõ lệnh, nhưng tất nhiên không thay thế được bài toán dự báo tải dài hạn. Hãy tập thói quen ghi nhận các chỉ số cơ sở (baseline) và mở file log ra đọc ngay khi thấy dấu hiệu bất thường. Quan trọng không kém là phải chỉ định người nhận thông báo cảnh báo (alert) khi website ngừng phản hồi (downtime), ổ đĩa sắp đầy hoặc chứng chỉ SSL/TLS gần hết hạn — và nhớ gửi thử một bức thư kiểm tra xem hộp mail nhận cảnh báo có đang hoạt động thật hay đã bị bộ lọc spam nuốt chửng.

Hãy tự tay gửi lại một lượt form liên hệ để xác nhận luồng email ngày mở site vẫn thông suốt. Nếu website có bật các lớp bộ nhớ đệm (Page Cache / Object Cache), hãy mở trình duyệt ở chế độ ẩn danh (Incognito) như một khách truy cập chưa đăng nhập, bởi giao diện mà tài khoản Admin nhìn thấy thường đi thẳng qua PHP chứ không phản ánh đúng trang tĩnh đang phục vụ công chúng. Với các công cụ đo lường như Analytics, chỉ đánh dấu hoàn tất sau khi bạn kiểm tra thấy sự kiện (event) được ghi nhận đúng thiết kế, và nhớ loại trừ các lượt truy cập thử nghiệm của đội kỹ thuật để tránh làm nhiễu số liệu báo cáo kinh doanh.

Dưới đây là lát cắt dữ liệu đo đạc dưới mức tải nhẹ vào lúc 14:23:38–44 ngày 01/10/2026 (UTC+7) trên máy lab: sáu mẫu thu thập liên tiếp từ PHP-FPM ghi nhận hàng đợi listen queue = 0, số tiến trình đang xử lý active = 1–2 trên tổng số total = 2; năm yêu cầu HTTP GET qua giao diện loopback đều trả về mã 200 OK với thời gian phản hồi byte đầu tiên (TTFB) trung vị đạt 0.154226 giây. Lưu ý kỹ thuật: công cụ lấy mẫu trạng thái tự tiêu tốn một worker trong pool chung, và bộ đếm truy vấn của MariaDB cũng bao gồm cả các câu lệnh giám sát. Việc thu thập được bức tranh số liệu này giúp bạn nắm trạng thái ban đầu, nhưng chưa đồng nghĩa với việc hệ thống cảnh báo tự động 24/7 đã được lắp đặt hoàn chỉnh.

Ảnh chụp màn hình thực tế từ phiên thu thập lúc 14:24:15 ngày 01/10/2026 (UTC+7), thể hiện kết quả đo trực tiếp của script hỗ trợ trong khung thời gian 14:23:38–44. Đây chỉ là ảnh chụp trạng thái tức thời, không phải biểu đồ lịch sử uptime, bài kiểm tra chịu tải (load test) hay bằng chứng đã tối ưu hóa hiệu năng. Khung ảnh giữ nguyên pixel gốc kèm logo; bấm vào ảnh để xem kích thước đầy đủ.

6. Viết điều kiện rollback bằng câu cụ thể

Khi sự cố xảy ra, tâm lý hoảng loạn rất dễ khiến người vận hành đưa ra quyết định sai lầm. Vì vậy, hãy viết sẵn điều kiện kích hoạt Rollback bằng những tiêu chí định lượng, rõ ràng và kiểm chứng được — ví dụ: “sau khi nâng cấp plugin, biểu mẫu liên hệ không lưu được bản ghi vào Database và lỗi tái diễn ở hai lần gửi thử liên tiếp”, hoặc “chức năng đăng nhập quản trị trả lỗi HTTP 500 khiến đội vận hành mất quyền kiểm soát”. Ngược lại, những cảm giác mơ hồ kiểu “hình như hôm nay web chạy hơi chậm” đòi hỏi bạn phải bình tĩnh đo đạc chỉ số và truy tìm nguyên nhân gây nghẽn trước, chứ tuyệt đối không vội vàng đè cả bản Backup Database cũ lên hệ thống.

Trong kịch bản khôi phục, hãy liệt kê cụ thể: những plugin nào có thể tắt nóng (deactivate) bằng WP-CLI để cô lập lỗi, file cấu hình vhost Nginx cũ nằm ở đâu, mốc bản sao lưu mã nguồn và SQL nào sẽ được sử dụng, ai là người có thẩm quyền ra lệnh Rollback và ai là người trực tiếp gõ lệnh. Đặc biệt, nếu website đã bắt đầu đón khách và phát sinh dữ liệu mới kể từ sau mốc Backup gần nhất, bạn bắt buộc phải có bước trích xuất và bảo toàn phần dữ liệu chênh lệch đó trước khi khôi phục. Đừng bao giờ dùng một bản Snapshot chụp từ đêm hôm qua để đè thẳng lên máy chủ lúc chiều nay nếu bạn không muốn làm bay màu hàng chục đơn hàng và thông tin khách hàng vừa đăng ký trong ngày.

Sơ đồ tư duy xử lý sự cố do localhost.vn biên soạn; không phải ảnh chụp màn hình hay kết quả chạy lệnh thực tế trên máy lab.

Mẫu biên bản ngày đầu

Một biên bản bàn giao xuất sắc không cần dài hàng chục trang giấy; điều cốt lõi là nó phải phản ánh trung thực trạng thái thực tế của hệ thống, gắn liền với tên người chịu trách nhiệm và đường dẫn tới bằng chứng kỹ thuật có thể tra cứu bất cứ lúc nào. Hãy duy trì thói quen cập nhật tài liệu này mỗi khi có đợt nâng cấp phần mềm hoặc thay đổi nhân sự tiếp quản, biến nó thành cuốn sổ tay sống của dự án thay vì cất vào ngăn kéo sau ngày ra mắt.

Đối chiếu checklist với bằng chứng đã có

Bảng tổng hợp dưới đây quy chuẩn toàn bộ mốc thời gian theo múi giờ Việt Nam (UTC+7). Mỗi dòng kết quả chỉ xác nhận đúng phạm vi của phép đo tương ứng, hoàn toàn không dùng để đánh đồng hay thay thế cho các hạng mục còn bỏ ngỏ trong checklist.

Lưu ý thêm khi đọc bảng: mốc 23:20 phản ánh thời điểm chúng ta rà soát tính cô lập của Database trên bản khôi phục đã dựng sẵn, chứ không phải thời gian chạy lệnh Restore. Các đợt thực nghiệm diễn ra trên cùng một máy chủ VPS cũng chưa mô phỏng được thảm họa sập toàn bộ phần cứng máy chủ vật lý. Chừng nào chưa đo đạc xong chỉ số RTO thực tế và chưa thiết lập hoàn chỉnh lịch trình cảnh báo cũng như cập nhật định kỳ, chúng ta vẫn chưa thể đặt bút ký nghiệm thu hoàn tất toàn bộ checklist ngày đầu.

Sau khi kết thúc chuỗi thực nghiệm, toàn bộ thư mục tạm, Database phụ và tài khoản người dùng thử nghiệm của hai đợt kiểm tra chức năng đều đã được dọn dẹp sạch sẽ; mã băm (hash) của hai file cấu hình trên các trang hiện hữu vẫn giữ nguyên vẹn. Việc thử nghiệm kéo file offsite thành công một lần bằng tay cũng chưa thể thay thế cho một lịch trình sao lưu tự động chạy bền bỉ mỗi ngày. Bước hành động tiếp theo là chỉ định rõ người cầm trịch, chốt kho lưu trữ dài hạn và chuẩn bị sẵn phương án máy chủ dự phòng độc lập. Dù bài tập giữ lại một bài viết đơn lẻ trước khi khôi phục đã thành công mỹ mãn, các hệ thống có đơn hàng hoặc biểu mẫu phức tạp vẫn cần kịch bản trích xuất riêng biệt — hãy luôn tự nhắc mình kiểm tra dữ liệu mới phát sinh trước khi bấm nút Rollback.

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

Tính năng Snapshot của nhà cung cấp VPS có thay thế được bản Backup ngoài máy không? Câu trả lời ngắn gọn là không nên đánh đồng. Snapshot và Offsite Backup phục vụ hai tầng rủi ro khác nhau. Bạn cần tìm hiểu kỹ xem Snapshot của nhà cung cấp có đảm bảo tính nhất quán cho MariaDB đang chạy không, quy trình khôi phục mất bao lâu, và đặc biệt là nếu chẳng may tài khoản quản lý tại nhà cung cấp VPS bị khóa hoặc mất quyền truy cập thì bạn lấy gì để khôi phục.

Một website cá nhân hoặc blog nhỏ có cần làm đủ ngần ấy bước không? Bạn hoàn toàn có thể rút gọn quy trình cho đỡ cồng kềnh, nhưng ba câu hỏi cốt lõi thì quy mô nào cũng phải trả lời được: bản sao lưu nằm ở đâu, ai đang nắm quyền cao nhất và khi sập thì khôi phục thế nào. Một trang blog nhỏ bé vẫn có thể bay màu toàn bộ công sức viết lách suốt nhiều năm chỉ vì một cú gõ nhầm lệnh rm -rf.

Khi nào thì chính thức khép lại giai đoạn ra mắt (Go-Live)? Đó là khi mọi chức năng cốt lõi đã vượt qua bài kiểm tra thực tế, mỗi đầu việc vận hành đều có chủ nhân rõ ràng và những hạng mục nào còn nợ lại đều được ghi nhận minh bạch trong biên bản. Ngay ở bài tiếp theo, chúng ta sẽ bắt tay vào biến quy trình Backup và Restore thành những thao tác thực chiến có số liệu đo đạc rõ ràng, thay vì chỉ nằm trên giấy.

Nguồn và bước tiếp theo

Tài liệu chính thức được đối chiếu ngày 01/10/2026: WordPress: backups, WordPress: file permissions, WP-CLI: DB export. Tài liệu WordPress: hardening giữ mốc tham chiếu ngày 30/09/2026. Toàn bộ kịch bản tình huống và biểu mẫu biên bản trong bài do đội ngũ biên tập xây dựng riêng cho chuỗi bài thực hành này.

Quay lại tổng quan tại lộ trình WordPress trên VPS. Bài trước đó: Sitemap, robots và Search Console sau ra mắt.