Поиск по сайту:

Как сделать резервную копию вашего сервера GitLab


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

GitLab имеет встроенный компонент резервного копирования, который может создать полный архив данных вашей установки. Архив можно восстановить на свежем сервере с той же версией GitLab.

Вот как настроить резервное копирование в локальную файловую систему или в корзину Amazon S3. Эти шаги предназначены для использования с редакциями GitLab omnibus. Вам нужно будет изменить команды CLI GitLab, добавив к ним префикс bundle exec rake, если ваш экземпляр был собран из исходного кода.

Создание резервной копии по требованию

Самый простой способ создать резервную копию — использовать команду создания по требованию. Запустите следующую команду в вашей оболочке:

sudo gitlab-backup create

Это работает на GitLab 12.2 и новее. Вместо этого в более старых версиях следует использовать альтернативную версию:

sudo gitlab-rake gitlab:backup:create

Резервная копия будет сохранена в виде tar-архива в каталоге, указанном в файле конфигурации GitLab. При установке Omnibus по умолчанию используется /var/opt/gitlab/backups. Каждому архиву резервных копий присваивается имя с отметкой времени создания и версией GitLab.

Что входит в резервную копию?

Встроенная утилита резервного копирования GitLab экспортирует данные, созданные пользователями в вашем экземпляре GitLab. Это включает в себя все в базе данных GitLab и ваших репозиториях Git на диске.

Восстановление резервной копии восстановит ваши проекты, группы, пользователей, задачи, загруженные вложения файлов и журналы заданий CI/CD. Резервная копия также охватывает веб-сайты GitLab Pages и образы Docker, загруженные в интегрированный реестр контейнеров.

Пакеты, добавленные в реестры пакетов GitLab, не поддерживаются. Вы должны настроить свою установку для сохранения пакетов во внешнем поставщике хранилища объектов, если вам нужно, чтобы их можно было восстановить без ручной перестройки.

Создание расписания резервного копирования

Нет встроенного механизма для определения расписания автоматического резервного копирования. Вы должны настроить свою собственную задачу cron для запуска показанной выше команды резервного копирования.

Запустите sudo crontab -e, чтобы открыть crontab root, затем добавьте в файл следующее содержимое:

0 21 * * * /opt/gitlab/bin/gitlab-backup create CRON=1

Сохраните и закройте файл, чтобы применить изменения crontab. В этом примере новая резервная копия будет создаваться каждый день в 21:00. Установка переменной среды CRON указывает GitLab скрыть отображение хода выполнения резервного копирования, чтобы вы не получали лишние электронные письма cron с выходными данными задания.

При использовании этой задачи «как есть» каждая резервная копия будет храниться бесконечно долго, пока вы не очистите их вручную. Это может быстро занять много места в хранилище, если вы используете активный экземпляр GitLab, содержащий большие проекты.

Необязательный ключ конфигурации позволяет удалять старые архивы как часть сценария создания резервной копии. Откройте файл конфигурации GitLab по адресу /etc/gitlab/gitlab.rb. Найдите backup_keep_time, раскомментируйте строку и установите количество секунд, в течение которых вы хотите хранить каждую резервную копию.

gitlab_rails['backup_keep_time'] = 432000

Здесь резервные копии хранятся пять дней. GitLab будет удалять все подходящие архивы в каталоге резервных копий каждый раз, когда выполняется команда создания резервной копии.

Вам нужно перенастраивать GitLab всякий раз, когда изменяется файл конфигурации. Запустите sudo gitlab-ctl reconfigure, чтобы применить новые настройки.

Исключение типов данных

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

Переменная среды принимает список типов данных, разделенных запятыми. Вы можете найти поддерживаемые в настоящее время параметры в вики GitLab.

Вот как сделать резервную копию всего, кроме образов реестра контейнеров:

sudo gitlab-backup create SKIP=registry

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

Резервное копирование на S3

GitLab может автоматически сохранять ваши резервные копии в S3-совместимых хранилищах объектов. Раскомментируйте строки backup_upload_connection и добавьте данные о вашем подключении:

