Cinco técnicas de respaldo y ninguna confiable: la noche en que GitLab borró su base de datos

Tener respaldos no es lo mismo que poder restaurar. La diferencia solo se ve el día que hace falta, y ese día ya es tarde para descubrirla. En enero de 2017, un servicio en la nube para alojar código lo descubrió en vivo, con miles de personas mirando.

Una aclaración antes de empezar: Hábil no participó en este caso. Lo contamos con lo que GitLab publicó en su postmortem público y con lo que reportó la prensa especializada.

Martes, pasadas las once de la noche

Es el 31 de enero de 2017. GitLab.com, el servicio en la nube donde equipos de software guardan su código, sus pendientes y sus revisiones, lleva horas con problemas. Desde la tarde, la base de datos principal está bajo una carga anormal. El equipo sospecha de spam. Los usuarios no pueden publicar comentarios [1][2].

Detrás de esa carga hay una coincidencia que nadie había previsto. Además del spam, un proceso para borrar los datos de un empleado de la propia empresa se programó por error, disparado por un reporte de abuso [1]. Las dos cosas juntas aprietan a la base.

Hacia las once de la noche (hora UTC), la presión deja una consecuencia más seria. La base principal tiene una réplica: una segunda copia que se mantiene al día recibiendo cada cambio, lista para tomar el lugar de la primera si esta falla. Con la carga, la réplica se queda atrás. Y cuando intenta ponerse al día, los cambios que necesitaba ya no están: la base principal los descartó antes de que la réplica los recibiera [1].

No hay forma automática de salir de ahí. La réplica hay que reconstruirla a mano [1].

Un ingeniero se pone a ello. Borra el directorio de datos de la réplica para copiarlo de nuevo desde la principal. Lanza la herramienta que hace esa copia y la herramienta no responde. Parece colgada. Ajusta parámetros. La base se niega a reiniciar. Ajusta otros [1].

Lo que nadie en ese momento sabe es que la herramienta no estaba colgada: estaba esperando en silencio a que la base principal empezara a enviar datos, algo que puede tardar varios minutos. Ese comportamiento no estaba en los procedimientos del equipo ni en la documentación oficial [1][2].

Es de noche en Países Bajos, donde trabaja el ingeniero [4]. El problema lleva horas. Cree que la copia fallida dejó basura en el directorio de la réplica y decide limpiarlo otra vez.

Escribe el comando de borrado. Lo ejecuta.

Uno o dos segundos después se da cuenta: no está en la réplica. Está en la base principal [1][2].

Lo detiene. Pero el comando de borrado no pregunta y no se puede deshacer. De unos 300 GB de datos, quedan unos 4.5 GB [2][4].

La búsqueda

En ese momento, la pregunta de todos es la misma: ¿de dónde restauramos?

GitLab no era una empresa improvisada. Tenía, en papel, varias capas de protección. El equipo empieza a revisarlas una por una, y las anota en un documento de Google que hace público para que cualquiera siga el avance [1][3].

El respaldo diario a la nube. Cada 24 horas, una tarea programada debía sacar un volcado completo de la base y guardarlo en un almacenamiento de Amazon (S3). El equipo abre el almacenamiento. Está vacío [1][2][4].

¿Por qué? La tarea corría la herramienta de volcado en su versión 9.2 contra una base en versión 9.6. La herramienta elegía su versión según el directorio de datos del servidor donde corría, y esa tarea corría en un servidor de aplicación, que no tenía directorio de datos. Así que tomaba la versión vieja y fallaba [1].

Fallaba todos los días. ¿Y nadie se enteraba? La tarea sí mandaba un correo cuando fallaba. Pero esos correos se rechazaban: el servidor que los recibía los devolvía porque los correos de las tareas programadas no tenían activado DMARC, un mecanismo que los servidores de correo usan para verificar que un mensaje es legítimo [1][5]. La alarma existía. Nunca llegó a nadie.

Las instantáneas de disco de la nube. GitLab corría entonces sobre Microsoft Azure, que puede tomar fotos periódicas de un disco completo. Estaban activadas para los servidores de archivos, pero no para los de base de datos: el equipo supuso que los otros respaldos bastaban [1].

