Aproximadamente seis horas de datos, incluidos detalles, solicitudes de combinación, usuarios, comentarios y fragmentos, se perderán a medida que GitLab se restaure desde una copia de seguridad.

El sitio de alojamiento de código GitLab tuvo una interrupción en el servicio después de sufrir un "grave" incidente con una de sus bases de datos que ha requerido mantenimiento de emergencia.

La compañía informó que perdió seis horas de datos de base de datos, incluyendo detalles, solicitudes de combinación, usuarios, comentarios y fragmentos de GitLab.com y estaba en el proceso de restauración de datos de una copia de seguridad. Los datos fueron borrados accidentalmente, según un mensaje de Twitter.

"Perder datos de producción es inaceptable, y en pocos días publicaremos los cinco por qué de lo sucedido y una lista de medidas que implementaremos", dijo GitLab en un boletín. Los repositorios de Git.wiki y las instalaciones auto alojadas no fueron afectadas.

La restauración significa que cualquier dato entre 17:20 UTC y 23:25 UTC desde la base de datos se habrá perdido cuando GitLab.com vuelva a funcionar. Proporcionando una cronología de los eventos, GitLab dijo que detectó el lunes que los spammers atacaron su base de datos creando fragmentos, haciéndolo inestable. GitLab bloqueó a los spammers basándose en la dirección IP y eliminó a un usuario de usar un repositorio como la forma de CDN. Esto dio lugar a 47,000 IP firmadas usando la misma cuenta y causando una carga alta de la base de datos, GitLab quitó los usuarios causantes del spam.

"Esta interrupción no afectó a nuestros clientes empresariales o la amplia mayoría de nuestros usuarios. Como parte de nuestros esfuerzos de recuperación en curso, estamos investigando activamente una posible pérdida de datos. Si se confirma, esta pérdida de datos afectaría menos del uno por ciento de nuestra base de usuarios y específicamente los metadatos periféricos que fueron escritos durante una ventana de seis horas ", dijo la compañía. "Hemos estado trabajando las veinticuatro horas para reanudar el servicio del producto afectado y establecer medidas a largo plazo para evitar que esto vuelva a suceder y seguiremos manteniendo nuestra comunidad actualizada a través de Twitter, nuestro blog y otros canales".

Mientras trataban el problema, GitLab encontró que la replicación de la base de datos se quedó muy atrás, deteniéndose eficazmente. "Esto ocurrió porque hubo un pico en las escrituras que no fueron procesadas a tiempo por la base de datos secundaria". GitLab ha estado tratando con una serie de problemas de bases de datos, incluyendo una negativa a replicar.

GitLab.com cayó a las 6:28 pm PST el martes 31 de enero y volvió a las 9:57 am PST del día siguiente, informó Tim Anglade, vicepresidente interino de marketing de la compañía.