Un error de almacenamiento de 2011 vació bandejas de entrada de Gmail; solo las copias de seguridad en cinta offline las recuperaron

El 27 de febrero de 2011, los usuarios de Gmail empezaron a iniciar sesión y descubrieron que sus bandejas de entrada estaban vacías. La causa fue una actualización rutinaria del software de almacenamiento que llevaba un error inesperado. Google detuvo el despliegue en cuanto surgió el problema y volvió a la versión anterior, pero el daño ya estaba hecho: se había borrado correo de cuentas que representaban, según una primera estimación, el 0,08 % de la base de usuarios de Gmail —unos 150.000 cuentas, cifra revisada después a la baja hasta el 0,02 %.

La parte incómoda del análisis posterior era por qué las copias no habían servido de ayuda. Gmail mantiene varias copias de cada buzón en varios centros de datos. Pero las réplicas no son independientes cuando ejecutan el mismo software: «en algunos casos excepcionales, los errores de software pueden afectar a varias copias de los datos», escribió Ben Treynor, vicepresidente de ingeniería de Google. Las únicas copias limpias estaban en cinta —offline y, por tanto, inmunes al error—. La cinta es lenta, y por eso la restauración tardó unas 30 horas en lugar de milisegundos; el 0,012 % restante de los usuarios afectados quedó restaurado desde cintas el 1 de marzo.

Google insistió en que «el correo nunca se perdió» y, para los estándares de los incidentes de pérdida de datos, la historia terminó bien. Pero el episodio desmintió la intuición de que la replicación en la nube significa seguridad, y las quejas por correo faltante y problemas de inicio de sesión continuaron hasta el cuarto día. Sigue siendo la cita de referencia para el fallo de réplicas correlacionadas: la redundancia protege contra la muerte de máquinas, no contra que el mismo error se ejecute en todas partes.

La estimación inicial del 0,08 % de los usuarios (unas 150.000 cuentas, revisada después al 0,02 %) vio sus bandejas de entrada vacías; la restauración desde cinta tardó unas 30 horas.

La actualización de almacenamiento introdujo un error que podía borrar datos, y el despliegue llegó a los sistemas en producción antes de que se detectara el defecto.

Las múltiples copias de Gmail ejecutaban todas el mismo software de almacenamiento, así que un solo error podía afectar a varias réplicas en distintos centros de datos.

La única copia a la que el error no podía llegar era la cinta offline —una vía de recuperación que Google mantuvo a pesar de la replicación, y que es lo que salvó los buzones—.

La restauración desde cinta era intrínsecamente lenta, lo que convirtió un único despliegue defectuoso en días de daño visible para el usuario.

Las réplicas protegen contra fallos de hardware, no de software. Un error puede corromper varias copias a la vez, así que conviene mantener una vía de recuperación fuera del radio de impacto del software —para Gmail, la cinta offline—.

Google completó la restauración desde cinta y publicó en el blog oficial de Gmail un relato inusualmente franco del fallo. El incidente se convirtió en un argumento permanente de la ingeniería de fiabilidad para mantener al menos un medio de recuperación fuera del dominio de fallo del software de producción; por ello la cinta entró en el vocabulario de la era de la nube. El modelo de replicación de Gmail en sí no cambió; lo que cambió fue la cautela ante fallos de software correlacionados en sistemas con múltiples copias.