La réplica. Es lo primero que cualquiera pensaría. Pero una réplica no es un respaldo: copia todo, incluidos los errores, y sirve para tomar el relevo de un servidor caído, no para regresar en el tiempo. Además, en este caso ya no existía: su directorio se había borrado minutos antes, como parte de la reconstrucción [1].

Las instantáneas del servidor. Quedaba una última capa: fotos del disco tomadas con LVM, el gestor de volúmenes lógicos del sistema. Se sacaban cada 24 horas, y no como respaldo, sino para copiar los datos reales a un ambiente de pruebas (staging). La más reciente programada tenía casi un día [1].

Esa madrugada, el documento público, que contaba por separado los volcados diarios y su copia en S3, resumió la situación en una frase que recorrió internet:

«De cinco técnicas de respaldo y replicación desplegadas, ninguna funciona de forma confiable, o ni siquiera estaba configurada.» [2][4]

Seis horas de suerte

Y entonces aparece la única buena noticia de la noche, y es casi un accidente.

Ese mismo día, hacia las 17:20 UTC, un ingeniero había tomado a mano una instantánea de la base para cargarla en el ambiente de pruebas. La tomó para tener datos recientes en las pruebas de una herramienta para repartir la carga de la base de datos [1]. Esa copia, hecha para otra cosa, era ahora la única con seis horas de antigüedad, no de veinticuatro.

El equipo elige esa copia. La alternativa era perder casi un día completo [1].

Falta llevarla de vuelta. Y ahí aparece otra decisión que alguien tomó tiempo atrás por buenas razones. El ambiente de pruebas corría en discos económicos de Azure, sin almacenamiento de alto desempeño, para ahorrar costos. Esos discos estaban limitados a unos 60 Mbps. Copiar los datos del ambiente de pruebas al servidor principal tomó alrededor de 18 horas. El cuello de botella no era la red ni el procesador: eran los discos [1].

Dieciocho horas de copia, con GitLab.com fuera de servicio.

La recuperación, en vivo

Lo que GitLab hizo durante esas horas es la otra mitad de esta historia, y es la que la distingue.

En lugar de cerrar la puerta y publicar un comunicado escueto al final, informó en público lo que ocurría mientras se recuperaba. Su cuenta de estado en Twitter lo dijo sin rodeos: «Borramos por accidente datos de producción y quizá tengamos que restaurar desde un respaldo» [1][2]. El documento de trabajo, con las notas del equipo y la lista de lo que había fallado, quedó a la vista de todos [1][3]. Y la recuperación se transmitió en YouTube. Llegó a tener unos 5,000 espectadores al mismo tiempo y fue, durante varias horas, la segunda transmisión en vivo más vista de la plataforma [1].

El 1 de febrero, hacia las 17:00 UTC, la base estaba restaurada, todavía sin los webhooks (los avisos automáticos que GitLab manda a otros sistemas cuando algo cambia). Hacia las seis de la tarde, el servicio estaba de vuelta, con los últimos pasos terminados [1][2]. En total, GitLab.com estuvo caído alrededor de 18 horas [1].

El equipo cuidó detalles que solo se ven cuando alguien ya pasó por aquí. Recuperó los webhooks levantando una base aparte desde la misma instantánea, sin el paso que los borra al copiar los datos a pruebas, y de ahí los pasó a la base principal. Adelantó en 100,000 todos los contadores de identificadores de la base, para que ningún número usado en las horas perdidas se volviera a asignar a otra cosa. Y como el código de los repositorios no vive en la base de datos sino aparte, en servidores de archivos que no se borraron, rehízo desde ahí, en su forma básica, los proyectos creados después de las 17:20, aunque sin sus pendientes ni sus revisiones [1].

Cuánto se perdió

Se perdieron los cambios hechos en la base durante unas seis horas: entre las 17:20 UTC y la medianoche del 31 de enero, según el postmortem, que en otro punto ubica el final hacia las 23:30 [1][2]. Su mejor estimación: cerca de 5,000 proyectos, 5,000 comentarios y 700 cuentas de usuario nuevas afectados [1].

Lo que no se perdió también importa. El código y las wikis guardados en GitLab.com estuvieron fuera de servicio durante la caída, pero no se perdieron. Las empresas que tenían GitLab instalado en sus propios servidores no se vieron afectadas [1][2][4].

