近日，在视频“How google Backs Up the Internet”中，Raymond Blum介绍了许多值得互联网公司学习的有关备份、恢复方面的技术与思想。Blum的演讲幽默诙谐，信息量巨大，洋洋洒洒地讲了一个多小时，处处闪现智慧的光芒，非常值得一听。

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

感谢Todd Hoff ，他对该视频做了非常详尽的梳理与总结（原文在这里），并归纳出演讲的几大主题：

• 永不丢失数据：即便Gmail的确发生过臭名远播的服务不可用事件，但它却能永不丢失数据，这一点远非单纯地通过许多个磁带备份和跨多个数据中心就可以实现，实际工作要复杂得多。每次读取数据都需要经过技术栈的多个层级，而每一层都要做许多工程工作，包括人力。
• 仅备份是不够的：你更需要的是恢复（restore）而非备份（backup）。备份只是在消费奢侈的恢复时所缴的税。可以使备份足够复杂，以保证恢复变得足够简单。
• 不应让消耗资源与获得容量线性扩展：不能说数据增长100倍，就需要100倍的人力和机器资源。应该寻找力量倍增的方法。自动化是改善利用率和效率的主要方法。
• 万物皆需冗余：Google的东西也不断失效，就像人体内的细胞不断死去一样。Google并不奢望它的东西能够永远不死，相反，Google做好应对计划。
• 万物皆需多样化：若担心站点本地出事，就把数据在多个站点存放；若担心用户操作错误，就对用户的交互进行多层隔离；若希望免遭某个软件bug的破坏，就换一个软件，把东西存在不同的厂商介质上以降低严重的软件bug产生的影响。
• 把人从决策环路中解放出来：一份邮件被Gmail保存了几个备份？诸如此类事情，就不应是人该操心的，它由Gmail和系统通过某些参数进行配置和管理的。设定高层策略，由系统来负责。只有在异常情况下才去打扰人。
• 不断地验证：不断对备份和恢复进行测试，以验证其正确性。不对其进行尝试，它就不可能正确工作。

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

• 保证100%的数据可用性，永不丢失数据

  从统计学角度看，一个2G的文件丢失200K听起来不错，但是文件却可能已经失效了。所以，数据的可用性远比可访问性重要；Google通过位置隔离、应用层问题隔离、存储问题隔离、存储介质问题隔离等多种混合手段保证数据的可用性。

• 冗余不同于可恢复性

  多份备份不足以保证数据不丢失（软件的错误会导致所有副本都是坏数据）；但是备份在某些情况下是有用的，比如一个数据中心不可用时可用另一个异地的数据中心的备份进行恢复；冗余有益于引用局部性，而当希望使所有的数据引用尽可能是本地访问时，拷贝就很好用。

• 从整体上看，Google系统非常健壮，因为有太多的备份

  Google的东西始终在出错，就像人体内的细胞不断地死亡一样。冗余就是应对之策，通过冗余可得到了比单台高质量机器更可靠的聚集可靠性。

• 大规模并行系统更容易出错

  若没有bug的情况下，运行在3万台机器上的MapReduce看起来很棒，但是一旦有bug，所有机器都等着运行此bug，其影响就会放大。

• 本地拷贝不能防止站点失效

  如果机房被水淹了，raid也无力回天；GFS（Google File System）采用RAID的概念，通过编码技术一次性将数据写到多个数据中心，你只需要使用n-1个备份就可以重构数据。所以，当你有三个数据中心时， 其中一个数据中心失效，还可以通过另外两个来进行数据重构。

• 可用性和数据一致性是整个公司层面的特征

  Google工程师、BigTable、GFS、Colossus都将数据持久性和一致性视为第一要务。

• 万事皆需多样性

  若担心本地站点出问题，就把数据存放在多个站点上；若担心用户操作错误，就对用户的交互进行多层隔离；若希望免遭某个软件bug的破坏，就换一个软件，把东西存在不同的厂商介质上以减低严重的软件bug带来的影响。

• 通过磁带备份数据的确很好

  磁带之所以好，因为它不是磁盘。磁盘的驱动程序里可能存在bug，但磁带不会，它提升了存储多样性。磁带容量遵循摩尔定律，所以乐见人们采用磁带作为备份介质；磁带是加密的，恶意分子很难从其中得到有价值的信息。

• 相对于备份，更应该关注恢复

  在人们使用数据之前就要发现问题，恢复是必不可少的；进行连续的恢复尝试，通过一个滑动窗口选择 5%的备份进行恢复并与先前备份的原始数据进行比对，在问题出现之前就解决它；比对也是自动执行的；

