企业官网建设流程全解析

简介：一份面向税务及企业级数据中心的数据级灾备项目建设方案文档，适合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_SID=zhenguan 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_CLIENT=dbprod01, NB_ORA_SERV=backup01)'; ALLOCATE CHANNEL c2 DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_CLIENT=dbprod01, NB_ORA_SERV=backup01)'; 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 2>&1。备份日志里出现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. 容灾端只读激活与一致性演练技巧

做灾备演练的方式决定了它会不会被业务部门排斥。破坏性演练要停复制、拉库、切应用，对生产影响风险大，周期也长。更实用的做法是定期做"只读激活"演练，在不打断生产复制的前提下，验证容灾端数据可读、可用。

具体操作流程：

1. 在阵列管理界面挂起异步复制关系，等待复制状态进入consistent；
2. 将容灾端复制卷以只读方式映射给一台测试主机；
3. 在测试主机上只读导入卷组：先执行varyonvg -r datavg，再mount -o ro挂载文件系统；
4. 检查关键数据文件、控制文件和归档日志是否在最近同步点，记录同步滞后时间；
5. 检查完成后卸载文件系统、关闭卷组、恢复复制关系，阵列会自动回补演练期间积累的增量。

验证命令如下：

# 只读激活卷组并挂载文件系统 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 blocksize=8192

dbv返回DBVERIFY - Verification complete说明文件物理块没有损坏。这个演练每次耗时约1小时，却能覆盖最大的风险点：链路中断、卷映射错误、复制关系意外挂起。每季度再挑一个非核心业务做完整拉起演练，从挂起复制到数据库可查询，记录实际耗时，和RTO估计值对比。如果连续两次超过目标，就要检查容灾主机的CPU和存储链路是否成为瓶颈。演练完成后马上在备份软件里查最近一次的备份日志，确认演练期间积累的增量数据已经重新同步完。只读激活虽然不写数据，但卷组状态的变化有时会影响后续复制关系，这一步能避免演练变成下一次事故的诱因。

本文还有配套的精品资源，点击获取