title: "Disaster Recovery: RTO/RPO và cách thiết kế cho các thảm họa thực tế"
series: "Software Architecture Masterclass"
part: "Phần 3 — Hệ thống Phân tán & Hạ tầng"
order: 29
audience: "Solutions Architect & Technical Lead"
reading_time: "14 phút"
tags: ["disaster-recovery", "rto", "rpo", "business-continuity", "high-availability", "backup-restore", "pilot-light", "warm-standby", "active-active", "infrastructure"]

Disaster Recovery: RTO/RPO và cách thiết kế cho các thảm họa thực tế

3 giờ sáng, khu vực AWS ap-southeast-1 gặp sự cố diện rộng — không phải một service, mà cả một Availability Zone mất điện do sự cố hạ tầng vật lý. Đội on-call được đánh thức, mở runbook "Disaster Recovery Plan" — một tài liệu Confluence 40 trang được viết cẩn thận hai năm trước, có sơ đồ, có checklist, có cả số điện thoại của "người phụ trách" đã nghỉ việc từ sáu tháng trước.

Bước 1 của runbook: "Restore từ snapshot RDS gần nhất tại region dự phòng." Đội thực thi. Snapshot cross-region tồn tại — điều đó đúng. Nhưng snapshot gần nhất là snapshot nào? Job tạo snapshot cross-region đã âm thầm fail trong ba tuần liền vì một thay đổi IAM policy không ai để ý, và không có alert nào được cấu hình cho việc đó. Snapshot "gần nhất" thực ra cách hiện tại 21 ngày. Dữ liệu ba tuần — bao gồm mọi giao dịch, mọi thay đổi cấu hình, mọi bản ghi khách hàng — không tồn tại ở bất kỳ đâu ngoài ổ đĩa đang chết dần trong AZ bị sập.

Đây không phải một câu chuyện hiếm. Đây là kết cục gần như tất yếu của một loại kế hoạch DR (Disaster Recovery) rất phổ biến: kế hoạch được viết ra để thỏa mãn một checklist audit hoặc một yêu cầu compliance, nhưng chưa từng được diễn tập với dữ liệu thật, tải thật, và con người thật đang bấm nút trong áp lực thật. Một bản kế hoạch DR chưa test không phải là bảo hiểm — nó là một tài liệu word có hình vẽ đẹp.

The Problem

Vấn đề kiến trúc ở đây không phải "làm sao backup dữ liệu" — mọi hệ thống tử tế đều có backup ở dạng nào đó. Vấn đề thật là: khi một phần hạ tầng (server, AZ, cả region) biến mất hoàn toàn, hệ thống của bạn khôi phục lại được bao nhiêu dữ liệu, và mất bao lâu để hoạt động trở lại — và con số đó có khớp với những gì doanh nghiệp có thể chịu đựng hay không?

Ba lỗ hổng kinh điển khiến câu trả lời luôn tệ hơn kỳ vọng:

Backup tồn tại nhưng không được verify. Job backup "chạy thành công" theo log không đồng nghĩa dữ liệu restore được. Snapshot có thể corrupt, incomplete, hoặc trỏ sai storage class. Không ai biết cho đến khi cần restore thật.
RTO/RPO chưa từng được định nghĩa bằng số, hoặc được định nghĩa bởi đội kỹ thuật một mình — không qua thống nhất với business. "Chúng ta cố gắng recover nhanh nhất có thể" không phải một mục tiêu kiến trúc, đó là một câu cửa miệng vô nghĩa không thể thiết kế hệ thống theo nó.
Kiến trúc DR không khớp với chi phí downtime thực tế của doanh nghiệp. Một hệ thống thanh toán mất 4 giờ có thể là thảm họa tài chính và pháp lý; một hệ thống nội bộ báo cáo mất 4 giờ chỉ là phiền toái. Áp cùng một chiến lược DR cho cả hai là lãng phí ở một phía và liều lĩnh ở phía kia.

Giải quyết vấn đề này đòi hỏi trước tiên phải nói cùng một ngôn ngữ với business bằng hai con số cụ thể, sau đó chọn một điểm trên phổ chiến lược DR khớp với hai con số đó — và quan trọng nhất, chứng minh được nó hoạt động bằng diễn tập thật.

