本篇文章主要讨论的是文件备份与恢复，以及涉及到的其他的模块，如打开文件备份模块以及合成备份模块。

主要讨论三个方面的内容，一个是文件备份与恢复的性能问题，打开文件备份模块的相关内容，以及合成备份的特性，执行原理。

文件备份的性能因素

文件备份恢复的性能因素较多，但是主要是以下几个方面，

１．文件数量的多少，文件数据的大小

当前内核单任务最合适的文件数据范围在100万个以内。（一个任务100个文件的性能下，执行不会对客户端造成严重的性能影响，从而导致客户端其他的工作受到影响。）

同一个机器，在性能许可的情况下，最好一个客户端的任务不要超两个（如果客户端性能非常好，配置很高，这个数据还是可以适当放宽的。）

如果按照在用户内存空间与内核空间平分秋色的内存分配来看，不同的平台所支持的文件数据的理论限制有：

（１）Ｗindows 32/64 – 2G/8T – 16M/24M（3G）/64G

（２）Linux32/Linux64 – 3G/512G – 24M/4G
由于物理限制及实际可用性方面的考虑，实现支持数量远小于此上。

２．对于文件过滤选项的支持

由于过滤需要对每个文件都进行计算。

对于目录过滤，则对每一个尚未过滤的目录进行计算

因此文件越多，过滤越多，性能下降越多

建议：

尽量不要设定过多的过滤条件，如果有可能把要过滤的文件以不同的任务来进行备份。
尽量不要设定对特定文件的过滤，这样取得的效果很少，但浪费的性能很大。

３．打开文件备份模块的应用

由于打开文件备份模块只用在系统备份与在备份普通任务的某些文件时（此文件被另一个程序独占使用）才会使用，因此其性能影响是有限的。

由于打开文件备份模块的作用与 Windows API 的功能大概相同，但是此模块无需像 Windows API 那样需要集成非常多的功能，因此从理论上说，打开备份文件模块的性能要比 Windows API 好。而且其在很多读写文件采用了更加优化算法，如在写文件时尽量避免磁头的移动，从恢复系统后的数据布局来看，数据的分布相当集中也说明了这一点（可以通过“分区->属性->工具->整理->分析报告”中查看）

p_w_picpath

４．备份恢复目的地

对于备份到本地与备份到网络的性能差异是有比较大的影响的，其次就是通过 USB 的文件备份到移动介质上。但是随着千M 与万 M 网的应用。备份到网络上的性能几乎与本地不相上下。有时真正的瓶颈则在于本地的磁盘读写及IO上，而不是在通路上。

５．数据源属性

数据源有：文件（Unix/Linux/Windows）

数据库（Oracle，SQL Server，Mysql，DB2）

邮件数据（Domino，Exchange等）

不同的数据源由于实现方式不同，以及平台性能差异，会对备份恢复的性能造成影响，如在*nix类的系统中，文件是很小的，而小文件无论在备份和恢复上对性能的影响都非常大，其次是文件系统的性能，据一般主观感受来说（因为手头没有数据），*nix文件系统的性能要好于Windows的。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

高级打开文件备份模块

1.功能介绍

读取与写入启动信息
分析和读取 Ext2、Ext3 文件系统内容
读取写入Windows FAT12/16/32/NTFS 文件系统内容
磁盘及分区操作，如分区创建、删除、格式化等。

我们还看一个实际的应用，DiskGenius，是一个使用相同的高级打开文件模块，在读取文件系统时产生的结果，这图中框中指示的是文件系统的特殊文件。

p_w_picpath

2.实现原理

直接读取磁盘或者分区上的扇区数据，并且根据扇区的数据分析出文件系统结构，再从文件系统的结构出发，一个个地分析其中的文件数据。由于其相当于实现的另一套文件系统接口层，直接操作磁盘扇区的读写，不再依赖于特定系统的文件系统所提供的 API，因此可以打开任意文件，读取任意扇区，任意位置的字节，包括隐藏分区。因此不受操作系统的一些限制，并且最近的功能里除了支持MBR外，还支持GPT方式的磁盘布局格式。

3.使用场合

备份和恢复Windows及Linux系统（只使用备份恢复启动信息部分）

打开文件的备份

磁盘分区的操作等

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

合成备份

1.什么是合成备份

合成备份，简单地来说，是由已经备份的数据合并而成的新数据，其特点就是不再从数据源中读取数据。在这里的图中所显示的一样，新合成的备份数据中的 三个文件 DocA，DocB，DocC都不是从数据源中提取的，而从之前已经备份的数据中提取的。

p_w_picpath

2.为什么需要合成备份

原因

一是：对于一些变动不是很频繁的文件，如果直接通过循环备份，有可能此文件在没有变动的情况下，会执行多次备份。浪费备份时间及带宽资源。
二是：如果不进行合成还可能造成重复归档，即一个文件无必要地进行了冗余。
三是：如果合成可以进行有效的归档操作。这一个特点，是与我们的方式有较为密切的关系。

p_w_picpath

