Full Restore vs Partial Restore website: chọn phạm vi nào?

Khi website gặp lỗi, câu hỏi quan trọng không chỉ là “có backup không?” mà còn là “cần restore toàn bộ hay chỉ một phần?”. Restore quá rộng có thể làm mất dữ liệu mới phát sinh; restore quá hẹp lại có thể bỏ sót thành phần gây lỗi hoặc khiến code và database không còn đồng bộ.

Bài này tập trung vào cách chọn phạm vi phục hồi: full restore, database-only, files-only hoặc selective restore. Quy trình thực thi sau khi đã chọn scope nằm ở Website Restore từ Backup.

Full Restore là gì?

Full Restore đưa toàn bộ website về một restore point gồm database, files, uploads, plugin/theme, cấu hình và các thành phần nằm trong backup set. Đây là phương án đơn giản về mặt consistency vì các lớp được đưa về cùng một thời điểm, nhưng blast radius của thay đổi lớn hơn.

Khi Full Restore phù hợp

Server hoặc filesystem bị hỏng trên diện rộng.
Deployment làm thay đổi đồng thời code và database schema.
Nhiều thành phần bị corruption.
Migration cần quay lại trạng thái trước cutover.
Restore point đã được kiểm chứng là một bộ hoàn chỉnh.

Rủi ro của Full Restore

Mất order, form, user activity hoặc content mới hơn restore point.
Khôi phục lại component/version cũ không còn an toàn.
Đưa cả cấu hình hoặc secret không còn phù hợp vào production.
Trong incident, có thể khôi phục cả persistence nếu restore point chưa được xác minh.

Database-only Restore là gì?

Database-only Restore chỉ đưa database về restore point cũ, giữ nguyên files/code hiện tại. Phương án này có ích khi lỗi nằm trong data, options, content hoặc database migration, nhưng phải kiểm tra compatibility với code version hiện tại.

Tình huống có thể dùng database-only

Xóa nhầm page/post/data trong database.
Import dữ liệu lỗi nhưng code không thay đổi.
Database migration thất bại nhưng application files còn đúng.
Cần phục hồi một số table hoặc logical dataset.

Với WordPress, database chứa nhiều dữ liệu do plugin quản lý; restore database cũ trong khi plugin code đã nâng version có thể tạo schema mismatch. Vì vậy phải kiểm tra migration state trước khi quyết định.

Files-only Restore là gì?

Files-only Restore khôi phục code, uploads hoặc một phạm vi filesystem nhưng giữ database hiện tại. Nó phù hợp hơn khi lỗi nằm ở file bị xóa, deployment sai, theme/plugin custom hoặc uploads bị mất.

Tình huống có thể dùng files-only

Theme/plugin custom bị ghi đè.
Uploads bị xóa nhưng database references còn đúng.
Deployment code lỗi nhưng database schema chưa thay đổi.
Một nhóm file bị corruption có phạm vi rõ.

Nếu code mới đã chạy database migration, quay files về version cũ mà giữ database mới có thể gây lỗi tương thích. Đây là lý do cần xem restore như một change có dependency.

Selective Restore là gì?

Selective Restore phục hồi một phần nhỏ hơn như một table, một nhóm record, uploads theo thư mục, một plugin/theme hoặc một file cấu hình. Ưu điểm là giảm blast radius; nhược điểm là cần hiểu dependency và consistency sâu hơn.

Selective Restore không nên thực hiện chỉ vì “ít thay đổi hơn”. Nếu dữ liệu có quan hệ chéo giữa nhiều table hoặc files, restore chọn lọc sai có thể tạo trạng thái logic không nhất quán.

Ma trận chọn phạm vi restore

Tình huống	Scope nên đánh giá trước	Điểm phải kiểm tra
Server hỏng hoàn toàn	Full Restore	Backup set, infrastructure, DNS/secret
Xóa nhầm content	Database/selective	Dữ liệu mới sau restore point
Plugin deployment lỗi	Files hoặc full	DB migration/schema change
Uploads bị mất	Files/selective	Media references, file path
Data import lỗi	Database/selective	Transaction boundary, affected tables
Security incident	Không quyết định chỉ theo scope kỹ thuật	Known-good point, persistence, evidence

5 câu hỏi trước khi chọn scope

1. Lỗi bắt đầu ở đâu?

Xác định component đầu tiên thay đổi: database, code, files, deployment, infrastructure hay external dependency. Nếu chưa biết root cause, restore quá sớm có thể chỉ che triệu chứng.

2. Thành phần nào đã thay đổi sau restore point?

So sánh database writes, uploads, code deploy và configuration changes. Thành phần thay đổi nhanh có nguy cơ mất dữ liệu cao hơn nếu bị restore toàn bộ.

3. Code và database có phụ thuộc version không?

Plugin/theme/application có thể chạy migration. Nếu code và schema phải đi cùng version, restore một phía có thể phá compatibility.

4. Có dữ liệu mới cần giữ lại không?

Order, form, comment, account hoặc editorial content mới cần được inventory trước khi restore. Nếu có, phải thiết kế merge/replay hoặc chọn scope hẹp hơn.

5. Restore point có đủ tin cậy không?

Trước khi chọn bất kỳ scope nào, restore point phải qua integrity/availability check. Xem restore test backup.

Consistency giữa database và files

Database và files có thể tham chiếu lẫn nhau. WordPress media trong database trỏ tới uploads; plugin options có thể phụ thuộc code version; theme setting có thể phụ thuộc template files. Vì vậy backup inventory cần biết rõ mối quan hệ giữa hai lớp.

Bài Backup Database và File website giải thích chi tiết thành phần nào thường nằm ở đâu.

Scope restore và RPO/RTO

Partial Restore có thể nhanh hơn Full Restore, nhưng không phải lúc nào cũng giúp đạt RTO nếu investigation và dependency analysis kéo dài. Ngược lại Full Restore nhanh về thao tác nhưng có thể làm mất quá nhiều dữ liệu so với RPO.

Do đó decision phải cân bằng cả RPO và RTO, không tối ưu một phía.

Operational artifact: Restore Scope Decision

event_id: <id>
root_cause_known: yes|no
affected_layers:
  database: yes|no
  files: yes|no
  uploads: yes|no
  infrastructure: yes|no
restore_point: <id/timestamp>
new_data_after_restore_point: <description>
code_db_schema_dependency: <description>
selected_scope: full|database|files|selective
reason: <why>
rollback_path: <reference>
owner: <person/team>

Quality gate trước khi restore

Scope lỗi được mô tả bằng evidence.
Dữ liệu mới sau restore point được inventory.
Code/database compatibility đã kiểm tra.
Restore point qua integrity check.
RPO/RTO impact được ghi.
Có rollback path.
Owner phê duyệt scope trước khi ghi đè.

Nguồn kỹ thuật

Kết luận

Không có nguyên tắc “luôn Full Restore” hay “luôn Partial Restore”. Phạm vi phục hồi phải dựa trên layer bị ảnh hưởng, dữ liệu mới, compatibility giữa code và database, restore-point integrity và RPO/RTO. Scope càng hẹp thì cần hiểu dependency càng rõ; scope càng rộng thì blast radius và nguy cơ mất dữ liệu càng lớn.