备份虚拟服务器通常来说是一个相对简单的任务。大部分备份软件都能支持虚拟服务器的备份。然而，虚拟化数据中心中集群的备份却通常容易被忽视。

集群用于虚拟服务器的容错，如果一个物理服务器发生了故障，虚拟机可以切换到这个集群中的另一个节点。如果这台虚拟机没有使用集群技术，那么物理服务器的故障会导致虚拟机不可用。

除非你的备份软件是集群感知的，否则备份和还原的过程可能不会是你之前期望的那样。这篇文章讨论了在备份Windows故障转移集群的虚拟机时需要注意的一些重要事项。

不支持集群感知会带来什么问题？

你可能想知道当你在使用备份软件备份一台集群虚拟服务器时，你的软件无法感知集群会出现什么问题？虽然每个备份应用程序都不同，但通常备份过程都很成功。不过问题在于，如果你需要为一台虚拟机做一个完整还原，这台虚拟机在还原完成后将不再有容错功能。换句话说，这台虚拟机可以工作的很好，但如果物理服务器发生了故障，这台虚拟机就不能切换至另一个集群节点，尽管这台虚拟机运行在一个集群主机上。

在这种情况下你需要基于你的虚拟化平台重新做一次虚拟机容错。在微软的服务器环境中，你需要打开故障转移集群管理器手动将虚拟服务器设置为一个集群资源。

对集群进行备份需要考虑哪些因素？

很显然，使用集群感知的备份软件是很重要的，但只用备份软件来直接支持备份是不够的，虚拟机备份必须遵循微软设定的一些规则。

第一条规则是机器必须运行以及必须设置Quorum，这意味着集群中的大多数节点需要处于工作状态，并且能够与其他节点进行通信。在一般情况下，这个要求并没有什么问题。然而，这个规则并没有考虑到发生故障的情形。如果大多数集群中的节点发生了故障，集群失去了Quorum，那你在修复集群问题前就无法为你的虚拟机进行集群级别的备份。这种情况下，只能进行离线备份。

在规划备份方案时，另外一个需要考虑的重要问题是存储集群。在Windows Server 2012发布之前，虚拟机的故障转移集群需要一个能够被集群中所有节点访问的集群共享卷。在Windows Server 2012中，这个集群共享卷的要求没有了，但微软的最佳实践中仍然建议使用一个集群共享卷。

集群共享卷的状态为Reserved

假设你的故障转移集群使用了集群共享卷，这个存储架构将直接影响到备份流程。尽管集群中所有的节点都能访问这个共享的存储设备，但在一个时间点只能有一个集群中的节点能访问这个集群共享卷，并由激活的集群节点来控制。这个操作被磁盘管理控制器直接影响。如果这个集群节点处于激活状态，那么磁盘管理控制器会将集群共享卷显示为激活状态。否则，这个集群共享卷将被显示为保留状态（Reserve），就像图中显示的那样。

为什么这个集群共享卷如此重要呢？原因很简单，因为你的备份软件需要与这个存储了虚拟机的卷通信。如果你在一个独立的集群节点执行备份操作，那么在备份的时间段内只有在线的磁盘才会被加入到备份任务中。

还原一个集群节点

任何一个能够感知虚拟化的备份软件（除了Windows Server Backup）都应该允许你还原一台单独的虚拟机。不过在制定灾难恢复计划时，需要考虑到集群节点。

从很大程度上说，对一个集群节点执行还原是一个简单的过程。其中最重要的是要了解集群中的每个节点都维护了一份集群配置数据的拷贝。当你在一个故障转移集群节点执行一个普通的裸机还原时，这个还原过程会将集群节点恢复到一个不一定与当前状态一致的状态。然后这个新的被还原的集群节点会与集群中的其他节点进行通信，并从其中一个节点下载集群配置信息，然后这个被还原的节点就会进入当前运行的状态。

如果由于某些原因，这个集群配置数据被损坏了，那么就需要执行一个授权还原。它与普通还原类似，需要在开始时执行一个集群节点的裸机还原。与普通还原不同的是，一个授权还原不会尝试从集群中的其他节点获取集群配置数据，它会将被还原节点中的集群配置数据作为最新的拷贝。这个拷贝随后将被分发到集群中的其他节点，最终集群中的所有节点将使用相同的集群配置数据。

在Windows故障转移集群环境下执行虚拟机的备份和还原操作是非常简单的。但尽管如此，但仍需要保证备份软件是集群感知的，并且还要确保备份运行在激活的集群节点上。另外，还要确保备份策略包含对独立集群节点和集群配置数据的备份。