谷歌数据恢复之上

雷蒙布卢姆(Raymond Blum)领导着一支站点可靠性工程师团队，主要负责谷歌数据的保密性和安全性。当然，谷歌永远也不会透露那些数据的总量是多少，但是从其高管的言语中来看，那些数据总量没达到YB级至少也达到了EB级。仅Gmail服务的相关数据就达到了EB级。
    布卢姆在解释谷歌如何互联网时称，常规的备份策略在谷歌是行不通的，原因是：在一般情况下，它们会随着容量进行调整。

他谈到了以下要点：

从未出现过数据丢失的事故。即使在GMail服务宕机时也没有丢失过数据，但是这比磁带备份要复杂得多。 整个系统的各个地方都需要检索数据，这就要求它在包括人在内的每一个层级上都提供引擎。

备份无用。它其实是你最关心的数据恢复功能。 它是一个恢复系统而不是备份系统。备份只是数据恢复战略中的一部分内容。 将任务转至备份，让它具备所需的各种功能，以便将数据恢复工作尽可能地简化。

你无法按比例调整。 如果数据量增加一百倍，你不可能将人力资源或机器资源也增加一百倍。你应该去寻找倍增器。 自动化是提高利用率和效率的重要方法之一。

无处不在的备用冗余。谷歌有很多种服务，总是会有某一些服务出现故障。这是不可避免的，就象人体内的细胞也在不停地老化死去一样。 谷歌从未想过能够避开这种情况，而是未雨绸缪地制定对应的计划。

无处不在的多样性问题。如果你担心某个站点不完全，那就请把数据放到多个站点上储存。 如果你担心的问题是用户误操作，那就请设置各种隔离政策，对用户互动进行限制。如果你想免于受到软件漏洞的危害，那就请使用不同的软件。 将数据保存在不同厂商的设备上可以减少软件漏洞的危害性。

将人中整个工作流程中解放出来。Gmail保存了多少份电子邮件的副本? 人们不应该去关心这样的问题。有些参数是由Gmail设置，然后由系统来管理的。 这是惯例。高级政策设置完成后，系统就会照此执行。 只有出现超常规的事情后，才需要人工介入。

用实际应用去证明它。如果你根本就不去尝试，那么它肯定是无法正常工作的。 备份和恢复一直处于被测试状态中，目的是验证它们是否能够正常运作。

不管是大型企业还是小型企业，都能从中学到不少知识。 布卢姆谈到的那些内容既风趣，又有教益，非常值得一读。他本人似乎也非常喜爱这项工作所具备的挑战性。

以下是我个人获得的一些心得：

数据有效性必须是100%。 永远也不会出现数据丢失的情况。

从统计学的角度来说，如果你在一个2GB的文件中丢掉200K的数据，那可能并不是很多，但是那份文件可能就变得不能用了。

数据有效性比访问通道有效性重要得多。如果一个系统宕机了，情况并不会变得十分糟糕。 但是如果数据丢失了，那就非常糟糕了。

谷歌保证你会遇到下列情况的各种组合：

场地隔离

因应用层出现问题导致的隔离

因存储层出现问题导致的隔离

因媒体失效导致的隔离

你必须考虑到你能控制的范围。将软件标在纵轴上，地点标在横轴上。 如果你想覆盖所有的东西，你就需要在每个不同地点都保留一份软件层的副本。你可以在不同地点使用虚拟机来实现这个目标。

备用冗余与可恢复性并不是一回事。

保留再多的数据副本也不能保证不发生数据丢失的事故。

对于某些类型的宕机事故来说，保留很多份数据副本确实是有用的。如果一颗流星撞击了一个数据中心，而你在远程站点保留了数据副本，那你当然不会受到影响。

如果你的存储设备中有一个软件漏洞，那么将数据复制到再多的设备上也无济于事，因为所有的数据副本都存在那个漏洞。Gmail宕机就是最好的例子。

数据中心遭流星撞击的概率绝不会比软件漏洞、用户误操作或错误数据写入等情况出现的概率高。

备用冗余非常适用于局部引用。当你希望所有的数据引用尽可能接近数据被使用的地点时，复制是个很好的方法。

整个系统的实用性达到了惊人的程度。

谷歌有很多种服务，总是会有某一些服务出现故障，这是不可避免的。 就象人体内的细胞在不断地死亡一样。我们从未想过实现服务从不出现故障的目标。 我们为它制定预案计划。各种设备总是会出现故障。

备用冗余就是解决问题的方法。事实证明，多台设备的可靠性比一台优质设备的可靠性更高。 一台设备可能会因为某种灾难而被毁掉。但是存放在50个不同地点的很多台设备是很难在同一时间一起被毁掉的。

大规模并行系统出现数据丢失的概率更高。