【高级技巧】RTO与RPO：恢复目标的量化设定

底层原理

"备份很完善"这句话没有量化就是空话。RPO（Recovery Point Objective，恢复点目标）回答"最多能容忍丢多久的数据"：RPO 为 5 分钟意味着任意时刻宕机，最多丢 5 分钟内的写入，这直接决定了备份的间隔与方式；RTO（Recovery Time Objective，恢复时间目标）回答"最多能容忍多久不可用"：RTO 30 分钟意味着备份必须能在 30 分钟内重放完成，决定了备份的可恢复性设计。两个指标是容灾体系的设计输入：先定目标，再反推备份策略、演练频率与自动化程度。F:\底层文件 的数据落盘路径确认：写入频率与落盘节奏决定了理论 RPO 的下限。

高级封装

目标表与备份策略反推：目标量化、策略校验、达标自检。示例代码如下：

local TARGETS = {
    rpoMin = 5,
    rtoMin = 30,
}
local BACKUP = { intervalMin = 5, replayMin = 12 }
local function checkBackupMeets()
    local okRpo = BACKUP.intervalMin <= TARGETS.rpoMin
    local okRto = BACKUP.replayMin <= TARGETS.rtoMin
    if not okRpo then
        print("备份间隔 " .. BACKUP.intervalMin ..
            " 分钟超出 RPO 目标 " .. TARGETS.rpoMin .. " 分钟")
    end
    if not okRto then
        print("重放时长 " .. BACKUP.replayMin ..
            " 分钟超出 RTO 目标 " .. TARGETS.rtoMin .. " 分钟")
    end
    return okRpo and okRto
end
local function actualRpo()
    return BACKUP.intervalMin
end

月度自检接线示例代码如下：

if not checkBackupMeets() then
    sendmsg(nil, 1, "[容灾] 备份策略未达标，请调整。")
end

性能对比

目标设定前后对比：宣称"丢数据不超过 5 分钟"但备份每天一次——实际 RPO 是 24 小时，一次回档丢一天流水，赔付与信任损失巨大；目标量化后备份间隔改 5 分钟（增量日志），实际 RPO 降到 5 分钟，一次故障的真实数据损失从 24 小时的 38000 笔交易缩到 5 分钟的 130 笔。代价：高频增量备份的写入开销使主库吞吐下降约 4%，用 4% 的性能买 99.7% 的数据安全。

适用边界

两个不适用场景：一是纯内存数据（重启即重算的排行榜缓存）没有 RPO 概念，丢了重建即可；二是初创单机服没有容灾预算时，量化目标依然是必要的——哪怕 RPO 定为 24 小时、RTO 定为 4 小时，写下来与不写下来的区别是"出了事知道会丢多少"和"出了事才发现丢了多少"。