高可用性是當今存儲專業人士們最常使用的一大術語。 但是， 僅僅只是簡單的將資金和最新的技術投入到貴公司資料中心的存儲陣列上，
在本文中， 獨立顧問Ben Maas將為我們廣大讀者朋友們概述關於如何有效的保護企業應用程式， 避免導致發生資料丟失和停機的最常見原因的五大關鍵步驟， 這五大步驟分別是：
1、 瞭解您企業軟體的功能;
2、 瞭解您企業所有應用程式的執行時間要求;
3、 適當地調整您企業資料中心的環境;
4、 適當地調整貴公司資料存儲庫的規模大小和設置
5、 實施更完善的實踐方案
實踐步驟一 瞭解您企業的資料保護軟體
當前， 許多企業其實是在不瞭解其全部功能或限制條件的情況下使用了某些資料保護軟體。
如果您企業的備份軟體依賴於代理執行虛擬機器備份， 則其將更直接地與虛擬機器檔案系統配合使用。 在這種情況下， 備份軟體可能使用微軟的卷影複製服務(Volume Shadow Copy Service，
而如果您企業的備份軟體採用的是無代理的方式進行快照， 其可能仍然部分的依賴代理進行備份。 一款備份軟體在執行備份以調用微軟VSS創建快照時， 會暫時將一段軟體放入虛擬機器中。 為此， 其將使用VMware API啟動快照， 然後將該軟體代碼放置在虛擬機器上以創建快照。 一旦完成快照， 其將刪除安裝的代碼片段。
即使這種混合的虛擬機器備份方法也可能是不夠的。 在某些情況下， 備份軟體可能需要與特定的應用程式(如微軟Exchange或SQL Server)集成， 以將資料同步到磁片。 這將創建一個在恢復後可用的應用程式一致性備份。
同樣， 許多備份軟體產品也使用重復資料刪除技術來最大限度地降低存儲需求。
您企業的軟體所支援的選項將影響到您執行此操作所需的頻寬量， 以及在用戶端、媒介伺服器或磁片目標上所需要的處理能力量， 以對該資料進行重復資料刪除。
瞭解備份軟體的這些功能和局限性是非常重要的， 因為它們會影響備份和恢復所花費的時間， 並最終影響備份的可靠性。
超越備份和恢復關鍵任務應用程式應始終保持線上或盡可能保持始終線上狀態。
實踐步驟二 瞭解應用程式的正常執行時間要求
在瞭解了貴公司所採用的備份軟體的功能和使用限制條件後， 您需要瞭解每款應用程式的恢復目標。 一旦您確定了這些目標， 您就需要將它們映射回到軟體中可用的功能， 甚至是映射回您企業內部的流程中，以確保它們的一致性，並且可以根據業務需求保持這些應用程式的可用性。
例如，MySQL對於其資料的即時快照並沒有一種得到正式認可的方法。因此，您無法證明您的備份軟體能夠隨時將資料同步到磁片，以創建可恢復的快照。
備份MySQL的唯一經過驗證的方法是關閉MySQL(這對於需要100%正常執行時間的應用程式來說是沒有意義的)，或者製作該資料的副本，然後針對副本進行快照。像MySQL這樣的例子說明了企業為什麼需要瞭解您的資料在哪裡以及它是如何運行的，所以您企業不需要運行恢復來發現您正在丟失資料或者資料已經損壞了。
相反，諸如微軟SQL等軟體提供的API可以為您企業提供比MySQL更好的資料保護體驗。使用VSS卷影副本，企業可以避免這些問題。再次強調，企業需要確保您的備份軟體知道如何正確的調用API，以便驗證您的資料是否已寫入磁片，從而最大限度地減少並最理想地避免資料丟失或損壞的可能性。
這一步是非常重要的，特別是如果您企業正在處理需要備份軟體來加密存儲在驅動器或記憶體中的資料的應用程式。加密會創建一個額外的保護級別，並且您需要確保備份軟體在資料進入驅動器之前對其進行加密。許多提供商要求企業客戶自行管理並保留自己的加密金鑰。IT專業人員們有責任保護這些金鑰。如果您企業丟失了加密金鑰，則會丟失備份，二如果丟失了備份，則會造成資料丟失。
實踐步驟三 適當地調整您企業的資料備份環境
企業需要針對兩種類型的備份進行考慮，以便正確的調整貴公司資料備份環境的規模大小。
資料中心備份
資料中心的備份可能是最容易量化和規模化的。企業往往擁有專用的網路來備份這些應用程式伺服器，而這種備份流量甚至可能無法通過企業網路。生產應用程式資料可能受基於陣列的快照技術的保護，其中備份軟體啟動資料快照，這些快照短期存儲在陣列上，並由備份軟體管理。然後，備份軟體可以將該快照備份到磁片、磁帶或甚至雲中以進行長期保存。在企業資料中心中使用的更複雜的備份軟體往往可以更輕鬆地對託管在資料中心中的應用程式進行備份。
當企業開始探討應用程式的備份位置位於資料中心之外(無論其是您企業資料中心建築的其他位置，園區還是遠端位置)時，恰當的調整備份和恢復環境的規模將變得更加困難。
如果通過LAN連接進行本地備份，則需要驗證在備份視窗期間是否有足夠的電腦資源和網路頻寬，以避免中斷生產應用程式。由於備份是往往在下班時間運行的，所以這通常並不是一個不能克服的問題。
但是，如果您企業在核心資料中心之外運行24x7運行的應用程式，並且該應用程式沒有需求低活躍的時間段，則可能需要升級這些伺服器上的計算資源，或者需要為這些應用程式提供額外的網路頻寬，以確保其備份和恢復可以在計畫的備份視窗內發生。您可能還需要考慮更高級的備份工具，例如高可用性解決方案(HA)。 HA技術使用即時的容錯移轉功能來確保任務關鍵型應用程式和資料的正常執行時間要求。
遠端備份
如果您企業需要在遠端位置通過WAN連接來備份或恢復應用程式的運行，其挑戰將變得更加嚴峻。除了確保擁有可用的計算和網路資源來備份和恢復資料外，還需要驗證是否可以及時恢復資料;否則就無法達到您企業的恢復目標。
唯一真正知道其是否可行的方法是在生產環境中進行測試。
當您企業這樣做時，請務必考慮在執行備份或恢復時可能在您備份環境中遇到的某些變數。例如，如果要通過VPN管道運行備份或恢復，則輸送量將會下降。另外，在通過LAN或WAN連結發送資料之前，是否需要加密資料?如果是這樣的話，請驗證對資料進行加密的設備是否可以及時執行以滿足您的備份或恢復服務級別協定。
還有需要注意的一點是，存儲備份資料的磁片必須足夠快才能滿足備份和恢復需求。我曾遇到過企業有眾多機器同時寫入或讀取資料的情況，從而導致了處理速度變慢。
考慮您企業可能有24台機器需要在24小時內恢復的情況。您企業可能不會嘗試逐一的對它們進行恢復。您將要並行恢復它們。同時還需要確保從中恢復資料的存放裝置可以處理滿足這些需求所需的I / O量。再次強調，有計算器可以幫助企業執行這些類型的評估，但我發現唯一的方法是肯定的是在您企業的環境中自行測試一下。
實踐步驟四 適當地調整資料存儲庫的大小和設置
我曾遇到過這樣的情況：軟體提供商對可以存入某存儲庫的資料量有嚴格的限制。例如，備份軟體提供商可能會強制規定2 TB的限制(或對單個備份存儲庫有其他限制)，這可能會迫使企業客戶需要將備份分散到多個存儲庫。
如果企業同時運行多個恢復流，這將起到作用。在這種情況下，您企業需要確保存儲庫可以快速讀取資料，以滿足您的恢復時間目標(RTO)。
有很多供應商能夠提供規模化的文檔，對於為您企業的環境適當地調整存儲庫的大小是非常有幫助的。您只需要確保您已經配置了足夠的存儲庫，並同時使其可用。
在備份過程中，對資料進行重復資料刪除時，使得這些存儲庫具備適當的規模大小尤為重要。
另外請注意，供應商使用備份代理來更接近虛擬主機上的存儲。在這種情況下，您企業需要確保已經進行了恰當的調整，以確保您企業擁有足夠的RAM、CPU和本機存放區，進而避免在備份或恢復過程中的某個時刻出現瓶頸。
我也曾經用作資料庫伺服器的虛擬機器，其承載了7到8TB的數據。有時候這些規模的虛擬機器會試圖從一個存儲庫中恢復這些資料。在這種情況下，由於輸送量不足，便成了一個真正的問題。只有在將資料分發到多個存儲庫之後，才能夠及時恢復資料，因為企業使用者可以同時在多個驅動器上運行恢復。
實踐步驟五 實施更完善的實踐方案
實施更完善的實踐方案。這意味著您企業應該運行多個測試。您企業絕不會完全意識到一個恢復過程具體會涉及到多少的遷移片斷，直到您真正執行了一次恢復過程之後。也許最複雜的是那些涉及從地理上分散的備份中所執行的恢復。在這些情況下，您需要運行恢復測試來確保您所想要的一切都將發生。
大多數情況下，我在測試過程中會遇到一些我從來沒有考慮過有發生可能性的問題。有一次，我遇到了一個軟體許可的問題。在測試期間恢復應用程式之後，應用程式軟體必須核實其許可授權。在遠端預警(call-home)過程中，授權軟體檢測到自從我在測試伺服器上運行應用程式以來，託管軟體的伺服器的IP位址發生了變化。然後其使軟體許可無效。雖然這很不方便，但是這成為了一個生產問題，因為它使軟體許可證在測試和生產中運行的軟體的副本無效。這種疏忽破壞了生產環境。
從測試開始自信地恢復您企業的環境。
這導致了我如何進行災難恢復測試方面的變化。現在，當我提出測試環境時，我會關閉出站的網路流量。在這段時間裡，我會看看有什麼流量是出站的，以確保沒有軟體試圖遠端報障預警，可能會在測試或生產環境中無意中造成中斷。這可能代表了我在一定程度上的偏執，我不一定告訴其他人也要這麼極端。然而，一朝被蛇咬十年怕井繩。我個人發現在恢復過程中軟體許可是一個問題。
企業需要執行測試的另一個很好的例子是確保資料可以恢復。我曾經供職過的一家公司在其微軟SQL伺服器上創建了一款“X”驅動器或檔共用。然後每週執行一次將資料備份到該 “X”驅動器上。然而，我對此其實並不知道，而公司的另一位同事是知道這款“X”驅動器的，並清楚其用來幹什麼的，所以他決定用它來在兩台SQL Server資料庫伺服器之間執行一些複製，其在那時的運行良好。
但過了一段時間後，公司更改了備份程式，並決定其SQL 伺服器不再需要這些資料庫伺服器上的“X”驅動器。 我對系統進行了評估，並將“X”驅動器放在整個環境中。而我們結束時，那位在在兩台SQL Server資料庫伺服器之間執行複製任務的同時開始沖著我們咆哮：“為什麼複製被中斷了?”
甚至是映射回您企業內部的流程中，以確保它們的一致性，並且可以根據業務需求保持這些應用程式的可用性。例如，MySQL對於其資料的即時快照並沒有一種得到正式認可的方法。因此，您無法證明您的備份軟體能夠隨時將資料同步到磁片，以創建可恢復的快照。
備份MySQL的唯一經過驗證的方法是關閉MySQL(這對於需要100%正常執行時間的應用程式來說是沒有意義的)，或者製作該資料的副本，然後針對副本進行快照。像MySQL這樣的例子說明了企業為什麼需要瞭解您的資料在哪裡以及它是如何運行的，所以您企業不需要運行恢復來發現您正在丟失資料或者資料已經損壞了。
相反，諸如微軟SQL等軟體提供的API可以為您企業提供比MySQL更好的資料保護體驗。使用VSS卷影副本，企業可以避免這些問題。再次強調，企業需要確保您的備份軟體知道如何正確的調用API，以便驗證您的資料是否已寫入磁片，從而最大限度地減少並最理想地避免資料丟失或損壞的可能性。
這一步是非常重要的，特別是如果您企業正在處理需要備份軟體來加密存儲在驅動器或記憶體中的資料的應用程式。加密會創建一個額外的保護級別，並且您需要確保備份軟體在資料進入驅動器之前對其進行加密。許多提供商要求企業客戶自行管理並保留自己的加密金鑰。IT專業人員們有責任保護這些金鑰。如果您企業丟失了加密金鑰，則會丟失備份，二如果丟失了備份，則會造成資料丟失。
實踐步驟三 適當地調整您企業的資料備份環境
企業需要針對兩種類型的備份進行考慮，以便正確的調整貴公司資料備份環境的規模大小。
資料中心備份
資料中心的備份可能是最容易量化和規模化的。企業往往擁有專用的網路來備份這些應用程式伺服器，而這種備份流量甚至可能無法通過企業網路。生產應用程式資料可能受基於陣列的快照技術的保護，其中備份軟體啟動資料快照，這些快照短期存儲在陣列上，並由備份軟體管理。然後，備份軟體可以將該快照備份到磁片、磁帶或甚至雲中以進行長期保存。在企業資料中心中使用的更複雜的備份軟體往往可以更輕鬆地對託管在資料中心中的應用程式進行備份。
當企業開始探討應用程式的備份位置位於資料中心之外(無論其是您企業資料中心建築的其他位置，園區還是遠端位置)時，恰當的調整備份和恢復環境的規模將變得更加困難。
如果通過LAN連接進行本地備份，則需要驗證在備份視窗期間是否有足夠的電腦資源和網路頻寬，以避免中斷生產應用程式。由於備份是往往在下班時間運行的，所以這通常並不是一個不能克服的問題。
但是，如果您企業在核心資料中心之外運行24x7運行的應用程式，並且該應用程式沒有需求低活躍的時間段，則可能需要升級這些伺服器上的計算資源，或者需要為這些應用程式提供額外的網路頻寬，以確保其備份和恢復可以在計畫的備份視窗內發生。您可能還需要考慮更高級的備份工具，例如高可用性解決方案(HA)。 HA技術使用即時的容錯移轉功能來確保任務關鍵型應用程式和資料的正常執行時間要求。
遠端備份
如果您企業需要在遠端位置通過WAN連接來備份或恢復應用程式的運行，其挑戰將變得更加嚴峻。除了確保擁有可用的計算和網路資源來備份和恢復資料外，還需要驗證是否可以及時恢復資料;否則就無法達到您企業的恢復目標。
唯一真正知道其是否可行的方法是在生產環境中進行測試。
當您企業這樣做時，請務必考慮在執行備份或恢復時可能在您備份環境中遇到的某些變數。例如，如果要通過VPN管道運行備份或恢復，則輸送量將會下降。另外，在通過LAN或WAN連結發送資料之前，是否需要加密資料?如果是這樣的話，請驗證對資料進行加密的設備是否可以及時執行以滿足您的備份或恢復服務級別協定。
還有需要注意的一點是，存儲備份資料的磁片必須足夠快才能滿足備份和恢復需求。我曾遇到過企業有眾多機器同時寫入或讀取資料的情況，從而導致了處理速度變慢。
考慮您企業可能有24台機器需要在24小時內恢復的情況。您企業可能不會嘗試逐一的對它們進行恢復。您將要並行恢復它們。同時還需要確保從中恢復資料的存放裝置可以處理滿足這些需求所需的I / O量。再次強調，有計算器可以幫助企業執行這些類型的評估，但我發現唯一的方法是肯定的是在您企業的環境中自行測試一下。
實踐步驟四 適當地調整資料存儲庫的大小和設置
我曾遇到過這樣的情況：軟體提供商對可以存入某存儲庫的資料量有嚴格的限制。例如，備份軟體提供商可能會強制規定2 TB的限制(或對單個備份存儲庫有其他限制)，這可能會迫使企業客戶需要將備份分散到多個存儲庫。
如果企業同時運行多個恢復流，這將起到作用。在這種情況下，您企業需要確保存儲庫可以快速讀取資料，以滿足您的恢復時間目標(RTO)。
有很多供應商能夠提供規模化的文檔，對於為您企業的環境適當地調整存儲庫的大小是非常有幫助的。您只需要確保您已經配置了足夠的存儲庫，並同時使其可用。
在備份過程中，對資料進行重復資料刪除時，使得這些存儲庫具備適當的規模大小尤為重要。
另外請注意，供應商使用備份代理來更接近虛擬主機上的存儲。在這種情況下，您企業需要確保已經進行了恰當的調整，以確保您企業擁有足夠的RAM、CPU和本機存放區，進而避免在備份或恢復過程中的某個時刻出現瓶頸。
我也曾經用作資料庫伺服器的虛擬機器，其承載了7到8TB的數據。有時候這些規模的虛擬機器會試圖從一個存儲庫中恢復這些資料。在這種情況下，由於輸送量不足，便成了一個真正的問題。只有在將資料分發到多個存儲庫之後，才能夠及時恢復資料，因為企業使用者可以同時在多個驅動器上運行恢復。
實踐步驟五 實施更完善的實踐方案
實施更完善的實踐方案。這意味著您企業應該運行多個測試。您企業絕不會完全意識到一個恢復過程具體會涉及到多少的遷移片斷，直到您真正執行了一次恢復過程之後。也許最複雜的是那些涉及從地理上分散的備份中所執行的恢復。在這些情況下，您需要運行恢復測試來確保您所想要的一切都將發生。
大多數情況下，我在測試過程中會遇到一些我從來沒有考慮過有發生可能性的問題。有一次，我遇到了一個軟體許可的問題。在測試期間恢復應用程式之後，應用程式軟體必須核實其許可授權。在遠端預警(call-home)過程中，授權軟體檢測到自從我在測試伺服器上運行應用程式以來，託管軟體的伺服器的IP位址發生了變化。然後其使軟體許可無效。雖然這很不方便，但是這成為了一個生產問題，因為它使軟體許可證在測試和生產中運行的軟體的副本無效。這種疏忽破壞了生產環境。
從測試開始自信地恢復您企業的環境。
這導致了我如何進行災難恢復測試方面的變化。現在，當我提出測試環境時，我會關閉出站的網路流量。在這段時間裡，我會看看有什麼流量是出站的，以確保沒有軟體試圖遠端報障預警，可能會在測試或生產環境中無意中造成中斷。這可能代表了我在一定程度上的偏執，我不一定告訴其他人也要這麼極端。然而，一朝被蛇咬十年怕井繩。我個人發現在恢復過程中軟體許可是一個問題。
企業需要執行測試的另一個很好的例子是確保資料可以恢復。我曾經供職過的一家公司在其微軟SQL伺服器上創建了一款“X”驅動器或檔共用。然後每週執行一次將資料備份到該 “X”驅動器上。然而，我對此其實並不知道，而公司的另一位同事是知道這款“X”驅動器的，並清楚其用來幹什麼的，所以他決定用它來在兩台SQL Server資料庫伺服器之間執行一些複製，其在那時的運行良好。
但過了一段時間後，公司更改了備份程式，並決定其SQL 伺服器不再需要這些資料庫伺服器上的“X”驅動器。 我對系統進行了評估，並將“X”驅動器放在整個環境中。而我們結束時，那位在在兩台SQL Server資料庫伺服器之間執行複製任務的同時開始沖著我們咆哮：“為什麼複製被中斷了?”