从误删到秒级恢复：用华为云 CBR 构建企业级备份与容灾体系

一、背景与痛点

1. 运维误删数据目录：rm -rf 打错路径，订单服务日志目录连带数据卷一起没了。靠手工从旧快照恢复，花了 4 小时
2. 升级回滚失败：大版本升级后接口异常，想回滚发现上一版备份是两周前的，中间订单数据对不上
3. 勒索软件试探：一台边缘服务器中了勒索病毒，虽然没扩散，但暴露了"全靠运气没中核心库"的现状
4. 无恢复演练：备份策略写了、任务跑了，但从没人真正做过一次完整恢复验证——备份文件能不能用、恢复到什么时间点，全是未知数

二、方案设计

2.1 为什么用 CBR 而不是手工脚本

2.2 备份策略分层

2.3 整体架构

生产环境（华北-北京四）
   │
   ├─ 云服务器备份（崩溃一致性）
   │    └─ 每日凌晨全量 + 增量链
   │
   ├─ 云硬盘备份（应用一致性）
   │    ├─ 数据库 ECS：预/后脚本冻结 IO
   │    └─ 应用 ECS：标准崩溃一致性
   │
   ├─ 跨区域复制 → 华南-广州
   │    └─ 容灾站点异步复制（每日）
   │
   └─ 备份策略管理
        ├─ 保留规则：日备保留7天、周备保留4周、月备保留12月
        └─ 审计日志：谁在什么时候删了备份

恢复演练（每月一次）
   └─ 从备份创建新 ECS → 挂载恢复 → 数据校验 → 销毁

三、实操步骤

3.1 创建备份存储库

• 类型：云服务器备份存储库 / 云硬盘备份存储库
• 容量：按源数据量 × 保留副本数估算（建议预留 2.5 倍）
• 保护类型：备份
• 绑定资源：选择需要备份的 ECS 或云硬盘

避坑：存储库容量不够时备份任务会失败但不通知，建议开启容量告警，阈值设 80%。

3.2 配置备份策略

• 执行时间：每日 02:00（业务低峰）
• 保留规则：
  • 每天保留最新 1 个，保留 7 天
  • 每周一保留 1 个，保留 4 周
  • 每月 1 日保留 1 个，保留 12 个月
• 跨区域复制：启用，目标区域 cn-south-1，延迟复制 6 小时

• 核心交易 ECS → prod-db-backup 策略
• 应用服务器 ECS → prod-app-backup 策略

3.3 配置应用一致性备份（数据库关键步骤）

#!/bin/bash
# 记录开始时间
echo "$(date '+%Y-%m-%d %H:%M:%S') pre_freeze start" >> /var/log/cbr_consistency.log

# MySQL 冻结：FLUSH TABLES WITH READ LOCK
mysql -u root -p${DB_PASS} -e "FLUSH TABLES WITH READ LOCK; SET GLOBAL read_only=ON;" 2>/dev/null

# 等待 IO 落盘
sync

echo "$(date '+%Y-%m-%d %H:%M:%S') pre_freeze done" >> /var/log/cbr_consistency.log
exit 0

#!/bin/bash
echo "$(date '+%Y-%m-%d %H:%M:%S') post_thaw start" >> /var/log/cbr_consistency.log

# MySQL 解冻：释放锁
mysql -u root -p${DB_PASS} -e "SET GLOBAL read_only=OFF; UNLOCK TABLES;" 2>/dev/null

echo "$(date '+%Y-%m-%d %H:%M:%S') post_thaw done" >> /var/log/cbr_consistency.log
exit 0

chmod +x /opt/cbr/scripts/pre_freeze.sh
chmod +x /opt/cbr/scripts/post_thaw.sh

• 启用：是
• 脚本路径：/opt/cbr/scripts/pre_freeze.sh 和 /opt/cbr/scripts/post_thaw.sh
• 超时时间：300 秒

