¿Cómo hacer una copia de seguridad a gran escala de Gitlab?

Cuando preguntan al soporte de Gitlab sobre cómo hacer una copia de seguridad de 3TB en los Gitlab locales, responden que usan nuestra herramienta que produce un tarball.

Esto me parece mal en todos los niveles. Este tarball contiene el volcado de postgres, las imágenes del acoplador, los datos de repositorio, la configuración de GIT LFS, etc., etc. Hacer una copia de seguridad de TB de datos estáticos junto con KB de datos muy dinámicos no parece correcto. Y luego viene el problema de que queremos hacer una copia de seguridad cada hora.

Pregunta

Realmente me gustaría saber de otros cómo lo hacen, para obtener una copia de seguridad consistente.

ZFS en Linux estaría bien conmigo, si eso es parte de la solución.

linux backup postgresql zfs gitlab Sandra
fuente

¿Por qué está mal esto? Realiza una copia de seguridad de su Gitlab por completo para restaurarlo por completo. No creo que esto esté mal. Por supuesto, usa mucho más espacio que, por ejemplo, copias de seguridad incrementales, pero ... No me importaría el tamaño de la copia de seguridad.

Lenniey

Tener una copia de seguridad cada hora no es desconocido, pero es imposible hacer un 3TB en menos de una hora con su enfoque. Y las copias de seguridad por solo un día serían ~ 100TB, donde podría haber solo 10MB de cambios en los datos.

Sandra

OK, esta es una pregunta diferente, no sobre la copia de seguridad en general, sino sobre las copias de seguridad frecuentes.

Lenniey

En sus documentos oficiales , incluso mencionan que su método es lento y sugieren alternativas:

If your GitLab server contains a lot of Git repository data you may find the GitLab backup script to be too slow. In this case you can consider using filesystem snapshots as part of your backup strategy.

sin embargo, no puedo hablar por experiencia. Pero puede que tenga que incluir algo como esto pronto ...

Lenniey

Gitlab tiene opciones en el archivo de configuración de copia de seguridad y banderas que le permite excluir secciones, o ir tan lejos como para almacenar imágenes y objetos en un almacén de objetos

ssube

Respuestas:

Durante un período de tiempo tan corto entre las copias de seguridad (1h), su mejor opción es confiar en la instantánea y el send/recv soporte del nivel del sistema de archivos .

Si usar ZoL no es un problema en su entorno, le recomiendo encarecidamente que lo use. ZFS es un sistema de archivos muy robusto y realmente le gustarán todos los extras (por ejemplo: compresión) que ofrece. Cuando se combina con sanoid/syncoid, puede proporcionar una estrategia de respaldo muy sólida. La principal desventaja es que no está incluido en el núcleo de la línea principal, por lo que debe instalarlo / actualizarlo por separado.

Alternativamente, si realmente necesita restringirse a las cosas incluidas en la línea principal, puede usar BTRFS. Pero asegúrese de comprender sus (muchos) inconvenientes y pita .

Finalmente, una solución alternativa es utilizar lvmthinpara realizar copias de seguridad periódicas (por ejemplo: con snapper), confiando en herramientas de terceros (por ejemplo:bdsync , blocksync, etc) para copiar sólo los deltas / barco.

Un enfoque diferente sería tener dos máquinas replicadas (vía DRBD) donde tomar instantáneas independientes a través de lvmthin.

shodanshok
fuente

¿Qué hay de postgres? ¿Pararía gitlab y postgres por un minuto, para poder hacer una toma de imagen consistente? Idealmente, sería genial si postgres se pudiera poner en modo de solo lectura mientras se realiza la instantánea.

Sandra

La restauración de @Sandra a partir de las instantáneas de un sistema de archivos debe aparecer en postgresql (y en cualquier otra base de datos escrita correctamente) como un escenario genérico de "bloqueo del host", lo que desencadena su propio procedimiento de recuperación (es decir, comprometerse con la base de datos principal de cualquier página parcialmente escrita). En otras palabras, no necesita poner postgres en modo de solo lectura al tomar instantáneas.

shodanshok

Revisaría lo que está respaldando y posiblemente use un enfoque de "ruta múltiple". Por ejemplo, puede hacer una copia de seguridad de los repositorios de Git ejecutándose constantemente a través de extracciones de Git en servidores de respaldo. Eso copiaría solo el diff y te dejaría con una segunda copia de todos los repositorios de Git. Presumiblemente podría detectar nuevos repositorios con la API.

Y use los procedimientos de copia de seguridad "incorporados" para hacer una copia de seguridad de los problemas, etc. Dudo que el 3TB provenga de esta parte, por lo que podrá hacer copias de seguridad muy a menudo a un costo muy bajo. También puede configurar la base de datos PostgreSQL con un modo de espera cálido con replicación.

Posiblemente su 3TB proviene de imágenes de contenedor en el registro de Docker. ¿Necesitas respaldarlos? Si es así, entonces puede haber un mejor enfoque solo para eso.

Básicamente, recomendaría mirar realmente qué es lo que constituye su respaldo y respaldar los datos en varias partes.

Incluso la herramienta de respaldo de GitLab tiene opciones para incluir / excluir ciertas partes del sistema, como el Registro Docker.

ETL
fuente

git pulls no es una copia de seguridad incremental perfecta. git push --forceromperá las copias de seguridad o borrará el historial de ellas, dependiendo de cómo se implemente.

user371366

@ dn3s es por eso que siempre deshabilitas git push --force en el repositorio principal. Si alguien quiere cambiar la historia, puede hacer su propio tenedor y aceptar todos los riesgos que conlleva.

charlie_pl

eso podría estar bien para la replicación , pero no desea que la integridad de sus copias de seguridad se base en el comportamiento correcto de la aplicación. ¿Qué sucede si hay un error en la aplicación o si está mal configurado en el futuro? ¿Qué pasa si su servidor está comprometido por un usuario malintencionado? Si su aplicación tiene la capacidad de eliminar contenido del host de copia de seguridad, se pierde gran parte del valor de las copias de seguridad remotas incrementales.

user371366