谷歌如何备份互联网和海量数据

2014年2月14日存储在线编译：雷蒙布卢姆(Raymond Blum)领导着一支站点可靠性工程师团队，主要负责谷歌数据的保密性和安全性。当然，谷歌永远也不会透露那些数据的总量是多少，但是从其高管的言语中来看，那些数据总量没达到YB级至少也达到了EB级。仅Gmail服务的相关数据就达到了EB级。

布卢姆在解释谷歌如何互联网时称，常规的备份策略在谷歌是行不通的，原因是：在一般情况下，它们会随着容量进行调整。

他谈到了以下要点：

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

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

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

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

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

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

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

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

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

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

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

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

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

       场地隔离

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

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

       因媒体失效导致的隔离

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

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

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

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

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

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

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

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

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

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

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

如果没有漏洞的话，MapReduce在3万台设备上运行还是不错的。但是如果系统有漏洞的话，那后果立刻就会被放大无数倍。

如果整个站点出现宕机，那么即便有本地数据副本也无济于事。

如果你的服务器机房进水了，那么即便你使用了RAID也没用。

谷歌直到一年前才停止使用的Google File System（GFS）系统充分发挥了RAID的概念。利用编码技术同时向不同城市的多个数据中心写入数据，因此你只要一些碎片就能完成数据的重建工作。 因此，即便3个数据中心同时熄火，你仍然能够使用自己的数据。

有效性和完整性都是整个机构的特征。

谷歌工程师、BigTable、GFS、Colossus都知道保证数据耐用性和完整性是首要大事。现在有很多系统就是用来检查和纠正数据有效性和完整性方面的错误的。

你想要多样化的配置。

如果你担心站点问题，请把数据存放到多个站点。

如果你担心用户人为误差问题，请禁止用户人工操作。

如果你想让数据不受软件错误的影响，就请把它放到不同的软件中。将数据保存到不同厂商的设备上可以降低大厂商故障的影响。

利用磁带将数据备份起来真的非常好。

磁带其实很好用，因为它跟磁盘不一样。如果可以的话，他们可能还会使用打孔卡片来储存数据。

试想一下，如果你的SATA硬盘的设备驱动程序中出现了一个漏洞，会出现什么样的后果呢？如果使用磁带的话，就不会有这样的问题了。 它增加了你的多样性，因为不同的媒体需要使用不同的软件。

磁带容量符合摩尔法则的规定，因此将磁带当作备份媒介来使用是很不错的，即便它们能够在其他设备上使用，它们也不会泄密。

磁带是加密的，这就意味着坏人很难从中得到有用的东西。

备份是无用的。你关心的其实是数据修复问题。

如果系统存在问题的话，你就必须在用户使用数据前找出它们。当你需要修复数据时，你就需要用到它了。

持续不断地进行数据修复。随机选择5%的数据进行备份，然后修复数据并进行对比。 为什么呢？ 在数据丢失前，搞清楚备份系统是否工作正常。这样可以找出并解决很多的问题。

进行自动对比。不能跟原始数据进行对比，因为原始数据已经发生了变化。 因此，给所有的数据分配检验数字，然后对比那些检验数字。将数据放回源媒体、磁盘、闪存或是其他任何存储媒介。 确定数据能够环行一周再回来。这个过程一直在进行之中。

如果故障率出现变化，就发出警报。

如果有些东西发生了变化，你可能想知道到底是怎么回事。如果一切运行正常，那就别来烦我。

系统肯定会不时出现一些故障，但是如果只是某个文件在首次修复时出现问题，那就不用发警报了。

假设第一次出现故障的概率为N，第二次出现故障的概率为Y。 如果故障率出现了变化，那么肯定是哪里出错了。

一切都停止下来。

磁盘经常因为故障而停止工作，但是这种事情一发生你就会知道，因为你一直监控着磁盘。

如果使用磁带的话，那出现故障时你是不知道的，只有当你想去使用它时才会知道它出现了故障。磁带可以存放很长的时间，但是在你需要用到它之前，你需要先进行测试。

