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

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


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


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

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

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

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

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

где

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И др.

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

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

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

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

comments powered by HyperComments
Восстановление GitLab из резервной копии - blog.bissquit.com
2017-12-07 22:42:52
[…] Все будет ещё проще, если вы настраивали регулярное резервное копирование GitLab по моей недавней статье (или близко к ней) — Резервное копирование GitLab. […]