容灾与数据备份：RTO/RPO、PITR 与恢复演练

RTO（Recovery Time Objective）恢复时间目标：
□ 从故障发生到服务恢复可用的最长时间
□ 决定：需要多快切换、要预热多少实例、要不要多活
□ 微型博客参考：核心读接口 15 分钟，写入 30 分钟

RPO（Recovery Point Objective）恢复点目标：
□ 能容忍丢失多少时间窗口的数据
□ 决定：备份频率、复制方式（同步/异步）、日志归档间隔
□ 微型博客参考：帖子与关系 RPO ≈ 0（同步复制），
  统计与热度 RPO 可放宽到 1 小时

两者是成本曲线：
RTO/RPO 越接近 0，成本越呈指数上升
□ 冷备（天级恢复）→ 便宜
□ 温备（小时级）→ 中
□ 热备/多活（分钟级）→ 贵

全量备份（Full）：
□ 完整复制所有数据；恢复最快、占用最大
□ 频率：每天 / 每周一次（按数据量定）

增量备份（Incremental）：
□ 只备份自上次备份以来的变化；占用最小、恢复最慢
□ 恢复需要「全量 + 所有增量」链式重放

差异备份（Differential）：
□ 备份自上次全量以来的变化；折中方案
□ 恢复需要「全量 + 最近一次差异」

3-2-1 原则：
3 份副本（1 份生产 + 2 份备份）
2 种介质（如本地磁盘 + 对象存储）
1 份异地（地理隔离，抗区域性灾难）

扩展 3-2-1-1-0：
+1 份离线/不可变（抗勒索）
+0 个错误（备份必须验证，不能有未验证的备份）

备份安全三件套：
□ 加密（Encryption）：
  · 传输加密（TLS）+ 静态加密（KMS 托管密钥）
  · 密钥与数据分离存储，密钥丢失 = 数据不可恢复
□ 不可变（Immutability）：
  · 对象存储开启 Object Lock / WORM（一次写入多次读取）
  · 保留期内任何人（包括管理员）都不能删除或篡改
□ 隔离（Isolation）：
  · 备份账号与生产账号分离，权限最小化
  · 备份网络与生产网络隔离（生产被攻陷不影响备份）
  · 离线/磁带等「空气间隙」副本

权限隔离示例：
生产服务账号：只能写业务数据，无备份桶权限
备份写入账号：只能写备份桶，不能删除
恢复账号：只在恢复流程中临时提权，用完即收回
审计：所有备份桶的删除操作必须触发告警

PostgreSQL 时间点恢复（PITR, Point-In-Time Recovery）：
□ 基础备份（pg_basebackup）+ WAL 归档（continuous archiving）
□ 恢复：还原基础备份 → 重放 WAL 到指定时间点
□ 能力：可恢复到「误删前 1 秒」的任意时刻
□ 部署：流复制到从库 + WAL 归档到对象存储

关键参数：
wal_level = replica             # 记录足够 WAL 用于归档
archive_mode = on
archive_command = 'wal-g wal-push %p'   # 归档到对象存储
archive_timeout = 60            # 强制切换 WAL 段，控制 RPO

# 全量基础备份 + 归档到对象存储（wal-g 示例）
wal-g backup-push /var/lib/postgresql/data
wal-g backup-list

# 恢复到指定时间点（先停库、还原、重放）
wal-g backup-fetch /var/lib/postgresql/data LATEST
# recovery.signal + restore_command 指向 wal-g wal-fetch

对象存储保护手段：
□ 版本控制（Versioning）：覆盖/删除保留历史版本，防误删
□ 跨区域复制（CRR）：异步复制到异地桶，抗区域故障
□ 生命周期（Lifecycle）：转低频/归档存储，降成本
□ 对象锁（Object Lock）：合规保留，防篡改
□ 校验和：上传时记录，读取时校验完整性

媒体资产的特殊性：
□ 大文件、不可变（上传后不改）→ 天然适合版本控制
□ 转码产物可重算 → RPO 可放宽，源文件必须保护好
□ CDN 缓存是「加速层」，不是「数据层」，丢了可回源

