Khi server production hỏng hoàn toàn, giá trị của offsite backup mới thể hiện rõ: bản sao vẫn tồn tại ngoài failure domain của host chính, cho phép dựng lại website trên hạ tầng khác thay vì phụ thuộc vào disk, snapshot hoặc control plane đã mất.
WordPress khuyến nghị giữ nhiều bản backup ở các vị trí khác nhau và nhấn mạnh một site điển hình cần cả files lẫn database để restore đầy đủ. NIST contingency guidance cũng khuyến nghị lưu backup offsite hoặc tại alternate site, còn CISA khuyến nghị duy trì offline/encrypted backups và thường xuyên kiểm tra khả năng restore. Nguồn: WordPress — Backups, CISA StopRansomware Guide và NIST SP 1339.
Bối cảnh: production server mất nhưng backup vẫn còn độc lập
Giả sử một VPS gặp storage failure nghiêm trọng và không còn boot được. Local snapshot cùng nằm trong account/provider bị ảnh hưởng nên không thể dùng ngay. Tuy nhiên, hệ thống vẫn còn một bản backup offsite nằm ở storage/account khác, đủ files, database và config cần thiết.
Điều kiện để offsite backup thực sự cứu được website
- Bản sao nằm ngoài cùng failure domain với production.
- Backup set gồm đủ database, files và config cần thiết.
- Credential/decryption key của backup vẫn truy cập được khi production account gặp sự cố.
- Restore procedure đã từng được test hoặc ít nhất được tài liệu hóa đầy đủ.
- Có phương án dựng target environment thay thế tương thích.
- DNS, TLS và các dependency có thể được chuyển sang hạ tầng mới.
Investigation: xác định phạm vi failure trước khi restore
Bước 1: xác minh failure domain đã mất những gì
Không nên restore ngay khi chưa biết phạm vi sự cố. Cần xác định chỉ compute hỏng, hay cả block storage, snapshot, control panel, DNS, secrets và database managed service cùng bị ảnh hưởng. Nếu backup cũng nằm trong cùng provider/account và không truy cập được, đó chưa phải offsite protection đúng nghĩa.
NIST contingency planning khuyến nghị lưu backup ở offsite hoặc alternate site để recovery không phụ thuộc vào cùng hạ tầng đang gặp sự cố. Đây là điểm khác biệt cốt lõi giữa “backup copy” và “recovery copy độc lập”.
Bước 2: kiểm tra backup set và restore target
WordPress hiện ghi rõ files và database là hai thành phần tách biệt; muốn khôi phục đầy đủ cần cả hai. Trước khi dựng server mới, cần xác minh timestamp, integrity, database dump, uploads, plugin/theme, wp-config.php và các dependency bên ngoài như object storage hoặc email service.
Target recovery environment nên tương thích về PHP, database engine, web server và extension quan trọng. Nếu environment khác quá nhiều, offsite backup vẫn có thể restore chậm hoặc fail vì dependency mismatch.
Bước 3: đo RPO trước khi quyết định go-live
RPO thực tế được xác định bởi thời điểm bản backup cuối cùng còn usable so với thời điểm production failure. Nếu backup chạy mỗi 6 giờ, nhưng job gần nhất fail, data loss có thể lớn hơn mục tiêu thiết kế.
Đọc thêm Offsite Backup, Backup 3-2-1 và Website Backup Strategy để chuẩn hóa failure domain và RPO/RTO.
Recovery: dựng lại website từ failure domain khác
Khôi phục application trước, cutover traffic sau
- Dựng clean target environment ở provider/host thay thế.
- Restore files và database theo backup set đã xác minh.
- Cập nhật credential/config nếu infrastructure mới khác production cũ.
- Chạy smoke test cho frontend, admin, media upload và business flow chính.
- Chỉ chuyển DNS/traffic sau khi application state đã được read-back.
CISA khuyến nghị reconnect systems và restore dữ liệu từ offline/encrypted backups theo thứ tự ưu tiên dịch vụ, đồng thời tránh đưa hệ thống chưa sạch hoặc chưa xác minh vào recovery environment.
Tách recovery path khỏi production account
Một offsite copy chỉ thật sự hữu ích khi quyền truy cập, storage và credential không cùng single point of failure với production. Có thể dùng account khác, provider khác hoặc ít nhất storage policy độc lập với delete/credential scope của production.
Quy tắc Backup 3-2-1 giúp thiết kế ba bản sao, hai loại storage/failure domain và một bản offsite để tránh trường hợp server hỏng kéo theo toàn bộ backup.
Khi nào có thể xác nhận offsite backup đã giảm single point of failure?
Không nên kết luận chỉ vì backup nằm ở “cloud”. Cần chứng minh production failure không làm mất quyền truy cập hoặc phá hủy cùng bản sao.
- Production host/account không còn hoạt động nhưng offsite backup vẫn truy cập được.
- Backup có thể restore sang một target environment độc lập.
- Credential hoặc encryption key không phụ thuộc vào hệ thống đã hỏng.
- DNS/traffic có thể cutover sang recovery environment.
- RPO/RTO đo thực tế nằm trong mục tiêu đã đặt.
Validation sau khi website phục hồi
| Kiểm tra | Kết quả mong đợi |
|---|---|
| Backup accessibility | Không phụ thuộc production failure domain |
| Files/database restore | Hoàn tất và nhất quán |
| Application smoke test | Frontend/admin/business flow PASS |
| DNS/TLS cutover | Traffic đi đúng recovery environment |
| RPO | Data loss nằm trong mục tiêu |
| RTO | Thời gian recovery nằm trong mục tiêu |
| New backup cycle | Backup của recovery environment đã được tạo và test |
Bài học vận hành và bước tiếp theo
- Backup cùng server không bảo vệ khỏi server/storage failure.
- Offsite copy phải độc lập cả storage lẫn access path.
- Recovery plan cần bao gồm target environment, DNS, TLS và credential.
- RPO/RTO chỉ có giá trị khi được đo bằng restore exercise thực tế.
- Restore thành công phải đi kèm cutover và post-recovery backup mới.
- Mỗi thay đổi lớn về hosting/provider nên kích hoạt review failure domain của backup.