Backup Retention Policy cho website là quy định nên giữ những bản sao lưu nào, giữ trong bao lâu và khi nào được xóa. Mục tiêu là có dữ liệu để phục hồi sau lỗi mà không giữ thông tin quá lâu hoặc tốn chi phí không cần thiết.
Chủ doanh nghiệp cần biết: lịch sao lưu, số phiên bản còn giữ, nơi lưu độc lập và người được phép xóa. Cũng cần xác nhận bản sao cũ có thể khôi phục được, không chỉ thấy thông báo “sao lưu thành công”.
Có nên giữ 30 ngày? Không có một con số phù hợp mọi website. Cửa hàng có nhiều đơn, website giới thiệu ít cập nhật và hệ thống hội viên có mức rủi ro khác nhau.
Tần suất sao lưu khác thời gian lưu bản sao thế nào?
Tần suất trả lời câu hỏi bao lâu tạo một bản mới. Thời gian lưu trả lời bản đó tồn tại tới khi nào. Hai phần phải được quyết định riêng.
Ví dụ: sao lưu mỗi giờ nhưng chỉ giữ 24 giờ. Nếu lỗi dữ liệu xuất hiện từ ba ngày trước mà hôm nay mới phát hiện, bản sạch cũ có thể không còn.
Theo Microsoft Azure Backup, lịch sao lưu và quy tắc lưu giữ là hai cấu hình riêng. Cách chọn cần dựa vào loại dữ liệu, mục tiêu phục hồi và các yêu cầu áp dụng.
Giữ quá ít bản sao có thể khiến mất cơ hội phục hồi
- Mã độc đã tồn tại nhiều ngày trước khi được phát hiện.
- Dữ liệu đơn hàng hoặc khách hàng bị sửa sai âm thầm.
- Nhân viên xóa nhầm trang, hình ảnh nhưng không nhận ra ngay.
- Phần mềm kết nối nhập dữ liệu sai liên tục qua nhiều lần sao lưu.
- Bản sao mới nhất đã chứa lỗi, nên cần chọn một bản cũ hơn.
Vì vậy, bản mới nhất chưa chắc là bản phù hợp. Trước khi phục hồi, cần đối chiếu thời điểm bắt đầu sự cố và kiểm tra bản sao có sạch hay không.
Vì sao không nên giữ tất cả bản sao mãi mãi?
Giữ vô hạn làm tăng chi phí lưu trữ, số lượng dữ liệu cần bảo vệ và mức ảnh hưởng nếu tài khoản sao lưu bị lộ. Dữ liệu khách đã xóa trên website có thể vẫn nằm trong các bản sao cũ.
Doanh nghiệp cần quy định thời hạn xóa và xử lý ngoại lệ khi có yêu cầu pháp lý hoặc lưu giữ hồ sơ. Không áp dụng tùy tiện một thời hạn pháp luật chung cho mọi loại dữ liệu.
Ví dụ lịch lưu bản sao theo ngày, tuần và tháng
| Nhóm bản sao | Ví dụ giữ lại | Khi nào hữu ích |
|---|---|---|
| Theo giờ, nếu cần | Theo mức đơn và dữ liệu thay đổi | Hạn chế mất đơn mới trong ngày |
| Hằng ngày | 7 bản gần nhất | Quay lại khi vừa cập nhật hoặc xóa nhầm |
| Hằng tuần | 4 mốc theo tuần | Lỗi được phát hiện sau nhiều ngày |
| Hằng tháng | 3 mốc theo tháng | Phân tích lỗi cũ, dữ liệu bị thay đổi âm thầm |
| Trước thay đổi lớn | Giữ theo mức rủi ro đã duyệt | Quay lại trước nâng cấp hoặc chuyển hosting |
Đây chỉ là ví dụ để lập kế hoạch, không phải khuyến nghị cố định cho mọi website. Một bản cuối tuần có thể đồng thời là bản ngày; cách tính số bản thực tế tùy phần mềm sao lưu.
Nếu máy chủ chỉ cho giữ bảy bản và tạo một bản mỗi ngày, bản sạch từ hơn một tuần trước có thể đã bị ghi đè. Hãy tính cả độ trễ khi phát hiện lỗi.
Chọn thời gian giữ theo loại website và mức mất dữ liệu chấp nhận
- Website giới thiệu: ưu tiên bản theo ngày hoặc tuần, cộng bản trước thay đổi lớn.
- Website nhận tư vấn: xác định biểu mẫu đã lưu trên website hay chuyển sang CRM riêng.
- Cửa hàng WooCommerce: cần bảo vệ đơn, giao dịch, tồn kho và dữ liệu khách thường xuyên hơn.
- Website hội viên hoặc đào tạo: xem tiến độ, quyền truy cập, học phí và thông tin tài khoản.
Xem RPO/RTO cho website để xác định mức mất dữ liệu và thời gian ngừng dịch vụ có thể chấp nhận. Thời gian giữ dài không thể thay thế việc tạo bản sao đủ thường xuyên.
Theo WooCommerce, cửa hàng cần bảo vệ cả cơ sở dữ liệu lẫn tệp trong wp-content. Bản sao chỉ có hình ảnh hoặc mã nguồn không đủ để phục hồi đơn hàng.
Bản sao lưu ngoài hosting và bản không thể xóa sớm
Không nên giữ mọi bản ở cùng nơi với website thật. Nếu máy chủ hoặc tài khoản bị chiếm quyền, kẻ tấn công có thể xóa cả website lẫn bản sao.
Bản lưu độc lập và bản có khóa bảo vệ hỗ trợ giảm rủi ro này. Xem Backup offsite và immutable cho website để hiểu rõ hai cơ chế khác nhau.
Tuy nhiên, theo AWS Backup Vault Lock, chế độ khóa nghiêm ngặt có thể ngăn xóa cho tới hết thời hạn. Cấu hình giữ vô thời hạn có thể tạo chi phí kéo dài. Hãy thử chính sách trước khi khóa.
Nên tạo bản riêng trước những thay đổi nào?
Ngoài lịch cố định, nên có bản trước khi nâng phiên bản WordPress, plugin quan trọng, PHP, thay cấu trúc dữ liệu hoặc chuyển hosting. Bản này giúp xác định trạng thái trước thay đổi.
Không phải cứ có bản trước cập nhật là được phép ghi đè dữ liệu hiện tại. Nếu website vẫn nhận khách hoặc đơn hàng, phải xác định những bản ghi phát sinh sau đó.
Chính sách lưu giữ cần ghi những thông tin gì?
- Những phần phải sao lưu: tệp, cơ sở dữ liệu và dịch vụ liên quan.
- Nhóm dữ liệu và mức độ quan trọng đối với hoạt động kinh doanh.
- Lịch tạo bản mới và thời điểm dự kiến.
- Thời hạn giữ theo ngày, tuần, tháng hoặc sự kiện.
- Vị trí lưu và phần lưu ngoài hosting.
- Khả năng khóa bản sao, thời điểm hết khóa nếu có.
- Người chịu trách nhiệm duyệt chính sách.
- Người có quyền xem, khôi phục hoặc xóa dữ liệu.
- Cảnh báo khi công việc sao lưu hoặc xóa gặp lỗi.
- Ngày thử khôi phục gần nhất và kết quả.
- Quy trình xóa bản hết hạn, ngoại lệ và quyền riêng tư.
- Ngày rà soát tiếp theo và người xác nhận.
Trước khi xóa bản cũ phải kiểm tra điều gì?
Đừng xóa từng tệp sao lưu theo cảm tính. Một số phương pháp sao lưu gia tăng cần bản gốc hoặc các phần liên quan để phục hồi. Hãy dùng chức năng quản lý vòng đời của phần mềm phù hợp.
Khi giảm thời gian giữ, một số dịch vụ có thể đánh dấu bản hiện có để xóa. Microsoft Azure Files mô tả cụ thể tình huống này. Cần xem ảnh hưởng đến các bản đang lưu trước khi xác nhận.
Đặc biệt, đừng để quy trình dọn tự động xóa hết những bản đã được kiểm tra là sạch sau một sự cố chưa kết thúc. Việc giữ ngoại lệ cần được phê duyệt, giới hạn và ghi nhận.
Thử khôi phục từ nhiều mốc lưu giữ
Nếu chỉ thử bản mới nhất, chưa thể biết bản tuần hoặc bản tháng cũ còn dùng được không. Nên chọn mẫu đại diện và thử ở môi trường riêng, không ghi đè website thật.
Theo hướng dẫn an toàn sao lưu của NCSC New Zealand, các bản sao cần được thử khôi phục. Xem quy trình Restore Test để kiểm tra dữ liệu, tệp và các chức năng chính.
Nếu khôi phục cơ sở dữ liệu cũ cho WooCommerce, đơn và khách phát sinh sau bản sao có thể bị ghi đè. WordPress.com có lưu ý riêng về rủi ro này. Phương án khôi phục chọn lọc tùy nền tảng và công cụ.
Khi xảy ra sự cố, chọn phiên bản nào?
Không phải luôn chọn bản mới nhất. Đội kỹ thuật cần xác định thời điểm dữ liệu còn đúng, mức mất dữ liệu chấp nhận và bản sao đã qua kiểm tra.
Trong Disaster Recovery Runbook, hãy ghi cách chọn phiên bản theo thời điểm lỗi, thay vì ghi cứng một mã bản sao. Người xử lý phải kiểm tra khả năng dùng và dữ liệu mới trước khi mở lại.
Checklist rà soát chính sách mỗi quý hoặc sau thay đổi lớn
- Website có thêm đơn hàng, dữ liệu khách hoặc tính năng quan trọng nào không?
- Mục tiêu RPO/RTO có thay đổi theo tình hình kinh doanh không?
- Chi phí lưu trữ có tăng hoặc có bản sao không cần thiết không?
- Đã thử bản ngày, tuần, tháng đủ đại diện chưa?
- Công việc tạo và xóa bản sao có chạy đúng không?
- Bản sao ngoài hosting vẫn tách biệt, truy cập được không?
- Người quản lý quyền, tài khoản và nơi lưu có thay đổi không?
- Đã có lỗi phát hiện muộn cho thấy thời gian giữ chưa đủ chưa?
Câu hỏi thường gặp
Giữ backup 30 ngày có đủ không?
Có thể đủ với một số website nhưng không có chuẩn chung. Hãy so khả năng phát hiện lỗi muộn, lượng dữ liệu thay đổi và chi phí lưu trữ.
Có nên giữ bản theo tháng rất lâu?
Chỉ khi có nhu cầu phục hồi, hợp đồng hoặc nghĩa vụ lưu trữ phù hợp. Cần xem dữ liệu cá nhân, quyền truy cập và khả năng khôi phục từ bản cũ.
Thời gian giữ có thay cho bản sao bất biến không?
Không. Một bên xác định thời điểm bản sao được xóa; bên kia bảo vệ bản sao khỏi sửa hoặc xóa trước hạn. Nên thiết kế hai phần cùng nhau.
Kết luận
Chính sách lưu bản sao website phải vừa đủ để xử lý lỗi phát hiện muộn, nhưng có lịch hết hạn rõ ràng. Hãy chọn tần suất theo lượng dữ liệu mới và thời gian giữ theo nhu cầu phục hồi.
Khi thuê dịch vụ quản trị và vận hành website, doanh nghiệp nên yêu cầu lịch giữ, người chịu trách nhiệm và kết quả thử khôi phục. Đó là bằng chứng hữu ích hơn con số “sao lưu bao nhiêu bản” đơn lẻ.
Đ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ả.