Website Backup là quá trình tạo và duy trì các bản sao có thể dùng để khôi phục website sau lỗi vận hành, cập nhật thất bại, xóa nhầm dữ liệu, sự cố hạ tầng hoặc security incident. Một bản backup chỉ có giá trị khi bạn biết rõ nó chứa gì, được lưu ở đâu, còn nguyên vẹn hay không và có thể restore trong thời gian mà doanh nghiệp chấp nhận được.
Vì vậy, câu hỏi đúng không phải chỉ là “website có backup chưa?”, mà là “chiến lược backup có đủ để đạt mục tiêu recovery của hệ thống này không?”. Bài này tập trung vào cách thiết kế chiến lược tổng thể; các control chuyên sâu gồm RPO/RTO, tần suất backup, retention, 3-2-1, offsite và restore test nên được xem là các lớp riêng trong cùng hệ thống.
Website Backup gồm những thành phần nào?
Với WordPress, một bản backup hoàn chỉnh thường cần cả database và files. WordPress lưu posts, pages, comments, options và nhiều dữ liệu động trong database; còn core, plugin, theme, uploads, wp-config.php và các file khác nằm trên filesystem. Chỉ tải thư mục web về máy thường không đồng nghĩa đã sao lưu database.
WordPress Developer Handbook cũng tách rõ hai lớp này và khuyến nghị coi database + files là một backup set để có thể phục hồi đầy đủ. Nếu cần đi sâu vào phần bảo vệ integrity và khả năng recovery của WordPress backup, xem bảo mật backup WordPress: restore integrity, retention và recovery.
Backup khác snapshot, replication và high availability như thế nào?
| Cơ chế | Mục tiêu chính | Điểm cần lưu ý |
|---|---|---|
| Backup | Khôi phục dữ liệu/hệ thống về trạng thái trước đó | Cần retention, integrity và restore test |
| Snapshot | Chụp nhanh trạng thái volume/VM tại một thời điểm | Có thể nằm cùng failure domain và không thay backup độc lập |
| Replication | Sao chép dữ liệu gần thời gian thực | Lỗi/xóa nhầm có thể được replicate sang bản sao |
| High Availability | Giảm downtime khi một node lỗi | Không tự động bảo vệ khỏi corruption hoặc compromise |
Một kiến trúc tốt có thể dùng nhiều cơ chế cùng lúc, nhưng đừng coi replication hoặc snapshot là bằng chứng rằng bạn đã có chiến lược backup đủ mạnh.
Bắt đầu chiến lược backup từ business impact
NIST SP 800-34 Rev. 1 xem backup và recovery là một phần của contingency planning và nhấn mạnh rằng phương án phục hồi phải phù hợp với mức độ ảnh hưởng khi hệ thống bị gián đoạn. Với website, điều đó có nghĩa là tần suất và phương pháp backup phải xuất phát từ giá trị của dữ liệu và mức downtime chấp nhận được, không phải từ một con số cố định dùng cho mọi site.
Hai câu hỏi đầu tiên: mất bao nhiêu dữ liệu và chờ bao lâu?
- RPO (Recovery Point Objective): lượng dữ liệu tối đa có thể chấp nhận mất, thường được diễn giải bằng khoảng thời gian.
- RTO (Recovery Time Objective): thời gian mục tiêu để đưa dịch vụ trở lại mức vận hành chấp nhận được.
Ví dụ một blog ít cập nhật có thể chấp nhận mất vài giờ nội dung, trong khi website thương mại có đơn hàng liên tục có thể cần RPO ngắn hơn. RPO/RTO phải được chủ hệ thống hoặc business owner chấp nhận; không nên tự đặt chỉ vì một plugin backup có sẵn lịch mặc định.
7 thành phần của một chiến lược backup website
1. Xác định dữ liệu và thành phần cần backup
Lập inventory database, uploads, plugin/theme tùy chỉnh, cấu hình, secrets reference, deployment artefact và dữ liệu do integration tạo ra. Phân biệt thứ có thể tải/cài lại từ nguồn tin cậy với dữ liệu duy nhất không thể tái tạo.
2. Chọn tần suất theo tốc độ thay đổi
Database có thể cần backup thường xuyên hơn files nếu site có đơn hàng, form hoặc user activity liên tục. Ngược lại uploads hoặc media cũng có thể thay đổi nhanh ở site nội dung. Tần suất phải dựa vào change rate + RPO, không chỉ “hàng ngày” vì thói quen.
3. Thiết kế retention
Giữ nhiều restore point để tránh tình huống bản backup gần nhất đã chứa corruption hoặc malware chưa được phát hiện. Retention nên có nhiều lớp thời gian phù hợp với nhu cầu điều tra và phục hồi, đồng thời tính tới chi phí lưu trữ và nghĩa vụ dữ liệu. Một failure mode thực tế là malware tồn tại trong nhiều generation backup khiến việc chọn restore point trở thành bài toán timeline và known-good state.
4. Tách failure domain
Nếu mọi backup nằm cùng server, cùng tài khoản cloud hoặc cùng quyền quản trị với production, một sự cố hạ tầng hay credential compromise có thể làm mất cả production lẫn backup. Offsite hoặc account/storage tách biệt giúp giảm rủi ro này. Case server hỏng nhưng website vẫn phục hồi nhờ Offsite Backup cho thấy vì sao tách failure domain quan trọng hơn việc chỉ có nhiều bản copy.
5. Bảo vệ confidentiality và integrity
Backup có thể chứa database, email, thông tin khách hàng, secret hoặc cấu hình nhạy cảm. Cần kiểm soát encryption phù hợp, quyền truy cập, audit, lifecycle credential và khả năng phát hiện bản backup bị sửa/xóa. Phần control-plane và ransomware protection được tách riêng ở Backup Security.
6. Tự động hóa nhưng phải monitoring
Backup job “được cấu hình” không đồng nghĩa backup vẫn chạy. Theo dõi job failure, dung lượng, thời gian hoàn tất, tuổi của restore point gần nhất và bất thường trong storage. Alert phải có owner xử lý; xem thêm Backup Monitoring. Một ví dụ điển hình là Backup Job âm thầm thất bại nhiều tuần và tạo Recovery Gap.
7. Restore test định kỳ
CISA khuyến nghị duy trì backup offline/encrypted cho dữ liệu quan trọng và kiểm thử định kỳ khả năng sẵn sàng và integrity trong kịch bản disaster recovery. Đây là quality gate quan trọng: backup không được coi là usable chỉ vì file tồn tại. Case có backup nhưng website vẫn không restore được là ví dụ rõ nhất về khoảng cách giữa “backup exists” và “recoverability”.
Backup Strategy Matrix
| Hạng mục | Câu hỏi cần chốt | Evidence |
|---|---|---|
| Scope | Backup database, files, config và integration nào? | Backup inventory |
| RPO | Mất tối đa bao nhiêu dữ liệu? | Business approval |
| RTO | Phục hồi trong bao lâu? | Recovery requirement |
| Frequency | Lịch nào đáp ứng RPO? | Job configuration + history |
| Retention | Cần bao nhiêu restore point? | Retention policy |
| Location | Có tách failure domain không? | Storage/account map |
| Security | Ai đọc/xóa/restore được? | Access control + audit |
| Integrity | Làm sao biết backup không hỏng? | Verification result |
| Restore | Đã test end-to-end chưa? | Restore test record |
Chiến lược backup cho các loại website khác nhau
Website giới thiệu ít thay đổi
Có thể ưu tiên backup trước mỗi thay đổi lớn, backup định kỳ database/files và giữ một số restore point dài hơn. Dù thay đổi ít, vẫn cần test restore và tách storage khỏi production.
Website nội dung cập nhật thường xuyên
Database và uploads có change rate cao hơn. Cần xem xét backup theo lịch dày hơn, giữ restore point nhiều tầng và kiểm tra khả năng khôi phục media + database nhất quán.
Website thương mại hoặc membership
Đơn hàng, user account và giao dịch làm RPO trở nên nhạy cảm. Restore toàn database về bản cũ có thể làm mất dữ liệu mới, nên chiến lược recovery cần tính tới dữ liệu phát sinh sau restore point và khả năng khôi phục chọn lọc.
Website đang trong security incident
Không nên mặc định restore ngay bản backup gần nhất. Trước hết phải xác định phạm vi, entry point, persistence và thời điểm backup còn đáng tin. Bài Incident Recovery Plan mô tả cách kết hợp recovery gate, credential, integrity và monitoring trước khi đưa website trở lại production.
Những lỗi backup phổ biến
- Chỉ backup database hoặc chỉ backup files nhưng tưởng là full-site backup.
- Giữ mọi bản sao trên cùng server hoặc cùng tài khoản có quyền xóa production.
- Không theo dõi job failure.
- Retention quá ngắn nên không còn known-good restore point.
- Không mã hóa dữ liệu nhạy cảm khi kiến trúc yêu cầu.
- Không kiểm tra khả năng giải mã hoặc credential recovery.
- Không test restore thực tế.
- Restore backup trong incident mà chưa kiểm tra backup có chứa persistence hay không.
Acceptance test cho chiến lược backup
- Scope backup được inventory và có owner.
- RPO/RTO được chấp nhận theo business impact.
- Lịch backup phù hợp change rate.
- Retention tạo đủ restore point cho lỗi vận hành và incident.
- Có ít nhất một bản sao tách failure domain phù hợp.
- Quyền đọc/xóa/restore được giới hạn và audit khi hệ thống hỗ trợ.
- Backup job có monitoring và alert owner.
- Restore test gần nhất PASS theo business flow quan trọng.
- Rollback/recovery procedure được cập nhật sau test.
Operational artifact: Backup Strategy Record
system: production-website
owner: <team/person>
backup_scope:
database: yes
files: yes
uploads: yes
config: yes
rpo: <business-approved>
rto: <business-approved>
frequency: <schedule>
retention: <policy>
storage_locations:
- <primary backup storage>
- <offsite/separate failure domain>
encryption: <at-rest/in-transit model>
last_successful_backup: <timestamp>
last_restore_test: <timestamp + result>
next_review: <date>
Mẫu trên là worksheet, không phải cấu hình bắt buộc. Các giá trị phải được điền từ hệ thống thật và được review sau thay đổi kiến trúc hoặc sau incident.
Nguồn kỹ thuật
- WordPress Developer — Backups
- WordPress Developer — Backing Up Your WordPress Files
- WordPress Developer — Backing Up Your Database
- NIST SP 800-34 Rev. 1 — Contingency Planning Guide
- CISA StopRansomware Guide — Backup and Recovery Practices
Kết luận
Website Backup chỉ thực sự có giá trị khi nó là một phần của chiến lược recovery có scope, RPO/RTO, frequency, retention, offsite protection, monitoring và restore test. Đừng đánh giá hệ thống bằng việc “có file backup”; hãy đánh giá bằng khả năng đưa website và dữ liệu quan trọng trở lại trạng thái chấp nhận được trong điều kiện sự cố thực tế.
Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem dịch vụ Backup & Recovery.