Backup Retention là chính sách xác định các restore point được giữ trong bao lâu và khi nào chúng được hết hạn hoặc xóa. Frequency trả lời “bao lâu tạo một backup”; retention trả lời “giữ lịch sử backup dài bao nhiêu”. Nếu chưa khóa tần suất, xem cách chọn tần suất backup website trước khi thiết kế retention.
Retention quá ngắn có thể khiến bạn không còn bản known-good khi phát hiện corruption hoặc malware muộn. Retention quá dài lại tăng chi phí, dữ liệu nhạy cảm và nghĩa vụ quản trị. Vì vậy không có một con số “giữ X bản” phù hợp cho mọi website.
Thiết kế Backup Retention Policy
Vì sao chỉ giữ bản mới nhất là rủi ro?
Lỗi không phải lúc nào cũng được phát hiện ngay. Một plugin có thể làm corrupt data âm thầm, malware có thể tồn tại nhiều ngày trước khi bị phát hiện, hoặc người dùng phát hiện xóa nhầm sau một khoảng thời gian. Nếu backup mới nhất đã chứa lỗi, bạn cần restore point cũ hơn.
Retention phải tính đến detection delay
Detection delay là khoảng thời gian từ khi lỗi/compromise bắt đầu đến khi bạn nhận ra. Retention window cần đủ để còn ít nhất một restore point trước sự kiện quan trọng, đặc biệt với incident khó phát hiện sớm.
Detection delay nên được xem cùng mục tiêu RPO/RTO: RPO quyết định độ gần của restore point, còn retention quyết định bạn còn giữ được lịch sử đó bao lâu.
Retention tiers: daily, weekly, monthly
Một mô hình phổ biến là giữ nhiều restore point gần hiện tại và ít restore point hơn khi đi xa về quá khứ. Ví dụ daily/weekly/monthly tiers có thể giảm chi phí nhưng vẫn giữ lịch sử dài. Đây là mô hình minh họa, không phải lịch bắt buộc.
| Tier | Mục tiêu | Câu hỏi |
|---|---|---|
| Recent | Rollback lỗi mới xảy ra | Cần bao nhiêu điểm gần nhất? |
| Weekly | Phát hiện lỗi muộn hơn | Detection delay thường bao lâu? |
| Monthly/long-term | Recovery dài hạn/audit | Có business/legal need không? |
Storage cost và retention
Chi phí không chỉ là dung lượng. Cần tính API/operation cost, egress khi restore, replication, encryption key, monitoring và thời gian kiểm tra. Compression và incremental backup có thể giảm storage nhưng tăng độ phức tạp của restore chain.
Dữ liệu nhạy cảm và privacy
Backup kéo dài vòng đời của dữ liệu. Nếu database chứa thông tin cá nhân hoặc dữ liệu phải xóa theo policy, retention backup cần được xem trong governance tổng thể. Không nên giữ vô thời hạn “cho an toàn” nếu không có business/legal basis.
SecureWebOps không thể xác định nghĩa vụ pháp lý cụ thể cho từng tổ chức; hãy đối chiếu policy nội bộ và yêu cầu pháp lý phù hợp.
Bảo vệ retention trong security incident
Retention và ransomware/malware
Trong security incident, backup gần nhất có thể đã chứa persistence hoặc data tampering. Retention đủ dài cho phép so sánh nhiều thời điểm và chọn restore point trước compromise.
Nhưng retention dài không đủ nếu attacker có thể xóa toàn bộ lịch sử. Backup repository cần account separation, immutable/offline copy hoặc control phù hợp. Xem Backup Security cho protection của repository và control plane.
Retention policy phải có protection khỏi deletion ngoài ý muốn
Người có quyền sửa retention có thể vô tình hoặc cố ý làm mất restore history. Nếu nền tảng hỗ trợ, giới hạn quyền thay retention/xóa backup, bật audit và yêu cầu review cho thay đổi policy quan trọng.
Không xóa backup chỉ dựa trên tuổi
Trong incident hoặc investigation, một restore point cũ có thể trở thành evidence hoặc known-good candidate. Trước khi cleanup retention trong thời gian sự cố, cần kiểm tra xem backup có đang được giữ phục vụ investigation/recovery không.
Restore test cần bao phủ nhiều tier
Đừng chỉ test bản backup mới nhất. Định kỳ chọn restore point ở các tier khác nhau để xác minh archive lâu ngày vẫn giải nén, giải mã và import được. Nếu long-term backup chưa từng test, retention dài chỉ là storage, chưa phải recovery capability. Quy trình thực thi nằm ở restore test backup.
Backup Retention Decision Matrix
| Yếu tố | Nếu cao | Ảnh hưởng retention |
|---|---|---|
| Change rate | Dữ liệu đổi nhanh | Cần nhiều recent restore points |
| Detection delay | Lỗi phát hiện muộn | Cần history dài hơn |
| Incident risk | Malware/persistence đáng kể | Cần known-good points cũ |
| Storage cost | Chi phí lớn | Cần tiering/dedup/compression |
| Data sensitivity | Dữ liệu nhạy cảm | Giới hạn retention + access control |
| Legal/business need | Có yêu cầu lưu trữ | Giữ theo policy được phê duyệt |
Operational artifact: Retention Policy Record
system: <website>
owner: <team/person>
rpo: <value>
estimated_detection_delay: <value>
retention_tiers:
recent: <policy>
weekly: <policy>
monthly_or_long_term: <policy>
immutable_or_offline_window: <policy>
deletion_authority: <role>
privacy_or_legal_constraints: <notes>
last_policy_review: <date>
last_old-restore-point_test: <date/result>
Acceptance test cho Backup Retention
- Retention có lý do gắn với detection delay và business need.
- Có đủ recent points để đáp ứng RPO.
- Có restore history đủ dài cho lỗi phát hiện muộn.
- Quyền xóa/thay retention được giới hạn.
- Backup cũ được test định kỳ.
- Retention không mâu thuẫn policy dữ liệu.
- Incident có cơ chế tạm giữ backup quan trọng trước auto-expire khi cần.
Nguồn kỹ thuật
- NIST SP 800-34 Rev. 1 — Contingency Planning Guide
- CISA StopRansomware Guide
- WordPress Developer — Backups
Kết luận
Backup Retention không phải bài toán “giữ bao nhiêu file”. Nó là cách bảo đảm luôn còn restore point phù hợp khi lỗi được phát hiện muộn, đồng thời kiểm soát chi phí, dữ liệu nhạy cảm và quyền xóa. Retention tốt phải đi cùng restore test và protection cho repository.