Có file backup không đồng nghĩa website có thể khôi phục thành công. Một bản backup có thể tồn tại nhưng thiếu database, thiếu uploads, hỏng archive, sai credential, lệch phiên bản PHP/MySQL hoặc không còn phù hợp với hạ tầng hiện tại. Chỉ đến lúc restore thật sự thất bại, khoảng trống giữa “backup job thành công” và “recovery capability” mới lộ rõ.
WordPress hiện nhấn mạnh rằng một website điển hình cần cả files và database để phục hồi đầy đủ. CISA khuyến nghị duy trì backup offline/encrypted và thường xuyên test availability, integrity trong kịch bản disaster recovery. NIST SP 1339 năm 2026 cũng coi việc tạo backup định kỳ, test backup và review trong recovery exercise là các ưu tiên cốt lõi. Nguồn: WordPress — Backups, CISA StopRansomware Guide và NIST SP 1339.
Bối cảnh: backup có nhưng restore vẫn fail
Giả sử website production gặp sự cố nghiêm trọng và đội vận hành chọn restore từ bản backup gần nhất. File backup có trên storage, timestamp nhìn hợp lệ và dashboard trước đó báo job thành công. Nhưng khi phục hồi, database import lỗi, wp-config không khớp credential mới, một phần uploads bị thiếu và website không thể boot đầy đủ.
Những tín hiệu cho thấy backup chưa restore-ready
- Backup chỉ có database hoặc chỉ có files.
- Archive tồn tại nhưng checksum/integrity chưa từng được kiểm tra.
- Không có tài liệu restore order, credential hoặc dependency cần thiết.
- Backup được tạo trước một thay đổi lớn về PHP, database hoặc hosting stack.
- Restore chưa từng được test trong môi trường tách biệt.
- RPO/RTO chỉ tồn tại trên giấy nhưng không có evidence đo thực tế.
Investigation: xác định restore thất bại ở lớp nào
Bước 1: kiểm tra backup set có đầy đủ không
WordPress phân biệt rõ database và files. Database chứa bài viết, settings và dữ liệu ứng dụng; files gồm core, theme, plugin, uploads, wp-config.php và các file web khác. Một backup set chỉ đầy đủ khi các thành phần cần thiết được lưu cùng thời điểm hợp lý và có thể ghép lại thành trạng thái website nhất quán.
Nếu database dump mới nhưng uploads cũ nhiều ngày, hoặc files được backup sau một deployment nhưng database lấy trước deployment, restore có thể tạo trạng thái lệch version/data dù từng artifact riêng lẻ vẫn hợp lệ.
Bước 2: kiểm tra integrity và khả năng đọc artifact
Backup cần được kiểm tra checksum, archive integrity, khả năng decompress/decrypt và khả năng đọc database dump. CISA nhấn mạnh việc test availability và integrity của backup trong disaster recovery scenario, vì backup không đọc được vào thời điểm recovery gần như tương đương không có backup.
Nếu backup được mã hóa, key hoặc recovery secret cũng là dependency cần được bảo vệ và kiểm tra khả năng truy cập. Không nên đợi đến lúc production down mới phát hiện key nằm trong account đã mất quyền truy cập.
Bước 3: kiểm tra environment và dependency mismatch
Restore có thể fail dù backup đúng nếu target environment khác quá nhiều: PHP extension thiếu, MySQL/MariaDB version không tương thích, web server config khác, DNS/SSL chưa sẵn sàng hoặc credential trong wp-config.php không còn đúng. Vì vậy recovery plan phải bao gồm cả application data lẫn infrastructure dependencies.
Đọc thêm Website Backup và kiểm tra backup có restore được không để chuẩn hóa backup set và restore verification.
Khi nào có thể xác nhận backup không recoverable?
Không nên kết luận chỉ vì một lần import lỗi do thao tác sai. Backup được coi là không recoverable khi artifact hoặc dependency khiến quá trình khôi phục đúng quy trình không thể hoàn tất trong điều kiện hợp lý.
- Backup set thiếu thành phần bắt buộc.
- Archive/database dump bị hỏng hoặc không thể đọc/decrypt.
- Restore đúng procedure vẫn không tạo được application state nhất quán.
- Dependency hoặc credential cần thiết không còn khả dụng và không có recovery path.
- Restore vượt xa RTO vì quy trình chưa từng được test hoặc tài liệu không đủ.
Remediation: biến backup thành recovery capability
Chuẩn hóa backup set và restore runbook
- Gắn database + files + config cần thiết thành một backup set logic.
- Ghi rõ timestamp, source, retention và checksum của từng artifact.
- Lưu restore order, credential dependency và version requirement.
- Tách backup khỏi cùng failure domain với production.
- Giữ owner rõ ràng cho backup job và restore procedure.
CISA khuyến nghị offline/encrypted backups và test procedure thường xuyên. Với website, Offsite Backup giúp giảm rủi ro cả production và backup cùng hỏng hoặc cùng bị mã hóa.
Đưa restore test thành control định kỳ
NIST SP 1339 nhấn mạnh backup phải được test và review trong recovery exercise. Restore test nên chạy trong môi trường tách biệt, xác minh database, files, login, frontend, admin, upload/media và các business flow quan trọng.
Không cần restore production mỗi tuần, nhưng phải có cadence phù hợp với mức độ thay đổi và criticality. Kết quả test nên ghi rõ PASS/FAIL, RPO đạt được, thời gian restore thực tế và blocker phát hiện được.
Dùng Backup & Recovery Maintenance Checklist để review định kỳ backup job, storage, retention, restore test và owner.
Validation sau khi sửa hệ thống backup
| Kiểm tra | Kết quả mong đợi |
|---|---|
| Backup set | Có đủ database, files và config cần thiết |
| Integrity | Checksum/archive/decryption PASS |
| Restore environment | Dependency và version tương thích |
| Database restore | Import hoàn tất không lỗi critical |
| File restore | Theme, plugin, uploads và config đầy đủ |
| Smoke test | Frontend, admin và business flow chính PASS |
| RPO/RTO | Được đo thực tế và nằm trong mục tiêu |
Bài học vận hành và bước tiếp theo
- Backup job success không đồng nghĩa restore success.
- WordPress thường cần cả files và database để phục hồi đầy đủ.
- Integrity test chỉ là một bước; restore test mới kiểm tra end-to-end recovery.
- Credential, encryption key và infrastructure dependency cũng là một phần của recovery capability.
- RPO/RTO phải được đo bằng exercise thay vì chỉ ước tính.
- Mỗi thay đổi lớn về hosting, PHP, database hoặc architecture nên kích hoạt review backup/restore procedure.