Backup & Recovery Maintenance Checklist: kiểm tra hệ thống backup website định kỳ

Backup & Recovery Maintenance Checklist để review scope, RPO/RTO, frequency, retention, security, monitoring, restore test và owner của hệ thống backup website.

Backup Recovery Maintenance Checklist với backup jobs, retention, restore test, security và monitoring

Backup & Recovery Maintenance Checklist là quy trình review định kỳ để bảo đảm hệ thống backup vẫn phù hợp với website hiện tại, không chỉ với cấu hình được tạo từ nhiều tháng trước. Website thay đổi plugin, hosting, database, traffic, owner, credential và business requirement; recovery plan cũng phải thay đổi theo.

CISA Cyber Resilience Review nhấn mạnh rằng backup/storage procedures cần được kiểm thử định kỳ để tiếp tục đáp ứng yêu cầu của dịch vụ khi điều kiện vận hành thay đổi. Vì vậy maintenance phải kiểm tra cả scope, RPO/RTO, frequency, retention, storage security, monitoring, restore test và owner.

Review coverage và recovery objectives

1. Review asset và backup scope

Bắt đầu bằng cách đối chiếu website hiện tại với những gì backup job thực sự thu thập. Kiểm tra:

  • Database/schema đang dùng.
  • Uploads/media.
  • Custom plugin/theme/MU-plugin.
  • Config và artefact cần cho recovery.
  • Object storage hoặc external data source.
  • Integration có dữ liệu nằm ngoài WordPress.

Nếu thêm service mới mà backup scope không được cập nhật, dashboard có thể vẫn báo success trong khi recovery set đã thiếu dữ liệu. Dùng Backup Database và File website làm inventory baseline.

2. Review RPO và RTO

Business impact thay đổi theo thời gian. Website trước đây chỉ là brochure có thể đã trở thành kênh bán hàng hoặc membership. Khi criticality tăng, RPO/RTO cũ có thể không còn phù hợp.

Review với owner:

  • Mất tối đa bao nhiêu dữ liệu vẫn chấp nhận được?
  • Website hoặc business flow phải hoạt động lại trong bao lâu?
  • Data asset nào cần mục tiêu khác nhau?
  • Observed RPO/RTO từ restore test gần nhất là bao nhiêu?

Tham chiếu RPO và RTO cho website.

3. Review backup frequency

So sánh expected schedule với change rate và RPO. Kiểm tra database, files và uploads có cần cùng frequency hay không.

Đừng chỉ xem cron configuration; cần xem lịch sử restore points thực tế. Nếu nhiều missed job làm khoảng cách restore point vượt RPO, frequency trên giấy không còn ý nghĩa. Case Backup Job âm thầm thất bại nhiều tuần cho thấy vì sao maintenance phải kiểm cả freshness và alert ownership thay vì chỉ kiểm schedule.

Xem cách chọn tần suất backup website.

4. Review retention

Retention phải đủ cho cả rollback ngắn hạn và lỗi phát hiện muộn. Review:

  • Recent restore points.
  • Weekly/monthly hoặc long-term tiers nếu có.
  • Detection delay từ incident thực tế hoặc giả định.
  • Auto-expire/lifecycle rules.
  • Privacy/legal/business constraints.
  • Khả năng giữ backup quan trọng trong incident.

Policy chi tiết nằm ở Backup Retention. Nếu malware tồn tại qua nhiều thế hệ backup, xem case Malware trong nhiều Generation Backup để thấy vì sao retention phải hỗ trợ tìm known-good restore point.

Review resilience controls

5. Review kiến trúc 3-2-1 và failure domain

Kiểm tra xem nhiều copies có thực sự tách failure domain hay chỉ khác tên. Hỏi:

  • Có bao nhiêu copies usable?
  • Có bản nằm ngoài production host/account không?
  • Một credential compromise có thể xóa mọi copy không?
  • Provider/region/account có common-mode failure không?
  • Offsite copy gần nhất có được tạo đúng hạn không?

Đối chiếu Backup 3-2-1 và Offsite Backup. Một case đáng tham chiếu là Server hỏng nhưng Website phục hồi nhờ Offsite Backup.

6. Review Backup Security

Backup chứa dữ liệu nhạy cảm và là recovery control quan trọng. Maintenance cần kiểm tra:

  • Admin access và MFA.
  • Backup-agent permissions.
  • Ai có quyền delete hoặc thay retention.
  • Encryption at rest/in transit.
  • Key owner và key recovery.
  • Immutable/offline controls.
  • Audit log của repository.
  • Credential đã hết hạn hoặc owner đã thay đổi.

Dùng Backup Security để review control plane.

7. Review Backup Monitoring

Monitoring phải phát hiện không chỉ explicit failure mà cả missed schedule, stale restore point, storage quota, retention change và telemetry gap.

Kiểm tra dashboard:

  • Last successful restore point age.
  • Job success/fail/missed.
  • Repository capacity và write/read health.
  • Backup-size deviation.
  • Retention/delete change.
  • Last restore-test result.
  • Telemetry last seen.

Checklist chuyên sâu nằm ở Backup Monitoring.

8. Chạy restore test định kỳ

