发现恢复比备份还要费时，许多人感到很惊讶，但这一点都不奇怪。事实上，每个人都应该为这种差异做好计划，并纳入到备份设计中。
以下是恢复起来通常比备份慢的五个原因。
RAID写开销
大多数现代磁盘阵列使用基于奇偶校验的独立磁盘冗余阵列(RAID)来构建，RAID级别从3到6。其他磁盘阵列使用纠删码来构建，这与基于奇偶校验的RAID面临相似的挑战。
将数据写入阵列时，基于奇偶校验的RAID需要计算奇偶校验信息。从这同一个阵列读取数据时不进行这种计算，因此读比写快得多。写开销对性能的影响可能很小，也可能很大，这取决于RAID级别及/或纠删码中使用的设置。但所有这种阵列都面临一些写开销，您需要找出自己的写开销有多大。
写时拷贝快照
与写开销相似的一个概念是，在使用写时拷贝快照的阵列和NAS文件管理器中发生的情况。当您创建写时拷贝快照时，它只是将一根棍子立在地上作为参考点。最初创建快照时，几乎不会发生I/O;所有的重活都在之后发生。写操作试图覆盖需要为快照保存的块时，该块会在允许继续写操作之前拷贝到快照区。这就是为什么名为写时拷贝。
与RAID写开销一样，这仅在写入时发生。快照开销也可能非常大，因为它取决于保存在该特定卷上的快照数量。更多的快照加大了在写操作继续之前需要拷贝单个写内容的机会;因此，写时拷贝卷上的快照越多，写新数据时的性能就越差。
写入到文件系统
下一个写开销出现在写入到文件系统时，尤其是含有数百万个文件的密集系统时。当您恢复文件时，文件系统必须先创建一个文件来恢复该数据。该文件的创建是单独的操作，无论文件大小如何，都需要耗费时间。如果有数百万个文件要恢复，这个文件创建时间实际上可能比恢复本身所花的时间还长。
不堪重负的事务日志
关系型数据库具有跟踪数据库所有更改的事务日志。数据库在事务日志中快速记录事务的能力通常不是大多数数据库设计中必须考虑的方面。然而，大型恢复每秒创建的事务可能比平常工作日需要创建的事务多得多，因而给事务日志带来了比平常大得多的负载。因此，事务日志也会减慢恢复速度。
多路备份流
考虑恢复比备份慢时要注意的最后一方面是多路(multiplexing)。好消息是，只有直接从磁带恢复时，才会出现这种开销。如果备份系统基于磁盘，不会出现这个问题。这实际上是过去二十年来许多人放弃磁带的主要原因。
要理解这个问题，应考虑磁带驱动器的主要问题：它们比实际需要的速度快得多。现代流式磁带驱动器的速度比典型增量备份的速度快10倍到20倍。为解决这个问题，业界开发了多路技术：将多个备份流交织成一个流，其速度快得足以让磁带驱动器满意。20年前多路开发出来时，这个领域的大多数人觉得别无选择，因为他们必须让磁带驱动器满意，才能进行成功的备份。然而，恢复面临庞大的开销。
如果您从多路磁带恢复，备份软件必须读取整个磁带，并丢弃除您需要的流之外的所有流。如果多路设置为10，磁带驱动器必须读取所有10路流，丢弃其中的9路流。这对恢复速度有很大影响。如果将其与上述某种写开销结合起来，情况可能会变得更糟。如果磁盘驱动器无法像磁带驱动器读数据一样快地写数据，磁带驱动器不得不停止和启动，以便磁盘驱动器跟上速度。
评估恢复延迟，设定预期
找出环境存在什么样的恢复速度开销，然后纳入到备份设计中，这点很重要。在您要恢复数据的每种类型的系统上对每种不同类型的数据执行测试恢复。这包括您在数据中心、每个大型文件服务器中使用的每种不同类型的RAID。搞清楚什么样的恢复速度是规定的恢复速度，然后询问供应商可以怎样加快这个恢复速度。
随后对大型恢复期间会发生什么准确地设定预期。开会讨论恢复重要的文件服务器需要多长时间，并向受影响的人解释为什么会这样。供应商可以帮助解释它是否无能为力，您可以接受这一点，也可以研究一种全然不同的备份技术。
重要的是在需要恢复任何数据之前做好所有这些工作。尽可能全面地进行恢复测试，看看恢复比备份慢的程度，并相应地调整设计和预期。
