备份与容灾自动化：RPO/RTO、Velero、PITR 与恢复演练

常见的"数据归零"场景：
  误删（DELETE 忘带 WHERE）、勒索软件、人为破坏、基础设施故障
代价公式：丢失数据量 × 重建成本 × 业务停摆损失
  没有备份时，一次误删可能等于"公司级事故"

手工备份的三个致命问题：
  - 忘了备份：人总会忘
  - 备了不会恢复：恢复步骤没验证，真出事时手忙脚乱
  - 恢复太慢：RTO 超标，业务已停摆

DevOps 化的目标：
  备份像 CI/CD 一样自动跑、可验证、可审计
  "备份不是备份做没做，而是恢复能多快"

RPO（Recovery Point Objective，恢复点目标）：
  最多允许丢多少数据 = 备份频率
  例：RPO=15min → 最多丢 15 分钟的数据

RTO（Recovery Time Objective，恢复时间目标）：
  最多允许停多久 = 恢复速度
  例：RTO=1h → 1 小时内必须恢复服务

两者独立：可以 RPO 很小但 RTO 很大（数据不丢但恢复慢）

  - 每个服务/数据资产登记一个"容灾等级"（RPO/RTO）
  - 备份频率、恢复方案由等级驱动
  - 等级定期评审（业务变了，容灾目标跟着变）
  - 达不到等级的，明确记录差距并排期改进

3-2-1 备份原则：
  3 份数据副本（生产 + 2 份备份）
  2 种不同介质（如本地 + 对象存储）
  1 份异地/异云（防机房级故障）

典型组合：
  每日全量 + 每小时增量（RPO=1h 内的好策略）
  保留策略：最近 N 天增量 + 最近 M 个全量 + 月度归档

cron 调度示例：
  00:10 每天     → 全量备份（写对象存储）
  *:20 每小时    → 增量备份（WAL/增量）
  每季度         → 归档到冷存储（Glacier/低频）
  每天 08:00     → 校验昨日备份（可恢复性检查）

# 概念：全量 + 增量备份脚本
#!/usr/bin/env bash
set -euo pipefail
TS=$(date -u +%Y%m%d-%H%M%S)
if [ "${BACKUP_TYPE}" = "full" ]; then
  pg_dump -Fc shop > /backup/shop-full-${TS}.dump
else
  pg_basebackup -D /backup/incr-${TS}  # 或基于 WAL 归档
fi
aws s3 cp /backup/ s3://backup-bucket/ --recursive

主备（Active-Passive）：
  - 备站已部署好完整应用 + 数据同步（数据库实时复制）
  - 主站故障 → DNS/流量切换 → 备站接流量
  - 关键：备站要"定期真切换演练"，否则切换时才发现没准备好

数据同步方式：
  - 数据库流式复制（PostgreSQL streaming / MySQL binlog）
  - 对象存储跨区域复制（S3 CRR / GCS 多区域）

多活（Active-Active）：
  - 多个区域同时服务，流量就近分发
  - 数据：需跨区域双向同步（冲突处理是难点）
  - 依赖：全局负载均衡（如 Global Load Balancer / Anycast）

适用：对 RTO 要求极高（秒级）、有全球用户、能承担复杂度
  不适用：大部分业务（主备 + 快速恢复通常已足够）

# 跨区域故障切换（DNS 层，概念）
# Route53 / 云解析：健康检查失败 → 切换流量到备站
#   primary.shop.example.com  → us-east-1（主）
#   standby.shop.example.com  → eu-west-1（备）
#   故障时：A 记录指向 eu-west-1

Velero = Kubernetes 备份/恢复/迁移工具（VMware 开源）
  - 备份集群资源（Deployment/Service/ConfigMap/CRD）
  - 备份 PV 数据（支持 Restic/Kopia 卷备份）
  - 恢复：整集群 or 按命名空间 or 按资源
  - 迁移：从旧集群搬到新集群

# 安装 Velero（备份目标为 S3 兼容对象存储）
velero install \
  --provider aws \
  --bucket velero-backups \
  --secret-file ./credentials-velero \
  --backup-location-config region=cn-north-1 \
  --plugins velero/velero-plugin-for-aws:v1.9.0 \
  --use-volume-snapshots=true

# 备份整个集群（含卷）
velero backup create cluster-backup-20260927 --default-volumes-to-restic
# 备份指定命名空间
velero backup create ns-checkout --include-namespaces checkout

# 恢复（注意：恢复到临时命名空间先验证）
velero restore create --from-backup cluster-backup-20260927 \
  --namespace-mappings shop:shop-restore

# 定时备份（Schedule）
velero schedule create daily-backup --schedule="0 1 * * *" \
  --default-volumes-to-restic

