企业讨论灾备方案时，经常先问采用什么备份软件、需要多少存储、是否建设异地机房。但在选择技术之前，更应该先回答两个问题：发生故障后，最多允许丢失多少数据？业务最长可以中断多久？这两个问题分别对应RPO和RTO。
先说结论
RPO决定企业能够承受的数据丢失量，RTO决定企业能够承受的业务中断时间。
RPO和RTO不是灾备产品的固定参数，而是根据业务影响分析确定的管理目标，必须分别设计、分别验证。
如果没有明确这两个指标，灾备建设很容易变成设备和软件的简单采购，最终可能出现“备份一直在做，但真正发生故障时仍然恢复不及时”的问题。
RPO是Recovery Point Objective的缩写，通常译为“恢复点目标”。它表示发生故障后，企业最多能够接受丢失多长时间范围内的数据，关注恢复数据能够接近故障前的哪个时间点。
例如，某系统每天凌晨2点进行一次全量备份。如果第二天下午2点发生故障，而中间没有增量备份或日志保护，那么最多可能丢失12小时的数据，其实际RPO就可能达到12小时。
需要注意，“RPO为零”通常意味着很高的技术与管理要求。即使采用同步复制，也要考虑误删除、勒索加密和应用错误是否会同步到灾备端。
RTO是Recovery Time Objective的缩写，通常译为“恢复时间目标”。它表示业务从发生中断开始，到恢复至约定可用状态所允许的最长时间。
RTO不只包括数据恢复，还可能包含故障发现、灾难判断、备用环境启动、数据挂载、数据库与中间件启动、应用配置调整、网络切换及业务验证。
例如，数据库在10分钟内完成挂载，并不代表RTO就是10分钟。如果应用启动和业务确认又用了50分钟，实际业务恢复时间仍接近1小时。
RPO和RTO分别解决“恢复到哪里”和“多久恢复”的问题。假设某医院核心业务系统在10:00发生故障，RPO为15分钟，意味着恢复后的数据原则上不应早于9:45；RTO为1小时，则意味着业务应在11:00前恢复到约定状态。
两者互相关联，但不能相互替代。高频备份可以缩小RPO，却不一定缩短RTO；准备充足的备用资源可以缩短RTO，却无法自动减少尚未保护的数据量。
企业应先开展业务影响分析：系统中断会造成什么影响，数据丢失能否补录，系统是否存在强依赖，以及缩短指标所增加的投入是否与业务损失匹配。
指标应具体到系统，必要时还应具体到数据库、应用和关键业务功能。同一大型系统内部，不同数据对象的保护要求也可能不同。
对于AIDRX一类面向灾备管理和恢复场景的平台，应用价值最终也应回到RPO和RTO上衡量：是否能够清晰掌握保护状态，是否能够减少恢复环节中的等待与人工操作，是否能够留下可验证的恢复结果。
不一定。同步复制可以减少基础设施故障造成的数据损失，但误删除、应用错误和勒索加密也可能同步传播，仍需结合独立备份、历史版本和隔离保护。
只能说明理论上接近一小时。若任务失败、执行延迟或副本不可用，实际RPO会更长。
通常从业务中断或灾难发生时开始，直到约定的业务功能恢复可用。企业应在灾备预案中统一计时口径。
原则上都应设置，但指标可以不同。核心系统需要严格量化，一般系统可以采用较宽松的目标。
