# Перенос self-hosted GitLab на новый сервер

> Перенос self-hosted GitLab на новый сервер: команда gitlab-backup, перенос секретов gitlab-secrets.json, восстановление и перенос Container Registry.

## Способы переноса self-hosted GitLab

Self-hosted GitLab переносят двумя способами: официальным механизмом резервного копирования `gitlab-backup` или полным копированием каталогов Omnibus-установки. Первый способ подходит для переезда между версиями GitLab, второй — для переноса «как есть» на идентичную версию.

Перед переносом зафиксируйте версию пакета: `gitlab-ce` или `gitlab-ee` одной версии должны стоять и на старом, и на новом сервере до восстановления бэкапа.

## Резервное копирование через gitlab-backup create

Команда создаёт архив с репозиториями, базой данных и вложениями, но не включает конфигурацию и секреты:

```
gitlab-backup create BACKUP=2026_09_29
ls /var/opt/gitlab/backups/
```

Файл архива вида `2026_09_29_16.5.0_gitlab_backup.tar` скопируйте на новый сервер через scp или rsync.

## Перенос секретов и gitlab.rb

Без файла `/etc/gitlab/gitlab-secrets.json` восстановленный GitLab не сможет расшифровать токены CI/CD, пароли пользователей 2FA и переменные окружения. Перенесите оба файла конфигурации вместе с бэкапом:

```
scp /etc/gitlab/gitlab-secrets.json root@newserver:/etc/gitlab/
scp /etc/gitlab/gitlab.rb root@newserver:/etc/gitlab/
```

На новом сервере примените конфигурацию командой `gitlab-ctl reconfigure` до восстановления бэкапа.

## Восстановление на новом сервере

Остановите сервисы записи данных, оставив работать только базу и Redis, и восстановите архив:

```
gitlab-ctl stop puma
gitlab-ctl stop sidekiq
gitlab-backup restore BACKUP=2026_09_29
gitlab-ctl restart
```

Проверьте вывод команды на ошибки восстановления прав доступа — типичная проблема, если каталог `/var/opt/gitlab/backups` скопирован без сохранения владельца `git:git`.

## Перенос Container Registry и артефактов CI/CD

Образы Container Registry в штатный бэкап не входят при хранении на локальном диске больше определённого объёма. Перенесите каталог реестра отдельно:

```
rsync -avz /var/opt/gitlab/gitlab-rails/shared/registry/ root@newserver:/var/opt/gitlab/gitlab-rails/shared/registry/
```

Если GitLab запущен в Docker-контейнерах, порядок переноса самих контейнеров и томов описан в статье про [перенос Docker-контейнеров между серверами](https://www.zevshost.net/ru/kb/migratsia-docker-konteynerov/). Для больших каталогов реестра используйте методы из статьи о [синхронизации серверов через rsync](https://www.zevshost.net/ru/kb/rsync-sinhronizatsiya-serverov/) — это позволит докопировать данные без повторной полной передачи.

## Проверка после переноса

Выполните диагностику служб и сравните количество проектов и пользователей:

```
gitlab-rake gitlab:check SANITIZE=true
gitlab-rails runner "puts Project.count"
```

Проверьте клонирование одного репозитория по SSH и HTTPS, запуск CI-пайплайна и вход хотя бы одного пользователя с включённым 2FA — это самый частый источник проблем при переносе без секретов.

## Итог: чек-лист переноса GitLab

- Убедитесь, что версия GitLab на новом сервере совпадает с исходной.
- Создайте бэкап через `gitlab-backup create` и перенесите архив.
- Скопируйте `gitlab-secrets.json` и `gitlab.rb` до восстановления.
- Восстановите бэкап и перенесите каталог Container Registry отдельно.
- Проверьте клонирование репозитория, CI-пайплайн и вход с 2FA.

После переключения DNS на новый сервер пройдитесь по общему [чек-листу проверки после миграции](https://www.zevshost.net/ru/kb/migratsia-proverka-posle/).

---

Источник: https://www.zevshost.net/ru/kb/migratsia-gitlab-self-hosted/