對於乙個企業來說,災難發生過後,最嚴重的問題不是來自於如何從磁帶中將資料恢復出來,而是來自於:
1、缺乏、甚或完全沒有文件化的恢復計畫和措施;
2、在重新配置硬體的時候,找不到原始系統配置和設定的文件;
3、磁帶文件、歸檔和跟蹤相關資料的缺失,或者不完整的磁帶歸檔策略;
4、對部門級的伺服器保護不夠充分。
#1 – 文件化並歸檔系統配置
成功的業務應用和資料恢復,始於完整的系統配置記錄文件,包括隨著時間的推延,系統配置被改變的日誌記錄。一旦這些文件被建立,至少要有乙個副本必須被存放在異地,以防本地的文件及其副本被損壞或毀壞。
建立文件,並在異地將文件進行歸檔,是快速並有效地重建系統的關鍵步驟。如果有乙個可以進行裸裝置恢復的方案,能夠往磁碟上直接載入所記錄的系統配置,為新裝置提供自動重建,將會為關鍵應用伺服器的重建提供更高的價值。
#2 – 文件化並歸檔災難恢復的程式
為了確保業務的成功恢復,必須建立乙個簡捷-有效的災難恢復程式,以及嚴格按照既定的程式去建立文件、並與業務關鍵資料一起安全地異地儲存。這樣可以避免「摸著石頭過河」的反覆的恢復測試。
#3 – 安全措施、文件及磁帶介質跟蹤
針對業務災難偶發事件的成功計畫,應包括異地存放磁帶、及記錄其磁帶內容的文件的策略和程式。如果沒有這些記錄磁帶內容的文件,在恢復時就要化大量的時間來索引和閱讀這些磁帶,以尋找藏於其中的重要資料。這樣會大大地延誤系統和資料的恢復。
根據業務需要來決定磁帶異地存放的頻率;磁帶內容必須建檔;文件必須是安全地和易於取出地作異地儲存;同時,磁帶必須是被跟蹤的。
所有這些步驟對於資料的安全保護和確保有效恢復來說,都是必須的。
#4 – 判別和保護所有業務關鍵的伺服器
為了業務的不間斷,所有執行著業務關鍵應用的部門級伺服器,包括email伺服器、小型資料庫伺服器、及其他執行著特別應用的伺服器,與資料中心的基礎設施一樣,必須被迅速恢復。
可悲的是,在大多數個案中,企業並沒有考慮對這些系統的保護。而事實上,這些部分應該與企業資料中心完全一樣,在同一計畫中文件化其保護程式和實施。
任何正在使用中的伺服器,以及每一台台式電腦和便攜機系統,從某種意義上來說都是值得保護的。最基本的資料保護可保證某種程度上的恢復。進一步而言,裸裝置恢復的方案可以確保以最少的工夫和經驗來恢復和重建關鍵應用伺服器,而且只需要少量的跟蹤裸裝置恢復磁碟本身的文件。
可以確保持續監控、資料連貫性和可用性的自動化工具是至關重要的,通過從大量災難事件中所獲得的重要經驗,我們認為上述手段可以保護企業的業務執行得更好。
成功的恢復
*包括磁帶跟蹤技術在內的介質管理方案,
*裸裝置恢復的解決方案
*實時的資料複製方案
*廣域的集群技術方案
AWS災難恢復方案示例 (1)備份和恢復
前面我們介紹了關於disaster recovery dr 的內容包括 disaster recovery dr 災難恢復的定義和內容概述 恢復時間目標 rto 和 恢復點目標 rpo 與災難恢復 dr 相關的aws功能和服務 1 與災難恢復 dr 相關的aws功能和服務 2 與災難恢復 dr 相關...
災難恢復 boot分割槽的恢復方法
boot分割槽是系統啟動中最重要的部分,如果伺服器由於病毒攻擊又或者被管理員誤刪除了boot分割槽。那麼就會存在潛在的風險。為什麼說是潛在的風險?因為boot分割槽被刪除後系統仍在繼續執行,看似無狀況但是在執行關機操作後就會無法啟動。1.掛載centos系統映象 2.進入救援模式 3.修復fstab...
使用者間的通訊方案設計
實現乙個利用 websocket 進行實時通訊的基於 web 的即時通訊應用,假設未來使用者量會很大,要用到多個伺服器,如何實現兩個使用者間的通訊呢?負載均衡演算法和訊息路由演算法均採用 一致性雜湊演算法 具體過程是 客戶端連線時根據ip或者客戶端標識通過一致性雜湊演算法定位到某台伺服器,訊息路由時...