磁带上的RAID4。

不要将数据只写到一盘磁带上。它们都是盒式磁带。 机械臂也许会失手掉落磁带，磁带上的磁粉也许会掉。不要冒险。

当把数据写到磁带上的时候，告诉写入软件将数据保存好，知道我们发出它可以改变的命令。如果你这样做的话，你已经违约了。

写满4盒磁带后，通过XORing即可生成第五盘代码磁带。这5盒磁带中丢掉任何一盘磁带，你都依然可以恢复数据。

现在告诉写入程序它们可以改变源数据了，因为数据已经被存放到最终的位置上，现在那些源数据变成备份冗余副本了。

谷歌备份的每一点数据都要经过这种处理。

每月丢失的磁带可能达到数百盒，但是由于这个处理程序的关系，每个月的数据丢失事故并不会达到数百次。

如果一盒磁带丢失了，可以利用持续不断的数据修复检测出来，然后你就可以利用相关的磁带重新制作一盒与丢失的磁带一模一样的磁带，所有的数据就都恢复了。如 果碰巧遇到两盒磁带都损坏的情况，那只有当那两盒磁带的损坏点也是一样的时候，你才会丢失数据，你可以利用磁带重新恢复数据。

不要因为这些技术而令数据丢失。数据丢失的代价太大了，但这就是商业成本。

备份是你为避免发生数据修复成本而采取的预防措施。

它是一个数据修复系统而不是备份系统。数据修复是不可避免的中断。 它们非常有用。利用备份来恢复数据。

按照要求对数据进行备份并根据需要将它们保留足够长的时间。尽可能快和尽可能自动去进行数据修复。

数据修复操作应该是简单、迅速和快捷的。你应该能够通过一项简单的操作来启动数据修复。

数据修复工作可以在你休息或睡觉的时候进行。因此，最好不要在数据修复操作中添加任何人工操作的要素。 你承受着压力。因此，当你在备份数据时请把数据修复的准备工作也做充足。

很大一部分系统都是这样工作的。

数据源也许必须将数据保存一段时间，这段时间也许是几天，然后才能将那些数据备份。但是一旦数据被备份好，它应该能够迅速被恢复。

为了让数据修复的速度尽可能快一点，请不要频繁使用备份媒体。花两个小时的时间去读一盒磁带的做法是不可取的。 只将一盒磁带写一半，然后同时读取两盒磁带，这样你就可以将数据恢复的时间缩短一半。

调整是一个问题。

当你有EB级的数据需要备份时，现实中还有其他一些限制条件。如果你必须拷贝10份EB级的数据，那你可能需要10个星期的时间去备份每天的数据。

由于数据中心遍布全球各地，因此你还有一些选择的余地。你是否会给每一个站点分配近乎无限的备份容量？ 你是否会按地区将所有的备份数据集合在一起？ 传输数据的带宽如何？ 你难道不需要为业务流量预留带宽吗？

相关成本。这里有很多折中方案。 并不是每一个站点都有备份设施。必须保证网络上的可用容量处于均衡状态。 备份必须在X站点进行，因为它有所需的带宽。

你不可能成比例地调整规模。

不能说你想要多少网络带宽和磁带都行。磁盘会出现故障，因此如果你有1万块磁盘的话，你可能需要1万多名操作员去更换它们。 你有1万个装载支架来放磁带吗？这都不是成比例增加的。

虽然磁带库的数量已经上升了一个数量级，但是对人员数量的要求并没有同步提高10倍。需要的人数肯定会增加一些，但肯定不会象按比例增加那么多。

有一个例子可以说明这一点，早期人们曾预测电话数量会增加30%，那么话务员的数量也应该增加30%，但是事实上并非如此，因为后来使用了程控技术自动接线。

自动化技术

日程安排已经实现了自动化。如果你有一项服务并且需要储存数据，你可能每隔一段时间就需要对数据进行备份一次，然后需要每隔一段时间对数据进行修复。 这些数据备份和数据恢复工作都可以由内部系统自动完成。备份是计划好的，系统可以自动进行数据恢复的测试工作和完整性测试。 当系统检测出某一盒磁带出现故障时，它会自动进行处理。