// 跨区域复制 + 版本控制：抗区域性故障
{
  "Role": "arn:aws:iam::123:role/replication",
  "Rules": [{
    "Status": "Enabled",
    "Prefix": "media/",
    "Destination": {
      "Bucket": "arn:aws:s3:::miniblog-media-dr",
      "StorageClass": "STANDARD_IA"
    },
    "DeleteMarkerReplication": { "Status": "Disabled" }
  }]
}

容灾等级（由低到高）：
□ 冷备（Backup & Restore）：出事了才拉起环境，RTO 小时级
□ 温备（Pilot Light）：最小环境常驻，出事扩起来，RTO 分钟~小时
□ 热备（Warm Standby）：完整环境 + 异步复制，RTO 分钟级
□ 多活（Active-Active）：两地都对外服务，RTO ≈ 秒级

多活的难点（不是「起两套」那么简单）：
□ 数据同步：跨区延迟 → 强一致与低延迟不可兼得
□ 写入冲突：两地同时写同一用户 → 需要冲突解决策略
□ 流量调度：DNS / Anycast / 全局负载均衡的健康检查
□ 会话与状态：登录态、购物车等状态要能跨区共享

故障切换（Failover）的关键设计：
□ 自动还是手动：核心库切换建议「自动检测 + 人工确认」
  · 全自动切换有脑裂风险（网络分区时两边都以为对方挂了）
□ 切换判据：健康检查连续失败 N 次 + 仲裁节点确认
□ 数据安全：切换前确认从库已追平（避免丢数据）
□ 回切预案：主恢复后如何切回（避免「单边运行」变常态）
□ 演练：定期做真实切换演练，验证 RTO 承诺

一致性风险：
□ 复制延迟导致从库数据滞后
□ 部分恢复（只恢复了一张表）造成引用断裂
□ 计数与实际记录数不符（点赞数 vs 点赞记录）
□ 软删除墓碑与关联数据不同步

校验手段：
□ 行数校验：关键表的行数在源与恢复环境比对
□ 校验和校验：分块计算 checksum 比对（如 pg_checksums）
□ 业务对账：计数表 vs 明细表定期对账
□ 引用完整性：孤儿记录扫描（无主评论、悬空关注）

-- 计数对账：发现「点赞数」与实际记录数的偏差
SELECT p.id, p.like_count, COUNT(l.user_id) AS actual
FROM posts p
LEFT JOIN likes l ON l.post_id = p.id
GROUP BY p.id, p.like_count
HAVING p.like_count <> COUNT(l.user_id);

-- 孤儿记录扫描：指向已删除帖子的评论
SELECT c.id FROM comments c
LEFT JOIN posts p ON p.id = c.post_id
WHERE p.id IS NULL;

恢复演练的层次：
□ L1 备份可读：确认备份文件能下载、能解压、校验和一致
□ L2 单表恢复：从备份中恢复一张表并验证行数与抽样内容
□ L3 全库恢复：完整还原到隔离环境，跑通关键查询
□ L4 时间点恢复：验证 PITR 能恢复到「误操作前 1 秒」
□ L5 切换演练：真实把流量切到备用环境，验证 RTO

演练剧本要素（同混沌工程）：
□ 稳态假设：演练前记录基线指标
□ 注入：模拟真实故障（删库、区域不可用）
□ 观测：恢复耗时是否满足 RTO、数据是否满足 RPO
□ 复盘：记录卡点（凭据过期、脚本失效、文档过时）

降级策略（故障期间的兜底）：
□ 只读模式：数据库故障时，写入拒绝、读取走缓存/从库
□ 功能降级：关掉非核心功能（推荐、搜索），保核心（时间线）
□ 静态兜底：首页降级为静态缓存页 + 提示
□ 排队缓冲：写入进队列，恢复后异步补写
□ 限流保护：故障期间收紧限流，避免雪崩

用户沟通：
□ 明确的状态页（Status Page）与提示文案
□ 避免「白屏」——降级也要给用户可用的东西
□ 恢复后对「降级期间受影响的操作」给出补偿或说明