對企業而言，若採取傳統的資料備份與復原方法，將造成業務損失與人力工時的浪費，使得RPO與RTO成為高成本的策略。為了應付不斷變化的企業需求以及快速成長的資料量，業界必須發展更多新方法，以滿足使用者立即備份的需求。

本文將討論運用LSI StoreAge SVM快照強化應用復原解決方案與其他方案的比較，並說明此技術能如何提高效能、資料完整性，以及達成更快的復原速度。

各種快照技術剖析

現今業界已有許多種快照與遠端備份技術，不過僅提供在儲存陣列內部的快照功能，或為資料管理者提供主機層級的快照功能，藉以減少資料備份的窗口。幾種常見的技術如下：

寫入即複製（Copy on Write；COW）快照

主機層級快照利用卷冊管理員（Host Volume Manager）來管理快照，並提供一些方式讓備份代理程式將資料傳送到備份伺服器。這可讓備份代理程式暫時停止資料庫的運作，並在將檔案系統複製到磁碟裡的同時產生卷冊快照（Volume Snapshot）。接著，使用者可以在備份代理程式上檢視這份快照，並透過串流模式在區域網路上傳送。這項解決方案在資料被傳送到磁碟時，將會使資料庫暫時中斷數秒，然後才回復到正常運作。

業界稱上述方法為「寫入即複製（COW）」，因為當快照在卷冊上運作時，若要改變資料模塊，必須先將其讀取與寫入快照，然後才能完成原始資料的寫入。但是如此一來，系統必須承擔效能下降的風險，而可以想見地，在一些高負載的系統上，這將會嚴重影響效能表現與終端使用者經驗，特別是當備份代理程式還同時透過串流模式在傳送資料。也因此，不管什麼時候，COW都限制了快照的數量。

許多主機外的快照是在磁碟陣列中所進行的，因此能間接減輕資料庫伺服器在執行COW時的負擔。此種方法的另一個優點是快照複本可直接儲存於備份伺服器，因此不需要透過額外伺服器或區域網路就能進行備份。不過，這項解決方案勢必會增加磁碟陣列控制器的負荷量。在每一個邏輯裝置（Logical Unit Number；LUN）中，控制器的負荷主要來自COW所產生的快照副本，而主機的龐大流量則使其雪上加霜。

虛擬化儲存能將快照技術與儲存網絡系統（SAN）做連結，然而缺點是許多採用COW的解決方案都會大量增加系統的負擔。在很多情況下，即使只使用了基本的卷冊管理功能，都需要龐大的CPU運算資源與具備大容量的快取次系統的支援。

寫入即導向（Redirect on Write；ROW）快照

除了上面提到的COW之外，還有一種常見的高擴充性區塊層級快照技術，稱作「寫入即導向（ROW）」快照技術。

ROW快照提供高擴充性，並透過低容量快照取代全容量快照，所以讓使用者可以檢視完全獨立的可讀寫式磁碟卷冊。這項特性讓企業能將快照應用於資料備份、應用測試、更新檔測試，以及開發等作業。ROW的另一項好處是每一個卷冊可提供大量的快照，並能透過這些快照檔案將資料快速回復到某一個特定的時間點。透過這種更細微的資料粒度，讓ROW能更進一步地減少RPO的數量。

另外，還有一些進階功能可為使用者省下寶貴的時間，例如透過檢視技巧的輔助，運用快照檔案將資料還原。ROW允許使用者在將快照資料嵌回原始來源之前進行修改或修復，進而縮短復原時間。如此一來，ROW能將停機時間對企業造成的衝擊降至最低。

通常在使用快照技術時，系統都會要求將磁碟組合成一個一致的群組，如此一來便可以將資料庫檔案與登錄檔分別存放於不同的磁碟來管理，以利後續的資料庫設計。這項功能讓所有的資料庫、登錄檔及資料卷冊，都能創造出一致的快照檔案。所以，應用伺服器能被更有效地管理，而且也可以透過程序檔來讓快照自動化。這個特性對於大型資料庫的安裝來說尤其重要，因其牽涉到內含許多不同內容的多顆磁碟之整合。因此，若無法將這些不同來源的資料在同一個時間點進行擷取的動作，就會造成資料庫的不穩定，甚或導致資料庫無法使用。

