Google 视频：Google 如何备份互联网？

Blum 用典型的 Google 式说法解释了为何常规的备份策略对 Google 不起作用：它们在实现容量倍增的同时需要付出倍增的付出（成本和资源）。若备份两倍的数据需要两倍的资源（时间、能源、空间等），那就没什么用，这不叫扩展。当要备份的数据量从 1 艾字节（exabyte）增长到 2 艾字节时，你需要一份不同的工作计划。

下面，根据 Todd Hoff 的整理，对演讲中的相关观点进行详细描述，由于篇幅较大，为简化阅读，笔者对内容做了部分删节，并对若干条目进行了转译。如需要阅读英文原文，可转到这里：

1. 保证 **100%** 的数据可用性，永不丢失数据从统计学角度看，一个 2G 的文件丢失 200K 听起来不错，但是文件却可能已经失效了。所以，数据的可用性远比可访问性重要；Google 通过位置隔离、应用层问题隔离、存储问题隔离、存储介质问题隔离等多种混合手段保证数据的可用性。
2. 冗余不同于可恢复性多份备份不足以保证数据不丢失（软件的错误会导致所有副本都是坏数据）；但是备份在某些情况下是有用的，比如一个数据中心不可用时可用另一个异地的数据中心的备份进行恢复；冗余有益于引用局部性，而当希望使所有的数据引用尽可能是本地访问时，拷贝就很好用。
3. 从整体上看，Google系统非常健壮，因为有太多的备份Google 的东西始终在出错，就像人体内的细胞不断地死亡一样。冗余就是应对之策，通过冗余可得到了比单台高质量机器更可靠的聚集可靠性。
4. 大规模并行系统更容易出错若没有 bug 的情况下，运行在 3 万台机器上的 MapReduce 看起来很棒，但是一旦有 bug，所有机器都等着运行此 bug，其影响就会放大。
5. 本地拷贝不能防止站点失效如果机房被水淹了，RAID 也无力回天；GFS（Google File System）采用 RAID 的概念，通过编码技术一次性将数据写到多个数据中心，你只需要使用 n-1 个备份就可以重构数据。所以，当你有三个数据中心时，其中一个数据中心失效，还可以通过另外两个来进行数据重构。
6. 可用性和数据一致性是整个公司层面的特征Google 工程师、BigTable、GFS、Colossus 都将数据持久性和一致性视为第一要务。
7. 万事皆需多样性若担心本地站点出问题，就把数据存放在多个站点上；若担心用户操作错误，就对用户的交互进行多层隔离；若希望免遭某个软件 bug 的破坏，就换一个软件，把东西存在不同的厂商介质上以减低严重的软件 bug 带来的影响。
8. 通过磁带备份数据的确很好磁带之所以好，因为它不是磁盘。磁盘的驱动程序里可能存在 bug，但磁带不会，它提升了存储多样性。磁带容量遵循摩尔定律，所以乐见人们采用磁带作为备份介质；磁带是加密的，恶意分子很难从其中得到有价值的信息。
9. 相对于备份，更应该关注恢复在人们使用数据之前就要发现问题，恢复是必不可少的；进行连续的恢复尝试，通过一个滑动窗口选择 5% 的备份进行恢复并与先前备份的原始数据进行比对，在问题出现之前就解决它；比对也是自动执行的；
10. 对失败率的变化做出告警如果有些事情不对劲，你应该立刻知晓；预期恢复过程中一定有失败，文件第一次尝试恢复时失败暂不告警；如果第一次尝试恢复时的错误率是 N，而第二次尝试恢复时的错误率为 Y，则意味着某个地方出问题了，因此必须告警（在数据使用之前就能够发现问题）。
11. 万事皆可出错磁盘不断地出错，但是你知道它何时出错，因为它在你的监视之中；而对于磁带，在你使用它之前你并不知道它是否有错。磁带存放的时间久，但你应该在使用它之前对其进行测试。
12. 在磁带上做 ****RAID对 4 个满载磁带通过 XOR 生成第 5 个编码带，这样，任意一个丢失了你都可以从其他四个中进行恢复。磁带时常丢失数据，通过不断地恢复来检测磁带的丢失，通过其兄弟磁带来重新构建该磁带。
13. 备份是为奢侈的恢复所缴的税。这是一个恢复系统而非备份系统；根据需要，允许备份足够复杂并跑的时间很长，但要使恢复尽可能地自动化并快速；因为备份可能很慢，数据源必须把原始数据保存一段时间，可能有几天，直到备份已经完成。为了使恢复足够快速，可以降低备份的介质使用效率，通常读一个磁带需要两小时，这太久了，如果把同样多的内容写到两个磁带里（每个磁带的利用率只有一半），然后并行地去读，时间就只需要一小时。
14. 扩展是个问题但你拥有艾字节的数据时，你还会面临一些现实问题，如果不得不拷贝 10 艾字节，那么为了备份一天的数据你可能要花 10 周的时间；在全球范围内拥有数据中心时，你必须要做出一些选择，比如是否每个中心都有无限的备份容量？是否要根据区域划分来进行备份？带宽能否支持？带宽是否要用于其他用来赚钱的业务？考虑相对成本，做出权衡，并非每个中心都有备份设备，需要权衡网络上的可用容量。
15. 不应让消耗资源与获得容量线性增长不能简单地说需要更多的带宽和磁带。比如，对于 10000 个磁带，需要 10000 个操作员去操作它们。在 Google，虽然磁带的数量增长了一个数量级，但却没有对应的人员增长比例；即便有一定的增长幅度，却远不如线性增长；一个很好的例子是，人们曾预测，当电话机数量增长 30% 时，美国人都要成为电话接线员，因为当时没有料到自动交换机的出现。
16. 一切都要自动化程序安排是自动化的；备份、恢复测试、一致性测试等等，都是自动执行的。一旦检测到坏掉的磁带，后续的处理也是自动的。你看不到它们的运行，你所能看到的是，也许有一天你会关心平均有多少个磁带坏掉了，或者当磁带的出错率变化时发出一个告警。
17. 让人摆脱稳定状态的操作包装并运送驱动器仍需要由人来执行。自动化接口来准备运送标签，获取 RMA 号、检查包装是否正常、接收确认单，如果这些环节出错则需要人来干预。同样，软件库的维护也是自动化的。
18. 自动处理死机每 30 秒就有一台机器死掉，如果一个正在执行 MapReduce 任务的机器死掉，不要告诉我，自动处理并继续执行。找另一台机器，转移工作并重新启动。如果机器的执行中存在依赖关系，则将机器调度成等待状态，如果等待时间太长了才需要人工干预。
19. 恢复的优先级设置归档数据的恢复可放在更重要的数据（如当前收件箱和发件箱）的恢复之后；一个月未登录的账户的用户数据的恢复可放在活跃用户的数据恢复之后。
20. 备份系统被视为巨大的全球组织不要指望只在纽约备份 Gmail；把备份看作一个巨大的全球性系统，一处发生备份，也一定同时在别的地方发生。
21. 需要良好的基础设施MapReduce 的作者在编写它时可能永远也无法想象它现在正在用于备份。但是，若没有 MapReduce，就不会出现将其用于备份的想法。
22. 不断进行验证不要想当然，侥幸不是一种策略；对于每个备份都要通过恢复进行验证。不到最后你都无法证明任何事情有效，这种态度帮助我们发现了许多问题。
23. ** 灾难恢复测试（DRT）** 灾难时有发生，你能做的只能适应。寻找基础设施和物理安全的漏洞；不能只有一条通向数据中心的道路，需要预备多条备选方案；需要对供应链设计冗余方案。
24. 在不同软件栈，不同位置和不同时间点进行冗余不要让只对数据进行迁移，需要在软件栈的各个层上把数据保留一段时间，即便你丢失了这里和那里的数据，你仍然可以在某个地方找到数据。
25. 只有信任你的同伴并扛起责任时，一个巨大组织才能运转起来相信他们理解自己所负责的部分；确保整个公司的软件接口都是良定义的，在不同层之间进行验证测试。