数据中心资源管理十分复杂。要保证虚拟机始终可用、确保快速的灾难恢复和可靠的故障恢复能力，需要很多技巧。
我们谈到了虚拟化领域的一些新技术，某些领域仍然缺乏有效的解决方案。在本文的第一部分，我们将讲述虚拟机备份的过程。在第二部分，进一步探讨虚拟环境下的故障恢复和集群。
备份
虚拟数据中心的备份和传统的备份没有太大的差别。先在每个子操作系统内安装备份代理，然后在其它位置复制虚拟机的文件、分区或整个虚拟磁盘。
这个方法很管用，但是在虚拟环境下应用这个方法时有一个很大的缺点，因为每台虚拟机使用的是主机操作系统的同一I/O通道。所以，如果多台虚拟机同时开始备份，难免会遇到I/O瓶颈。
为了防止这样的阻塞，管理员应该仔细地规划好备份，使各虚拟机备份之间有一定的时间差，以防止子操作系统在操作密集期间重叠造成拥挤。
不幸的是，这个方法不具可扩展性。也就是说，当有很多虚拟机时，不可避免的会有备份重叠。因为根据应用需求，如果每个虚拟磁盘数据达到20GB，那么每个备份可能要花好几个小时，所以难免会出现 备份时间上的重叠。
子操作系统备份在恢复时，管理员还有一些事要做。首先重建一台空虚拟机，然后从裸机恢复CD启动 虚拟机。
冒险的做法
此外，还有一个可选的方案是在主机层做子操作系统备份。
由于虚拟机是一个独立的单个文件，存储于主机操作系统的文件系统内，就跟一个电子数据表或图片 文件一样，所以许多虚拟化新手可能认为备份是件非常简单的事。然而，事实绝非如此，备份要比他们 想象的困难得多。
首先，虚拟机被认为是开放文件（open file），由一个进程或应用锁定（想想Microsoft Outlook的 .PST邮件存档文件）。这些文件只能通过特殊的方式访问——即冻结其状态镜像（我们通常 称作快照），然后执行备份。
备份软件只有知道了如何处理这些开放文件，才可能执行备份任务，尽管有时主机操作系统会协助备份。例如，Windows Server 2003有个功能叫做VSS（卷影拷贝服务），可以借助第三方解决方案执行快 照。
即使是知道如何处理这些开放文件，在执行在线备份时我们仍然还得面对另一个挑战：虚拟机不仅仅是开放文件，还是一个访问整套虚拟硬件的完整操作系统。
每次进行快照时，一切都会停止不动，包括虚拟内存和中断程序。这在虚拟领域里叫做断电，可能损坏子机文件系统结构。
有少数的厂商支持这种方法，即使有一个强大的操作系统在断电时不会造成数据损坏。Vizioncore是一款支持这种方法的产品，很受esxRanger的欢迎。esxRanger能够在VMware ESX Server中执行虚拟机在 线备份，而且提供了相当多的自动化过程。
Massimiliano Daneri发布了有名的VMBK script，尽管它们不支持这种方法，但还是勇敢地尝试了这个方法，也可以为VMware ESX Server虚拟机执行基本的在线备份。
微软将从知名的Service Pack 1开始，为它的Virtual Server 2005提供这种支持。不过，不会允许使用标准Microsoft Backup做备份。
最常用的备份方法
通常被接受，而且唯一真正被虚拟商认可的虚拟机方法是挂起或关闭正在运行的虚拟机，然后执行备 份和恢复或重启虚拟机。不幸的是，这个过程与具有高可用性的服务相抵触，使管理员不得不利用传统 的基于代理的备份方法备份关键任务虚拟机。
当操作系统更加适应虚拟化之后，在线备份问题最终将会得到解决。不过，值得注意的是，这第二种 方法也会给主机I/O通道带来一定的压力。
为了彻底地解决这个问题，我们必须将备份点从主机改为存储设施。在存储设施中操作虚拟机文件不 会直接影响虚拟化平台。
VMware是第一个使用这个解决方案的，不过现在它的产品VMware Consolidated Backup（VCB）有很 多值得注意的限制：只对ESX Server可用；只能作为第三方备份解决方案代理（使得用户不得不为不同 产品配置和安装不同的脚本）；而且它不能执行恢复过程。
在存储层，还有一种不同的备份方法：利用存储区域网络（SAN）管理软件和LUN克隆。通常，这个方 法提供的粒度（granularity）不够，因为存储设施不能识别LUN格式，因此不能提供单个虚拟机备份。
LUN格式识别取决于我们购买的存储管理软件，以及支持何种文件系统。它可能识别NTFS格式的LUN， 允许我们备份VMware Server的Windows虚拟机。然而，它可能不支持VMFS格式，我们就无法备份VMware ESX Server虚拟机。
如果LUN格式无法识别，或者我们没有任何好的存储管理解决方案，我们将只能克隆整个LUN。LUN内 包含多个虚拟机，即使只有其中一个虚拟机需要恢复，我们也只能同时恢复所有虚拟机。