Một file backup tồn tại không chứng minh rằng website có thể phục hồi. Backup có thể bị truncate, archive hỏng, database dump không import được, thiếu uploads, sai key encryption hoặc phụ thuộc vào credential đã mất. Vì vậy restore test là quality gate quan trọng nhất của một hệ thống backup.
CISA khuyến nghị kiểm thử định kỳ availability và integrity của backup trong disaster recovery scenario. WordPress Developer Handbook cũng nhấn mạnh backup files và database phải phục vụ khả năng restore, không chỉ lưu trữ. Trước khi test, nên xác nhận backup set đã bao phủ đúng dữ liệu theo Backup Database và File website.
Có 4 mức kiểm tra backup
| Mức | Kiểm tra gì? | Giới hạn |
|---|---|---|
| Existence | File/object tồn tại | Không chứng minh đọc được |
| Integrity | Hash/archive/decrypt | Chưa chứng minh application chạy |
| Partial restore | Import DB hoặc restore files | Chưa kiểm tra full business flow |
| Full restore test | Khôi phục site và smoke test | Gần nhất với recovery thật |
Chuẩn bị restore test an toàn
Chuẩn bị môi trường restore test
Không restore đè production chỉ để “test”. Dùng staging, sandbox hoặc environment cô lập phù hợp. Nếu backup chứa dữ liệu production, vẫn phải bảo vệ privacy và access control.
Ngăn side effect ra hệ thống thật
Website restore trong test có thể gửi email, webhook, payment call hoặc background jobs. Hãy disable/reroute các integration có thể gây side effect trước khi mở site test.
Thực hiện restore test
Bước 1: xác minh backup artefact
- Kiểm tra timestamp và source.
- Đối chiếu expected size hoặc object count.
- Xác minh checksum/hash nếu pipeline có tạo.
- Test archive có thể list/extract.
- Test decrypt bằng recovery key.
- Kiểm tra metadata/version của backup tool.
Integrity check nên thất bại rõ nếu file hỏng; đừng coi “job status success” là bằng chứng thay thế.
Bước 2: restore database
Import database vào môi trường test và kiểm tra:
- Dump parse/import hoàn tất.
- Tables/plugin tables tồn tại.
- Charset/collation không gây lỗi.
- Post/page/user/options sample có dữ liệu hợp lý.
- Database user/credential test có privilege phù hợp.
WordPress Developer Handbook mô tả database backup/restore và lưu ý database export không bao gồm files như themes, plugins, uploads hay wp-config.php.
Bước 3: restore files
Khôi phục WordPress files theo backup set: uploads, custom plugins/themes, config cần thiết và các artefact khác. Kiểm tra permission/ownership theo môi trường test; không copy blindly security setting từ environment khác nếu kiến trúc khác nhau.
Bước 4: xử lý URL, domain và secret cho môi trường test
Restore sang hostname khác có thể cần thay URL hoặc config. Không dùng production secret nếu không cần. Email/API/payment keys nên chuyển sang test credential hoặc bị vô hiệu.
Bước 5: smoke test business flow
Một restore được coi là usable khi các chức năng quan trọng hoạt động, không chỉ homepage trả HTTP 200.
- Homepage và route quan trọng.
- Login/logout bằng account test.
- Media/uploads hiển thị.
- Form hoặc workflow chính ở chế độ test.
- Admin page quan trọng.
- Plugin/theme custom không fatal error.
- Scheduled jobs/integration được kiểm soát.
Bước 6: đo RPO và RTO thực tế
RPO thực tế có thể đánh giá qua timestamp dữ liệu sau restore so với thời điểm sự cố giả định. RTO thực tế đo từ lúc bắt đầu recovery tới khi business flow cần thiết PASS. So sánh kết quả với mục tiêu trong RPO và RTO cho website.
Nếu test vượt xa RTO mục tiêu, vấn đề có thể nằm ở download, decrypt, database import, DNS, credential recovery hoặc runbook.
Bước 7: kiểm tra known-good trong security incident
Backup restore thành công về kỹ thuật chưa chắc sạch malware. Nếu dùng cho security recovery, cần xác minh restore point có trước initial compromise, không chứa persistence và sẽ được harden/credential-rotate trước go-live.
Xem Incident Recovery Plan và bảo mật backup WordPress: restore integrity và recovery.
Đánh giá kết quả restore test
Restore Test Record
| Trường | Evidence |
|---|---|
| Backup ID/time | Restore point đã dùng |
| Environment | Sandbox/staging |
| Integrity | Hash/archive/decrypt PASS/FAIL |
| Database | Import PASS/FAIL |
| Files/uploads | Restore PASS/FAIL |
| Business flow | Smoke tests |
| RPO observed | … |
| RTO observed | … |
| Issues | … |
| Owner/action | … |
Những failure thường gặp khi restore test
- Backup database thiếu plugin tables.
- Archive files hỏng hoặc thiếu uploads.
- Không còn encryption key.
- Backup plugin cần license/service không truy cập được.
- Restore URL/domain tạo redirect loop.
- Email/webhook test gửi ra production.
- Incremental chain thiếu một phần.
- Storage egress quá chậm so với RTO.
Test bao lâu một lần?
Không có lịch cố định cho mọi site. Tần suất restore test nên tăng khi hệ thống critical, thay đổi backup architecture, đổi provider, đổi encryption key, thay retention hoặc sau khi một restore test thất bại. Ít nhất phải test sau thay đổi lớn trước khi tin vào configuration mới.
Acceptance gate: khi nào backup được coi là “restore-ready”?
- Artefact đọc/giải nén/giải mã được.
- Database import PASS.
- Files/uploads/config trong scope đầy đủ.
- Business flow quan trọng PASS trong môi trường cô lập.
- RPO/RTO đo được và nằm trong mức chấp nhận hoặc có accepted risk.
- Procedure được cập nhật theo issue của test.
- Evidence record có owner và ngày review tiếp theo.
Khi backup đã đạt gate và cần đưa website thật trở lại hoạt động, chuyển sang quy trình Website Restore từ Backup để thực thi có snapshot, rollback và go-live control.
Nguồn kỹ thuật
- WordPress Developer — Backups
- WordPress Developer — Backing Up Your Database
- WordPress Developer — Backing Up Your WordPress Files
- CISA StopRansomware Guide
- NIST SP 800-34 Rev. 1 — Contingency Planning Guide
Kết luận
Một backup chỉ được coi là đáng tin khi đã đi qua restore test. Hãy kiểm tra integrity, database, files, secrets, business flow và đo RPO/RTO trong môi trường cô lập. Nếu chưa từng restore, bạn mới chỉ biết rằng backup file tồn tại — chưa biết recovery có hoạt động.