Disaster recovery khác backup ở đâu
Backup trả lời câu hỏi: nếu dữ liệu bị mất hoặc hỏng, có bản sao để lấy lại không. Disaster recovery (khôi phục sau thảm hoạ, viết tắt DR) trả lời một câu hỏi rộng hơn: nếu toàn bộ hệ thống ngừng hoạt động, gồm cả server, phần mềm, cấu hình mạng, không chỉ riêng dữ liệu, thì doanh nghiệp cần làm gì, theo thứ tự nào, và mất bao lâu để mọi thứ hoạt động trở lại bình thường.
Ví dụ để thấy khác biệt: một doanh nghiệp có backup dữ liệu đầy đủ, nhưng server chính đặt tại văn phòng bị cháy hoặc ngập nước. Có bản sao dữ liệu không đồng nghĩa với việc doanh nghiệp biết ngay phải dựng lại hệ thống ở đâu, bằng phần cứng nào, ai là người chịu trách nhiệm từng bước, và trong lúc dựng lại thì nhân viên và khách hàng nên được thông báo ra sao. Đó chính là phần disaster recovery bổ sung mà backup đơn thuần không có.
Hai chỉ số cần biết: RTO và RPO
Hai chỉ số này là ngôn ngữ chung khi trao đổi với đội kỹ thuật hoặc nhà cung cấp dịch vụ hạ tầng về mức độ sẵn sàng cần có.
- RTO (Recovery Time Objective, mục tiêu thời gian khôi phục): tối đa bao lâu doanh nghiệp chấp nhận hệ thống ngừng hoạt động trước khi phải hoạt động trở lại. Ví dụ RTO 4 giờ nghĩa là kể từ lúc sự cố xảy ra, hệ thống phải hoạt động lại trong vòng 4 giờ.
- RPO (Recovery Point Objective, mục tiêu điểm khôi phục): tối đa bao nhiêu dữ liệu doanh nghiệp chấp nhận mất, tính theo thời gian kể từ lần backup gần nhất. Ví dụ RPO 24 giờ nghĩa là nếu sự cố xảy ra, doanh nghiệp chấp nhận mất dữ liệu phát sinh trong tối đa 24 giờ trước đó, vì bản backup gần nhất được lấy cách đó 24 giờ.
RTO và RPO càng ngắn thì chi phí đầu tư hạ tầng càng cao, vì đòi hỏi backup thường xuyên hơn và có hệ thống dự phòng sẵn sàng thay thế nhanh hơn. Doanh nghiệp nhỏ không cần copy nguyên mô hình của ngân hàng (RTO/RPO tính bằng phút), mà cần tự xác định mức chấp nhận được thực tế của mình, dựa trên câu hỏi đơn giản: nếu hệ thống ngừng chạy một ngày, thiệt hại có nghiêm trọng tới mức phải đầu tư nhiều hơn để rút ngắn thời gian đó không.
Bốn bước bắt đầu cho doanh nghiệp nhỏ, chưa có ngân sách lớn
Bước 1: Liệt kê hệ thống nào thật sự "không thể ngừng"
Không phải hệ thống nào cũng cần mức độ sẵn sàng như nhau. Một doanh nghiệp thường có hệ thống bán hàng, website, email nội bộ, phần mềm kế toán. Nên xếp hạng: nếu chỉ được cứu một hệ thống trước, hệ thống nào ảnh hưởng doanh thu trực tiếp nhất, tức thời nhất. Đó là nơi nên đầu tư DR trước, thay vì dàn trải đều cho mọi hệ thống.
Bước 2: Viết ra, không chỉ giữ trong đầu một người
Kế hoạch disaster recovery hữu ích nhất khi được viết thành tài liệu cụ thể: sự cố loại nào thì gọi ai, liên hệ nhà cung cấp hosting bằng cách nào, tài khoản quản trị lưu ở đâu, ai có quyền truy cập backup để khôi phục. Nhiều doanh nghiệp nhỏ chỉ có một người (thường là quản lý IT hoặc người sáng lập) nắm hết thông tin này trong đầu. Nếu người đó không liên lạc được đúng lúc sự cố xảy ra, cả doanh nghiệp bị kẹt theo.
Bước 3: Test khôi phục thật, không chỉ tin backup đang chạy
Giống nguyên tắc đã nêu ở bài backup: một kế hoạch DR chưa từng thử nghiệm thực tế không đáng tin. Nên có ít nhất một lần mỗi năm diễn tập giả lập: giả sử hệ thống chính không truy cập được, đo xem thực tế mất bao lâu để dựng lại và hoạt động bình thường, so với mục tiêu RTO đã đặt ra. Khoảng cách giữa lý thuyết và thực tế thường lớn hơn dự đoán.
Bước 4: Cân nhắc hạ tầng dự phòng theo đúng mức chấp nhận rủi ro
Với doanh nghiệp nhỏ, không nhất thiết phải đầu tư một trung tâm dữ liệu dự phòng riêng. Nhiều nhà cung cấp cloud (như AWS, Google Cloud, hoặc nhà cung cấp trong nước) đã có sẵn tuỳ chọn sao lưu sang khu vực (region) khác với chi phí hợp lý hơn nhiều so với tự xây. Với hệ thống nhỏ, đôi khi giải pháp thực tế nhất chỉ là: đảm bảo có thể dựng lại toàn bộ hệ thống từ backup trên một server mới trong vài giờ, không cần hệ thống dự phòng chạy song song 24/7.
