Un backup de GitLab que no puede restaurar es solo un fichero grande

La mayoría de las instancias autoalojadas de GitLab tienen un trabajo de backup nocturno, y la mayoría de las personas que lo configuraron nunca han restaurado a partir de él. Eso es un problema, porque el archivo que produce GitLab es incompleto a propósito. Restáurelo en un servidor nuevo sin los ficheros que omite y sus repositorios volverán, pero sus variables de CI, los ajustes de doble factor y los registros de runners se convertirán en datos ilegibles. Esto es lo que contiene un backup completo de GitLab, cómo moverlo sin debilitar su seguridad y cómo demostrar que funciona.

Qué incluye la tarea de backup, y qué deja fuera

En una instalación por paquete (Omnibus), la tarea de backup es:

sudo gitlab-backup create STRATEGY=copy

Escribe un único archivo tar en el directorio de backups, normalmente /var/opt/gitlab/backups. Ese archivo contiene la base de datos, los repositorios Git, las subidas, los objetos LFS, los artefactos de trabajos de CI, las páginas, los paquetes y, si está habilitado, el registro de contenedores. STRATEGY=copy copia los datos antes de archivarlos, lo que evita errores cuando los ficheros cambian durante un backup largo en una instancia con actividad.

Lo que no contiene, a propósito:

• /etc/gitlab/gitlab-secrets.json, las claves usadas para cifrar las columnas sensibles de la base de datos.
• /etc/gitlab/gitlab.rb, su configuración.
• Los certificados y claves TLS bajo /etc/gitlab/ssl, si los guarda ahí.
• Las claves de host SSH en /etc/ssh, que los clientes de sus desarrolladores ya tienen registradas.

GitLab los deja fuera para que un único archivo robado no contenga a la vez los datos cifrados y la clave que los descifra. Es un razonamiento sólido, y le traslada a usted la tarea de respaldarlos por separado.

Por qué importa tanto el fichero de secretos

Las variables de CI/CD, los tokens de registro de runners, las semillas de autenticación de doble factor, las contraseñas de integraciones y varios valores más están cifrados en la base de datos con claves de gitlab-secrets.json. Restaure la base de datos sin el fichero de secretos correspondiente y GitLab arranca, los repositorios están ahí, y entonces los pipelines fallan, los usuarios con doble factor no pueden iniciar sesión y los runners hay que registrarlos de nuevo.

Respalde el directorio de configuración como un artefacto propio:

sudo gitlab-ctl backup-etc --backup-path /var/opt/gitlab/config-backups

Esto produce un tar de /etc/gitlab, incluido el fichero de secretos. Guárdelo en un lugar distinto del archivo de datos, con un acceso más estricto, y mantenga las parejas correspondientes juntas en su política de retención. Un archivo de datos del lunes y un fichero de secretos del jueves pueden no coincidir si algo se rotó entre medias.

En instalaciones en contenedor los comandos son los mismos, ejecutados dentro del contenedor, y /etc/gitlab es el volumen que haya mapeado a esa ruta. Asegúrese de que ese volumen forma parte de lo que respalda; es fácil respaldar solo el volumen de datos.

Extraiga el backup, no lo empuje

El patrón habitual es un cron en el servidor de GitLab que copia el archivo a un host de backup. Eso significa que el servidor de GitLab guarda credenciales que pueden escribir en sus backups. Si GitLab queda comprometido, también lo queda el camino para llegar a los backups y borrarlos.

Invierta la dirección. El host de backup se conecta a GitLab y recoge los ficheros. GitLab no guarda ninguna credencial del host de backup y no tiene ruta de red hacia él. En el lado de GitLab, limite lo que puede hacer la clave del host de backup con un comando forzado en authorized_keys:

command="/usr/local/bin/backup-send",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAA... backup-puller

donde backup-send es un pequeño script que no hace nada salvo transmitir el archivo de datos más reciente y su archivo de configuración correspondiente. En el host de backup, el trabajo recoge ambos, comprueba sus tamaños y checksums, y alerta si falta alguno o es más antiguo de lo esperado.

Después haga cumplir la dirección en el firewall: el host de backup puede abrir conexiones hacia GitLab; nada en la red de GitLab puede abrir conexiones hacia el host de backup.

Reglas de restauración que conviene conocer antes de necesitarlas

Un backup de GitLab solo se restaura sobre la misma versión y edición de GitLab que lo creó. Escriba la versión en el nombre del archivo o en un fichero anexo en el momento del backup:

sudo gitlab-rake gitlab:env:info > gitlab-env-$(date +%F).txt

Si pierde el servidor y el único instalador que encuentra es más nuevo, primero instalará la versión antigua, restaurará y después actualizará por la ruta soportada. Saberlo de antemano convierte una noche larga en un procedimiento planificado.

La restauración en sí, sobre una instalación limpia de la versión correspondiente:

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
# put gitlab-secrets.json and gitlab.rb back into /etc/gitlab first
sudo gitlab-ctl reconfigure
sudo gitlab-backup restore BACKUP=
sudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true
sudo gitlab-rake gitlab:doctor:secrets

El último comando es el que importa. gitlab:doctor:secrets recorre las columnas cifradas e informa de las que no puede descifrar. Si informa de fallos, su fichero de secretos y su archivo de datos no van juntos.

Demuéstrelo con regularidad

Una restauración que no ha probado es una esperanza. Conviértala en rutina:

• Levante una VM desechable en una red aislada sin ruta hacia producción.
• Instale la versión de GitLab registrada con el backup.
• Restaure la pareja más reciente de configuración y datos.
• Ejecute gitlab:check y gitlab:doctor:secrets.
• Clone un repositorio conocido, compare el hash de su último commit con producción y abra la página de variables de CI de un proyecto.
• Registre el resultado y el tiempo que llevó, y después destruya la VM.

Cronométrelo también. La duración de la restauración es su tiempo real de recuperación, y en una instancia grande suele ser mayor de lo que la gente calcula.

Una segunda copia independiente del código

El backup completo protege la aplicación entera. Para los repositorios en sí, un simple mirror le da una segunda copia que no depende en absoluto de las herramientas de GitLab:

git clone --mirror git@gitlab.example.com:group/project.git
git -C project.git remote update --prune

Ejecútelo desde el lado del backup para los repositorios que no puede permitirse perder. No restaurará issues ni merge requests, pero significa que el historial de su código fuente sobrevive incluso a un archivo de backup que no pueda leer.

La versión corta

• gitlab-backup create es la mitad de un backup. gitlab-ctl backup-etc es la otra mitad.
• Mantenga secretos y datos en parejas correspondientes, guardadas por separado, con un acceso más estricto a los secretos.
• El lado del backup extrae; GitLab no tiene ruta hacia sus propios backups.
• Registre la versión de GitLab con cada archivo.
• Restaure con regularidad, y ejecute gitlab:doctor:secrets cada vez.

Así protegemos las instancias de GitLab que operamos para clientes en nuestros propios datacenters. Si quiere que revisemos su propia ruta de restauración, estaremos encantados de ayudar.

Hable con un ingeniero

Related

Relacionado: Control de versiones gestionado en GitLab · Documentos de oficina gestionados en Nextcloud