近来有关备份的问题之一是如果可以消除整个备份程序，那么快照，重复数据删除，压缩和复制的功能的多数存储系统，他们是否也可以被消除呢？这个想法听起来很好。让主存储自己掌控，这样也可以消除数据中心中的一个麻烦进程，但是这个策略也有一个漏洞。那就是主存储可以完全完成我们所期待的备份任务吗？
　　例如，备份系统的能力是当一個系统发生故障或数据设置被破坏时，我们可以追溯到某个特定的时间点。这就意味着在某个时间我们能够复制一套好的数传串，通常我们是在晚上来做，并且在一个独立的存储设备上来存储这些数据，这些独立的存储设备通常容量比主存储小，价格也比主存储更便宜。
　　在存储冗余副本时，使用快照，重复数据删除，压缩和复制功能是一套更高效的方法。很多主存储系统利用重复数据删除来支持更多的快照或不限制数据副本。多数可以把数据复制到一个远程站点，因此可以避免在一个站点发生灾难后没有先前数据的问题。有了这些功能部署，我们现在可以在灾难发生时，及时地在某个时间点恢复，并且整个系统也可以被恢复，但是即使这样，还存在一些潜在的缺点。
　　使用主存储存在的一个明显的漏洞是在主要位置发生一个系统故障的风险。这可能来自一个控制器错误或一个多驱动故障。如果主存储系统发生故障时，而主存储是备份副本的唯一来源，那么这时你需要从远程副本中恢复数据。此时，最主要的问题是时间。需要多长时间从广域网上获取数据，并恢复本地系统的数据呢？和通过线上获取所有的数据这种方法相比，把它传送到灾难恢复单元更容易些。
　　另一个问题是所有冗余数据的参考方法。通过重复数据删除，当制作一个数据副本或做快照时，快照或重复数据删除服务为冗余副本创建一个参考表格来标记写入要求，而不是实际的写入。这个参考表格是一个数据库。主要是为了应对潜在的故障。主存储上的数据和所有副本的数据点都依赖这个表格来配置自身数据。如果表格被破坏了，那么在某个时间点的副本甚至主存储数据都变得不可读。
　　以上情况发生的几率都很小，但这也就是我们做备份来防止数据丢失的原因。你可以在本地复制第二个模块儿，在灾难恢复时复制第三次，这和备份基本上是一样的事情。我们同样也可以假设系统故障或破坏瞬时发生。
　　不管是重复数据删除或快照都可能会产生错误，但这个错误不会即刻显现。我们有可能在一个坏的表格中写入了数据，重复数据删除也可能在积极地寻找错误，所有的程序都正确地进行，直到一个月后，你可能才发现这个问题。你突然读取一个文件时，这个文件可能丢失了，也可能被破坏了。多数重复数据删除进程可以自我检查代码，这样有助于防止发生类似的事情。但是这种事情也是值得注意的。
　　多亏了主存储上的快照，重复数据删除和复制，甚至是二级恢复也可以很好的被接受。它基本上可以99.999%的保证你的关键信息迅速恢复。在一个独立的平台没有存储数据时，要特别注意它的风险。