1. Vì sao cần liệt kê kịch bản mất dữ liệu?
Trong vận hành hệ thống, câu hỏi không phải là “có sự cố hay không”, mà là:
Sự cố nào sẽ xảy ra trước, xảy ra như thế nào, và chúng ta có sẵn sàng hay không.
Phần lớn hệ thống thất bại vì:
Chỉ backup theo thói quen
Không phân tích rủi ro thực tế
Không gắn backup với kịch bản cụ thể
📌 Backup không dựa trên kịch bản = backup cảm tính.
2. Kịch bản 1: Lỗi người vận hành (Human Error)
2.1. Các tình huống thường gặp
Xóa nhầm database
Chạy sai script production
Ghi đè file cấu hình
Rsync sai chiều
Import nhầm dữ liệu test lên production
📌 Đây là nguyên nhân phổ biến nhất, không phải hacker.
2.2. Vì sao backup thường không cứu được?
Backup bị ghi đè nhanh
Không có bản backup cũ hơn
Không có snapshot trước khi thao tác
📌 Khi phát hiện lỗi, backup sạch đã không còn.
2.3. Yêu cầu đối với backup
Có retention policy rõ ràng
Có bản backup theo thời gian
Có snapshot trước thao tác nguy hiểm
3. Kịch bản 2: Lỗi phần cứng (Hardware Failure)
3.1. Tình huống thực tế
Hỏng ổ cứng
RAID rebuild lỗi
SSD chết đột ngột
Mainboard, PSU lỗi
📌 RAID không phải backup.
3.2. Hệ quả
Mất toàn bộ dữ liệu
Server không boot được
Downtime kéo dài
3.3. Yêu cầu đối với backup
Backup tách khỏi server
Có off-site copy
Không phụ thuộc vào RAID
4. Kịch bản 3: Lỗi phần mềm và cập nhật
4.1. Tình huống
Update OS lỗi
Update PHP, database không tương thích
Composer update làm hỏng site
Migration database lỗi
4.2. Vì sao nguy hiểm?
Lỗi không phát hiện ngay
Dữ liệu bị ghi sai âm thầm
Khi phát hiện thì đã qua nhiều ngày
4.3. Yêu cầu đối với backup
Có backup trước update
Có khả năng rollback
Giữ backup dài hơn vài ngày
5. Kịch bản 4: Tấn công mã độc và ransomware
5.1. Đặc điểm
Mã hóa dữ liệu
Xóa hoặc mã hóa cả backup
Tấn công theo quyền hệ thống
5.2. Vì sao backup thất bại?
Backup mount writable
Backup dùng chung user
Không có off-site / offline copy
📌 Khi bị tấn công, backup cũng bị mã hóa.
5.3. Yêu cầu đối với backup
Backup off-site
Tách quyền ghi
Có bản offline / air-gap
6. Kịch bản 5: Lỗi mạng, lỗi trung tâm dữ liệu
6.1. Tình huống
Mất điện diện rộng
Mất mạng
Sự cố trung tâm dữ liệu
Cháy, ngập nước
6.2. Hệ quả
Toàn bộ hệ thống ngừng hoạt động
Không thể truy cập backup nếu backup cùng DC
6.3. Yêu cầu đối với backup
Có backup ngoài DC
Có kế hoạch DR
Có điểm phục hồi độc lập
7. Kịch bản 6: Lỗi logic dữ liệu (Silent Data Corruption)
7.1. Mô tả
Dữ liệu bị sai nhưng hệ thống vẫn chạy
Không có log lỗi rõ ràng
Phát hiện muộn
Ví dụ:
Báo cáo sai
Dữ liệu bệnh nhân không nhất quán
Lịch sử bị ghi đè
7.2. Vì sao nguy hiểm?
Backup gần nhất cũng đã sai
Không biết bản nào là đúng
7.3. Yêu cầu đối với backup
Giữ backup dài hạn
Có kiểm tra tính toàn vẹn
Có khả năng so sánh dữ liệu lịch sử
8. Kịch bản 7: Thảm họa tổng thể (Worst Case)
8.1. Tình huống
Mất toàn bộ hệ thống
Không còn server nào hoạt động
Không còn quyền truy cập
8.2. Câu hỏi sống còn
Backup có nằm ở nơi khác không?
Có ai khác truy cập được không?
Có tài liệu phục hồi không?
9. Liên hệ với hệ thống thực tế
Trong các hệ thống:
Dịch vụ người bệnh
Hệ thống nội bộ bệnh viện
Hạ tầng nhiều lớp (proxy – web – DB)
Thực tế thường gặp kết hợp nhiều kịch bản cùng lúc:
Lỗi người + lỗi phần mềm
Lỗi phần cứng + lỗi mạng
Ransomware + backup không tách biệt
Backup không được thiết kế để chống lại một sự cố lý tưởng,
mà để sống sót qua những kịch bản xấu nhất có khả năng xảy ra.
Hiểu đúng các kịch bản mất dữ liệu là bước bắt buộc trước khi:
Chọn công cụ
Thiết kế kiến trúc
Xây dựng SOP backup
- Đăng nhập để gửi ý kiến
