針對VMware vCenter Site Recovery Manager (SRM)業務決策的復雜度,通常不只局限于技術成分。事實上，技術配置絕大部分取決于企業所作的IT之外的業務決策。

　　很多由業務驅動的SRM設計都采用標準的災難恢復規劃。這包括指定運行關鍵任務的服務器以及將備份保存的時間。但不幸的，有些VMware SRM決定涉及了企業內部的政治，難以妥協以及過于細致的規劃。

　　VMware SRM的恢復時間目標（RTO）

　　恢復時間目標（Recovery Time Objective, RTO)是一個系統在發生災難后必須得到恢復的時間長度。這個變量決定哪些虛擬機在VMware SRM恢復計劃中首先啟動。SRM很容易從技術角度來配置虛擬機的重要性。但是直到企業勾畫出一個合適的順序，IT團隊只能猜測哪些虛擬機需要首先得到恢復。

　　一旦企業決定了整個系統的RTO，IT部門必須將其轉換為具體服務器的RTO。大多數企業擁有多臺服務器并存在各種關聯。例如，一個公司可能不為域控制器和反病毒管理系統定義RTO。但是架構中的每臺服務器都以某種方式與他們關聯著。因此確保這些服務器獲得合適的優先級，是SRM實施團隊的任務。

　　恢復點目標（RPO）

　　另一個商業決定是恢復點目標（Recovery Point Objective, RPO）。它定義了災難后一個系統可以接受的以時間為單位的數據損失量。傳統上，RPO同時定義了服務器備份的頻率。但是當應用到SRM實施中來，RPO決定了在主備站點陣列間的復制頻率。

　　在設計虛擬機數據存儲以及存儲復制之前，一項很重要的業務決定是為每個應用定義RPO。虛擬化管理員們接下來能夠將相近RPO的服務器歸組并配置到同一套存儲卷中。然后他們可以根據RPO為每個存儲卷配置合適的復制計劃。要注意的是，如果將VMware SRM引進到現有的vSphere架構中，這個過程可能需要對存儲系統的重設計以及遷移。

　　沒有RTO以及RPO？

　　如果你的公司沒有常規的災難恢復規劃工作以確定你所有系統的RTO以及RPO，那么你要為一個較長的過程做準備。由于RTO以及RPO涉及到內部的政治，技術局限，個人決定以及系統交互，定義它們是很費時間的。

　　保持這些RTO以及RPO的定義，與你公司的業務部門進行常規的溝通，對系統優先級的變化保持更新是同樣重要的。VMware SRM以及存儲管理員們必須有合適的時間來實施這些變化。

　　最重要的是IT和業務部門在VMware SRM設計過程中相互配合，以確保平穩和可靠的實施。