正如人们所期望的，备份软件厂商当前正在其功能集中增加重复数据删除功能。此外，备份软件厂商，如CommVault正在使用一种数据缩减技术，也即众所周知的单实例技术，在备份主机接收数据并开始文件层次的比较时发挥作用。

尽管这种方法很明显会降低备份过程引发的某些存储要求，但是它不能解决网络带宽的需求问题，也不能解决类似数据的多个副本的问题(只有那些通过特定应用程序运行的数据才需要检验是否存在冗余)。

单实例存储并不能解决备份存储中存在的另一个大问题：那些定期发生轻微变动的文件。

在单实例存储中，那些不需要每天变化的离散文件通常被排除在备份的实例之外。然而，在所有的备份传送策略中，那些无变化的文件并不是问题所在，那些每天变化一点的大型文件才是真正的问题所在。

数据库，VMware镜像和Exchange存储通常每天都会发生轻微变化。一个文件层次的单实例对照能够看到不同文件之间的变化，但不能显示同一文件之间的轻微变化。

这意味着，整个文件必须要重新存储，与真正的重复数据删除技术相比，这会导致贫乏的数据缩减效果。很明显，万一没有数据块级别的缩减，就不可能节省空间，特别是对那种超大型的数据库文件来说，更不可能节省空间了。

单实例存储另一大无法解决的挑战在于，相似的数据集中通常存在多个备份源。例如，备份管理员可能会使用备份软件的Exchange模块来备份Exchange;而Exchange管理员可能同时还使用另一单独的工具来备份Exchange存储。在这个备份过程中不存在数据缩减，因为一个备份软件不能看到由另一个独立的备份工具创建的备份。

在这两种情况中(频繁且小规模变化的应用程序及多个备份源的情况)，基于块级的重复数据删除系统会识别冗余的数据块，从而即便是备份源不同(可能来自备份应用程序或是Exchange)，也能够减少存储负担。

那些使用单实例存储技术的软件供应商声称这种方式是最适合存储恢复的方式。言外之意是，重复数据删除系统存在一些恢复性能方面的问题。

然而，虽然一些厂商的重复数据删除系统中有可能已经存在一些恢复性能问题，但是只要系统的架构设计得当，那么重复数据删除过程应该就不会给性能造成很大的影响。

在真实世界的数据中心中，在通过通用型数据删除系统进行恢复的过程，备份后数据和源服务器之间存在太多的其它瓶颈，这些是问题所在。

万一恢复的性能需求超过了从磁盘恢复的能力，那么就需要考虑其它的高可靠性解决方案，例如集群技术或活动目标等。(活动目标是一种备份目标应用程序，可以像正常的文件系统一样被浏览和阅读访问。)

最后，单实例存储方法的前提假设是所有数据类型的所有备份、归档及其它数据管理功能都使用单一软件应用程序。这个假设并不实际。

虽然很多备份软件厂商确实提供了备份以外的某种形式的附加组件，但是这些附加模块的功能性有所不同，并且实际上大部分客户在归档和备份上是分别使用不同的解决方案，在特定平台(如VMware)上使用特定应用程序。此外，软件制造商为一个针对唯一的数据库或操作系统的模块所投入的时间和成本也是有限的。