作为人，你不需要了解这些东西。也许在未来的某个时候，你才会想起来去查看一下有多少磁带出现过问题。 如果磁带故障率发生变化，从每天100盒增加到每天300盒，系统才会发出警报。 但是在系统发出警报之前，系统是不会提示你每天有100盒磁带出现问题是在正常范围以内的。

人工不应介入稳态运行的系统。

包装和运输硬盘仍然需要人工来完成。 自动准备运输标签，获得RMA编码，核对发出的包裹，接收回执，这都是自动进行的。只有当这个流程中断时，才需要人为干预。

库软件维护也是如此。如果有一个固件需要升级，并不需要派一名员工去给每个系统升级。 下载固件升级，然后将它送到总控制库即可。 对固件升级进行测试，尽可能准确地验证测试结果。 然后将它发出去。这套正常操作不需要人工干预。

自动处理设备宕机事故。

很多设备每分钟会宕机两次。如果在使用3万台设备执行MapReduce作业时有一台设备宕机，那就别告诉我了，只要自动处理好它然后继续执行作业就行了。 再找一台设备，将工作负载移动过去，然后重启设备。

如果设备之间存在关联性，那就请在计划中加一个等待指令。如果系统等待的时间太长，则可以向管理员发出警报。 你处理你自己的计划工作。这是算法应该做的事，而不是人应该做的事。

在数据增长的同时，保持效率不断提高。

提高利用率和效率。数据量增长100倍的时候，决不能出现对人员或设备的需求量也增长100倍的情况。

2011年的GMail宕机事故和修复情况。从中可以看出谷歌是如何丢掉数据然后又找回那些数据的。他在周日上午10:31收到一条警报信息，上面写着：“Holly Crap呼叫xxx-xxxx”。如需了解更多关于那次宕机事故的信息，请点击这里。

Gmail服务的数据量已经达到EB级了。那需要使用很多很多的磁带。

100%恢复。数据可用性并不是100%。 丢失的数据在事故发生后的第一天或第二天并没有全部恢复。 但是最终，所有的数据都被恢复了。

复制层发生了一系列故障和事故。是的，我们有三个相同的文件，但是它们都空了。 即使进行过设备测试、系统测试和装配测试，故障也无法避免。

从磁带恢复数据。这是一项繁重的工作。 数据恢复的时间与数据规模是成正比的。恢复1GB的数据也许只要1毫秒到几秒的时间就行了。 但是要恢复20万个收件箱（每个收件箱中都有几GB的数据），那就要一些时间了。

叫醒了欧洲的两名员工来处理此事，因为当时他们那里是白天。将人员分配在不同的地方，就是有这样的好处。

数据被从每一盒磁带上恢复过来，并经过了验证。这项工作没有花太多的时间，只用了几天就完成了。 员工们对此感到满意。遇到类似事故的其他公司花了一个月的时间才意识到他们无法将数据恢复回来。 谷歌采取了一些措施来保证下次遇到类似事故时会更快地完成相关的处理工作。

读一盒磁带要花2个小时的时间。磁带散布在很多地点。 没有哪一个站点有足够的计算能力去读取所有与数据恢复有关的磁带。

利用压缩技术和检验数字技术，其实并不需要把20万盒磁带都读一遍。

从那以后，数据恢复工作就一直在不断改进。

为各种数据的恢复工作设定优先等级。

你应该对各种数据的恢复工作设定优先等级，比如先恢复你正在使用的收件箱的数据和已发送的电子邮件数据，然后再恢复归档数据。

一个月都没有被碰过的帐户可以放在后面恢复，优先恢复相对比较活跃的用户的帐户的数据。

备份系统被视为一个巨大的全局有机组织。

例如，不要只在纽约备份GMail服务的数据，因为如果数据中心的规模扩大或缩小，备份数据的规模就应该相应地进行调整。

