Um bug de armazenamento de 2011 esvaziou caixas de entrada do Gmail; só backups em fita offline as trouxeram de volta

Em 27 de fevereiro de 2011, usuários do Gmail começaram a entrar em suas contas e encontravam as caixas de entrada vazias. A causa foi uma atualização de rotina do software de armazenamento que carregava um bug inesperado. O Google interrompeu a implantação assim que o problema surgiu e reverteu para a versão antiga, mas o dano já estava feito: mensagens haviam sido apagadas de contas que representavam, numa primeira estimativa, 0,08% da base de usuários do Gmail — cerca de 150.000 contas, número depois revisado para baixo, para 0,02%.

A parte desconfortável do postmortem era por que as cópias não haviam ajudado. O Gmail mantém múltiplas cópias de cada caixa de correio em vários data centers. Mas as réplicas não são independentes quando rodam o mesmo software: "em alguns casos raros, bugs de software podem afetar várias cópias dos dados", escreveu Ben Treynor, vice-presidente de engenharia do Google. As únicas cópias limpas estavam em fita — offline e, portanto, imunes ao bug. Fita é lenta, e por isso a restauração levou cerca de 30 horas em vez de milissegundos; os 0,012% restantes dos usuários afetados foram restaurados a partir de fitas até 1º de março.

O Google enfatizou que "o e-mail nunca foi perdido" e, pelos padrões dos incidentes de perda de dados, a história terminou bem. Mas o episódio furou a intuição de que replicação na nuvem significa segurança, e reclamações sobre mensagens desaparecidas e problemas de login continuaram até o quarto dia. Permanece como a citação padrão para falha de réplicas correlacionadas: a redundância protege contra máquinas que morrem, não contra o mesmo bug rodando em todos os lugares.

A estimativa inicial de 0,08% dos usuários (cerca de 150.000 contas, depois revisada para 0,02%) viu caixas de entrada vazias; a restauração a partir de fita levou cerca de 30 horas.

A atualização de armazenamento introduziu um bug que podia apagar dados, e a implantação chegou aos sistemas em produção antes que o defeito fosse detectado.

As múltiplas cópias do Gmail rodavam todas o mesmo software de armazenamento, então um único bug podia atingir várias réplicas em diferentes data centers.

A única cópia que o bug não conseguia alcançar era a fita offline — um caminho de recuperação que o Google manteve apesar da replicação, e foi isso que salvou as caixas de correio.

A restauração a partir de fita era inerentemente lenta, transformando uma única implantação defeituosa em dias de danos visíveis aos usuários.

Réplicas protegem contra falha de hardware, não de software. Um bug pode corromper várias cópias ao mesmo tempo, então mantenha um caminho de recuperação fora do raio de alcance do seu software — no caso do Gmail, a fita offline.

O Google concluiu a restauração a partir de fita e publicou um relato incomumente franco da falha no Official Gmail Blog. O incidente tornou-se um argumento permanente na engenharia de confiabilidade para manter pelo menos um meio de recuperação fora do domínio de falha do software de produção — a fita entrou no vocabulário da era da nuvem por causa disso. O modelo de replicação do Gmail em si não mudou; o que mudou foi a cautela em relação a falhas de software correlacionadas em sistemas com múltiplas cópias.