隨著虛擬化數(shù)據(jù)中心和全天候運營時代的來臨，我們需要重新思考傳統(tǒng)的數(shù)據(jù)保護方法。本文列舉虛擬服務器數(shù)據(jù)保護的五大挑戰(zhàn)。

虛擬化過程中的數(shù)據(jù)保護問題

服務器虛擬化的優(yōu)勢顯著，并且正在推動向大規(guī)模虛擬服務器部署的“遷移”。從借助服務器整合實現(xiàn)的成本節(jié)約到新興私有和公共云架構(gòu)的靈活性及敏捷性，虛擬化技術正以無可比擬的優(yōu)勢迅速成為現(xiàn)代數(shù)據(jù)中心的基石。

然而，虛擬服務器部署也會產(chǎn)生意想不到的數(shù)據(jù)存儲和保護后果。物理服務器和網(wǎng)絡的整合產(chǎn)生了大規(guī)模融合的 IT 基礎設施，致使本已有限的資源更加稀缺。10：1 的典型服務器整合率意味著，即使面對日常 IT 管理任務（如備份和恢復），可供使用的資源也很少。除了資源較少外，數(shù)據(jù)的大規(guī)模增長與虛擬機數(shù)量的日益增多致使越來越多的整合數(shù)據(jù)需要得到管理和保護。目前，虛擬服務器在成本節(jié)省、靈活的應用程序設置以及正常運行方面的優(yōu)勢正促使客戶在虛擬機環(huán)境中部署越來越多的關鍵應用程序。這些關鍵應用程序通常伴隨著要求最為嚴苛的服務水平協(xié)議 （SLA），涉及應用程序正常運行、數(shù)據(jù)恢復點和快速恢復時間等問題。

隨著虛擬化數(shù)據(jù)中心和全天候運營時代的來臨，我們需要重新思考傳統(tǒng)的數(shù)據(jù)保護方法。數(shù)據(jù)保護和數(shù)據(jù)恢復必須對前端生產(chǎn)系統(tǒng)（被保護的數(shù)據(jù)來源）具有最低限度的影響，而且不能僅僅依賴舊有磁帶備份連續(xù)寫入的方法將數(shù)據(jù)從生產(chǎn)系統(tǒng)復制到后端系統(tǒng)�，F(xiàn)代化的有效解決方案能夠最大限度降低生產(chǎn)系統(tǒng)負載、減少管理工作、增強數(shù)據(jù)保護和恢復、簡化向虛擬化數(shù)據(jù)中心的過渡，以及在需要的時候支持基于云的選項。

虛擬服務器數(shù)據(jù)保護的挑戰(zhàn)

1. 備份窗口爆炸性增長：服務器的高度整合和較高的虛擬機 （VM） 密度將數(shù)據(jù)所有權(quán)集中于少量物理服務器，這些服務器占據(jù)了僅用于產(chǎn)生工作量的絕大部分資源。因此，只有很少的資源可用于傳統(tǒng)管理任務，如在固定窗口內(nèi)通過網(wǎng)絡移動數(shù)據(jù)的備份任務。在全新的統(tǒng)一、虛擬化環(huán)境中，存儲和備份團隊需要能夠在較短的時間內(nèi)以極少的計算方式、網(wǎng)絡和存儲資源保護不斷增長的大型數(shù)據(jù)庫。

隨著服務器資源持續(xù)整合以及虛擬環(huán)境變得越發(fā)集中，虛擬機所擁有的數(shù)據(jù)量也在不斷飆升。虛擬環(huán)境所擁有的、管理和保護的數(shù)據(jù)量大量激增，使得傳統(tǒng)的磁帶備份連續(xù)寫入方法本就無力應付的局面更加惡化，這樣的案例隨處可見。比如，采用傳統(tǒng)的磁帶備份連續(xù)寫入方法，成功備份數(shù) TB 數(shù)據(jù)庫所需時間超過了 24 小時，遠未達到現(xiàn)代化數(shù)據(jù)中心的要求。

