Exchange Server 数据保护与灾难恢复.docx
《Exchange Server 数据保护与灾难恢复.docx》由会员分享，可在线阅读，更多相关《Exchange Server 数据保护与灾难恢复.docx（13页珍藏版）》请在冰点文库上搜索。
ExchangeServer数据保护与灾难恢复
MicrosoftExchangeServer的设计考虑了备份因素。
组织需要备份其邮件数据，同时还必须能够恢复这些信息。
为满足这些要求，Microsoft构建了一整套数据保护选项，从传统的
备份和低端的恢复到操作连续性，直至可提供最高水平的可用性和灾难恢复功能的真正业务连续性解决方案。
在本文中，我将介绍这些选项并帮助您决定如何为您的组织实施最佳Exchange恢复解决方案。
级别1：
基本备份和恢复
您可以在数据库脱机后备份Exchange文件，也可以在数据库正在运行时进行备份。
实际上，更多情况下建议采用后一种方式来备份Exchange。
但Exchange不仅仅是一组文件。
它是包含大型数据库文件和事务日志的信息存储区。
发送给Exchange的邮件消息会立即记录在事务日志中，当系统进入某些空闲周期时（通常在若干毫秒之后），这些消息将复制到数据库中。
Exchange通过将信息尽快存储到磁盘，来提供高水平的恢复功能。
恢复Exchange最根本的是这两组信息的可用性。
一旦系统出现故障，则需要结合使用上一次备份以及该备份点之后发生的所有事务，将Exchange恢复为最近的信息。
注意，Exchange会根据需要自动将事务重新播放到恢复的数据库中。
备份程序访问Exchange数据库信息的方式是通过可扩展存储引擎（ESE）备份API或更新的VSS解决方案（稍后我将介绍这些新的解决方案）。
只要启动ESE备份，Exchange就会暂时挂起向其数据库进行的所有写入。
在ESE暂时将数据库设置为只读模式以便能够在完整备份过程中对其进行复制的同时，它还会使用一个临时数据库来保存在备份过程中发生的新事务。
当备份完成后，ESE会将数据库返回正常的读/写模式，并应用累积在临时数据库中的事务。
成功完成备份后，最后还会清除掉旧的事务日志。
即使对于在半夜时分备份正在进行时登录的用户，此备份过程也是直接和透明的；虽然如此，ESE仍然需要很长时间才能完成，特别是因为Exchange数据库的规模跨度很大，可以从几千兆字节到可管理的30到50GB，甚至高达100GB——如果使用标准技术，几乎一整夜也无法完成备份。
要初步了解使用NTBackup.exe时的可用选项，请看一下图1。
图1使用NTBackup实用工具
Exchange最佳实践
如果希望能够迅速从常见硬件和系统故障中恢复，应在夜间运行完整的Exchange备份。
为改进Exchange服务器使用本地磁盘时的性能和恢复能力，应使用单独的RAID阵列来存储Exchange数据库和Exchange事务日志，这一点很重要。
这样，如果RAID阵列控制器出现故障，或者如果阵列中的多个磁盘出现故障，使得剩余磁盘无法再重新构造条块化的数据时，您仍然能够进行恢复。
如果丢失了事务日志，您仍然可以在其他驱动器上获得最新的Exchange数据库，从而能够继续使用新事务日志进行正常操作。
如果丢失了数据库驱动器，此时的恢复策略应是返回到前一夜的Exchange数据库的完整备份，然后应用当前日期的事务日志使之保持最新状态。
限制Exchange数据库的大小非常重要，以便能够以合理的用时备份每个数据库——更重要的是，能够进行恢复。
对多数组织来说，这意味着需要使数据库的大小保持在30到50GB之间。
如果数据库超出该大小，则建议将其拆分成多个小数据库，以便能够对恢复进行管理。
备份和恢复连续性
数据库和事务日志的放置位置非常重要——不仅仅是对于备份性能，还事关恢复速度。
今天，所有服务器都支持各种级别的磁盘驱动器冗余（称为RAID）。
从基本上讲，RAID使得磁盘驱动器出现故障时不会导致系统崩溃，但在更换和重建磁盘之前系统性能会降低。
在此期间，为响应每个磁盘的访问请求，阵列控制器必须动态地使用剩余磁盘重新构建数据。
有关邮箱服务器存储设计的详细信息，请参阅MicrosoftITShowcase文章“ExchangeServer2007的64位应用”。
Exchange的核心功能是其单实例数据库设计。
这意味着在一个Exchange数据库中，只会存储一个特定邮件消息副本以及一个附件（如果有）。
如果该邮件是发送给同一信息存储区中的多个收件人，则会创建指向相应对象（邮件、附件）的附加指针，但不会复制对象。
这不仅对提高传送效率很有好处，还可以为Exchange节省磁盘和磁带空间。
由于Exchange只擅长恢复整个数据库，因而单个邮箱、文件夹或邮件的恢复会要求先恢复整个磁带。
毫无疑问，用户会希望具备更小单位的恢复能力。
磁带的这种单实例特性使之非常难以实现。
针对此需求，备份服务供应商采用了“程序块级备份”（Brick-LevelBackup）技术（本人并不建议采用此技术）。
使用认可的ESE备份API完成Exchange的完整备份后，备份产品会将每个邮箱添加到备份磁带上。
因为该备份API并未提供一种从单个邮箱中提取数据的方式，所以使用了MAPI。
结果，备份磁带由于复制了所有邮件和附件而变得非常长。
Microsoft提供了一些增强功能，可部分解决这一问题。
例如，管理废纸篓（或转储程序）会在用户将某些数据删除后，将其保留一段时间，以防再次需要。
此外，不再需要保留一个备用服务器作为Exchange恢复林；恢复存储组允许管理员部分装载从磁带上取回的已恢复数据库，并将数据复制或合并至邮箱级别。
熟能生巧
许多组织都曾领教过一项艰巨的任务，即不管决定在哪个级别上进行备份和恢复，都必须定期对备份媒体和恢复过程进行测试。
许许多多管理员都是在灾难发生后才知道其备份技术和恢复过程是否能够正常工作。
最佳的测试时间是在建立和配置了崭新的服务器之后，当它已经开始作为Exchange组织的一部分运行，但上面只有很少的用户时即开始。
此时，您应当执行一次Exchange完整备份，并定期备份您的驱动器，此外还要捕获系统的状态，其中包括系统磁盘上的重要文件和IIS元数据库（其中存储了Exchange的路由配置）。
然后，小心地重新格式化该新服务器并重新启动，更新最初构建服务器时获取的注释。
您应当能够从系统状态中恢复设置，同时还要具有足够的文档来手动重新实施系统配置的设置。
在这种“消防演习”上花些时间可显著减少将来的恢复操作所需的时间。
您应当定期重复此过程。
执行此任务时，可记下从离站位置获取磁带所需的时间。
那些在此期间不得不耐心等待的用户经常会开始认真考虑磁盘到磁盘备份在其备份和恢复策略中所能起到的重要作用——即使离站磁带存储仍然为灾难恢复提供了最终支撑。
磁带备份面临的挑战
从磁带中恢复需要很长时间。
现在，Exchange对于组织来说是如此重要，以致于用户和管理者希望它能够始终处于可用状态。
当出现严重问题时，大多数组织都感到措手不及。
没有人会想到从磁带中恢复75GB的数据库居然需要八个小时——而这甚至还未包括从离站存储设施中获取磁带或重新安装操作系统所需的时间。
此外，从磁带中检索正确的数据库也是一项严峻的挑战。
自从Exchange首次面世以来的10年时间里，磁盘存储和广域网的成本已经有了大幅下降。
这使得许多组织能够支付更快的备份和恢复方法的成本。
这些组织可以利用相关技术，为其Exchange基础结构实现操作的连续性和灾难恢复功能。
级别2：
操作连续性
操作连续性是一组旨在使恢复过程尽可能迅速完成，同时尽量缩短意外停机时间的过程和技术。
操作连续性针对通过磁带进行的本地恢复提供了改进的恢复时间目标（RTO）和恢复点目标（RPO）。
它力争消除（只要有可能）使磁带重新入站所需的时间。
请参见图2以比较备份和恢复的操作连续性与灾难恢复。
图2恢复连续性（单击该图像获得较小视图）
图2恢复连续性（单击该图像获得较大视图）
该图显示了恢复和可用性的连续性，左下角的技术速度慢、成本低；右上角的技术速度快、成本高；同时在操作连续性与灾难恢复解决方案之间有意进行了一下模糊过渡。
该图揭示了这些方法在成本、恢复时间和可用性之间的取舍状况。
在本文中，我会刻意将本地连续性处理与灾难恢复明确区分开来。
灾难恢复始终被视为一种远程操作，并以使数据离站为主要目标。
距离带来了额外难度，并且通常成本更高，但灾难恢复是有关严重灾难性事件后的业务继续的措施。
稍后我将深入探讨这一问题。
一些历史
随着Exchange在基础结构中的地位越来越重要及其数据库中存储的信息越来越多，显然有必要减少备份和恢复所需的时间。
某些大型组织与Microsoft协同工作，开发出一种方法，大大改进部分操作的恢复。
如果某个组织可以从外界接收或向其发送新电子邮件，则表面上看起来好像什么也没有发生。
毕竟，表面现象是很重要的。
为实施Exchange的这种“拨号音”式恢复，一个新的空数据库取代了被破坏的数据库。
然后，Exchange和ActiveDirectory®使用适当的权限创建新邮箱，使得用户能够发送和接收邮件。
当检索了备份磁带并恢复了数据后，可使用管理权限进行装载。
然后，Exchange管理员可以将恢复的邮箱合并到拨号音邮箱中。
可根据需要划分邮箱的优先级。
虽然这是一项改进，但该过程很耗时，也比较复杂；它最初使用了EXMERGE，后来应用到了恢复存储组中。
不过应当注意，拨号音恢复方案之后的完整数据恢复会是一项非常艰巨、复杂的任务（尤其是在Exchange2007中，存储组可多达50个）。
如果考虑实施拨号音恢复方案，请注意确保益处大于付出。
卷影复制服务
为利用低廉的磁盘并从生产Exchange服务器中消除处理器开销，针对Microsoft®WindowsServer®2003和Exchange开发了一个新备份API。
所创建的卷影复制服务（VSS）旨在提供一致的数据时点副本。
这些快照是可迅速生成的Exchange数据的只读副本，其中只连续包含发生更改的数据。
这些副本通常指向另一个具有可用磁盘空间的服务器，或者指向存储区域网络（SAN）。
可以保留多个快照，并在磁带上制作备份。
这样一来，生产Exchange服务器将不再受到备份软件和磁带副本开销的性能影响。
使用VSS进行Exchange数据保护具有多个优点。
首先，可以从Exchange服务器中消除磁带备份操作的性能负载。
虽然仍然需要备份到磁带，但它可以使用Exchange数据的副本，而不影响用户性能。
其次，每晚多次获取快照成为可能。
随之而来的另一个好处是您可以在辅助服务器上或其他本地存储中保留多个快照。
市场上有许多第三方产品利用了VSS快照功能。
有些产品只是减少了备份和恢复Exchange数据库所需的时间，另一些产品还添加了某些功能，例如比本机Exchange所能提供的单位更小的恢复能力，使您能够恢复至邮箱级别。
虽然没有人喜欢如此零碎的备份，但人们确实希望能够恢复特定的文件夹，甚至单个邮件消息。
复制技术
以软件为媒介的Exchange故障转移是某些复制供应商提供的一个选项。
它将激活一个备用Exchange服务器，然后通知ActiveDirectory所有用户的邮箱已经移走。
有两种方式来完成此任务，并且它们都要求对Exchange和Windows环境进行某些自定义。
一种需要对DNS用一些小技巧，使得备用服务器能够获取故障服务器的名称和IP地址。
这种方法的优点是客户端工作站方面会比较简单，因为Outlook®会认为它仍在使用相同的服务器。
第二种方法使用一台运行Exchange的备用服务器，其上存储了数据库的副本，但并未进行任何装载。
出现故障时，该备用服务器将通知ActiveDirectory所有用户的邮箱已移到它那里。
然后将运行一个脚本或发布一个组策略，告知客户端它们位于不同的邮件服务器上。
Outlook2007能够识别ActiveDirectory，这使得该过程变得更简单，因为它自己就会自动识别出这些映射。
使用MSCS的本地群集
可用性连续性的高端是Microsoft群集服务（MSCS）；Exchange是能够识别群集的应用程序。
群集可在两台或更多台计算机之间共享信息，这样如果其中一台出现故障，其他计算机可接管其工作。
今天，大多数Exchange群集都有两个或四个节点，最多可以使用八个节点。
始终会指定一个节点作为被动节点——可在WindowsServer正在运行且安装了ExchangeServer的情况下操作，但没有活动的邮箱。
Exchange2003提供了一种两节点的主动/主动群集，但是由于性能负载的原因，现在不建议使用它，Exchange2007将不再对其提供支持。
针对Exchange2003的群集方式，包含一个被动节点的Exchange2007群集仍然可以使用一个单一的共享存储阵列。
虽然群集品质的存储阵列通常具有许多冗余功能来防范多种类型的故障，但它们仍然只提供一个数据副本，这留下了一个隐患。
这就是为什么这些群集被称为单副本群集（SCC）的原因，以区别于Exchange2007中的多副本群集（MCC）所带来的下一代数据保护手段。
我们将在说明灾难恢复时进一步讨论MCC。
本地连续复制
本地连续复制（LCR）是Exchange2007的一项新功能，它提供了一种改进方式来维护同一服务器内Exchange数据库和事务日志的第二份副本。
这为使Exchange数据库和事务日志分别位于不同RAID阵列中的最佳实践添加了一个冗余层：
利用LCR可以在存储数据库主副本的阵列中存储一份日志的辅助副本，然后在存储日志主副本的阵列中存储一份数据库的辅助副本（参见图3）。
如果其中任何一个RAID控制器或阵列本身出现故障，您仍然可以使用另一个阵列中的数据库和事务日志。
通过这种方式，您可以继续操作——虽然这会令人感到有些紧张，并且性能会有所降低——直至能够将出现故障的阵列重新建立起来。
图3配置LCR
LCR是一种本地操作连续性解决方案，而不是一种备份方案，因此您仍然需要一个完整备份策略。
使用LCR还有一个性能损失，因为您的服务器现在要制作数据库和事务日志的两份副本。
此外，在Exchange2007的实现中存在一些限制，使得LCR只适用于较小的组织，因为LCR只支持某个存储组中的一个数据库，以及某个组织中的一个公用文件夹数据库。
使用LCR恢复功能实现的故障转移不是瞬间即可完成的——必须要由一位有经验的IT专业人士通过运行脚本来备份Exchange。
该过程要求执行在Exchange管理控制台之外运行的Exchange命令行管理程序命令。
ExchangeServer2003EnterpriseEdition使组织最多能够运行20个Exchange数据库（四个存储组，每组最多五个数据库），而Exchange2007EnterpriseEdition允许使用多达50个存储组，每组都有自己的数据库。
事务日志也从Exchange2003中的5MB文件减少为Exchange2007中的1MB文件。
这两项变化都是设计来支持LCR的——外加群集连续复制（CCR），它在某种程度上也与此相关。
中小型组织将使用LCR以便为其Exchange操作提供改进的数据保护。
LCR易于实现，但仍然需要手动干预。
作为一种“同一服务器/本地磁盘”解决方案，LCR只是迈向改进的操作连续性的第一步。
虽然它确实能够针对RAID阵列和RAID控制器的故障起到保护作用，但多个磁盘或RAID控制器同时发生故障的可能性是很低的。
多数情况下，故障方案涉及整个服务器的崩溃，这将我们引向了Exchange保护中的下一步。
第三方本地非主机复制
为进一步提升Exchange的恢复能力，第三方供应商开发了一些利用“非主机”复制方式的产品，使用Exchange日志文件在另一台计算机上保留一份Exchange数据库的备用副本。
在这种情况下，数据保护或归档解决方案将执行一个Exchange的ESE完整备份，将其备份到另一台计算机上，然后在Exchange关闭事务日志时立即将其取出。
它会将这些事务日志插入到其Exchange数据库副本中，以使其始终保持最新状态。
如前所述，这些日志很小（在Exchange2003中为5MB，在Exchange2007中为1MB），因此当完整备份完成后，将这些日志文件复制到非主机服务器上几乎不会给Exchange服务器带来任何系统开销。
级别3：
灾难恢复和高可用性
灾难恢复是指在主要数据中心不可用时将它重新建立起来并恢复运行的能力。
Exchange需要具备有效的灾难恢复能力，因为电子邮件和日历功能在今天已经成了许多组织的命脉。
有些公司将其传统的离站存储磁带备份作为某种形式的灾难恢复措施，但是如果您唯一的数据中心遭到火灾或水灾破坏，那么即使用车拉来成卷的磁带也毫无意义。
灾难恢复实际上不仅仅是将数据移到另一处位置，还涉及恢复应用程序并使之运行的技术和过程。
要实现有效的灾难恢复，需要让主系统和辅助系统相隔一定距离。
地点相隔距离的远近取决于考虑要克服的灾难的量级。
如果您担心失火，那么或许园区内的另一栋建筑已足够远。
但是，涉及火车或飞机失事的基础设施灾难可能会影响1英里或1英里以上的半径范围。
许多灾难是区域性的：
洪水、冰雹、地震甚至停电等。
通信也可由于自身的灾难而陷入困境——从切断与您的ISP之间的链接的反铲问题到拒绝服务攻击，直至针对一般商务的InternetDoS攻击。
在实践中，如果您的组织已经在多个地点配备了IT员工，那么针对您要防范的灾难类型，其中一处位置可能会符合您的远程操作连续性标准。
与求助于灾难恢复服务提供商或在新位置租用空间相比，使用自己的设施和员工要更经济。
灾难恢复的终极目的是给人一种感觉：
使客户确信您的业务仍在运行中。
当灾难袭击某个城市或地区时，人们对此可以理解；但是如果您的公司在几天到一个星期之内没有恢复正常，那么很有可能客户和供应商会做出最坏的猜想；许多公司都因此而落败下去。
对于客户来说，您的运营必须看上去已经恢复正常，以使他们确信您的业务仍在继续。
客户对恢复的及时性存在不同认识：
与办公家具供应商的暂停运营相比，他们对金融服务公司的暂停运营更易失去耐心，这很容易理解。
灾难恢复要求
如果希望能够在灾难后使Exchange重新在线，需要将其数据复制到一个辅助地点，并使用适当复制技术将数据提供给一个已准备好运行这些数据的预热Exchange服务器，然后通知Outlook客户端它们的邮箱已经移走。
Exchange在复制方面的要求较高，尤其是在距离较远时。
对于真实的事务数据库，每个写入的顺序极为重要。
使问题变得更加复杂的是，Exchange使用SMTP传输协议在服务器之间传输所有事务和系统信息，而这是一种非常占用带宽的协议。
此外，对于Exchange群集，必须每隔500毫秒在系统之间传递一个检测信号。
如果辅助节点没有收到该信号，则可能会触发故障转移。
解决这些问题的复杂性或许是Microsoft直到今天才在Exchange2007中涉足这一领域的原因。
在Microsoft尚未涉足之前，若干第三方解决方案已经开发出来，它们使用基于主机或基于阵列的复制功能来复制Exchange数据。
供应商意识到他们可以通过将节点分散到不同位置来扩展一个群集，这称为扩展群集。
今天，要实现扩展群集，最常见的方式是使用通用的第三方数据复制产品或那些专门为扩展Exchange节点而开发的产品。
您可以使用MSCS完成此任务，但WAN上的子网要求是个难点。
向远程数据中心提供可靠的高带宽连接是很复杂的，再加上群集，无疑会增加建立、维护和定期测试灾难恢复系统的成本，并会提出更高的人员要求。
群集连续复制
Microsoft通过Exchange2007中的群集连续复制功能扩展了它对群集的支持。
CCR扩展了LCR的功能，现在能够维护两个Exchange数据库和事务日志副本，在两个群集节点上实现同一设想。
灾难恢复意味着需要使主系统与辅助系统在地理上彼此分离，在WindowsServer2008（原代号为“Longhorn”）使得扩展群集成为可能之前，Microsoft多副本群集（MCC）无法跨越很远的距离。
使MCC节点能够具有单独的数据副本的技术称为多数节点集（MNS），它是指一个选举过程，其中两个或多个节点决定由谁来保存数据的活动副本。
当出现故障时，其余节点将进行一次新选举以确定由谁接管作为新的主处理/数据服务器。
支持这种技术民主行为的是CCR，它将确保每个节点都具有最新的数据库。
使用CCR的Exchange2007群集被限制为只有两个节点。
在大型组织中，Exchange服务器通常在服务器上配置本地系统磁盘，然后通过SAN连接到Exchange数据库（使用SCSI、光纤或iSCSI磁盘阵列）。
对于MCC/MNS群集，一个有趣的问题是高端的Exchange存储是否会退化到为每个节点使用本地RAID阵列。
如果MNS群集的目的是使每个节点具有自己的独立存储，那么将每个节点指向旨在提供公共存储的SAN是否仍然有意义呢？
在一个中规中矩的MCC/MNS群集方案中，主节点会将存储放在SAN上，而辅助群集节点会使用本地磁盘或成本较低的iSCSISAN。
该辅助节点可远离主数据中心，位于一个不具有SAN基础结构的远程位置。
不管其如何展开，使用MNS和CCR的MCC都是在冗余和增强的可用性方面取得的另一项进步，因为此时有多台计算机能够进行故障转移，并且数据在单独的存储元素上进行复制。
不过，在WindowsServer2008出现之前，这仍然完全局限在一个数据中心内。
WindowsServer2008将提供扩展群集的本机支持，使MNS群集中的节点能够在地理位置上相隔任意远的距离——前提是节点之间的网络延迟能够稳定地低于500毫秒。
直到这时（以及从此以后），第三方群集技术才能基于MicrosoftMNS和CCR提供扩展群集所需的地理分隔，以便获得有效的灾难恢复解决方案。
群集属于灾难恢复连续性的高端领域，而CCR可恰当地定位为Exchange的高可用性功能。
即使这种结合具有较高的成本和人员要求，但对于希望获得一个同构的Microsoft环境的用户来说，这将是一种令人兴奋而先进的解决方案。
第三方远程操作连续性
一旦面世，Microsoft解决方案和第三方扩展产品就将占据灾难恢复连续性的绝对高端，这一点勿庸置疑。
数秒内即可自动完成故障转移——几乎尽善尽美。
不过，并非所有公司都需要如此级别的可用性和业务连续性，有些也无力为此支付数十万美元的费用。
对许多公司来说，能够在几分钟内完整恢复Exchange的可靠解决方案已经足以提供他们所需的所有操作连续性。
例如，MimosaSystems,Inc.将一个数据中心内的操作连续性扩展到远程连续性。
在远程位置，MimosaDR维护了一个Exchange副本，使用来自主Exchange服务器的事务日志使其保持最新状态，并时刻
升级会员 