这是《RocketMQ 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 备份回答“数据坏了能不能恢复”，迁移回答“换集群后路由、位点、业务和客户端能不能安全切换”。两者都不是简单复制文件，必须先定义恢复目标、数据边界和回滚路径。
25.1 目标定义
常用目标：
| 目标 | 问题 |
|---|---|
| RPO | 最多可接受丢多少数据 |
| RTO | 多久恢复服务 |
| 消息范围 | 全集群、核心 Topic、审计 Topic |
| 位点范围 | 消费位点、重试、死信、事务状态 |
| 服务范围 | 客户端、Proxy、监控、告警 |
示例：
core topics RPO = 0 through sync replication
recovery RTO = 30 minutes
noncritical topics RPO = 5 minutes
没有目标的备份方案很难验证有效性。
25.2 备份对象
必须备份：
- Topic 配置；
- 队列数和权限；
- ACL 配置；
- Broker 配置；
- NameServer 地址和元信息；
- 消费组位点；
- 关键消息数据；
- 事务和定时消息状态；
- 监控和告警配置；
- 运维脚本与证书配置说明。
消息数据可以选择：
| 方式 | 适用 |
|---|---|
| 副本 | 在线高可用 |
| 冷备份文件 | 指定时间点恢复 |
| 异地复制 | 机房级容灾 |
| 归档到对象存储 | 审计和长期保留 |
| 业务事件表 | 业务级兜底 |
25.3 文件备份
理论备份对象：
store/commitlog
store/consumequeue
store/index
store/config
store/checkpoint
broker config
注意：
- 在线文件复制可能得到不一致快照；
- Broker 停止后复制更一致，但服务中断；
- 云盘快照需确认崩溃一致性；
- ConsumeQueue 和 Index 可重建，但重建耗时；
- 必须保留 checkpoint 和配置；
- 备份文件不要和原集群同故障域；
- 恢复前校验版本和目录结构。
25.4 备份验证
备份必须恢复演练：
restore to isolated cluster
-> start brokers
-> verify topic route
-> check offsets
-> sample messages
-> compare counts
-> test consumer resume
-> measure recovery time
验证指标：
- 消息条数；
- 按时间范围的边界；
- 指定业务 Key 查询；
- 消费位点；
- 死信和重试；
- 权限；
- 恢复耗时；
- 应用可连接性。
未演练过的备份只能算“复制了一份未知状态的文件”。
25.5 迁移方式
| 方式 | 适用 | 特点 |
|---|---|---|
| 停机迁移 | 小规模、强一致 | 简单但服务中断 |
| 双写迁移 | 核心业务 | 数据可对账，改造多 |
| 双消费迁移 | 消费逻辑切换 | 需防重复副作用 |
| 位点映射迁移 | 新旧数据连续 | 位点换算复杂 |
| 云厂商迁移 | 上云或跨云 | 依赖工具和网络 |
常用流程：
inventory
-> build target
-> backfill or dual write
-> verify data
-> migrate consumers gradually
-> switch producers
-> observe
-> retire old cluster
25.6 位点迁移
位点不是全局数字，必须按队列处理：
old cluster:
topic + broker + queueId -> offset
new cluster:
topic + broker + queueId -> offset
如果新集群从历史数据第一条开始重放，位点可以重新初始化；如果新旧数据拼接，需要明确边界事件和切换时间戳。
推荐做法：
- 使用业务事件时间和唯一 ID 做对账；
- 新旧集群使用相同 eventId；
- 消费端幂等；
- 记录切换边界；
- 小流量消费组验证；
- 保留回滚位点。
25.7 客户端切换
切换清单：
- 配置中心地址；
- ACL 凭据；
- Topic 名称和权限；
- 消费组命名；
- SDK 版本；
- 超时和重试；
- TLS 配置；
- 灰度规则；
- 回滚开关。
发布顺序建议：
noncritical consumers
-> noncritical producers
-> critical consumers
-> critical producers
避免生产者新集群、消费者旧集群的长期错配。
25.8 回滚方案
回滚前提：
- 旧集群仍可写入；
- 双写或补偿仍在运行；
- 新增事件可回流；
- 位点可恢复；
- 客户端配置可快速切换；
- 业务幂等有效。
需要明确：
rollback trigger
rollback owner
data reconciliation
maximum rollback window
超过最大回滚窗口后，只能前向修复，不能强行回退。
25.9 常见错误
| 错误 | 后果 |
|---|---|
| 只备份消息不备份配置 | 恢复后路由和权限缺失 |
| 在线随意复制存储文件 | 数据不一致 |
| 位点直接照搬 | 消费错位 |
| 双消费未做幂等 | 重复业务动作 |
| 迁移后不做对账 | 数据缺失不可发现 |
| 无回滚窗口 | 只能停业修复 |
| 备份未恢复演练 | 恢复能力未知 |
本章小结
备份与迁移的核心是数据边界、位点语义、配置完整性和回滚能力。副本是在线高可用，不等于备份；文件复制不等于可恢复。关键业务应有业务级对账和事件表兜底，所有方案都要在隔离环境中演练。
思考题
- RPO 和 RTO 如何影响备份设计？
- 为什么不能把旧集群 offset 直接写入新集群？
- 双写迁移和双消费迁移分别适合什么场景？
- 迁移时为什么 eventId 很重要？
- 为什么备份必须做恢复演练？