灾难恢复

灾难恢复是在安全规划中保护企业免受重大负面事件影响的领域。重大负面事件包括任何可能造成业务风险的事件 事情。在信息技术领域，灾难恢复步骤包括恢复服务器或备份主机、用户交换机（PBX）重建或提供局域网（LAN）来 满足当前的业务需求。 中文名 灾难恢复 外文名 disaster recovery 本 质 恢复正常的商业运作过程。 要 求 评估机构的灾难性风险 实施步骤 选择数据中心地址。 目录 1 灾难恢复的概念 2 虚拟化灾难恢复 .准备建设灾难恢复站 .灾难恢复站建设实施 .虚拟化在灾难恢复中的作用 .灾难恢复的复杂性分析 3 灾难恢复计划 .如何制定灾难恢复计划 .灾难恢复服务选项 .当云端成为一个风暴 4 实现VDI灾难恢复的四种方式 .Hyper-V的灾难恢复 .Windows To Go的灾难恢复 .储存同步灾难恢复 .离线虚拟桌面的灾难恢复 5 灾难恢复的现状 6 灾害恢复能力评估 7 灾害恢复能力的发展 灾难恢复的概念 本文讲述了信息技术和管理的概念。关于人类事故和急救，详见灾难应对。 灾害恢复是指自然或人为灾害后重新启用信息系统的数据、硬件和软件设备，恢复正常业务运行的过程。灾害恢复规则 规划是业务连续规划范围较广的一部分，其核心是评估和预防企业或机构的灾难性风险，特别是关键业务数量 及时记录、备份和保护流程。 虚拟化灾难恢复 虚拟化提供了革命性的灾难恢复计划，允许虚拟机在物理服务器之间无缝迁移。 准备建设灾难恢复站 构建远程VMware在灾难恢复站之前，有许多问题需要考虑。 检查现有的基础设施。在完全明确主要数据中心的资产之前，不能复制。 了解应用程序及其依赖性。明确哪些应用程序需要抵御灾难。考虑存储和网络(主站和备份站) 即使在不同的环境下，架构之间的任何潜在差异也可以确保程序将故障转移到备份站。 建立恢复点目标（RPO）恢复时间目标(RTO)。 如果数据每小时复制到第二数据中心，灾难发生时最多可能会丢失 59分59秒的数据丢失。如果这是可以接受的，不会严重影响业务，那么PTO可设定为一小时。 为用户服务。终端用户可能无法访问所有运行维护的服务器和应用程序。考虑如何更换用户的桌面和应用程序 ，明确他们如何进行远程访问。 灾难恢复站建设实施 选择数据中心地址。主数据中心的高速连接是灾难恢复中心选择的关键因素之一。 硬件的获取、安装和准备。 安装和配置vSphere。 选择工具。 复制。初始化数据的复制将是最大的数据传输，然后复制变化块将更小，但复制数据 大小取决于应用程序中数据量变化的大小。复制数据的大小也取决于复制间隔(由复制间隔)RPO变化。 虚拟化在灾难恢复中的作用 硬件独立性：基于物理系统的灾难恢复解决方案需要在恢复站保留相同的硬件，或者必须经过许多复杂和耗时的步骤 在新的或不同的硬件上重建服务器操作系统。有时，恢复服务器是相同的硬件模型，但包括最新的硬盘控制器固定 零件会导致服务器镜像延迟。虚拟化使硬件从操作系统中抽象，并统一操作系统中使用的设备驱动器，无论是 所有虚拟机都使用一个共同的驱动集样，在新服务器上安装服务器镜像节省了大量的设备驱动器 对应的麻烦，大大减少了恢复时间和配置错误的风险。 虚拟机磁盘格式文件:虚拟机将其子操作系统、应用、存储和配置(如IP地址）存放在一个文件里。这个文件——虚拟 机磁盘格式（VMDK）或虚拟硬盘（VHD）该文件包含整个操作系统环境，以便简单地装载和保存虚拟机。 该文件不仅包括操作系统的镜像和应用代码，还包括虚拟处理器、内存和设备。这很简单 可移动文件包括组成服务器所需的所有信息、服务器环境描述、实际代码和数据。从虚拟机磁盘文件启动虚拟机时系统 所有参数都会自动快速设置。在灾难恢复站恢复会变得非常简单，只需启动VMHD或VHD。 物理工具到虚拟工具：虚拟机解决方案需要使用管理工具来创建、启动、停止和保存虚拟机镜像。为了方便创建虚拟机 ，有许多工具可以帮助分析物理服务器和创建服务器VMDK或VHD。由物理系统创建VMDK或VHD文件可以很快 部署到恢复站。 硬件再利用：恢复站虚拟机硬件不必闲置在那里等待灾难，也可用于开发、测试或其他用途。当发生灾难时 关闭用于测试或开发的虚拟机，然后启动虚拟机的生产，只需几秒钟即可完成。 灾难恢复的复杂性分析 由于用户对服务器虚拟化技术的接受度不断提高，行业对所谓的通用高可用策略有着需求。尽管如此 该方法可以通过集群故障迁移技术在一定程度上简化数据保护步骤，但并非所有数据保护都支持这种方法。 首先，即使对服务器虚拟化部署最乐观的预测成为现实，到2016年仍有21%X86平台关键业务(产生收藏) 高性能事务处理程序)在不使用任何虚拟化技术的物理服务器上运行。因此，对于虚拟化和非虚拟化 不同的服务器有必要采取不同的策略。 在采用了 x86 在虚拟化技术的工作负载中，一些虚拟机（VMs）与之对应的数据盘(表现为VMDK 和 VHD 文件）相比 其他虚拟机和数据盘更重要。在没有虚拟化技术的环境中，有许多不同的虚拟程序，但并非所有的应用程序都是 关键业务相关。在传统的服务器环境中，一些应用程序和虚拟机被频繁使用，而另一些应用程序则不那么频繁。这些真相 况都影响着数据备份和数据复制的频率和策略。[4] 灾难恢复计划 制定灾难恢复计划和建立基础设施IT经理担心。云服务提供更低的成本和更大的灵活性，但并非没有风险 的。 灾难恢复意味着更多的部署和灵活性测试，但也意味着更多的不确定性。 灾难恢复(DR)灾难恢复系统价格昂贵， 灾难恢复配置难度大，大部分灾难恢复只能在非 对于业务时间的故障恢复测试，灾难恢复模拟故障的内容很容易过时。灾难恢复服务(DRaaS)云容灾是一种方法， 成本更低，更容易部署，有能力定期提供测试计划，可以与企业的变化保持同步。 值得注意的是，在毁灭性灾难之后，云灾难恢复选择可能不可用。这意味着停留IT资源和数据使企业瘫痪。 如何制定灾难恢复计划 数据中心的工作人员和业务相关人员花费了大量的时间和精力本上花费了大量的时间和精力。 首先，预测潜在的数据中心灾难：灾害性天气、停电、供应商系统脱机、内部人员损坏或外部攻击。 立即在线确定公司的灾难恢复应用程序。审核清单，优先考虑日常操作的关键程序。 接下来, 冗余数据中心基础设施-服务器、软件、网络连接和支持应用程序的载体的原始数据和安装。没有灾难恢复计划 避免成本考虑；离线数据中心很贵。 通常, 灾难恢复计划要求复制每个应用程序的基础设施组件。 灾难恢复需要与主备份网站网络连接，备份系统应该是 前软件信息。 合适的员工需要知道如何调用备份流程。他将决定使用哪些系统，哪些员工应该更换系统备份。灾难恢复责任包 通知他们的网络和系统提供商更改数据，确保员工知道如何恢复系统。理想情况下，业务用户只是影响很小。IT团队 在灾难恢复数据期间，需要向工作人员提供最新的备份数据程序。 IT该部门经常花很多时间来设计和分析物理灾难恢复的计算环境，而不是在编码和测试中增加价值。测试灾难 在恢复计划中，数据中心团队应与相关操作系统和所有最新补丁一起测试接收、框架、堆叠和安装硬件。他们创造了灾难 难以恢复用户账户，部署框架或应用程序服务器环境和安装测试工具。程序员可以花一半的时间恢复普通灾难的基础设施 与其把时间花在实际的测试程序上。 由于灾害恢复过程复杂，企业通常每年测试一两次偶尔的灾害恢复计划。公司越大，灾害恢复计划证明的过程就越多 复杂。 灾难恢复程序一旦进入计划，很快就会过时。应用程序不断变化，团队必须经常审查和更新灾难恢复程序。大公司在 计划的每一个细节都花费了大量的时间和高达7的时间数以上的金钱($1,000,000+)。灾难恢复花费更多以确保计划仍然是可 行的。 许多企业只是口头上承认灾难恢复。在IT投资上，花大量的时间来缓解这1%,甚至更低的灾难恢复风险似乎并不是个好的 投资。IT经理有一份又长又不断增长的日常优先清单,而当灾难发生时，灾难恢复是唯一重要的事。 灾难恢复服务选项 云服务在共享基础设施上不断省钱。云的虚拟化和自动化的进步使之有更大的灵活性。企业根据需要使用云资源,虽然只 是在关键的应用上。暂时的案例中灾难恢复测试发生容易增加。 基于云端的灾难恢复,程序员不用在比特和字节上苦干;他们在硬件和操作系统界面上工作。因此更多的IT自动化的任务,生 产力的提高和灾难恢复测试时间的减少。数据中心的工作人员可以做为优先程序更经常, 分配更多的资源测试整个灾难恢 复服务功能。 云端灾难恢复服务的价格正在上升: 根据咨询公司预测，从2013年的640,800,000美元涨到2018年的5,800,000,000美元, 复合年增长率为55.2%。 当云端成为一个风暴 灾难恢复服务有其局限性。 “云端灾难恢复供应商无法完备份系统冗余,“剑桥公司的灾难恢复分析师Rachel Dines说。 灾难恢复供应商不能证明以模仿每个客户的基础设施设置建设的数据中心成本, 所以他们走捷径。灾难恢复服务提供商将 构建系统处理数量有限的故障。理论上讲,如果遇到灾难恢复特定场地的问题，比如数据中心的电力中断，企业将灾难恢 复他们的系统,。然而,如果发生重大自然或人为灾害,可能没有足够的空间在灾难恢复站点运行每个灾难恢复服务客户的 应用程序。当发现当灾难发生时， IT组织在危难关头唯一能做的是找到它并解决,因为灾难恢复服务比传统的灾难恢复构 建有更大程度的风险。 云端的灾难恢复也增加了企业网络带宽的需求。在供应商的云端灾难恢复服务放置应用程序副本和虚拟机(VM)镜像。那 些应用程序和虚拟机镜像不断更新,来自企业生产站点与灾难恢复服务供应商的数据中心的数据传输。这种加载应变可用 带宽。灾难恢复服务能够很好地处理简单的应用程序,但可能降低网络性能的进程密集型系统,如客户关系管理、企业资源 规划应用程序。[5]  实现VDI灾难恢复的四种方式 对于企业——特别是自己运行虚拟桌面环境的企业——来说，确保部署可靠的灾难恢复计划是非常重要的。但是现在应 该如何制定VDI灾难恢复计划？我们可以考虑Hyper-V、Windows To Go、存储同步和离线虚拟桌面等四种方式。 Hyper-V的灾难恢复 　　第一种灾难恢复方式不是很常用，但是据我所知已经至少有一家企业选择使用这种灾难恢复方式。这家企业在微软 Hyper-V平台当中运行自己的灾难恢复虚拟桌面，并且将灾难恢复虚拟桌面的备份版本存储在云中以防万一。 　　对于大规模灾难恢复事件来说，企业 通常会和硬件供应商达成协议，供应商将一批桌面PC租借给企业以供紧急使用 ，直到企业完全从事故当中恢复为止。根据协议，这些PC将会运行Windows 8并且已经安装Hyper-V。企业的灾难恢复 计划是将虚拟桌面的备份版本推送到所有PC上，使用Windows 8当中的Hyper-V功能为用户提供灾难恢复虚拟桌面服务 。 　　然而对于灾难恢复大型企业来说，完成这项灾难恢复计划需要投入异常庞大的工作量，因此灾难恢复可能是不切实 际的，但是对于灾难恢复中小型企业来说，灾难恢复确实是一种十分高效的方式。这种灾难恢复方式使得企业不再依赖 于任何后台基础架构，就能够恢复虚拟桌面的正常运行。 　　唯一的要求是DHCP（动态主机配置协议）服务器可以为虚拟桌面分配IP地址。对于这种灾难恢复情况来说，企业 可以使用无线路由器提供到PC的网络连接并且分配IP地址。 Windows To Go的灾难恢复 　　另外一种可行方案是Windows To Go的灾难恢复。这种灾难恢复特性在Windows 8当中被首次推出，灾难恢复允 许由USB闪存盘引导启动Windows。 　　采用这种灾难恢复方案的企业需要在遭遇灾难袭击之前，制作大量的USB闪存盘。将这些闪存盘存储在远离办公地 点的场所，在遭遇灾难袭击时分发给用户。 　　不幸的是，使用Windows 7的企业不能采用WindowsTo Go这种灾难恢复方式，但是可以使用Boot to VHD作为替 代灾难恢复解决方案。 　　不论对于 哪种灾难恢复情况，USB闪存盘的容量都将限制虚拟桌面镜像的大小，因此，安装有大量应用程序的桌面 镜像并不适合存放在USB闪存盘当中。 　　这种灾难恢复方式的另外一种缺点是如果想要实现真正的高效恢复，就需要提前花费大量时间准备闪存盘。如果虚 拟桌面镜像版本十分稳定，那么并不是什么问题，但是如果企业需要定期更新其虚拟桌面镜像，那么这种灾难恢复方式 就变得不切合实际了。 存储同步的灾难恢复 　　另外一种在VDI灾难恢复领域使用更为广泛的方式是将现有环境构建在多个数据中心，或者灾难恢复直接延伸到云 中，但是这种灾难恢复方式是否可行在很大程度上取决于厂商的解决方案。虽然这是一种最为可靠的灾难恢复方式，但 是灾难恢复也是最为昂贵的。 　　横跨数据中心的基本理念是扩展虚拟桌面所在的主机集群，以便能够分布在多个数据中心。同时将保存有虚拟硬盘 的存储设备复制到其他数据中心，使用这种灾难恢复方式，可以将虚拟桌面同时存储在两个不同地点。 　　尽管理论上，可以实现将虚拟桌面故障转移到第二数据中心，但是在第二数据中心创建一个完全分离的虚拟桌面池 却是一种更为高效的灾难恢复方式；将虚拟桌面运行在其他位置也会产生网络变更需求。 　　在一些灾难恢复情况当中，相比于远程恢复现有虚拟桌面，将用户连接到其他位置的虚拟桌面可能会更加容易一些 。[6]  离线虚拟桌面的灾难恢复 　　VMware提供的新特性允许移动办公用户离线查看和使用虚拟桌面。理论上，企业可以使用这种灾难恢复方式实现 灾难准备，以灾难恢复应对能够提前通知的、即将到来的灾难，比如缓慢逼近的飓风。 　　但是这种灾难恢复方式的缺点也十分明显。首先，在灾难已经出现之后采用这种灾难恢复方式并不容易。其次，这 种特性只能工作在VMware环境当中。 　　已经部署VDI环境的企业必须在灾难恢复业务连续性计划当中解决虚拟桌面问题。保证后端服务器资源在灾难袭击 之后还能够正常工作是最为基础的部分，但是如果没有虚拟桌面，用户就不能正常访问这些资源。[7]  灾难恢复的现状 若处理得当，灾难恢复（DR）计划是一项复杂而耗时的任务，这有助于解释为什么在过去的几年中，调查显示有连续计 划的企业数量在下降。在一个年度普华永道（PricewaterhouseCoopers）的研究中，有灾难恢复计划的企业下降到约 为39%，而去年同期的调查为50%左右。这些公司中，那些真正测试灾难恢复计划的企业通常是声称有计划中的一小部 分。这些只有灾难恢复计划文档但是没有实际测试的公司，其实际上对灾难恢复的准备更加让人担忧。 由于对灾难恢复必要性和实际价值的误解，相关的计划活动也少了。明显的，虽然“更少（的员工）更高效的工作”就 是“使用计算机来提高效率，”并且较少员工数量实际上更加依赖于自动化资源不间断的使用以及减少（哪怕是短时间 的）中断操作带来的误差，但是这些见解和确保自动化的连续性和弹性的需求并没有联系起来。[8]  灾难恢复能力评估 评估灾难恢复小组的能力的基本指标包括：知识，可以通过取得的专业证书或者参加的教育计划获得记录；经验，可以 根据以前的工作职责或者参与实际的灾难来判断；积极性，可以根据参与专业机构、出席并且/或者在大型会议上演讲以 及发表的文章来判断。每一项都可以被轻松地定义并制订成基准，而且可以作为评估和增加灾难恢复小组成员的技巧和 技能的一个有效的出发点。[9]  灾难恢复能力的发展 IT专家们看到对于灾难恢复（DR）的需求，并且很多人因为这个原因而使用OpenStack私有云。但是灾难恢复投资回报 （ROI）的模糊不清使得把这个推售到企业的业务部门成为很艰难的任务。 上周在亚特兰大举行的OpenStack峰会上的一次会议中，小组专家成员讨论结果表明Swift存储应用程序接口或者API， 对于为灾难恢复营造更好的环境尤为关键。 老化的基础架构和过期的灾难恢复计划，与此同时还要迁移到24小时不间断的运营模式，促使了，一家位于新泽西州 Somerset的移动和存储公司搭建了一个基于Swift的对象存储环境。[10]  ========

灾难恢复

https://msdn.microsoft.com/library/azure/jj714804.aspx 灾难恢复是一个术语，指的是关键系统组件出现故障，而此类故障通常需要人工干预才能还原正常操作。对于 Service  Bus for Windows Server 而言，灾害可能表现在以下几个方面： Service Bus for Windows Server 所使用的一个或多个数据库丢失。此故障可能是由硬件故障、操作员错误或数据中心 范围的灾难事件导致的。 运行 Service Bus for Windows Server 的节点丢失。 Service Bus for Windows Server 节点和数据库均丢失。 本主题讨论以下灾难恢复方案： 为灾难恢复做准备  故障转移场节点（重用现有场证书）  故障转移场节点（颁发新场证书）  故障转移 SQL Server  故障转移场和 SQL Server（重用现有场证书）  故障转移场和 SQL Server（颁发新场证书）  还原 Service Bus 场数据库  还原网关数据库  还原容器数据库  还原 Service Bus 实体  为灾难恢复做准备 Service Bus for Windows Server 将其所有数据存储在 SQL Server 数据库中。若要启用从灾难中恢复，请设置定期备 份或推进数据冗余解决方案。 Service Bus for Windows Server 使用以下数据库： 一个 Service Bus for Windows Server 场数据库。 一个网关数据库。 一个或多个容器数据库。 在这些数据库中，只有网关数据库和容器数据库必须进行镜像或备份。若要重新创建 Service Bus for Windows Server  场数据库，你可以按照本部分中的步骤进行操作。如果你选择备份网关数据库和容器数据库，请确保备份不同数据库的 时间不要相隔太远。 有关对 SQL Server 实施高可用性和灾难恢复的相关信息，请访问以下链接： Selecting a High Availability Solution（选择高可用性解决方案）  Description of disaster recovery options for Microsoft SQL Server（Microsoft SQL Server 灾难恢复选项的说明）  故障转移场节点（重用现有场证书） Service Bus for Windows Server 场节点不可用。SQL Server 仍然可用。若要从丢失的场恢复，请创建一个新场，然 后将网关数据库和容器数据库附加到新场。未发生数据丢失。若要创建新场并附加现有网关数据库和容器数据库，请执 行以下操作： 必备组件：现有 Service Bus for Windows Server 场证书。 使用 Web 平台安装程序在所有新场计算机上安装 Service Bus for Windows Server 及其所有必备组件。 安装旧 Service Bus for Windows Server 场的场证书。 在其中一个新场节点上，使用以下参数运行 Restore-SBFarm cmdlet： RunAsAccount：运行 Service Bus for Windows Server 服务的帐户。此帐户必须是用于旧场的同一帐户。 GatewayDBConnectionString：现有网关数据库的连接字符串。 SBFarmDBConnectionString：此 cmdlet 创建的 Service Bus for Windows Server 场数据库的连接字符串。 FarmCertificateThumbprint：旧 Service Bus for Windows Server 场的场证书指纹。在 Service Bus for Windows  Server 场数据库 [Store].[ServiceConfig] 表的 ConfigName SBEncryptionCertificateThumbprint 值下找到场指纹。 MessageBrokerPort：用于消息代理通信的端口。此端口必须是用于在旧场中进行消息代理通信的同一端口。如果未指 定，则使用默认端口。 HttpsPort：用于 HTTPS 通信的端口。此端口必须是用于在旧场中进行 HTTPS 通信的同一端口。如果未指定，则使用 默认端口。 TCPPort：用于 TCP 通信的端口。此端口必须是用于在旧场中进行 TCP 通信的同一端口。如果未指定，则使用默认端 口。 Restore-SBFarm cmdlet 将创建新的 Service Bus for Windows Server 场数据库。你可以删除旧的 Service Bus for  Windows Server 场数据库。 在所有新场节点上，使用以下参数运行 Add-SBHost cmdlet： SBFarmDBConnectionString：在步骤 3 中创建的 Service Bus for Windows Server 场数据库的连接字符串。 RunAsPassword：SecureString，包含在其下运行 Service Bus for Windows Server 进程的帐户的密码。 EnableFirewallRules：如果主机的防火墙规则应更新为允许 Service Bus for Windows Server 数据通过防火墙，则设 置为 true；否则设置为 false。 故障转移场节点（颁发新场证书） Service Bus for Windows Server 场节点不可用。SQL Server 仍然可用。若要从丢失的场恢复，请创建一个新场，然 后将网关数据库和容器数据库附加到新场。未发生数据丢失。若要创建新场并附加现有网关数据库和容器数据库，请执 行以下操作： 必备组件：无。 使用 Web 平台安装程序在所有新场计算机上安装 Service Bus for Windows Server 及其所有必备组件。 在其中一个新场节点上，使用以下参数运行 Restore-SBFarm cmdlet： RunAsAccount：运行 Service Bus for Windows Server 服务的帐户。此帐户必须是用于旧场的同一帐户。 GatewayDBConnectionString：现有网关数据库的连接字符串。 SBFarmDBConnectionString：此 cmdlet 创建的 Service Bus for Windows Server 场数据库的连接字符串。 CertificateAutoGenerationKey：SecureString，其中包含的密码可用于保护此 cmdlet 创建的新场证书。 MessageBrokerPort：用于消息代理通信的端口。此端口必须是用于在旧场中进行消息代理通信的同一端口。如果未指 定，则使用默认端口。 HttpsPort：用于 HTTPS 通信的端口。此端口必须是用于在旧场中进行 HTTPS 通信的同一端口。如果未指定，则使用 默认端口。 TCPPort：用于 TCP 通信的端口。此端口必须是用于在旧场中进行 TCP 通信的同一端口。如果未指定，则使用默认端 口。 Restore-SBFarm cmdlet 将创建新的 Service Bus for Windows Server 场数据库。你可以删除旧的 Service Bus for  Windows Server 场数据库。 使用以下参数在其中一个场节点上运行 Restore-SBGateway cmdlet： SBFarmDBConnectionString：在步骤 2 中创建的 Service Bus for Windows Server 场数据库的连接字符串。 GatewayDBConnectionString：已还原网关数据库的连接字符串。 对所有场节点调用 Update-SBHost cmdlet。 对于每个容器数据库，使用以下参数调用 Restore-SBMessageContainer cmdlet。在其中一个场计算机上运行此  cmdlet。 SBFarmDBConnectionString：在步骤 2 中创建的 Service Bus for Windows Server 场数据库的连接字符串。 ContainerDBConnectionString：容器数据库的连接字符串。 Id：还原的消息容器的 ID。 可从网关数据库的 [dbo].[ContainersTable] 表获得还原的消息容器的 ID，该表包含所有消息容器的 ID、连接字符串、 数据库服务器名称和数据库名称。选择其数据库名称与原始容器数据库名称匹配的容器的 ID。 在所有新场节点上，使用以下参数调用 Add-SBHost cmdlet。 SBFarmDBConnectionString：在步骤 2 中创建的 Service Bus for Windows Server 场数据库的连接字符串。 RunAsPassword：SecureString，包含在其下运行 Service Bus for Windows Server 进程的帐户的密码。 EnableFirewallRules：如果主机的防火墙规则应更新为允许 Service Bus for Windows Server 数据通过防火墙，则设 置为 true；否则设置为 false。 CertificateAutogenerationKey：SecureString，其中包含的密码可用于保护此 cmdlet 创建的新场证书。 所有服务命名空间密钥都是使用场证书加密的。颁发新场证书时将要求你替换所有服务命名空间密钥。对于每个命名空 间，使用以下参数调用 Set-SBNamespace cmdlet。在其中一个场计算机上运行此 cmdlet。 Name：服务命名空间的名称。 PrimarySymmetricKey：新的服务命名空间密钥。 故障转移 SQL Server SQL Server 不可用。若要从丢失的 SQL Server 恢复，请按照“故障转移场和 SQL Server”部分所述，创建一个新的  SQL Server 和 Service Bus for Windows Server 场。 故障转移场和 SQL Server（重用现有场证书） SQL Server 和所有场节点都不可用。若要从丢失的场和 SQL Server 恢复，请创建一个新场和一个新 SQL Server，然后 将网关数据库和容器数据库附加到新场。若要还原 Service Bus for Windows Server 场和 SQL Server，请执行以下操 作： 必备组件： 网关数据库和容器数据库的备份。 现有 Service Bus for Windows Server 场证书。 安装并配置新的 SQL Server。 使用 SQL 还原功能从备份副本还原网关数据库和容器数据库，如 Restore a Database Backup (SQL Server  Management Studio)（还原数据库备份 (SQL Server Management Studio)）中所述。 使用 Web 平台安装程序在新场计算机上安装 Service Bus for Windows Server 及其所有必备组件。 安装旧 Service Bus for Windows Server 场的场证书。 在其中一个新场节点上，使用以下参数调用 Restore-SBFarm cmdlet： RunAsAccount：运行 Service Bus for Windows Server 服务的帐户。此帐户必须是用于旧场的同一帐户。 GatewayDBConnectionString：现有网关数据库的连接字符串。 SBFarmDBConnectionString：此 cmdlet 创建的 Service Bus for Windows Server 场数据库的连接字符串。 FarmCertificateThumbprint：旧 Service Bus for Windows Server 场的场证书指纹。在 Service Bus for Windows  Server 场数据库 [Store].[ServiceConfig] 表的 ConfigName SBEncryptionCertificateThumbprint 值下找到场指纹。 MessageBrokerPort：用于消息代理通信的端口。此端口必须是用于在旧场中进行消息代理通信的同一端口。如果未指 定，则使用默认端口。 HttpsPort：用于 HTTPS 通信的端口。此端口必须是用于在旧场中进行 HTTPS 通信的同一端口。如果未指定，则使用 默认端口。 TCPPort：用于 TCP 通信的端口。此端口必须是用于在旧场中进行 TCP 通信的同一端口。如果未指定，则使用默认端 口。 Restore-SBFarm cmdlet 将创建新的 Service Bus for Windows Server 场数据库。你可以删除旧的 Service Bus for  Windows Server 场数据库。 使用以下参数对其中一个场节点调用 Restore-SBGateway cmdlet： SBFarmDBConnectionString：在步骤 5 中创建的 Service Bus for Windows Server 场数据库的连接字符串。 GatewayDBConnectionString：已还原网关数据库的连接字符串。 对所有场节点调用 Update-SBHost cmdlet。 对于每个容器数据库，使用以下参数调用 Restore-SBMessageContainer cmdlet。在其中一个场计算机上运行此  cmdlet。 SBFarmDBConnectionString：在步骤 5 中创建的 Service Bus for Windows Server 场数据库的连接字符串。 ContainerDBConnectionString：容器数据库的连接字符串。 Id：还原的消息容器的 ID。 可从网关数据库的 [dbo].[ContainersTable] 表获得还原的消息容器的 ID，该表包含所有消息容器的 ID、连接字符串、 数据库服务器名称和数据库名称。选择其数据库名称与原始容器数据库名称匹配的容器的 ID。 在所有新场节点上，使用以下参数调用 Add-SBHost cmdlet： SBFarmDBConnectionString：在步骤 5 中创建的 Service Bus for Windows Server 场数据库的连接字符串。 RunAsPassword：SecureString，包含在其下运行 Service Bus for Windows Server 进程的帐户的密码。 EnableFirewallRules：如果主机的防火墙规则应更新为允许 Service Bus for Windows Server 数据通过防火墙，则设 置为 true；否则设置为 false。 故障转移场和 SQL Server（颁发新场证书） SQL Server 和所有场节点都不可用。若要从丢失的场和 SQL Server 恢复，请创建一个新场和一个新 SQL Server，然后 将网关数据库和容器数据库附加到新场。若要还原 Service Bus for Windows Server 场和 SQL Server，请执行以下操 作： 必备组件： 网关数据库和容器数据库的备份。 安装并配置新的 SQL Server。 使用 SQL 还原功能从备份副本还原网关数据库和容器数据库，如 Restore a Database Backup (SQL Server  Management Studio)（还原数据库备份 (SQL Server Management Studio)）中所述。 使用 Web 平台安装程序在新场计算机上安装 Service Bus for Windows Server 及其所有必备组件。 在其中一个新场节点上，使用以下参数调用 Restore-SBFarm cmdlet： GatewayDBConnectionString：现有网关数据库的连接字符串。 SBFarmDBConnectionString：此 cmdlet 创建的 Service Bus for Windows Server 场数据库的连接字符串。 CertificateAutoGenerationKey：SecureString，其中包含的密码可用于保护此 cmdlet 创建的新场证书。 MessageBrokerPort：用于消息代理通信的端口。此端口必须是用于在旧场中进行消息代理通信的同一端口。如果未指 定，则使用默认端口。 HttpsPort：用于 HTTPS 通信的端口。此端口必须是用于在旧场中进行 HTTPS 通信的同一端口。如果未指定，则使用 默认端口。 TCPPort：用于 TCP 通信的端口。此端口必须是用于在旧场中进行 TCP 通信的同一端口。如果未指定，则使用默认端 口。 Restore-SBFarm cmdlet 将创建新的 Service Bus for Windows Server 场数据库。你可以删除旧的 Service Bus for  Windows Server 场数据库。 使用以下参数对其中一个场节点调用 Restore-SBGateway cmdlet： SBFarmDBConnectionString：在步骤 4 中创建的 Service Bus for Windows Server 场数据库的连接字符串。 GatewayDBConnectionString：已还原网关数据库的连接字符串。 对所有场节点调用 Update-SBHost cmdlet。 对于每个容器数据库，使用以下参数调用 Restore-SBMessageContainer cmdlet。在其中一个场计算机上运行此  cmdlet。 SBFarmDBConnectionString：在步骤 4 中创建的 Service Bus for Windows Server 场数据库的连接字符串。 ContainerDBConnectionString：容器数据库的连接字符串。 Id：还原的消息容器的 ID。 可从网关数据库的 [dbo].[ContainersTable] 表获得还原的消息容器的 ID，该表包含所有消息容器的 ID、连接字符串、 数据库服务器名称和数据库名称。选择其数据库名称与原始容器数据库名称匹配的容器的 ID。 在所有新场节点上，使用以下参数调用 Add-SBHost cmdlet： SBFarmDBConnectionString：在步骤 4 中创建的 Service Bus for Windows Server 场数据库的连接字符串。 RunAsPassword：SecureString，包含在其下运行 Service Bus for Windows Server 进程的帐户的密码。 EnableFirewallRules：如果主机的防火墙规则应更新为允许 Service Bus for Windows Server 数据通过防火墙，则设 置为 true；否则设置为 false。 CertificateAutoGenerationKey：SecureString，其中包含的密码可用于保护此 cmdlet 创建的新场证书。 所有服务命名空间密钥都是使用场证书加密的。颁发新场证书时将要求你替换所有服务命名空间密钥。对于每个命名空 间，使用以下参数调用 Set-SBNamespace cmdlet。在其中一个场计算机上运行此 cmdlet。 Name：服务命名空间的名称。 PrimarySymmetricKey：新的服务命名空间密钥。 还原 Service Bus 场数据库 Service Bus for Windows Server 场数据库已损坏或丢失。若要从丢失的 Service Bus for Windows Server 场数据库 恢复，请按照“故障转移场（重用现有场证书）”部分所述重新创建场。 还原网关数据库 Service Bus for Windows Server 网关数据库已损坏或丢失。 此 cmdlet 将尝试连接到所有容器数据库。其数据库无法访问的任何容器将在网关数据库中标记为故障。若要启用出现 故障的容器，请对出现故障的容器运行 Restore-SBMessageContainer cmdlet。 必备组件： 网关数据库的备份。 使用 SQL 还原功能从备份副本还原网关数据库和容器数据库，如 Restore a Database Backup (SQL Server  Management Studio)（还原数据库备份 (SQL Server Management Studio)）中所述。 对所有场节点调用 Stop-SBHost cmdlet。 使用以下参数对其中一个场节点调用 Restore-SBGateway cmdlet： GatewayDBConnectionString：已还原网关数据库的连接字符串。 对所有场节点调用 Update-SBHost cmdlet。 对其中一个场节点调用 Get-SBMessageContainer cmdlet。注意是否有任何消息容器的状态为故障。 对于每个状态为故障的消息容器，使用以下参数对其中一个场节点调用 Restore-SBMessageContainer cmdlet： ContainerDBConnectionString：容器数据库的连接字符串。 Id：消息容器的 ID。 对所有场节点调用 Start-SBHost cmdlet。 还原容器数据库 一个或多个 Service Bus for Windows Server 容器数据库已损坏或丢失。若要还原丢失的容器数据库，请执行以下操作 。 必备组件： 每个丢失的容器数据库的备份。 使用 SQL 还原功能从备份副本还原所有丢失的容器数据库，如 Restore a Database Backup (SQL Server  Management Studio)（还原数据库备份 (SQL Server Management Studio)）中所述。 对于每个丢失的容器数据库，使用以下参数调用 Restore-SBMessageContainer cmdlet。在其中一个场计算机上运行 此 cmdlet。 ContainerDBConnectionString：还原的容器数据库的连接字符串。 Id：还原的消息容器的 ID。 通过对其中一个场节点调用 Get-SBMessageContainer cmdlet 来获取还原的消息容器的 ID。此 cmdlet 返回所有消息 容器的 ID、连接字符串、数据库服务器名称和数据库名称。选择其数据库名称与原始容器数据库名称匹配的容器的 ID 。 对所有场节点调用 Stop-SBHost cmdlet。 对所有场节点调用 Start-SBHost cmdlet。 还原 Service Bus 实体 Service Bus 队列或主题已删除。若要还原丢失的实体，请执行以下操作。实体将被还原到当前的一个容器数据库中。 必备组件： 网关数据库和所有容器数据库的备份。 使用 SQL 还原功能还原所有容器数据库，如 Restore a Database Backup (SQL Server Management Studio)（还原 数据库备份 (SQL Server Management Studio)）中所述。将容器数据库还原到临时数据库中。不要覆盖当前容器数据 库。 使用 SQL 还原功能还原网关数据库，如 Restore a Database Backup (SQL Server Management Studio)（还原数据 库备份 (SQL Server Management Studio)）中所述。将网关数据库还原到临时数据库中。不要覆盖当前网关数据库。 使用以下参数对其中一个场节点调用 Restore-SBEntity cmdlet： EntityPath：要还原的实体的 URI。 SourceGatewayConnectionString：还原的临时网关数据库的连接字符串。 SourceMessageContainersConnectionStrings：还原的临时容器数据库的连接字符串列表。 对所有场节点调用 Stop-SBHost cmdlet。 对所有场节点调用 Start-SBHost cmdlet。 删除临时网关数据库和临时容器数据库。 ========

五款免费灾难恢复工具

http://os.51cto.com/art/201307/403070.htm 很多灾难恢复工具超出很多预算。让人欣慰的是还有免费工具，能够出色地备份并运转你的设备。让我们来看一下本文 这五个灾难恢复工具吧，或许对您的工作有所帮助。 AD：51CTO 网+ 第十二期沙龙：大话数据之美_如何用数据驱动用户体验 你希望需要从灾难中恢复的事情永远不会发生。但是，事物的一般规律是灾难必会打击你。当它发生时，你只能希望自 己提前做过准备，未雨而绸缪。你准备情况的深度和宽度会不尽相同，这取决于你正在准备的内容。为服务器恢复做准 备与为桌面恢复做准备大为不同。你可能需要一个机器的克隆影像，能够将服务器（或者一个桌面）快速复原。你可能 只需要一个数据的牢靠备份。不管哪一种方式，你需要正确的工具来完成此项工作。 很多灾难恢复工具超出很多预算。让人欣慰的是还有免费工具，能够出色地备份并运转你的设备。让我们来看一下这五 个工具吧。 1.Macrium Reflect Macrium Reflect是一个专业产品的免费版本。专门针对家庭使用的台式机（支持XP、Vista、Win 7、Win 8（32位和 原生64位），Macrium Reflect 可以处理：硬盘镜像/克隆、访问Windows资源管理器的映象、计划备份、接受Linux救 援CD、支持RAID和GPT。利用这个工具，你可以创造可靠的磁盘镜像，确保你快速备份机器并运行。无疑，这款软件 是供个人使用的。尝试一下，你会喜欢上它，你也许想为你的生意购买该软件的专业版本。此款软件供桌面使用的专业 版本仅售58.99美元，供服务器使用的专业版本价值199.99美元。 5款免费灾难恢复工具 2. Clonezilla Clonezilla是一个免费、开源、裸金属备份和恢复工具。Clonezilla基于DRBL、Partclone和Upcast。该软件有两个版本 ：Live和ClonezillaSE（服务器版本）。Live版本供单独的桌面使用，而Server版本适用于大规模部署（同时高达40个机 器）。Clonezilla支持：大量文件系统、LVM2、无人模式、组播传输（仅在SE中使用）等等。镜像可以保存在本地驱动 器、SSH服务器、Samba服务器和/或NFS服务器中。Clonezilla仅在硬盘保存和恢复已使用的数据块以节省硬盘空间。 虽然Clonezilla不是仅保存已使用的数据块，目标驱动器必须与源驱动器同等大小或大于后者。进行镜像备份的驱动器必 须是未安装的。 5款免费灾难恢复工具 3. DriveImageXML DriveImageXML同 Macrium Reflect类似，也为个人使用提供了免费版本。这个免费版本允许你备份、浏览和恢复镜 像。拥有浏览镜像的功能，这意味着你能够恢复文件和/或文件夹（不只是整个镜像）。DriveImageXML使用微软 Windows Volume Shadow Services，所以你能够从正在使用的驱动器中创建出镜像。尝试一下这个免费版本，看看它 是否满足你的需要。如果能够达到要求，你可以以100美元的价格购买五个用户的许可，价格区间一直到价值500美元的 100个用户的使用许可。 5款免费灾难恢复工具 4. Quick Disaster Recovery Quick Disaster Recovery（QDR）是一个在内置的Windows管理员工具已经禁用的情况下（如注册表编辑器、任务管 理器等），能够快速复原机器的工具。从用户图形界面（GUI）你可以重启已经被禁用的功能或使用替代工具。不管怎 样，你可以避免这样的“灾难”。QDR同样能够允许你快速停止在启动项中运行的应用（通过把你指引到注册表项方式 ，你可以在此做删除或禁用的操作）。QDR是免费的，根据通用公共许可证（GPL）发布。 5款免费灾难恢复工具 5. System Rescue CD System Rescue CD是一个Linux系统救援盘，允许对崩溃的系统进行管理和修复。你能够管理分区、恢复数据、编辑配 置文件，此外该软件在Linux和Windows系统下都可以使用。软件核心支持所有主要文件系统以及网络系统，如Samba 和NFS。软件配置的工具包括 Gparted、Partimage、 ddrescue、FSArchiver、Ntfs3g、test-disk、 Memtest+、  Rsync以及大量其他功能工具（想想典型的Linux工具）。这款软件在控制台和GUI模式下都可运行，根据通用公共许可 证发布，可免费试用。如果你能胜任此项任务，你甚至可以创建自己的版本的System Rescue CD，包括特定的脚本或 工具。 5款免费灾难恢复工具 总结 有很多的救援工具可供管理员使用。你可能面临最重要单一任务之一是，确保你拥有胜任此项工作的正确工具并适合你 的技能组合/工作风格。尝试这些工具中的一个或多个，我相信至少其中之一将会加入到你的系统管理员工具包中。 ========

Oracle 灾难恢复以及11g新特性恢复指导

http://blog.csdn.net/demonson/article/details/40150083 实验： 数据库灾难恢复（数据文件、控制文件、参数文件、归档文件等丢失） 法一：利用冷备 法二：RMAN恢复及11g新特性(list/advise/repair failure,create spfile from memory) 1.配置catalog数据库 1）catalog目录库：创建大文件表空间、用户、授权 create  bigfile tablespace rc_data datafile '/u01/app/Oracle/oradata/ORCL/rc_data.dbf' size 20m; create user rc_admin identified by oracle default tablespace rc_data; grant connect,resource,recovery_catalog_owner to rc_admin; 2）创建catalog库 RMAN> rman catalog rc_admin/oracle@ORCL RMAN> create catalog; 3）注册catalog库（在target库中） RMAN> rman target / catalog rc_admin/oracle@ORCL RMAN>register database; 4）配置target数据库 RMAN> rman target / catalog rc_admin/oracle@ORCL RMAN>configure retention policy to recovery window of 7 days;       --修改保留策略 RMAN>configure controlfile autobackup on;       --打开控制文件自动备份 RMAN>configure device type disk parallelism  4;        --开启并行备份，行度设置为4 2.备份target数据库 当所有文件丢失时，使用RMAN，应连接catalog库（catalog库中含有控制文件等） [oracle@jibo admin]$ rman target / catalog rc_admin/oracle@ORCL Recovery Manager: Release 11.2.0.4.0 - Production on Thu Oct 16 10:19:55 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. connected to target database: PROD (DBID=270879665) connected to recovery catalog database RMAN> show all; RMAN configuration parameters for database with db_unique_name PROD are: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; #  default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO  '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_PROD.f'; # default RMAN> backup database include current controlfile plus archivelog delete all input;      --全库备份加上归档日志文件     3.模拟灾难： 1）删除所有数据文件： SYS@PROD>select name from v$datafile; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b393xosc_.dbf /u01/app/oracle/oradata/PROD/datafile/o1_mf_sysaux_b393xovt_.dbf /u01/app/oracle/oradata/PROD/datafile/o1_mf_undotbs1_b393xq2d_.dbf /u01/app/oracle/oradata/PROD/datafile/o1_mf_users_b393xqpm_.dbf /u01/app/oracle/oradata/PROD/datafile/o1_mf_example_b393xp04_.dbf /u01/app/oracle/oradata/PROD/datafile/tbs_users1.dbf /u01/app/oracle/oradata/PROD/datafile/tbs_users2.dbf /u01/app/oracle/oradata/PROD/datafile/pitr.dbf /u01/app/oracle/oradata/PROD/datafile/pitr_ind.dbf /u01/app/oracle/oradata/PROD/arch_tbs.dbf 10 rows selected. SYS@PROD>!rm /u01/app/oracle/oradata/PROD/datafile/*.dbf SYS@PROD>!rm /u01/app/oracle/oradata/PROD/arch_tbs.dbf SYS@PROD>desc v$controlfile;  Name                                      Null?    Type  ----------------------------------------- -------- ----------------------------  STATUS                                             VARCHAR2(7)  NAME                                               VARCHAR2(513)  IS_RECOVERY_DEST_FILE                              VARCHAR2(3)  BLOCK_SIZE                                         NUMBER  FILE_SIZE_BLKS                                     NUMBER 2）删除所有控制文件： SYS@PROD>select name from v$controlfile; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/PROD/controlfile/o1_mf_b2255k12_.ctl /u01/app/oracle/fast_recovery_area/PROD/controlfile/o1_mf_b2255kjo_.ctl SYS@PROD>!rm /u01/app/oracle/oradata/PROD/controlfile/o1_mf_b2255k12_.ctl SYS@PROD>!rm /u01/app/oracle/fast_recovery_area/PROD/controlfile/o1_mf_b2255kjo_.ctl 3）删除参数文件： SYS@PROD>show parameter spfile; NAME                                 TYPE        VALUE ------------------------------------ ----------- ------------------------------ spfile                               string      /u01/app/oracle/product/11.2.0                                                  /dbhome_1/dbs/spfilePROD.ora SYS@PROD>!rm /u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfilePROD.ora 4）删除归档文件： desc v$archived_log --归档文件 SYS@PROD>select name from v$archived_log; NAME -------------------------------------------------------------------------------- /u01/app/oracle/fast_recovery_area/PROD/archivelog/2014_10_16/o1_mf_1_7_b3y4y1s8_.arc /u01/app/oracle/fast_recovery_area/PROD/archivelog/2014_10_16/o1_mf_1_8_b3y56mno ... 8 rows selected. SYS@PROD>!rm /u01/app/oracle/fast_recovery_area/PROD/archivelog/2014_10_16/*; alter system checkpoint;   --触发错误 5）退出重新进入： SYS@PROD>stutdown immediate SP2-0734: unknown command beginning "stutdown i..." - rest of line ignored. SYS@PROD>shutdown immediate ORA-01116: error in opening database file 2 ORA-01110: data file 2: '/u01/app/oracle/oradata/PROD/datafile/o1_mf_sysaux_b393xovt_.dbf' ORA-27041: unable to open file Linux-x86_64 Error: 2: No such file or directory Additional information: 3 SYS@PROD>shutdown abort ORACLE instance shut down. SYS@PROD>startup ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initPROD.ora'   --报错 4.利用catalog恢复target数据库 1）在catalog库查看target数据库DBID sqlplus rc_admin/oracle RC_ADMIN@ORCL>select * from rc_database;     DB_KEY  DBINC_KEY       DBID NAME     RESETLOGS_CHANGE# RESETLOGS ---------- ---------- ---------- -------- ----------------- ---------        241        242 1385095721 ORCL                925702 03-SEP-14          1         61  270879665 PROD               1107625 08-OCT-14 2）连接catalog数据库 [oracle@jibo ~]$ rman target / catalog rc_admin/oracle@ORCL Recovery Manager: Release 11.2.0.4.0 - Production on Thu Oct 16 14:08:59 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. connected to target database (not started) connected to recovery catalog database     --可以连接，但数据库没有启动 3）设置dbid，并启动数据库到nomount状态 RMAN> set dbid=270879665; executing command: