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

В рамках плана аварийного восстановления вы можете защитить производственные ваш экземпляр GitHub Enterprise Server данные, настроив автоматизированные резервные копии.

В этой статье

О вариантах резервного копирования GitHub Enterprise Server

GitHub предлагает два варианта резервного копирования вашего GitHub Enterprise Server экземпляра:

  • GitHub Enterprise Server Backup Utilities: Открытая система резервного копирования, которую вы устанавливаете на отдельный хост. Дополнительные сведения см. в разделе ниже.
  • GitHub Enterprise Server Backup Service (в Публичный предварительный просмотр): Управляемая служба резервного копирования, доступная в GitHub Enterprise Server. См . раздел AUTOTITLE.

Около GitHub Enterprise Server Backup Utilities

GitHub Enterprise Server Backup Utilities это система резервного копирования, которую вы устанавливаете на отдельном хосте, которая регулярно делает резервные снимки ваш экземпляр GitHub Enterprise Server через защищённое SSH-сетевое соединение. Вы можете использовать снимок для восстановления существующего GitHub Enterprise Server экземпляра в предыдущее состояние с резервного хоста.

Передаваться по сети и занимать дополнительное физическое пространство на диске будут только данные, добавленные с момента последнего моментального снимка. Чтобы свести к минимуму влияние на производительность, резервное копирование выполняется в режиме онлайн с минимальным приоритетом ЦП и ввода-вывода. Для выполнения резервного копирования не нужно планировать период обслуживания.

Основные релизы и номера версий для GitHub Enterprise Server Backup Utilities совпадают с полнометражными релизами GitHub Enterprise Server. Мы поддерживаем четыре последние версии обоих продуктов. Дополнительные сведения см. в разделе Релизы GitHub Enterprise Server.

Для более подробной информации о функциях, требованиях и расширенном использовании см. GitHub Enterprise Server Backup Utilities README в документации GitHub Enterprise Server Backup Utilities проекта.

Необходимые компоненты

Чтобы использовать GitHub Enterprise Server Backup Utilities, необходимо иметь отдельную систему хоста от ваш экземпляр GitHub Enterprise Server. Дополнительные сведения о том, как должна быть настроена система, см. в разделе "Требования " в репозитории github/backup-utils.

Вы также можете интегрироваться GitHub Enterprise Server Backup Utilities в существующую среду для долгосрочного постоянного хранения критически важных данных.

Мы рекомендуем, чтобы резервный хост и ваш экземпляр GitHub Enterprise Server размещались географически далеко друг от друга. Это гарантирует, что резервные копии будут доступны для восстановления в случае крупной аварии или сбоя сети на первичном сайте.

Требования к физическому хранилищу зависят от использования диска репозитория Git и ожидаемых шаблонов роста.

ОборудованиеРекомендация
Число виртуальных ЦП4
Память8 ГБ
ХранениеВ пять раз больше выделенного хранилище основного экземпляра

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

Для получения дополнительной информации см. GitHub Enterprise Server Backup Utilities требования в GitHub Enterprise Server Backup Utilities документации проекта.

Установка GitHub Enterprise Server Backup Utilities

Чтобы установить GitHub Enterprise Server Backup Utilities на ваш резервный хост, скачайте последнюю версию GitHub Enterprise Server Backup Utilities из репозитория github/backup-utils , совместимую с вашей версией GitHub Enterprise Server. Например, если у вас установлена версия 3.8.4 GitHub Enterprise Server, скачайте последнюю версию GitHub Enterprise Server Backup Utilities серии 3.10. Это возможно, потому что все версии GitHub Enterprise Server Backup Utilities совместимы с обратной совместимостью для двух версий, то есть GitHub Enterprise Server Backup Utilities серия 3.10 может использоваться для резервного копирования и восстановления GitHub Enterprise Server экземпляров версий 3.8, 3.9 или 3.10.

После скачивания сжатого архива можно извлечь и установить содержимое. Дополнительные сведения см. в статье "Начало работы " в репозитории github/backup-utils.

Если у вас уже есть файл конфигурации резервной копии, backup.configубедитесь, что вы скопировали его в расположение недавно распакованной и установленной версии GitHub Enterprise Server Backup Utilities.

Резервные снимки, созданные компанией GitHub Enterprise Server Backup Utilities , записываются на путь диска, заданный GHE_DATA_DIR переменной каталога данных в вашем backup.config файле. Эти моментальные снимки должны храниться в файловой системе, которая поддерживает символьные и жесткие ссылки.

Примечание.

