CDR - Continuous Data Replication SANsymphony Product Introduction CDR - Continuous Data Replication 連續式資料備份、災難復原與異地備援 Copyright 2000 DataCore Software Corporation

主機磁碟機故障之救援步驟 磁碟機發生故障，進行問題診斷 10 分鐘 聯絡服務廠商到場 4 小時 更換故障磁碟機 20 分鐘 磁碟機發生故障，進行問題診斷 10 分鐘 聯絡服務廠商到場 4 小時 更換故障磁碟機 20 分鐘 利用磁帶備份回復資料 3 小時 系統開啟，回復應用程式服務 10 分鐘 總停機時間：7.6 小時

其他延長停機時間之潛在因素 磁帶備份是否成功？ 磁帶復原是否成功 資料遺失程度？ 硬體故障排除與修復之複雜度

什麼是 DataCore CDR？ CDR = Continuous Data Replication 連續式資料複製與復原方案 同時適用於 WAN & LAN 網路環境，進行資料複製 主機磁碟機故障後，可於數分鐘內迅速回復應用程式服務，大幅縮短停機時間

採用 CDR 之系統救援方式 磁碟機發生故障，進行問題診斷 10 分鐘 利用 CDR 備份資料啟動系統與應用程式服務 5 分鐘 磁碟機發生故障，進行問題診斷 10 分鐘 利用 CDR 備份資料啟動系統與應用程式服務 5 分鐘 聯絡服務廠商到場 4 小時 更換故障磁碟機 20 分鐘 將 CDR 備份資料回復至本機磁碟機 3 小時 重新啟動系統，回復正常運作 10 分鐘 總停機時間：25 分鐘　 五分鐘即可恢復應用程式服務作業！

持續性資料複製 適用所有 Windows 系統（server & desktop） 針對系統本機磁碟進行持續性備份 透過 TCP/IP 網路備份至 CDR Server 可透過 iSCSI 迅速回復資料存取 不需改變系統原有儲存架構 Windows System + CDR Client OS Data IP Network (LAN or WAN) Continuous Disk-based Backup DataCore CDR Server OS Data

備份資料多版本控制 LAN SQL2000 DELL 2950 SQL2005 DELL 2850 SQL2000 DELL IBM x220 IBM x220 SQL2000 Compaq SQL2000 Compaq IBM OS Data CDR C/L OS Data CDR C/L OS Data CDR C/L OS Data CDR C/L OS Data CDR C/L OS Data CDR C/L OS Data CDR C/L OS Data CDR C/L OS Data CDR C/L OS Data CDR C/L LAN WSS2003 NAS DELL PV750 OS Data CDR C/L Snapshot OS' Data’ OS' Data’ 14:00 OS' Data’ DataCore CDR Server 16:00 18:00 OS' Data’

應用程式服務迅速回復（Local Area DR） 適用於區域環境的本地災難復原 可透過 IP 或 FC SAN 進行 SAN boot，不需進行資料回存，即可先爭取時效回復應用程式服務，之後再進行硬體維修 待故障磁碟機修復後，再以背景模式進行資料回存 資料回存完畢後，再擇期重新啟動系統，選擇以本地磁碟開機，即回復系統正常運作 Windows System OS Data IP or FC SAN iSCSI or FC SAN Boot DataCore CDR Server OS Data

無硬體特性限制的異機備援方案 可在不同硬體特性主機間實行系統備援 不受限於原始主機之硬體架構 Virtual Server 可在不同硬體特性主機間實行系統備援 不受限於原始主機之硬體架構 CDR 備份資料可直接透過 iSCSI 指派給虛擬主機開機作業，不需進行資料轉換 原始主機修復後亦可直接將服務移回，不需進行資料轉換 Windows System + CDR Client VM Virtual Servers OS Data OS Data IP or FC SAN Continuous Disk-based Backup DataCore CDR Server OS Data

Remote Data Replication 可快速部署的異地備援方案 可快速導入異地備援計劃，不需更動原有儲存架構 可在不同硬體特性主機間進行備援 採用 Asynchronous Replication 模式，不需使用 iSCSI 協定進行資料複製，對於網路頻寛與連線品質之容錯能力高 Windows Systems + CDR Client Virtual Server OS Data VM Virtual Servers WAN Continuous Remote Data Replication LAN / iSCSI DataCore CDR Server OS Data

