Website Restore từ Backup: quy trình khôi phục an toàn

Website Restore từ Backup là quy trình đưa website trở lại trạng thái vận hành bằng một restore point đã được chọn và kiểm chứng. Restore an toàn không phải chỉ là bấm nút “Restore”: cần khóa scope, bảo toàn dữ liệu mới phát sinh, chuẩn bị rollback, kiểm tra database/files, xử lý DNS/secret và xác minh business flow trước khi mở lại traffic.

Mục tiêu của bài này là mô tả quy trình thực thi restore từng bước. Nếu câu hỏi của bạn là “backup này có dùng được không?”, xem cách kiểm tra backup có thực sự restore được. Nếu đang cân nhắc chỉ restore database/file hay full site, xem bài Full Restore vs Partial Restore.

Chuẩn bị recovery trước khi restore

Xác định lý do và exit condition

Restore cần một trigger rõ: deployment thất bại, data corruption, xóa nhầm, hỏng server, migration lỗi hoặc recovery sau incident. Đồng thời phải định nghĩa “restore thành công” nghĩa là gì: homepage chạy, checkout hoạt động, login được, media đầy đủ, cron hợp lệ hay toàn bộ business flow quan trọng PASS.

Bước 1: khóa thời điểm và phạm vi thay đổi

Nếu website vẫn nhận order, form hoặc user activity, dữ liệu tiếp tục thay đổi trong lúc bạn chuẩn bị restore. Hãy ghi timestamp, xác định write activity và quyết định có cần maintenance mode, queue, read-only hoặc biện pháp giảm write hay không.

Không khóa thời điểm sẽ khiến bạn khó biết dữ liệu nào thuộc trước và sau restore point, đặc biệt với database động.

Bước 2: chọn restore point phù hợp

Đừng mặc định dùng bản backup mới nhất. Chọn restore point dựa trên:

Thời điểm lỗi hoặc incident bắt đầu.
Integrity của backup.
Dữ liệu có thể mất so với RPO.
Compatibility với code, database schema và hạ tầng hiện tại.
Khả năng backup chứa corruption hoặc persistence.

Trong security incident, “mới nhất” có thể là lựa chọn sai nếu backup đã chứa malware. Với tình huống đó, cần thêm known-good validation trước khi restore.

Bước 3: tạo snapshot/pre-restore evidence

Trước khi ghi đè, giữ snapshot hoặc backup của trạng thái hiện tại nếu còn khả năng. Snapshot này phục vụ rollback, so sánh dữ liệu mới phát sinh và investigation nếu restore không giải quyết được vấn đề.

Không xóa artefact cũ ngay sau restore; cần retention phù hợp để có đường quay lại.

Bước 4: chuẩn bị môi trường và dependency

Thành phần	Cần kiểm tra
Compute/hosting	PHP/runtime, disk, permission, service health
Database	Version, charset/collation, credential, capacity
DNS/CDN/WAF	Origin, cache, proxy mode, certificate
Secrets	DB credential, API key, salts, payment/email test mode
External dependency	Object storage, search, CRM, payment, webhook

Restore files thành công nhưng dependency sai vẫn có thể khiến website lỗi hoặc tạo side effect.

Thực thi restore

Bước 5: restore database

Với WordPress, database chứa posts, pages, users, options, metadata và dữ liệu plugin. Trước import, xác định database target, backup format và quyền ghi.

Database restore checklist

Xác minh đúng database/schema target.
Backup trạng thái database hiện tại nếu cần rollback.
Import bằng công cụ phù hợp.
Kiểm tra error, charset/collation và table count.
Kiểm tra các plugin table quan trọng.
Xác minh sample dữ liệu business.

Nếu restore database về điểm cũ, phải đánh giá dữ liệu phát sinh sau restore point có cần replay, merge hoặc nhập lại không.

Bước 6: restore files và uploads

Khôi phục files theo scope đã chốt: WordPress core nếu cần, plugin/theme, custom code, uploads và cấu hình liên quan. Kiểm tra owner/permission thay vì copy permission từ môi trường cũ một cách máy móc.

Với uploads, sample nhiều loại file và đường dẫn để bảo đảm media mapping đúng sau restore.

Bước 7: xử lý URL, cache, DNS và secret

Nếu restore sang host hoặc domain khác, kiểm tra site URL, home URL, reverse proxy, CDN cache và redirect. Clear cache theo phạm vi cần thiết; không purge vô điều kiện nếu cache là một phần của rollback strategy.

Secret cần được đối chiếu với environment. Trong staging/test, tuyệt đối tránh dùng production payment/email credential nếu có thể gây side effect.

Verify và go-live

Bước 8: chạy smoke test theo business flow

HTTP 200 không đủ để kết luận restore thành công. Tối thiểu cần kiểm tra:

Homepage và route chính.
Login/logout với account test.
Admin page cần thiết.
Media/uploads.
Form/checkout hoặc workflow quan trọng ở chế độ kiểm thử.
Scheduled jobs cần thiết.
Error log sau restore.

Bước 9: đo RPO/RTO thực tế

Ghi thời điểm restore point, dữ liệu mới nhất sau recovery và thời gian từ lúc bắt đầu tới khi business flow PASS. So sánh với mục tiêu đã đặt trong RPO và RTO cho website.

Nếu vượt target, ghi bottleneck thay vì chỉ kết luận “restore chậm”.

Bước 10: mở traffic có kiểm soát

Không nên chuyển từ test sang full traffic ngay nếu rủi ro cao. Có thể dùng staged rollout, limited traffic, health check hoặc maintenance exit gate phù hợp với architecture.

Ngay sau go-live, theo dõi error rate, auth event, resource, business transaction và anomaly để phát hiện regression sớm.

Khi nào phải rollback restore?

Database import gây lỗi hoặc mất dữ liệu ngoài dự kiến.
Business flow critical không PASS.
Restore point không tương thích code/schema.
Xuất hiện dấu hiệu corruption hoặc malware.
RTO bị vượt nghiêm trọng và có phương án recovery khác tốt hơn.

Rollback không phải thất bại của quy trình; nó là control bắt buộc khi thay đổi recovery không đạt acceptance gate.

Restore Procedure Record

incident_or_change_id: <id>
restore_point: <backup id + timestamp>
reason: <failure/change/incident>
pre_restore_snapshot: <reference>
scope:
  database: yes|no
  files: yes|no
  uploads: yes|no
start_time: <timestamp>
database_restore: PASS|FAIL
files_restore: PASS|FAIL
smoke_test: PASS|FAIL
observed_rpo: <value>
observed_rto: <value>
rollback_available: yes|no
owner: <person/team>
final_decision: go-live|rollback|investigate

Quality gate trước khi đóng restore

Restore point có lý do chọn và evidence integrity.
Pre-restore state có rollback path.
Database/files đúng scope.
Business flow critical PASS.
Không có error mới chưa giải thích.
Observed RPO/RTO được ghi.
Monitoring sau restore hoạt động.
Owner xác nhận go-live hoặc accepted risk.

Nguồn kỹ thuật

Kết luận

Website Restore từ Backup là một change có rủi ro cao và phải được vận hành như một quy trình có snapshot, rollback, scope, verification và owner. Restore đúng không chỉ đưa file/database quay lại; nó phải đưa business flow về trạng thái chấp nhận được và tạo được evidence rằng recovery đã thành công.