评估在线处理和后处理去重的恢复时间

数据复制所需的时间

你还需要知道数据复制是一个怎样的工作流程。以及当进行文件备份的时候、当备份任务结束的时候，或者仅当所有备份任务结束的时候，数据复制是否还在进行中?

很显然，你希望能够以重复数据删除格式而非原本的格式对数据进行复制，以便最少地占用主站点和灾难恢复站点的带宽需求，因此你必须等待，直到重复数据删除开始。在最开始的重复数据删除过程中，大多数厂商在存储数据之前都会先对数据进行重复数据删除和压缩，但是并不是所有的厂商在进行数据复制的时候都将数据保存为这样的格式。如果厂商必须要在复制之前对数据进行解压缩的话，完成复制的过程将会对带宽需求造成一定的影响，这也是可能会对TTR造成影响的一个因素。

清楚什么时候构成重复数据删除文件的必要元数据被复制也十分重要。否则你无法将文件从灾难恢复站点恢复，除非这些元数据(关于数据仓库的数据，指在数据仓库建设过程中所产生的有关数据源定义，目标定义，转换规则等相关的关键数据)也处在灾难恢复站点上。

一些方法将元数据与文件同时进行复制，然而其他做法却不会对整个文件的元数据进行复制，除非特殊的备份工作的复制过程结束，或一些情况下甚至更晚些的时候才会同时复制。对于大的数据传输任务来说，完成复制需要的时间的不同决定了什么时候开始从远程站点进行文件的恢复，这之间可能会有几个小时的差距。这将对TTR产生明显的影响。

将数据复制与重复数据删除设备进行功能上的整合而不是使用独立的复制能力来完成任务是有很大的好处的，例如基于阵列的复制。随着元数据传输的结束，综合的选择可让文件立刻适用于灾难恢复站点的只读要求，但是更加静态的选择例如基于阵列的复制，会要求该文件在允许访问之前被手动安装到服务器上。整合的做法让重复数据删除之后的数据的完整性的管理工作变得更加容易，但是即使这样你往往想知道厂商是怎样解决数据完整性问题的。在重复数据删除后的环境中，大块数据的丢失可能会影响几百或几千的不同的文件，因此，你一定要确保你对厂商在此方面的做法的可靠性是满意的。

恢复的时间

在比较恢复时间的时候，厂商显然想告诉用户他们可提供很快的恢复能力。在线的做法不会将数据隐藏为原本的格式，然而大多数后期处理厂商建议至少要维持最新的备份数据的原本的格式，以便促进更快的恢复。(据统计，如果可行，大多数恢复来自于最新的备份)

在比较恢复时间的时候，要确保你已经清楚了数据从远程站点被恢复所需的时间，无论被隐藏在主站点上还是非主站点上。维持主站点的一个大的缓存可能会导致更佳的恢复时间，例如已被传输到灾难恢复站点的数据，但是这可能不是恢复种类(你必须在你的环境中操作)的现实的代表。

磁盘价格变得越来越实惠了，但是主站点上的大量的缓存花费了比更少缓存或没有缓存的磁盘更多的费用。如果被隐藏很多天的话还值得备份在主站点上么？如果必须在灾难恢复站点进行恢复的话，你可以做的是什么？你需要的数据会适用于主站点的磁盘存储么？数据不仅应该在主站点上，还应该必须是可恢复的。在灾难发生的时候，上述情况可能并非总是如此。

在考虑这些问题的时候，头脑中有一些意识变得日渐明显。如果你有严格的RPO/RTO请求的话，运行速度很快的最新版本的在线重复数据删除技术可能会很好地创造TTR，可能会比后期处理的重复数据删除技术的做法少用几个小时的时间，甚至当后期处理做法的备份提取(而非重复数据删除)性能比在线设备的超额完成任务量在2倍到3倍的情况下也是如此。在你处理大的备份集的时候这就不再是一个问题了，在与可同时进行备份提取和重复数据删除的后期处理技术进行对比的时候，我们发现单一的最大的备份任务将很可能决定在线处理与后期处理做法的TTR的不同。这是因为大多数的后期处理重复数据删除做法在备份任务完成之前不能开始进行重复数据删除。这就意味着有着严格的恢复规定的规模较大的企业实际上可能更适用于在线重复数据删除技术。提供带有重复数据删除性能的这些解决方案至少可以满足你的网络交付数据能力的要求。

在制定采用重复数据删除技术的灾难恢复战略的时候，与数据复制功能进行整合是满足企业恢复需求的一个关键的功能，不仅可以简化数据迁移流程，还有助于进行更加自动的数据恢复，并提供可能减少几个小时时间内的TTR。

总结

虽然不同厂商的产品的架构存在很大的不同，但是这些不同并不会对TTR造成很大的影响，因为市场上仍然有一些可以起到作用的关键产品。通过了解你的需求，然后了解不同厂商做法的影响，你就可以把工作重点放在指标的定制上，并且让这些指标来帮助你更直截了当地作出技术决策。