避坑：pre_freeze 脚本执行超时会导致备份失败，数据库锁持有期间业务写入阻塞，所以冻结窗口要尽量短（通常 < 30 秒）。

3.4 跨区域复制配置

• 与源区域不同可用区（至少跨 AZ）
• 优先选择不同地理区域（如北京 → 广州）

3.5 恢复演练流程（每月执行）

• 从最新备份创建新 ECS（不覆盖生产）
• 使用不同 IP 段，避免网络冲突

# 挂载恢复后的数据盘
mount /dev/vdb1 /mnt/recovery

# 校验数据库文件完整性
mysqlcheck -u root -p${DB_PASS} --check --all-databases

# 校验关键业务表行数
mysql -u root -p${DB_PASS} -e "SELECT COUNT(*) FROM orders.orders_2024;" > /tmp/row_count.txt

• 启动应用服务，检查日志无报错
• 跑核心接口冒烟测试

• 记录恢复耗时、数据校验结果
• 销毁演练 ECS 和数据盘

• 实际 RTO vs 目标 RTO
• 发现的问题和整改措施

四、验证结果

• 源区域备份完成 → 目标区域可见：延迟 4-8 小时（符合预期）
• 目标区域独立恢复测试：成功

五、生产避坑清单

1. 只备份不演练：备份文件损坏、权限丢失、格式不兼容，恢复时才发现全是废文件
2. 备份策略"永远保留"：存储库撑满后新备份全部失败，还占着钱
3. 应用一致性脚本有 bug：pre_freeze 里锁了数据库但 post_thaw 没执行，数据库永久只读
4. 跨区域复制没开：单区域故障（虽然概率低）直接全丢
5. 备份存储库和源数据在同一可用区：AZ 级故障一起没
6. 数据库没开 binlog：备份只能恢复到备份时刻，备份后到故障前的增量数据全丢
7. 恢复时直接覆盖生产：恢复操作出错，生产数据被覆盖且无法回退
8. 备份任务失败没人看：告警没配或配了没人管，连续失败一周才发现

• 每月至少一次恢复演练，写进运维 SOP
• 保留规则按"日/周/月"三级，不保留无限历史
• 应用一致性脚本先在测试环境验证，确认 post_thaw 一定能执行
• 跨区域复制目标选地理距离 ≥ 500km 的区域
• 数据库备份 + binlog 归档双重保险，RPO 才能压到分钟级
• 恢复操作一律先恢复到新环境校验，确认无误再决定是否切换生产
• 备份任务失败告警接值班手机，不是接邮箱
• 备份存储库容量告警设 80%，提前扩容

六、成本结构梳理

经验：备份存储成本通常占云总支出的 5%-10%，但它是"最后一道防线"。别在这上面省，但要定期审视保留策略，清理过期备份。

七、总结与扩展

• 一致性是底线：崩溃一致性只能保证文件系统不坏，数据库必须上应用一致性
• 跨区域是刚需：单区域故障虽罕见，但一旦发生就是毁灭性的
• 演练比备份重要：没演练过的备份等于没备份
• RPO/RTO 要量化：模糊的"尽快恢复"不是目标，"30 分钟内恢复、丢失不超过 5 分钟数据"才是

1. 备份即代码：用 Terraform/CloudFormation 管理备份策略和存储库，版本可控
2. 自动化演练：定时任务自动拉起恢复环境、跑校验脚本、输出报告、销毁资源
3. CDP 持续数据保护：对核心数据库引入秒级 RPO 方案，替代定时备份
4. 勒索防护联动：备份 + 防勒索服务 + 文件完整性监控，构建纵深防御
5. 合规审计：备份操作日志接入 LTS，满足等保/行业合规要求
6. 混合云容灾：本地 IDC + 云上双活，关键业务 RTO 压到分钟级

本文为原创备份容灾实践，基于华为云云备份 CBR 整理，操作步骤以当前控制台页面为准。生产环境部署前请在测试环境验证脚本和流程。转载请注明出处。