每個虛擬機實際上都是一套大型的文件設施（即在VMware環(huán)境下的VMDK），而這些大型的文件通常被存儲于LUNs就是熟知的數(shù)據(jù)存儲。傳統(tǒng)的數(shù)據(jù)保護技術例如VMware的數(shù)據(jù)保護vStorage API（VADP），或者VMware Consolidated Backup （VCB）都要依靠外部代理來保護與虛擬服務器相關聯(lián)的VMDK文件。雖然 VADP 顯著提升了這一流程的效率，但是它是將鏡像文件從數(shù)據(jù)庫移至備份磁盤進行保護，因此仍然是磁帶備份連續(xù)寫入方法。對于備份窗口日漸減少的環(huán)境，則根本沒有足夠的時間或帶寬來移動所有 VM 數(shù)據(jù)。即使基礎設施可用于復制所有數(shù)據(jù)，也會在讀取數(shù)據(jù)時為數(shù)據(jù)庫帶來極大的負擔。

2. 虛擬機數(shù)據(jù)未受保護：部署新虛擬機的便捷性導致虛擬機“泛濫”，管理員要采取繁瑣步驟并耗費大量時間跟蹤新虛擬機，以確保對其使用正確的數(shù)據(jù)保護和保留策略。創(chuàng)建重要的虛擬機但從不備份會帶來巨大風險�，F(xiàn)在，許多管理員要花費工作日當中的大部分時間來跟蹤新虛擬機并手動應用數(shù)據(jù)保護策略。在擁有成百上千臺虛擬機的現(xiàn)代數(shù)據(jù)中心，這種人工確保虛擬機保護策略的方法根本無法適應現(xiàn)狀發(fā)展要求的。

3. 應用程序缺少必要的集成：隨著越來越多的任務關鍵型應用程序（例如 SQL、Exchange 和 Oracle）的虛擬化，有必要為這些應用程序提供與其在純粹物理服務器設置同等水平的保護和恢復，同時使其停留在高度統(tǒng)一、虛擬化環(huán)境的約束下�，F(xiàn)代化數(shù)據(jù)中心需要一種可提供一定程度應用程序和虛擬化平臺感知的數(shù)據(jù)保護解決方案，以提供一致的備份和恢復功能，這將最大限度確保這些關鍵應用程序的正常運行。

4. 多恢復點挑戰(zhàn)：伴隨著數(shù)據(jù)的高增長和高變化率，依賴前一晚的備份進行恢復已遠遠不夠。此外，企業(yè)在虛擬服務器環(huán)境中部署的關鍵應用程序越來越多，他們需要數(shù)小時的恢復點目標 （RPO）。換言之，能夠恢復到幾小時以前（而不是前一晚）的備份是十分必要的，從而實現(xiàn)最小化數(shù)據(jù)丟失并減輕因中斷而對企業(yè)造成的影響。在不影響生產(chǎn)活動的情況下創(chuàng)建頻繁的恢復點是一項巨大挑戰(zhàn)。

5. 缺乏小顆粒數(shù)據(jù)的恢復能力：為了進一步加快恢復，企業(yè)需要一個在卷、文件或應用程序?qū)ο蠹墑e恢復小顆粒的數(shù)據(jù)/文件集成方法。從虛擬機數(shù)據(jù)庫恢復單個電子郵件或文件的能力對于確保應用程序正常運行、滿足可用性及正常運行服務等級協(xié)議 （SLA） 至關重要。傳統(tǒng)方法需要回到整個虛擬機數(shù)據(jù)庫（例如 VMDK）并搜索全部內(nèi)容以找到單個用戶電子郵件，十分耗時并且占用大量資源，并非一個切實可行的解決方案。目前，有許多支持文件和對象級恢復的新方法問世，但是，它們可能需要二次操作以獲取所需小顆粒數(shù)據(jù)/文件，進而增加了數(shù)據(jù)保護過程中的額外處理時間，風險也隨之而來。因為，能夠提供深入到文件或?qū)ο蠹壍臄?shù)據(jù)顆�；謴瓦x項，并且只需單次備份和恢復操作即可實現(xiàn)，這樣的解決方案是目前最需要的。