大公司如何备份他们的数据？

这取决于你的目的是什么。

如果您正在寻找备份进行灾难恢复（服务器爆炸，数据中心烧毁等），那么简单的答案是，他们可能根本就不做备份。 我们有一个处理敏感政府数据的客户，他们的部分任务是我们不允许在可移动媒体上进行备份或备份 。 我们被允许实时复制到容灾站点，就是这样。 这两个站点都在相同的物理和逻辑安全级别。 这里的问题是，如果我在Site A上搞砸了一些东西，那么它几乎可以立即复制到Site B上。

如果您从数据完整性的angular度谈论备份（例如，您不小心丢弃了Customers表，并且已经将其复制到灾难恢复站点），那么大型磁带库中的LTO-5磁带通常就是这样。 每个磁带最多3TB，磁带库中有多个磁带可以快速备份大量数据（这里的快速指的是Mbps，备份25TB数据可能还需要很多很多小时）。

任何体面的备份套件都可以进行高压缩和重复数据删除，这大大减less了所需的存储空间。 我看到一个压缩和重新启动的Exchange备份工具的估计值，据称这个比率为15：1（15GB的数据存储在1GB的备份中）。

我非常怀疑Google会为他们的许多search引擎数据进行备份，因为大部分search引擎数据是可以replace的，而且它的分布范围如此之广，以至于如果系统失去了很大一部分甚至是整个数据中心在线感谢故障转移BGP路由。

实际上， 谷歌看起来像是把大量的数据备份到磁带上 ，这并不是我所期待的：

他们的大部分数据都存储在他们自己的GFS文件系统中，而且GFS要求每个64 MB的块至less有三个副本生成一个文件（GFS使用64 MB块）。 话虽如此，我不认为他们打扰备份，因为他们至less有三个副本的每个文件，和故障节点上的块可以迅速取代简单复制数据从任何剩余的两个良好的副本到一个新的节点。

有关更多信息，请参阅http://labs.google.com/papers/gfs.html

farseeker的答案是好的，但我认为可以通过从这个angular度思考来澄清：你想要恢复什么？ 这是DR吗？ 需要什么恢复时间？ 举个例子，假设你的公司依赖于一个25TB的sql服务器数据库。 如果数据失败或错误（丢失表格，损坏的数据库等），首席技术官希望能够在一小时内恢复数据库。 如果发生站点故障，则需要2小时。

面对这听起来很难，但这不是不可能的。 由于您知道您的备份策略必须在一小时内恢复，因此您知道不会恢复完整备份，您将不得不与dba团队一起工作，以确保将数据库划分为可pipe理的块。 你也会做频繁的日志备份。 对于灾难恢复应该考虑一个复制策略（可能是一个时间延迟版本的日志数据实时复制，但不适用）。 正如farseeker所说，这取决于目的，而这个目的应该是做某种forms的恢复。