上面的图中展示了在循环备份方式下，DocA如果不采用合成时，会从数据源再读取一次，而采用合后，直接从原有备份数据中直接提取，由于是就近提取。则实现起来就非常方便，而且即使是直接读取数据，也比通过异地的方式要方便快捷一些。

3.合成备份的执行方式

即合成的数据里全是增量的话，我们就合成增量，如果里面有一个完全，则我们进行完全合成。

p_w_picpath

3.0 之前的合成，如图中所示的方式进行合成。通过循环方式，将多余的完全与增量删除，则且针对合成的数据进行直接合成，这是合成增量的的方式。

p_w_picpath

合成完全的方式，则与增量方式相同，只是在合成类型上不一样

p_w_picpath

缺点：

这样的合成方式有几个非常大的缺陷：

客户端离线时无法执行合成 ，限制了执行的时机。
客户端在线时一般是工作时间，此时执行合成将占用服务器端 I/O 及 CPU 资源。影响其他客户端的备份。
在合成过程中客户端离线会导致合成备份执行项提示出错，但是实际合成过程不需要客户端参与。因此应该不再向客户端提示信息。

4.关于SmartMove的合成

针对上面所提的几个问题，则发明了 SmartMove 合成算法，

SmartMove合成的特点：
1）. SmartMove 算法，它可根据介质可用空间、已过期数据量、无效数据量等选择是否采用无 I/O 操作的合成备份（不使用服务器 I/O 资源以及 CPU 资源）。
2）. 对已过期数据，可提供给调用者根据自身策略进行处理，主要用于归档整合。
3）. 合成备份过程不涉及到网络客户端，仅在本地介质上执行。
4）. 当介质空间充足时，合成将非常快速。I/O将尽量向后延迟。
5）. 以任务单独在介质服务器上运行
6）. 合成不再以循环为条件，而是以执行计划为条件。其与原来的循环是两个不同的执行体系。

SmartMove 合成也只有两种合成类型，一种是合成增量，一种是合成完全，合成增量与合成完全的条件与非SmartMove合成方法是一样的，即，合成是所有数据都是增量，那么就合成增量，如果合成时有一个完全，那么合成就是完全。像图中合成时，就合成一个完全备份。

p_w_picpath

合成备份的执行过程，完成合成备份要经过下面的三个步骤，

第一是确定合成的范围。这个是根据任务所设定的合成策略来确定的。比如图中的虚框所包含的就是我们根据合成策略所确定的合成范围。
第二步就是确定合成类型，SmartMove 合成的顺序是按时间由后向前依次合成，当遇到第一个完全备份时就停止合成，或者直到所确定的范围最早的一个时间点停止，因此真正合成的范围是黄框所确定的时间点。
第三步，当合成完成时，原时间点对应的 EBS 文件并没有从数据中删除，而是由新生成的合成备份数据进行参考。最后把被合成的的时间点，比如上面的黄框所确定的时间点删除。
这样，一个SmartMove 合成的完成了。由于在合成时，并没有产生数据文件的I/O，则只是针对原来的元数据记录进行重新组合，因此这个合成备份是非常快的。

p_w_picpath

p_w_picpath

如上图在合成完全备份时有一个特别的情况，就是任务的循环备份完全保留数大于1的情况，在这种情况下，只要合成的备份类型是完全备份，那么就执行真正的数据合成，而不仅仅是元数据的合成。

为什么会出现这种情况呢？下我们来说明一下。

在出现上述的情况时，如果执行 SmartMove 合成，那么就有可能多个时间点指向到同一个 EBS 文件，如 A。EBS，由于循环备份与合成备份是两个独的运行体系，那么有可能循环备份的时候会把 A。EBS 删除了，这时，另一个时间点的文件就在再也恢复不了了。
如果我们不删除这些 EBS 文件，而让合成来删除，会怎么样呢？不是不可以，如果合成支持这样的操作，那么在每次合成时都需要进行全文件树分析，这将导致合成效率下降。如果不进行分析，就需要改变 EBS 格式，就会导致旧的程序无法支持新的 EBS 格式，从而出现兼容性问题。

合成增量的方式是较为简单的方式。合成增量是否执行 SmartMove 算法，则完全取决于空间条件，及备份集数量。
在图中，执行过程也完全过程一样，都是确定范围，合成，然后删除被合成的时间点。这里也不进行更深入一步的讨论。

p_w_picpath

当下面的三个条件都为真时，就执行SmartMove合成备份：

当可用空间大于用户预先设定的执行SmartMove合成的阀值时，
. 并且合成完全备份时循环策略的完全保留设定为大于 1；
并且当合成的备份集数小于 65536 个时，也就是一个时间点所能支持的最多的备份集数。

这个时间就执行SmartMove合成备份。

虽然看上去要执行 SmartMove 算法的条件要求比较多，但是第一与第三条通常都为真，而合成任务时一般都设置循环的完合保留数为1
，并且根据用户合成策略，一般来说，合成范围内都是增量的情况居多。所以绝大多数时间都是执行 SmartMove 合成的。