為何要複製？

在典型的電子商務中，資料無需太久的時間就會成長到需要多重的處理地點。為因應客戶、供應商與員工的回應要求，電子商務的系統通常會決定將資料放置在最接近使用者的位置，以發揮最大的效率。若要從多重地點取得資料，就必須將資料複製或放置到那些地點。例如價目表、產品規格、網頁等等通常全都會被複製到電子商務的各營運地點。很明顯地這類資料在所有地點都必須一致，資料變更時也必須同步。

資料通常也會複製以供資料查閱使用。隨著電子商務益趨成熟，會出現堆積如山的營運歷史資料。各企業的歷史資料可以儲存在資料倉儲中以供查閱，或供各種計劃用途的趨勢分析使用。雖然這些資料非常有用，但由於資料查閱非常依賴I/O，故若無重大的營運改變，電子商務的線上資料通常不作查閱用途。同時，為避免資料查閱影響系統運作效能，資料大多被複製到獨立的伺服器(資料倉儲)，供應電子商務營運必要的查閱使用。

複製資料的第三個理由，或許是最重要的理由，就是為了災難復原(disaster recovery)。隨著電子商務的成長，資料中心停擺對社會經濟的影響將非常重大。審慎的商業運作乃是企業的生存之道，因此，電子商務必須能夠迅速從火災、洪水、惡意破壞、供電故障、軟體故障或其他的突發事件中迅速恢復運作。

複製的本質

無論是以佈告、查閱或災難復原為目的，資料複製的本質都是相同的。營運資料的最新副本會一直維持在線上，位於主要資料中心以外的獨立地點，而且必須與用來營運企業的主要資料庫同步。

複製可以保持多份與應用軟體線上使用的電子商務資料相同之副本。複製技術特點如下：

無論是檔案或磁區群組的複製軟體都被設計成即使網路或系統故障時，仍可保持複製資料的完整性，同時提供營運實務上所需的適當效能。

應用軟體在主要伺服器上執行，更新檔案系統和儲存在磁區群組中的資料庫表格中的資料 (有或無檔案系統) 的同時，檔案系統和磁區群組的副本會儲存在第二個伺服器中。可以看出複製的三個要點：

* 無論檔案系統或磁區群組(包括多個檔案系統)都必須能夠複製。檔案系統的複製功能對眾多檔案之許多管理工作非常有用，這些檔案是複雜的電子商務應用軟體中不可分割的一環。磁區群組複製比較適合使用於儲存少量的大型檔案與分散在多重磁區的多個檔案系統的資料庫。

* 複製是一對多的作業。源頭是單一的，而目標則是各複製檔案系統或磁區群組。複製的源頭為應用軟體提供資料讀寫存取能力，而檔案系統副本則可被指定供應用軟體使用。實際上，進行複製作業時，磁區群組副本是無法供應用軟體使用的。

* 複製所運用的是傳統硬體零組件與網路連線。複製資料無需特定硬體，也不需要指定複製專用的通訊連結(雖然VERITAS建議使用專線，以獲得最佳效能與應用軟體反應速度)。此外，雖然複製磁區應有相同的容量，但主要與次要的資料副本無需儲存在同一磁碟上。

複製是資料存取與管理堆疊的一個層級，而由於複製物件是檔案系統或磁區，因此所有的儲存管理基礎功能如Quick I/O for Databases，包含可用性強化，如鏡射與效能強化，都可以用來連結資料副本。

複製必需具有策略基礎。系統管理者可以制定適當的複製政策，以滿足企業需求。複製政策包含：

一旦制定政策後，就可以自動執行複製作業，除非發生災害等意外事故，完全無需系統管理者介入。

無論檔案系統或磁區群組的複製都可以達成相同的基本目標，就是維持多部電腦的資料一致，差異只是在於產生副本的本質。這些差異將影響各種類型的應用軟體使用副本的方式。

檔案系統複製

檔案系統複製是同步的作業。這表示應用軟體在資料源頭的寫入作業必須到所有目標位置都寫入完成為止，才會結束。同步複製的機制將在後續章節討論，然而此種複製會使應用軟體寫入至複製檔案系統時，花費較寫入本地檔案系統更多的時間。因此，檔案系統複製通常不適合較高更新率的應用軟體來使用。

由於檔案系統將最新資料複製保存在次要位置，資料源頭與次要位置的副本絕對是相同的，因此無需保有更新記錄，即可從通訊故障或次要位置故障時恢復。此種方式可降低複製所需之I/O資源，然而缺點是，當資料源頭與次要位置之間的通訊故障時,會要求冗長的再同步程序。

