Резервное копирование GitLab

Резервное копирование GitLab необходимо выполнять настолько часто, насколько того требует ваше окружение. Поскольку сам процесс состоит из нескольких шагов и включает в себя ряд не совсем очевидных, но очень важных моментов, я хочу рассмотреть его более детально в этой статье.


Если вам интересна тематика Debian и связанных с ним приложений, рекомендую обратиться к тегу Debian на моем блоге.


Резервное копирование GitLab

Рассмотренный сценарий резервного копирования актуален лишь для GitLab Omnibus 1.

Подготовительные задачи

Первым делом необходимо внести изменения в основной файл конфигурации GitLab, задав в настройках информацию о хранилище резервных копий. Открываем файл для редактирования:

nano /etc/gitlab/gitlab.rb

Вставляем кусок кода:

gitlab_rails['backup_upload_connection'] = {
 :provider => 'Local',
 :local_root => '/mnt/backup01'
}
gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups'
gitlab_rails['backup_keep_time'] = 604800

где

  • /mnt/backup01 — точка монтирования удаленного хранилища;
  • gitlab_backups — подпапка, которая будет создана в корневом каталоге;
  • backup_keep_time — время жизни бэкапа в секундах

Примечание: настройки подразумевают использование локального хранилища. «Локальное» в терминологии GitLab означает, что оно находится локально на сервере, но при этом никто не запрещает, чтобы это было примонтированное удаленное хранилище. Именно такой вариант я и буду использовать, но доступна возможность бэкапа на облачные хранилища 2.

Чтобы изменения вступили в силу, переконфигурируем GitLab:

gitlab-ctl reconfigure

На этом предварительные настройки закончены.

Создание скрипта

Создадим папку со скриптами (внутри будет храниться чувствительные к компрометации данные, обратите внимание на права доступа):

mkdir -m 700 /root/scripts

Добавим два файла — gitlab_backup и gitlab_backup_credentials. Первый — это сам скрипт, его вы можете скачать. Второй — файл с учетными данными для доступа к хранилищу, он имеет формат:

user=<username>
pass=<password>

Этот файл необходим для того, чтобы в явном виде не прописывать учетные данные в скрипте.

Не забудьте установить необходимые права к каждому файлу:

chmod 600 /root/scripts/gitlab_backup.sh
chmod 700 /root/scripts/gitlab_backup_credentials

Осталась пара шагов, чтобы скрипт заработал.

Включение скрипта в работу

Настроим задание, чтобы скрипт запускался по расписанию. Открываем файл crontab для редактирования:

nano /etc/crontab

Примечание: вариант прямого редактирования /etc/crontab допустим, но не рекомендуем. Лучше редактировать планировщик командой crontab -e, но синтаксис файла отличается, подробнее читайте в статье Debian. Шпаргалка сисадмина. Планировщик задач.

В самый конец вставляем строку:

00 6 * * * root /root/scripts/gitlab_backup.sh

Скрипт будет запускаться каждый день в 6 утра.

Принцип работы

Чтобы бэкап был полным, он должен включать как минимум следующие разделы:

  • архив каталога конфигурации /etc/gitlab
  • архив данных приложения, размещение которых определено в параметре git_data_dirs файла конфигурации (/etc/gitlab/gitlab.rb). По умолчанию /var/opt/gitlab/git-data.

Бэкап каталога /etc/gitlab придется делать вручную. В минимальном варианте для этого достаточно всего одной команды, например:

tar -cf /mnt/backup01/gitlab_backups/$(date "+etc-gitlab-%Y%m%d-%H%M%S.tar") -C / etc/gitlab

Бэкап приложений выполняется средствами GitLab и делается ещё проще:

gitlab-rake gitlab:backup:create

то есть по сути вам достаточно всего две команды, чтобы сделать полный бэкап GitLab. Но в реальности все несколько сложнее и у вас могут возникнуть и другие шаги:

  • монтирование/размонтирование удаленного хранилища;
  • удаление старых бэкапов;
  • отправка отчета о выполнении скрипта.

И др.

Примечание: забегая вперед хочу отметить, что очень важно в скрипте выводить также версию GitLab. Дело в том, что восстановить бэкап вы сможете исключительно на сервере той же самой версии, на которой этот бэкап снимался. Узнать версию можно командой:

aptitude show gitlab-ce | grep Версия | awk -F «: » ‘{print $2}’

В своем варианте скрипта я добавил обработчик команд, который проверяет код выхода и если он отличается от нормального, то выполнение скрипта останавливается. Также кастомизировал отчет о событиях. В отчете на своей электронной почте вы увидите что-то подобное:

[27/04/2017 06:00:02]: Starting work
[27/04/2017 06:00:02]: cifs-utils has been installed
[27/04/2017 06:00:02]: mailutils has been installed
[27/04/2017 06:00:02]: Mount point /mnt/backup01 is free
[27/04/2017 06:00:03]: Mount remote storage - Success
[27/04/2017 06:00:03]: Gitlab version: 8.16.4-ce.0
[27/04/2017 06:00:05]: Backup directory: /mnt/backup01/gitlab_backups
[27/04/2017 06:00:05]: Backup directory contain 58 files with a total size in 20G
[27/04/2017 06:00:13]: Setting up permission mask - Success
[27/04/2017 06:00:13]: Backup gitlab configuration - Success
[27/04/2017 06:00:13]: Storage contain 10 configuration backups and 1 are older than 7 days. Need to delete old files...
[27/04/2017 06:00:13]: Delete old configuration backups - Success
[27/04/2017 06:00:13]: Starting GitLab backup engine...

На самом деле все упирается лишь в особенности вашей инфраструктуры.

comments powered by HyperComments