Настройка резервных копий в экземпляре

Сведения о 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" в документации проекта "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 являются обратно совместимыми для 2 версий, то есть для резервного копирования и восстановления экземпляров 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 обновляют версию.

Скачайте соответствующий выпуск GitHub Enterprise Server Backup Utilities на странице выпусков репозитория github/backup-utils.
Чтобы извлечь репозиторий с помощью tar, выполните следующую команду.
```
tar -xzvf /path/to/github-backup-utils-vMAJOR.MINOR.PATCH.tar.gz
```
Чтобы перейти в локальный каталог репозитория, выполните следующую команду.
```
cd backup-utils
```
Чтобы скопировать включенный файл backup.config-example в backup.config, выполните следующую команду.
```
cp backup.config-example backup.config
```
Для изменения конфигурации отредактируйте файл backup.config в текстовом редакторе.
1. Если вы ранее обновили GitHub Enterprise Server Backup Utilities с помощью Git, убедитесь, что вы скопируйте существующую конфигурацию из backup.config нового файла. Дополнительные сведения см. в разделе "Обновление 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. Рекомендуется выбрать расположение в той же файловой системе, что и узел резервного копирования.
Чтобы предоставить узлу резервного копирования доступ к экземпляру, откройте страницу параметров основного экземпляра http(s)://HOSTNAME/setup/settings и добавьте ключ SSH узла в список авторизованных ключей SSH. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
На узле резервного копирования проверьте подключение SSH с помощью команды ваш экземпляр GitHub Enterprise Server .ghe-host-check
```
./bin/ghe-host-check
```
Чтобы создать начальную полную резервную копию, выполните следующую команду.
```
./bin/ghe-backup
```

Подробнее о расширенном использовании см. в файле сведений проекта "GitHub Enterprise Server Backup Utilities" в документации проекта "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".

Проверьте метод установки для 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
```
Чтобы определить, как обновить 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" из документации проекта "GitHub Enterprise Server Backup Utilities".

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

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

При восстановлении резервных копий до ваш экземпляр GitHub Enterprise Serverможно восстановить данные только из двух выпусков компонентов. Например, при резервном копировании из GitHub Enterprise Server 3.0.x можно восстановить резервную копию в экземпляре, на котором выполняется GitHub Enterprise Server 3.2.x. Восстановить данные из резервной копии 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.

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

Убедитесь, что режим обслуживания включен в основном экземпляре и все активные процессы завершены. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.
Остановите репликацию на всех узлах реплики в конфигурации высокой доступности. Дополнительные сведения см. в разделе Сведения о настройке высокого уровня доступности.
Подготовьте новый экземпляр GitHub Enterprise Server для использования в качестве целевого объекта для восстановления резервной копии. Дополнительные сведения см. в разделе Настройка экземпляра GitHub Enterprise Server.
Если в ваш экземпляр GitHub Enterprise Server включен GitHub Actions, необходимо настроить внешний поставщик хранилища для GitHub Actions в экземпляре замены. Дополнительные сведения см. в разделе Резервное копирование и восстановление сервера GitHub Enterprise с включенным 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

bin/ghe-backup-progress

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

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

Shell

bin/ghe-backup-progress --once

bin/ghe-backup-progress --once

Настройка резервных копий в экземпляре

В этой статье