36.3 冷备 / 温备 / 热备
一句话
冷、温、热的区别不在“数据同步得多快”，而在恢复时还有多少活要人干：冷备要人找机器、装环境、导数据，温备环境和数据都就位只等启动，热备连启动都不用、自动切；RTO 的杠杆是预置与自动化，不是更快的硬盘。
三种形态：差在“人”和“自动化”
| 形态 | 数据是否就位 | 环境是否就位 | 切换谁来做 | 典型 RTO | 典型 RPO |
|---|---|---|---|---|---|
| 冷备 | 有备份，可能需要先买/借机器 | 没有，需现装 | 人工 | 小时级 | 上次备份（小时~天） |
| 温备 | 定期同步（日志/快照/复制） | 已预装、可随时启动 | 人工或半自动 | 分钟~1 小时 | 分钟~小时 |
| 热备 | 实时同步 | 常驻运行 | 自动检测 + 自动切流 | 秒级 | 秒级或 0 |
🔑 记忆锚点：冷备是“东西在仓库”，温备是“东西在车上、人待命”，热备是“两套都在跑”。三者的成本差是数量级的，但 RTO 的差不是靠“买更快的设备”缩小的。
把 RTO 拆开看：数据只占一小部分
一次真实恢复要经过五步，任何一步都能把 RTO 拖长：
发现故障 → 决策/拉人 → 准备环境 → 恢复数据 → 校验/切流
| 形态 | 发现 | 决策 | 准备环境 | 恢复数据 | 校验 | RTO 合计 |
|---|---|---|---|---|---|---|
| 冷备 | 0.25h | 0.50h | 6.00h | 1.46h | 0.50h | 8.71h |
| 温备 | 0.25h | 0.25h | 0.50h | 0.15h | 0.25h | 1.40h |
| 热备 | 0.02h | 0 | 0.02h | 0.01h | 0.05h | 0.10h |
同样的数据（1 TiB），冷备 8.71 小时里真正搬数据只有 1.46 小时（17%），剩下 7.25 小时是“找机器、装系统、装依赖、配网络、等人拍板”。所以：
- 把存储换快 1 倍，冷备 RTO 只从 8.71h 降到 8.0h（省 8%）；
- 预置一套环境（把“准备”从 6h 压到 0.5h），RTO 直接掉到 2.2h；
- 再把“决策”变成值班表 + 预案（0.5h → 0.25h），才进入温备区间。
⚠️ RTO 不是技术指标，是组织指标。没有值班表、没有恢复手册、没有演练的团队，无论买多贵的存储，RTO 都按“第二天上班再处理”算。
一年停多久：把 RTO 换算成可用性
按每年 4 次故障估算（不含计划内维护）：
| 形态 | RTO | 年停机 | 年可用性 | 相对成本 |
|---|---|---|---|---|
| 冷备 | 8.71h | 34.8h | 99.60% | 1.0× |
| 温备 | 1.40h | 5.6h | 99.94% | 1.4× |
| 热备 | 0.10h | 0.4h | 99.995% | 2.2× |
读法：冷备到温备，多花 40% 成本，年停机从 34.8h 降到 5.6h（6 倍）；温备到热备，再多花 57% 成本，年停机从 5.6h 降到 0.4h（14 倍）。
这就是“9 的边际成本”：99.6% → 99.94% → 99.995%，每一段都要多买一套东西，而且越往后越依赖自动化而不是硬件——热备的 0.1h 里，人不参与决策，全靠健康检查与自动切流（见 35.4 故障检测）。
热备的三个前提，缺一个就退化成温备
买了一主一备、数据实时同步，不等于热备：
| 前提 | 缺了会怎样 | 实际 RTO |
|---|---|---|
| 自动检测 | 靠人发现“服务挂了” | +15~30 分钟 |
| 自动决策 + 切流 | 检测到但不敢自动切，等人确认 | +10~30 分钟 |
| 备端容量足够 | 切过去直接被打挂，再切回来 | 故障放大 |
| 数据同步可验证 | 切过去发现落后 2 小时 / 数据损坏 | 不可用 |
| 回切方案 | 主机恢复后两边都写，脑裂 | 数据不一致 |
🔑 热备的本质是“自动切换的合法性”，不是“多一台机器”。合法性来自三样东西：租约/仲裁（防脑裂）、fencing（防旧主继续写）、可验证的同步延迟。这些比机器贵得多，也难得多。
成本结构：钱花在哪
| 项 | 冷备 | 温备 | 热备 |
|---|---|---|---|
| 计算资源 | 0（故障时才开） | 小规格常驻（能跑起来） | 与生产同规格常驻 |
| 存储 | 备份存储（可归档层） | 备份 + 同步副本 | 双份在线存储 |
| 网络 | 备份传输 | 持续复制（跨区流量） | 同步复制（低延迟专线） |
| 人 | 故障时临时拉人 | 值班 + 预案 | 7×24 值班 + 自动化平台 |
| 演练 | 半年一次 | 每季度 | 每月/混沌工程 |
| 相对成本 | 1.0× | 1.4× | 2.2× |
一个常被忽略的数字：每季度演练一次、每次 4 人 × 4 小时，一年 64 人时，只占 4 人团队 0.8% 的工时。这点投入换来的是“RTO 从纸面数字变成可复现数字”。不做演练的冷备，真实 RTO 通常是估算值的 2–3 倍（经验值，取决于团队熟悉度）。
可运行的 RTO 账本
package main
import "fmt"
// 一次故障恢复要经过的步骤（单位：小时）。数字是「未预先演练过的团队」的典型值。
type tier struct {
name string
detect float64 // 发现故障
decide float64 // 决策/拉人
prep float64 // 找机器、装环境、开机
restor float64 // 恢复数据
verify float64 // 校验与切流
rpo float64 // 小时
cost float64 // 相对成本（以冷备为 1）
}
func main() {
const incidentsPerYear = 4.0
hoursPerYear := 365 * 24.0
tiers := []tier{
{"冷备", 0.25, 0.50, 6.00, 1.46, 0.50, 24, 1.0},
{"温备", 0.25, 0.25, 0.50, 0.15, 0.25, 0.25, 1.4},
{"热备", 0.02, 0.00, 0.02, 0.01, 0.05, 0.001, 2.2},
}
fmt.Printf("%-6s %8s %8s %8s %8s %8s %8s %8s %8s %7s\n",
"形态", "发现h", "决策h", "准备h", "恢复h", "校验h", "RTO", "年停机", "可用性", "成本")
for _, t := range tiers {
rto := t.detect + t.decide + t.prep + t.restor + t.verify
down := rto * incidentsPerYear
avail := 1 - down/hoursPerYear
fmt.Printf("%-6s %8.2f %8.2f %8.2f %8.2f %8.2f %7.2fh %7.1fh %8.4f%% %6.1fx\n",
t.name, t.detect, t.decide, t.prep, t.restor, t.verify, rto, down, avail*100, t.cost)
}
// 关键：把「准备」压掉，冷备就变成温备；把「决策」压掉，温备就接近热备
cold := tiers[0]
rto := cold.detect + cold.decide + cold.prep + cold.restor + cold.verify
fmt.Printf("\n冷备的 %.2fh 里，真正搬数据只有 %.2fh（%.0f%%），其余 %.2fh 是找机器/装环境/等人\n",
rto, cold.restor, cold.restor/rto*100, rto-cold.restor)
fmt.Printf("RTO 从 %.2fh 压到 1h 的杠杆：预置环境（省 %.1fh）+ 值班表（省 %.1fh），不是换更快的存储\n",
rto, cold.prep, cold.decide)
// 演练成本：每季度一次，每次 4 人 × 4h
drillHours, drillPeople := 4.0, 4.0
fmt.Printf("每季度演练一次：每年 %.0f 人时，只占 4 人团队的 %.1f%% 工时\n",
drillHours*drillPeople*4, drillHours*drillPeople*4/(4*2000)*100)
}
输出：
形态 发现h 决策h 准备h 恢复h 校验h RTO 年停机 可用性 成本
冷备 0.25 0.50 6.00 1.46 0.50 8.71h 34.8h 99.6023% 1.0x
温备 0.25 0.25 0.50 0.15 0.25 1.40h 5.6h 99.9361% 1.4x
热备 0.02 0.00 0.02 0.01 0.05 0.10h 0.4h 99.9954% 2.2x
冷备的 8.71h 里，真正搬数据只有 1.46h（17%），其余 7.25h 是找机器/装环境/等人
RTO 从 8.71h 压到 1h 的杠杆：预置环境（省 6.0h）+ 值班表（省 0.5h），不是换更快的存储
每季度演练一次：每年 64 人时，只占 4 人团队的 0.8% 工时
选型：先看 RTO/RPO，再看钱
| 业务 | 可接受停机 | 选 | 理由 |
|---|---|---|---|
| 内部报表、离线任务 | 1 天 | 冷备 | 重跑即可，人工成本低于常驻资源 |
| 一般业务系统 | 1–4 小时 | 温备 | 环境预置，值班表覆盖 |
| 交易、支付、登录 | < 5 分钟 | 热备 | 自动切换 + 容量冗余 |
| 只读 CDN / 静态站 | 秒级 | 多活/边缘 | 无状态，切流即可 |
| 合规留存数据 | 不要求在线 | 冷备 + 归档 | 见 39.3 存储分级 |
反模式
| 反模式 | 后果 |
|---|---|
| 只买冷备，却承诺 99.99% | 承诺无法兑现，故障时按天算停机 |
| 有热备但没有自动切流 | 实际 RTO = 人工响应时间，钱白花 |
| 热备切过去容量不够 | 备端被打挂，故障从单点变成双点 |
| 从不演练 | 真实 RTO 是估算值的 2–3 倍，恢复手册过期 |
| 备份与灾备混为一谈 | 数据能恢复，但服务几小时起不来 |
| 只做数据同步，不做回切方案 | 主机恢复后双写，脑裂 |
| 冷备机器“随时能买” | 云上配额不足/库存紧张时买不到 |
| 演练只演“切过去”，不演“切回来” | 回切才是最容易出事的一步 |
自检
Q1 冷备 RTO 8.71 小时，其中搬数据只占 1.46 小时。如果把存储吞吐提高一倍，RTO 能降到多少？真正该做什么？
▸ 答案：只能省 0.73 小时（1.46 → 0.73），RTO 约 7.98 小时，降幅 8%。因为瓶颈在“准备环境 6 小时”——找机器、装系统、装依赖、配网络、等审批。正确动作是预置：备一套已装好的环境（哪怕关机），把 6 小时压到 0.5 小时，RTO 立刻到 2.2 小时；再配值班表和恢复脚本，进入 1 小时以内。存储吞吐只在数据量极大（几十 TB）时才成为瓶颈。
Q2 你们买了一主一备、数据实时同步，对外宣称 RTO < 1 分钟。真故障时用了 40 分钟才恢复。最可能缺什么？
▸ 答案：缺自动检测与自动切流（以及切流后的容量验证）。数据同步只保证“数据在”，不保证“服务能接管”：没有健康检查 → 靠人发现；没有自动决策 → 等人确认；没有 DNS/网关切换 → 手工改配置；备端容量不足 → 切过去被打挂。40 分钟 ≈ 发现 15 分钟 + 确认 10 分钟 + 手工切流 15 分钟，正好是“有热备数据、没有热备自动化”的典型值。
Q3 RPO = 0 一定比 RPO = 5 分钟贵很多吗？什么情况下两者成本接近？
▸ 答案：不一定。RPO=0 靠同步复制实现，成本主要是“多一份在线副本 + 写延迟”，在同城双活（RTT 1–2ms）里代价很小；只有跨地域同步才会把写延迟推到几十毫秒并需要专线。若业务本来就有同城双活（为了单机房故障），把复制改成同步只增加很小的成本，RPO 就从分钟级变成 0。反过来，如果只有单机房 + 异地异步，为了 RPO=0 上跨地域同步，才是昂贵的那一步（见 36.4 两地三中心与多活）。
Q4 备份和灾备各解决什么问题？只做备份、不做灾备，能不能达到 99.99%？
▸ 答案：备份解决数据不丢（RPO），灾备解决服务不停（RTO）。只做备份，数据能恢复但恢复要几小时（冷备 8.71h），一年 4 次故障就是 34.8h 停机，可用性 99.60%——离 99.99%（年停机 52.6 分钟）差两个数量级。99.99% 需要“分钟级接管”，也就是温备起步、热备达标，并且要靠自动化切流而不是人工。
Q5 为什么“每季度演练一次”这种看起来很低频的动作，反而比升级硬件更能降低真实 RTO？
▸ 答案：因为真实 RTO 的瓶颈是人：不演练的团队不知道备份放在哪、恢复脚本怎么跑、依赖哪些密钥、切换后要改哪些 DNS；这些知识在故障当天现学，时间会翻 2–3 倍。演练把“隐性步骤”变成“清单”，把“等人”变成“值班表”，把 6 小时的准备压到 1 小时以内。硬件只能优化那 17% 的数据搬运时间，演练优化的是剩下的 83%。
跨篇相关：RTO/RPO 的定义与 9 的换算见 36.1 RTO / RPO；备份本身怎么选策略见 36.2 备份策略；跨机房的热备属于多活拓扑，见 36.4 两地三中心与多活；自动切换的检测依据见 35.4 故障检测。