GitHub debería ser lo primero de lo que haga una copia de seguridad

Si pregunta a la mayoría de los equipos de TI o de plataformas cuál es su principal prioridad en materia de copias de seguridad, obtendrá siempre la misma respuesta: el correo electrónico, los recursos compartidos, el software ERP y, por supuesto, la infraestructura (hardware, software y componentes de red). GitHub suele situarse en algún punto intermedio, o bien se descarta con el siguiente argumento: «GitHub se replica a sí mismo, no hay problema.» 

Esa clasificación es un vestigio de una época pasada. GitHub es ahora el sistema de registro más valioso y de mayor velocidad en la mayoría de las organizaciones de ingeniería, y debe ocupar el primer puesto en la lista de prioridades de copias de seguridad, por delante del correo electrónico, los recursos compartidos y la mayoría de las aplicaciones alojadas en la nube. 

Por qué GitHub ha saltado a la cabeza 

Lo que alberga GitHub ha cambiado. Una organización moderna de GitHub alberga el modelo operativo de la empresa: código de aplicaciones, infraestructura como código, pipelines de CI/CD, configuraciones de implementación, manuales de procedimientos, políticas de seguridad, SDK orientados al cliente, indicaciones de IA y, cada vez más, las definiciones de agentes que automatizan el trabajo diario de ingeniería. Perder un repositorio solía significar perder algo de código. Hoy en día, perder un repositorio puede significar perder las especificaciones sobre cómo opera la empresa. 

La velocidad ha aumentado drásticamente. Con Copilot, Cursor y Claude Code en los flujos de trabajo diarios, una organización de 50 ingenieros que en 2023 producía 200 confirmaciones al día ahora produce habitualmente entre 600 y 1.000. Los agentes realizan confirmaciones durante la noche. Los agentes realizan confirmaciones durante el fin de semana. Lo que antes tardaba una semana en crearse, ahora puede crearse en un día, lo que también significa que un solo incidente destructivo puede acabar con más trabajo que nunca. 

Los modos de fallo han empeorado. Las protecciones nativas de GitHub (protección de ramas, replicación, el plazo de 90 días para repositorios eliminados) son reales, pero limitadas. No se recuperan de un «force push» que GitHub considera legítimo porque procede de una cuenta de servicio autenticada. No permiten recuperarse de un agente que reescribe .github/workflows en un bucle que destruye los artefactos de lanzamiento. Tampoco permiten recuperarse de un token de acceso personal comprometido que se utiliza para eliminar 200 ramas a las 3:00 de la madrugada. 

¿Qué copia de seguridad de GitHub tiene que soportar 

Los incidentes destructivos que realmente importan no suelen ser maliciosos. Son de carácter cotidiano, y la era de los agentes los ha hecho más habituales: 

• Un agente de limpieza elimina ramas que parecían obsoletas, pero que no lo eran.&
• Un agente de refactorización realiza un «push» forzado a la rama principal tras una rebase incorrecta. 
• Un script de migración reescribe el historial en una docena de repositorios. 
• Se utiliza un token de agente comprometido para eliminar ramas, etiquetas o versiones antes de que nadie se dé cuenta. 
• Un flujo de trabajo de CI ejecuta un comando git destructivo generado por un agente. 

En todos los casos, el daño parece legítimo para GitHub. Se autenticó. Ha sido autorizado. Las propias protecciones de GitHub no tienen forma de saber que la subida fue errónea. 

Un ejemplo teórico 

Una empresa de tecnología financiera de tamaño medio gestiona 18 repositorios en GitHub, de los que se realiza una copia de seguridad cada noche. Dispone de un agente de programación que ejecuta pruebas y aplica correcciones automatizadas en toda la organización, autenticado con una cuenta de servicio que tiene permisos de administrador en el monorepo principal, ya que los permisos más detallados eran un proyecto previsto para el próximo trimestre. 

El sábado a las 2:00 de la madrugada, el agente detecta un error en su lógica de rebase mientras procesa una solicitud de incorporación de cambios (PR) de gran tamaño. Realiza un «force push» de un historial reescrito a la rama «main», descartando 142 confirmaciones de la semana anterior, incluidas tres correcciones de emergencia que ya se están ejecutando en producción. Nadie lo supervisa. Ninguna regla de protección de ramas bloquea el envío. 

El equipo se da cuenta el lunes por la mañana. La última copia de seguridad válida se realizó el viernes a medianoche. Entre esa instantánea y el incidente, el agente había fusionado 47 PR. Las 47 han desaparecido del control de código fuente. Las correcciones siguen activas en producción, pero la fuente de referencia para ellas ya no existe en ningún repositorio. 

La recuperación lleva tres días. Dos de las correcciones de emergencia no se pueden recompilar correctamente y hay que reescribirlas desde cero. Una copia de seguridad cada hora habría limitado la pérdida a 47 minutos de trabajo. 

Qué debe buscar en una solución de copia de seguridad para GitHub 

Si GitHub sea su prioridad número uno en materia de copias de seguridad, la solución debe cumplir cuatro requisitos: 

Frecuencia de copias de seguridad intensiva. Las herramientas de copia de seguridad utilizan el término RPO (objetivo de punto de recuperación). En lenguaje sencillo, se trata de la cantidad de trabajo que está dispuesto a perder si algo falla, medida en tiempo. Si su copia de seguridad se ejecuta cada noche, su RPO es de 24 horas. Para GitHub en la era de los agentes, la frecuencia nocturna es demasiado lenta. La frecuencia mínima es cada hora. Treinta minutos es un plazo aceptable para los monorepos críticos. Pregunte a cualquier proveedor cuál es su cadencia mínima y si se aplica a todo el repositorio (incluidas las incidencias, las solicitudes de incorporación de cambios y la configuración) o solo al código. 

Cobertura integral. Realizar copias de seguridad solo del código convierte un incidente de cuatro horas en uno de cuatro días. Necesita incidencias, solicitudes de incorporación de cambios, debates, flujos de trabajo de Actions, versiones, objetos LFS, reglas de protección de ramas y ajustes a nivel de organización, como la pertenencia a equipos y las instalaciones de aplicaciones. La pérdida de .github/workflows por sí sola puede suponer la pérdida de la configuración de los agentes de los que depende. 

Inmutabilidad. Un token de administrador comprometido que pueda eliminar un repositorio a menudo también puede eliminar la copia de seguridad, si el sistema de copias de seguridad confía en las mismas credenciales. Las copias aisladas físicamente o con bloqueo de objetos no son opcionales. Marcan la diferencia entre un mal día y una pesadilla en la que haya que reconstruir todo a partir de los portátiles de los desarrolladores. 

Recuperación probada. Restaure un repositorio no crítico de principio a fin al menos una vez al trimestre. Mida cuánto tiempo lleva realmente. Una copia de seguridad de la que nunca ha restaurado nada es una suposición, no un plan. 

El cambio 

La mayoría de las organizaciones realizan copias de seguridad de GitHub partiendo de la premisa de que se trata de un repositorio de código con algunos artefactos secundarios adjuntos. GitHub ya no es eso. Es el sistema operativo de mayor velocidad que utilizan la mayoría de las empresas, y la rapidez con la que acumula valor ha superado la estrategia de copias de seguridad que la mayoría de los equipos han heredado. 

Suba GitHub a lo más alto de la lista de prioridades. Una cadencia de copias de seguridad agresiva, una cobertura completa, la inmutabilidad y una recuperación probada son las características que hacen realidad esa prioridad. Sin ellas, «hacemos copias de seguridad de GitHub» es una casilla que marcar, no un plan.