Backup maintenance không được đóng chỉ bằng việc review configuration. Cần chọn restore point và test khả năng:

  • Đọc/giải nén/giải mã.
  • Import database.
  • Restore files/uploads.
  • Khởi động site trong môi trường test.
  • Chạy business-flow smoke test.
  • Đo observed RPO/RTO.

CISA khuyến nghị test availability và integrity của backup thường xuyên trong disaster-recovery scenario. Quy trình cụ thể: Restore Test. Case Có backup nhưng Website vẫn không Restore được là failure mode cần dùng để kiểm chất lượng bài test.

Review operations và ownership

9. Review restore procedure và rollback

Runbook có thể lỗi thời sau khi đổi hosting, PHP, database, DNS/CDN, secret management hoặc deployment pipeline. Chạy tabletop hoặc restore drill để kiểm tra từng bước còn đúng.

Đặc biệt review:

  • Ai có quyền kích hoạt restore.
  • Pre-restore snapshot.
  • Full vs partial decision.
  • Database/files order.
  • DNS/cache/secret handling.
  • Go-live và rollback gate.

Tham chiếu Website Restore từ Backup.

10. Review owner, escalation và access

Mỗi component phải có owner hiện tại. Nhân sự thay đổi có thể để lại account cũ, alert không ai nhận hoặc runbook phụ thuộc một cá nhân.

Hạng mụcOwner cần có
Backup jobOps/platform owner
RepositoryStorage/security owner
RPO/RTOBusiness/service owner
Restore procedureRecovery owner
Backup alertsOn-call/operations owner
Restore-test evidenceReviewer/approver

11. Review thay đổi kể từ kỳ maintenance trước

Đối chiếu change log và hỏi liệu các thay đổi sau có ảnh hưởng recovery không:

  • Hosting/provider/region.
  • Database engine/version.
  • Plugin/theme critical.
  • Object storage/CDN.
  • DNS/WAF.
  • Payment/CRM/email integration.
  • Encryption key hoặc secret-management model.
  • Traffic/data volume tăng mạnh.

Mỗi change lớn nên kích hoạt review ngoài lịch định kỳ nếu nó làm thay đổi recovery architecture.

Lịch maintenance nên bao lâu một lần?

Không có một lịch cố định phù hợp cho mọi website. Tần suất review nên dựa vào criticality, change velocity và recovery risk. Một mô hình vận hành có thể gồm:

Tần suấtReview trọng tâm
Hàng ngàyJob/restore-point freshness và critical alert
Hàng tuầnMissed job, capacity, noisy alert
Hàng tháng/quýScope, owner, retention, security, dashboard
Sau thay đổi lớnFull architecture và runbook impact
Sau incidentKnown-good backup, detection gap, RPO/RTO, corrective action

Đây là khung tham khảo, không phải fixed schedule bắt buộc.

Operational artifact: Backup & Recovery Maintenance Record

review_date: YYYY-MM-DD
system: <website>
review_owner: <person/team>
backup_scope: PASS|FAIL
rpo_rto_review: PASS|FAIL
frequency: PASS|FAIL
retention: PASS|FAIL
failure_domain_3_2_1: PASS|FAIL
backup_security: PASS|FAIL
monitoring: PASS|FAIL
restore_test: PASS|FAIL
restore_runbook: PASS|FAIL
owner_access_review: PASS|FAIL
changes_since_last_review: <summary>
open_actions:
  - issue: ...
    owner: ...
    due: ...
    evidence_ref: ...
next_review: YYYY-MM-DD

Definition of Done cho kỳ maintenance

  1. Không có critical backup scope gap chưa có owner.
  2. RPO/RTO vẫn được business chấp nhận.
  3. Restore-point freshness đáp ứng target hoặc có accepted gap.
  4. Retention và offsite/failure-domain architecture được xác minh.
  5. Repository access/security đã review.
  6. Backup Monitoring không có telemetry blind spot chưa xử lý.
  7. Restore test gần nhất PASS hoặc failure có remediation + retest.
  8. Runbook, owner và escalation hiện hành.
  9. Mọi issue còn mở có owner, deadline và evidence.

Nguồn kỹ thuật

Kết luận

Backup & Recovery Maintenance không phải kiểm tra xem cron còn bật hay không. Một kỳ review đúng phải xác minh toàn bộ recovery capability: dữ liệu nào được bảo vệ, mục tiêu nào phải đạt, bản sao nằm ở đâu, ai có quyền phá hoặc phục hồi chúng, hệ thống có alert khi hỏng không và restore drill có thực sự PASS hay không.

◇
Cần hỗ trợ kiểm tra và xử lý website?Đội ngũ SecureWebOps sẵn sàng hỗ trợ theo phạm vi phù hợp.
Liên hệ ngay →
Đoàn Trình Dục
Về tác giả Đoàn Trình Dục TD Digital · Website Operations & Security

Đoàn Trình Dục là tác giả nội dung trên SecureWebOps. Các bài viết tập trung vào bảo mật WordPress, giám sát an ninh website, malware/backdoor, hardening, backup/recovery và Incident Response theo hướng thực hành, có bước kiểm tra, bằng chứng, validation và rollback khi phù hợp.

Xem hồ sơ tác giả →