• 对失败率的变化做出告警

  如果有些事情不对劲，你应该立刻知晓；预期恢复过程中一定有失败，文件第一次尝试恢复时失败暂不告警；如果第一次尝试恢复时的错误率是N，而第二次尝试恢复时的错误率为Y，则意味着某个地方出问题了，因此必须告警（在数据使用之前就能够发现问题）。

• 万事皆可出错

  磁盘不断地出错，但是你知道它何时出错，因为它在你的监视之中；而对于磁带，在你使用它之前你并不知道它是否有错。磁带存放的时间久，但你应该在使用它之前对其进行测试。

• 在磁带上做RAID

  对4个满载磁带通过XOR生成第5个编码带，这样，任意一个丢失了你都可以从其他四个中进行恢复。磁带时常丢失数据，通过不断地恢复来检测磁带的丢失，通过其兄弟磁带来重新构建该磁带。

• 备份是为奢侈的恢复所缴的税。

  这是一个恢复系统而非备份系统；根据需要，允许备份足够复杂并跑的时间很长，但要使恢复尽可能地自动化并快速；因为备份可能很慢，数据源必 须把原始数据保存一段时间，可能有几天，直到备份已经完成。为了使恢复足够快速，可以降低备份的介质使用效率，通常读一个磁带需要两小时，这太久了，如果 把同样多的内容写到两个磁带里（每个磁带的利用率只有一半），然后并行地去读，时间就只需要一小时。

• 扩展是个问题

  但你拥有艾字节的数据时，你还会面临一些现实问题，如果不得不拷贝10艾字节，那么为了备份一天的数据你可能要花10周的时间；在全球范围 内拥有数据中心时，你必须要做出一些选择，比如是否每个中心都有无限的备份容量？是否要根据区域划分来进行备份？带宽能否支持？带宽是否要用于其他用来赚 钱的业务？考虑相对成本，做出权衡，并非每个中心都有备份设备，需要权衡网络上的可用容量。

• 不应让消耗资源与获得容量线性增长

  不能简单地说需要更多的带宽和磁带。比如，对于10000个磁带，需要10000个操作员去操作它们。在Google，虽然磁带的数量增长 了一个数量级，但却没有对应的人员增长比例；即便有一定的增长幅度，却远不如线性增长；一个很好的例子是，人们曾预测，当电话机数量增长30%时，美国人 都要成为电话接线员，因为当时没有料到自动交换机的出现。

• 一切都要自动化

  程序安排是自动化的；备份、恢复测试、一致性测试等等，都是自动执行的。一旦检测到坏掉的磁带，后续的处理也是自动的。你看不到它们的运行，你所能看到的是，也许有一天你会关心平均有多少个磁带坏掉了，或者当磁带的出错率变化时发出一个告警。

• 让人摆脱稳定状态的操作

  包装并运送驱动器仍需要由人来执行。自动化接口来准备运送标签，获取RMA号、检查包装是否正常、接收确认单，如果这些环节出错则需要人来干预。同样，软件库的维护也是自动化的。

• 自动处理死机

  每30秒就有一台机器死掉，如果一个正在执行MapReduce任务的机器死掉，不要告诉我，自动处理并继续执行。找另一台机器，转移工作并重新启动。如果机器的执行中存在依赖关系，则将机器调度成等待状态，如果等待时间太长了才需要人工干预。

• 恢复的优先级设置

  归档数据的恢复可放在更重要的数据（如当前收件箱和发件箱）的恢复之后；一个月未登录的账户的用户数据的恢复可放在活跃用户的数据恢复之后。

• 备份系统被视为巨大的全球组织

  不要指望只在纽约备份Gmail；把备份看作一个巨大的全球性系统，一处发生备份，也一定同时在别的地方发生。

• 需要良好的基础设施

  MapReduce的作者在编写它时可能永远也无法想象它现在正在用于备份。但是，若没有MapReduce，就不会出现将其用于备份的想法。

• 不断进行验证

  不要想当然，侥幸不是一种策略；对于每个备份都要通过恢复进行验证。不到最后你都无法证明任何事情有效，这种态度帮助我们发现了许多问题。

• 灾难恢复测试（DRT）

  灾难时有发生，你能做的只能适应。寻找基础设施和物理安全的漏洞；不能只有一条通向数据中心的道路，需要预备多条备选方案；需要对供应链设计冗余方案。

• 在不同软件栈，不同位置和不同时间点进行冗余

  不要让只对数据进行迁移，需要在软件栈的各个层上把数据保留一段时间，即便你丢失了这里和那里的数据，你仍然可以在某个地方找到数据。

• 只有信任你的同伴并扛起责任时，一个巨大组织才能运转起来

  相信他们理解自己所负责的部分；确保整个公司的软件接口都是良定义的，在不同层之间进行验证测试。