Khôi phục thảm họa
Lựa chọn trang DR
Trang khôi phục phải ở đủ xa để không chia sẻ thảm họa chung, nhưng đủ gần cho chế độ nhân bản bạn cần. Hai ràng buộc đó — cộng với những colocation thực sự tồn tại trong thị trường ứng cử — quyết định danh sách ứng cử trước khi trao đổi với bất kỳ nhà cung cấp nào. Công cụ dưới đây kiểm chứng cả ba yếu tố dựa trên dữ liệu thực: thời gian vòng về được đo lường giữa 14 thị trường và catalog 1629 colocation.
Công cụ tìm kiếm cặp DR
Chọn thị trường chính của bạn. Các ứng cử viên được xếp hạng theo thời gian vòng về, với chế độ nhân bản mỗi khoảng cách hỗ trợ.
| Ứng cử viên DR | RTT | Chế độ nhân bản hỗ trợ | Colocation trong thị trường |
|---|
Số liệu RTT là các phép đo inter-region đám mây được công bố (Azure, cloudping.co) — các nguồn trên ma trận độ trễ. Các tuyến fiber giữa các colocation tuân theo các đường đi tương tự; xác nhận cặp chính xác với các nhà khai thác trước khi cam kết RPO cho nó.
Chế độ sao lưu được xác định bởi vật lý
Ánh sáng trong cáp quang truyền khoảng 100 km trong mỗi mili giây thời gian đi về. Con số duy nhất này quyết định kiến trúc: sao lưu đồng bộ yêu cầu thời gian đi về nằm trong ngân sách ghi của ứng dụng, điều này giới hạn khoảng cách gần 100 km — và mọi thứ ở xa hơn là không đồng bộ, bất kể lớp lưu trữ hứa hẹn gì.
| Chế độ | Ngân sách RTT | RPO | Ý nghĩa |
|---|---|---|---|
| Đồng bộ | ≤ ~10 ms | Không | Mỗi ghi dữ liệu được xác nhận tại cả hai vị trí trước khi ứng dụng tiếp tục. Độ trễ giao dịch bao gồm chuyến khứ hồi, vì vậy khoảng cách trở thành chi phí cho ứng dụng. |
| Gần như đồng bộ | ~10–25 ms | Giây | Ghi dữ liệu liên tục với xác nhận được nới lỏng. Lựa chọn thực tế cho các cặp trung tâm dữ liệu gần nhau như Frankfurt–Amsterdam hoặc Singapore–Kuala Lumpur. |
| Không đồng bộ | Bất kỳ | Phút | Vị trí DR bị trễ theo khoảng thời gian sao chép. Lựa chọn duy nhất cho khoảng cách xa — và là lựa chọn đúng cho hầu hết workload dù sao. |
Bốn mô hình DR, định giá trung thực
Chi phí được biểu diễn dưới dạng tỷ lệ chi phí vận hành của vị trí chính. Mô hình quyết định RTO; chế độ sao chép quyết định RPO; và sự kết hợp quyết định ngân sách. Hầu hết các tổ chức chạy các mô hình khác nhau cho các tầng workload khác nhau — active-active cho đường dẫn doanh thu, sao lưu-khôi phục cho mọi thứ có thể chờ một ngày.
| Mô hình | RPO | RTO | Chi phí so với vị trí chính | Cách hoạt động |
|---|---|---|---|---|
| Sao lưu và khôi phục | Giờ–ngày | Ngày | ~5% | Sao lưu được sao chép ngoài site, cơ sở hạ tầng chỉ xây dựng khi thảm họa xảy ra. Rẻ, chậm, và phần khôi phục là phần mà không ai từng kiểm tra. |
| Đèn canh | Phút–giờ | Giờ | ~10–20% | Dữ liệu cốt lõi được sao chép tới quy mô tối thiểu, mở rộng khi chuyển đổi dự phòng. Một vài racks tại site DR lưu trữ cơ sở dữ liệu; tài nguyên tính toán được cung cấp khi cần. |
| Sẵn sàng nóng | Giây–phút | Phút–giờ | ~30–50% | Một bản copy của production được thu nhỏ chạy liên tục. Chuyển đổi dự phòng là quá trình nâng cấp, không phải xây dựng lại. |
| Hoạt động-Hoạt động | ≈ Không | ≈ Không | 100%+ | Cả hai site đều phục vụ lưu lượng; mất một site là sự kiện giảm dung lượng, không phải mất dịch vụ. Yêu cầu ứng dụng phải được thiết kế cho nó từ đầu — cải tạo sau sẽ là viết lại. |
Sử dụng bộ ước tính chi phí colocation ở tỷ giá Index của thị trường mục tiêu để tính toán chi phí quy mô sẵn sàng.
Những gì thực sự gặp sự cố
Lập kế hoạch DR có xu hướng tưởng tượng về động đất. Nhật ký sự cố cho biết các mối đe dọa thực sự gần hơn với nguồn điện: nhiễu loạn cung cấp điện, cháy pin UPS, hỏng hóc hệ thống làm mát và lỗi phần cứng mạng. Một site DR trên cùng lưới điện, trong cùng vùng lũ, cùng carrier hotel không bảo vệ chống lại gần như bất cứ điều gì. Những mục gần đây:
- 2026-09-01Google Cloud: network degradation in us-central1-b takes down 15 products for up to 4h08mus-central1-b (Council Bluffs, Iowa)
- 2026-08-31Microsoft 365: authentication-configuration fault disrupts Exchange Online, Teams, SharePoint and Defender XDR for multiple daysGlobal (Microsoft 365 cloud services)
- 2026-08-27Proton: total cooling failure at Frankfurt datacenter takes down Mail, VPN, Drive and Pass for 2h18mFrankfurt, Germany (Proton-operated datacenter)
- 2026-08-20Google Cloud us-west1 (Oregon) region: multi-service degradation for about 3h40mus-west1 region (The Dalles, Oregon)
- 2026-08-17GitHub outage: retry storm and Central US datacenter network saturation cause 7h47m disruption to Issues, PRs, Actions and CopilotCentral US datacenter region, with failover traffic routed to Northern Virginia
Danh sách kiểm tra site DR
- Lưới điện khác so với lưới chính — xác minh trạm con thực tế, không phải tuyên bố tiếp thị
- Ngoài vùng lũ và vùng địa chấn chính
- Đường dẫn cáp quang đa dạng: hai site không được chia sẻ carrier hotel hay điểm đổ bộ cáp
- RTT được đo thực tế, không ước tính — và phải nằm trong ngân sách (độ trễ) của chế độ sao chép bạn chọn
- Trung tâm dữ liệu được chứng thực ở mức độ tuân thủ mong đợi — kiểm tra thư mục chứng thực
- Dung lượng có thể mở rộng theo hợp đồng: trang DR mà bạn không thể mở rộng trong thảm họa thực tế chỉ là trang trí
- Kỹ thuật viên từ xa với thời gian phản hồi theo hợp đồng — trong sự cố khu vực, bạn sẽ không cần bay đến hiện trường
- Failover được kiểm tra từ đầu đến cuối trước khi go-live, sau đó hàng năm — kế hoạch không phải là khả năng
Thường gặp
Khoảng cách giữa trung tâm dữ liệu chính và trang DR nên là bao nhiêu?
Đủ xa để không chia sẻ một thảm họa, đủ gần cho chế độ sao chép của bạn. Yêu cầu cơ bản là lưới điện riêng biệt, vùng ngập lụt riêng biệt và đường truyền mạng riêng biệt — trong thực tế từ 50 km trở lên. Sao chép đồng bộ giới hạn khoảng cách tối đa ở khoảng 100 km (khoảng 10 ms round-trip); sao chép không đồng bộ không có giới hạn khoảng cách. Nhiều cơ quan quản lý ở Châu Á-Thái Bình Dương yêu cầu DR ngoài quốc gia, buộc phải dùng async.
Sự khác biệt giữa RPO và RTO là gì?
RPO (recovery point objective) là lượng dữ liệu bạn có thể mất được, và nó được xác định bởi chế độ sao chép. RTO (recovery time objective) là thời gian ngừng hoạt động bạn có thể chịu được, và nó được xác định bởi mô hình DR — backup-restore phục hồi trong vài ngày, active-active trong vài giây. Chi phí tỷ lệ với cả hai: giảm bất kỳ cái nào thêm một bậc độ lớn sẽ khoảng gấp đôi ngân sách DR.
Sao chép đồng bộ có thể hoạt động giữa các quốc gia không?
Chỉ giữa các quốc gia lân cận. Singapore–Kuala Lumpur ở ~8 ms RTT hỗ trợ nó; Frankfurt–Amsterdam ở ~11 ms là ranh giới. Bất cứ cái nào vượt quá ~25 ms đều phải dùng không đồng bộ bất kể datasheet của nhà cung cấp storage nói gì — mọi write sẽ phải chịu độ trễ round-trip, và team ứng dụng sẽ cảm thấy nó trước team DR.
Điều gì thực sự làm sập trung tâm dữ liệu?
Nhật ký sự cố của chúng tôi được chi phối bởi các sự kiện điện (gián đoạn từ nhà cung cấp và lỗi UPS), hỏa hoạn (phòng pin lithium-ion xuất hiện lặp lại), lỗi làm mát và lỗi phần cứng mạng — không phải thảm họa thiên nhiên khu vực. Ý nghĩa thực tế: một trang DR ở cùng vùng trên cùng lưới điện bảo vệ được gần như không có sự cố thực tế xảy ra ở cơ sở, trong khi một trang ở nước lân cận bảo vệ được gần như tất cả.
Cloud công cộng có phải là trang DR hợp lệ cho colocation workloads không?
Đối với backup-restore và pilot-light patterns, thường là có — bạn chỉ trả tiền cho standby capacity khi nó chạy, chính xác là mô hình định giá cloud. Vấn đề là chi phí egress trên return trip và sự phức tạp vận hành: phục hồi colocation estate lên cloud infrastructure có nghĩa là phải duy trì hai deployment targets liên tục. Kiểm tra full restore, không phải replication.
Nên kiểm tra DR bao lâu một lần?
Một full failover ít nhất hàng năm, kiểm tra phục hồi component hàng quý, và sau mỗi thay đổi cơ sở hạ tầng quan trọng. Một kế hoạch DR chưa được kiểm tra là một tài liệu, không phải khả năng — và nhật ký sự cố cho thấy lỗi tập trung ở chính các cơ chế (power switchover, cooling restart) mà chỉ kiểm tra thực tế mới phát hiện được.
Tìm kiếm thị trường DR?
Cho chúng tôi biết trang chính, RPO cần thiết và yêu cầu tuân thủ. Chúng tôi sẽ cung cấp các cơ sở ở các thị trường DR khả thi, giá benchmark, và những câu hỏi đáng hỏi với mỗi nhà điều hành.