Восстановление GitLab из резервной копии делится всего на два этапа – восстановление конфигурации и восстановление данных. Первый этап вы должны сделать вручную, второй делается встроенными средствами GitLab. Также важно не забыть о подготовке окружения, на котором будет выполняться восстановление.
Об этом я и расскажу в статье, но помимо этого, не забывайте про официальную документацию 1 2 3.
Если вам интересна тематика Debian и связанных с ним приложений, рекомендую обратиться к тегу Debian на моем блоге.
Содержание
Восстановление GitLab из резервной копии
Если вдруг возникла необходимость развернуть бэкапы на новом сервере, то обкатанный сценарий disaster recovery под рукой окажется как нельзя кстати.
Все будет ещё проще, если вы настраивали регулярное резервное копирование GitLab по моей недавней статье (или близко к ней) – Резервное копирование GitLab.
Исходный и целевой серверы
Чтобы восстановление прошло максимально просто и быстро, ваш новый сервер по своим настройкам (хранилище, сеть, имя и т.п.) должен максимально походить на старый сервер.
Настройки моего окружения можно увидеть в статьях:
Ну а теперь к делу.
Подготовка окружения
Поскольку GitLab имеет встроенные средства резервного копирования и восстановления, на новом сервере необходимо сначала развернуть чистый GitLab, что мы и делаем.
Ставим пререквизиты:
|
1 2 3 4 |
apt-get install curl \ openssh-server \ ca-certificates \ postfix |
В процессе установки настройки постфикса оставляем по умолчанию.
Находим нужную версию gitlab в архиве APT/YUM repository for GitLab Community Edition packages.
Свою версию я нашел – gitlab-ce_8.16.4-ce.0_amd64.deb
Выполняем инструкции, описанные на сайте в разделе Install this Package, а именно:
|
1 |
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash |
Успешное выполнение скрипта завершается сообщением: The repository is setup! You can now install packages.
После этого ставим Gitlab:
|
1 |
apt-get install gitlab-ce=8.16.4-ce.0 |
Запускаем начальную конфигурацию (на новом сервере, на который планируется восстановить данные, это нужно сделать хотя бы один раз):
|
1 |
gitlab-ctl reconfigure |
Теперь нужно накатить бэкап на свежий сервер.
Восстановление
Перед выполнением восстановления вам необходимо скопировать бэкап на целевой сервер. Резервная копия в моем случае состоит из двух файлов – архива конфигурации, сделанного вручную и архива данных, сделанного встроенными средствами GitLab.
Предположим оба архива уже находятся на сервере.
Установить пакет cifs-utils:
apt-get install cifs-utils
Смонтировать удаленное хранилище:
mount.cifs //storage/backup /mnt/backup01 -o credentials=/home/bissquit/gitlab_backup_credentials,uid=<git_user_uid>,gid=<git_user_gid>.
Разархивируем файлы конфигурации (в зависимости от того как вы делали архив, в вашем случае команда может отличаться):
|
1 |
tar -xf etc-gitlab-20170502-060017.tar -C / |
Скопируем архив данных в хранилище (по умолчанию /var/opt/gitlab/backups):
|
1 |
cp 1493694108_2017_05_02_gitlab_backup.tar /var/opt/gitlab/backups/1493694108_2017_05_02_gitlab_backup.tar |
Как только все файлы лежат по своим местам, останавливаем сервисы:
|
1 |
gitlab-ctl stop unicorn |
|
1 |
gitlab-ctl stop sidekiq |
На всякий случай проверяем их статус:
|
1 |
gitlab-ctl status |
Выполняем восстановление:
|
1 |
gitlab-rake gitlab:backup:restore BACKUP=1493694108_2017_05_02 |
где 1493694108_2017_05_02 – префикс архива данных GitLab.
В процессе восстановления будут заданы пара вопросов, на которые отвечаем утвердительно, если сервер восстанавливаем с нуля.
Если все прошло успешно, увидите что-то подобное в самом конце:
Запускаем и проверяем:
|
1 |
gitlab-ctl start |
|
1 |
gitlab-rake gitlab:check SANITIZE=true |
После этого восстановление можно считать завершенным, но требуется как минимум проверить корректность работы сервиса.
Notes:
