文件保护使用vss快照实现：
Microsoft Exchange Server 2003 使用包含在Microsoft Windows Server2003操作系统中的卷影复制服务(VSS)来生成Exchange Server 2003 数据库和日志文件的卷影副本。通过使用VSS，您也许能够在几分钟中内恢复数据库，不管数据库的大小。快速恢复能力主要取决于VSS方案中的提供程序组件的能力。
因为有许多不同的VSS 策略可用，您必须理解和测试方案的容量、性能和恢复，来确保在您的部署中您所需要的数据被成功恢复。您也必须确认在VSS 框架中任何潜在的方案是可操作的。我们将要描述为Exchange Server 2003选择、测试、部署和监视VSS 方案。
什么是VSS?
VSS 是一套COM API，它部署了这样的架构，让卷备份能够被执行同时系统上的应用程序继续写入卷。请求者、书写器和提供程序它们在VSS架构中通讯来创建和恢复卷影副本。一个卷的影子副本及时地复制了加载在卷上处于正常状态的所有的数据。
备份的过程包含下面这些步骤：
1. 请求者发起备份。接着请求者通知书写器准备一个数据集便于备份。
2. 书写器为备份准备数据。Exchange Server 2003 和其他应用程序部署根据应用程序的特定要求准备数据的书写器。在数据集准备好之后，书写器用信号通知请求者来备份数据集。
3. 提供程序与磁盘系统交互，并管理影子副本。当被请求者指示的时候，提供程序创建影子副本。
4. 请求者发信号将备份成功或失败的信号发送给书写器，接着完成整个备份过程。
5. 通过分开请求者、书写器和提供程序的功能，VSS 架构使得每个组件独立于其他组件。一个请求者能够与不同的提供程序或多个书写器交互。
Exchange 书写器随着Exchange Server 2003自动被安装。请求者能够访问Exchange 书写器只有当Exchange Server 2003 被安装在Windows Server 2003 操作系统上。VSS 备份将对Exchange Server 2003不可用如果Exchange Server 2003 安装在Microsoft Windows 2000 Server 上。
当被请求者指示这样做的时候，Exchange 书写器准备Exchange 数据库用于备份。书写器通过暂停对数据库的所有磁盘写I/O最多达20秒来实现它。这也被称为冻结数据库。提供程序必须能够在该窗口中完成影子备份否则备份将被失败。在备份完成之后，书写器解冻数据库并恢复正常的I/O 操作。
注意：
Windows Server 2003 的Windows Backup能够使用缺省的基于软件的Windows VSS 提供程序来执行磁盘卷和文件的普通VSS 备份。然而，Windows Backup 不能与Exchange 书写器进行通讯，也不应该被用来制作Exchange 数据库文件的VSS 备份。几个非Microsoft 的备份应用程序部署了能够与Exchange 书写器一起工作的请求者。
VSS 备份方法
提供程序能够以很多种方式来执行影子备份。尽管Exchange 书写器不知道提供程序是如何创建影子副本，确认您理解了您的方案中的提供程序是如何工作的，这样的话您能够计划性能和容量。尽管对于现有的影子副本备份方法没有工业标准定义或命名约定，备份方法的大多数在总体上能够被分为克隆影子副本或快照影子副本。
克隆影子副本
在影子副本集中克隆影子副本是卷的完整副本。一个影子副本集是一组在同一个点被及时同步的卷影副本。
象一个普通的副本一样，克隆是独立于原始的数据。如果所有的原始数据丢失的话，克隆仍保持不变。这不同于快照，它不完全独立于原始数据。
您必须考虑容量对话当您使用克隆的时候。为了确保可复原的副本如果在备份的时候发生故障，您必须使用N+1 计划，N 是备份克隆的数量，您想在任何时候使用可用的备份克隆来恢复。例如，如果您决定只拥有一个备份，您仍然需要两(1+1)个目标克隆来旋转来阻止数据丢失如果在备份的时候发生故障。
1. 提供程序供应商决定具体的方案是如何部署克隆是如何创建的。
镜像 一些方案预先准备镜象。这些镜像备份接着被分成两份，一个备份为您提供只读的副本和一个活的生产环境中的卷。该策略几乎对生产环境中逻辑单元号(LUN)没有影响当备份和校验与完整性检查发生的时候。然而，它会对生产环境中的LUN增加显著的I/O 负载在备份之前。
您必须确认您安排好时间来重新同步不在需要生产环境中的逻辑单元号的克隆当您在多个克隆之间旋转。对于恢复，方案也许将只读副本重新同步到生产环境中的LUN，它影响其他在线的使用相同的生产LUN的存储组直到所有的数据被备份。在恢复期间，一些存储阵列仅更改指示器到只读副本。这使它可写。
克隆 一些方案在备份的时候创建克隆，其中LUN中所有的数据必须被拷贝到其他LUN。那些数据接着被标记为只读。该策略在前面能够消耗更少的容量，但是要求所有的数据在备份的时候被拷贝。通过这个策略，您必须知道一个特定的存储控制器能维持每个小时多少千兆字节，除了在备份的时候对生产数据库LUN 的影响。这让您正确地设计您的LUN为了最大的吞吐量，并计划该操作的时间来最小化对生产LUN的影响。
快照影子副本
克隆和快照之间的最重要区别是快照是不完全独立于原始数据。一般地，通过在一个点及时地定义一个标记来创建快照，同时确保数据能够被及时回滚到那个点。您能够保持多个快照，并且快照与克隆相比要求更少的空间。
能够以几种不同的方法来创建快照。最常用的方法是copy-on-write。
copy-on-write 方法在一个点及时地定义一个快照，接着监视原始的数据集是否更改。如果发生更改，更改被记录或跟踪在单独的位置。随着时间的过去，因此，快照的大小会继续增长，尤其当一个快照是由快速更改数据集组成。
快照管理器提供了数据集的不同视图，通常好象它们是数据的不同完整备份。根据需要快照管理器也能够切换到数据的任何可用的视图，这样，在某种意义上，恢复数据。
记住快照不是真正独立于数据的备份。如果原始数据破坏了的话，快照数据是没有用的因为它只包含了 数据的最近的修改。
这种备份方法给您提供了回滚的机制，但不是真正的数据备份。该备份方法的好处是您只写入更改，而不是所有的数据，到磁盘，因此快照的实际创建发生的非常快。缺点是如果您的原始数据损坏的话您没有可恢复的备份。
因为快照备份不提供真正的备份，大多数方案部署了额外的步骤将快照备份流出到磁带。流出到磁带对您的生产数据库LUN 的I/O 增加了显著的连续负载。
在常规操作期间，对于加载Exchange 数据库的磁盘的I/O 负载是非常随机的，但是对于流备份来说I/O 负载是非常连续的。持续负载和随机负载的混合使的缓存很难继续保持高效，并且会导致额外的延迟并使最高吞吐量大大减少。如果您计划完全依赖快照作为您的Exchange Server 2003 的备份源，这是要考虑的一个重要因素。
许多Exchange Server 管理员计划减少该问题的影响通过在非高峰时间制定流备份。尽管这是一个有效的策略，但什么是真正的非高峰时间也许并不很明显。
除了响应客户端的请求，Exchange 数据库也要时间来执行在线维护。管理员能够计划该维护的时间，但经常要求一天的几个小时才能完成。即使终端用户负载很低，数据库也许忙于维护任务。您也必须考虑额外服务器负载要求用来准备或执行备份。作为非常好的实践，避免备份窗口与在线维护或高峰用户需求时间重叠。
要决定数据库活动的高峰时间是什么，您必须通过至少几天的基线时间段真正描绘出您的数据库负载。
Exchange 请求者和校验与完整性检查
Exchange 数据库文件被分成了一系列相同大小的页面。这些页面中的每个都包含了验证页面上Exchange 数据的完整性的校验。如果页面上的任何数据在Exchange 服务器的控制之外发生了更改，例如，磁盘或控制器错误，校验检查将检测到该问题。Exchange 事务日志文件也部署了校验计划，但它不是基于页面的。因此，事务日志文件的损坏也能够被检测到。
Microsoft 支持流备份API来执行Exchange 数据库的备份当它们运行的时候。流API 部署在所有版本的Windows 和Exchange Server的Windows Backup 中以及许多非Microsoft 备份应用程序中。
注意：您必须在运行Windows Server 的计算机上安装Exchange 管理程序，来让Windows Backup 执行Exchange 在线流API 备份。
本质上，流备份在将数据库拷贝到媒介上的时候一次拷贝一页，非常整齐。在备份的期间，每页的校验被验证，只有当数据库中的所有页都通过验证，备份才算成功完成。备份中事务日志文件也被验证。这保证特定数据库的最后一次备份是好的。
当影子副本被创建的时候没有机会去验证数据库或事务日志的页完整性。因此，必须在影子副本被创建后执行校验与完整性检查。Microsoft 指导方针提供了在请求者上执行该验证的职责。
请求者，或备份应用程序，对数据库和日志文件运行校验与完整性检查在备份完成之后。这对数据库和事务日志逻辑单元号(LUN)来说是非常重的流I/O负载。请求者通过运行执行Exchange Server 数据库工具 (Eseutil.exe) 来执行校验与完整性检查。它读取整个备份文件集来验证每个数据库页面和事务日志文件的单独完整性。
在缺省情况下，Eseutil.exe 运行和存储读数据一样快，对于通常的独立于生产LUN的克隆这是最优的。然而，不是所有的VSS 备份集都独立于原始数据。
有时候，它也许能够帮助降低校验与完整性检查的I/O 率通过增加人为的暂停在一组I/O 数字之后。通过使用Exchange Server 2003 加上 Service Pack 2，您能够增加下面的开关来增加1秒钟的暂停在一组I/O数字之后。
/p
这里的x 表示在经过多少I/O之后暂停将发生。例如，下面的命令增加1秒钟的暂停在每100个I/O之后：
eseutil /K /p100
I/O 减速部署只针对于数据库文件验证，不适用于事务日志文件验证。
当策划您的备份方法的时候，您必须仔细考虑和计划由校验与完整性检查创建的I/O 负载。该验证是备份过程的一个重要部分不能被忽视。
快照不能完全独立于生产LUN。因此，对快照运行校验检查肯定会影响生产LUN。克隆上的校验检查可能会或可能不会影响生产系统，取决于克隆保存在哪儿和它是如何被访问的。
您必须仔细的监视I/O 负载和验证过程对您的终端用户和平常数据库维护的影响。仔细地使用Eseutil.exe 减速机制也许也能够让您更好地掌握验证性能和其他I/O 需求
=========================================================
卷影复制服务（VSS）详细介绍
本文中内容是参考以下内容整理而成:
1．学习笔记29：Volume Shadow Copy Service（VSS）如何工作 — Windows Live
4．VSS（卷影拷贝服务）与snapshot优缺点及区别 - TL的专栏 - CSDN博客
5．Volume Shadow Copy Service (Windows)
8．How Volume Shadow Copy Service Works: Data Recovery
1 卷影复制服务（VSS）概念
VSS卷影拷贝服务其实不是一项新技术了，在2003年前后发布的Windows 2003和Windows XP SP1都提供了对VSS的支持。最近几年微软的一线产品对VSS支持的越来越多，包括Exchange，SQL，AD，DPM等等。在Windows 2008中甚至系统的自带的备份工具也换成了VSS版本的1。
卷影拷贝服务（Volume Shadow Copy Service，VSS）是Microsoft在Windows Server 2003中开始引入的服务，它能让用户在没有IT专业人员协助的情况下，更轻松地恢复丢失的文件。此外，VSS还提供了更灵活的备份方案。结合了良好的规划以及最新的备份和恢复技术，卷影拷贝服务将对灾难恢复计划的增强很有帮助。VSS甚至让小企业也有恢复丢失数据的能力。其实，VSS还为大企业提供比基本工具更多的恢复选项，并帮助其减少数据恢复任务中IT专业人员的数量2,4。
VSS 是一套COM API，它部署了这样的架构，让卷备份能够被执行同时系统上的应用程序继续写入卷。请求者、书写器和提供程序它们在VSS架构中通讯来创建和恢复卷影副本。一个卷的影子副本及时地复制了加载在卷上处于正常状态的所有的数据3。
2 VSS解决的问题
VSS被广泛的应用到Windows的备份处理中，除了windows自带的备份应用，还被Veritas、CA、CommVault等厂家采用4。
你可以通过使用VSS，在特定卷上建立数据拷贝时间点；并在将来的某一时刻把数据恢复到任何一个你曾创建的时间点的状态。这两个功能可以帮助客户的计算机恢复意外删除的文件，这样的工作即使一般员工也能轻松完成，并且不需要创建高效备份策略的能力2。
对于IT技术支持人员来说，最常见的请求一般是恢复人为原因造成的数据丢失。用户不经意地存储了有错误信息的文件，不小心删除文件，或是其他的数据意外，都是经常发生的2。
当用户需要重新找回数据的时候，经常需要请技术支持人员拔出备份磁带，进行人工恢复，这个工作相当浪费时间2。
VSS让管理员能够在服务器上发布共享文件夹，在一定的时间间隔内做时间点的备份（在指定时间内最多可以存在65份拷贝）。这让最终用户能够安全地处理文件并随时恢复到早前的版本，而不需要IT部门的干涉2。
3 VSS工作原理
VSS是Windows 下的快照技术，由Requestor, Writer, 和Provider组成，同时集成了COM技术。因此，它不再是单单在卷级上的block进行处理，而是和各种系统应用相关联，比如SQL，EXCHANGE，AD等等。从而使得在不关机，也不停止应用的情况下，做备份4。
完整的VSS解决方案包含以下基础部件6：
VSS 服务 Windows 操作系统的一部分，用于确保其他组件能够正确地通信和协作。
VSS 请求者 请求实际创建卷影复制的软件（或者如导入或者删除它们等其它高级别的操作）。通常是备份程序。诸如Windows Server Backup 工具和System Center Data Protection Manager等都是VSS请求者。非微软的VSS请求者包含几乎所有运行在Windows上的备份软件。
VSS Writer 该组件保证要备份的数据集的一致性。一般作为商业应用程序的一部分提供，如SQL Server® or Exchange Server。多种面向Windows组件的VSS Writer，如注册表，已经内嵌到Windows系统当中。非微软的VSS Writers被包含在需要在备份时保证数据一致性的许多Windows应用当中。
VSS provider 该组件用于创建和管理卷影复制。可以通过软件或硬件方式实现。Windows操作系统集成了一个基于写时拷贝(copy-on-write)技术的VSS Provider。如果使用存储区域网络（SAN），且有相应的硬件Provider，最好是将相应的Provider安装一下，这样可以减轻主机创建和维护卷影复制的负担。
下图是展示了VSS服务如何协调Requester，Writer，Provider来创佳卷影复制的，以及一些微软所提供的基于VSS的解决方案。
图一 VSS 架构及相关解决方案
3.1 创建卷影复制的流程
下图是展示了卷影复制创建的流程。
图二 卷影复制创建流程
要创建一个卷影复制需要，requester，writer，provider要执行一下步骤：
1． Requester请求VSS（卷影复制服务）枚举writers，收集writers的信息，为创建卷影复制做准备工作。
2． 每个Writer创建一个关于组件和需要备份的数据存储的XML描述并将其发送给VSS。VSS将writer的描述提供给requester，再由requester选择要备份的组件。
3． VSS通知所有writer准备创建卷影复制所需要的数据。
4． 每个writer根据情况准备数据，例如完成所有打开的事务，回滚事务日志，刷新缓存。当准备好卷影复制的数据，writer通知VSS。
5． VSS让writers暂时冻结程序的I/O写请求（I/O读请求仍然可用）几秒钟，以用来创建卷影复制。冻结时间不能超过60秒。VSS刷新文件系统的缓存，然后冻结文件系统，用来保证记录的系统元数据的正确性以及将被卷影复制的数据的写入顺序的一致性。
6． VSS通知requester在10秒内创建卷影复制。在这期间，文件系统I/O写请求仍然处于冻结状态。
7． VSS解冻文件系统的I/O写请求。
8． VSS通知writers解冻应用程序的I/O写请求。这时应用程序重又可以向进行卷影复制的磁盘写入数据。
|
备注 |
|
如果writers处于冻结状态的时间超过60秒或者providers没有在10秒内完成卷影复制的提交，创建卷影复制的操作会被中止。 |
9． Requestor可以选择重试或者通知管理员稍后重试等操作。
10． VSS在卷影复制成功创建之后把卷影复制的位置信息返回给Requestor。某些情况下，卷影复制可被临时设置成可读写的状态，以便VSS或者其它应用在完成创建卷影复制以前修改其中的内容。待修改完成后，卷影复制被设为只读状态。这个阶段被称之为“自动恢复”（Auto-Recovery），这步是用于取消任何在卷影复制创建之前未完成的进行在要做卷影复制卷上的文件系统或应用程序事务。
|
备注 |
|
以上步骤是按照Windows Server 2008的帮助文档翻译而成，个人感觉不及Windows Server 2003中描述的清楚，但本着与时俱进的思想，还是选择了对08版本中的进行了直译,对于03的翻译，可以参考1中所述。J |
4 VSS注意事项
这一服务唯一的缺点是你需要为每一个卷影留出更多的磁盘空间，因为你必须在某处存储这些拷贝。不过，因为VSS使用指针数据，这些拷贝占用的空间要比你想象的小得多，你可以有效地存储这些拷贝。
你还可以将复制与备份工具和VSS配合使用，来将拷贝移动到另一个VSS——其他站点的可用服务器。因此，如果原始服务器在灾难中崩溃了，你的最终用户还是可以访问他们的数据。由于VSS在一定时间间隔内做一次快照，并且在母文件使用时并不锁定它们，因此开放文件锁定并不会影响到复制与备份工具。
除了复制开放文件以外，你还可以在最终用户处理文件的时候备份VSS快照。这一功能通过消除备份窗口、开放文件锁定和其他的障碍，显著地提高了备份能力。
你或许还将遭遇CPU利用问题（在运行备份代理的时候）和LAN利用问题（在跨越网络进行数据备份的时候），不过这并不妨碍最终用户使用文件。
备份VSS快照产生干净的数据镜像以及恢复时间点拷贝的能力。你既可以恢复整个快照，也可以取你所需，或者你还可以使用VSS备份工具来恢复单独的文件和文件夹。
因为你基于时间点来备份文件拷贝，所以可以很轻松的使用复制工具即时地将VSS快照移动到另一台灾难恢复站点中的服务器上，并在那里进行备份，创建脱站的缺省备份。需要将备份保存在脱站位置的公司会发现实施灾难恢复（DR）系统变得相当简单，而且备份系统能平滑地协同工作。
转自：http://blog.csdn.net/ziliaobeifun/article/details/6171529
参考：
http://www.jucaiba.com/page/2026.aspx
https://storage.it168.com/a2009/0505/2749/000000274925_1.shtml