Exchange 2003设计和体系结构（19）

两段式备份解决方案

为了解决这些问题并支持服务器整合，OTG 设计了一个灵活的、两段式过程用于在多节点的集群配置中备份数据 － 磁盘到磁盘（阶段 1）和磁盘到磁带（阶段 2）。

OTG 充分利用了这样一个事实：在一个集群资源组中的资源能够在该资源组内移动而不依赖于其它的资源组。例如，一个集群 Exchange 服务器的一个活动节点除了连接到用于恢复生产数据的资源组外，还被连接到一个独立的专用备份 LUN 集群资源组。

在第一阶段，备份在集群内的所有活动节点上运行以完成在线的、磁盘到磁盘的备份，数据通过直接相连的光纤信道从生产数据资源组内的 LUN 到达备份资源组内的 LUN。备份资源组具有支持两条的在线保留的容量。一旦该过程完成，备份资源组中的 LUN 的控制被转移到一个备用的非活动节点。此时，非活动节点启动第二阶段，磁盘到磁带的备份，数据通过一个直接相连的光纤信道从备份资源组到达磁带库。这一过程将活动阶段从等待磁盘到磁带传输的时间中解放出来，从而将活动阶段用于处理数据备份操作的时间最小化。此过程如图 4 所示。

图 4：两段式备份过程
浏览全尺寸图像。

OTG 选择了这种两段式过程而没有选择使用直接光纤连接到磁盘库的、一段式的、磁盘到磁带的备份。虽然一段式过程不需要在 SAN 配置备份 LUN，从而可以在 SAN 中腾出更多额外存储用于更多的邮箱，但 OTG 认识到它无法承受当集群中的节点发生从磁带库断开连接的故障时损失宝贵的生产时间的风险。当发生这种故障时，节点服务器必须重启才能重新将服务器连接到磁带库。如果活动节点是, 执行此项工作的服务器，OTG 需要对该节点进行故障转移，以便使它能够重启并重新连接到磁带库。OTG 认为这对系统可用性是一个无法接受的风险。相反，通过在一个不支持用户的非活动节点上执行备份到磁带的工作，当该非活动节点需要重启以恢复服务器到库的连接时，不会造成生产服务的损失。

每数据库的在线备份被定期安排在晚上 8:00 到凌晨 1:30 之间，让 OTG 对每个服务器进行完全备份。数据库按每个 SG 同时备份。这里有一个重要的特性，Exchange 2003 允许在每 SG 的基础上进行并行备份与恢复操作。因此，对每个数据库的备份操作可以交替进行。

恢复解决方案

利用 OTG 的新集群解决方案，一个服务器硬件故障只是一次自动集群节点故障转移；服务几乎不受影响。如果发生磁盘故障，则需要根据故障范围和故障发生于一天中的哪个时段来实施不同的恢复方案。

方法不再依赖于方案

在过去，部署什么样的恢复方案取决于故障的类型和范围以及商务优先级。在 Exchange 2000 中，组织可以在下面两种方案中任选其一：快速恢复消息服务但放弃对旧的邮箱数据的立即访问，或者恢复对他们的服务的完全访问但需要花费更多的时间。

例如，如果一个数据库被丢失，最多可能会影响 200 个用户。因为磁盘上有最多达两天的备份数据，而且可以在一个小时内在线恢复（恢复速率最高为每分钟 2 GB），所以使用常规 Exchange 恢复过程来快速地在线恢复用户的邮箱数据。

注：每个 Exchange 数据库由两个文件组成： Exchange Database（EDB）文件和 Streaming Media（STM）文件。

在 Exchange 2000 中，如果整个 SG 丢失，那么故障在一天中哪个时段发生往往是决定如何处理的关键因素。如果故障在工作时间发生，那么恢复服务常常优先于恢复数据，后者可以在以后恢复。在该方案中，损坏的数据库被删除并重建（一个称为“清除数据库”的过程）。

如果故障发生在较晚的非工作时间，OTG 优先选择更快速地恢复所有丢失的数据，而牺牲立即恢复服务。在这种情况下，他们选择执行恢复而不清除受影响的数据库。

图 5 展示了 OTG 用于决定是先恢复服务后恢复数据还是同时恢复数据和服务的决策树。

图 5：OTG 生产恢复决策树
浏览全尺寸图像。