显然，甚至在1TB企业驱动器上迁移100PB数据可能导致严重的数据丢失，而且就我所知很多云并没有采用RAID或者通过镜像来保护数据。记住，完美的情况是没有通道故障、内存损毁和其他所有类型硬件故障和潜在损毁。那么如果情况并不完美，故障率以数量级恶化的话呢?

　　以现有技术来说，你可能会丢失900TB数据，这并不是一个小数字，需要花费不少时间来进行复制。

　　带宽限制复制

　　现在让我们来看一看在不同因特网连接速度下对数据卷复制所需的时间。

　　显然，没有人会采用OC-768连接，而且短时间内也不会有人使用，很少有人会将100PB的数据复制到一个云中，但是问题在于，数据密度增长的速度要快于网速。现有已经有人提到了100PB归档，但是他们并没有提到OC-384网络。在灾难发生的时候，使用OC-384复制100PB数据将需要10个月的时间，而且谁会用得起OC-384?这就是原因所在，至少对最大型的企业存储环境来说，一个集中化的灾难恢复站点(当需要找回所有数据的时候你可以使用它)将是可预见的未来内企业的一个需求。

　　带宽问题并不仅仅局限于企业用户。在未来的12到24个月内，我们大多数人将采用10Gb网络连接，而在家庭内基于因特网的最快连接是OC- 768，这样从内部来说我们每个人的连接速度大约是OC-768的6.5%。当然这将受到DSL和线缆连接的限制，但是他们的性能将会继续增长并消耗掉主干网带宽。这是非常惊人的，尤其是考虑到我们生成了多少数据、迁移这些数据需要多少时间。我曾经使用了一项家庭因特网备份服务，在家有大约1TB的数据，而通过网线连接将所有这些数据离线复制完成竟然花了我三个月的时间，这就是瓶颈所在。如果我在创建离站拷贝之间发生系统崩溃的话，可能我的数据就会丢失了。

　　像Internet2这样的技术可能会缓解一下这个难题，但是我担心我们生成数据的速度要快于迁移数据的速度。当数据丢失(由人为错误和自然灾难等等导致)的时候这个问题就变得尤为关键，而且你必须重新复制数据。你将所有这些数据保存在云中，在两个不同位置保存两个副本。在这期间，你可能只进行了一次拷贝，考虑到硬错误率，你可能正处于风险中。你可以有多于两个的副本——这对任务关键数据来说可能是一个好主意——但是这样做的成本会很高。

　　谷歌、雅虎和其他搜索引擎大多使用云技术来保存数据，但是那些已经有10、20、40或者更多PB不频繁使用的存储数据的归档站点该怎么办呢? 现在有很多站点，不管他们保存的是医疗数据、医疗图像或者基因数据，或者气象站点这样有大型图像的站点，或被要求保存所有符合Sarbanes- Oxley法案的数据的站点，将所有这些数据在线保存有意义吗?可能没有意义，数据大小和成本将是最大的难题。