灾难恢复(DR):RTO/RPO 定义、冷备/热备/双活架构

灾难恢复(DR):RTO/RPO 定义、冷备/热备/双活架构

一、RTO 与 RPO 定义

  • RTO(Recovery Time Objective,恢复时间目标)
    指系统在灾难发生后,允许的最长不可用时间。
    • 举例:RTO = 2 小时 → 系统必须在 2 小时内恢复上线。
  • RPO(Recovery Point Objective,恢复点目标)
    指系统在灾难发生后,允许的数据丢失时间范围。

👉 RTO 决定恢复速度,RPO 决定数据完整性。两者共同决定容灾架构的设计与投入。


二、常见容灾架构模式

架构模式 定义 RTO RPO 成本 典型场景
冷备(Cold Standby) 仅做数据备份,无备用系统运行,灾难后需人工恢复环境 数小时~数天 数小时以上 历史归档、非核心业务
热备(Hot Standby) 备用系统实时同步,可随时接管 分钟级 秒级甚至 0 金融交易、电商支付
双活(Active-Active) 两地机房同时对外提供服务,实时同步,互为主备 秒级 接近 0 极高 核心金融、电信、跨区域业务

注:冷备强调"低成本+长恢复",热备强调"快速切换",双活则追求"零中断、零丢失",但投入最大 oneprocloud.com.cn


三、架构选择的思考维度

  1. 业务重要性
    • 核心交易系统 → 双活/热备
    • 内部办公系统 → 冷备/温备
  2. 预算投入
    • 冷备成本最低,但恢复慢
    • 双活需高昂带宽、存储与同步机制
  3. 合规与 SLA 要求
    • 金融、医疗、电信等行业往往要求 RTO < 1 小时,RPO ≈ 0
    • 政府或制造业 ERP 系统可接受 RTO 数小时,RPO 分钟级

四、总结

  • RTO/RPO 是容灾设计的核心指标,决定了恢复速度与数据完整性。
  • 冷备 → 热备 → 双活,体现了从低成本到高可用的演进路径。
  • 企业应结合 业务关键性、预算、合规要求,选择合适的 DR 策略,而非盲目追求"双活"。
相关推荐
人间凡尔赛1 小时前
AI-Native 云原生架构:2026 年从容器编排到智能体编排的范式革命
后端·云原生·架构
LONGZETECH1 小时前
新能源汽车充电设备装配与调试仿真教学软件 技术架构与核心实现解析
大数据·算法·3d·unity·架构·汽车
星创易联2 小时前
从T-Box到5G车载网关:高阶自动驾驶通信架构演进
5g·架构·自动驾驶
Ai拆代码的曹操2 小时前
opencode CLI 源码拆解:yargs + effectCmd 双层架构如何管理 20+ 子命令
架构·ai编程·opencode·源码拆解
熊猫钓鱼>_>2 小时前
ArkUI 动画实战:从理论到交互,构建流畅的鸿蒙动效体验
华为·架构·交互·harmonyos·arkts·arkui·native
咩咩啃树皮11 小时前
第40篇:Vue3组件化开发精讲——组件拆分、复用、父子通信、工程化架构
java·前端·架构
CS创新实验室13 小时前
量子计算机的操作系统:原理、实践与经典架构之对比
架构·操作系统·量子计算
人间凡尔赛13 小时前
WAIC 2026 落幕,AI Agent 开发已进入 Harness 架构时代
人工智能·架构
极客侃科技14 小时前
制造企业 MES/APS 选型:SAP PP/DS 集成、ERP-MES 边界划分与一体化架构要点
运维·架构·制造