Резервное копирование GitLab необходимо выполнять настолько часто, насколько того требует ваше окружение. Поскольку сам процесс состоит из нескольких шагов и включает в себя ряд не совсем очевидных, но очень важных моментов, я хочу рассмотреть его более детально в этой статье.
Если вам интересна тематика Debian и связанных с ним приложений, рекомендую обратиться к тегу Debian на моем блоге.
Содержание
Резервное копирование GitLab
Рассмотренный сценарий резервного копирования актуален лишь для GitLab Omnibus 1.
Подготовительные задачи
Первым делом необходимо внести изменения в основной файл конфигурации GitLab, задав в настройках информацию о хранилище резервных копий. Открываем файл для редактирования:
|
1 |
nano /etc/gitlab/gitlab.rb |
Вставляем кусок кода:
|
1 2 3 4 5 6 |
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:
|
1 |
gitlab-ctl reconfigure |
На этом предварительные настройки закончены.
Создание скрипта
Создадим папку со скриптами (внутри будет храниться чувствительные к компрометации данные, обратите внимание на права доступа):
|
1 |
mkdir -m 700 /root/scripts |
Добавим два файла – gitlab_backup и gitlab_backup_credentials. Первый – это сам скрипт, его вы можете скачать. Второй – файл с учетными данными для доступа к хранилищу, он имеет формат:
|
1 2 |
user=<username> pass=<password> |
Этот файл необходим для того, чтобы в явном виде не прописывать учетные данные в скрипте.
Не забудьте установить необходимые права к каждому файлу:
|
1 2 |
chmod 600 /root/scripts/gitlab_backup.sh chmod 700 /root/scripts/gitlab_backup_credentials |
Осталась пара шагов, чтобы скрипт заработал.
Включение скрипта в работу
Настроим задание, чтобы скрипт запускался по расписанию. Открываем файл crontab для редактирования:
|
1 |
nano /etc/crontab |
В самый конец вставляем строку:
|
1 |
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 придется делать вручную. В минимальном варианте для этого достаточно всего одной команды, например:
|
1 |
tar -cf /mnt/backup01/gitlab_backups/$(date "+etc-gitlab-%Y%m%d-%H%M%S.tar") -C / etc/gitlab |
Бэкап приложений выполняется средствами GitLab и делается ещё проще:
|
1 |
gitlab-rake gitlab:backup:create |
то есть по сути вам достаточно всего две команды, чтобы сделать полный бэкап GitLab. Но в реальности все несколько сложнее и у вас могут возникнуть и другие шаги:
- монтирование/размонтирование удаленного хранилища;
- удаление старых бэкапов;
- отправка отчета о выполнении скрипта.
И др.
aptitude show gitlab-ce | grep Версия | awk -F “: ” ‘{print $2}’
В своем варианте скрипта я добавил обработчик команд, который проверяет код выхода и если он отличается от нормального, то выполнение скрипта останавливается. Также кастомизировал отчет о событиях. В отчете на своей электронной почте вы увидите что-то подобное:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[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... |
На самом деле все упирается лишь в особенности вашей инфраструктуры.
