# Google 如何备份 Internet 和数十亿字节的其他数据 > 原文： [http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html)  [Raymond Blum](https://plus.google.com/115038404694487056892/posts?hl=en) 领导了一组站点可靠性工程师，负责对 Google 的数据保密并确保其安全。 当然，Google 永远不会说这实际上有多少数据，但是从评论看来，它还不是 [约字节](http://en.wikipedia.org/wiki/Yottabyte) ，但很多 [艾字节](http://en.wikipedia.org/wiki/Exabyte) 大小。 仅 GMail 就要处理近几十亿字节的数据。 Blum 先生在视频中 [Google 如何备份互联网](http://www.youtube.com/watch?v=eNliOm9NtCM) 解释了常见的备份策略不适用于 Google 原因：通常他们以容量 扩展规模 **。 如果备份两倍的数据需要两倍的工作量（时间，精力，空间等），那么它将无法正常工作，并且无法扩展。 您必须找到效率，以便容量可以比支持该容量所需的努力更快地扩展。 从备份一个 EB 备份到备份两个 EB 时，需要一个不同的计划。 谈论主要是关于 Google 如何做到这一点。** 演讲的一些主要主题： * **从来没有数据丢失** 。 即使是臭名昭著的 GMail 中断也没有丢失数据，但是故事远不只是大量的磁带备份而复杂。 从整个堆栈中检索数据，这需要在各个层面（包括人员）进行工程设计。 * **备份无用**。 这是您关心的还原。 这是一个还原系统，而不是备份系统。 备份是您为还原的奢侈而支付的一种税。 将工作转移到备份上，并根据需要使其变得复杂，以使还原如此简单，一只猫就可以做到。 * **您无法线性缩放**。 您无法拥有 100 倍的数据或 100 倍的人员或机器资源。 寻找力的乘数。 自动化是提高利用率和效率的主要方法。 * **冗余**。 Google 的东西总是失败。 废话 人体细胞死亡的方式相同。 Google 并不梦想事情不会消亡。 它计划。 * **所有事物的多样性** 。 如果您担心站点的位置，请将数据放在多个站点中。 如果您担心用户错误，请与用户交互隔离。 如果要防止软件错误，请把它放在其他软件上。 将东西存储在不同的供应商设备上，以减少大的供应商错误影响。 * **将人类带出循环** 。 GMail 保留多少电子邮件副本？ 这不是人类应该关心的事情。 一些参数是由 GMail 配置的，系统会处理。 这是一个不变的主题。 制定了高级策略，系统也这样做了。 如果发生超出规范的事情，只会打扰到人。 * **证明** 。 如果您不尝试，将无法使用。 不断测试备份和还原，以验证它们是否有效。 对于任何规模的组织，这里都有很多值得学习的地方。 布拉姆先生的 [演讲](http://www.youtube.com/watch?v=eNliOm9NtCM) 具有娱乐性，内容丰富，值得一看。 他似乎确实很喜欢工作中的挑战。 这是我对这个非常有趣的演讲的掩饰，我们从野兽内部学习了许多秘密： * **数据可用性必须为 100％ 。** **从来没有数据丢失**。 * 从统计上讲，如果您从 2GB 的文件中丢失了 200K，这听起来不错，但是该文件现在可能已无用，请考虑执行文件或纳税申报单。 * 数据的可用性对访问的可用性更为重要。 如果系统出现故障，那不是世界末日。 如果数据丢失，那就是。 * Google 保证在所有可能的组合中为您提供以下所有服务： * 位置隔离 * 与应用层问题的隔离 * 与存储层问题的隔离 * 与媒体故障隔离 * **考虑可以在** 上移动滑块的尺寸。 将软件垂直放置，水平放置。 如果要涵盖所有内容，则需要在不同位置复制该软件层。 您可以在不同位置的 VM 上执行此操作。 * **冗余与可恢复性** 不同。 * 多份复印无助于达到无损保证。 * 许多副本对某些类型的中断有效。 如果小行星撞击数据中心，并且您的副本很远，您就会被覆盖。 * 如果存储堆栈中有错误，则复制到 N 个位置无济于事，因为该错误会损坏所有副本。 以 GMail 中断为例。 * 小行星的数量不及代码错误，用户错误或缓冲区写入错误。 * 冗余有利于参考位置。 当您希望所有数据引用都尽可能靠近使用数据的位置时，复制就很好。 * **整个系统非常强大，因为其中有很多**。 * **Google 内容始终失败**。 废话 人体细胞死亡的方式相同。 我们没有梦想事情不会消亡。 我们为它计划。 机器一直死掉。 * **冗余就是答案** 。 总的来说，结果比一台高质量机器更可靠。 一架机器可以被小行星摧毁。 放置在 50 个不同位置的机器更难销毁。 * **大规模并行系统有更多的损失机会** 。 * 可以在 30K 台计算机上运行的 MapReduce 非常棒，直到出现错误为止。 您有相同的错误等待立即在任何地方运行，从而扩大了影响。 * **本地副本无法防止站点中断** 。 * 如果服务器机房中有洪灾，RAID 将无济于事。 * 大约一年前，在整个 Google 上使用的 Google 文件系统（GFS）将 RAID 的概念提升了一个档次。 使用 [编码技术](http://en.wikipedia.org/wiki/Erasure_code) 一次写入不同城市中的多个数据中心，因此您只需要 N-1 个片段即可重建数据。 因此，有了三个数据中心，一次就可以消亡，您仍然可以获得可用的数据。 * **可用性和完整性是组织范围内的特征** 。 * Google 工程师，BigTable，GFS，Colossus 都知道数据持久性和完整性是第一要务。 有很多系统可以检查和纠正数据可用性和完整性方面的任何失误。 * **您想要所有事物的多样性** 。 * 如果您担心站点的位置，请将数据放在多个站点中。 * 如果您担心用户错误，请与用户交互隔离。 * 如果要防止软件错误，请将其放在其他软件上。 将东西存储在不同的供应商设备上，以减少大的供应商错误影响。 * **用来备份内容的磁带确实非常好** 。 * **磁带很棒，因为它不是磁盘** 。 如果可以的话，他们会使用打孔卡。 * 想象一下您是否在 SATA 磁盘的设备驱动程序中存在错误。 磁带可以帮助您避免麻烦。 因为不同的媒体意味着不同的软件，所以它增加了您的多样性。 * 磁带容量遵循摩尔定律，因此尽管他们正在研究替代方案，但他们对磁带作为备份介质感到非常满意，但他们不会说它们是什么。 * 磁带已加密，这意味着邪恶力量很难从中获得有用的东西。 * **备份无用。 这是您关心的** 还原。 * 在有人需要数据之前先确定是否存在问题。 当您需要还原时，您确实需要它。 * **运行连续还原** 。 不断随机选择 5％的备份并还原它们以进行比较。 为什么？ 在数据丢失之前找出备份是否有效。 抓了很多问题。 * **运行自动比较** 。 由于原件已更改，因此无法与原件进行比较。 因此，对所有内容进行校验和并比较校验和。 将其返回到源介质，磁盘或闪存，或它来自何处。 确保数据可以往返。 这一直都在做。 * **出现故障率变化的警报** 。 * **如果有所不同，您可能想了解一下** 。 如果一切正常，请不要告诉我。 * 可能会出现一些故障，但不要针对第一次尝试后无法还原的文件发出警报。 * 假设第一次尝试的失败率通常是 N。第二次尝试的失败率是 Y。如果失败率发生变化，则说明出现了问题。 * **一切都破裂了** 。 * 磁盘一直损坏，但是您知道它发生的时间，因为您正在监视它。 * 使用磁带之前，您不知道它已损坏，直到尝试使用它为止。 磁带可以使用很长时间，但是您需要先对其进行测试。 * 磁带 上的 **[RAID4](http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_4) 。** * 不要只写一盘磁带。 它们是墨盒。 机器人可能会掉落它们，或者可能会产生一些磁通量。 不要碰碰运气 * 写入磁带 **时，告诉编写者保留数据** ，直到可以更改为止。 如果这样做，您就违反了合同。 * 建立 4 个完整的磁带，然后通过将所有内容异或来生成第 5 个代码带。 您可以丢失 5 盘磁带中的任何一盘并恢复数据。 * 现在告诉编写者他们可以更改源数据，因为数据已经将其移到了最终的物理位置，并且现在是冗余的。 * Google 备份的每一位数据都经过此过程。 * 一个月会丢失数百个磁带，但是由于这个过程，每月不会有数百个数据丢失案例。 * 如果丢失了一条磁带，则可以使用连续还原检测到该磁带，并使用同级磁带重建另一条磁带，一切正常。 在极少的情况下，如果两个磁带都损坏，则只有在磁带上的相同两个点都损坏的情况下，数据才会丢失，因此在磁带级进行重建。 * 由于这些技术，不会造成数据丢失。 这很昂贵，但这是做生意的成本。 * **备份是您为还原**所支付的奢侈税。 * **这是一个还原系统，而不是备份系统** 。 恢复是不可屏蔽的中断。 他们胜过一切。 恢复备份。 * 使备份变得复杂并且需要的时间很长。 使恢复尽可能快和自动。 * 恢复应该是愚蠢的，快速且简单的。 希望一只猫能够触发集中还原。 * 当您休息好或狗累了时，恢复可能会发生。 因此，您不希望人为因素决定还原服务数据副本是否成功。 你压力很大。 因此，在进行备份的所有时间中，所有工作和思考都要做。 * 大量系统以这种方式工作。 * 数据源可能必须能够存储一段时间（也许几天），然后才能保证已备份数据。 但是一旦备份，便可以快速还原和还原。 * 不再最有效地利用备份上的介质来加快还原速度。 花两个小时读磁带是不好的。 只写一半的磁带并并行读取它们，这样您就可以在一半的时间内取回数据。 * **秤是一个问题** 。 * 当您有 EB 级数据时，会有现实世界的限制。 如果您必须复制 10 EB，那么每天备份数据可能需要 10 周的时间。 * 在全球的数据中心中，您有几种选择。 您是否给每个站点近乎无限的备份能力？ 您是否按地区对所有备份进行群集？ 运送数据的带宽呢？ 您不需要带宽来赚钱吗？ * 查看相关费用。 有妥协。 并非每个站点都具有备份功能。 必须平衡网络上的可用容量。 您从哪里获得最大的收益。 例如，备份必须在站点 X 上进行，因为它具有带宽。 * **您无法线性缩放**。 * 不能只是说您想要更多的网络带宽和更多的磁带驱动器。 驱动器损坏，因此，如果驱动器数量为 10,000，则需要的操作员数量是驱动器数量的 10,000 倍。 您是否有 10,000 倍的装载台来放置磁带驱动器，直到卡车将其捡起。 这些都不是线性的。 * 尽管磁带库的数量增加了一个完整的数量级，但涉及的人数却没有 10 倍。 还有更多的数字，但远非线性增长。 * 例子是一个早期的预测，随着电话数量的增长，美国人口的 30％将被用作电话接线员。 他们看不到的是自动切换。 * **自动化所有** 。 * 调度是自动的。 如果您有一项服务，则说我有一个数据存储，并且每个 N 都需要一个副本，并且还原必须在 M 中进行。在内部，系统会做到这一点。 计划备份，运行还原测试以及运行完整性测试等。当检测到损坏的磁带时，将自动对其进行处理。 * 您作为人类没有看到任何这些。 您可能有一天会问平均多少磁带断裂。 否则，如果磁带损坏率从每天 100 条磁带更改为每天 300 条磁带，可能会发出警报。 但是在此之前，请不要告诉我每天是否有 100 盘磁带破损，如果这超出了正常范围。 * **人体不应参与稳态操作** 。 * 包装和运输驱动器仍然是人类的活动。 自动化的界面可以准备运输标签，获取 RMA 编号，检查包裹是否已外出，获得收据确认，以及是否发生这种情况，必须由人工干预。 * **库软件维护同样** 。 如果要进行固件更新，则不会有人在每个系统上运行并执行升级。 下载它。 让它推送到金丝雀图书馆。 让它进行测试。 让结果验证为准确。 然后将其推出。 没有人参与正常操作。 * **自动处理机器死亡** 。 * 机器每分钟死两次。 如果一台机器在使用 30,000 台机器的 MapReduce 工作中快要死了，请不要告诉我，只需处理并继续前进即可。 查找另一台机器，移动工作，然后重新启动。 * **如果存在依赖项，则安排等待时间**。 如果您等待太久，请告诉我。 您可以自己安排时间。 这是算法的工作，而不是人类的工作。 * **随着增长不断提高效率** 。 * 大大提高了利用率和效率。 不能有 100 倍的数据需要 100 倍的人员或机器资源。 * **2011 年的重大 GMail 中断和恢复** 。 关于 Google 如何删除数据并取回数据的故事。 * 在星期日的上午 10:31，他得到了一个页面，上面写着“ Holly Crap call xxx-xxxx”。 有关中断的更多信息 [此处](http://gmailblog.blogspot.com/2011/02/gmail-back-soon-for-everyone.html) 。 * Gmail 的数据量已接近 EB。 磁带很多。 * 100％恢复。 可用性不是 100％。 在第一天或第二天还没有全部。 但是到了一段时期的尽头。 * 在复制发生的层中发生了一系列的错误和不幸。 是的，我们有三个相同的文件，但它们都是空的。 即使进行单元测试，系统测试和集成测试，错误也可以解决。 * 从磁带恢复。 大量工作。 这是恢复时间与规模有关的地方。 取回千兆字节可以在几毫秒到几秒钟内完成。 取回 200,000 个各个演出的收件箱将需要一段时间。 * 在欧洲唤醒了几个同事，因为他们比较新鲜。 分布式劳动力的优势。 * 已从许多磁带上还原了数据并进行了验证。 没花几个星期或几个月，只花了几天。 他们对此感到满意。 其他处于类似情况的公司花了一个月的时间才意识到他们无法取回数据。 已采取步骤来确保下一次该过程将更快。 * 一个磁带机需要 2 个小时才能读取。 磁带遍布各处。 否则，任何一个位置都将没有足够的能力来读取还原过程中涉及的所有磁带。 * 使用压缩和校验和，他们实际上不需要读取 200K 磁带。 * 从那时起，恢复流程已得到很大改善。 * **优先还原** 。 * 可以在保存更重要的数据（例如当前收件箱和发送的电子邮件）之后恢复已存档的数据。 * 一个月内没有被触摸过的帐户可以等待，直到更活跃的用户被首先还原。 * **备用系统被视为巨大的全球生物** 。 * 不想仅在纽约进行 GMail 备份，因为如果该数据中心增长或收缩，则备份需要适当扩展。 * 将备份视为一个巨大的全球跨越系统。 进行备份时，它可能完全位于其他位置。 * 必须在磁带所在的位置进行磁带还原。 但是在制作磁带之前，数据可能在纽约，而备份在俄勒冈州，因为那里有足够的存储空间。 位置隔离是自动处理的，不会告诉客户端其数据备份的位置。 * 容量可以移动。 只要具有全球容量并且网络可以支持它，磁带位于何处都没有关系。 * **您拥有的数据越多，保留它就越重要** 。 * 通常，越大的东西越重要。 Google 过去只是搜索。 现在是 Gmail，存储在驱动器，文档等中的东西。它既更大，也越来越重要。 * **拥有良好的基础架构** 。 * 可以使用通用的瑞士军刀真的很不错。 编写 MapReduce 时，他们可能从未想到过将其用于备份。 但是，如果没有 MapReduce，就不可能出现将其用于备份的想法。 * **缩放比例确实很重要，您无法拥有任何无法扩展的部分-软件，基础架构，硬件，流程-**。 * 您不能说我将在拥有操作人员的情况下部署更多的磁带机。 如果您要雇用两倍的人，您有两倍的停车位吗？ 自助餐厅的房间？ 洗手间？ 一切都必须扩大规模。 您将遇到一个瓶颈，它将阻止您。 * **证明** 。 * 不要将任何事情视为理所当然。 希望不是战略。 * 如果不尝试，将无法使用。 必须进行还原才能验证备份。 直到最后，您还没有证明任何东西。 这种态度发现了很多失败。 * **DRT。 灾难恢复测试** 。 * 每 N 个月就会发布一次灾难场景。 模拟组织各个级别的响应。 * 在灾难不带走任何损失的情况下，公司将如何生存？ 必须学会适应。 * 发现基础结构和物理安全方面的巨大漏洞。 * 想象一下，一个数据中心有一条通向它的道路，并且有卡车在路上装载着备用发电机的燃料。 路迷路了怎么办？ 最好有一条道路和另一家柴油燃料供应商。 * 确实有供应链冗余策略。 * **在不同时间点在不同位置的不同软件堆栈中的冗余** 。 * **不要只让数据在堆栈中迁移** 。 将数据保留在堆栈的不同层中一段特定的驻留时间。 因此，如果您丢失了该数据，则此数据会重叠。 时间，位置和软件。 * 考虑 GMail 中断示例。 如果复制损坏了，怎么也不会丢失数据？ 这是听众提出的问题，他真的不想透露细节。 数据一直在备份。 假设我们有截至 9PM 的数据。 假设损坏发生在晚上 8 点，但尚未录制到磁带上。 腐败被制止了。 软件已回滚到工作版本。 在堆栈中的某个时刻，所有数据仍然存在。 磁带上有东西。 有东西正在复制。 前端有东西。 日志中有东西。 所有这些来源都有重叠之处，有可能重建所有数据。 对于这种情况，政策是直到将数据放入另一个堆栈中 N 个小时后，才从一个卡住的数据中取出数据。 * **删除问题** 。 * 我要删除它。 不会为了删除数据而重写磁带。 大规模而言太昂贵了。 * 一种方法是对加密密钥进行智能处理。 他没有告诉我们 Google 做什么。 也许丢失了有效删除数据的密钥？ * **当您信任同事并分担责任时，一个庞大的组织就可以工作。** 。 * 相信他们了解自己的部分。 * 确保组织和软件接口定义正确。 在各层之间实施验证测试。 * **白名单和黑名单**。 * 确保数据位于保证的位置，并保证不在某个位置，这与其余的哲学原理（即位置多样性和位置独立性）背道而驰。 * 最初不是堆栈的功能。 必须添加以支持政府要求。 * 在堆栈中将责任降低得越低越好。 填写正确的个人资料，它就会神奇地发生。 ## 相关文章 * [在 Reddit 上](http://www.reddit.com/r/programming/comments/1wzsmk/how_google_backs_up_the_internet_along_with/) “如果您想对软件错误进行“保护”，那么？？？ 嘿托德， 这是一个令人难以置信的帖子，其中包含许多有用的信息，非常感谢您将其组合在一起！ 嘿， 我想知道更多有关 Google 备份的内容。 是完整的档案备份，以便保存在 google 中创建的每个文件，还是更多的滚动备份，其中删除了未使用的数据，仅备份了最近的几周。 另外，是 Google 对数据进行重复数据删除，还是每个用户的每个文件等等，都是单独保存的。 呵呵，所以安全是一个问题。 这是我在网上找到的最佳信息之一，谢谢分享