Мы рекомендуем убедиться, что ваши снимки не хранятся в подкаталоге GitHub Enterprise Server Backup Utilities установочной папки, чтобы не перезаписывать папку данных при обновлении GitHub Enterprise Server Backup Utilities версий.

  1. Скачайте соответствующий GitHub Enterprise Server Backup Utilities релиз со страницы релизов в репозитории github/backup-utils.

  2. Чтобы извлечь репозиторий с помощью tar, выполните следующую команду.

    tar -xzvf /path/to/github-backup-utils-vMAJOR.MINOR.PATCH.tar.gz

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

    cd backup-utils

  4. Чтобы скопировать включенный файл backup.config-example в backup.config, выполните следующую команду.

    cp backup.config-example backup.config

  5. Для изменения конфигурации отредактируйте файл backup.config в текстовом редакторе.

    1. Если вы уже обновляли GitHub Enterprise Server Backup Utilities с помощью Git, убедитесь, что скопировали существующую конфигурацию backup.config в новый файл. Для получения дополнительной информации см. раздел Upgrading GitHub Enterprise Server Backup Utilities.

    2. Установите GHE_HOSTNAME значение на имя хоста или IP-адрес вашего основного GitHub Enterprise Server экземпляра.

      Примечание.

      Если ваш экземпляр GitHub Enterprise Server развернут как кластер или в конфигурации с высокой доступностью с использованием балансировщика нагрузки, то GHE_HOSTNAME это может быть имя хоста балансировщика нагрузки, при условии, что балансировщик позволяет SSH доступ через порт 122 к ваш экземпляр GitHub Enterprise Server.

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

    3. Задайте для расположения файловой системы, в котором вы хотите хранить моментальные снимки резервных копий, значение GHE_DATA_DIR. Рекомендуется выбрать расположение в той же файловой системе, что и узел резервного копирования.

  6. Чтобы предоставить узлу резервного копирования доступ к экземпляру, откройте страницу параметров основного экземпляра http(s)://HOSTNAME/setup/settings и добавьте ключ SSH узла в список авторизованных ключей SSH. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

  7. На вашем резервном хосте проверьте SSH-соединение ваш экземпляр GitHub Enterprise Server с помощью команды ghe-host-check .

    ./bin/ghe-host-check

  8. Чтобы создать начальную полную резервную копию, выполните следующую команду.

    ./bin/ghe-backup

Для получения дополнительной информации о расширенном использовании см. GitHub Enterprise Server Backup Utilities README в документации GitHub Enterprise Server Backup Utilities проекта.

Модернизация GitHub Enterprise Server Backup Utilities

При обновлении GitHub Enterprise Server Backup Utilitiesвы должны выбрать версию, которая будет работать с вашей текущей версией GitHub Enterprise Server. Ваша установка GitHub Enterprise Server Backup Utilities должна быть как минимум той же версии, что ваш экземпляр GitHub Enterprise Serverи , и не должна быть более чем на две версии впереди. Для получения дополнительной информации смотрите GitHub Enterprise Server требования к версиям в GitHub Enterprise Server Backup Utilities документации проекта.

  1. Проверьте способ установки для GitHub Enterprise Server Backup Utilities. Ранее поддерживались версии GitHub Enterprise Server Backup Utilities установки и обновлений в локальном репозитории Git, но этот метод больше не поддерживается.

    1. На узле резервного копирования перейдите к каталогу, где установлены GitHub Enterprise Server Backup Utilities (как правило, backup-utils).

    2. Чтобы проверить, существует ли действительный рабочий каталог в Git-репозитории, выполните следующую команду.

      git rev-parse --is-inside-work-tree

  2. Чтобы определить, как улучшить GitHub Enterprise Server Backup Utilities, просмотрите выход из git rev-parse --is-inside-work-tree.

    • Если выход — true, GitHub Enterprise Server Backup Utilities был установлен путём клонирования Git-репозитория проекта. Чтобы обновиться, скопируйте существующую конфигурацию , backup.configзатем следуйте инструкциям в разделе Установка GitHub Enterprise Server Backup Utilities.
    • Если выход включает fatal: not a git repository (or any of the parent directories), GitHub Enterprise Server Backup Utilities был извлечен из сжатого архивного файла. Чтобы обновиться, следуйте инструкциям в разделе Установка GitHub Enterprise Server Backup Utilities.

Планирование резервного копирования

Вы можете запланировать регулярное резервное копирование на узле резервного копирования с помощью команды cron(8) или аналогичной службы планирования команд. Настроенная частота резервного копирования будет определять целевую точку восстановления (RPO) для наихудшего случая в вашем плане восстановления. Например, если вы запланировали выполнение резервного копирования каждый день в полночь, то в случае аварии можете потерять до 24 часов данных. Рекомендуется начать с почасового расписания резервного копирования, что в худшем случае обеспечивает потерю не более одного часа данных при уничтожении данных первичного сайта.

Если попытки резервного копирования перекрываются, команда ghe-backup прерывается с сообщением об ошибке, указывающим на существование одновременного резервного копирования. В этом случае рекомендуется уменьшить частоту запланированных резервных копирований. Для получения дополнительной информации см. раздел «Планирование резервных копий» вGitHub Enterprise Server Backup Utilities README в документации GitHub Enterprise Server Backup Utilities проекта.