兼具經濟與高效能之 iSCSI Boot 方案 可利用一般網路卡（支援 PXE 功能）進行 iSCSI boot，不需購買昂貴之 iSCSI HBA 卡 純粹軟體功能，設定簡單 資料存取效能佳，開機速度快，與 iSCSI HBA 卡無顯著差異

為何 CDR 適用於 WAN 環境之異地備援？ DataCore CDR 採用 Store-and-Forward 技術，備份資料首先儲存於本地 buffer，再透過 IP 網路傳送至 CDR Server IP 網路若中斷，只會影響資料傳送，資料備份作業仍持續進行，待傳資料也將暫存於 buffer 中，一旦網路恢復連線，即可接續原本狀態繼續傳送資料 對 IP 網路之容錯能力佳 其他類似產品（如 FalconStor CDP）則須先透過 SAN 指派磁碟機給主機，再透過鏡像軟體（DiskSafe）於主機進行 data mirroring，一旦 SAN 連線中斷，mirror 狀態將成為 out of sync，待 SAN 連線回復後，須先手動掃描磁碟機，再進行 mirror recovery，對本地磁碟與 SAN 磁碟機進行資料同步後，才能重新開始資料備份 若線路品質不穩定或頻寬負載過大，容易發生 SCSI 寫入指令之 retry timeout，導致寫入失敗，進而引發後續一連串複雜而耗時的人工 recovery 程序 以 WAN 特性而言，絕對無法提供所需之頻寬與線路品質（穩定性）

DataCore CDR 與 FalconStor CDP 比較 Server 作業系統 Windows （安裝維護簡單） Linux （安裝維護複雜麻煩） 可支援 Client 作業系統 資料備份網路 LAN or WAN （採用 Store-and-Forward 技術） IP or FC SAN （基於 SCSI 協定） 網路容錯能力 佳 （直接續傳資料即可） 差 （須經過複雜之 recovery 程序） 主機所需配備介面 Ethernet NIC 即可 FC or iSCSI HBA 支援 Caching I/O 加速功能 是 否 支援 Snapshot 版本控制 支援 Snapshot 排程 支援 Sync. Marker 適用於 LAN 環境災難復原 適用於 WAN 環境異地備援 Client Agent 分級 Server & Desktop Server & Desktop，Server 又區分為 Standard, Enterprise & Data Center 整體建置成本 適中 偏高

傳統資料庫備份之問題 ? ? ? ? ? Snapshot/File Backup FC/iSCSI Target Backup Agent Backup Server Snapshot/File Backup FC/iSCSI Target Backup Client Backup Agent DB/Snapshot Agent SQL 2000 Module (With SQL 2000 SP? API) SQL 2005 Module (With SQL 2005 SP? API) Exchange 2003 Module (With Exchange 2003 SP? API) Exchange 2007 Module (With SQL 2007 SP? API) Oracle 9g Module (With Oracle 9g SP? API) ? ? ? ? ? SQL 2000 SP3 SP4 SQL 2005 SP1 Exchange 2003 SP1 Exchange 2007 SP1 Oracle 9g SP1 傳統備份軟體必須利用個別應用程式所提供之 API 開發 DB 備份模組，但不同 Service Pack 與 Patch 版本之應用程式行為可能有些許差異，因此常發生因 API 版本相容性問題而影響應用程式運作之情況（實際發生案例：東Ｘ國際、Ｘ誠會計師事務所）

VSS 簡化備份軟體開發流程，降低軟體複雜性，提高軟體品質， CDR Server Snapshot AIM CDR Client AIM Client DataCore VSS Windows VSS Service SQL 2000 SP3 SP4 SQL 2005 SP1 Exchange 2003 SP1 Exchange 2007 SP1 Oracle 9g SP1 VSS 簡化備份軟體開發流程，降低軟體複雜性，提高軟體品質， 並確保應用系統穩定度與可靠性

Shell Scripting 確保最佳相容性與穩定度 CDR Server Snapshot AIM CDR Client AIM Client SQL 2000 Scripting (With SQL 2000 Commands) SQL 2005 Scripting (With SQL 2005 Commands) Exchange 2003 Scripting (With Exchange 2003 Commands) Exchange 2007 Scripting (With SQL 2007 Commands) Oracle 9g Scripting (With Oracle 9g Commands) SQL 2000 SP3 SQL 2000 SP4 SQL 2005 SP1 Exchange 2003 SP1 Exchange 2007 SP1 Oracle 9g SP1 Command Line Interface Command Line Interface Command Line Interface Command Line Interface Command Line Interface Command Line Interface 對同一版本應用程式而言，即使不同 Patch 與 Service Pack 版本之間其 CLI 之語法仍然相同，不影響 Shell Script 執行之正確性，且 CLI 原本即屬於應用程式之一部份，因此亦不會有相容性之問題，進而並確保應用系統穩定度與可靠性