網路停擺後，資料源頭和次要檔案複製位置必需透過各自計算檔案總數來進行比對，確認所持有的副本是否彼此相同。若次要位置的檔案總數不相符，則次要位置的版本會被資料源頭的副本所取代。

與記錄重播的方式相比較，這種恢復技術比較費時。由於檔案系統的複製作業，必需犧牲恢復時間來降低對正常作業所造成之效率影響。檔案系統複製因此比較適合通訊或網路具備有較高可用性的環境，以免網路時常停擺造成再次的同步作業。

檔案系統複製的另一項優點就是其複製可以是雙向的。在次要位置的應用軟體也可以存取位於複製檔案系統的檔案。在某些情況下，應用軟體於次要位置檔案中所作的修改可以複製回資料源頭，當然這就不是磁區組群複製的討論範圍了，因為磁區組群複製是無法雙向作業的。

磁區組群複製

在磁區群組複製時，寫入資料源頭的區塊會複製到多個次要位置的磁區。由於磁區複製僅需極少的相關作業，因此可以是非同步複製。非同步複製的機制將在下一章節討論。然而對應用軟體而言，磁區群組複製的主要優點在於改善應用軟體效能以及從網路停擺中迅速恢復。

在網路停擺時，主要的磁區複製位置會記錄所有的需複製至複製磁區群組之所有更新。在網路恢復後，網路停擺時在資料源頭該區塊的更新記錄會傳送到次要位置。因此，磁區群組複製很適合用於資料源頭與次要位置之間的網路穩定性較差時的環境。

由於磁區群組複製的特性無法使位於次要位置的應用軟體在複製進行當中使用副本，因此磁區群組複製技術最適合用於以下兩種情況：

資料公佈：

某些企業在中心位置保管資料，然後公佈至多個次要位置以供使用。如在多個電子商務據點使用的網頁、價目表、產品規格與其他的文件就是這類應用的極佳範例。

災難復原：

災難復原中心通常設置在距離主要資料中心非常遙遠的地方，以便發生災害時仍能繼續營運。(例如，設置在距離主要位置非常遙遠的另一個地震區塊，以避免區域性的災害。)主要位置的磁區群組可以複製到災難復原中心。若主要位置發生災害，則可以在災難復原中心迅速重新啟動應用軟體，並運用最新的資料副本重新營運。

以上兩者的相同特色都是在複製後使用次要位置的資料，而非在複製當中使用資料。

同步複製

若次要位置的磁區群組內容與主要位置的對應區域相同時，次要副本就可以說是最新的。若要次要位置隨時保有最新資料，那麼所有更新都必須同步複製到所有位置。也就是說，每個應用軟體更新都必須寫入到主要磁區與次要位置磁區的相對應位置，然後才會允許應用軟體繼續執行。

同步複製所需的連續作業可能導致無法接受的冗長應用軟體反應時間。部分廠商提供的磁區複製最佳化技術，可改善應用軟體反應時間，而無需犧牲資料複製的目標。這種技術使得同步寫入至磁區的資料可在寫入後立即執行以下功能：

然而運用圖二所示的複製機制，可保障資料安全，免於以下狀況發生導致資料遺失：

即使擁有如此的絕佳方案，若經常更新應用軟體，或是需複製為數眾多的次要位置，將使系統遭遇瞬間的網路過載，，都將因同步複製作業而導致應用軟體效能低落。若磁區複製可支援非同步複製模式，可解決這種狀況。

非同步複製

運用非同步複製技術，可讓應用軟體將寫入要求記錄在主要位置之後，立即繼續執行。資料傳送與寫入至次要位置的磁區是非同步發生的，通常會在應用軟體被通知寫入已經完成之後。說明同步與非同步複製的應用軟體時間差。

如圖三所示，非同步複製可以減少延遲，或一連串應用軟體寫入要求的執行時間。然而，非同步複製的更重要影響是，避免因瞬間的網路超載拖延應用軟體效率或導致寫入要求失敗。寫入至非同步複製磁區的應用軟體不會因為網路超載而慢下來或無法連接網路，因為其操作執行獨立於通訊連結與次要位置之外。

只要網路與次要位置可以負荷，複製管理軟體會儘快傳送寫入要求的主要位置記錄至次要位置。若網路超載是短暫的，最後仍會清除，而次要位置仍可維持最新資料。若網路超載時間漫長，則尚未複製至次要位置之記錄會增加，此時主要位置之應用軟體仍能正常運行，不受影響。非同步複製可運用暫存來因應短期的網路超載，但絕非替代不穩定狀態的網路頻寬。

