3 bước giúp bạn sẵn sàng cho thảm họa dữ liệu ngay từ bây giờ

Các sự cố mất mát, hư hỏng dữ liệu luôn là điều đáng sợ với bất kỳ người quản lý IT nào. Càng đáng lo lắng hơn khi bạn biết rằng những sự cố này trước sau gì cũng xảy ra, vấn đề chỉ là lúc nào và mức độ nghiêm trọng như thế nào mà thôi. Điều tốt nhất người IT có thể làm là chuẩn bị và chuẩn bị một cách tốt nhất cho tình huống nó xảy ra.

Hẳn nhiên, việc triển khai một giải pháp dự phòng thảm họa (DR) hoàn chỉnh không phải là vấn đề đơn giản. Đặc biệt với các DN không có nhiều nguồn lực tài chính và nhân sự cho công tác IT. Nếu chưa biết bắt đầu từ đâu, 3 bước nền tảng bên dưới làm tham khảo quan trọng giúp bạn chuẩn bị cho tình huống DR.

1. Xác định RPO/RTO

Khi triển khai bất kỳ giải pháp nào, điều căn bản nhất để bắt đầu là xác định rõ mục tiêu muốn đạt được. Với DR, mục tiêu này chính là 2 giá trị: RPO và RTO. Đây là 2 giá trị bạn cần định lượng rõ và có sự thống nhất với lãnh đạo công ty. Bởi 2 giá trị này sẽ quyết định giải pháp và cơ chế bạn tiến hành sao lưu dữ liệu.

RPO – Recovery Point Objective

RPO là lượng dữ liệu mà công ty bạn chấp nhận mất mát khi sự cố xảy ra. Có thể bạn thắc mắc: Đã là DR thì sao lại có chuyện mất mát ở đây? Thực tế, chỉ trừ phi bạn triển khai giải pháp đồng bộ thời gian thực (Real-time Sync) thì mới không có mất mát dữ liệu khi sự cố xảy ra với hệ thống chính; còn ngoài ra, cho dù bạn sao lưu tốt thế nào thì khi phục hồi vẫn mất một lượng dữ liệu (so với khi không có sự cố). Trong ý nghĩa của RPO, lượng dữ liệu bị mất mát này có thể tính bằng đơn vị giờ làm việc, ngày làm việc,…

RPO là giá trị quan trọng bởi nó ảnh hưởng đến tần suất sao lưu dữ liệu. Và với những dữ liệu có yêu cầu RPO cao thì tần suất sao lưu này lại ảnh hưởng đến giải pháp, phần mềm sao lưu bạn chọn triển khai. Điều gì sẽ xảy ra nếu lãnh đạo công ty chỉ chấp nhận mất lượng dữ liệu 2 giờ nhưng bản sao lưu gần nhất bạn có thể phục hồi cách đó đã 1 tuần.

RTO – Recovery Time Objective

RTO xác định khoảng thời gian bạn tiến hành phục hồi để hệ thống có thể hoạt động trở lại, tức là khoảng thời gian công ty bạn chấp nhận ngưng trệ. Nếu thời gian này quá lâu, hoạt động công ty bạn chắc chắn gặp nhiều ảnh hưởng. VD: Bạn cần 2 ngày để phục hồi hệ thống mail Exchange Server, cũng đồng nghĩa trong 2 ngày đó nhân viên công ty bạn không thể liên lạc bằng email với khách hàng, đối tác. Hoặc phải sử dụng phương thức liên lạc khác.

2. Sao lưu offsite

Hẳn nhiên những sự cố dữ liệu thường xảy ra nhất là virus, hư ổ cứng, nhân viên thao tác nhầm. Ở những tình huống này, bản sao lưu onsite vẫn có thể giúp bạn phục hồi. Thậm chí rất nhanh vì bản sao lưu là onsite, bạn có thể nhanh chóng tiến hành hơn là bản offsite.

Tuy nhiên, bạn không thể biết được sự cố nào sẽ xảy ra với dữ liệu. Đó có thể là cháy nổ, kẻ xấu phá hoại, trộm cắp,… Với những thảm họa này, nếu bản sao lưu được lưu onsite gần dữ liệu gốc, khả năng mất mát cả hai là không nhỏ. Do đó, việc lưu trữ bản sao lưu offsite cách xa dữ liệu gốc vẫn là điều tốt hơn. Và tốt nhất là có cả bản sao lưu offsite lẫn onsite.

Nếu sao lưu bằng Tape hay HDD, bạn cần vận chuyển thiết bị này đi lưu trữ cách xa. Nếu dùng những dịch vụ Cloud Backup như zBackup, quá trình sao lưu offsite là hoàn toàn tự động. Bạn không phải mất thời gian tiến hành thao tác này.

3. Testing, testing, testing

Sao lưu là một chuyện nhưng phục hồi lại là chuyện khác. Tình huống sao lưu thường xuyên nhưng không thể phục hồi không phải là chuyện hiếm. Mà nguyên nhân chính ở đây là người IT không thường xuyên kiểm tra (testing) dữ liệu để kịp thời phát hiện các sai sót trong quá trình sao lưu. Có rất nhiều lý do dẫn đến tình trạng này: Tape bị lỗi không đọc được, bản sao lưu bị sai, hoặc thậm chí hoàn toàn không có dữ liệu trong Tape/Disk. Còn phải kể đến tình huống người IT vì không testing thường xuyên nên không nắm bắt được cách thức tiến hành phục hồi, đặc biệt với các ứng dụng phức tạp như Active Directory, SQL Server, Exchange Server, Oracle,…