Diez días después, el 10 de febrero, GitLab publicó un postmortem completo: la cronología hora por hora, cada mecanismo que falló y por qué, y una lista pública de tareas para corregirlo, cada una con su número de seguimiento [1]. Empezaba con una disculpa directa: «A los usuarios de GitLab.com cuyos datos perdimos y a las personas afectadas por la caída: lo sentimos» [1].

Qué enseña este caso

Es fácil leer esta historia como la de un ingeniero que se equivocó de ventana. Sería la lectura equivocada. El propio postmortem de GitLab no se queda ahí: pregunta por qué una sola equivocación pudo costar tanto, y la respuesta tiene poco que ver con esa persona.

1. Un respaldo que nadie ha restaurado es una suposición

GitLab tenía tareas de respaldo, almacenamiento en la nube, instantáneas y una réplica. En un diagrama de arquitectura, eso se ve sólido. Lo que no tenía era la prueba de que alguno de esos mecanismos devolvía una base funcionando.

El postmortem lo dice en una sola línea, sin adornos: «Como no había un dueño, nadie era responsable de probar este procedimiento» [1].

Note lo que eso significa para una dirección. Nadie apagó los respaldos. Nadie decidió correr riesgos. El respaldo diario falló en silencio por una diferencia de versión que nadie veía, y avisó por un canal que nadie recibía. La única forma de descubrirlo antes era intentar restaurar. Y como esa tarea no era de nadie, nadie la hizo.

2. Una réplica protege contra la caída, no contra el error

Este punto confunde incluso a equipos con experiencia. Una réplica está pensada para que el servicio siga si un servidor se cae. Según cómo esté configurada, puede ir con retraso, como la de GitLab esa noche. Y si alguien borra datos, o una aplicación escribe basura, la réplica copia el borrado y la basura con la misma diligencia. Para regresar a un momento anterior hace falta otra cosa: un respaldo que guarde la historia, o un registro de cambios que permita reconstruir la base hasta un minuto dado.

El postmortem lo separa con claridad: la réplica era para relevar al servidor, no para recuperarse de un desastre [1].

3. Lo que se hace a mano, a deshoras, no tiene red de seguridad

La reconstrucción de la réplica no estaba automatizada ni bien documentada. GitLab lo reconoce: el procedimiento era manual, se apoyaba en guiones improvisados y la documentación era escasa [1][2]. Un ingeniero a mitad de la noche, tras horas de incidente, tenía que recordar cada paso, distinguir dos servidores con nombres casi iguales (db1 y db2) y adivinar si una herramienta silenciosa estaba colgada o trabajando.

En esas condiciones, el riesgo de equivocarse crece mucho. La primera tarea de la lista de GitLab fue, de hecho, hacer más evidente en qué servidor y en qué ambiente está cada quien al escribir un comando [1].

4. Las decisiones de ahorro se cobran el día del desastre

Las instantáneas de Azure no estaban activas para las bases porque se pensó que los demás respaldos bastaban. El ambiente de pruebas tenía discos lentos porque así costaba menos [1]. Cada decisión era razonable por separado. Juntas, y sumadas a la réplica perdida, al respaldo diario que fallaba y a las alertas rechazadas, contribuyeron a que un error de dos segundos terminara en una recuperación de unas 18 horas.

No hay nada malo en ahorrar. Lo que falta, casi siempre, es que alguien escriba la consecuencia junto a la decisión: «con estos discos, restaurar toma tantas horas; ¿lo aceptamos?». Si esa pregunta se hace antes, se decide. Si se descubre el día del desastre, solo se padece.

5. Lo que GitLab hizo bien también es parte de la lección

Sería injusto contar esta historia sin decirlo con todas sus letras: GitLab manejó la crisis con una transparencia que pocas empresas se atreven a tener. Informó en público durante la recuperación, abrió sus notas de trabajo, transmitió la recuperación, se disculpó sin rodeos y publicó un análisis que nombra cada falla propia [1].

Y aprendió de su propia transparencia. El documento público llegó a mostrar el nombre del ingeniero involucrado; en el postmortem, GitLab anunció que en el futuro omitiría los nombres, porque otros ingenieros podrían no sentirse cómodos con que se publicaran [1]. El análisis apunta a los procesos, no a la persona.

