切换与回切是一对流程
存储容灾的完整生命周期包含两个方向的动作。切换把业务从生产站点搬到灾备站点，让业务在灾难发生后尽快恢复；回切把业务从灾备站点搬回原站点，恢复原有的运行位置与保护级别。回切容易在方案设计阶段被忽略，但它的复杂度通常高于切换：原站点在灾难中可能被部分重建，数据状态与灾备站点不一定一致；同时业务已经恢复运行，无法像切换那样安排一个完全停写的窗口，把增量按顺序回传并保持一致性成为整个流程中最难的部分。
基本信息
| 切换方向 | 生产站点到灾备站点 |
|---|---|
| 回切方向 | 灾备站点回到原生产站点 |
| 切换前提 | 确认副本完整性、业务可启动性与授权 |
| 回切前提 | 原站点修复验收完成，差异分析清楚 |
| 回切难点 | 业务不停机时传送增量并保持顺序一致 |
| 记录要求 | 记录各阶段时间点、数据缺口与责任人 |
典型使用场景
- 计划内切换：利用维护窗口把业务临时搬到灾备站点
- 计划外切换：生产站点失效后的紧急接管
- 回切准备：原站点硬件修复验收并完成数据差异分析
- 回切执行：在业务低谷期切换并逐项验证业务功能
- 成对演练：切换与回切一起演练，验证双向流程都可用
- 复盘归档：记录每次切换的真实耗时与遇到的问题
阶段与注意点
| 阶段 | 关键动作 | 注意点 |
|---|---|---|
| 切换决策 | 确认故障范围并取得授权 | 提前明确谁有权决定切换 |
| 数据提升 | 把灾备副本提升为主用 | 核对落后量是否可接受 |
| 业务接管 | 应用与网络指向灾备站点 | 刷新连接池与 DNS 缓存 |
| 灾备运行 | 灾备站点承担生产负载 | 性能可能低于生产，需降级策略 |
| 原站点修复 | 硬件与数据修复并验收 | 验收标准应提前定义 |
| 增量回传 | 把灾备期间新数据回传原站点 | 业务不停机时的追平策略 |
| 回切执行 | 切回原站点并验证功能 | 保留随时回退的路径 |
| 恢复保护 | 重建复制关系 | 避免长期停留在单向运行状态 |
回切比切换更容易出问题，因为它发生在业务已经恢复之后：紧迫感下降，参与人员的注意力已经转移，同时原站点的数据状态往往需要重新确认。稳妥的做法是把回切当作一个独立项目来准备，包含差异分析、追平计划、切换窗口与验收清单，而不是把它当成切换的逆向操作随手执行。
回切期间若业务不中断，存在两端数据同时演进的风险。常见做法是让业务继续在灾备站点写入，同时把增量按顺序回传到原站点，待追平后再安排切换窗口。任何情况下都不应让两个站点同时接受同一业务的写入，否则会产生无法自动合并的数据分叉。
回切准备检查表
回切准备检查表
# [ ] 原站点硬件与固件已修复并完成验收
# [ ] 原站点数据状态已确认，同步方向已明确
# [ ] 增量回传带宽足以在窗口内追平
# [ ] 业务方已确认切换窗口与回退条件
# [ ] 回切后立即重建复制关系
# [ ] 回切完成后核对数据完整性与业务功能