Velero 最佳实践：
  - 备份对象存异地/异云桶（防区域级故障）
  - 定期做"恢复演练"（恢复到测试集群验证）
  - 卷备份用 Kopia/Restic，别依赖云快照绑定

PITR（Point-In-Time Recovery，时间点恢复）：
  - 全量备份 + 持续 WAL/binlog 归档
  - 可恢复到任意时间点（精确到事务）
  - 应对"误删了 5 分钟前的数据"这类场景

对比：
  普通备份 → 恢复到"上次备份时刻"
  PITR     → 恢复到"任意时刻"（靠 WAL 重放）

# 开启 WAL 归档（postgresql.conf）
wal_level = replica
archive_mode = on
archive_command = 'aws s3 cp %p s3://pg-wal-bucket/%f'

# 全量基础备份
pg_basebackup -D /backup/base -Ft -z -P

# 恢复（restore_command 拉取 WAL）
# recovery.signal + restore_command = 'aws s3 cp s3://pg-wal-bucket/%f %p'
# recovery_target_time = '2026-09-27 11:30:00 UTC'

  - AWS RDS：自动备份 + 时间点恢复（默认保留 7 天，可延长到 35 天）
  - 阿里云 RDS：备份保留天数可配置 + 秒级恢复
  - GCP Cloud SQL：PITR 需开 binary logging

要点：托管 PITR 要显式开启、设好保留期、定期演练
  别以为"云上自动备份"就不用管——保留期、恢复能力都要验证

"备份能恢复"不是假设，而是要靠演练证明：
  - 90% 的备份故障都在"真需要恢复时"才暴露
  - 演练 = 在非生产环境真实执行恢复流程

演练频率建议：
  - 月度：关键服务（L0/L1）恢复演练
  - 季度：整集群/多服务联合演练
  - 每年：跨云容灾切换演练

恢复演练流程：恢复到临时环境 → 校验数据完整性 → 冒烟/E2E 验证 →
  记录恢复耗时（对比 RTO）→ 生成报告并排期修复差距项
失败处理：演练失败 = 发现真问题，立即修复备份/恢复流程

混沌验证的"故障注入"用于容灾演练：
  - 随机杀主库 → 验证自动切换（failover）
  - 注入区域级故障 → 验证跨云切换
  - 断网模拟 → 验证备份上传是否中断、是否重试

价值：混沌让演练从"人为安排"变成"持续验证"
  ——即使没人记得演练，系统也在被验证

备份不是"设置了就行"，要监控这些点：
  - 备份是否按时执行（成功/失败/超时）
  - 备份文件大小/数量是否异常（突然变小 = 可能失败）
  - 恢复校验是否通过（每日自动校验）
  - 对象存储容量与成本

告警示例：
  备份任务失败 → 立即告警
  连续 N 天无成功备份 → 告警
  校验失败 → 升级告警

# Prometheus 示例：最近备份距今超过 RPO 即告警
time() - backup_last_success{job="velero"} > (15 * 60)

  - 数据备份是大多数合规要求的硬性项（SOC 2 / ISO 27001 / GDPR）
  - 备份要加密（静态加密 + 传输加密）
  - 保留策略要明确（法律/业务要求的数据保留期限）
  - 审计需证明：有备份、有演练、有监控

# 每日备份 + 校验流水线（CI 定时触发，概念）
name: daily-backup
on:
  schedule:
    - cron: '0 1 * * *'
jobs:
  backup-and-verify:
    runs-on: ubuntu-latest
    steps:
      - name: Velero backup
        run: velero backup create daily-$(date +%Y%m%d)
      - name: DB PITR base backup
        run: pg_basebackup -D /tmp/base -Ft -z
      - name: Upload to object storage
        run: aws s3 sync /tmp/base s3://backup-bucket/daily/
      - name: Restore verify (临时环境)
        run: |
          velero restore create --from-backup daily-$(date +%Y%m%d) \
            --namespace-mappings shop:shop-verify
          ./scripts/verify-restore.sh
      - name: Notify
        run: curl -X POST https://im.example.com/hooks/backup-result -d '{"status":"ok"}'

□ 每个服务登记容灾等级（RPO/RTO），按等级设计备份与恢复
□ 备份策略：全量 + 增量/差异组合，遵守 3-2-1 原则
□ 异地/异云存储（防区域级故障）
□ Kubernetes 用 Velero（含卷备份）+ 定时 Schedule
□ 数据库开 PITR（WAL/binlog 归档 + 保留期确认）
□ 恢复演练月度/季度化，演练即验收
□ 备份失败/过期/校验失败监控告警
□ 备份加密 + 保留策略 + 审计记录
□ 混沌注入验证自动切换与跨云容灾

备份与容灾 = "平时多流汗，战时少流血；
备份靠自动化，恢复靠演练。"