The Theory

RTO và RPO — hai trục định nghĩa mọi chiến lược DR

RTO (Recovery Time Objective) — thời gian tối đa hệ thống được phép ngừng hoạt động trước khi được khôi phục. Trả lời câu hỏi: "Từ lúc thảm họa xảy ra đến lúc hệ thống chạy lại, chúng ta có bao lâu?" RTO = 4 giờ nghĩa là 4 giờ sau sự cố, hệ thống phải phục vụ được request trở lại.

RPO (Recovery Point Objective) — lượng dữ liệu tối đa được phép mất, đo bằng thời gian tính từ thời điểm backup/replicate gần nhất đến thời điểm xảy ra sự cố. RPO = 15 phút nghĩa là bạn chấp nhận mất tối đa 15 phút dữ liệu mới nhất (những giao dịch chưa kịp replicate).

Hai trục này độc lập nhau và đều có chi phí riêng. RTO thấp đòi hỏi hạ tầng đứng sẵn (standby capacity) để không mất thời gian dựng lại từ đầu. RPO thấp đòi hỏi replication liên tục, gần-real-time, không phải backup theo lịch (schedule).

Phổ chiến lược DR — bốn điểm dừng chính

Đây không phải bốn lựa chọn rời rạc mà là một dải liên tục đánh đổi chi phí lấy tốc độ phục hồi:

1. Backup & Restore. Dữ liệu được sao lưu định kỳ (hàng ngày/hàng giờ) vào một địa điểm khác (khác AZ, khác region). Khi thảm họa xảy ra, dựng lại toàn bộ hạ tầng từ đầu (provisioning), rồi restore dữ liệu vào đó. RTO tính bằng giờ đến ngày; RPO tính bằng giờ (khoảng cách giữa hai lần backup).

2. Pilot Light. Một phiên bản "thu nhỏ" của hệ thống lõi (thường chỉ database, được replicate liên tục) luôn chạy ở site dự phòng, nhưng compute (application server) không chạy — chỉ được provision khi cần. Ví như để đèn hoa tiêu (pilot light) của lò sưởi luôn cháy, khi cần chỉ bật lò lên chứ không phải châm lửa từ đầu. RTO rút ngắn còn phút-đến-giờ vì phần dữ liệu đã sẵn sàng, chỉ cần scale compute lên.

3. Warm Standby. Một phiên bản đầy đủ chức năng nhưng chạy ở quy mô thu nhỏ (scaled-down) luôn hoạt động song song ở site dự phòng — vừa đủ để phục vụ traffic tối thiểu, sẵn sàng scale lên full capacity khi failover. RTO tính bằng phút; RPO có thể xuống gần-zero nếu dùng continuous replication.

4. Multi-Site Active-Active. Cả hai (hoặc nhiều) site cùng phục vụ traffic sản xuất song song, đồng bộ liên tục. Khi một site sập, traffic được route toàn bộ sang site còn lại gần như tức thời. RTO gần-zero (giây đến vài phút do DNS/routing propagation), RPO gần-zero nếu dùng synchronous replication (dù đây bản thân lại là một đánh đổi CAP Theorem khác — xem Bài 21).

Nguyên lý cốt lõi: càng dịch chuyển về phía active-active, chi phí hạ tầng thường trực càng tăng tuyến tính hoặc hơn, còn RTO/RPO giảm phi tuyến ở gần điểm zero — chặng cuối cùng để đạt RTO/RPO gần-zero luôn đắt đỏ không cân xứng so với chặng trước đó.

The Trade-off

Đây là phần không được phép mơ hồ: chọn một điểm trên phổ DR nghĩa là chấp nhận một cái giá cụ thể, không phải chỉ nhận lợi ích.

Backup & Restore — được gì, mất gì:

