RPO và RTO: xác định mục tiêu khôi phục trước khi chọn giải pháp backup

ByDHTD Admin

Khi nói về backup, câu hỏi thường được đặt ra đầu tiên là dùng phần mềm nào hoặc lưu ở đâu. Câu hỏi đúng hơn là: nếu hệ thống gặp sự cố, doanh nghiệp chấp nhận mất tối đa bao nhiêu dữ liệu và chờ tối đa bao lâu để hoạt động trở lại? Hai con số trả lời câu hỏi này là RPO và RTO.

RPO và RTO là gì?

  • RPO (Recovery Point Objective): điểm thời gian xa nhất mà dữ liệu có thể bị mất. Nếu RPO là một giờ, backup hoặc nhân bản phải đủ thường xuyên để mất tối đa dữ liệu một giờ gần nhất.
  • RTO (Recovery Time Objective): khoảng thời gian tối đa từ lúc sự cố xảy ra đến khi dịch vụ hoạt động lại ở mức chấp nhận được.
RPORTODòng thời gian khi xảy ra sự cốDữ liệu có thể mấtThời gian gián đoạnBản backup cuốiSự cố xảy raHệ thống hoạt động lạiBackup càng thường xuyên thì RPO càng nhỏ; hệ thống khôi phục càng tự động thì RTO càng ngắn.
Hình 1. RPO đo lượng dữ liệu có thể mất, RTO đo thời gian ngừng hoạt động.

Hai chỉ số này độc lập với nhau: một hệ thống có thể cần RPO rất nhỏ (không được mất giao dịch) nhưng chấp nhận RTO dài hơn, hoặc ngược lại. Mục tiêu càng khắt khe thì chi phí hạ tầng, băng thông và vận hành càng cao, nên cần đặt mục tiêu theo giá trị nghiệp vụ chứ không đặt chung một mức cho mọi thứ.

Cách xác định mục tiêu

  1. Lập danh mục hệ thống và dữ liệu: máy chủ, cơ sở dữ liệu, ứng dụng, tệp chia sẻ, dịch vụ SaaS (như email, SharePoint) và các phụ thuộc giữa chúng.
  2. Đánh giá tác động nghiệp vụ (BIA): cùng các bộ phận trả lời hệ thống ngừng thì quy trình nào dừng, thiệt hại tăng theo thời gian ra sao.
  3. Phân tầng hệ thống: nhóm theo mức độ quan trọng và gán RPO, RTO tương ứng cho từng tầng.
  4. Chọn kiến trúc phù hợp từng tầng: backup định kỳ, backup liên tục (CDP), nhân bản sang site phụ, hoặc cụm HA.
Phân tầng hệ thống theo mức độ quan trọngTầng 1: hệ thống lõiRPO và RTO ngắn nhất, cần nhân bản hoặc HATầng 2: hệ thống quan trọngBackup thường xuyên, khôi phục có kế hoạchTầng 3: hệ thống hỗ trợBackup hằng ngày, khôi phục theo thứ tự ưu tiênTầng 4: dữ liệu lưu trữBackup định kỳ, chấp nhận khôi phục chậm hơn
Hình 2. Phân tầng giúp đầu tư đúng chỗ thay vì áp một mức bảo vệ cho mọi hệ thống.

Từ mục tiêu đến thiết kế backup

  • Quy tắc 3-2-1: tối thiểu ba bản sao dữ liệu, trên hai loại phương tiện khác nhau, một bản ở ngoài site.
  • Bản sao bất biến (immutable) hoặc offline: giúp bản backup không bị mã hóa hoặc xóa khi ransomware tấn công vào hệ thống.
  • Tách quyền quản trị backup khỏi quyền quản trị hệ thống sản xuất, bật MFA cho console quản lý backup.
  • SaaS không đồng nghĩa với có backup: dịch vụ đám mây đảm bảo tính sẵn sàng của nền tảng, còn việc khôi phục dữ liệu bị xóa nhầm hoặc bị mã hóa thường vẫn là trách nhiệm của khách hàng; cần đọc kỹ mô hình trách nhiệm chia sẻ.

Kiểm thử khôi phục: bước hay bị bỏ qua

Một bản backup chưa từng được khôi phục thử thì chưa thể coi là đáng tin cậy. Nên lên lịch diễn tập khôi phục định kỳ, đo thời gian thực tế và so với RTO đã đặt. Kết quả thường cho thấy những phụ thuộc bị bỏ sót như DNS, chứng thư, tài khoản dịch vụ hoặc thứ tự khởi động giữa các hệ thống. Ghi lại thành runbook để khi sự cố xảy ra, đội ngũ có quy trình rõ ràng thay vì xử lý ngẫu hứng.

Nếu doanh nghiệp cần đánh giá hiện trạng hoặc xây dựng lộ trình triển khai phù hợp, đội ngũ DHTD sẵn sàng trao đổi và tư vấn theo bối cảnh cụ thể của từng đơn vị.

Similar Posts