Backup Retention Policy cho website là quy tắc xác định bản backup nào được giữ, giữ trong bao lâu và khi nào được xóa. Retention không nên chọn theo cảm tính kiểu “giữ càng lâu càng tốt”; nó phải cân bằng RPO/RTO, khả năng phát hiện sự cố muộn, chi phí lưu trữ, dữ liệu nhạy cảm và yêu cầu vận hành.
Tóm tắt: Retention tốt tạo đủ nhiều recovery point để quay lại trước một lỗi hoặc compromise, nhưng vẫn có lịch xóa rõ ràng. Cần phân lớp daily/weekly/monthly hoặc theo event, bảo vệ ít nhất một bản offsite, test restore và review policy khi website thay đổi.
Retention khác tần suất backup thế nào?
Tần suất backup trả lời “bao lâu tạo một recovery point mới?”. Retention trả lời “giữ recovery point đó bao lâu?”. Một website có thể backup mỗi giờ nhưng chỉ giữ 24 giờ; khi sự cố được phát hiện sau ba ngày, các bản sạch có thể đã biến mất.
Vì sao giữ quá ít bản backup là rủi ro?
- malware tồn tại nhiều ngày mới bị phát hiện;
- lỗi dữ liệu tích lũy chậm;
- content bị xóa nhầm nhưng không ai nhận ra ngay;
- integration ghi sai dữ liệu trong nhiều chu kỳ;
- recovery point mới nhất có thể đã chứa lỗi.
Vì sao giữ mọi thứ mãi mãi cũng không tốt?
Retention quá dài làm tăng chi phí, complexity và phạm vi dữ liệu phải bảo vệ. Với dữ liệu khách hàng hoặc dữ liệu nhạy cảm, việc giữ bản sao cũ cũng có thể làm tăng bề mặt rủi ro. Policy cần có owner, lịch xóa và lý do kinh doanh rõ ràng.
Một mô hình retention thường dùng
| Lớp | Mục đích | Ví dụ cách dùng |
|---|---|---|
| Hourly/nearline | RPO ngắn | Dữ liệu giao dịch thay đổi liên tục |
| Daily | Rollback lỗi gần đây | Website hoạt động hằng ngày |
| Weekly | Giữ lịch sử trung hạn | Lỗi phát hiện muộn |
| Monthly | Điểm phục hồi dài hơn | Thay đổi lớn, seasonality |
| Event-based | Điểm trước thay đổi rủi ro | Migration, update lớn, redesign |
Không nên sao chép lịch này thành tiêu chuẩn cố định. Website cần chọn số lượng và thời gian giữ theo dữ liệu, business impact và chi phí.
Retention phải bám RPO và khả năng phát hiện sự cố
RPO/RTO quyết định mật độ recovery point và tốc độ phục hồi; retention quyết định doanh nghiệp có thể quay lại bao xa. Nếu compromise thường chỉ được phát hiện sau nhiều ngày, giữ một lịch sử quá ngắn là không phù hợp.
Retention và offsite/immutable backup
Retention không chỉ là thời gian. Cần biết recovery point nằm ở đâu và ai có quyền xóa. Xem Backup offsite & immutable để giảm rủi ro một tài khoản hoặc failure domain làm mất toàn bộ lịch sử backup.
Retention theo loại website
- Website giới thiệu: có thể ưu tiên daily/weekly và điểm trước change lớn.
- Lead generation: cần xem lead có được đẩy sang CRM riêng hay chỉ nằm trong database website.
- WooCommerce: cần recovery point dày cho database giao dịch và lịch sử đủ dài để xử lý lỗi phát hiện muộn.
- Membership/LMS: cần cân nhắc subscription, progress và dữ liệu người dùng.
Event-based backup có vai trò gì?
Ngoài lịch định kỳ, nên tạo recovery point trước các thay đổi có blast radius lớn: update core/plugin/theme, nâng PHP, migration, thay cấu trúc database hoặc release custom code. Event-based backup giúp rollback chính xác hơn một bản định kỳ cách xa thời điểm thay đổi.
Retention policy cần ghi những trường nào?
- phạm vi dữ liệu;
- loại recovery point;
- tần suất tạo;
- thời gian giữ;
- vị trí lưu;
- immutable/lock nếu có;
- owner;
- quyền xóa;
- monitoring job;
- restore test gần nhất;
- quy trình xóa khi hết hạn;
- review date.
Restore test phải lấy mẫu từ nhiều lớp retention
Nếu chỉ test bản mới nhất, doanh nghiệp chưa biết bản weekly/monthly cũ có còn restore được không. Restore test nên định kỳ lấy mẫu từ các lớp retention quan trọng để phát hiện corruption, dependency drift hoặc vấn đề quyền truy cập.
Retention trong DR Runbook
DR Runbook không nên ghi một backup ID cố định; thay vào đó phải ghi logic chọn recovery point theo incident, RPO, thời điểm compromise và lớp retention. Điều này giúp đội vận hành chọn được bản đủ mới nhưng vẫn đủ sạch.
Checklist review retention mỗi quý hoặc sau thay đổi lớn
- website có thêm dữ liệu business-critical mới không;
- RPO/RTO có thay đổi không;
- storage cost có tăng bất thường không;
- có recovery point nào không được test không;
- job xóa có hoạt động đúng không;
- offsite copy còn độc lập không;
- credential/owner có thay đổi không;
- có incident nào cho thấy retention hiện tại quá ngắn không.
FAQ
Giữ backup 30 ngày có đủ không?
Không có con số chung. Cần dựa vào tốc độ thay đổi dữ liệu, khả năng phát hiện sự cố muộn, business impact và chi phí.
Có nên giữ bản monthly rất lâu?
Có thể nếu có lý do business hoặc recovery rõ ràng, nhưng vẫn cần quản lý quyền, dữ liệu nhạy cảm và khả năng restore.
Retention có thay thế immutable backup không?
Không. Retention nói về thời gian giữ; immutable nói về khả năng sửa/xóa. Hai lớp giải quyết rủi ro khác nhau.
Kết luận
Backup Retention Policy tốt giúp website có đủ lịch sử để quay lại trước một sự cố mà không giữ dữ liệu vô hạn. Hãy thiết kế mật độ recovery point theo RPO, độ dài lịch sử theo khả năng phát hiện muộn, bảo vệ một lớp offsite phù hợp và chứng minh bằng restore test.
Trong Managed Website, retention nên là một phần của backup governance, không phải cấu hình mặc định của plugin hoặc hosting rồi bỏ quên.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.
