Bài 10. RPO, RTO và cách xác định cho từng hệ thống

1. Vì sao cần RPO và RTO?

Rất nhiều hệ thống:

• Có backup

• Có retention

• Có off-site

Nhưng khi xảy ra sự cố, vẫn tranh cãi và lúng túng:

• Mất bao nhiêu dữ liệu là chấp nhận được?

• Hệ thống phải chạy lại trong bao lâu?

📌 RPO và RTO tồn tại để chấm dứt tranh cãi này.

2. RPO là gì?

RPO (Recovery Point Objective) là:

Mức độ mất dữ liệu tối đa có thể chấp nhận được, tính bằng thời gian.

Nói cách khác:

• Sau sự cố, dữ liệu được phép quay lại mốc nào trong quá khứ?

Ví dụ:

• RPO = 1 giờ → chấp nhận mất dữ liệu 1 giờ gần nhất

• RPO = 24 giờ → chấp nhận mất dữ liệu của ngày hôm nay

📌 RPO không nói về thời gian khôi phục, chỉ nói về độ mới của dữ liệu.

3. RTO là gì?

RTO (Recovery Time Objective) là:

Thời gian tối đa cho phép để hệ thống hoạt động trở lại sau sự cố.

Ví dụ:

• RTO = 30 phút → hệ thống phải chạy lại trong 30 phút

• RTO = 8 giờ → downtime tối đa 8 giờ

📌 RTO không nói về dữ liệu, mà nói về dịch vụ.

4. Mối quan hệ giữa RPO và RTO

RPO và RTO liên quan nhưng không giống nhau:

Một hệ thống có thể:

• RPO thấp (mất ít dữ liệu)

• Nhưng RTO cao (chạy lại chậm)

Hoặc ngược lại.

5. RPO và RTO quyết định chiến lược backup

5.1. RPO thấp → backup thường xuyên

• Near-real-time replication

• Snapshot dày

• Incremental backup

5.2. RTO thấp → cần kiến trúc dự phòng

• Failover

• Standby server

• Reverse proxy chuyển hướng nhanh

📌 Backup thuần túy không đáp ứng RTO rất thấp.

6. Xác định RPO cho từng hệ thống

6.1. Câu hỏi cần đặt ra

• Dữ liệu nào mất là không chấp nhận được?

• Dữ liệu nào có thể nhập lại?

• Lỗi phát hiện sau bao lâu?

6.2. Ví dụ phân loại RPO

7. Xác định RTO cho từng hệ thống

7.1. Câu hỏi cần đặt ra

• Dừng hệ thống bao lâu thì ảnh hưởng nghiêm trọng?

• Có phương án làm việc tạm không?

• Có hệ thống thay thế không?

7.2. Ví dụ phân loại RTO

8. Kết hợp RPO / RTO với 3-2-1 và 7-4-12-5

• RPO quyết định:

  • Tần suất backup

  • Loại backup (full / incremental)

• RTO quyết định:

  • Có cần standby không

  • Có cần failover không

📌 Retention không thay thế RPO/RTO.

9. Ví dụ xác định RPO/RTO cho hệ thống thực tế

Hệ thống bệnh viện (mô tả giản lược)

10. Sai lầm thường gặp khi xác định RPO/RTO

• Chọn RPO = 0 nhưng không có kiến trúc phù hợp

• Chọn RTO rất thấp nhưng chỉ có backup

• Không thống nhất giữa CNTT và nghiệp vụ

• Không văn bản hóa cam kết

11. Đưa RPO/RTO vào SOP và cam kết vận hành

RPO và RTO cần:

• Được phê duyệt

• Được văn bản hóa

• Được kiểm tra định kỳ

📌 Không có RPO/RTO rõ ràng = không có tiêu chí thành công cho backup.

Backup chỉ là phương tiện.
RPO và RTO mới là mục tiêu.

Một chiến lược backup tốt không phải là:

• Backup nhiều nhất

• Backup thường xuyên nhất

Mà là:

• Đáp ứng đúng RPO

• Đáp ứng đúng RTO

• Với chi phí và nguồn lực hợp lý