针对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设计过程中相互配合，以确保平稳和可靠的实施。