案例檢討 – 東X國際 問題 在導入 FalconStor CDP 時，於 DB2 主機 DB2 Snapshot Agent，但在資料庫交易量較大時， Snapshot Agent 暫停資料庫並完成執行快照作業後，無法重新恢復資料庫運作，而須手動強迫關閉資料庫並重新啟動 根本問題在於，廠商於開發 Snapshot Agent 時所使用之 DB2 API 版本與用戶實際使用之 DB2 應用程式版本不一致。而即使版本一致，仍涉及程式撰寫方法之正確與否 在發生問題時，難以進行偵錯，找出問題之導因（皆為二進位執行碼），造成問題發生後延宕逾一年，遲遲無法解決，專案終究宣告失敗 解決方案 導入 DataCore CDR，並於 DB2 主機撰寫 Shell Script，透過 DB2 命令列指令呼叫 DB2 原生功能暫停資料庫，並在對 CDR Server 送出快照指令後，再次以 DB2 命令列指令呼叫 DB2 原生功能恢復資料庫運作 由於 DB2 命令列指令原本即屬於 DB2 應用程式之一部份，因此不會有相容性之問題 一旦發生問題，可經由簡易故障排除程序，找出產生錯誤之原因

Synchronization Marker 在非同步資料傳輸中維持資料同步之優雅方案 將資料流（data stream）與命令流（command stream）整合於同一資訊串流中，亦即所謂的 in-band 架構 In-band 架構確保資料傳輸與附加資料操作（如執行快照）乃基於相同之時序 以 FalconStor CDP（out-of-band 架構）為例 DiskSafe Agent 負責執行資料抄寫 Snapshot Agent 負責暫停／恢復資料庫運作，並通知 CDP Server 執行快照 DiskSafe 與 Snapshot Agent 之間，並無同步機制確保資料抄寫與指令執行之時序一致性 亦即在執行快照前，無法 100% 保證所有資料均已寫入磁碟機中，因此在資料庫交易量較大時，可能造成快照備份資料之不完整

資料流與資料操作指令之時序同步 FalconStor CDP DataCore CDR T0：Snapshot 指令傳送完成時間 Snapshot Command Synchronization Marker (Could be Snapshot Command) FalconStor CDP Client FalconStor CDP Server DataCore CDR Client DataCore CDR Server Snapshot Agent CDP Service VSS & Shell Scripting CDR Service Data Store Data Store DiskSafe Agent Data Stream AIM Client Data Stream T1 T0 T1 T0 T0：Snapshot 指令傳送完成時間 T1：資料傳送完成時間 T0 早於 T1，表示 Snapshot 指令執行時資料尚未傳送完畢 T0：資料傳送完成時間 T1：Snapshot 指令傳送完成時間 T0 早於 T1，表示資料傳送完畢後才會執行 Snapshot 指令

增加自動化作業之彈性 Flush Marker Snapshot Marker Custom Marker 強迫清除緩衝區資料 要求 CDR Server 執行快照更新作業 Custom Marker 可依用戶需求進行客製化，以自動執行特定之作業，例如： 執行特殊需求或複雜之快照作業 啟動磁帶備份作業 更新備援系統資料 啟動批次工作

DataCore 成功案例

DataCore CDR Case Study – 東貿國際 IBM x3650 (Standby Server ) Project Goal: Bare-metal system recovery for JDEdward ERP system with IBM DB2 Previous Issue: Initial deployment of FalconStor CDP (for over 1 year) failed due to incompatibility of DB2 and DB Agent. Product was returned to vendor after project failure DataCore Solution Deployed CDR backup (OS & application data) Multiple snapshot versions System recovery to original x365 server System recovery to new x3650 server Project Progress: Signed-off closed Status of Current Customer Environment: Up and running! IBM x365 (CDR Client ) JDEdward ERP + DB2 OS Data OS Data FC SAN LAN-based CDR Backup DataCore CDR Server OS Data