《圖一　高低容量快照式意圖(A)全容量快照：原始卷冊大小x快照數量+1。主機寫入至原始資料模塊，加重在原始資料卷冊上COW的I/O負荷，因此支援的快照有限。(B)低容量快照：主機僅寫入新的快照區，因此擁有更高的擴充性。》

資料庫應用的各種挑戰

應用整合

資料庫應用中最重要的要素之一，就是確保任何解決方案都能提供一個機制，以保護資料的完整性。

企業決定選用何種解決方案來推動應用整合是一件相當重要的事情。若企業在暫停應用資料的變更前，就對關鍵任務資料庫進行快照，資料就可能出現前後不一致的結果，其後果相當於突然拔掉伺服器的電源插頭。於是就衍生出許多問題，例如：

• ●資料庫是否能復原？





• ●執行何種作業類型是否有差別？





• ●是否能前推至尚未進行的動作之前？





• ●資料庫管理者要花多長的時間來修復？





• ●將會流失多少資料？





• ●若無法回復資料，會有什麼樣的後果？

應用整合讓資料庫能以透明化的方式進行暫停讀寫，並提供系統足夠的時間將緩衝區的資料寫入磁碟，以確保資料的完整性。其中，功能強大的SANAPI描述檔能支援各種資料庫類型，包括Microsoft SQL Server、Microsoft Exchange及Oracle。而像Sybase 12.5這類僅提供命令列執行介面的靜態資料庫，在建立快照之前會先把資料寫入磁碟。也因為這層相似的特性，所以可以將它們整合到SANAPI描述檔，藉此使用這類資料庫的相關功能。

SAN CLI元件庫提供許多介面，不但能用來建立即時快照，同時還可以確保資料的一致性。隨後大量的快照檔案便可以上傳到備份伺服器上的SATA硬碟，或是經由VTL再轉至傳統的磁帶櫃做儲存動作。透過這些強大的標準套件，遠端即時資料儲存便不難實現，同時亦能節省資料回復動作所需的大量時間與成本。

應用回復

許多企業會訂立資料備份策略，卻疏忽了資料回復策略，但是每個應用程序都應該同時具備以上兩者。企業必須為他們每天在使用的系統排定一個優先順序，如此方能順利制定後續的資料回復策略。

傳統的備份方法可以讓你把資料回復到預設的備份點，而透過較審慎的規劃及紀錄檔重播，甚至可以將其回復到較新的時間點。快照備份則是讓你可以隨時檢視經由快照擷取的檔案資料，並且在資料毀損的時候，將資料庫檔案的複本套回受損的資料庫。然而，這一連串複製與貼上的動作看似簡單，實際上卻得花費可觀的時間。

例如，某些快照解決方案，僅能將資料回復到最近一次擷取快照時的狀態。其風險在於若該時間點的資料仍處於損毀狀態，就被迫得採用傳統備份的回復方法，進而大幅增加回復資料所耗費的時間。

採用StoreAge SVM容量快照解決方案，能將一份可完全讀/寫的資料回傳到原始，或已經回復過的資料庫伺服器中，以便檢查資料的完整性。若發現某個快照檔案有毀損的狀況，則會迅速套用更早一點的快照檔案，以維持資料的完整性。接著，被稱作時間前推（roll forward）的測試，便在不影響原始資料的前提下開始進行。在時間前推的過程中若發現問題，該筆資料將會被保存起來，並由系統一再測試其參數，直到問題解決了為止。若系統成功完成時間前推的測試，便會將資料回復到他本來的面貌。這邊可以得到一個結論，若沒有快照功能的輔助，上述的資料回復過程是不可能達成的。

若沒有採用這些技術，一旦時間前推失敗了，測試者就必須從磁帶回存資料，再進行一次前推、測試。若還是行不通，就使用更早版本的資料再試一遍－這種昂貴、費時、又不受歡迎的工作，會對團隊產生額外的壓力。

若企業的資料庫並不需要進行時間前推，而且也不介意僅採用最近時間點的快照檔案，那麼Recovery Point Objective將會把資料回復至最後一次擷取快照的時間點，然後經由StoreAge低容量快照應用程式（StoreAge multiView）的測試後，進行一個簡單的時間回推，再把資料回復成原來的樣子。