Esa actitud no es solo buena imagen. Una empresa que puede decir en público «esto falló y por esto» es una empresa que puede corregirlo. La transparencia no elimina el riesgo, pero permite examinar las fallas y asignar mejoras concretas.

Qué planearon y qué ya habían cambiado

El postmortem publicó una lista de tareas abiertas, cada una con su número público. Entre ellas [1]:

• Hacer evidente en la línea de comandos en qué servidor y en qué ambiente se está trabajando.
• Monitorear los respaldos, para que un respaldo que falla no pase inadvertido.
• Tomar instantáneas de la base cada hora en lugar de cada día, y activar las instantáneas de disco para las bases.
• Investigar la recuperación a un punto en el tiempo y el archivado continuo de los cambios de la base.
• Probar de forma automatizada que los respaldos se pueden restaurar.
• Mejorar la documentación y los procedimientos de la replicación.
• Nombrar un dueño de la durabilidad de los datos (quien responde de que se conserven íntegros y se puedan recuperar).
• Preparar la recuperación ante desastres también para todo lo que no es la base de datos.
• Que borrar a un usuario por spam no lo elimine de forma definitiva.

Al publicar el postmortem, GitLab ya tomaba las instantáneas LVM cada hora y había empezado a construir un tablero público del estado de los respaldos; las instantáneas de disco de Azure para las bases seguían en evaluación [1]. Según InfoQ, en las dos semanas siguientes al incidente GitLab empezó a archivar en tiempo real los cambios de la base en un almacenamiento de Amazon, y una restauración de prueba a un punto en el tiempo tardó poco menos de dos horas [5]. Meses después, el equipo organizaba jornadas dedicadas a restaurar sus respaldos —la base principal, otras bases y una instantánea de disco— para comprobar que de verdad respaldaban [6][7]. En junio de 2017 esas restauraciones todavía eran manuales y la automatización estaba en la lista de pendientes [6]. Cambiar una costumbre lleva tiempo, incluso después de un susto así.

El postmortem resume el espíritu del cambio en una frase que vale para cualquier operación: «Un ambiente ideal es uno en el que se pueden cometer errores, pero recuperarse de ellos con facilidad y rapidez, con un impacto mínimo o nulo» [1]. No se trata de prohibir comandos. Se trata de que equivocarse no cueste 18 horas.

Lo que esto significa para su empresa

Usted probablemente no opera una plataforma global como GitLab.com. Pero el patrón de esta historia aparece en empresas de cualquier tamaño, y casi siempre con los mismos ingredientes:

• Infraestructura armada a mano. Servidores, redes y tareas programadas que alguien configuró una vez, que funcionan y que nadie se atreve a tocar. Nadie sabe con certeza qué tienen, porque no está escrito en ningún lado.
• Respaldos que se programan, pero no se restauran. Hay una tarea que «hace el respaldo» y un reporte que dice que corrió. Nadie ha intentado levantar una base completa desde ese archivo.
• Alertas que no llegan a nadie. Correos a buzones que no se leen, o que se rechazan, como en GitLab.
• Procedimientos que viven en la memoria de una persona. Funcionan mientras esa persona está, descansada y disponible.
• Ahorros sin la consecuencia escrita. Discos más lentos, copias menos frecuentes, menos ambientes, todo sin que nadie haya calculado cuánto tardaría la recuperación con esas decisiones.

La diferencia entre una noche como la de GitLab y un susto de una hora no está en tener más herramientas. Está en tres prácticas que se pueden revisar:

La infraestructura escrita como código. Cuando cada servidor, red, permiso y tarea programada está descrito en archivos que se guardan y se revisan como cualquier cambio de software, las configuraciones quedan visibles y revisables. Si una tarea de respaldo corre en el servidor equivocado, como la de GitLab, el error puede verse en una revisión, en lugar de quedar escondido en una máquina. Y si se acompaña de revisión y pruebas, esa descripción facilita reconstruir lo que se pierda de forma consistente.

La evidencia de cada cambio. Quién cambió qué, cuándo y por qué, registrado sin depender de la memoria de nadie. Cuando algo se rompe, esa historia es lo primero que se consulta.

Las restauraciones ensayadas. Un respaldo vale lo que vale su última restauración exitosa. Se ensaya con calendario, se mide cuánto tarda y se compara contra lo que el negocio aceptó perder y esperar. Si nadie ha restaurado en meses, lo que usted tiene no es un respaldo comprobado: es una suposición.

