Server chết, diaster recovery là một kế hoạch lớn. Rất nhiêu khê, nhiêu việc nhỏ nhỏ, không thể vội được. Cần hết sức bình tĩnh và rà soát từng lớp - từng khía cạnh để phục hồi. Có thể mất hàng tuần hay hàng tháng mới trở lại ban đầu. Nhất là khi trước đó mình không backup tất cả mọi thứ nên nhiều thứ cần phải cấu hình, build lại.
1. Disaster Recovery không phải là sự cố kỹ thuật thông thường
Disaster xảy ra khi:
Server chết hoàn toàn
Storage hỏng
Mất cả site
Ransomware phá hủy dữ liệu
Trong các tình huống này:
Không có gì để “sửa”
Không có gì để “rollback”
Chỉ còn backup và quyết định con người
Disaster Recovery là lúc tổ chức được kiểm tra, không chỉ hệ thống.
2. Mục tiêu thực tế của Disaster Recovery
DR không nhằm:
Phục hồi 100% ngay lập tức
Dựng lại hệ thống hoàn hảo
DR nhằm:
Khôi phục dịch vụ sống còn
Trong thời gian chấp nhận được
Với dữ liệu tin cậy
📌 Sống lại trước, hoàn thiện sau.
3. Đánh giá nhanh sau thảm họa (Initial Assessment)
Ngay khi disaster xảy ra, cần xác định:
Mức độ mất mát (1 server, nhiều server, toàn site)
Thành phần còn sống
Backup còn dùng được không
RPO/RTO có còn khả thi không
📌 Không phục hồi khi chưa đánh giá.
4. Kích hoạt kịch bản DR
Một tổ chức trưởng thành phải có:
Người kích hoạt DR
Quyền ra quyết định
Quy trình rõ ràng
📌 DR không thể kích hoạt ngẫu hứng.
5. Chuẩn bị môi trường DR
Có thể là:
Site dự phòng
Cloud
Server thuê tạm
Hạ tầng nội bộ còn sống
Chuẩn bị:
OS
Network
Storage
Access
📌 DR site không cần giống 100%, nhưng phải đủ để chạy.
6. Trình tự phục hồi toàn hệ thống (High-level)
Thứ tự ưu tiên:
Network & truy cập
Storage
OS
Database
Application backend
Web server
Reverse proxy / DNS
Giám sát
📌 Không đảo ngược thứ tự.
7. Phục hồi database – trục sống còn
Chọn thời điểm backup đúng
Restore logic (dump)
Kiểm tra dữ liệu nghiệp vụ
📌 Database là nguồn sự thật, phải phục hồi trước ứng dụng.
8. Phục hồi ứng dụng và dịch vụ
Restore code
Restore config
Restore file upload
Khớp DB
📌 Không bật public khi chưa test nội bộ.
9. Reverse proxy và công bố dịch vụ
Dựng proxy DR
Cập nhật routing
Điều chỉnh DNS
Bật public từng phần
📌 Công bố dịch vụ là quyết định nghiệp vụ, không chỉ kỹ thuật.
10. Giao tiếp trong DR
Cần:
Thông báo nội bộ
Thông báo người dùng (nếu cần)
Báo cáo lãnh đạo
📌 Giao tiếp kém làm DR thất bại ngay cả khi kỹ thuật đúng.
11. Kiểm soát rủi ro trong quá trình DR
Không xóa backup gốc
Không restore đè vội
Không “sửa tạm” không ghi nhận
📌 DR không phải lúc để sáng tạo.
12. Sau khi hệ thống sống lại (Post-DR)
Giám sát chặt
Soát dữ liệu
Đánh giá chênh lệch
Lập kế hoạch phục hồi hoàn chỉnh
📌 DR không kết thúc khi hệ thống chạy, mà khi hệ thống ổn định.
13. Diễn tập DR – điều bắt buộc
Không diễn tập → DR thất bại
Diễn tập giúp:
Rút ngắn RTO
Phát hiện thiếu sót
Huấn luyện con người
📌 DR là năng lực, không phải tài liệu.
14. Sai lầm phổ biến trong Disaster Recovery
Không có kịch bản DR
Không có người quyết định
Chỉ dựa vào replication
Không test backup off-site
Không diễn tập
15. Checklist Disaster Recovery (tóm tắt)
Backup off-site sẵn sàng
Key mã hóa sẵn sàng
SOP DR rõ ràng
Phân quyền rõ
Đã từng diễn tập
Disaster Recovery không phải là kế hoạch cho “nếu”,
mà là kế hoạch cho “khi”.
Một tổ chức trưởng thành:
Không hy vọng disaster không xảy ra
Mà chuẩn bị để sống sót khi nó xảy ra
Backup là nền móng.
Phục hồi là hành động.
Disaster Recovery là năng lực chiến lược.
- Đăng nhập để gửi ý kiến