将备份当作一个巨大的全球性系统来对待。当备份发生的时候，它也许是在其他任何地点进行的。

利用磁带来恢复数据必须在磁带所在的地点进行。但是数据可以在纽约而备份却在俄勒冈进行，因为俄勒冈的数据中心有足够的容量。 地点隔离是自动处理的，谷歌没有将数据的备份地点告知客户。

容量是可以移动的。由于有一个全局容量并得到网络的支持，因此磁带在哪里并不重要。

你拥有的数据越多，数据备份工作就越重要。

东西越大就越重要，这是一条常规定律。谷歌以前只做搜索业务。 现在它有了GMail服务，因此它变得更大和更重要了。

建立一套优秀的基础设施

随身携带一把瑞士军刀真的很好。当MapReduce被开发出来的时候，他们可能从未想到过它会被用于备份。 但是如果不是已经开发出MapReduce的话，那么人们也不会想到把它用于备份。

调整规模真的很重要，你不能只拥有它的一部分，比如软件、基础设施、硬件、流程等等。

你不能说，我有足够多的员工，因此我打算使用更多的磁带。如果你打算将员工人数增加一倍，先想想你公司外面的停车场是否能增加一倍的停车位吧。 公司的自助餐厅和休息室呢？ 每一样都要增加一倍，最后你肯定会遇到一个过不去的瓶颈，然后不得不停下来。

在实际应用中证明它。

凡事都不要想当然。希望并不是一种策略。

如果你不去测试它，它就无法正常工作。要想验证备份，就必须进行数据恢复工作。 除非你到最终都没有证明任何东西。事实证明，这样的做法会导致大量的事故出现。

灾难恢复测试。

每过N个月都会出现一种灾难。你应当在企业组织的每个层级模拟灾难发生时的反应。

如果灾难什么都不带走，公司将如何生存呢？ 必须学会适应。

在基础设施和物理安全设备中找出巨大的漏洞。

设想一下，如果有一个数据中心只有一条路通向外界，那么那条路上必然塞满了运输发动机燃料的卡车。如果那条路不在了，会怎么样？ 最好再增加一条通道和另一条输送柴油机燃料的供应管道。

制定供应链备用策略。

在不同的时间点和不同的地理位置及时对不同软件的数据进行备份。

不要只是让数据在不同的系统层级之间移动，而是应该将数据保存在系统的不同层级中。 这样当你丢失某些数据时，你还可以从其他地方恢复它们。时间、地点和软件，这都很重要。

以GMail宕机事故为例。如果复制软件存在漏洞，怎么可能不出现数据丢失事故呢？ 这是某位听众提出的问题，他并不想要知道处理的细节。数据不断被备份。 假设从晚上9点之后的数据我们都有，而数据错误是在晚上8点发生的，但是错误的数据还没有被备份到磁带上。 错误被停止了。软件被恢复到之前某个正常运行的状态。 在某一时刻，所有的数据都是完好的。那些数据都在磁带上。 有些数据被复制了。 有些数据在前端，有些数据在日志里，这些数据源的某些数据是重复的，你是有可能重新所有的数据的。 在这些情况下，不要将数据从设备中提取出来，直到它被存入另一台设备后过了N小时才能那么做。

删除问题。

我想删除这些数据。不要通过重写磁带的方式去删除磁带上的数据。 由于磁带的规模太大，那样做的成本就太高了。

有一种更加可行的做法是，利用密钥来达到目的。它不会告诉我们谷歌在做什么。 也许钥匙丢掉就等于把数据删除了。

只有当员工们彼此信任且共同承担责任时，一个规模庞大的组织才能高效运转。

彼此信任。

确定组织界面和软件界面都得到了明确的定义。在各个层级之间进行验证测试。

制定白名单和黑名单。

确保数据被存放在一个受到保护的地方并且保证那些数据不会被存放到某个特定的地点。这有助于保证地点多样性和地点独立性。

这并不是设备固有的功能。必须添加到支持管理条件中。

将责任下方到尽可能低的层级。填写正确的档案，它就象魔术一样发生了。