【编者按】作者Todd Hoff是High Scalability创始人，为我们解读Google数据保密和数据安全负责人Raymond Blum的演讲。数据安全的一个重要工作就是备份，备份的容量扩展、存储备份的媒介、备份的效率……通过对互联网中庞大数据多样化、复杂的备份，使数据在任何情况下都能简单地还原、恢复。数据安全不仅仅是一个技术问题，它还受到现实的种种限制，做好数据安全，是任何一个企业都要考虑的问题。
CSDN推荐：欢迎免费订阅《Hadoop与大数据周刊》获取更多Hadoop技术文献、大数据技术分析、企业实战经验，生态圈发展趋势。
以下为译文：
Raymond Blum带领Site Reliability Engineers团队负责谷歌的数据保密和数据安全。当然Google从来都不会如实说有多少数据，但从评论上看目前还没到 yottabyte级（1YB=280B），不过也有很多exabyte级（1EB=260B）的数据了。仅Gmail就有接近exabyte的数据。
Blum先生在名为“ 谷歌如何备份互联网”的视频中解释，常见的备份策略对谷歌无效，原因听起来让人吃惊：它们大多是在努力用容量实现扩展。如果备份两倍多的数据，那时间、能源、空间也会消耗两倍，如果不这么做，就不能进行扩展。要让容量比支持容量的能力扩充更快，必须要有效率。从备份1exabyte数据转变到备份2exabyte数据，需要一个不同的计划。演讲的内容的主要关于Google是如何实现容量扩展的。
演讲的一些主要议题：
- 从无数据丢失。甚至影响颇为不好的GMail停电事件也没有丢失数据，这远比备份许多磁带要复杂的多。数据从整个堆栈检索，每一层都需要管理，包括对人的管理。
- 备份无用。还原你想要的部分，这是指还原系统而不是备份系统。备份是你要为还原付出的高昂代价。将工作转移到到备份上并使备份适当的复杂，是为了让还原尽可能的简单。
- 不可以线性扩展。不可能有100倍的数据，你就能得到100倍的人力和机器资源。你只能去寻找使能力倍增的方法。自动化是提高利用率和效率的主要途径。
- 冗余。谷歌的存储设备一直在老化。这当然不用说都知道，就像我们身体的细胞会死一样，Google并没有幻想着事物不会消亡，它只是为事物的消亡做好准备。
- 多样性。如果你担心某个站点的位置不安全，那就把数据放在多个站点。如果你是担心用户错误，那就将用户交互与数据隔离。如果你想要避免软件bug的损害，那就把数据放在不同的软件上。从不同的供应商获取存储设备，以减少供应商的bug影响存储的数据。
- 将人从繁琐的劳动中解放出来。通过GMail保留一封电子邮件有多少备份？这不应该是人关心的事情。通过GMail配置一些参数，系统会具体安排。这是不变的主题，高级别策略设置和系统实现了它。只有规范之外的事情发生才会需要人的参与。
- 证明。如果你不试用它，那它就不会起作用。备份和还原就是不断的测试，以验证它们的工作的过程。
无论组织大小，都有很多要学习的东西。Blum先生的 演讲很风趣、信息量大、很值得一看。看起来他真的很喜欢工作中的挑战。
以下是我对这个演讲的注释，从中我们可以了解到许多不为人知的秘密：
- 数据可用性必须是100%，不能有数据丢失
- 统计学上，2GB文件中如果丢失了200K数据，似乎没什么大不了，但这个文件或许就不能用了，比如说可执行文件或报税表。
- 数据的可用性比可访问性更重要。如果系统关闭，后果并不特别严重。但如果数据丢失，那就不是小事了。
- 谷歌保证用以下所有可能组合保证数据安全：
- 位置隔离
- 隔离应用层问题
- 隔离存储层问题
- 隔离媒介故障
- 想象一下移动滑块的情形。让软件像纵向滑块那样，让地址像横向滑块那样。如果你想要包含一切，你需要不同地址的软件层备份。你可以在不同的地址使用虚拟机。
- 冗余不等于可恢复性
- 制作多个备份不能保证数据不会丢失。
- 多个备份对某些种类的停机是有效的。例如一颗小行星击中一个数据中心，而在一个很远的地方，你有这个数据中心的备份。
- 如果你在存储堆栈中有一个bug，那把它复制到N个地方也没有用，因为bug破坏了所有备份。示例：请参阅GMail停机。
- 相比小行星，代码中的bug、用户错误或已损坏缓冲区的写入，这些故障发生要多得多了。
- 冗余对访问局部性有帮助。当你想要所有的数据引用与正在使用位置的数据尽可能接近时，备份是个不错的选择。
- 因为这么多的备份，整个系统非常稳健
- 谷歌的设备一直在老化。这不用说也知道，我们身体的细胞也同样会死。我们并没有幻想事物不会消亡，我们只是在为消亡做准备。机器也一直在损耗。
- 冗余就是答案。合计一下，这要比单一的高质量机器更加可靠。单一机器可能会被一颗小行星摧毁。想要摧毁放在50个不同地点的机器就难说了。
- 大规模并行系统的数据丢失几率更大
- MapReduce在30000台机器上运行得很好，当然是在没有bug的前提下。一旦有bug出现，造成的影响也是成倍的。
- 本地备份不能防止站点停机
- 如果你的服务器机房中发生灾难性的破坏，那RAID也帮不了你。
- Google文件系统(GFS)，大约一年前，整个Google都在使用这个文件系统，它将RAID的概念又升级了一次。使用 编码技术将数据写入不同城市的多个数据中心，只需要N-1个数据片段，即可还原完整的数据。所以即使3个数据中心中一个停机了，也不会影响数据可用性。
- 可用性和完整性是组织广泛的特点
- 谷歌的工程师们，BigTable，GFS，Colossus都知道数据持久性和完整性是第一任务。很多系统需要检查并更正在数据可用性和完整性上的错误。
- 多样性
- 如果你担心某个站点的位置安全，那就把数据放在多个站点。
- 如果你担心用户错误，那就把用户交互和数据隔离。
- 如果你想要避免软件bug的破坏，那就把数据放在不同的软件上。从不同的供应商获取设备，以减少供应商的bug影响存储的数据。
- 磁带备份真的很不错
- 磁带好是因为它不像磁盘那样。如果可能他们甚至会使用打孔卡。
- 想象一下假如你SATA磁盘的设备驱动程序里有一个bug。磁带就避免了这一问题。因为不同的媒介意味着不同的软件，这就增加多样性。
- 磁带容量遵循摩尔定律，所以他们对磁带作为备份介质都很满意，虽然他们还在寻找替代品，现在很难说这些替代品是什么。
- 磁带加密意味着有着不良企图的家伙们将很难从磁带中得到有用的东西。
- 备份是无用的，真正需要关心的是还原
- 在有人需要数据之前发现数据是否存在问题，你确定需要数据时再还原。
- 持续还原。不断随机选择5%的备份，还原并对它们进行比较。为什么呢？因为需要在数据丢失之前查明数据是否还能用，找出存在的问题。
- 自动比较。因为原始文件已更改，所以不能与原始进行比较。所以将校验码和校验码进行比较。把它带到源媒介、磁盘或闪存，或者其它的媒介。请确保数据可以做一次往返，自动比较是一直都在做的事情。
- 故障率变化的警报
- 你可能想要知道是不是有什么发生了变化。如果一切运行正常，那就没有必要告诉我了。
- 预期会有一些失败，但别第一次尝试还原的文件失败就发出警报。
- 假设首次尝试的失败率是N，第二次尝试的失败率为Y。如果故障率发生变化那一定是哪里出问题了。
- 损坏
- 磁盘随时都有可能中断，但因为你监视它，所以你能及时的了解到。
- 要是磁带的话，只有你使用它的时候，才知道是不是坏了。虽然磁带保存的时间很长，但是你想在用它之前检测它是不现实的。
- 磁带上的 RAID4
- 不要将数据仅写到一盘磁带上。他们是墨盒，随时会有意外发生。
- 向磁带写入数据时，编写器要保持数据不变，直到数据被完全写入。
- 建立4盘完整磁带，然后通过XOR（逻辑运算）生成第五盘代码磁带。你可以失去5磁带的任何一个，也能恢复数据。
- 现在告诉编写器它们可以更改源数据，因为数据已经到了到最终的物理位置，有冗余了。
- 谷歌备份的每一bit数据都要经历这个过程。
- 数以百计的磁带每个月都将丢失，并没有造成数据的丢失，就是得益于这个过程。
- 假设当检测到一盘磁带丢失，通过使用连续还原和同级磁带重新生成另一个磁带，一切都没问题。在那种两个磁带都被损坏的罕见情况下，如果磁带上的受损的两个点相同，那数据就只好丢失了，只能在subtape一级完成重建。
- 实现这些技术的成本很高，但是为了不丢失数据，很值得。
- 备份是你为奢侈的还原付出的代价
- 它是指还原系统而不是备份系统。还原是一个不可屏蔽的中断，他们胜过一切。
- 让备份变得复杂而且只要需要就这样做。让还原变得快捷而且越自动化越好。
- 恢复应该是傻瓜式、快速和简单。就算是一只猫也能完成还原操作。
- 无论你休息得很好还是累的很惨，还原时才不会问你是不是准备好了。所以不要让人为因素决定服务数据还原的成功与否。
- 大部分的系统都是这样工作的。
- 数据源或许能够将数据存储一段时间，也许是在它备份之前的几天。但一旦备份完成，它随时都可以还原，而且还原得很快。
- 为了使还原速度更快，不能将全部资源用于备份。花两个小时来读取磁带是不可行的。只写一半磁带，并行读取它们，这样你仅用一半的时间就可以获取数据。
- 扩展是个问题
- 当你有exabyte级的数据时，也会有现实世界的限制。如果你要复制10exabyte数据，然后它会花10周时间备份每一天的数据。
- 考虑到分布在世界各地的数据中心，可供选择的方案并不多。你能给每个站点无限的备份容量吗？你会按区域划分所有备份吗？转移数据的带宽呢？你难道不需要带宽来为挣钱的流量服务吗？
- 看看有关的费用。也有一些妥协方案，比如不是每个网站都有备份设施。必须平衡网络中的可用容量。怎样才能最划算？例如，只在有足够带宽的站点中进行备份。
- 不能线性扩展
- 你不能只是说想要更多的网络带宽和更多的磁带驱动器。驱动器中断的情况，如果你有10000个驱动器坏了，你需要10000个运算器来替换它们。你有10000个装卸码头来放磁带驱动器，直到一辆卡车把它们运走。这一切都不可以是线性的。
- 虽然磁带库的数量提高了一个数量级，但参与其中的人并没有随之线性增长。
- 比如早期曾有人预测，随着电话的增多，30%的美国人会被雇佣为电话接线员。显然他们没预见到未来的自动接线。
- 自动化
- 调度被自动化。如果你有一个服务，你说：我有一个数据存储，每N天我需要一个备份，在M时必须还原。内部系统完成这些事情：计划备份、运行还原测试和运行完整性测试等等。并且磁带故障的处理也是全自动的。
- 人是无法看到这些的。也许有一天，你可能会问平均多少个磁带损坏了。或如果磁带破损率从每天100盒磁带变成每天300盒磁带时，就会发出警报。但在那之前不要问我：如果一天100盒磁带损坏是不是在正常水平内？
- 人不应参与稳态操作
- 装载和运输驱动器仍然是人类的活动。自动化的接口准备装运标签，得到RMA号码，检查已经出来的软件包，拿回执，如果出现故障，人才会进行干涉。
- 库软件维护也类似。例如固件更新时，人不会将这些更新运行在每一个系统中，系统会自动下载这些更新，并进行验证、运行。这些常规的操作不需要人的干预。
- 自动处理死机事件
- 机器平均一分钟死两台。如果一台机器在进行MapReduce作业期间使用30,000机器，有一台机器死机了，那就不要告诉我了，处理完它，继续工作。找到另一台机器，转移任务，重新启动。
- 如果有依赖关系那就先等待。如果你等得太久，就让我知道。你处理你自己的计划。这是算法的工作，不需要人为的操作。
- 保持效率正向提高
- 大幅提高利用率和效率。不能有100倍的数据就需要100倍的人或机器资源。
- 2011年Gmail停机和还原，谷歌如何丢失数据又找回
- 在周日的上午10：31他看到了一个网页，上面写：“Holly Crap打电话给xxx-xxxx”。关于中断要想了解更多，请看在 这里。
- Gmail的数据量达exabyte级别。这意味着大量的磁带。
- 100%恢复并不意味着可用性也是100%，数据恢复要过段时间才能正常使用。
- 一系列的bug和意外事件会产生在备份的过程中。即使是单元测试、系统测试和集成测试，对一些bug也是无能为力。
- 从磁带中还原意味着大量的工作。还原时间和规模相关。还原gigabyte级数据可以在几毫秒到几秒时间内完成。还原200,000个收件箱中的几个gig，每个都得花去不少时间。
- 把欧洲的几个同事叫醒，因为他们刚休息完、很清醒。这就是分布式劳动力的优势。
- 从许多磁带还原和检验数据。不需要花几个星期或几个月时间，只需要花几天的时间。这使他们很开心。在类似情况下的其他公司花了一个月时间才意识到他们找不回数据了。需要采取一些措施以确保这个处理下一次更快。
- 一个磁带驱动器需要2个小时来读。这些磁带分布在各地。否则在还原过程中，任何单一地点都不会有足够能力读取还原过程中涉及的所有磁带。
- 压缩和校验码实际上不需要读取200K磁带。
- 还原过程自那时以来已大为改善。
- 优先还原
- 已存档的数据可以在更重要的数据之后还原，比如你当前收件箱和发送的电子邮件。
- 一个月内没用过的帐户可以等活跃用户优先恢复之后还原。
- 备份系统被看作是一个巨大的全球有机体
- 例如，不要只考虑GMail在纽约备份，因为如果该数据中心增长或收缩，备份需要适当调整规模。
- 把备份看成一个横跨世界的巨型系统。备份时它可能完全是在别的地方完成。
- 在磁带上的还原必须是在磁带所在的位置。但到它制作磁带时，数据可能在纽约而备份可能在俄勒冈州，因为在那里有容量。位置隔离是自动的，客户不知道自己的数据被备份在哪里。
- 容量可以被迁移。只要有全球的容量和网络支持，磁带被放在哪无关紧要。
- 拥有的数据越多，保存好它就越重要
- 越大越重要的是他们的一条准则。谷歌曾经只是搜索引擎。现在它还是Gmail，还有驱动器、文档一类的东西。它现在变得更大也更重要了。
- 有良好的基础结构
- 处理问题时，有通用的解决方案再好不过了。在写MapReduce时可能从来没有想到它会被用于备份。但要是没有MapReduce，利用它进行备份的想法也是不会有的。
- 扩展的重要性不言而喻，软件、基础设施、硬件、流程都要可以扩展。
- 你不能说：我要去部署更多的磁带驱动器，就需要两倍的员工。你会雇这么多的人吗？你有两倍多的停车点吗？还有食堂房间？厕所？一切都要扩大规模。你会遇到一个瓶颈，然后寸步难行。
- 证明
- 别把什么事情都当作理所当然。希望毕竟不是一种战略。
- 如果你不检验它，那就起不到作用。还原操作必须要检验备份。直到你结束了你还没证明什么。这种态度已发现有很多的不足。
- DRT.灾难恢复测试
- 每N个月都要模拟一场灾难恢复，看系统每一层的反应。
- 如何做到无论灾难带走什么，公司都能生存下去？答案只有一个：必须学会适应。
- 在基础设施和物理安全发现无数漏洞。
- 想象有一个数据中心，一条通向数据中心的路，路上的卡车满载了备用发电机的燃料。那如果这条路不通了怎么办？最好有另一条路，另一供应商可以提供柴油燃料。
- 必须要有供应链冗余策略。
- 不同时间点不同地点不同软件堆栈中的冗余
- 不要仅仅通过堆栈迁移数据。特别是暂停期间堆栈不同层中保留的数据。丢失的数据可以在其它地方找到。所以记住：时间、地点和软件。
- 想一下Gmail的中断示例。如果备份损坏，数据怎样才能不会丢失？这是演讲时，听众的一个问题，他不想透露太多。数据是持续备份的。假设我们有下午9点的数据，假设下午8点出现损坏，但还没有做出磁带。这时损坏被停止了，软件被回滚到上一个工作版本。在一些还原点，所有堆栈中的数据是还在那里。这些就是磁带上的东西。磁带会备份这些东西。在前端上有，在日志中有。所有数据都可以实现重建。但要在所有数据被转移到另一个堆栈中之后再对其进行操作。
- 删除问题
- 不去重写磁带而只是删除数据的成本太高。
- 一种办法是聪明地使用加密密钥。他没有告诉我们谷歌是怎么做的。
- 当你信任你的同事，并给他们分配各自的职责时，一个巨型的组织就运作起来了
- 相信他们能胜任自己的岗位。
- 确定组织和软件接口定义得很好。执行层与层之间的检验测试。
- 白名单和黑名单
- 确保数据在安全的地方，保证数据不会在某些地方，保证数据位置多样性和位置独立性。
- 最初并不是堆栈的功能。因为要满足政府的要求，必须添加进来。
- 这些功能尽可能放在堆栈的最底层。填写正确的配置文件，就都完成了。
原文链接： How Google Backs Up the Internet Along With Exabytes of Other Data？（编译/毛梦琪 审校/周小璐）