Настройка 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.