GitLab: varias capas de copia y casi ninguna funcionó
El 31 de enero de 2017, un ingeniero borró por error la base de datos principal de GitLab.com. Había copias configuradas por varias vías. Casi ninguna sirvió, porque nadie había comprobado que funcionaran.
Qué pasó
Durante un pico de carga por spam, el equipo de GitLab intentaba reparar la réplica de su base de datos. Un ingeniero ejecutó un borrado pensando que estaba en el servidor secundario. Estaba en el principal. En segundos desaparecieron unos 300 GB de datos.
No fue un ataque ni un desastre natural. Fue un error humano, el escenario más común de todos.
Las copias que fallaron
El informe que GitLab publicó después enumera sus mecanismos de protección y por qué ninguno respondió como se esperaba:
- Copias diarias de la base de datos. La herramienta de copia era de una versión distinta a la de la base de datos y fallaba. El almacenamiento de destino estaba vacío.
- Alertas que nadie recibió. Los avisos de fallo se enviaban por correo, y el servidor receptor los rechazaba. Nadie supo que las copias fallaban.
- Instantáneas de disco en la nube. Estaban activadas para otros servidores, pero no para los de la base de datos.
- Replicación. Servía para conmutar en caso de avería, no como copia. Y la réplica se había borrado durante la reparación.
- Una instantánea de hacía unas 6 horas. Se había creado para copiar datos a un entorno de pruebas, no como copia de seguridad. Fue lo que les salvó.
Cómo se recuperaron
El equipo restauró desde esa instantánea de unas 6 horas antes. El problema fue la velocidad: estaba en discos lentos del entorno de pruebas, limitados a unos 60 Mbps, y copiar los datos llevó cerca de 18 horas. El servicio volvió al día siguiente.
Lo que se perdió
Se perdieron los cambios de unas 6 horas: unos 5.000 proyectos, 5.000 comentarios y alrededor de 700 cuentas de usuario. Los repositorios de código, guardados aparte, no se vieron afectados.
Lecciones para tu empresa
- Una copia que no has restaurado no es una copia. Programa pruebas de restauración periódicas y completas.
- Vigila activamente las copias. No basta con esperar un correo de error: la ausencia de avisos también es una señal.
- Nombra a un responsable. En GitLab nadie tenía asignado comprobar las copias, así que nadie lo hacía.
- Mide cuánto tardas en restaurar. El RTO sobre el papel no sirve si los datos viajan a 60 Mbps.
- Diseña para el error humano. Las personas se equivocan. La infraestructura tiene que permitir recuperarse rápido.