當前位置：
首頁 >
灾难恢复学习总结
發布時間：2025/4/14
36
豆豆
災難恢復
災難恢復是在安全規劃中保護企業免受重大負面事件影響的領域。其中重大的負面事件包括任何能造成企業業務風險的事情。在信息技術領域，災難恢復步驟包括恢復服務器或備份主機、用戶交換機（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;
========
總結
- 上一篇： oracle 备份与恢复学习总结
- 下一篇： VS 断点无法调试学习总结