简介一份面向税务及企业级数据中心的数据级灾备项目建设方案文档适合IT架构师、运维及灾备规划人员参考。内容系统覆盖项目分析、国际灾备级别、国税总局灾备调研、详细需求分析及技术指标针对征管数据库等重要生产系统给出基于磁盘阵列的远程数据复制、跨100公里容灾中心12Mb/s链路同步、SAN/LAN双模式备份、在线备份与系统镜像恢复等完整设计并对RTO/RPO、备份频率等关键指标提出具体规划建议同时强调不改变现有系统架构以降低实施风险。全文共95页以单个docx格式提供压缩包3.87MB结构完整、层次清晰可直接作为同类项目方案编写与汇报的参考模板。该文档已有1326人学习具备较高参考价值。1. 从SHARE 78分级到Tier 6选型异地灾备的边界怎么定数据大集中之后灾备方案的第一个问题不是买多大盘阵而是确认容灾级别。SHARE 78把灾备分为Tier 0到Tier 6七级Tier 0只做本地备份数据中心整体失效时无能为力Tier 6做到零数据丢失恢复时间分钟级成本也最高。多数项目最后用核心生产库按Tier 6、非生产数据按Tier 2/3的分级方式收口。这份95页的省级数据灾备建设方案对正在做灾备项目立项的运维团队和DBA来说最有价值的不是存储品牌选型而是如何把RPO/RTO、链路带宽、备份窗口这些参数落到可执行设计里。边界定清楚后面的存储规划、备份策略、演练频次才有依据。2. 备份管理系统四层架构与零改动接入约束2.1 存储虚拟化层先把异构存储统一起来省级数据中心通常有多个历史时期建成的存储系统盘阵型号、固件和厂商接口各不相同。如果备份系统直接依赖某一台阵列的私有复制功能后续扩容和更换设备都会被卡住。方案里把存储虚拟化层放在最底层就是为了屏蔽这些差异让上层应用只看到逻辑存储资源不用关心物理盘阵是谁家的。存储虚拟化层还要承载远程同步、远程异步传输和本地存储空间镜像。这样可以做到在异构盘阵之间复制数据而不是只在同一厂商设备之间复制。对运维团队来说这一层选型时要重点关注是否支持一致性组。一致性组保证多个逻辑卷在同一个时间点被打快照或复制数据库的数据文件和控制文件在一个复制周期内处于一致状态否则灾备端恢复时文件时间点对不上库永远起不来。存储虚拟化实现上分服务器级、存储设备级、网络级三种。服务器级虚拟化依赖主机上的卷管理器实施简单但消耗主机资源存储设备级虚拟化通常在阵列内部完成对主机透明网络级虚拟化需要专门的虚拟化网关适合做多厂商存储统一管理。灾备方案里一般混合使用远程复制交给阵列引擎或虚拟化网关备份介质服务器上的磁盘管理用卷管理器就够了。2.2 存储管理层和调度层把备份恢复固化成策略存储管理层覆盖备份/恢复、归档/检索、迁移/调回、灾难备份、操作系统备份恢复。换句话说日常说的备份系统只是四层中的一层方案设计时这一层要同时考虑数据生命周期在线数据、近线数据、离线归档数据在什么时间点迁移不是等磁盘满了才想起来。管理层同时负责统一的设备/网络管理存储资源池的容量情况、磁带库的驱动器状态都要在这里汇总。调度层把运维动作变成自动化工作流。一个典型的例子是备份作业完成后自动做校验校验通过才清理本地归档日志这样能把人为误操作从备份链路里拿掉。调度层还要和现有监控平台做事件关联分析。备份失败的原因可能是生产阵列I/O延迟过高也可能是介质服务器磁带机脏了分开看告警会漏掉根因。方案里要求的不只是备份软件本身是一个能跟现有工单、监控联动的恢复体系。四层架构的职责边界可以按下表拆解选型时按表逐项打勾| 层次 | 职责范围 | 落地模块 | | 存储虚拟化层 | 异构存储统一、远程复制、空间镜像 | 虚拟化网关/阵列引擎 | | 存储管理层 | 备份恢复、归档检索、迁移调回 | 备份服务器/介质服务器 | | 存储调度层 | 策略编排、自动化作业、事件关联 | 作业调度引擎 | | 系统管理集成层 | 与监控、告警、工单系统联动 | API/事件接口 |2.3 三个不动约束下的接入方式方案明确要求不修改服务器操作系统、不改变集群配置和卷管理器/文件系统设置、不改变光纤网络设备运行状态。这条约束把备份系统的接入方式限定为旁路式。常见做法是在SAN交换机上划分独立zone把备份介质服务器接入存储网络但生产主机和阵列的既有zone完全不动生产主机安装备份代理数据读取走SAN路径控制消息走备份网络或管理网备份策略只定义在备份服务器上生产端不增加任何自启动任务。备份介质服务器上注册磁带库或磁盘存储单元时以NBU风格命令为例# 在备份介质服务器上注册磁带库存储单元 # -storage_unit 备份软件内部存储单元名 # -media_server 归属的介质服务器 # -device_path 磁带机SCSI设备路径配错会导致挂载介质失败 # -robotic_path 机械手设备路径配错会无法自动换带 tpconfig -add -storage_unit bk_library \ -media_server backup01 \ -device_host backup01 \ -device_path /dev/sg5 \ -robotic_path /dev/sg6这条命令的作用是告诉备份软件这台介质服务器上有一台磁带库驱动器在/dev/sg5机械手在/dev/sg6。生产环境接入时不要手工逐台添加先用备份软件自带的设备发现功能扫描一遍再手工微调路径。设备路径在AIX或Linux下可能因重启变化建议结合多路径软件的持久化绑定固定名称。3. SAN/LAN备份模式与数据库在线复制作业编排3.1 按数据类型选择备份数据路径方案要求同时支持SAN和LAN两种模式。SAN备份是数据库或文件系统数据通过光纤通道直接写入备份设备不经过业务以太网LAN备份是数据通过以太网传到备份介质服务器再写库。对征管数据库这类核心系统SAN备份是首选备份流量不占业务网络带宽也不容易被交换机拥塞影响。| 对比项 | SAN备份 | LAN备份 | | 数据路径 | FC存储网络 | 以太网 | | 对业务网络影响 | 基本无 | 占用带宽 | | 适合场景 | 数据库、虚拟机、大文件 | 小型业务系统、文件服务 | | 恢复速度 | 快 | 受网络限制 | | 接入条件 | 需要HBA和FC交换机zone | 现网即可 |这个选择不要光看纸面参数。实施时先在备份介质服务器上做一次全网的SAN路径扫描确认生产主机到介质服务器的FC路径数和实际带宽再按路径数分配并发通道。很多项目在规划阶段就定下SAN备份实施时才发现介质服务器的FC端口只有两个并发通道一多就排队。3.2 数据库在线备份脚本与窗口控制数据库在线备份的核心是不停库。以Oracle环境为例RMAN的SBT接口把备份数据交给备份软件由介质服务器决定写到磁盘还是磁带。这样数据库实例只负责把数据块读出来备份动作保持在线状态。#!/bin/bash # 征管生产库在线全量备份每周日01:00执行 export ORACLE_SIDzhenguan export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH rman target / EOF RUN { ALLOCATE CHANNEL c1 DEVICE TYPE SBT_TAPE PARMS ENV(NB_ORA_CLIENTdbprod01, NB_ORA_SERVbackup01); ALLOCATE CHANNEL c2 DEVICE TYPE SBT_TAPE PARMS ENV(NB_ORA_CLIENTdbprod01, NB_ORA_SERVbackup01); BACKUP INCREMENTAL LEVEL 0 DATABASE INCLUDE CURRENT CONTROLFILE PLUS ARCHIVELOG DELETE INPUT; RELEASE CHANNEL c1; RELEASE CHANNEL c2; } EOF脚本里的动作分三部分理解。ALLOCATE CHANNEL c1/c2是分配两条并行备份通道NB_ORA_CLIENT是数据库注册在备份软件里的客户端名NB_ORA_SERV是备份服务器名这两个参数必须与备份软件里的配置一致否则通道分配失败。INCREMENTAL LEVEL 0是全量备份作为后续增量恢复的基线INCLUDE CURRENT CONTROLFILE把当前控制文件放进备份集避免单独备份控制文件时遗漏。PLUS ARCHIVELOG DELETE INPUT表示在备份数据库的同时备份归档日志并删除本地已备份的归档防止归档目录写满。调度用crontab固定窗口0 1 * * 0 /opt/scripts/db_full_backup.sh /var/log/db_backup.log 21。备份日志里出现ORA-19506或ORA-19511时优先查看介质服务器上的备份进程日志多半是磁带设备或通道参数问题而不是数据库本身故障。3.3 100公里12Mb/s链路下的远程复制设计方案指定容灾中心在100公里外链路带宽12Mb/s。这个带宽对同步远程复制来说基本不可行100公里光纤单向延迟约0.5ms一个写IO要等远端确认生产库的每次提交都会被拖慢。所以生产数据库的远程复制只能做异步RPO控制在秒级到分钟级。12Mb/s的理论带宽是1.5MB/s扣除协议开销和TCP重传后有效吞吐按1MB/s估算比较安全。日增数据量和传输时间的关系如下表| 日增数据量 | 估算传输时间 | 夜间6小时窗口是否够用 | | 5GB | 约85分钟 | 够 | | 20GB | 约5.6小时 | 勉强够 | | 40GB | 约11小时 | 不够需要压缩或缩短周期 |如果日增量超过20GB常见处理是打开远程复制软件的压缩传输或者只复制数据文件增量而不是整卷。压缩对数据库数据文件的收益一般能到30%-50%。这些量化结果要写进设计方案作为链路带宽升级或复制策略调整的依据。异步复制的一致性靠一致性组保证阵列上要把数据库数据卷和日志卷放进同一个一致性组否则容灾端恢复时数据文件和控制文件不在同一时间点。4. RPO/RTO目标分解与备份恢复策略参数化4.1 按数据类别拆分RPO/RTO一份灾备方案不能把所有数据都按同一个RPO/RTO口径设计。核心数据库、SAN环境重要数据、LAN环境业务系统、历史归档数据的容忍度完全不同。建议按下面这张表拆解| 数据类别 | 保护方式 | RPO | RTO | | 征管数据库生产 | 阵列异步远程复制 | 秒级 | ≤4小时 | | SAN环境重要数据 | 数据库在线备份远程复制 | ≤15分钟 | ≤6小时 | | LAN环境业务系统 | 备份软件跨链路复制 | ≤24小时 | ≤1个工作日 | | 历史归档数据 | 磁带/电子传送 | 天级 | 按需恢复 |这张表的好处是把要求高可用和要求可恢复分开。生产库RPO定秒级意味着靠远程复制历史归档RPO定天级靠批量传输。指标写进合同后验收时才能明确测什么不会出现业务部门按零丢失要求、建设方按每日备份交付各说各话的情况。4.2 备份周期与保留策略备份策略回答三个问题多久备一次、保留多久、放在哪里。下面是项目里典型的一套参数| 备份作业 | 频率 | 保留期 | 存放位置 | | 数据库全备 | 每周日01:00 | 4周 | 本地磁带库容灾中心 | | 数据库增量备份 | 周一至六01:00 | 2周 | 本地磁带库 | | 归档日志备份 | 每切换或每小时 | 7天 | 本地磁盘容灾中心 | | 操作系统镜像 | 每月一次 | 6个月 | 容灾中心 |保留期不是越长越好。全备保留4周加归档日志保留7天可以恢复到最近7天内任意时间点要恢复到一个月前的状态依赖周备磁带。操作系统镜像保留6个月是为了应对系统级损坏时的重建不依赖数据库日志单独保留更灵活。实际项目里保留参数要结合磁带库槽位数和备份容量重新算否则存储很快会被撑满。备份数据本身也需要验证。每周全备结束后从备份软件里挑选一个业务库做抽样恢复测试恢复到一个隔离的测试实例上确认数据文件和控制文件时间点一致。归档日志备份如果连续三天没有生成说明数据库可能没有开启归档模式或者日志传输中断要立即检查否则恢复点会回退到上一次归档备份。4.3 恢复操作顺序从复制卷激活到数据库拉起灾难发生时容灾端的操作顺序决定RTO能不能达标。以AIX环境为例常见恢复流程是挂起阵列远程复制关系将复制卷映射给容灾主机导入卷组启动数据库到mount状态做检查。# 容灾端识别远程复制映射过来的磁盘 lspv | grep -i remote # 导入生产端卷组卷组名必须与原环境一致 importvg -y datavg hdisk5 # 激活卷组并挂载数据文件所在文件系统 mount /dev/datavg/lv_data /oracle_data # 以mount方式启动数据库先确认数据文件状态 su - oracle -c sqlplus / as sysdba EOF startup mount; select name,status from v\$datafile; EOF这里有几个容易出错的地方。importvg的-y参数如果和原环境卷组名不一致数据库参数文件里所有路径都要改恢复时间会大幅拉长所以容灾端的盘符和卷组规划要在建设期就固定下来。mount失败时不要急着反复挂载先执行lsvg datavg看卷组状态如果是closed状态要先varyonvg datavg。数据库启动到mount而不是open是因为异步复制可能落后生产端一小段时间需要先用v$recover_file检查是否有文件需要恢复再决定直接open还是recover。恢复顺序里有一个常见误区先启动数据库再挂文件系统。文件系统没挂载就启动数据库会报ORA-01157无法识别数据文件回退后重新挂载白白浪费几分钟。恢复窗口是按分钟计的操作顺序应该提前固化到预案文档里不能靠现场临场判断。5. 容灾端只读激活与一致性演练技巧做灾备演练的方式决定了它会不会被业务部门排斥。破坏性演练要停复制、拉库、切应用对生产影响风险大周期也长。更实用的做法是定期做只读激活演练在不打断生产复制的前提下验证容灾端数据可读、可用。具体操作流程在阵列管理界面挂起异步复制关系等待复制状态进入consistent将容灾端复制卷以只读方式映射给一台测试主机在测试主机上只读导入卷组先执行varyonvg -r datavg再mount -o ro挂载文件系统检查关键数据文件、控制文件和归档日志是否在最近同步点记录同步滞后时间检查完成后卸载文件系统、关闭卷组、恢复复制关系阵列会自动回补演练期间积累的增量。验证命令如下# 只读激活卷组并挂载文件系统 varyonvg -r datavg mount -o ro /dev/datavg/lv_data /mnt/dr_check # 检查数据库数据文件是否可读且大小正常 ls -l /mnt/dr_check/oradata/system01.dbf # 使用dbv校验单个数据文件物理块一致性 dbv file/mnt/dr_check/oradata/system01.dbf blocksize8192dbv返回DBVERIFY - Verification complete说明文件物理块没有损坏。这个演练每次耗时约1小时却能覆盖最大的风险点链路中断、卷映射错误、复制关系意外挂起。每季度再挑一个非核心业务做完整拉起演练从挂起复制到数据库可查询记录实际耗时和RTO估计值对比。如果连续两次超过目标就要检查容灾主机的CPU和存储链路是否成为瓶颈。演练完成后马上在备份软件里查最近一次的备份日志确认演练期间积累的增量数据已经重新同步完。只读激活虽然不写数据但卷组状态的变化有时会影响后续复制关系这一步能避免演练变成下一次事故的诱因。本文还有配套的精品资源点击获取 从SHARE 78到Tier 6：省级数据灾备建设方案设计要点
简介一份面向税务及企业级数据中心的数据级灾备项目建设方案文档适合IT架构师、运维及灾备规划人员参考。内容系统覆盖项目分析、国际灾备级别、国税总局灾备调研、详细需求分析及技术指标针对征管数据库等重要生产系统给出基于磁盘阵列的远程数据复制、跨100公里容灾中心12Mb/s链路同步、SAN/LAN双模式备份、在线备份与系统镜像恢复等完整设计并对RTO/RPO、备份频率等关键指标提出具体规划建议同时强调不改变现有系统架构以降低实施风险。全文共95页以单个docx格式提供压缩包3.87MB结构完整、层次清晰可直接作为同类项目方案编写与汇报的参考模板。该文档已有1326人学习具备较高参考价值。1. 从SHARE 78分级到Tier 6选型异地灾备的边界怎么定数据大集中之后灾备方案的第一个问题不是买多大盘阵而是确认容灾级别。SHARE 78把灾备分为Tier 0到Tier 6七级Tier 0只做本地备份数据中心整体失效时无能为力Tier 6做到零数据丢失恢复时间分钟级成本也最高。多数项目最后用核心生产库按Tier 6、非生产数据按Tier 2/3的分级方式收口。这份95页的省级数据灾备建设方案对正在做灾备项目立项的运维团队和DBA来说最有价值的不是存储品牌选型而是如何把RPO/RTO、链路带宽、备份窗口这些参数落到可执行设计里。边界定清楚后面的存储规划、备份策略、演练频次才有依据。2. 备份管理系统四层架构与零改动接入约束2.1 存储虚拟化层先把异构存储统一起来省级数据中心通常有多个历史时期建成的存储系统盘阵型号、固件和厂商接口各不相同。如果备份系统直接依赖某一台阵列的私有复制功能后续扩容和更换设备都会被卡住。方案里把存储虚拟化层放在最底层就是为了屏蔽这些差异让上层应用只看到逻辑存储资源不用关心物理盘阵是谁家的。存储虚拟化层还要承载远程同步、远程异步传输和本地存储空间镜像。这样可以做到在异构盘阵之间复制数据而不是只在同一厂商设备之间复制。对运维团队来说这一层选型时要重点关注是否支持一致性组。一致性组保证多个逻辑卷在同一个时间点被打快照或复制数据库的数据文件和控制文件在一个复制周期内处于一致状态否则灾备端恢复时文件时间点对不上库永远起不来。存储虚拟化实现上分服务器级、存储设备级、网络级三种。服务器级虚拟化依赖主机上的卷管理器实施简单但消耗主机资源存储设备级虚拟化通常在阵列内部完成对主机透明网络级虚拟化需要专门的虚拟化网关适合做多厂商存储统一管理。灾备方案里一般混合使用远程复制交给阵列引擎或虚拟化网关备份介质服务器上的磁盘管理用卷管理器就够了。2.2 存储管理层和调度层把备份恢复固化成策略存储管理层覆盖备份/恢复、归档/检索、迁移/调回、灾难备份、操作系统备份恢复。换句话说日常说的备份系统只是四层中的一层方案设计时这一层要同时考虑数据生命周期在线数据、近线数据、离线归档数据在什么时间点迁移不是等磁盘满了才想起来。管理层同时负责统一的设备/网络管理存储资源池的容量情况、磁带库的驱动器状态都要在这里汇总。调度层把运维动作变成自动化工作流。一个典型的例子是备份作业完成后自动做校验校验通过才清理本地归档日志这样能把人为误操作从备份链路里拿掉。调度层还要和现有监控平台做事件关联分析。备份失败的原因可能是生产阵列I/O延迟过高也可能是介质服务器磁带机脏了分开看告警会漏掉根因。方案里要求的不只是备份软件本身是一个能跟现有工单、监控联动的恢复体系。四层架构的职责边界可以按下表拆解选型时按表逐项打勾| 层次 | 职责范围 | 落地模块 | | 存储虚拟化层 | 异构存储统一、远程复制、空间镜像 | 虚拟化网关/阵列引擎 | | 存储管理层 | 备份恢复、归档检索、迁移调回 | 备份服务器/介质服务器 | | 存储调度层 | 策略编排、自动化作业、事件关联 | 作业调度引擎 | | 系统管理集成层 | 与监控、告警、工单系统联动 | API/事件接口 |2.3 三个不动约束下的接入方式方案明确要求不修改服务器操作系统、不改变集群配置和卷管理器/文件系统设置、不改变光纤网络设备运行状态。这条约束把备份系统的接入方式限定为旁路式。常见做法是在SAN交换机上划分独立zone把备份介质服务器接入存储网络但生产主机和阵列的既有zone完全不动生产主机安装备份代理数据读取走SAN路径控制消息走备份网络或管理网备份策略只定义在备份服务器上生产端不增加任何自启动任务。备份介质服务器上注册磁带库或磁盘存储单元时以NBU风格命令为例# 在备份介质服务器上注册磁带库存储单元 # -storage_unit 备份软件内部存储单元名 # -media_server 归属的介质服务器 # -device_path 磁带机SCSI设备路径配错会导致挂载介质失败 # -robotic_path 机械手设备路径配错会无法自动换带 tpconfig -add -storage_unit bk_library \ -media_server backup01 \ -device_host backup01 \ -device_path /dev/sg5 \ -robotic_path /dev/sg6这条命令的作用是告诉备份软件这台介质服务器上有一台磁带库驱动器在/dev/sg5机械手在/dev/sg6。生产环境接入时不要手工逐台添加先用备份软件自带的设备发现功能扫描一遍再手工微调路径。设备路径在AIX或Linux下可能因重启变化建议结合多路径软件的持久化绑定固定名称。3. SAN/LAN备份模式与数据库在线复制作业编排3.1 按数据类型选择备份数据路径方案要求同时支持SAN和LAN两种模式。SAN备份是数据库或文件系统数据通过光纤通道直接写入备份设备不经过业务以太网LAN备份是数据通过以太网传到备份介质服务器再写库。对征管数据库这类核心系统SAN备份是首选备份流量不占业务网络带宽也不容易被交换机拥塞影响。| 对比项 | SAN备份 | LAN备份 | | 数据路径 | FC存储网络 | 以太网 | | 对业务网络影响 | 基本无 | 占用带宽 | | 适合场景 | 数据库、虚拟机、大文件 | 小型业务系统、文件服务 | | 恢复速度 | 快 | 受网络限制 | | 接入条件 | 需要HBA和FC交换机zone | 现网即可 |这个选择不要光看纸面参数。实施时先在备份介质服务器上做一次全网的SAN路径扫描确认生产主机到介质服务器的FC路径数和实际带宽再按路径数分配并发通道。很多项目在规划阶段就定下SAN备份实施时才发现介质服务器的FC端口只有两个并发通道一多就排队。3.2 数据库在线备份脚本与窗口控制数据库在线备份的核心是不停库。以Oracle环境为例RMAN的SBT接口把备份数据交给备份软件由介质服务器决定写到磁盘还是磁带。这样数据库实例只负责把数据块读出来备份动作保持在线状态。#!/bin/bash # 征管生产库在线全量备份每周日01:00执行 export ORACLE_SIDzhenguan export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH rman target / EOF RUN { ALLOCATE CHANNEL c1 DEVICE TYPE SBT_TAPE PARMS ENV(NB_ORA_CLIENTdbprod01, NB_ORA_SERVbackup01); ALLOCATE CHANNEL c2 DEVICE TYPE SBT_TAPE PARMS ENV(NB_ORA_CLIENTdbprod01, NB_ORA_SERVbackup01); BACKUP INCREMENTAL LEVEL 0 DATABASE INCLUDE CURRENT CONTROLFILE PLUS ARCHIVELOG DELETE INPUT; RELEASE CHANNEL c1; RELEASE CHANNEL c2; } EOF脚本里的动作分三部分理解。ALLOCATE CHANNEL c1/c2是分配两条并行备份通道NB_ORA_CLIENT是数据库注册在备份软件里的客户端名NB_ORA_SERV是备份服务器名这两个参数必须与备份软件里的配置一致否则通道分配失败。INCREMENTAL LEVEL 0是全量备份作为后续增量恢复的基线INCLUDE CURRENT CONTROLFILE把当前控制文件放进备份集避免单独备份控制文件时遗漏。PLUS ARCHIVELOG DELETE INPUT表示在备份数据库的同时备份归档日志并删除本地已备份的归档防止归档目录写满。调度用crontab固定窗口0 1 * * 0 /opt/scripts/db_full_backup.sh /var/log/db_backup.log 21。备份日志里出现ORA-19506或ORA-19511时优先查看介质服务器上的备份进程日志多半是磁带设备或通道参数问题而不是数据库本身故障。3.3 100公里12Mb/s链路下的远程复制设计方案指定容灾中心在100公里外链路带宽12Mb/s。这个带宽对同步远程复制来说基本不可行100公里光纤单向延迟约0.5ms一个写IO要等远端确认生产库的每次提交都会被拖慢。所以生产数据库的远程复制只能做异步RPO控制在秒级到分钟级。12Mb/s的理论带宽是1.5MB/s扣除协议开销和TCP重传后有效吞吐按1MB/s估算比较安全。日增数据量和传输时间的关系如下表| 日增数据量 | 估算传输时间 | 夜间6小时窗口是否够用 | | 5GB | 约85分钟 | 够 | | 20GB | 约5.6小时 | 勉强够 | | 40GB | 约11小时 | 不够需要压缩或缩短周期 |如果日增量超过20GB常见处理是打开远程复制软件的压缩传输或者只复制数据文件增量而不是整卷。压缩对数据库数据文件的收益一般能到30%-50%。这些量化结果要写进设计方案作为链路带宽升级或复制策略调整的依据。异步复制的一致性靠一致性组保证阵列上要把数据库数据卷和日志卷放进同一个一致性组否则容灾端恢复时数据文件和控制文件不在同一时间点。4. RPO/RTO目标分解与备份恢复策略参数化4.1 按数据类别拆分RPO/RTO一份灾备方案不能把所有数据都按同一个RPO/RTO口径设计。核心数据库、SAN环境重要数据、LAN环境业务系统、历史归档数据的容忍度完全不同。建议按下面这张表拆解| 数据类别 | 保护方式 | RPO | RTO | | 征管数据库生产 | 阵列异步远程复制 | 秒级 | ≤4小时 | | SAN环境重要数据 | 数据库在线备份远程复制 | ≤15分钟 | ≤6小时 | | LAN环境业务系统 | 备份软件跨链路复制 | ≤24小时 | ≤1个工作日 | | 历史归档数据 | 磁带/电子传送 | 天级 | 按需恢复 |这张表的好处是把要求高可用和要求可恢复分开。生产库RPO定秒级意味着靠远程复制历史归档RPO定天级靠批量传输。指标写进合同后验收时才能明确测什么不会出现业务部门按零丢失要求、建设方按每日备份交付各说各话的情况。4.2 备份周期与保留策略备份策略回答三个问题多久备一次、保留多久、放在哪里。下面是项目里典型的一套参数| 备份作业 | 频率 | 保留期 | 存放位置 | | 数据库全备 | 每周日01:00 | 4周 | 本地磁带库容灾中心 | | 数据库增量备份 | 周一至六01:00 | 2周 | 本地磁带库 | | 归档日志备份 | 每切换或每小时 | 7天 | 本地磁盘容灾中心 | | 操作系统镜像 | 每月一次 | 6个月 | 容灾中心 |保留期不是越长越好。全备保留4周加归档日志保留7天可以恢复到最近7天内任意时间点要恢复到一个月前的状态依赖周备磁带。操作系统镜像保留6个月是为了应对系统级损坏时的重建不依赖数据库日志单独保留更灵活。实际项目里保留参数要结合磁带库槽位数和备份容量重新算否则存储很快会被撑满。备份数据本身也需要验证。每周全备结束后从备份软件里挑选一个业务库做抽样恢复测试恢复到一个隔离的测试实例上确认数据文件和控制文件时间点一致。归档日志备份如果连续三天没有生成说明数据库可能没有开启归档模式或者日志传输中断要立即检查否则恢复点会回退到上一次归档备份。4.3 恢复操作顺序从复制卷激活到数据库拉起灾难发生时容灾端的操作顺序决定RTO能不能达标。以AIX环境为例常见恢复流程是挂起阵列远程复制关系将复制卷映射给容灾主机导入卷组启动数据库到mount状态做检查。# 容灾端识别远程复制映射过来的磁盘 lspv | grep -i remote # 导入生产端卷组卷组名必须与原环境一致 importvg -y datavg hdisk5 # 激活卷组并挂载数据文件所在文件系统 mount /dev/datavg/lv_data /oracle_data # 以mount方式启动数据库先确认数据文件状态 su - oracle -c sqlplus / as sysdba EOF startup mount; select name,status from v\$datafile; EOF这里有几个容易出错的地方。importvg的-y参数如果和原环境卷组名不一致数据库参数文件里所有路径都要改恢复时间会大幅拉长所以容灾端的盘符和卷组规划要在建设期就固定下来。mount失败时不要急着反复挂载先执行lsvg datavg看卷组状态如果是closed状态要先varyonvg datavg。数据库启动到mount而不是open是因为异步复制可能落后生产端一小段时间需要先用v$recover_file检查是否有文件需要恢复再决定直接open还是recover。恢复顺序里有一个常见误区先启动数据库再挂文件系统。文件系统没挂载就启动数据库会报ORA-01157无法识别数据文件回退后重新挂载白白浪费几分钟。恢复窗口是按分钟计的操作顺序应该提前固化到预案文档里不能靠现场临场判断。5. 容灾端只读激活与一致性演练技巧做灾备演练的方式决定了它会不会被业务部门排斥。破坏性演练要停复制、拉库、切应用对生产影响风险大周期也长。更实用的做法是定期做只读激活演练在不打断生产复制的前提下验证容灾端数据可读、可用。具体操作流程在阵列管理界面挂起异步复制关系等待复制状态进入consistent将容灾端复制卷以只读方式映射给一台测试主机在测试主机上只读导入卷组先执行varyonvg -r datavg再mount -o ro挂载文件系统检查关键数据文件、控制文件和归档日志是否在最近同步点记录同步滞后时间检查完成后卸载文件系统、关闭卷组、恢复复制关系阵列会自动回补演练期间积累的增量。验证命令如下# 只读激活卷组并挂载文件系统 varyonvg -r datavg mount -o ro /dev/datavg/lv_data /mnt/dr_check # 检查数据库数据文件是否可读且大小正常 ls -l /mnt/dr_check/oradata/system01.dbf # 使用dbv校验单个数据文件物理块一致性 dbv file/mnt/dr_check/oradata/system01.dbf blocksize8192dbv返回DBVERIFY - Verification complete说明文件物理块没有损坏。这个演练每次耗时约1小时却能覆盖最大的风险点链路中断、卷映射错误、复制关系意外挂起。每季度再挑一个非核心业务做完整拉起演练从挂起复制到数据库可查询记录实际耗时和RTO估计值对比。如果连续两次超过目标就要检查容灾主机的CPU和存储链路是否成为瓶颈。演练完成后马上在备份软件里查最近一次的备份日志确认演练期间积累的增量数据已经重新同步完。只读激活虽然不写数据但卷组状态的变化有时会影响后续复制关系这一步能避免演练变成下一次事故的诱因。本文还有配套的精品资源点击获取