另外，為了維持應用程式的運作，也有一些企業選擇部署叢集解決方案。此法為將資料庫應用安裝在形成叢集的不同節點上，而後資料庫便在節點上運作。一旦執行資料庫程式的某節點發生故障，則正常運作的節點會取而代之，繼續接手執行資料庫。上述過程需要複雜的運作環境來支援，不僅資料庫本身必須支援多節點的叢集環境，連支應資料庫運行的眾多相關資源，都必須有節點間轉移的能力。此外，負責備份這些資料庫應用的程式亦必須支援叢集環境，導致此解決方案售價偏高。但是，若運用了上述的快照技術，就能大幅降低叢集環境備份解決方案的複雜性。

上面提到的各種解決方案，其目的都在因應本地端所可能遭遇的各種災害，包括人為錯誤、SAN故障、以及主機故障等因素。但若是遭遇恐怖攻擊，或是惡劣氣候導致設施癱瘓等大範圍的災害呢？

運用遠距備份維持應用資料的完整性

很多企業為了預防本地端的資料庫毀損，通常會讓關鍵的資料庫內容在其他地點也能照常運作，並且能在遠端檢視本地端資料的毀損狀況。有鑑於此，先進的快照功能可以讓企業在不會干擾系統運作的前提下，進行資料的檢驗動作，以利縮短回復毀損資料的時間。

然而，若企業只選用了遠距備份或資料同步鏡射，則有兩個必須考量的因素可能影響資料的完整性：

• (1)許多災害並非是發生在短時間內的單一事件，而是可能持續數分鐘甚至長達數小時（斷斷續續的停電、通訊線路中斷、磁碟故障等）。其中，間歇性的故障最難以應付，因為它們會在災難發生時，不只一次地損害資料的完整性。





• (2)另一個要考慮到的因素是修復故障所需的時間。在採用同步鏡射方法時，所有資料─不論是否受損─都會立即被複製到次要儲存裝置，而其結果是若一端的資料庫檔案系統毀損，另一端的資料也會跟著遭殃。要將這類型的資料毀損修復，通常得花上數小時到數天，在某些情況下甚至無法復原。

綜上所述，若企業選擇了錯誤的回復方法，則可能使資料毀損得更嚴重，甚至導致資料完全遺失的情況。而若是沒有採用快照，就無法將資料回復到已知的時間點，因此必須採用傳統的備份/回存方法。反之，如果採用全容量的快照，就必須花費大量時間來複製所有資料，導致回復後的資料過時而不符實際狀況。最後，某些快照技術僅允許在主要或次要的站點中擇一擷取快照，這意謂著若應用整合快照僅侷限在本地端，則複製的快照檔案無法維持與原應用的一致性。

《圖二　資料庫及快照檔案從本地端或備援伺服器複製過程的示意圖。備援端可用來進行站點外備份，或取代原系統上線運作，且模塊層級的資料異動內容會複製到主要站點。》

解決之道

針對這些問題，StoreAge SVM提供了一些解決方式，首先來談談低容量快照。因為低容量快照所複製的檔案容量較小，因此可以得到較多的檢驗時間點，以便檢查檔案的一致性。若在檢查過程中發現了某個一致的狀態，就能藉此讓資料庫回復上線，可能的話還可以把資料狀態推移至較新的時間點。應用整合快照則可以將資料複製到備援端，故在災害發生的時候可以將原本的資料在本地端或備援端的伺服器上重現，並且不需要透過磁帶回存。

StoreAge SVM針對這些問題提供解決方案。運用低容量快照，就能得到許多時間點，可檢查這些時刻的資料一致性。找到某個一致的狀態後，就能讓資料庫回復上線，若可能的話還能把資料狀態推移至較新的時間點。應用整合快照會複製到災難復原站點，且能在災難復原或主要站點上，快速讓一致的資料上線運作，不必從磁帶進行回存。最後，非同步鏡射自動回復功能（StoreAge multiMirror）可讓災難復原測試進行得更順利，方法是只把災難復原站點中被異動過的資料模塊回存到主要站點，而不必對所有資料進行完整的模塊層級資料同步化。如此一來，就不必為了要達到理想的資料更新速度而花大筆金錢去購買頻寬。

---本文由LSI公司提供---