2. 核心指标设计：备份成功率、备份时长、数据完整性校验、存储空间使用率

指标设计这事儿，说白了就是给系统装上一块仪表盘。你开车不能光凭感觉踩油门，得看转速、看油温、看时速。监控备份系统也一样——没有指标，你就是在盲开。

我个人习惯，核心指标只抓四个：成功率、时长、完整性、空间。多了记不住，少了不放心。下面一个一个拆开讲。

2.1 备份成功率：最直白的健康信号

成功率是所有指标里最基础的。它回答一个问题：“这次备份到底跑没跑通？”

公式很简单：

备份成功率 = (成功备份任务数 / 总备份任务数) × 100%

但这里有个坑——什么叫“成功”？ 我见过不少团队只看备份软件返回的 exit code，0 就算成功。嗯，这远远不够。

所以我的做法是，把成功率拆成三层：

日常监控只看 L1 和 L2，L3 可以放到周级别或月级别去做。你想想看，如果 L2 都过不了，L1 的成功率就是一张废纸。

2.2 备份时长：别让备份拖垮业务窗口

备份时长直接关系到你的备份窗口能不能关得上。我建议至少监控三个维度：

• 总耗时：从任务启动到结束的时间
• 传输速率：平均每秒写入多少数据
• 增量 vs 全量：两种模式的时长要分开看

为什么要分开？因为增量备份的时长如果突然飙升到全量级别，那说明你的增量机制可能失效了。我在项目中遇到过这种情况——某天增量备份跑了 4 个小时，查了半天发现是 rsync 的 --link-dest 参数配错了，每次都在做伪全量。

2.3 数据完整性校验：备份的“质检员”

备份做完了，数据对不对？这是最容易被忽视的一环。我见过太多人只盯着成功率，结果恢复时才发现文件损坏。

完整性校验，我一般用两种手段：

1. 校验和比对：备份完成后计算文件的 MD5 或 SHA256，跟源文件比对
2. 样本恢复测试：随机抽取 1%-5% 的备份文件，尝试恢复并验证内容

校验和比对适合全量备份，样本测试适合增量。为什么？因为增量备份的文件碎片化严重，全量校验太耗时间。

# 一个简单的校验脚本片段
#!/bin/bash
SOURCE_FILE="/data/db/mysql.ibd"
BACKUP_FILE="/backup/db/mysql.ibd"

SOURCE_HASH=$(sha256sum "$SOURCE_FILE" | awk '{print $1}')
BACKUP_HASH=$(sha256sum "$BACKUP_FILE" | awk '{print $1}')

if [ "$SOURCE_HASH" == "$BACKUP_HASH" ]; then
    echo "INTEGRITY_CHECK: PASS"
else
    echo "INTEGRITY_CHECK: FAIL"
    exit 1
fi

这个脚本看着简单，但实际生产环境里要注意两点：一是源文件在备份过程中可能还在写入，二是大文件的哈希计算很吃 CPU。我建议在备份完成后、源文件静默期再做校验。

2.4 存储空间使用率：别让磁盘成为定时炸弹

存储空间这个指标，看似简单，其实最容易出幺蛾子。你光看总使用率是不够的，得看趋势。

我习惯监控三个值：

• 当前使用率：已用空间 / 总空间 × 100%
• 日增长量：过去 24 小时新增了多少数据
• 剩余可用天数：按当前增长速率，还能撑几天

举个例子：

你看，当前使用率才 72%，离 85% 还有距离，但剩余可用天数只剩 14 天了。如果不加磁盘，两周后就会爆。这就是趋势指标的价值。

2.5 四个指标的关系：一张图说清楚

这四个指标不是孤立的。成功率告诉你“做没做完”，时长告诉你“做得快不快”，完整性告诉你“做得好不好”，空间告诉你“还能做多久”。它们共同构成一个闭环。

下面这张图展示了它们之间的关系：

从图里你能看到，四个指标从不同角度描述备份系统的状态。任何一个指标出问题，都意味着系统存在风险。我个人习惯在监控大屏上把这四个指标放在同一行，一眼扫过去就能判断系统是否健康。

2.6 指标落地的几个建议

最后，聊几个我在实际项目中踩过的坑：

• 指标粒度要对齐业务：数据库备份和文件备份的时长阈值肯定不一样，别用同一套规则
• 历史数据要保留：至少保留 90 天的指标数据，方便做趋势分析和容量规划
• 告警别太敏感：单次失败不一定需要马上告警，连续 3 次失败再触发，能减少很多噪音