Disaster Recovery (DR) cho website là kế hoạch đưa website và các dịch vụ cần thiết trở lại hoạt động sau sự cố nghiêm trọng. Ngoài dữ liệu, phải kiểm tra khách còn đăng nhập, gửi liên hệ và đặt hàng được không.
Chủ doanh nghiệp cần biết: website được phép ngừng bao lâu, có thể mất bao nhiêu dữ liệu và ai cho phép mở lại. Có bản sao lưu chưa có nghĩa đã có kế hoạch khôi phục.
Disaster Recovery cho website khác backup thế nào?
Backup website giữ bản sao dữ liệu. Disaster Recovery rộng hơn: dùng bản sao, máy chủ, tên miền, tài khoản và người phụ trách để khôi phục dịch vụ.
| Backup | Disaster Recovery |
|---|---|
| Tạo và giữ bản sao | Đưa dịch vụ trở lại trạng thái hoạt động |
| Quan tâm dữ liệu, lịch sao lưu, thời gian lưu bản sao | Quan tâm mục tiêu dữ liệu, thời gian, các kết nối và thứ tự khôi phục |
| Có thể hoàn thành dù website vẫn chạy | Được kích hoạt khi có sự cố cần phục hồi |
| Thành công khi có bản sao hợp lệ | Thành công khi website và hành trình quan trọng hoạt động lại đúng |
Vì vậy, “hosting có backup” không đồng nghĩa website đã có kế hoạch Disaster Recovery.
Những sự cố nào có thể kích hoạt Disaster Recovery?
- Máy chủ hoặc vùng hạ tầng gặp lỗi khiến production không thể tiếp tục.
- Database hỏng, bị xóa hoặc thay đổi sai trên diện rộng.
- Deploy, cập nhật hoặc migration làm website không thể khôi phục nhanh bằng rollback thông thường.
- Tài khoản hoặc hệ thống bị xâm nhập và production không còn đáng tin cậy.
- Ransomware hoặc mã độc ảnh hưởng tới dữ liệu và bản sao đang online.
- Nhà cung cấp hosting, DNS, storage hoặc thành phần phụ thuộc quan trọng gián đoạn.
Nếu nghi bị tấn công, cần theo quy trình xử lý website bị hack. Không dùng bản sao mới nhất nếu chưa kiểm tra nó có nhiễm mã độc không.
RPO và RTO phải xuất phát từ tác động kinh doanh
RPO là khoảng mất dữ liệu tối đa doanh nghiệp chấp nhận khi quay về bản sao cũ. RTO là thời gian ngừng dịch vụ tối đa có thể chấp nhận. Theo AWS, đây là mục tiêu từ nhu cầu kinh doanh.
| Loại website | Câu hỏi RPO | Câu hỏi RTO |
|---|---|---|
| Website giới thiệu | Mất các chỉnh sửa gần nhất có ảnh hưởng đáng kể không? | Website có thể offline bao lâu trước khi ảnh hưởng thương hiệu hoặc chiến dịch? |
| Lead generation | Có thể mất bao nhiêu form hoặc dữ liệu lead? | Khi nào form và landing page phải hoạt động lại? |
| WooCommerce | Có thể mất bao nhiêu đơn hàng, trạng thái thanh toán hoặc tồn kho? | Khi nào checkout phải hoạt động trở lại? |
| Membership/LMS | Có thể mất bao nhiêu tài khoản, tiến độ hay giao dịch? | Khi nào người dùng cần đăng nhập và sử dụng lại? |
RPO/RTO càng chặt thường đòi hỏi kiến trúc, automation và chi phí vận hành cao hơn. Mục tiêu hợp lý là mục tiêu được doanh nghiệp chấp nhận và hệ thống có khả năng chứng minh bằng kiểm thử.
Ví dụ giả định: website hỏng lúc 14 giờ, bản sao sạch gần nhất ở 13 giờ. Các đơn mới trong khoảng đó có thể không có trong bản phục hồi. Cần đối soát với hệ thống thanh toán và dữ liệu còn lưu.
Bảy phần của kế hoạch phục hồi website
1. Chọn chức năng quan trọng
Ưu tiên biểu mẫu, đơn hàng, đăng nhập và chức năng đang tạo doanh thu. Cần người đại diện doanh nghiệp quyết định thứ tự.
2. Liệt kê phần phụ thuộc
Liệt kê tên miền, DNS, hosting, dữ liệu, email, thanh toán, CRM và tài khoản quản trị. Thiếu một quyền truy cập cũng có thể làm website không mở lại được.
3. Chọn phương án phục hồi
Có thể phục hồi trên máy chủ sạch hoặc sử dụng máy dự phòng. AWS mô tả nhiều mô hình theo chi phí và mục tiêu. Không phải website nhỏ nào cũng cần dự phòng đắt tiền.
4. Chọn bản dữ liệu tin cậy
Bản sao phải đủ mới, dùng được và an toàn. Nếu bị tấn công, cần kiểm tra cả mã độc hoặc thay đổi trái phép có thể đã có trong bản sao.
5. Chuẩn bị quyền truy cập
Phải biết ai giữ quyền hosting, tên miền, DNS và kho sao lưu. Chuẩn bị quyền dự phòng an toàn khi người phụ trách chính vắng mặt.
6. Hướng dẫn từng bước
Ghi thứ tự việc làm, người quyết định, điều kiện được mở lại và phương án nếu phục hồi chưa đạt. Không phụ thuộc vào trí nhớ của một người.
Xem Disaster Recovery Runbook cho website để thực hiện từng bước kỹ thuật. Bài này tập trung vào các quyết định và tiêu chí nghiệm thu.
7. Kiểm tra và diễn tập
Cần thử phục hồi và ghi thời gian thực tế. Kiểm tra cả người thực hiện, quyền, máy chủ và chức năng mà khách sử dụng.
Mười bước phục hồi website sau sự cố
- 1. Xác nhận sự cố: xác định phạm vi và người kích hoạt kế hoạch.
- 2. Dừng thay đổi: tránh ghi thêm dữ liệu hoặc sửa nhiều phần cùng lúc.
- 3. Giữ bằng chứng: lưu nhật ký nếu nghi có tấn công.
- 4. Chọn bản sao: kiểm tra độ mới, lỗi và độ an toàn.
- 5. Dựng nơi phục hồi: ưu tiên hệ thống sạch và tách biệt khi cần.
- 6. Khôi phục: dữ liệu, mã, cấu hình, quyền và kết nối thiết yếu.
- 7. Thử chức năng: đăng nhập, biểu mẫu, đơn hàng, email.
- 8. Phê duyệt mở lại: chỉ chuyển truy cập sau khi đạt điều kiện.
- 9. Giám sát tiếp: kiểm tra lỗi qua Website Monitoring.
- 10. Rút kinh nghiệm: ghi thời gian, dữ liệu thiếu và việc cần sửa.
Backup thành công nhưng Disaster Recovery vẫn có thể thất bại
Có bản sao vẫn có thể thất bại vì thiếu ảnh, mất quyền DNS, thiếu khóa kết nối hoặc email không gửi được. Trang chủ mở lại chưa có nghĩa khách đã đặt hàng được.
Đây là lý do DR cần được xem như một năng lực vận hành, không phải một thư mục chứa file nén.
Khôi phục website bán hàng: tránh mất đơn và thu tiền trùng
Khôi phục bản sao cũ có thể thiếu đơn mới, tài khoản khách hoặc trạng thái thanh toán. WooCommerce khuyên phải bảo vệ dữ liệu phát sinh sau lần sao lưu.
Nếu cửa hàng dùng WooCommerce Subscriptions, lịch gia hạn cũ có thể chạy lại sau phục hồi. Theo tài liệu WooCommerce, phải đối soát để tránh xử lý tiền trùng. Khi quay về máy chủ chính, đừng ghi đè đơn phát sinh trên máy dự phòng.
Khác nhau giữa thử bản sao và diễn tập toàn bộ kế hoạch
| Restore test | DR drill |
|---|---|
| Kiểm tra backup có phục hồi được không | Kiểm tra toàn bộ kế hoạch phục hồi dịch vụ |
| Thường tập trung vào dữ liệu và ứng dụng | Bao gồm người, quyền, hệ thống phụ thuộc và thời gian |
| Có thể làm định kỳ trên môi trường thử | Nên mô phỏng kịch bản sự cố thực tế |
| Kết quả: bản dữ liệu phục hồi có dùng được | Kết quả: hệ thống có đáp ứng RPO/RTO và quy trình hay không |
Disaster Recovery cần kết nối với Monitoring và Incident Response
DR cần đi cùng Website Monitoring. Giám sát giúp phát hiện và kiểm tra sau sự cố. Người phụ trách quyết định khi nào cần phục hồi toàn bộ.
Trong quản trị và vận hành website, hãy phân rõ người nhận cảnh báo, người phục hồi và người nghiệm thu. Không mở lại website khi chưa xác minh an toàn.
Chủ doanh nghiệp nghiệm thu kế hoạch DR thế nào?
- Có chức năng ưu tiên, RPO/RTO và người phê duyệt.
- Có bản sao lưu đủ tin cậy và đã thử khôi phục.
- Biết ai giữ quyền truy cập hosting, DNS và kho sao lưu.
- Đã thử biểu mẫu, đăng nhập, email và đặt hàng an toàn.
- Đã đối soát đơn mới, tiền đã thu và dữ liệu khách.
- Có kết quả diễn tập và người theo dõi sau phục hồi.
FAQ
Website nhỏ có cần Disaster Recovery không?
Không cần máy chủ dự phòng đắt tiền ngay. Tối thiểu phải có bản sao dùng được, quyền truy cập, người phụ trách và cách thử liên hệ.
Có backup hằng ngày thì đã đủ DR chưa?
Chưa. Đơn hoặc liên hệ phát sinh sau lần sao lưu có thể chưa nằm trong bản sao. DR còn cần người và cách phục hồi, kiểm tra.
RTO càng thấp càng tốt phải không?
Không. RTO phải dựa vào mức gián đoạn doanh nghiệp chịu được và chi phí đáp ứng. Không cam kết thời gian chưa diễn tập.
Khi website bị hack có nên restore bản backup gần nhất?
Không. Cần kiểm tra bản sao có an toàn, tài khoản bị chiếm quyền chưa và nguyên nhân sự cố đã xử lý chưa.
Kết luận
DR không chỉ đưa tập tin trở lại máy chủ. Cần kết hợp dữ liệu, con người, thời gian, quyền và bằng chứng để website phục vụ khách an toàn.
Hướng dẫn nền tảng về ưu tiên nghiệp vụ, trách nhiệm và diễn tập có trong NIST SP 800-34 Rev.1.
Đọc chuyên sâu về Disaster Recovery
- RPO và RTO cho website: đặt recovery objective theo business impact trước khi chọn kiến trúc phục hồi.
- Kiểm tra restore backup website: chứng minh recovery point có thể đưa dữ liệu và ứng dụng trở lại trạng thái usable.
- Disaster Recovery Runbook: biến DR plan thành các bước trigger, restore, smoke test, go/no-go và monitoring.
- DR Drill cho website: kiểm chứng end-to-end con người, quyền, dependency, runbook và thời gian recovery thực tế.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.