GitLab es una herramienta de DevOps completa que incluye control de versiones, Wiki, CI y más. Esto significa (y habrán podido comprobarlo quienes hayan realizado una instalación manual de GitLab desde los fuentes) que está conformado por un buen número de componentes, y al momento de implementar una estrategia de backup puede resultar abrumadora. Sin embargo, afortunadamente GitLab cuenta con su propia herramienta de backup incluida en el paquete de instalación. Este artículo explica cómo configurar una estrategia de backup y utilizando dicha herramienta.
Como muchos sabemos, las copias de seguridad y respaldo son una de las tareas más difíciles e importantes en el trabajo de un SysAdmin.
Para comenzar, crear un directorio donde almacenar las copias de respaldo de la instancia local de GitLab:
root@gitlab:~# mkdir -p /backups/gitlab root@gitlab:~# chown git:root /backups/gitlab/
Luego es necesario editar la configuración de GitLab para establecer la ruta al directorio de backups:
root@gitlab:~# nano /usr/local/gitlab/config/gitlab.yml
Debajo de la configuración de backup, modificar la clave "path":
backup:
path: "/backups/gitlab"
Habiendo configurado correctamente la ruta es posible verificar el funcionamiento de la herramienta de backup de GitLab. Pasar al usuario git y cambiar al directorio de instalación de GitLab:
root@gitlab:~# su - git git@gitlab:~$ cd /usr/local/gitlab
Para crear un backup de GitLab, ejecutar el script rake con el parámetro gitlab:backup:create:
git@gitlab:/usr/local/gitlab$ bundle exec rake gitlab:backup:create RAILS_ENV=production 2019-05-20 10:00:04 -0300 -- Dumping database ... Dumping PostgreSQL database gitlab ... [DONE] 2019-05-20 10:00:07 -0300 -- done 2019-05-20 10:00:07 -0300 -- Dumping repositories ... * emiliano/my_awesome_project ... [DONE] [DONE] Wiki 2019-05-20 10:00:08 -0300 -- done 2019-05-20 10:00:08 -0300 -- Dumping uploads ... 2019-05-20 10:00:08 -0300 -- done 2019-05-20 10:00:08 -0300 -- Dumping builds ... 2019-05-20 10:00:08 -0300 -- done 2019-05-20 10:00:08 -0300 -- Dumping artifacts ... 2019-05-20 10:00:08 -0300 -- done 2019-05-20 10:00:08 -0300 -- Dumping pages ... 2019-05-20 10:00:08 -0300 -- done 2019-05-20 10:00:08 -0300 -- Dumping lfs objects ... 2019-05-20 10:00:08 -0300 -- done 2019-05-20 10:00:08 -0300 -- Dumping container registry images ... 2019-05-20 10:00:08 -0300 -- [DISABLED] Creating backup archive: 1558357208_2019_05_20_11.9.5_gitlab_backup.tar ... done Uploading backup archive to remote storage ... skipped Deleting tmp directories ... done done done done done done done done Deleting old backups ... skipping
Se observa que se crean copias de respaldo de la base de datos, los repositorios, las wikis, y el resto de los componentes de GitLab.
Al finalizar la ejecución, se ha creado un archivo tar con sufijo "gitlab_backup.tar":
git@gitlab:/usr/local/gitlab$ ls -lh /backups/gitlab/ total 235K -rw------- 1 git git 240K may 20 10:00 1558357208_2019_05_20_11.9.5_gitlab_backup.tar
Más allá de la copia de seguridad de todos los datos de la instancia de GitLab, es recomendable resguardar los siguientes archivos de configuración:
/usr/local/gitlab/config/gitlab.yml /usr/local/gitlab/config/unicorn.rb /usr/local/gitlab/config/database.yml /usr/local/gitaly/config.toml /etc/default/gitlab /etc/logrotate.d/gitlab /usr/local/etc/nginx/nginx.conf /usr/local/etc/nginx/gitlab.conf
Para ello, utilizar un script aparte.
También es recomendable mantener una copia con rsync de los directorios de instalación de todos los componentes de GitLab:
/usr/local/gitaly /usr/local/gitlab /usr/local/gitlab-shell /usr/local/gitlab-workhorse
Aparte del resto de los componentes que hacen al funcionamiento de GitLab, como Postgres, Nginx, etc.
Por supuesto estamos hablando de una estrategia de backup local (en el propio servidor) que dependerá luego del software de backup utilizado a bajo nivel en la infraestructura de nuestra organización.
Finalmente es necesario crear una nueva tarea de cron para crear automáticamente una copia de seguridad una vez al día:
git@gitlab:/usr/local/gitlab$ crontab -e
Agregar la siguiente tarea para correr la tarea de backup a las 20:31 hs. (cambiar la hora según conveniencia):
31 20 * * * . /etc/profile; cd /usr/local/gitlab && bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1
Luego de unos días se van acumulando las copias de seguridad en el directorio de backup:
git@gitlab:~$ ls -lh /backups/gitlab/ total 2,1M -rw------- 1 git git 240K may 23 20:31 1558654285_2019_05_23_11.9.5_gitlab_backup.tar -rw------- 1 git git 240K may 24 20:31 1558740685_2019_05_24_11.9.5_gitlab_backup.tar -rw------- 1 git git 240K may 25 20:31 1558827082_2019_05_25_11.9.5_gitlab_backup.tar -rw------- 1 git git 240K may 26 20:31 1558913485_2019_05_26_11.9.5_gitlab_backup.tar -rw------- 1 git git 240K may 27 20:31 1558999881_2019_05_27_11.9.5_gitlab_backup.tar -rw------- 1 git git 240K may 28 20:31 1559086283_2019_05_28_11.9.5_gitlab_backup.tar -rw------- 1 git git 240K may 29 20:31 1559172684_2019_05_29_11.9.5_gitlab_backup.tar -rw------- 1 git git 240K may 30 20:31 1559259087_2019_05_30_11.9.5_gitlab_backup.tar
Para borrar automáticamente backups antiguos (que ya fueron pasados a cinta u otro medio de almacenamiento externo por el software de backup subyacente), revisar el script Bash en el artículo Borrar automáticamente backups de más de 60 días.
La restauración de una copia de respaldo se hace utilizando el mismo script rake. Revisar la documentación oficial de GitLab al respecto: Backing up and restoring GitLab - Restore.
Referencias
Tal vez pueda interesarte