Được: chi phí hạ tầng dự phòng gần như bằng 0 (chỉ trả tiền lưu trữ backup, rẻ). Đơn giản để vận hành, ít bề mặt lỗi khi bình thường.
Mất: RTO thực tế thường bị đánh giá thấp nghiêm trọng. "Restore mất 2 giờ" trên giấy thường bỏ qua thời gian provision hạ tầng mới, DNS propagation, warm-up cache, và thời gian con người ra quyết định failover — thực tế thường là 6-24 giờ cho hệ thống có quy mô dữ liệu lớn. RPO bị giới hạn bởi tần suất backup — không thể thấp hơn chu kỳ backup dù muốn.

Pilot Light — được gì, mất gì:

Được: RTO cải thiện đáng kể so với backup-restore (phút-giờ thay vì giờ-ngày) với chi phí thường trực thấp hơn nhiều so với warm standby — chỉ trả tiền cho phần dữ liệu replicate, không trả cho compute nhàn rỗi.
Mất: Vẫn cần thời gian scale compute lên khi failover thật — nếu auto-scaling hoặc infrastructure-as-code (Terraform, xem Bài 27) chưa được test kỹ, "vài phút" trên giấy dễ biến thành "vài giờ" khi gặp giới hạn quota, dependency thiếu, hoặc image lỗi thời không ai build lại.

Warm Standby — được gì, mất gì:

Được: RTO tính bằng phút một cách đáng tin cậy hơn vì hệ thống đã chạy sẵn ở dạng thu nhỏ, đã được validate là hoạt động (không phải "lý thuyết sẽ chạy").
Mất: Trả tiền cho hạ tầng chạy 24/7 dù không có sự cố — thường là 30-50% chi phí của hệ thống chính, vĩnh viễn, bất kể có bao giờ dùng đến hay không. Đây là chi phí bảo hiểm thuần túy, không tạo giá trị kinh doanh trực tiếp.

Multi-Site Active-Active — được gì, mất gì:

Được: RTO/RPO gần-zero, trải nghiệm người dùng gần như không nhận ra sự cố. Đây là mức duy nhất phù hợp cho hệ thống mà mỗi giây downtime là tổn thất tài chính trực tiếp đo được (sàn giao dịch, thanh toán, hệ thống y tế cấp cứu).
Mất: Chi phí hạ tầng gần gấp đôi (chạy đầy đủ ở nhiều site) cộng thêm độ phức tạp vận hành tăng vọt — phải giải quyết bài toán đồng bộ dữ liệu hai chiều (conflict resolution), split-brain khi network partition, và testing trở nên khó hơn nhiều bậc vì mọi thay đổi phải đúng ở tất cả các site đồng thời. Đây cũng là nơi CAP Theorem trở thành vấn đề thực chiến hàng ngày, không còn là lý thuyết.

Không có lựa chọn nào "tốt nhất" — chỉ có lựa chọn khớp hoặc không khớp với chi phí downtime thực tế mà doanh nghiệp đo được bằng tiền, uy tín, hoặc nghĩa vụ pháp lý.

The Architecture Diagram

quadrantChart
    title Phổ chiến lược Disaster Recovery: Chi phí vs RTO/RPO đạt được
    x-axis Chi phí hạ tầng thấp --> Chi phí hạ tầng cao
    y-axis RTO/RPO chậm (giờ-ngày) --> RTO/RPO nhanh (giây-phút)
    quadrant-1 Vùng Active-Active
    quadrant-2 Vùng Warm Standby
    quadrant-3 Vùng Backup-Restore
    quadrant-4 Vùng Pilot Light
    Backup & Restore: [0.15, 0.15]
    Pilot Light: [0.4, 0.45]
    Warm Standby: [0.65, 0.7]
    Multi-Site Active-Active: [0.9, 0.92]

