灾难恢复
灾难恢复是在安全规划中保护企业免受重大负面事件影响的领域。其中重大的负面事件包括任何能造成企业业务风险的事情。在信息技术领域，灾难恢复步骤包括恢复服务器或备份主机、用户交换机（PBX）重建或提供局域网（LAN）来
满足当前的业务需求。
中文名 灾难恢复 外文名 disaster recovery 本 质 恢复正常商业运作的过程。 要 求 对机构的灾难性风险做出评估
实施步骤 选取数据中心地址。
目录
1 灾难恢复概念
2 虚拟化灾难恢复
.构建灾难恢复站点的准备
.构建灾难恢复站点的实施
.虚拟化在灾难恢复时中的作用
.灾难恢复的复杂性剖析
3 灾难恢复计划
.如何制定灾难恢复计划
.灾难恢复服务选项
.当云端成为一个风暴
4 实现VDI灾难恢复的四种方式
.Hyper-V的灾难恢复
.Windows To Go的灾难恢复
.存储同步的灾难恢复
.离线虚拟桌面的灾难恢复
5 灾难恢复的现状
6 灾难恢复能力评估
7 灾难恢复能力的发展
灾难恢复概念
本文讲述的是信息技术与管理概念。关于人体意外与急救，详见“灾难应对”。
灾难恢复，指自然或人为灾害后，重新启用信息系统的数据、硬件及软件设备，恢复正常商业运作的过程。灾难恢复规
划是涵盖面更广的业务连续规划的一部分,其核心即对企业或机构的灾难性风险做出评估、防范，特别是对关键性业务数
据、流程予以及时记录、备份、保护。
虚拟化灾难恢复
通过允许虚拟机在物理服务器之间进行无缝迁移，虚拟化提供了革命性的灾难恢复计划。[1]
构建灾难恢复站点的准备
在构建一个远程VMware灾难恢复站点之前，有许多问题需要考虑。
清查现有的基础设施。在彻底理清一个主要数据中心的资产之前，不能对其进行复制。
了解应用程序和它们的依存关系。明确哪些应用程序需要抵抗灾难的能力。要考虑到（主站点和备份站点）存储和网络
架构之间任何潜在的差异，确保程序即使在不同的环境下，也能够按照预期实现把故障转移到备份站点。
建立恢复点目标（RPO）和恢复时间目标(RTO)。 如果数据每小时复制到第二数据中心，当灾难发生时，有可能最多丢
失之间59分59秒的数据。如果这样是可接受的，不会严重地影响业务，那么PTO可以设定为一个小时。
为用户服务。终端用户也许不能够访问运行维护的所有的服务器和应用程序。要考虑怎样替换用户们的桌面和应用程序
，明确他们怎样进行远程访问。
构建灾难恢复站点的实施
选取数据中心地址。一条可承担到主数据中心的高速连接是选择灾难恢复中心需要考虑的关键的几个因素之一。
获取、安装和准备硬件。
安装和配置vSphere。
选择工具。
实施复制。初始化数据的复制将是最大规模的数据传输，随后的对发生改变的块进行复制将会小很多，但是复制数据的
大小会依据应用程序中数据量改变的大小而定。复制的数据的大小也会依据复制的间隔（由RPO决定）而变化。[2]
虚拟化在灾难恢复时中的作用
硬件独立：基于物理系统的灾难恢复解决方案都需要将相同的硬件保留到恢复站点，或必须经过很多复杂耗时的步骤在
新的或不同的硬件上重建服务器操作系统。有时候碰巧恢复服务器就是同一个硬件模型，但是包含了最新硬盘控制器固
件，会导致服务器镜像延迟。虚拟化使硬件从操作系统中抽象化，而且使操作系统中使用的设备驱动器统一化，不管是
何种底层硬件模型，所有虚拟机都使用一个共同的驱动集。这样，在新服务器上安装服务器镜像时就省了很多设备驱动
对应的麻烦，大大减少了恢复时间和配置错误的风险。
虚拟机磁盘格式文件：虚拟机将其子操作系统、应用、存储和配置（如IP地址）存放在一个文件里。这个文件——虚拟
机磁盘格式（VMDK）或虚拟硬盘（VHD）文件，包含了整个操作系统环境以便能进行简单的虚拟机装载和保存。这个
文件不仅包含了操作系统镜像和应用编码，还描述了虚拟机所需的配置，其中包括虚拟处理器、内存和设备。这个简单
的可移动文件包含了组成服务器所需的一切信息、服务器环境描述、实际码和数据。从虚拟机磁盘文件启动虚拟机时系
统会自动迅速设置所有参数。在灾难恢复站点进行恢复会变得很简单，只需启动VMHD或VHD。
物理工具到虚拟工具：虚拟机解决方案需要利用管理工具来创建、启动、停止和保存虚拟机镜像。为了方便创建虚拟机
，有很多工具可以帮助分析物理服务器和从服务器创建VMDK或VHD。从物理系统创建的VMDK或VHD文件可以很快地
部署到恢复站点。
硬件再利用：恢复站点的虚拟机硬件不必闲置在那里等着灾难发生，它也可以用作开发、测试或其它用途。当发生灾难
时，关闭用于测试或开发的虚拟机，然后启动生产虚拟机，这个过程只需几秒钟即可完成。[3]
灾难恢复的复杂性剖析
由于用户对于服务器虚拟化技术接受程度不断提高，业界有一种对于所谓的“万能的高可用策略”的需求。虽然这种做
法可以在一定程度上通过集群故障迁移技术实现简化数据保护的步骤，但并不是所有的数据保护都支持这种做法。
首先，即使当前关于服务器虚拟化部署最乐观的预测成为现实，到2016年也仍然有21%的X86平台的关键业务（产生收
入的高性能事务处理程序）运行在高达75%的没有使用任何虚拟化技术的物理服务器上。所以，针对虚拟化和非虚拟化
的不同服务器采用不同的策略是很有必要的。
在采用了 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: SET DBID
database name is "PROD" and DBID is 270879665
RMAN> startup nomount;
startup failed: 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'
starting Oracle instance without parameter file for retrieval of spfile
Oracle instance started
Total System Global Area 1068937216 bytes
Fixed Size 2260088 bytes
Variable Size 281019272 bytes
Database Buffers 780140544 bytes
Redo Buffers 5517312 bytes
4)还原参数文件和数据文件
RMAN>restore spfile;
RMAN>restore controlfile;
或者：
RMAN>restore spfile from autobackup;
RMAN>restore controlfile from autobackup;
或者：
RMAN>restore spfile from
'/u01/app/oracle/fast_recovery_area/PROD/autobackup/2014_10_16/o1_mf_s_861103939_b3yh28ts_.bkp';
RMAN>restore controlfile from '/u01/app/oracle/...';
--如果Oracle无法找到自动备份文件，则需要手工制定该文件的具体位置
5）启动数据库到mount状态并使用11g数据库的新特性（list/advise/repair failure）
RMAN> startup mount;
database is already started
database mounted
released channel: ORA_DISK_1
released channel: ORA_DISK_2
released channel: ORA_DISK_3
released channel: ORA_DISK_4
新特性：
list failure;
--如果list failure 没有输出结果，则需要我们手动恢复数据库；
advise failure;
--如果advise failure 输出的最后，显示没有可用的自动修复选项，则同样需要我们手动恢复；
repair failure;
--三条命令顺序不能改变
补充：
如果list failure没有输出结果，
则可以尝试打开数据库，查看报错信息，然后进行相应的处理；
eg：
alter database open;
alter database open resetlogs;
restore datafile 1;
list failure;
advise failure;
repair failure;
指令：
RMAN>list failure;
RMAN>advise failure;
RMAN>repair failure;
具体执行过程：
RMAN> list failure;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
1702 CRITICAL OPEN 16-OCT-14 Control file needs media recovery
1522 CRITICAL OPEN 16-OCT-14 System datafile 1:
'/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b393xosc_.dbf' is missing
709 CRITICAL OPEN 08-OCT-14 System datafile 1:
'/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b393xosc_.dbf' needs media recovery
469 CRITICAL OPEN 08-OCT-14 System datafile 1:
'/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b2251bs1_.dbf' is missing
242 HIGH OPEN 29-SEP-14 One or more non-system datafiles are missing
974 HIGH OPEN 10-OCT-14 Tablespace 11: 'PITR_IND' is offline
644 HIGH OPEN 08-OCT-14 One or more non-system datafiles need media recovery
817 HIGH OPEN 09-OCT-14 Name for datafile 7 is unknown in the control file
808 HIGH OPEN 09-OCT-14 Name for datafile 6 is unknown in the control file
RMAN> advise failure;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
1702 CRITICAL OPEN 16-OCT-14 Control file needs media recovery
1522 CRITICAL OPEN 16-OCT-14 System datafile 1:
'/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b393xosc_.dbf' is missing
709 CRITICAL OPEN 08-OCT-14 System datafile 1:
'/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b393xosc_.dbf' needs media recovery
469 CRITICAL OPEN 08-OCT-14 System datafile 1:
'/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b2251bs1_.dbf' is missing
242 HIGH OPEN 29-SEP-14 One or more non-system datafiles are missing
974 HIGH OPEN 10-OCT-14 Tablespace 11: 'PITR_IND' is offline
644 HIGH OPEN 08-OCT-14 One or more non-system datafiles need media recovery
817 HIGH OPEN 09-OCT-14 Name for datafile 7 is unknown in the control file
808 HIGH OPEN 09-OCT-14 Name for datafile 6 is unknown in the control file
analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
analyzing automatic repair options complete
Not all specified failures can currently be repaired.
The following failures must be repaired before advise for others can be given.
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
1702 CRITICAL OPEN 16-OCT-14 Control file needs media recovery
1522 CRITICAL OPEN 16-OCT-14 System datafile 1:
'/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b393xosc_.dbf' is missing
709 CRITICAL OPEN 08-OCT-14 System datafile 1:
'/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b393xosc_.dbf' needs media recovery
469 CRITICAL OPEN 08-OCT-14 System datafile 1:
'/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b2251bs1_.dbf' is missing
242 HIGH OPEN 29-SEP-14 One or more non-system datafiles are missing
644 HIGH OPEN 08-OCT-14 One or more non-system datafiles need media recovery
817 HIGH OPEN 09-OCT-14 Name for datafile 7 is unknown in the control file
808 HIGH OPEN 09-OCT-14 Name for datafile 6 is unknown in the control file
Mandatory Manual Actions
========================
no manual actions available
Optional Manual Actions
=======================
1. If you have the correct version of the control file, then shutdown the database and replace the old control
file
2. If file /u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b393xosc_.dbf was unintentionally renamed or
moved, restore it
3. If you restored the wrong version of data file
/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b393xosc_.dbf, then replace it with the correct one
4. If file /u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b2251bs1_.dbf was unintentionally renamed
or moved, restore it
5. If file /u01/app/oracle/oradata/PROD/ind_tbs.dbs was unintentionally renamed or moved, restore it
6. If file /u01/app/oracle/oradata/PROD/datafile/o1_mf_sysaux_b2251bvo_.dbf was unintentionally renamed
or moved, restore it
7. If file /u01/app/oracle/oradata/PROD/datafile/o1_mf_undotbs1_b2251bw5_.dbf was unintentionally
renamed or moved, restore it
8. If file /u01/app/oracle/oradata/PROD/datafile/o1_mf_users_b2251byw_.dbf was unintentionally renamed or
moved, restore it
9. If file /u01/app/oracle/oradata/PROD/datafile/o1_mf_example_b2257d0c_.dbf was unintentionally renamed
or moved, restore it
10. If file /u01/app/oracle/oradata/PROD/datafile/tbs_move_01.dbf was unintentionally renamed or moved,
restore it
11. If file /u01/app/oracle/oradata/PROD/datafile/o1_mf_sysaux_b393xovt_.dbf was unintentionally renamed
or moved, restore it
12. If file /u01/app/oracle/oradata/PROD/datafile/o1_mf_undotbs1_b393xq2d_.dbf was unintentionally
renamed or moved, restore it
13. If file /u01/app/oracle/oradata/PROD/datafile/o1_mf_users_b393xqpm_.dbf was unintentionally renamed
or moved, restore it
14. If file /u01/app/oracle/oradata/PROD/datafile/o1_mf_example_b393xp04_.dbf was unintentionally
renamed or moved, restore it
15. If file /u01/app/oracle/oradata/PROD/datafile/tbs_users1.dbf was unintentionally renamed or moved,
restore it
16. If file /u01/app/oracle/oradata/PROD/datafile/tbs_users2.dbf was unintentionally renamed or moved,
restore it
17. If file /u01/app/oracle/oradata/PROD/datafile/pitr.dbf was unintentionally renamed or moved, restore it
18. If file /u01/app/oracle/oradata/PROD/datafile/pitr_ind.dbf was unintentionally renamed or moved, restore
it
19. If file /u01/app/oracle/oradata/PROD/arch_tbs.dbf was unintentionally renamed or moved, restore it
20. If you restored the wrong version of data file
/u01/app/oracle/oradata/PROD/datafile/o1_mf_users_b393xqpm_.dbf, then replace it with the correct one
21. If you restored the wrong version of data file /u01/app/oracle/oradata/PROD/datafile/tbs_move_01.dbf,
then replace it with the correct one
22. If you restored the wrong version of data file
/u01/app/oracle/oradata/PROD/datafile/o1_mf_sysaux_b393xovt_.dbf, then replace it with the correct one
23. If you restored the wrong version of data file
/u01/app/oracle/oradata/PROD/datafile/o1_mf_undotbs1_b393xq2d_.dbf, then replace it with the correct one
24. If you restored the wrong version of data file /u01/app/oracle/oradata/PROD/datafile/pitr_ind.dbf, then
replace it with the correct one
25. If the file exists, rename data file 7 to the name of the real file using ALTER DATABASE RENAME FILE
command. If the file does not exist, create a new data file using ALTER DATABASE CREATE DATAFILE
command.
26. If the file exists, rename data file 6 to the name of the real file using ALTER DATABASE RENAME FILE
command. If the file does not exist, create a new data file using ALTER DATABASE CREATE DATAFILE
command.
Automated Repair Options
========================
Option Repair Description
------ ------------------
1 Restore and recover database
Strategy: The repair includes complete media recovery with no data loss
Repair script: /u01/app/oracle/diag/rdbms/prod/PROD/hm/reco_2998735934.hm
RMAN> repair failure;
Strategy: The repair includes complete media recovery with no data loss
Repair script: /u01/app/oracle/diag/rdbms/prod/PROD/hm/reco_2998735934.hm
contents of repair script:
# restore and recover database
restore database;
recover database;
alter database open resetlogs;
Do you really want to execute the above repair (enter YES or NO)? yes
executing repair script
Starting restore at 16-OCT-14
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00003 to
/u01/app/oracle/oradata/PROD/datafile/o1_mf_undotbs1_b393xq2d_.dbf
channel ORA_DISK_1: restoring datafile 00004 to
/u01/app/oracle/oradata/PROD/datafile/o1_mf_users_b393xqpm_.dbf
channel ORA_DISK_1: restoring datafile 00010 to /u01/app/oracle/oradata/PROD/arch_tbs.dbf
channel ORA_DISK_1: reading from backup piece
/u01/app/oracle/fast_recovery_area/PROD/backupset/2014_10_16/o1_mf_nnndf_TAG20141016T105733_b3yf19
4z_.bkp
channel ORA_DISK_2: starting datafile backup set restore
channel ORA_DISK_2: specifying datafile(s) to restore from backup set
channel ORA_DISK_2: restoring datafile 00005 to
/u01/app/oracle/oradata/PROD/datafile/o1_mf_example_b393xp04_.dbf
channel ORA_DISK_2: restoring datafile 00008 to /u01/app/oracle/oradata/PROD/datafile/pitr.dbf
channel ORA_DISK_2: restoring datafile 00009 to /u01/app/oracle/oradata/PROD/datafile/pitr_ind.dbf
channel ORA_DISK_2: reading from backup piece
/u01/app/oracle/fast_recovery_area/PROD/backupset/2014_10_16/o1_mf_nnndf_TAG20141016T105733_b3yf12
ln_.bkp
channel ORA_DISK_3: starting datafile backup set restore
channel ORA_DISK_3: specifying datafile(s) to restore from backup set
channel ORA_DISK_3: restoring datafile 00002 to
/u01/app/oracle/oradata/PROD/datafile/o1_mf_sysaux_b393xovt_.dbf
channel ORA_DISK_3: restoring datafile 00006 to /u01/app/oracle/oradata/PROD/datafile/tbs_users1.dbf
channel ORA_DISK_3: restoring datafile 00007 to /u01/app/oracle/oradata/PROD/datafile/tbs_users2.dbf
channel ORA_DISK_3: reading from backup piece
/u01/app/oracle/fast_recovery_area/PROD/backupset/2014_10_16/o1_mf_nnndf_TAG20141016T105733_b3yf10
lb_.bkp
channel ORA_DISK_4: starting datafile backup set restore
channel ORA_DISK_4: specifying datafile(s) to restore from backup set
channel ORA_DISK_4: restoring datafile 00001 to
/u01/app/oracle/oradata/PROD/datafile/o1_mf_system_b393xosc_.dbf
channel ORA_DISK_4: reading from backup piece
/u01/app/oracle/fast_recovery_area/PROD/backupset/2014_10_16/o1_mf_nnndf_TAG20141016T105733_b3yf0z
o6_.bkp
channel ORA_DISK_1: piece
handle=/u01/app/oracle/fast_recovery_area/PROD/backupset/2014_10_16/o1_mf_nnndf_TAG20141016T10573
3_b3yf194z_.bkp tag=TAG20141016T105733
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:04:30
channel ORA_DISK_2: piece
handle=/u01/app/oracle/fast_recovery_area/PROD/backupset/2014_10_16/o1_mf_nnndf_TAG20141016T10573
3_b3yf12ln_.bkp tag=TAG20141016T105733
channel ORA_DISK_2: restored backup piece 1
channel ORA_DISK_2: restore complete, elapsed time: 00:05:01
channel ORA_DISK_3: piece
handle=/u01/app/oracle/fast_recovery_area/PROD/backupset/2014_10_16/o1_mf_nnndf_TAG20141016T10573
3_b3yf10lb_.bkp tag=TAG20141016T105733
channel ORA_DISK_3: restored backup piece 1
channel ORA_DISK_3: restore complete, elapsed time: 00:11:10
channel ORA_DISK_4: piece
handle=/u01/app/oracle/fast_recovery_area/PROD/backupset/2014_10_16/o1_mf_nnndf_TAG20141016T10573
3_b3yf0zo6_.bkp tag=TAG20141016T105733
channel ORA_DISK_4: restored backup piece 1
channel ORA_DISK_4: restore complete, elapsed time: 00:16:35
Finished restore at 16-OCT-14
Starting recover at 16-OCT-14
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
datafile 6 not processed because file is read-only
datafile 7 not processed because file is read-only
starting media recovery
archived log for thread 1 with sequence 13 is already on disk as file
/u01/app/oracle/fast_recovery_area/PROD/onlinelog/o1_mf_1_b395df1j_.log
archived log for thread 1 with sequence 14 is already on disk as file
/u01/app/oracle/fast_recovery_area/PROD/onlinelog/o1_mf_2_b395dqql_.log
archived log file name=/u01/app/oracle/fast_recovery_area/PROD/onlinelog/o1_mf_1_b395df1j_.log thread=1
sequence=13
archived log file name=/u01/app/oracle/fast_recovery_area/PROD/onlinelog/o1_mf_2_b395dqql_.log thread=1
sequence=14
media recovery complete, elapsed time: 00:00:30
Finished recover at 16-OCT-14
database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
repair failure complete
RMAN>
5.查看恢复结果
1）登陆数据库，查看当前数据库状态，查看数据文件等重要文件的状态；
[oracle@jibo ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Thu Oct 16 14:59:53 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SYS@PROD>select status from v$instance;
STATUS
------------
OPEN
--数据库已经打开
或者：
SYS@PROD>select open_mode from v$database;
2)重新生成spfile；
数据库打开，查看spfile，没有spfile文件，生成spfile文件，再查看:
SYS@PROD>show parameter spfile;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string
SYS@PROD>create spfile from memory;
File created.
SYS@PROD>shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@PROD>startup;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size 2260088 bytes
Variable Size 285213576 bytes
Database Buffers 775946240 bytes
Redo Buffers 5517312 bytes
Database mounted.
Database opened.
SYS@PROD>show parameter spfile;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string /u01/app/oracle/product/11.2.0
/dbhome_1/dbs/spfilePROD.ora
SYS@PROD>
6.重新备份数据库
RMAN> backup database include current controlfile plus archivelog;
========
2369
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
