善用資料保護API建構高性價比的異地備援計畫

傳統異地備援的架構都是以儲存設備為主體，藉由儲存設備控制器韌體功能執行快照，再將快照內容視規劃的頻寬、RPO、RTO目標，以同步或是非同步方式執行異地資料抄寫。要建置這樣的架構，初期軟、硬體採購，維運後網路頻寬的費用，對一般企業而言是不小的預算，往往因此而卻步。

沒有備援機制，一旦企業資訊服務因為不可預期的因素停止，如果沒有一個可立即啟動的回復計畫，所造成的損失將難以預估。如何在有限的預算下建構一個可立即啟動的回復計畫是一個值得討論的題目。

第一步驟，要先確定一個務實的RPO、RTO目標；就算是RPO一小時、RTO三小時，一旦備援情事發生，所造成的損失都是可以控制的。根據設定的RPO目標，也許擷取傳輸備援資料的方式就不一定要採用儲存設備快照。例如VMWare的VADP API、Microsoft的VSS、Oracle資料庫的RMAN、Linux的LVM API都是非常可行的選擇，我們稱這些機制為資料保護(Data Protection) API。

而且，透過資料保護API擷取的資料都具有application consistent的特性及備援策略的獨立性，前者確保傳輸至異地後資料的完整性與可用性，後者可以依每個系統的業務需求個別賦予不同的備援策略。這是使用儲存設備以LUN為單位的快照比較難以達到的目標。如果藉由資料保護API來擷取備援資料可行，備援兩地使用不同規格的儲存設備就不是不可能的任務。如果考慮在雲端服務業者端建構備援機制，採用資料保護API一樣可行。

如果RTO目標允許，可以考慮已具有Object Storage Server的NAS；如Amazon S3相容模式，或是雲端服務業者的儲存機制；如Amazon S3、Azure、Google Nearline、中華電信HiCloud、遠傳電信FETNet來儲存異地備援資料。一旦備援情事發生，調度可用的設備或是租用雲服務資源，都是可行的高性價比回復計畫。

除了RPO、RTO之外，還需要考量維運人力與操作的複雜度。一旦備援機制啟動後，維運人員的挑戰就是當正式系統回復運作後，如何將不同屬性的資料從備援端，正確又有效率的抄寫回正式系統端。少了這個考量，備援架構仍是有瑕疵的。如果您正在尋求異地備援B計畫，Actifio的專家可以根據以上所提的可行機制規劃一個符合您企業需求的異地備援計畫。