Восстановление резервной копии.

В случае длительного сбоя или катастрофического события на основном сайте вы можете восстановить ваш экземпляр GitHub Enterprise Server устройство, создав другой экземпляр и выполнив восстановление с резервного хоста. Перед восстановлением экземпляра необходимо добавить SSH-ключ резервного хоста в целевой GitHub Enterprise экземпляр как авторизованный SSH-ключ.

При восстановлении резервных копий в ваш экземпляр GitHub Enterprise Server, вы можете восстановить данные максимум из двух релизов функций позади. Например, если вы сделаете резервную копию с GitHub Enterprise Server 3.0.x, вы сможете восстановить резервную копию на экземпляр с 3.2.x GitHub Enterprise Server . Вы не можете восстановить данные с резервной копии GitHub Enterprise Server 2.22.x на экземпляр с 3.2.x, потому что это будет три перехода между версиями (с 2.22 на 3.0, затем с 3.1 к 3.2). Необходимо было бы сначала выполнить восстановление в экземпляр с версией 3.1.x, а затем обновление до версии 3.2.x.

Параметры сети исключены из моментального снимка резервного копирования. После восстановления необходимо вручную настроить сеть на целевой GitHub Enterprise Server экземпляре.

Необходимые компоненты

  1. Убедитесь, что режим обслуживания включен в основном экземпляре и все активные процессы завершены. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.
  2. Остановите репликацию на всех узлах реплики в конфигурации высокой доступности. Дополнительные сведения см. в разделе Сведения о настройке высокого уровня доступности.
  3. Создайте новый GitHub Enterprise Server экземпляр для восстановления резервной копии. Дополнительные сведения см. в разделе Настройка экземпляра GitHub Enterprise Server.
  4. Если ваш экземпляр GitHub Enterprise Server включено GitHub Actions , необходимо настроить внешний поставщик хранилища для GitHub Actions замены экземпляра. Дополнительные сведения см. в разделе Резервное копирование и восстановление GitHub Enterprise Server с включённым GitHub Actions.

Запуск операции восстановления

Чтобы восстановить ваш экземпляр GitHub Enterprise Server данные с вашего резервного хоста, используя последний успешный снимок, используйте ghe-restore команду. С помощью следующих дополнительных параметров можно использовать следующие параметры ghe-restore.

  • Флаг -c перезаписывает параметры, сертификаты и данные лицензии на целевом узле, даже если он уже настроен. Не указывайте этот флаг, если вы настраиваете промежуточный экземпляр в целях тестирования и хотите сохранить существующую конфигурацию на целевом объекте. Для дополнительной информации смотрите раздел «Использование команд резервного копирования и восстановления» вGitHub Enterprise Server Backup Utilities README в репозитории github/backup-utils.
  • Флаг -s позволяет выбрать другой моментальный снимок резервной копии.

После выполнения ghe-restoreкоманда подтверждает восстановление, а затем выводит сведения и состояние во время операции.

$ ghe-restore -c 169.154.1.1
> Checking for leaked keys in the backup snapshot that is being restored ...
> * No leaked keys found
> Connect 169.154.1.1:122 OK (v2.9.0)

> WARNING: All data on GitHub Enterprise appliance 169.154.1.1 (v2.9.0)
>          will be overwritten with data from snapshot 20170329T150710.
> Please verify that this is the correct restore host before continuing.
> Type 'yes' to continue: yes

> Starting restore of 169.154.1.1:122 from snapshot 20170329T150710
# ...output truncated
> Completed restore of 169.154.1.1:122 from snapshot 20170329T150710
> Visit https://169.154.1.1/setup/settings to review appliance configuration.

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

В экземпляре в конфигурации высокой доступности после восстановления на новых дисках в существующем или пустом экземпляре ghe-repl-status может сообщить, что репликация Git или Alambic не синхронизирована из-за устаревших UUID сервера. Эти устаревшие идентификаторы UUID могут быть результатом отставного узла в конфигурации высокой доступности, которые по-прежнему присутствуют в базе данных приложения, но не в восстановленной конфигурации репликации.

Чтобы устранить проблему после завершения восстановления и перед началом репликации, можно отключить устаревшие UUID с помощью ghe-repl-teardown. Если вам нужна дополнительная помощь, посетите Поддержка GitHub Enterprise.

Мониторинг хода выполнения резервного копирования или восстановления

Во время операции резервного копирования или восстановления можно использовать ghe-backup-progress служебную программу на узле резервного копирования для мониторинга хода выполнения операции. Программа печатает ход выполнения каждого задания последовательно.

Для мониторинга прогресса на резервном хосте из каталога, содержащего GitHub Enterprise Server Backup Utilities, выполните следующую команду.

Shell
bin/ghe-backup-progress

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

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

Shell
bin/ghe-backup-progress --once