Cinco preguntas para su próximo comité

1. ¿Cuándo fue la última vez que restauramos una base completa desde un respaldo, en un ambiente aparte, y funcionó? Si la respuesta es «nunca» o «no sé», ahí está su primer riesgo.
2. ¿Cuánto tardaría esa restauración, medido y no estimado, y cuántas horas de datos perderíamos?
3. ¿Quién es el dueño de que los respaldos funcionen? Un nombre, no un área.
4. Si mañana falla la tarea de respaldo, ¿quién se entera y cómo? ¿Esa alerta ya se probó?
5. ¿Podríamos volver a levantar nuestra infraestructura igual si perdiéramos el servidor, o depende de lo que recuerde una persona?

Si dos o más respuestas son «no sé», sus respaldos no están comprobados.

Por dónde empezar esta semana

No hace falta un proyecto para dar el primer paso. Elija su base de datos más importante y pida a su equipo una sola cosa: restaurar el respaldo más reciente en un ambiente aparte, medir cuánto tarda y comprobar que la aplicación funciona encima. Anote el resultado, la fecha y quién lo hizo. Si funciona, ya tiene su primera evidencia. Si no funciona, acaba de descubrir en un martes tranquilo lo que GitLab descubrió a medianoche.

Preguntas frecuentes

¿Una réplica de la base de datos cuenta como respaldo?

No necesariamente. Una réplica puede ayudar a mantener el servicio si un servidor se cae, pero también copia los borrados y los errores. Para regresar a un momento anterior hace falta un respaldo que guarde la historia o un mecanismo de recuperación a un punto en el tiempo.

¿Cada cuánto conviene ensayar una restauración?

Depende de cuánto cambian sus datos y de lo que su negocio puede tolerar. Lo importante es que tenga fecha en el calendario y un dueño, y que se repita también después de cambios grandes, como una actualización de versión de la base. En GitLab, una diferencia de versión fue justo la que rompió el respaldo diario [1].

¿Qué es «infraestructura como código» y por qué ayuda con los respaldos?

Es describir servidores, redes, permisos y tareas programadas en archivos que se guardan y se revisan como cualquier software, en lugar de configurarlos a mano. Ayuda porque lo que está escrito se puede revisar, comparar y volver a levantar igual. Los datos no viajan en ese código: viajan con sus respaldos, que se ensayan aparte.

¿Más copias de respaldo nos habrían protegido?

No necesariamente. GitLab tenía varias capas y ninguna funcionaba de forma confiable esa noche; la base se salvó con una copia hecha a mano para otra cosa [1][2]. Los ensayos regulares de restauración habrían ayudado a detectar antes que algunas capas no eran recuperables y que las alertas no llegaban a nadie.

¿Qué pasó con el ingeniero?

El postmortem no lo culpa. Analiza por qué un error humano, que en algún momento iba a ocurrir, pudo tener ese costo, y anuncia que en incidentes futuros omitirá los nombres de las personas involucradas [1].

¿Cuánto tiempo de datos perdió GitLab?

Unas seis horas de cambios en la base de datos, según el propio postmortem. El código y las wikis no se perdieron [1].

Qué hace Hábil

Hábil es una consultora mexicana de ingeniería, fundada en 2006. En Aprovisionamiento de infraestructura diseñamos con usted la base sobre la que corren sus sistemas, la montamos y se la entregamos funcionando, documentada y escrita como código, en su nube, en su centro de datos o en los dos. Incluye, cuando su caso lo pide, respaldos que se restauran y un plan de recuperación con tiempos acordados y probados. Su equipo recibe el código y la documentación para operarla, y para volver a levantarla igual, sin depender de nosotros. Vea la página Aprovisionamiento de infraestructura.

La primera conversación es sin costo: parte de qué tiene montado hoy, cómo se respalda y cuándo fue la última vez que alguien lo restauró. Escríbanos por WhatsApp.

Los hechos, horas y cifras son los que publicaron GitLab y la prensa citada; no son mediciones propias. Las citas están traducidas del inglés. Horas en UTC, como las publica GitLab. Fuentes consultadas el 20 de octubre de 2026.