用云备份 CBR 给云服务器数据做定期备份的实践笔记

一、为什么快照之外还要做备份

很多同学把云硬盘快照当成备份，其实两者不是一回事。快照是某个时间点的数据副本，通常和原盘放在同一个可用区，适合升级、打补丁前的临时回滚点；而云备份 CBR（Cloud Backup and Recovery）是独立存储的备份数据，支持跨区域复制，面对误删文件、勒索病毒加密、整机故障这类场景时，只有独立备份才是最后一道防线。我的习惯是：快照管「回滚」，备份管「保命」。

二、CBR 的三个核心概念

1. 备份存储库：存放备份数据的空间，按容量购买，分云服务器备份、云硬盘备份、文件系统备份等类型，创建时要预估数据量并留出增长余量。
2. 备份策略：定义什么时候备、保留多久。可以按天或按周触发，保留规则支持按份数、按天数或永久保留。
3. 资源绑定：把 ECS 或 EVS 资源关联到存储库并绑定策略，之后就会按策略自动执行，不再依赖人工想起来点一下。

三、我的实操配置

1. 创建云服务器备份存储库，容量按系统盘加数据盘总量的 1.5 倍预留。
2. 建备份策略：每天凌晨 2 点（业务低峰）自动备份，保留最近 7 份日备份；另外每周日多保留一份、留 30 天，兼顾短期回滚和月度追溯。
3. 绑定资源后先手动执行一次全量备份，确认任务成功、备份点状态正常。
4. 做一次恢复演练：把备份恢复到一块新云硬盘上挂载检查文件完整性。备份没验证过恢复，等于没有备份——这一步千万别省。
5. 给存储库设置容量告警，使用率超过 80% 时提前扩容，避免容量满了导致新备份静默失败。

四、成本优化的几个小经验

CBR 是增量备份，只有第一次是全量，后续只传变化的数据块，所以日备份的实际增量成本比想象中低。真正烧钱的是保留规则贪多：永久保留看着安心，容量账单会一直涨。建议按数据重要程度分层——热数据短期高频备份，冷数据降低频率或转归档。另外定期清理测试环境产生的无用备份点，也是个体力活但很省钱。

五、常见坑

1. 备份时间窗和业务高峰重叠，全量备份的 IO 抖动会拖慢线上服务，时间点务必选低峰期。
2. 存储库容量不足时备份任务会失败，而失败很容易被忽略，一定要配告警。
3. 恢复时选错时间点，把好数据覆盖掉，恢复前先确认备份点的创建时间。
4. 只备系统盘不备数据盘，真正出事时业务数据还是丢。

六、小结

备份的价值不在平时，而在出事的那一天。CBR 把「创建存储库—定策略—绑资源—验恢复」这条链路做成了配置化操作，一次设置、长期自动运行，再配合容量告警和定期恢复演练，就能用很低的运维成本，给云服务器数据上一份靠谱的保险。