2011年一次存储漏洞清空了Gmail收件箱；只有离线磁带备份将它们恢复

2011年2月27日，Gmail用户开始登录时发现收件箱空空如也。起因是一次例行的存储软件更新带有一个意外漏洞。问题一出现，谷歌就停止了部署并回退到旧版本，但损害已经造成：邮件已从账户中被删除，最初估计涉及Gmail用户群的0.08%——约15万个账户，后来下调至0.02%。

事后复盘中最令人不安的部分是，为什么那些副本没有帮上忙。Gmail在多个数据中心为每个邮箱保留多份副本。但当副本运行相同的软件时，它们并不独立：“在极少数情况下，软件漏洞可能影响数据的多个副本，”谷歌工程副总裁本·特雷诺写道。唯一干净的副本在磁带上——离线，因此不受该漏洞影响。磁带速度慢，这就是为什么恢复花了约30小时而不是毫秒级；其余0.012%受影响的用户在3月1日前从磁带恢复。

谷歌强调“邮件从未丢失”，以数据丢失事件的标准来看，这个故事结局不错。但这一事件戳破了“云复制就意味着安全”的直觉，关于邮件丢失和登录问题的投诉持续到第四天。它至今仍是相关副本故障的标准引用案例：冗余防范的是机器死亡，而不是同一个漏洞在所有地方运行。

初步估计0.08%的用户（约15万个账户，后修正为0.02%）看到空收件箱；磁带恢复耗时约30小时。

存储更新引入了一个可能删除数据的漏洞，部署在缺陷被发现之前就到达了生产系统。

Gmail的多份副本都运行相同的存储软件，因此一个漏洞可能触及跨数据中心的多个副本。

漏洞唯一无法触及的副本是离线磁带——这是谷歌在复制之外保留的恢复路径，正是它拯救了这些邮箱。

从磁带恢复本质上很慢，把一次糟糕的部署拉长成数天的用户可见损害。

副本防范的是硬件故障，而不是软件。一个漏洞可能同时损坏多个副本，因此要在软件的爆炸半径之外保留一条恢复路径——对Gmail来说，就是离线磁带。

谷歌完成了从磁带的恢复，并在官方Gmail博客上发布了一份异常坦率的故障说明。这一事件成为可靠性工程中一个长期论据：至少保留一种恢复介质在生产软件故障域之外——正因如此，磁带进入了云时代的词汇表。Gmail的复制模型本身没有改变；改变的是对多副本系统中相关软件故障的警惕。