非同步複製的優點是擁有較佳的應用軟體反應速度(與同步複製相比)、瞬間網路超載的容忍度，以及在次要位置故障或網路停擺後的快速恢復。而缺點是次要位置的磁區會有短暫時間無法維持最新狀態。倘若在這狀況下，次要電腦當機或通訊連結故障，則會在恢復後從主要位置傳送資料並寫入。然而，倘若主要位置遭遇無法恢復的災害，而主要記錄內容無法恢復時，次要位置的恢復作業就必須以稍微過時的資料來執行了。

為降低這種風險，系統管理者可以限制次要位置被允許處於未更新狀態的最大寫入次數。超過此限時，在主要位置的應用軟體寫入動作會暫停(不會給予完成訊號)，直到未傳送的資料量低於臨界值為止。這個臨界值的設定可以有效控制未即時更新至次要位置的資料總量。

雖然非同步複製無法達到完美的一致性，然而其超高效能仍是作業上相當需要的。無論是瞬間的更新超載，或因其他來源造成網路超載而增加應用軟體反應時間，非同步複製可免除複製資料所需的大部分動作，提高應用軟體的反應時間，而差異就在於複製作業是否實際了。

使用複製磁區

使用磁區複製時，無論是否擁有檔案資料、檔案系統資料、資料庫頁面或其他物件，複製管理軟體不會有任何更新區塊的資料。若無該資料，複製管理軟體將無法使主要與次要位置同步更新。因此，磁區群組複製是無法雙向進行的，僅可從主要位置複製區塊到次要位置，但無法反向複製。

混合式恢復技術

若運用非同步複製技術的主要位置發生無法恢復的災害時，次要位置磁區會稍微過時。某些在主要位置處理完成的更新 (可能是應用軟體或使用者動作所造成) 可能還在傳輸，或記錄下來以供災害後立即傳輸，這種更新就不會反應到次要資料庫。而混合式技術運用較高階的系統功能 (例如：資料庫記錄) ，通常會被求在這種狀況下執行恢復作業。

例如，資料庫表格空間可能包含在複製磁區群組中磁區的內建檔案系統內。磁區群組可能使用非同步複製，以提昇效能。然而，資料庫記錄通常會存在使用同步複製方式之檔案系統的檔案中。也就是說，即使主要位置因災害可能導致資料表更新在傳輸中遺失，但如透過redo記錄復原，會使次要位置資料庫副本完整無缺，並使次要位置維持最新狀況。因為記錄是同步複製的，即使資料庫本身未同步複製，所有的資料庫更新都會反應在記錄上。

災害 vs. 故障

前面已就儲存裝置複製在災後復原時的重要性加以說明。擁有重要資料的遠端副本，使電子商務的企業可以迅速從災害中再站起來。在遠端的最新資料是企業永續經營的重要一環，但基於考量還有員工、通訊、運輸等等因素，除非遭遇致命的災害，否則企業通常都不願意從主要資料中心將營運重心移動到備援位置。

一般而言，最好還是以本地問題的方式來處理系統故障與儲存裝置故障。而擁有容錯功能的RAID，是解決儲存裝置故障的最佳解決方案。擁有自動應用軟體故障恢復功能的叢集架構 (在後續章節討論)，可讓資料中心保持完整無缺而且能夠運作，是解決系統當機的最佳解決方案。任何電子商務災害恢復重點策略必須運用客觀的標準，來區別可能中斷複製的短期故障和需要次要資料中心暫時接手的真實災害。

主要或次要伺服器的網路停擺以及故障都可能會中斷磁區複製。主要與次要的複製記錄是防止這種中斷的機制，可在所需的設備再度取得時，重新同步並恢復複製。主要位置的複製記錄會保留更新資料，直到傳輸給次要位置為止。若主要位置遭遇災害而需要次要位置取代成為新的主要位置時，就會使用次要位置的複製記錄。

交互式災後復原

將主要與次要複製位置的角色與檔案系統的複製磁區群組加以連結有助於交互式災後復原作業。因此，以某伺服器當作主要伺服器，而另一複製磁區群組當作次要伺服器，且互為次要位置是非常可行的。(圖六)說明交互式災害恢復的機制。

圖六所示的系統擁有專屬於應用軟體A與B的伺服器。應用軟體A的資料被複製到應用軟體B的伺服器的複製磁區群組中，反之亦然。若任一位置故障時，應用軟體會在另一伺服器上重新啟動，且運用最新資料。

隨著電子商務成長而開始採用專屬的應用軟體伺服器，必需謹慎地考慮交互式災後復原技術，當作企業成長管理策略的一部份。此一技術對於電子商務成長時增加的龐大硬體投資提供下列好處是：