gitlab_rails['backup_upload_connection'] = {
    "provider" => "AWS",
    "region" => "eu-west-1",
    "aws_access_key_id" => "access_key",
    "aws_secret_access_key" => "secret_key",
    # "endpoint" => "https://..."
}

Добавьте свой собственный ключ доступа, секретный ключ и идентификатор региона AWS, чтобы завершить подключение. Вам также следует установить поле endpoint, если вы подключаетесь к провайдеру, отличному от AWS. Укажите URL-адрес вашего сервера хранилища объектов, чтобы GitLab мог загрузить на него.

Вы также должны установить ключ backup_upload_remote_directory. Найдите эту строку в файле конфигурации, раскомментируйте ее и задайте имя корзины S3 для загрузки резервных копий:

gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups';

Запустите sudo gitlab-ctl reconfigure, чтобы применить изменения.

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

Учтите, что параметр backup_keep_time не поддерживается при использовании хранилища S3. Это относится только к локально хранящимся архивам резервных копий. Вы можете добиться чего-то подобного, используя встроенные политики истечения срока действия S3 для автоматического удаления загрузок по истечении установленного периода времени.

Стратегия резервного копирования

Стратегия резервного копирования GitLab по умолчанию заключается в непрерывной потоковой передаче данных в tar-архив. Обычно это работает хорошо, но может создавать проблемы на очень активных экземплярах GitLab. Данные могут измениться в исходном каталоге до того, как они перейдут в архив, из-за чего tar пропустит их с ошибкой файл изменился при чтении.

Чтобы бороться с этим, GitLab представила необязательную стратегию copy. Это копирует все подходящие данные резервной копии во временный каталог, а затем передает скопированное содержимое в окончательный tar-архив. Это гарантирует, что tar не читает из работающего экземпляра GitLab, но имеет побочный эффект временного увеличения потребления хранилища GitLab. Производительность резервного копирования также может заметно снизиться, особенно на медленных устройствах хранения.

Стратегия copy активируется установкой переменной среды STRATEGY при выполнении команды резервного копирования. Вы должны убедиться, что у вас достаточно свободного места на диске. GitLab будет запускать резервное копирование поэтапно, поэтому вам потребуется только удвоить размер вашего самого большого типа данных. Например, если у вас есть 5 ГБ репозиториев Git и 10 ГБ реестров контейнеров, вам потребуется 10 ГБ дополнительного свободного места, а не 15 ГБ.

sudo gitlab-backup create STRATEGY=copy

Не забудьте: сделайте резервную копию файла конфигурации!

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

  • /etc/gitlab/gitlab.rb — это ваш файл конфигурации GitLab. Все установки, кроме самых основных, со временем претерпевают множество модификаций. Резервное копирование этого файла позволяет перенести его в новую установку GitLab без необходимости начинать с нуля.
  • /etc/gitlab/gitlab-secrets.json — необходимо создать резервную копию этого файла. Он включает в себя ключ шифрования вашей базы данных, секреты, используемые для двухфакторной аутентификации, и другие не подлежащие восстановлению конфиденциальные данные. Потеря этого файла может сделать любые попытки восстановления невозможными, даже если у вас есть работающий резервный архив.

Вы можете использовать другую задачу cron для резервного копирования этих двух файлов. Их следует скопировать с вашего сервера, чтобы вы могли получить к ним доступ, если столкнетесь с аппаратным сбоем.

Заключение

Резервные копии жизненно важны для любого администратора GitLab. Программное обеспечение обычно имеет решающее значение для каждой команды в организации, поэтому любое неожиданное время простоя может вызвать серьезные операционные проблемы.

В GitLab есть все необходимое для регулярного создания резервных копий. Наилучший подход — создать задачу cron, которая запускает встроенный скрипт по регулярному расписанию. Сохраняйте архивы резервных копий во внешнем объектном хранилище для защиты от потери, сбоя или повреждения оборудования. Не забудьте вручную сделать резервную копию файлов конфигурации и секретов GitLab, иначе процесс восстановления будет значительно сложнее.




Все права защищены. © Linux-Console.net • 2019-2024