sequenceDiagram
    participant User as Người dùng
    participant Primary as Site chính (Region A)
    participant Standby as Site dự phòng (Region B)
    participant Ops as Đội vận hành
    participant Monitor as Hệ thống giám sát

    Note over Primary,Standby: Vận hành bình thường - replication liên tục
    Primary->>Standby: Replicate dữ liệu (đồng bộ hoặc bất đồng bộ tùy RPO mục tiêu)
    Monitor->>Primary: Health check định kỳ

    rect rgb(255, 230, 230)
        Note over Primary: THẢM HỌA: Region A mất kết nối hoàn toàn
        Monitor--xPrimary: Health check thất bại liên tục
        Monitor->>Ops: Cảnh báo sự cố nghiêm trọng
    end

    Ops->>Ops: Xác nhận thảm họa thật (không phải false positive)
    Note over Ops: Đây là bước tốn thời gian nhất nếu chưa diễn tập

    alt Chiến lược Backup-Restore
        Ops->>Standby: Provision hạ tầng mới từ đầu
        Ops->>Standby: Restore dữ liệu từ backup gần nhất
        Note over Standby: RTO: giờ-ngày, RPO: theo chu kỳ backup
    else Chiến lược Warm/Pilot Standby
        Ops->>Standby: Scale compute lên full capacity
        Note over Standby: RTO: phút, RPO: gần chu kỳ replicate
    else Chiến lược Active-Active
        Monitor->>Standby: Tự động route toàn bộ traffic
        Note over Standby: RTO: giây, RPO: gần-zero
    end

    Standby->>User: Phục vụ traffic trở lại
    Ops->>Ops: Ghi nhận sự cố, chuẩn bị failback sau khi Region A hồi phục

Implementation Guardrails

RTO/RPO phải được viết thành con số cụ thể và ký duyệt bởi business stakeholder, không phải do đội kỹ thuật tự quyết. "RTO = 4 giờ, RPO = 15 phút" là một cam kết có chi phí đi kèm rõ ràng — người chấp nhận trả chi phí đó (hoặc chấp nhận rủi ro tương ứng nếu chọn mức thấp hơn) phải là người có thẩm quyền kinh doanh, không phải kiến trúc sư tự đặt ra rồi báo cáo sau.
Kế hoạch DR bắt buộc phải qua diễn tập thật (game day / DR drill) ít nhất mỗi năm một lần, với kịch bản gần giống thảm họa thật nhất có thể — bao gồm cả việc cố ý ngắt kết nối, không thông báo trước cho toàn đội, và đo thời gian thật từ lúc phát hiện đến lúc phục vụ lại được traffic. Một kế hoạch chỉ tồn tại trên giấy tương đương với không có kế hoạch.
Mọi backup/replication job phải có alerting riêng cho chính nó khi thất bại — không chỉ dựa vào log "success". Câu hỏi kiểm tra bắt buộc định kỳ: "Nếu job backup fail âm thầm ngay bây giờ, bao lâu nữa chúng ta phát hiện ra?" Nếu câu trả lời là "không biết" hoặc "khi cần restore", đó là một lỗ hổng nghiêm trọng cần vá ngay.
RPO không chỉ là backup — phải tính cả dữ liệu "đang bay" (in-flight): message queue chưa consume, transaction chưa commit, cache chưa flush. Một chiến lược DR chỉ tính dữ liệu đã persist vào database mà bỏ qua dữ liệu đang xử lý trong pipeline (RabbitMQ, event stream) sẽ mất nhiều hơn con số RPO cam kết.

Architect's Verdict

Một kế hoạch DR chưa từng được test không phải là kế hoạch DR — đó là cảm giác an toàn giả tạo, tệ hơn cả việc thừa nhận không có kế hoạch, vì nó khiến tổ chức ngừng lo lắng về đúng thứ đáng lo. RTO/RPO không phải chỉ số kỹ thuật để khoe trong tài liệu kiến trúc — chúng là cam kết tài chính và pháp lý với business, và phải được đàm phán bằng tiền, không phải bằng cảm tính "nhanh nhất có thể". Nếu ngân sách chưa cho phép active-active, hãy trung thực nói RTO/RPO thực tế là gì thay vì hứa một con số đẹp không ai kiểm chứng — một con số xấu nhưng đúng luôn tốt hơn một con số đẹp nhưng sai vào đúng lúc cần nó nhất.

🔗 Bài viết liên quan: High Availability (HA) — nền tảng thiết kế chịu lỗi mà DR xây trên đó; CAP Theorem — lý do multi-site active-active không bao giờ đạt được RPO=0 tuyệt đối mà không đánh đổi tính nhất quán.

Bài trước: Observability · Bài tiếp theo: Cloud-Native Architecture