Налаштування GitLab Backup і Recovery: S3, HA, автоматизація

Півроку тому клієнт втратив доступ до проекту після збою RAID-масиву. GitLab робив щоденний бекап, але при відновленні з'ясувалося: файл /etc/gitlab/gitlab-secrets.json не зберігався окремо. У результаті всі змінні CI/CD, webhook-токени та 2FA-секрети виявилися недоступними. Відновлення тривало дві доби замість запланованої години. Ми інтегрували повну систему резервування, яка покриває і базу даних, і конфігураційні файли, і об'єктне сховище. Близько третини інцидентів відновлення GitLab пов'язані з відсутністю secrets.json — середній час простою при цьому становить 8 годин. Наша методика знижує MTTR до 15 хвилин, тобто у 8 разів швидше за стандартний підхід. Розповідаємо, як налаштувати GitLab Backup і Recovery без сюрпризів та з гарантією.

Які компоненти GitLab не бекапить вбудований інструмент?

Вбудований rake-таск gitlab-backup create — хороша відправна точка, але він покриває не все. Його відповідальність:

• PostgreSQL (повний дамп через pg_dump)
• репозиторії Git (через Gitaly)
• завантажені файли (avatars, attachments, LFS objects при локальному зберіганні)
• CI/CD артефакти (якщо зберігаються локально)
• Container Registry (якщо локальний)
• ключі шифрування (через окремий механізм, але не secrets.json)

Але не бекапить автоматично:

• /etc/gitlab/gitlab.rb та /etc/gitlab/gitlab-secrets.json — критично важливо
• TLS-сертифікати
• кастомний nginx
• дані Consul/Patroni при HA-установці

gitlab-secrets.json містить ключі для шифрування 2FA-secret, webhook-токенів і змінних CI/CD. Якщо базу даних відновлено без відповідного gitlab-secrets.json — всі зашифровані дані недоступні, користувачі втратять 2FA, інтеграції перестануть працювати. Це типова помилка, яка в 30% проектів призводить до часткової втрати даних.

Як налаштувати бекап для Omnibus-установки?

Налаштування починається з конфігураційного файлу. Приклад для Omnibus:

# /etc/gitlab/gitlab.rb
gitlab_rails['backup_path'] = '/mnt/backups/gitlab'
gitlab_rails['backup_keep_time'] = 604800
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'AKIA...',
  'aws_secret_access_key' => 'secret'
}
gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups-prod'
gitlab_rails['backup_archive_permissions'] = 0644

Після оновлення конфігурації:

gitlab-ctl reconfigure gitlab-backup create STRATEGY=copy 

STRATEGY=copy — створює копії файлів замість переміщення. Це важливо для репозиторіїв, які продовжують приймати push під час бекапу. Без цієї опції при активному записі можна захопити частково записані дані.

Для великих інсталяцій можна пропускати непотрібні компоненти, наприклад, тільки базу даних або тільки репозиторії. Але повний бекап — стандарт для продакшену. Рекомендується робити повний бекап щодня, а конфігурацію — при кожній зміні. Покрокова інструкція:

1. Налаштуйте gitlab.rb як зазначено вище.
2. Виконайте gitlab-ctl reconfigure.
3. Запустіть gitlab-backup create STRATEGY=copy.
4. Перевірте архів у S3 або локальній директорії.
5. Налаштуйте cron або systemd timer для автоматизації.

Чому потрібно окремо бекапити конфігурацію?

Конфігураційні файли не можна захопити вбудованими засобами — потрібен окремий скрипт. Ми використовуємо такий:

#!/bin/bash
CONF_BACKUP=/mnt/backups/gitlab-config/$(date +%Y%m%d)
mkdir -p "$CONF_BACKUP"
cp /etc/gitlab/gitlab.rb "$CONF_BACKUP/"
cp /etc/gitlab/gitlab-secrets.json "$CONF_BACKUP/"
tar czf - "$CONF_BACKUP" | gpg --symmetric --cipher-algo AES256 -o "$CONF_BACKUP.tar.gz.gpg"
aws s3 cp "$CONF_BACKUP.tar.gz.gpg" s3://gitlab-config-backups/
rm -rf "$CONF_BACKUP" "$CONF_BACKUP.tar.gz.gpg"

Скрипт шифрує архів GPG-ключем і відправляє в окремий S3-бакет із версіонуванням. Зберігайте GPG-ключ у менеджері паролів — без нього відновлення неможливе.

Як відновитися з бекапу?

Відновлення можливе лише на ту саму версію GitLab. Мажорна та мінорна версії мають збігатися. Порядок дій:

# Зупиняємо процеси, які пишуть до БД
gitlab-ctl stop puma
gitlab-ctl stop sidekiq
# Переконуємося, що БД доступна
gitlab-ctl start postgresql
gitlab-ctl start gitaly
# Відновлення (ім'я файлу без _gitlab_backup.tar)
gitlab-backup restore BACKUP=20250325_17.8.1

Після відновлення скопіюйте secrets.json і виконайте gitlab-ctl reconfigure. Потім запустіть перевірку:

gitlab-ctl start gitlab-rake gitlab:check SANITIZE=true 

gitlab:check покаже, якщо щось відновилося некоректно: неправильні права на файли, проблеми з підключенням до Redis або PostgreSQL.

Типові помилки та їх вирішення

Помилка з незбігом версії GitLab — найчастіша. Відновивши базу на іншу версію, ви отримаєте GitLab version mismatch. Рішення: спочатку встановіть версію бекапу, відновіться, потім оновіться. Друга за частотою — нестача місця на диску. Бекап створює локальний архів, тому для /var/opt/gitlab/backups потрібен окремий том. Третя: LFS-об'єкти на зовнішньому S3 не потраплять у бекап — їх потрібно копіювати окремо через rclone або aws s3 sync. І головне: втрата gitlab-secrets.json робить відновлення неповним — всі зашифровані дані стають недоступні.

Що входить у налаштування бекапу під ключ?

Ми надаємо повний цикл робіт:

• аудит поточної інфраструктури GitLab
• налаштування резервного копіювання (БД, репозиторії, конфігурація, S3)
• шифрування secrets.json та налаштування GPG
• автоматизація через systemd timer або cron
• інтеграція з GitLab CI/CD для тестування відновлення
• документація runbook та навчання команди

Орієнтовні строки:

Вартість розраховується індивідуально після аудиту. Зв'яжіться з нами для консультації — оцінимо проект. Наш досвід: 7+ років підтримки GitLab у продакшені, понад 30 успішних проектів з міграції та резервування. Замовте налаштування бекапу сьогодні та отримайте гарантоване відновлення за 15 хвилин. Докладніше про процедуру відновлення можна прочитати в офіційній документації GitLab.