GITLAB - резервное копирование и восстановление


Администрирование операционных систем на базе Linux (Debian/Ubuntu и Centos/RedHat) Резервное копирование и восстановление информации (Backup & Recovery)
backup gitlab restore установка gitlab
 
 

* В этом блоге я описываю свою повседневную рабочую практику, поэтому все статьи в блоге написаны лично мной и при копировании их на свой сайт пожалуйста указывайте ссылку на страницу откуда вы скопировали.
* Если какая-то статья вам помогла, то вы можете дать мне немного денег вместо простого спасибо (ссылка на форму поддержки проекта внизу страницы), если вы что-то не поняли или у вас что-то не получается, то вы можете нанять меня и я вам все подробно расскажу (расценки и ссылки в конце статьи).


(последние правки 1 месяц)

На днях меня попросили посмотреть механизмы резервного копирования которые остались от уволившегося системного администратора в одной из компаний. Честно говоря я был немного удивлен подходом к резервному копированию который он применял, ведь как я говорю мало сделать резервную копию сервера или отдельного сервиса, надо потом с этой копии еще и восстановиться.

Сегодня я вам расскажу как правильно делать резервные копии GITLAB, ведь там на самом деле есть штатный механизм и совершенно не обязательно и даже вредно делать дамп всех баз и файловых частей. Если вы активно используете GITLAB в продакшн у вас может произойти рассинхронизация на этапе снятия дампов баз и файловых частей системы и естественно, что ни к чему хорошему это не приведет.

Для управления сервером gitlab, на этапе когда он находится в рабочем состоянии служит консольная утилита gitlab-ctl, а для создания резервных копий служит утилита gitlab-rake и этих двух механизмов я уже касался в статье "GITLAB - перенос интегрированной базы Postgresql в штатную базу операционной системы".

Создадим резервную копию всех сервисов GITLAB при помощи команды:

# gitlab-rake gitlab:backup:create

В зависимости от объема ваших репозиториев и базы данных эта операция может занять довольно много времени. Если все операции прошли успешно, то в результате вы получите сообщение:

Creating backup archive: 1540360268_2018_10_24_11.2.3-ee_gitlab_backup.tar ... done
Uploading backup archive to remote storage  ... skipped
Deleting tmp directories ... done

Резервные копии находятся в каталоге /var/opt/gitlab/backups:

# ls /var/opt/gitlab/backups
1540360268_2018_10_24_11.2.3-ee_gitlab_backup.tar

А теперь восстановим созданную резервную копию при помощи последовательности команд:

# systemctl start gitlab-runsvdir.service
# gitlab-rake gitlab:backup:restore BACKUP=1540360268_2018_10_24_11.2.3-ee
# systemctl restart gitlab-runsvdir.service

Архив вы естественно должны положить в каталог /var/opt/gitlab/backups и если все прошло успешно, то вы получите подобное сообщение:

Restoring lfs objects ... 
done
This task will now rebuild the authorized_keys file.
You will lose any data stored in the authorized_keys file.
Do you want to continue (yes/no)? yes

.......
Deleting tmp directories ... done

Вручную создавать резервные копии, это не самая лучшая идея и я бы рекомендовал вам автоматизировать создание резервных копий штатными средствами и доставку их на удаленное хранилище. Можно написать простенький shell-скрипт для этих целей:

#!/bin/sh
gitlab-rake gitlab:backup:create
rsync -r /var/opt/gitlab/backups/ backup-0001@backup.gita-dev.ru:/home/backup-0001/git.gita-dev.ru/
rm -R /var/opt/gitlab/backups/*

Резервную копию можно восстановить и на чистую установку сервера gitlab если существующий перестал корректно функционировать, для начала вам конечно его потребуется установить, но на самом деле там дел на 15 минут если следовать моей инструкции "Как установить GITLAB (пошаговое руководство)".

Восстанавливать бэкап вам потребуется именно на такую версию gitlab с которой он и создавался, а в противном случае вы получите ошибку:

GitLab version mismatch:
  Your current GitLab version (11.4.0-ee) differs from the GitLab version in the backup!
  Please switch to the following version and try again:
  version: 11.2.3-ee

Вы можете установить определенную версию gitlab при помощи простой последовательности команд. Во первых получаем все доступные версии пакета:

# apt-cache madison gitlab-ee

Во вторых, удалим текущую конфигурацию gitlab:

# gitlab-ctl cleanse

Деинсталлируем текущую версию гитлаб и устанавливаем версию которая нам требуется:

# apt-get purge gitlab-ee
# apt-get install gitlab-ee=11.2.3-ee.0
Моя официальная страница на FaceBook
Мой микроблог в твиттер

Установка GITLAB на ARM-платформу (BananaPI M2)

Установка GITLAB на ARM-платформу (BananaPI M2)

В процессе эксплуатации GIT-хранилища RhodeCode я пришел к мнению, что надо с него мигрировать и благо, что я на него не сильно пока залез. Главная причина по которой я решил с него мигрировать, это его прожорливость и если на одной из клиентских платформ с выделенным сервером он вполне себе прижился, то на моем небольшом VPS он потребляет катастрофически много ресурсов и периодически по этому поводу залезает в swap, после чего скорость его работы падает на столько, что остается только материться. Сегодня будем пробовать не менее прожорливого монстрика GITLAB, но устанавливать его будем на наше файловое хранилище которое как наверное помните по моим предыдущим заметкам построено на ARM-платформе BabanaPI M2.


Как установить GITLAB (пошаговое руководство)

Как установить GITLAB (пошаговое руководство)

И еще одна небольшая инструкция по установке web-приложения на Linux-сервер (точнее на Ubuntu Server 16.04). В рамках одного из текущих проектов мне потребовалось развернуть GITLAB на сервер заказчика и естественно мне на этот шаг работы (как в принципе и на весь проект) необходимо подготовить документацию, а так как инструкция по установке внутреннего git-репозитария GITLAB особой коммерческой тайны не представляет, я могу поделиться с вами этим пошаговым руководством.


HTTPS-защита подключений к GITLAB

HTTPS-защита подключений к GITLAB

Как я уже говорил в заметке про установку GITLAB, этот комбайн тащит за собой набор софта включающий в себя Nginx, Postgresql и т.п., а сегодня мы будет отключать использование встроенного в GITLAB Nginx и будем использовать наш центральный Front Nginx, что позволит установить параллельно с GITLAB на одном сервере еще ряд приложений. Одной из побочных задач такого решения служит настройка HTTPS-защиты подключений к нашему внутреннему GIT-репозитарию.


GITLAB - перенос интегрированной базы Postgresql в штатную базу операционной системы

GITLAB - перенос интегрированной базы Postgresql в штатную базу операционной системы

GitLab, это отличный GIT-репозитарий для использования внутри компании с богатым функционалом и простой установкой, как его устанавливать я уже рассказывал и вы наверное обратили внимание, что этот продукт рекомендуется использовать на отдельном хосте и он поставляется полностью со своей инфраструктурой программ окружения. Как отвязать его от использования встроенного Nginx я вам уже рассказал и сегодня мы будем отвязывать его от встроенного сервера Postgresql.


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


Есть вопросы?
Спрашивайте и я обязательно вам отвечу!

* Поля обязательные для заполнения .