1.1 背景说明

本方案面向IBM DB2业务数据库，目标是在现有主库 + 冷备库 + 归档日志持续应用架构基础上，满足对该数据库提出的 RTO 和 RPO 灾备指标要求。

1.2 RTO/RPO 目标

• 指标要求：在故障发生后 4 小时内完成服务恢复（RTO≤4 小时），在故障发生前 1 小时内的数据可通过灾备恢复（RPO≤1 小时，为本系统需满足的最低要求）。
• 设计目标：在满足上述指标的前提下，尽可能缩短实际恢复时间、尽量减少数据丢失。

二、整体架构方案概述

2.1 方案选型

在本方案中，采用”主库 + 冷备库 + 归档日志实时传输与应用”的架构，即：

• 生产库为主库，承担所有在线业务读写；
• 冷备库为长期处于“待命”状态的备机，只接受归档日志与定期备份恢复，不对外提供业务访问；
• 通过归档日志的持续传输与应用，保证冷备库数据延迟控制在 1 小时以内，从而满足 RPO≤1 小时；
• 发生故障时，通过预先定义的切换脚本将冷备库提升为新主库，在 4 小时 RTO 内完成服务恢复。

2.2 架构组成

• 主库服务器：承载 DB2 生产实例及业务数据库。
• 冷备服务器：已部署 DB2 实例，当前通过备份恢复和日志应用保持与主库数据同步。
• 备份存储架构：冷备服务器的 /db2backup 目录通过 NFS 挂载到主库服务器，主库备份目标路径指向 /db2backup/data，实现备份数据直接写入冷备侧存储。
• 归档日志存储：主库归档日志存储在主库本地磁盘，通过 rsync 定期同步至冷备服务器本地，供冷备库应用。
• 日志传输与应用脚本：负责定期将主库归档日志传输至冷备库并自动应用。
• 虚拟化与运行状态：主库和冷备库虚拟机分别部署在不同的 ESXi 物理主机上，灾备虚拟机保持开机运行，冷备库数据库长期保持 rollforward pending 状态，不对外提供业务访问。

三、数据保护与备份策略

3.1 备份策略设计

• 全量备份：

su - db2inst1 -c "db2 BACKUP DATABASE 「数据库名」 ONLINE TO /db2backup/data COMPRESS WITHOUT PROMPTING"
[ $? -eq 0 ] && find /db2backup/data -name "「数据库名」.0.*.001" -mtime +6 -delete

su - db2inst1 -c "db2 BACKUP DATABASE 「数据库名 2」 ONLINE TO /db2backup/data COMPRESS WITHOUT PROMPTING"
[ $? -eq 0 ] && find /db2backup/data -name "「数据库名 2」.0.*.001" -mtime +6 -delete

- 建议固定在每周五晚 19:30 进行一次数据库全量在线备份，备份目标路径为 /db2backup/data（利用 NFS 挂载，备份数据直接写入冷备侧存储）。
- 全量备份保留周期根据合规要求和存储成本综合确定，根据现有的存储建议保留一份全量备份，但需要在第二份备份镜像生成后才能移除上一个备份镜像；
- 参考 DB2 在线全量备份命令示例：  

su - db2inst1 -c "db2 BACKUP DATABASE 「数据库名」 ONLINE TO /db2backup/data COMPRESS WITHOUT PROMPTING"
su - db2inst1 -c "db2 BACKUP DATABASE 「数据库名 2」 ONLINE TO /db2backup/data COMPRESS WITHOUT PROMPTING" - 可结合定时清理任务定期删除超出保留周期的历史备份文件，仅在备份成功后执行清理，使用 [ $? -eq 0 ] 来明确检查上一条命令的退出状态，正常备份完成后退出才会删除上一周期的备份镜像，如果备份失败则不删除，排查原因后再重新择期备份。

• 日志归档策略：
  • 启用归档日志模式，确保所有已提交事务均写入归档日志，当前的模式为LOGRETAIN，已确认；
  • 归档日志生成后，每隔 5～10 分钟由 rsync 脚本增量同步至冷备服务器；
  • 归档日志本地保留时间根据 RPO 及演练需求配置，根据我们当前环境可保留 7～14 天。

3.2 冷备库数据建立与维护

• 初始构建：
  • 从主库最近一次全量备份（位于 /db2backup/data）在冷备服务器上进行 restore 恢复；
  • 恢复完成后，从该备份点开始持续应用主库归档日志，使冷备库追平至当前时间附近。
• 持续维护：
  • 每个季度基于最近一次全量备份（/db2backup/data）在冷备服务器上执行一次完整 restore（基线重建），并配合持续应用近期归档日志，既验证恢复链路，又缩短日志应用链路，降低故障场景下的恢复复杂度。

四、日志传输与应用策略

4.1 日志传输频率

• 日志生成与传输：

# 同步主库归档日志到冷备服务器
rsync -avz --bwlimit=10240 /db2archive/「数据库名」/ root@x.x.x.x:/db2archive/「数据库名」/
rsync -avz --bwlimit=10240 /db2archive/「数据库名 2」/ root@x.x.x.x:/db2archive/「数据库名 2」/

上面命令的参数说明：-a 保持文件属性，-v 显示详细信息，-z 压缩传输，--bwlimit=10240 限制带宽为 10MB/s主要是考虑到现有存储的 IO 压力可以设置合适的带宽限制。

- 通过调度任务（如每 5～10 分钟）检查主库归档目录，将新产生的归档日志同步到冷备服务器；
- 传输统一采用 rsync，实现增量同步，并可按需配置带宽限制与重试策略，确保传输可靠性与安全性；

• RPO 控制：
  • 根据 RPO 要求和业务写入量配置 rsync 同步间隔，建议同步间隔控制在 5～10 分钟范围内，实际可根据现有资源情况由大到小逐步调整到既不影响业务操作又能尽可能满足 RPO 的要求，每次调整后需持续监控主库性能指标、网络带宽使用率和冷备日志应用延迟，确认无异常后再进一步优化；
  • 在考虑日志生成频率、网络带宽和脚本执行时间前提下，将“日志产生到传输完成”的时间控制在约 15 分钟级别（每天产生的数据量不到 1GB，传输的归档日志单个 40MB，实际传输的数据量可以说很少，传输时间和 IO 可控）；
  • 在冷备侧设置同样频率的日志应用任务，综合传输与应用延迟，使冷备库数据延迟通常控制在 30 分钟以内，最大不超过 1 小时，从而满足 RPO≤1 小时。也可根据运维需要适当延长日志应用（回滚）的间隔，例如设置为半天应用一次归档日志，在主库发生人为误操作时提供更长的恢复窗口，同时由于归档日志持续传输至冷备服务器，灾难场景下仍可快速应用所有日志完成追平。
  • 日常运维要求：需持续监控 rsync 同步状态及冷备库日志应用延迟，确保不超过预设阈值，保障灾备系统的有效性。

4.2 日志应用策略

• 冷备库上运行周期任务：
  • 扫描指定目录下的新归档日志文件，按顺序调用 DB2 恢复命令进行日志应用；
  • 日志应用典型命令：
    su - db2inst1 -c "db2 ROLLFORWARD DATABASE 「数据库名」 TO END OF LOGS"
su - db2inst1 -c "db2 ROLLFORWARD DATABASE 「数据库名 2」 TO END OF LOGS"
• 异常处理：
  • 对日志缺失、损坏、无法应用等情况，脚本记录详细日志并触发告警；
  • 由运维人员根据告警信息及时排查，必要时重新进行一轮冷备基线构建。

五、RTO 评估与恢复流程设计

5.1 RTO 构成分析

在本方案中，冷备库平时持续应用日志，始终保持接近主库的最新状态，因此故障恢复时不再需要从头进行大规模备份恢复操作：

• 不将“从全量备份重新恢复数据库”的时间计入常规故障 RTO；
• RTO 主要由以下部分构成：
  • 故障确认与决策时间（目标：10～30 分钟内完成告警确认、影响评估和启动切换决策）；
  • 冷备库日志最终追平时间（目标：10～20 分钟内完成剩余归档日志的传输与应用）；
  • 数据库提升为主库、启动服务、基础验证时间（目标：30～40 分钟完成数据库角色切换）；
  • IP 切换与业务验证时间（目标：10～20 分钟完成服务器 IP 切换与业务方确认）。

RTO 时间构成一览表（常规场景）：

按照上述拆分，常规总耗时约 1.0～1.8 小时，即使考虑复杂故障场景预留 1～1.5 小时缓冲，仍可在 4 小时 RTO 约束内完成恢复。

5.2 故障切换流程（主库不可用场景）

故障切换步骤与目标耗时表：

1）发现故障（目标耗时：10～20 分钟）：

• 监控系统检测到主库实例或主机不可达，触发告警；
• 运维与业务共同确认故障级别，决定启动灾备切换。

2）冻结主库侧（目标耗时：10～20 分钟）：

• 确认主库已彻底失效或在短时间内无法恢复，避免“双主写入”风险；
• 如主库仍可访问但状态异常，需先停止主库服务并做好最终备份（视现场情况选择，如果还能继续传输最新的归档可以尝试传输）。
• 在 VMware vSphere 虚拟化平台把主库的网卡断开或者关机。

3）冷备库最终追平（目标耗时：10～20 分钟）：

• 检查并传输主库最终产生的归档日志（如仍可获取）；
• 在冷备库完成剩余日志应用，使数据尽量追平至最后一个可用日志点。

4）提升冷备库为主库（目标耗时：20～30 分钟）：

• 在冷备库执行必要的 DB2 命令，使数据库从恢复（Rollforward Pending）状态切换为正常开放状态。具体操作如下：

# 停止日志回滚，使数据库进入可读写状态
su - db2inst1 -c "db2 ROLLFORWARD DATABASE 「数据库名」 STOP"
su - db2inst1 -c "db2 ROLLFORWARD DATABASE 「数据库名 2」 STOP"

# 激活数据库
su - db2inst1 -c "db2 ACTIVATE DATABASE 「数据库名」"
su - db2inst1 -c "db2 ACTIVATE DATABASE 「数据库名 2」"

5）IP 切换与业务验证（目标耗时：10～20 分钟）：

• 将冷备服务器（新主库） IP 地址由 x.x.x.x 修改为原主库 IP y.y.y.y，使应用端无需修改配置即可连接。操作示例：

yast lan
# 在 YaST 网络配置界面将 IP 修改为 y.y.y.y 并保存生效

• 进行业务验证，确认业务可正常处理。

6）切换完成与记录（目标耗时：10～20 分钟）：

• 总结整理本次切换的过程形成文档，为后续保障提供有力的依据。

六、灾后恢复与架构重构

6.1 架构重构策略

切换完成后，原冷备库（y.y.y.y）将作为新的“主库”长期提供服务。故障主机修复后，无需进行业务回切，直接将其重构为新的“冷备库”，恢复原有的 1+1 灾备格局。这种方式能有效避免二次切换带来的业务停机风险和操作复杂度。

6.2 原主库重构为新冷备库流程

• 环境验证与角色转换：故障主机修复后，验证原 DB2 实例可用性。无需重新安装实例，直接将其角色由“生产”调整为“备份”；
• IP 地址调整：修改原主库服务器 IP 地址为 x.x.x.x，以适配备库角色。：

yast lan
# 在 YaST 网络配置界面将 IP 修改为 x.x.x.x 并保存生效

• 数据基线同步（Restore）：从当前生产库（y.y.y.y）进行一次最新全量备份，在原主库服务器上执行 restore 恢复，建立新的同步基线；
• 传输应用链路重建：将原有的日志应用、清理等脚本移植/配置到该服务器，重新建立从 y.y.y.y 到 x.x.x.x 的归档日志传输链路。重要变更评估要求：如需对上述两台灾备相关服务器或其所在虚拟化/存储/网络环境执行重大变更（如 ESXi 主机迁移、存储重构、网络/VLAN 调整、操作系统或 DB2 升级等），须提前由我方进行灾备影响评估和审核，确保相关操作不会引起备份链路或日志传输链路中断，避免灾备能力失效；
• 后续能力提升建议：在现有主备 + 归档日志灾备架构基础上，如对 RTO/RPO 有更高要求或需要更细粒度的时间点恢复能力，建议评估采购支持 CDP（持续数据保护）的第三方数据保护工具，与本方案协同使用。