Không có một câu trả lời cố định cho câu hỏi website nên backup bao lâu một lần. Tần suất phù hợp phụ thuộc vào lượng dữ liệu thay đổi, mức dữ liệu chấp nhận mất, thời gian phục hồi, business impact và khả năng của hệ thống backup.
Một site ít cập nhật có thể không cần cùng lịch với website thương mại nhận đơn hàng liên tục. Vì vậy frequency nên được thiết kế từ RPO + change rate, không phải từ thói quen “backup mỗi ngày”.
Cách xác định tần suất backup theo RPO và change rate
RPO là điểm bắt đầu để chọn tần suất
Recovery Point Objective (RPO) thể hiện lượng dữ liệu tối đa có thể chấp nhận mất khi phục hồi, thường quy đổi thành khoảng thời gian. Nếu business chỉ chấp nhận mất tối đa 1 giờ dữ liệu, một backup mỗi 24 giờ không đáp ứng mục tiêu đó.
RPO là quyết định business/operational. Tooling phải phục vụ RPO, không phải ngược lại. Xem RPO và RTO cho website để khóa recovery objective trước khi đặt lịch.
Change rate quan trọng không kém RPO
| Loại website | Dữ liệu thay đổi | Điểm cần xem |
|---|---|---|
| Website giới thiệu | Thấp | Backup trước thay đổi + lịch định kỳ |
| Blog/news | Nội dung, media, comment | Database và uploads |
| E-commerce | Đơn hàng, user, inventory | RPO ngắn, recovery data consistency |
| Membership/LMS | User activity, progress | Database thay đổi liên tục |
Bảng chỉ minh họa yếu tố cần xem, không phải lịch mặc định.
Database và files có thể cần tần suất khác nhau
Database thường thay đổi nhanh ở site có đơn hàng, form, comment hoặc user activity; trong khi WordPress core/plugin/theme có thể chỉ thay đổi trong maintenance window. Uploads lại có thể tăng nhanh ở site media.
Do đó chiến lược hợp lý có thể backup database dày hơn files, miễn restore procedure biết cách ghép chúng thành restore point nhất quán.
Thiết kế lịch backup thực tế
Scheduled backup
Chạy theo chu kỳ để đáp ứng RPO và tạo restore points đều đặn.
Event-driven backup
Tạo backup trước thay đổi có rủi ro: cập nhật core/plugin/theme, migration, thay cấu hình quan trọng, deployment hoặc data import lớn. WordPress Developer Handbook khuyến nghị backup database trước upgrade; với change lớn, backup cả database và files thường hữu ích hơn.
Xem quy trình cập nhật WordPress an toàn để đặt backup đúng vị trí trong change workflow.
Full và incremental ảnh hưởng frequency thế nào?
Full backup thường tốn thời gian/dung lượng hơn. Incremental/differential có thể chạy dày hơn nhưng làm recovery phụ thuộc chain và tooling. Nếu chuỗi incremental dài hoặc phức tạp, restore test trở nên quan trọng hơn.
Đừng chọn incremental chỉ để đạt frequency đẹp trên dashboard nếu đội vận hành không thể phục hồi chain một cách đáng tin cậy.
Backup window và tải hệ thống
Backup có thể tiêu tốn CPU, I/O, database lock hoặc bandwidth. Chạy quá dày có thể ảnh hưởng production. Hãy đo duration, resource impact và chọn architecture/tooling đáp ứng RPO mà không tạo outage.
Ví dụ cách suy luận tần suất
Các ví dụ dưới đây chỉ minh họa phương pháp, không phải recommendation cố định:
- Site chỉ thay nội dung vài lần mỗi tháng: ưu tiên backup trước change + lịch định kỳ để phát hiện job failure.
- Blog cập nhật hàng ngày: database/files nên có restore point đủ gần với nhịp xuất bản.
- Store có giao dịch liên tục: tần suất database phải bám RPO của order/user data; có thể cần cơ chế bổ sung ngoài full backup truyền thống.
- Site đang migration: backup ngay trước cutover và giữ bản pre-change riêng dù lịch định kỳ vừa chạy.
Frequency không thay retention
Backup mỗi giờ nhưng chỉ giữ 24 giờ restore points vẫn có thể thất bại khi corruption hoặc malware được phát hiện sau vài ngày. Frequency trả lời “tạo restore point bao lâu một lần”; retention trả lời “giữ restore point trong bao lâu”. Hai policy phải thiết kế cùng nhau.
Để khóa retention theo detection delay và business need, xem Backup Retention. Backup cũng cần được bảo vệ khỏi attacker; xem bảo mật backup WordPress cho integrity và recovery.
Monitoring tần suất backup
Đừng chỉ cấu hình cron rồi quên. Theo dõi:
- Tuổi của restore point gần nhất.
- Job success/fail.
- Duration tăng bất thường.
- Backup size giảm/tăng đột biến.
- RPO thực tế có bị vượt khi job fail không.
Nếu hai job liên tiếp fail, khoảng cách giữa restore points có thể vượt xa lịch được cấu hình. Bài Backup Monitoring đi sâu vào freshness, missed schedule và repository health.
Frequency Decision Worksheet
| Câu hỏi | Giá trị cần điền |
|---|---|
| Business-approved RPO | … |
| Data change rate | … |
| Database change rate | … |
| Uploads/files change rate | … |
| Backup duration | … |
| Resource impact | … |
| Scheduled frequency | … |
| Event-driven trigger | … |
| Maximum tolerated missed jobs | … |
Acceptance test
- Frequency có lý do gắn với RPO/change rate.
- Database và files được đánh giá riêng nếu change rate khác nhau.
- Có backup trước change quan trọng khi cần.
- Monitoring phát hiện missed backup trước khi vượt RPO.
- Retention đủ dài để xử lý lỗi được phát hiện muộn.
- Restore test chứng minh tần suất và chain hiện tại phục hồi được.
Acceptance cuối nên được chứng minh bằng restore test thực tế, không chỉ bằng cấu hình lịch.
Nguồn kỹ thuật
- WordPress Developer — Backups
- WordPress Developer — Backing Up Your Database
- NIST SP 800-34 Rev. 1 — Contingency Planning Guide
Kết luận
Website nên backup bao lâu một lần phải được quyết định từ RPO, change rate và business impact. Lịch càng dày không tự động càng tốt; điều quan trọng là restore point đủ gần, hệ thống chịu được tải, missed job được phát hiện và backup vẫn restore được khi cần.