数仓容灾怎么设计？RPO 和 RTO 如何落地？
面试怎么回答
数仓容灾先按业务确定 RPO 和 RTO，再选择备份恢复、温备或热备。备份范围要包含数据、元数据、作业配置和实时恢复位置，复制不能替代防误删的历史备份。演练从服务中断计时，到关键报表可查询且对账通过才结束，同时验证日志重放、写入隔离和回切步骤，用实测结果判断目标是否达到。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
面试官追问：“有异地备份我知道。假设现在主库不可用，多久能让业务重新看到可信的日报？”回答这句话，需要知道数据能恢复到哪里，也需要知道整条服务链多久恢复。
先按业务定义可接受的数据损失与恢复时长，再匹配备份、复制和重放方案；恢复演练必须覆盖数据、元数据、调度和最终报表验收。
RPO 和 RTO 对应不同的业务损失
RPO 关注故障后最多可以接受丢失多长时间范围的数据，RTO 关注服务中断后最多多久恢复。一个方案可能数据损失很小，但恢复过程很慢，也可能恢复很快却只到昨天的备份。
数仓内部也不必只有一个统一目标。在线指标服务、财务日结和历史探索可以按影响分级，再给出数据恢复点、最低可服务范围和恢复时限。目标应由业务后果推动，而不是照搬某个产品的宣传数字。
恢复材料不止是数据文件
需要保留表结构、分区与目录元数据、作业代码、调度依赖、参数配置、权限以及可安全恢复的凭据引用。实时链路还要考虑状态快照、消费位置和外部写入状态之间的一致性。
对象存储里文件齐全，却找不到当前表版本或恢复后的入口，业务依然不能使用。备份还要与生产错误隔离：持续复制会把误删或错误更新同步过去，多个在线副本不能替代可选择历史恢复点的备份。
按恢复目标选择资源投入
冷备份恢复通常需要重新准备资源、加载数据和启动任务；温备保留部分基础能力；热备则持续维护可切换服务。投入越高，也越需要处理一致性、故障判定和切换后的写入归属。
如果原始事件或日志保留足够久，可以通过重放补齐备份后的数据，但重放速度和下游承载能力会影响恢复时间。不能只计算备份复制耗时，还要把资源拉起、元数据恢复、补数与校验放入同一时间预算。
一个典型场景：库恢复了，报表仍然不可用
比如恢复演练中，数据库很快启动，团队先宣布完成；随后发现调度依赖指向旧环境，维表没有追到事实水位，报表权限也缺失。初步判断是几个零散配置问题，实际是验收范围只覆盖数据库进程。
改进后，从事故发生开始计时，依次记录基础服务、数据恢复、链路追平和关键查询验收时间。对于核心指标，要对比恢复前已发布结果与恢复后同口径结果，确认可查询不只是技术接口返回成功。
切回主环境也需要明确协议
故障切换后要防止旧主恢复时重新接受冲突写入，采用明确的写入归属与隔离机制。回切前比较两侧水位、补齐差异，再决定切换窗口，不能只把域名改回去。
定期演练源日志过期、备份不可读、单区域失效和配置缺失等已纳入方案的情形，记录实际恢复点与耗时。只有可重复演练的结果才能证明方案接近目标，文档上填写的 RPO、RTO 只是尚待验证的承诺。