Cuando le pides a una instancia de GitLab en ejecución que genere un archivo de copia de seguridad completo con el gitlab-rake gitlab:backup:createcomando:
- ¿GitLab realiza algo para congelar el estado de la aplicación?
- ¿Existe algún riesgo de generar una copia de seguridad técnicamente funcional que presente un estado inconsistente?
En detalle:
- ¿Qué sucede cuando se envían nuevas confirmaciones mientras se genera la copia de seguridad?
- En términos generales, si se inicia alguna modificación durante la copia de seguridad, ¿qué puede pasar?
- ¿Existe algún caché que ponga en cola los cambios para aplicarlos a la base de datos o escribir en archivos/repositorios?
Por el momento, no tengo idea de qué sucede cuando se archiva un repositorio que se está modificando o cuando se realiza una copia de seguridad en una base de datos que ejecuta transacciones.
Leí el código de respaldo de GitLab hoy.gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/backuppero no pude encontrar ninguna pista a mis preguntas.No codifico con Ruby, así que eso no me ayuda...
GitLab simplemente ejecuta el tarcomando en los archivos a respaldar.
En la documentación de GitLabdocs.gitlab.com/ee/raketasks/backup_restore.html#backup-strategy-optionse afirma que:
Cuando los datos cambian mientras tar los lee, puede ocurrir que el archivo de error cambie a medida que lo leemos y hará que falle el proceso de copia de seguridad. Para combatir esto, 8.17 introduce una nueva estrategia de respaldo llamada copia. La estrategia copia archivos de datos en una ubicación temporal antes de llamar a tar y gzip, evitando el error.
El STRATEGY=copyargumento hace que gitlab-rake gitlab:backup:createse ejecute un rsync -acomando para copiar todos los archivos antes de crear el archivo con tar.
Según tengo entendido, la documentación dice que al utilizar la copyestrategia, GitLab nunca producirá un archivo técnicamente dañado y nunca dejará de crearlo. Supongo que esta estrategia garantiza que el archivo generado se pueda restaurar, pero ¿qué pasa con el estado de coherencia de los datos?
¿Podemos asegurarnos de que el archivo de respaldo incluya un estado de instantánea consistente/limpio de la instancia de GitLab?
No encuentro ninguna información en la documentación al respecto.
Quiero hacer una copia de seguridad de GitLab sin interrupciones.
Sé que podría detener GitLab durante unos segundos y tomar una instantánea del volumen o sistema de archivos LVM en lugar de usar el mecanismo de copia de seguridad integrado, pero no quiero interrumpir GitLab.
Puede ejecutar una copia de seguridad de GitLab, interrumpiendo todos los servicios menos postgresqluno, por lo que no se pueden realizar modificaciones mientras realiza la copia de seguridad con el mecanismo integrado de GitLab, pero aún así debe bloquear el servicio para sus usuarios durante algún tiempo.
Bonificación: ¡Mis preguntas también se aplican a la toma de instantáneas del volumen o sistema de archivos LVM!
Respuesta1
Hay muchas preguntas sobre cómo realizar una copia de seguridad constante de Gitlab, pero no he encontrado una buena respuesta.
Algunas de las preguntas:
- https://stackoverflow.com/questions/24066283/how-to-make-a-consistent-gitlab-backup
- https://stackoverflow.com/questions/15825735/gitlab-is-the-backup-rake-task-atomic
puedo citarte@SorenLøvborgLa respuesta que parece correcta:
Los propios repositorios tienen una copia de seguridad mediante
git bundle, por lo que también deberían ser seguros. Las cargas son archivos simples y se escriben una vez, por lo que tampoco debería haber problemas. Es posible que la base de datos no esté perfectamente sincronizada con repositorios y archivos, pero no de una manera que provoque la pérdida de datos. Con todo, parece completamente seguro hacer una copia de seguridad mientras GitLab se está ejecutando, incluso si no es atómico.
Editar:ya has recibido una respuesta oficial deEquipo Gitlab.