1. Backup là gì?
Backup (sao lưu dữ liệu) là quá trình tạo ra bản sao có thể sử dụng được của dữ liệu và/hoặc cấu hình hệ thống, nhằm phục hồi hệ thống về trạng thái chấp nhận được khi xảy ra sự cố.
Điểm cần nhấn mạnh:
Backup không phải là hành động sao chép dữ liệu, mà là một cam kết có thể phục hồi.
Một bản backup chỉ thực sự có giá trị khi:
Có thể restore thành công
Restore đúng dữ liệu
Restore trong thời gian cho phép
Nếu không đáp ứng được ba điều trên, thì dù có “backup đầy ổ cứng”, hệ thống vẫn coi như không có backup.
2. Backup KHÔNG phải là Restore, và càng không phải Disaster Recovery
Trong thực tế vận hành, ba khái niệm này thường bị đánh đồng:
| Khái niệm | Bản chất |
|---|---|
| Backup | Tạo bản sao dữ liệu |
| Restore | Phục hồi dữ liệu từ backup |
| Disaster Recovery (DR) | Khôi phục toàn bộ hệ thống và dịch vụ |
Một hệ thống có thể:
Có backup
Nhưng không restore được
Và hoàn toàn không có khả năng DR
📌 Đây là nguyên nhân hàng đầu khiến backup “tồn tại trên giấy”.
3. Vì sao backup luôn được triển khai, nhưng vẫn thất bại?
3.1. Vì backup thường được coi là việc phụ
Trong nhiều tổ chức:
Triển khai hệ thống → ưu tiên chạy được
Vận hành → ưu tiên không lỗi
Backup → “làm sau cũng được”
Backup thường:
Giao cho người ít kinh nghiệm nhất
Không có người chịu trách nhiệm rõ ràng
Không có KPI, không được kiểm tra định kỳ
Hệ quả:
Backup có chạy, nhưng không ai biết nó có dùng được hay không
3.2. Vì chỉ backup dữ liệu, không backup hệ thống
Một sai lầm phổ biến:
“Có database backup là đủ.”
Thực tế:
Có DB backup nhưng:
Mất cấu hình web server
Mất cấu hình PHP
Mất reverse proxy
Mất SSL
Không dựng lại được hệ thống để restore DB
📌 Backup dữ liệu mà không backup môi trường vận hành → restore thất bại.
3.3. Vì backup nằm cùng chỗ với hệ thống chính
Rất nhiều hệ thống:
Backup lưu trên chính server đang chạy
Hoặc cùng storage, cùng mạng, cùng quyền ghi
Khi xảy ra:
Hỏng ổ cứng
Lỗi RAID
Ransomware
Lỗi thao tác xóa nhầm
→ Production và backup cùng chết một lúc
📌 Backup như vậy chỉ là bản sao tiện lợi, không phải bản sao an toàn.
3.4. Vì không có chính sách lưu giữ (Retention Policy)
Backup không có kế hoạch giữ lâu dài dẫn đến:
Ghi đè backup cũ
Chỉ giữ vài ngày gần nhất
Khi phát hiện lỗi dữ liệu muộn → không còn bản backup sạch
Điển hình:
Dữ liệu bị sai từ 2 tháng trước
Backup chỉ giữ 7 ngày
Không có cách quay lại trạng thái đúng
3.5. Vì không bao giờ test restore
Đây là lỗi nghiêm trọng nhất.
Rất nhiều hệ thống:
Chưa từng thử restore
Chưa từng dựng lại server từ backup
Chưa từng kiểm tra:
Restore mất bao lâu
Có thiếu file nào không
Có chạy được dịch vụ không
📌 Backup chưa test restore = backup chưa tồn tại
4. Backup thất bại không phải do công cụ, mà do tư duy
Trong thực tế:
Rsync không sai
Tar không sai
Borg, Restic, Veeam cũng không sai
Backup thất bại vì:
Không có chiến lược
Không có kiến trúc
Không có trách nhiệm
Không có diễn tập phục hồi
5. Backup đúng nghĩa phải trả lời được 5 câu hỏi
Một hệ thống backup đúng nghĩa phải trả lời rõ ràng:
Backup cái gì?
(Dữ liệu, cấu hình, hệ thống nào là sống còn)Backup ở đâu?
(On-site, off-site, offline)Backup bao lâu?
(7-4-12-5 hay chính sách khác)Khi nào cần restore?
(RPO)Restore trong bao lâu?
(RTO)
Nếu không trả lời được 5 câu hỏi này, backup gần như chắc chắn sẽ thất bại khi cần dùng.
Backup không thất bại vì thiếu công nghệ,
mà vì thiếu tư duy quản trị rủi ro.
Backup chỉ thực sự có giá trị khi:
Được thiết kế như một phần của hệ thống
Được kiểm soát, kiểm tra và diễn tập
Được coi là năng lực phục hồi, không phải thao tác kỹ thuật đơn lẻ
- Đăng nhập để gửi ý kiến
