互联网服务
AC研讨会第三期：灾难备份之灾备演练的重要性
AC研讨会第三期：灾难备份之灾备演练的重要性
研讨会主题简介：
在进入IT化的各个行业当中，所有行业对安全灾备无疑是最谨慎、最注重的。灾难备份是信息系统建设的一个重要内容。它的存在是系统运行的保障，也是维护行业发展稳定的必要措施。所以社区组织一场灾难备份之灾备演练的重要性方面的研讨会。让专家在线帮助大家共同解答和交流。
研讨会形式：社区会员可以先提出你在灾难备份中面临的问题，先抛出大家的问题，然后可以由专家或者社区中的高手都可以参与互动解答。目的就是要帮助大家解决遇到的相关问题。
研讨注意事项：社区会员尽可能要围绕主题来提出问题和讨论，别跑偏主题了
研讨会持续时间：2012年6月26日-2012年7月3日
集中研讨时间：7月3日，下午14：:00-16:00
研讨结束时会由主持专家颁发互动奖，奖品：
主持专家：孙伟光（论坛ID:myciciy)
目前在中国金融化电子公司（中国人民银行子公司）担任高级系统工程师一职，主要负责IBM Power小型机及Storage产品，AIX PowerHA PowerVM系统软件架构设计安装调试维护。现主要从事金融行业灾备系统方案设计，规划实施，云计算中心基础设施建设设计规划实施工作。
从2008年起，孙伟光一直担任【专家坐诊】等多个版块的版主，从《AIX中国》杂志创刊以来，一直是杂志的特邀作者。并两度晋级AIX高手挑战赛全国总决赛十强。
专业技术与特长：
1、熟练对IBM Power服务器安装和维护
2、熟练FastT系列(DS4000)系列存储安装调试配置
3、熟悉安装配置HACMP,有一定的维护和故障排错经验
4、熟悉EMC CX/CX3系列存储及光纤交换机的简单配置
5、对oracle db2数据库简单的安装配置
6、对Legato备份软件有一定的了解和使用
7、熟悉Linux(Suse 9/10)安装配置,Linux下VCS双机的安装配置
8、熟悉存储的基本概念原理及磁盘阵列基本结构(SAN NAS)
9、AIX高手挑战赛2008年赛第四名，AIX高手挑战赛2009年赛风云十强
10、《AIX中国》杂志特邀作者，AIX专家俱乐部论坛版主
推荐阅读：
AC研讨会第一期：基于Power 海量数据架构设计
http://www.aixchina.net/club/thread-79016-1-1.html
AC研讨会第二期：系统运维之故障处理
http://www.aixchina.net/club/thread-79305-1-1.html
研讨会主题简介：
在进入IT化的各个行业当中，所有行业对安全灾备无疑是最谨慎、最注重的。灾难备份是信息系统建设的一个重要内容。它的存在是系统运行的保障，也是维护行业发展稳定的必要措施。所以社区组织一场灾难备份之灾备演练的重要性方面的研讨会。让专家在线帮助大家共同解答和交流。
研讨会形式：社区会员可以先提出你在灾难备份中面临的问题，先抛出大家的问题，然后可以由专家或者社区中的高手都可以参与互动解答。目的就是要帮助大家解决遇到的相关问题。
研讨注意事项：社区会员尽可能要围绕主题来提出问题和讨论，别跑偏主题了
研讨会持续时间：2012年6月26日-2012年7月3日
集中研讨时间：7月3日，下午14：:00-16:00
研讨结束时会由主持专家颁发互动奖，奖品：
主持专家：孙伟光（论坛ID:myciciy)
目前在中国金融化电子公司（中国人民银行子公司）担任高级系统工程师一职，主要负责IBM Power小型机及Storage产品，AIX PowerHA PowerVM系统软件架构设计安装调试维护。现主要从事金融行业灾备系统方案设计，规划实施，云计算中心基础设施建设设计规划实施工作。
从2008年起，孙伟光一直担任【专家坐诊】等多个版块的版主，从《AIX中国》杂志创刊以来，一直是杂志的特邀作者。并两度晋级AIX高手挑战赛全国总决赛十强。
专业技术与特长：
1、熟练对IBM Power服务器安装和维护
2、熟练FastT系列(DS4000)系列存储安装调试配置
3、熟悉安装配置HACMP,有一定的维护和故障排错经验
4、熟悉EMC CX/CX3系列存储及光纤交换机的简单配置
5、对oracle db2数据库简单的安装配置
6、对Legato备份软件有一定的了解和使用
7、熟悉Linux(Suse 9/10)安装配置,Linux下VCS双机的安装配置
8、熟悉存储的基本概念原理及磁盘阵列基本结构(SAN NAS)
9、AIX高手挑战赛2008年赛第四名，AIX高手挑战赛2009年赛风云十强
10、《AIX中国》杂志特邀作者，AIX专家俱乐部论坛版主
推荐阅读：
AC研讨会第一期：基于Power 海量数据架构设计
http://www.aixchina.net/club/thread-79016-1-1.html
AC研讨会第二期：系统运维之故障处理
http://www.aixchina.net/club/thread-79305-1-1.html
0同行回答
“答”则兼济天下，请您为题主分忧！
演练的确很重要,但要真的定期做,是存在困难的.许多的基础工作还是要作的,不能因为有了灾备,进行简化甚至免除.
为减少灾备演练的抵触和花费,可以每次一个侧重点地进行,多次之后来一次临界演练,验证所有程序和常规准备情况,以发现问题.收起
为减少灾备演练的抵触和花费,可以每次一个侧重点地进行,多次之后来一次临界演练,验证所有程序和常规准备情况,以发现问题.收起
浏览617
灾备演练是检验灾备系统和灾难恢复团队的一个手段,组织一个好的灾备演练,首先要与组织的高层沟通,得到高层 ...FIGHT58588 发表于 2012-6-28 15:14
说得很好浏览574
浏览587
灾备演练是检验灾备系统和灾难恢复团队的一个手段,组织一个好的灾备演练,首先要与组织的高层沟通,得到高层的认可和支持,,然后制定本次演练的目标,范围,演练的方式以及灾难恢复的场景,并且与灾备演练所涉及的部门进行有效的沟通,制定演练计划.
对于演练的过程,国人习惯于制定详细的脚本,严格按照脚本进行演练,保障演练顺利进行,这样的好处是演练本身不会带来意外,但是不能对灾难恢复计划和灾备系统进行有效的检验;而在国外,多数企业级的演练更多的是检验灾难恢复计划和灾备系统的有效性,以及灾难恢复团队的熟练性收起
对于演练的过程,国人习惯于制定详细的脚本,严格按照脚本进行演练,保障演练顺利进行,这样的好处是演练本身不会带来意外,但是不能对灾难恢复计划和灾备系统进行有效的检验;而在国外,多数企业级的演练更多的是检验灾难恢复计划和灾备系统的有效性,以及灾难恢复团队的熟练性收起
浏览648
浏览639
说到灾备演练，有点大，说个小的，备份有效性验证，又一次一客户，误删了非核心生产数据，通过自己的备份恢复，既有备份软件备份又有本地备份，结果一恢复，傻眼了，备份的有问题，恢复不了，客户备份数据1年多，都没有发现自己备份的数据是否有效收起
浏览579
转帖
一、容灾项目需要多大的投资？
其实这个问题也可以被反问为：你希望容灾系统能达到什么效果？要想阐述清楚此问题，首先要明白两个指标：RTO和RPO。
RTO，Recover Time Object，恢复时间指标，是指当灾难发生后，生产系统需要多长时间能够恢复生产，它是衡量企业在灾难发生后多长时间能重新开始运转的指标。
RPO，Recover Point Object，恢复点指标，是指灾难发生后，容灾系统能把数据恢复到灾难发生前的哪一个时间点的数据，它是衡量企业在灾难发生后会丢失多少生产数据的指标。
理想状态下，我们希望RTO=0，RPO=0，即灾难发生对企业生产毫无影响，既不会导致生产停顿，也不会导致生产数据丢失。从当前计算机技术水平来说，我们可以为用户建设这种类型的容灾系统，其中最著名的例子当属VISA和Master的结算系统，由于这两个银行结算组织占据了全球银行结算业务的重要地位，他们的结算系统不允许发生任何停顿和数据丢失的情况，即使在"911"这种极端情况下。但实现这样的容灾系统的投资巨大，它结合了存储数据复制技术、服务器操作系统镜像技术、集群技术、数据库高可用性设计、应用系统高可用性设计、同步容灾技术、异步容灾技术、同城容灾方案、异地容灾方案，以及相应的管理流程和意外事件反映处理流程等详细的规章制度，和人员配备、行政保障手段（通信、交通等），综合在一起完成一个完整的容灾方案（实际是双生产中心或多生产中心方案，并没有单纯的容灾中心）。但是这种方案的投资过于巨大，目前中国可能除了中国银联这种特殊性质的企业外，不会有太多的企业会去实现这个系统。
因此，在电信企业BSS/OSS系统容灾系统建设中，投资规模为多少是合理的？如果业务部门能确认RTO/RPO指标，那技术部门选择了合适的容灾技术以及配套的管理流程就可以确定投资规模了。例如，如果业务部门确认，灾难发生后，3个小时内营业厅恢复生产就可以满足用户需求，且营业系统数据不能丢失，那RTO＝3小时，RPO＝0，那就必须选择基于存储平台数据复制技术的同步容灾方案；如果业务部门确认，灾难发生后，3天能恢复经营分析系统工作，且以前的数据丢失可以忽略不计，那RTO=3天，RPO无，那选择ATA磁盘实现异地备份，就能满足要求。
另外需要提的是，为了百年不遇的灾难投入巨资建设一个容灾中心，容灾中心的设备在灾难发生前不能给企业带来效益，这是企业决策者很难接受的，因此如何合理分配投资，将容灾中心建设成为第二生产中心，与生产中心成为企业支持企业正常运行的双中心，并实现互为容灾，是降低总体拥有成本（TCO，Total Cost of Ownership），提高投资回报率（ROI，Return Of Investment）的一个重要措施，应该得到企业的高度重视。
二、容灾项目对生产系统性能的影响
容灾系统的本质是将生产系统的数据以及这些数据的变化，完整地复制到容灾系统中，并通过相关技术手段，确保容灾系统中数据的完整性和一致性。容灾系统对生产数据和生产数据的变化的复制操作，必然需要与完成这些操作相对应的CPU资源（存储的CPU、或服务器的CPU）、内存资源（存储的Cache、或服务器的RAM）、网络资源（TCP/IP、FC或FICON），如果这些资源不能独立分配给容灾系统（实际上不可能独立），则必然会影响生产系统的性能。
因此更准确的问题是，如何确保容灾系统上线后，在可以实现既定的RTO/RPO指标的同时，不会影响生产系统的正常运行？答案是可以通过技术手段实现的。
要想实现，则必须对现有生产系统进行详细的性能分析，包括系统I/O特性（IOPS，Respond Time，读写比，I/O块大小，I/O峰值、均值，时间特性等等）、系统内各子系统业务特点、存储空间分配、服务器CPU和RAM资源的使用状况、SAN网络情况（端口使用状况、Zoning划分状况、端口IOPS等）、能够使用的数据复制链路（FC、TCP/IP、ATM、E1/E3）以及链路的QoS保障等。获得这些数据后，通过对容灾系统I/O分布的详细设计，将I/O均匀分布到更多的设备上，从而确保生产系统实现容灾后，不会造成性能下降影响正常生产的情况出现。
三、容灾不能替换备份
容灾系统会完整地把生产系统的任何变化复制到容灾端去，包括不想让它复制的工作，比如不小心把计费系统内的用户信息表删除了，同时容灾端的用户信息表也会被完整地删除。如果是同步容灾，那容灾端同时就删除了；如果是异步容灾，那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统中取出最新备份，来恢复被错误删除的信息。因此容灾系统的建设不能替代备份系统的建设。
反过来，建设了备份系统，是否就不需要容灾系统？这还要看业务部门对RTO/RPO指标的期望值，如果允许RTO＝14天，RPO＝1天，那备份系统就能满足要求。不过，可要考虑清楚了：从磁带上恢复50TB的数据，并要确保数据完整恢复回数据库，是否能在2周内完成？
四、选择什么容灾技术能保证项目实施成功？
容灾项目实施成功，与技术关系不大。能举出成功案例的容灾技术，则必有它的可行性。但作为一个工程师，除了考虑项目的可行性外，还要考虑项目的不可行性。任何技术的实现，都有它的制约条件。在自己的生产环境中，能否避免这些制约条件的出现？或者出现后，是否有资源可以解决它？
比如ORACLE在中国实施了一个基于DataGuard的容灾方案，但在实施过程中出现了大量意想不到的问题和BUG，作为对中国电信客户的重视，ORACLE甚至派遣R&D人员到现场编制PATCH以保证项目能实施，但这种资源，是否每个客户都能向ORACLE索取？
因此，选择一个简单的容灾方案，并选择一个曾经成功实施过该方案的工程团队，才是确保容灾项目实施成功的关键。收起
一、容灾项目需要多大的投资？
其实这个问题也可以被反问为：你希望容灾系统能达到什么效果？要想阐述清楚此问题，首先要明白两个指标：RTO和RPO。
RTO，Recover Time Object，恢复时间指标，是指当灾难发生后，生产系统需要多长时间能够恢复生产，它是衡量企业在灾难发生后多长时间能重新开始运转的指标。
RPO，Recover Point Object，恢复点指标，是指灾难发生后，容灾系统能把数据恢复到灾难发生前的哪一个时间点的数据，它是衡量企业在灾难发生后会丢失多少生产数据的指标。
理想状态下，我们希望RTO=0，RPO=0，即灾难发生对企业生产毫无影响，既不会导致生产停顿，也不会导致生产数据丢失。从当前计算机技术水平来说，我们可以为用户建设这种类型的容灾系统，其中最著名的例子当属VISA和Master的结算系统，由于这两个银行结算组织占据了全球银行结算业务的重要地位，他们的结算系统不允许发生任何停顿和数据丢失的情况，即使在"911"这种极端情况下。但实现这样的容灾系统的投资巨大，它结合了存储数据复制技术、服务器操作系统镜像技术、集群技术、数据库高可用性设计、应用系统高可用性设计、同步容灾技术、异步容灾技术、同城容灾方案、异地容灾方案，以及相应的管理流程和意外事件反映处理流程等详细的规章制度，和人员配备、行政保障手段（通信、交通等），综合在一起完成一个完整的容灾方案（实际是双生产中心或多生产中心方案，并没有单纯的容灾中心）。但是这种方案的投资过于巨大，目前中国可能除了中国银联这种特殊性质的企业外，不会有太多的企业会去实现这个系统。
因此，在电信企业BSS/OSS系统容灾系统建设中，投资规模为多少是合理的？如果业务部门能确认RTO/RPO指标，那技术部门选择了合适的容灾技术以及配套的管理流程就可以确定投资规模了。例如，如果业务部门确认，灾难发生后，3个小时内营业厅恢复生产就可以满足用户需求，且营业系统数据不能丢失，那RTO＝3小时，RPO＝0，那就必须选择基于存储平台数据复制技术的同步容灾方案；如果业务部门确认，灾难发生后，3天能恢复经营分析系统工作，且以前的数据丢失可以忽略不计，那RTO=3天，RPO无，那选择ATA磁盘实现异地备份，就能满足要求。
另外需要提的是，为了百年不遇的灾难投入巨资建设一个容灾中心，容灾中心的设备在灾难发生前不能给企业带来效益，这是企业决策者很难接受的，因此如何合理分配投资，将容灾中心建设成为第二生产中心，与生产中心成为企业支持企业正常运行的双中心，并实现互为容灾，是降低总体拥有成本（TCO，Total Cost of Ownership），提高投资回报率（ROI，Return Of Investment）的一个重要措施，应该得到企业的高度重视。
二、容灾项目对生产系统性能的影响
容灾系统的本质是将生产系统的数据以及这些数据的变化，完整地复制到容灾系统中，并通过相关技术手段，确保容灾系统中数据的完整性和一致性。容灾系统对生产数据和生产数据的变化的复制操作，必然需要与完成这些操作相对应的CPU资源（存储的CPU、或服务器的CPU）、内存资源（存储的Cache、或服务器的RAM）、网络资源（TCP/IP、FC或FICON），如果这些资源不能独立分配给容灾系统（实际上不可能独立），则必然会影响生产系统的性能。
因此更准确的问题是，如何确保容灾系统上线后，在可以实现既定的RTO/RPO指标的同时，不会影响生产系统的正常运行？答案是可以通过技术手段实现的。
要想实现，则必须对现有生产系统进行详细的性能分析，包括系统I/O特性（IOPS，Respond Time，读写比，I/O块大小，I/O峰值、均值，时间特性等等）、系统内各子系统业务特点、存储空间分配、服务器CPU和RAM资源的使用状况、SAN网络情况（端口使用状况、Zoning划分状况、端口IOPS等）、能够使用的数据复制链路（FC、TCP/IP、ATM、E1/E3）以及链路的QoS保障等。获得这些数据后，通过对容灾系统I/O分布的详细设计，将I/O均匀分布到更多的设备上，从而确保生产系统实现容灾后，不会造成性能下降影响正常生产的情况出现。
三、容灾不能替换备份
容灾系统会完整地把生产系统的任何变化复制到容灾端去，包括不想让它复制的工作，比如不小心把计费系统内的用户信息表删除了，同时容灾端的用户信息表也会被完整地删除。如果是同步容灾，那容灾端同时就删除了；如果是异步容灾，那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统中取出最新备份，来恢复被错误删除的信息。因此容灾系统的建设不能替代备份系统的建设。
反过来，建设了备份系统，是否就不需要容灾系统？这还要看业务部门对RTO/RPO指标的期望值，如果允许RTO＝14天，RPO＝1天，那备份系统就能满足要求。不过，可要考虑清楚了：从磁带上恢复50TB的数据，并要确保数据完整恢复回数据库，是否能在2周内完成？
四、选择什么容灾技术能保证项目实施成功？
容灾项目实施成功，与技术关系不大。能举出成功案例的容灾技术，则必有它的可行性。但作为一个工程师，除了考虑项目的可行性外，还要考虑项目的不可行性。任何技术的实现，都有它的制约条件。在自己的生产环境中，能否避免这些制约条件的出现？或者出现后，是否有资源可以解决它？
比如ORACLE在中国实施了一个基于DataGuard的容灾方案，但在实施过程中出现了大量意想不到的问题和BUG，作为对中国电信客户的重视，ORACLE甚至派遣R&D人员到现场编制PATCH以保证项目能实施，但这种资源，是否每个客户都能向ORACLE索取？
因此，选择一个简单的容灾方案，并选择一个曾经成功实施过该方案的工程团队，才是确保容灾项目实施成功的关键。收起
浏览628
浏览615
