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

Pregunte a la mayoría de los equipos de TI o de plataforma cuál es su principal prioridad de copia de seguridad y escuchará la misma lista: correo electrónico, archivos compartidos, software ERP e infraestructura (hardware, software y componentes de red), por supuesto. GitHub normalmente se sitúa en algún lugar en el medio, o se le hace caso omiso con lo siguiente: "GitHub se replica a sí mismo, estamos bien".

Esa clasificación es un remanente de una época diferente. 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 encabezar la lista de prioridades de copia de seguridad, por delante del correo electrónico, los archivos compartidos y la mayoría de las aplicaciones alojadas en la nube.

Por qué GitHub ha saltado a la cima

Lo que vive en GitHub ha cambiado. Un org moderno de GitHub contiene el proyecto operativo de la empresa: código de aplicación, infraestructura como código, canalizaciones de CI/CD, configuraciones de despliegue, libros de ejecución, políticas de seguridad, SDK orientados al cliente, indicaciones de IA y, cada vez más, las definiciones de agentes que automatizan la ingeniería del día a día. Perder un repositorio solía significar perder algo de código. Hoy en día, perder un repositorio puede significar perder la especificación de cómo funciona la empresa.

La velocidad aumentó drásticamente. Con Copilot, Cursor y Claude Code en los flujos de trabajo diarios, una org de 50 ingenieros que producía 200 commits al día en 2023 ahora produce rutinariamente entre 600 y 1.000. Los agentes realizan commits durante la noche. Los agentes se comprometen 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 empeoraron. Las protecciones nativas de GitHub (protección de rama, replicación, la ventana de 90 días de repos borrados) son reales, pero estrechas. No se recuperan de un push forzado que GitHub considera legítimo porque proviene de una cuenta de servicio autenticada. No se recuperan de un agente que reescribe .github/workflows en un bucle que destruye los artefactos de liberación. No se recuperan de un token de acceso personal comprometido que se utiliza para eliminar 200 ramas a las 3:00 a.m.

Lo que una copia de seguridad de GitHub realmente tiene que sobrevivir

Los eventos destructivos que importan no son en su mayoría maliciosos. Son mundanos, y la era de los agentes los hizo más comunes:

• Un agente de limpieza borra ramas que parecían obsoletas pero no lo eran.
• Un agente de refactorización fuerza el empuje a main tras un rebase erróneo.
• Un script de migración reescribe el historial en una docena de repos.
• Un token de agente comprometido se utiliza para borrar ramas, etiquetas o versiones antes de que nadie se dé cuenta.
• Un flujo de trabajo CI ejecuta un comando git destructivo que ha generado un agente.

En todos los casos, el daño parece legítimo para GitHub. Fue autenticado. Fue autorizado. Las propias protecciones de GitHub no tienen forma de saber que el push fue erróneo.

Un ejemplo teórico

Una mediana empresa de tecnología financiera ejecuta 18 repos en GitHub, con copias de seguridad nocturnas. Tienen un agente de codificación que ejecuta pruebas y aplica correcciones automatizadas en toda la org, autenticado con una cuenta de servicio que tiene alcance de administrador en el monorepo principal, porque los permisos de grano fino eran un proyecto de futuro trimestre.

El sábado a las 2:00 a.m., el agente encuentra un error en su lógica de rebase mientras procesa un PR grande. Fuerza el envío de un historial reescrito a main, descartando 142 commits de la semana anterior, incluidos tres hotfixes de producción que ya se están ejecutando en prod. Ningún humano está observando. Ninguna regla de protección de rama bloquea el push.

El equipo se entera el lunes por la mañana. La última copia de seguridad buena se ejecutó el viernes a medianoche. Entre esa instantánea y el incidente, el agente había fusionado 47 PR. Los 47 han desaparecido del control de fuentes. Los hotfixes siguen vivos en producción, pero la fuente de verdad para ellos ya no existe en ningún repo.

La recuperación lleva tres días. Dos de los hotfixes no pueden reconstruirse limpiamente y se reescriben desde cero. Una copia de seguridad cada hora habría limitado la pérdida a 47 minutos de trabajo.

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

Si GitHub es su prioridad número 1 en copias de seguridad, la solución necesita cuatro cosas:

Cadencia de copia de seguridad agresiva. Las herramientas de copia de seguridad utilizan el término RPO (objetivo de punto de recuperación). En lenguaje llano, es cuánto trabajo está dispuesto a perder si algo se rompe, medido 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, cada noche es demasiado lento. Cada hora es el suelo. Treinta minutos es defendible para monorepos críticos. Pregunte a cualquier proveedor cuál es su cadencia mínima, y si se aplica a todo el repositorio (incluidas incidencias, PR y configuraciones) o sólo al código.

Cobertura de toda la superficie. Hacer una copia de seguridad sólo del código convierte un incidente de cuatro horas en uno de cuatro días. Necesita ediciones, PRs, discusiones, flujos de trabajo de acciones, lanzamientos, objetos LFS, reglas de protección de ramas y configuraciones a nivel org como la pertenencia a equipos y las instalaciones de aplicaciones. Perder .github/workflows por sí solo puede significar perder la configuración de los agentes de los que depende.

Imputabilidad. Un token de administrador comprometido que puede borrar un repo a menudo puede borrar también la copia de seguridad, si el sistema de copia de seguridad confía en las mismas credenciales. Las copias bloqueadas por aire o por objeto no son opcionales. Son la diferencia entre un mal día y una pesadilla de reconstrucción desde 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 tarda realmente. Una copia de seguridad desde la que nunca se ha restaurado es una suposición, no un plan.

El cambio

La mayoría de las orgs hacen copias de seguridad de GitHub basándose en la suposición de que es un repositorio de código con algunos artefactos secundarios adjuntos. Eso ya no es lo que es GitHub. Es el sistema operativo de mayor velocidad que manejan la mayoría de las empresas, y la velocidad a la que acumula valor ha superado la postura de copia de seguridad que heredaron la mayoría de los equipos.

Mueva GitHub al primer puesto de la lista de prioridades. La cadencia agresiva de las copias de seguridad, la cobertura de toda la superficie, la inmutabilidad y la recuperación probada son las características que hacen realidad esa prioridad. Sin ellos, "hacemos copias de seguridad de GitHub", es una casilla de verificación, no un plan.