Настройка резервных копий на устройстве

Сведения о 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, необходима система узла Linux или Unix, отдельная от экземпляр GitHub Enterprise Server.

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

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

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

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

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

Дополнительные сведения см. в Требованиях проекта "GitHub Enterprise Server Backup Utilities" в документации проекта "GitHub Enterprise Server Backup Utilities".

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

Чтобы установить GitHub Enterprise Server Backup Utilities на узле резервного копирования, рекомендуем клонировать Git-репозиторий проекта. Этот подход позволит получать новые выпуски напрямую через Git, а существующий файл конфигурации резервного копирования 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" в локальный каталог на узле резервного копирования, выполните следующую команду.
```
$ git clone https://github.com/github/backup-utils.git /path/to/target/directory/backup-utils
```
Чтобы перейти в локальный каталог репозитория, выполните следующую команду.
```
cd backup-utils
```
Чтобы обновить версию проекта до последнего выпуска, используйте ветвь stable, выполнив команду git checkout stable.
```
git checkout stable
```
А если необходимо использовать конкретную версию проекта, выполните следующую команду, заменив X.Y.Z на нужную версию выпуска.
```
$ git checkout vX.Y.Z
```
Чтобы скопировать включенный файл backup.config-example в backup.config, выполните следующую команду.
```
cp backup.config-example backup.config
```
Для изменения конфигурации отредактируйте файл backup.config в текстовом редакторе.
1. Задайте значение GHE_HOSTNAME для имени узла или IP-адреса основного экземпляра GitHub Enterprise Server.
  
  Примечание: Если экземпляр GitHub Enterprise Server развертывается как кластер или в конфигурации с высоким уровнем доступности с помощью подсистемы балансировки нагрузки, GHE_HOSTNAME может быть именем узла подсистемы балансировки нагрузки, если он разрешает доступ по протоколу SSH (через порт 122) к экземпляр GitHub Enterprise Server.
  
  Чтобы обеспечить немедленную доступность восстановленного устройства, создавайте резервные копии, предназначенные для основного экземпляра, даже в конфигурации георепликации.
2. Задайте для расположения файловой системы, в котором вы хотите хранить моментальные снимки резервных копий, значение GHE_DATA_DIR. Рекомендуется выбрать расположение в той же файловой системе, что и у узла резервного копирования, но не там, где вы клонировали Git-репозиторий на шаге 1.
Чтобы предоставить узлу резервного копирования доступ к экземпляру, откройте страницу параметров основного экземпляра http(s)://HOSTNAME/setup/settings и добавьте ключ SSH узла в список авторизованных ключей SSH. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
На узле резервного копирования проверьте подключение по протоколу ghe-host-check SSH с помощью экземпляр GitHub Enterprise Server с помощью команды .
```
./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 можно обновить в репозитории Git, получив последние изменения.

Если же вы не используете для своей установки Git-репозиторий, вы можете извлечь на ее место новый архив либо изменить свой подход и начать использовать Git.

Проверка типа установки

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

На узле резервного копирования перейдите к каталогу, где установлены GitHub Enterprise Server Backup Utilities (как правило, backup-utils).
Чтобы проверить, существует ли действительный рабочий каталог в Git-репозитории, выполните следующую команду.
```
git rev-parse --is-inside-work-tree
```
Если выводится значение true, то GitHub Enterprise Server Backup Utilities были установлены путем клонирования Git-репозитория проекта. Если выводится значение fatal: not a git repository (or any of the parent directories), то GitHub Enterprise Server Backup Utilities, скорее всего, были установлены путем извлечения сжатого файла архива. Если установка находится в репозитории Git, вы можете установить последнюю версию с помощью Git. Если установка выполнялась из сжатого архивного файла, вы можете скачать и извлечь последнюю версию либо переустановить GitHub Enterprise Server Backup Utilities с помощью Git для упрощения будущих обновлений.

Обновление установки в репозитории Git
Использование Git для обновлений вместо сжатых архивов

Обновление установки в репозитории Git

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

Примечание. Рекомендуется скопировать существующий файл backup.config во временное расположение, например $HOME/backup.config, прежде чем обновлять GitHub Enterprise Server Backup Utilities.
Скачайте последние обновления проекта, выполнив команду git fetch.
```
git fetch
```
Чтобы обновить версию проекта до последнего выпуска, используйте ветвь stable, выполнив команду git checkout stable.
```
git checkout stable
```
А если необходимо использовать конкретную версию проекта, выполните следующую команду, заменив X.Y.Z на нужную версию выпуска.
```
$ git checkout vX.Y.Z
```
1. Для проверки, что обновление установлено, выполните следующую команду.
```
./bin/ghe-backup --version
```
Чтобы проверить SSH-подключение настроенных продуктов GitHub Enterprise Server, выполните следующую команду.
```
./bin/ghe-host-check
```

Использование Git для обновлений вместо сжатых архивов

Если узел резервного копирования подключен к Интернету и ранее вы использовали сжатый архив (.tar.gz), чтобы установить или обновить GitHub Enterprise Server Backup Utilities, рекомендуется вместо него использовать для установки репозиторий Git. Обновление с помощью Git выполняется проще и сохраняет текущую конфигурацию резервного копирования.

На узле резервного копирования перейдите к каталогу, где установлены GitHub Enterprise Server Backup Utilities (как правило, backup-utils).
GitHub Enterprise Server Backup Utilities имеют существующую конфигурацию, для создания резервной копии которой скопируйте текущий файл backup.config в безопасное расположение, например в домашний каталог.
```
$ cp backup.config $HOME/backup.config.saved-$(date +%Y%m%d-%H%M%S)
```
Перейдите в локальный каталог на узле резервного копирования, где требуется установить GitHub Enterprise Server Backup Utilities в виде Git-репозитория.
Чтобы клонировать репозиторий проекта в каталог на узле резервного копирования, выполните следующую команду.
```
git clone https://github.com/github/backup-utils.git
```
Чтобы перейти в клонированный репозиторий, выполните следующую команду.
```
cd backup-utils
```
Чтобы обновить версию проекта до последнего выпуска, используйте ветвь stable, выполнив команду git checkout stable.
```
git checkout stable
```
А если необходимо использовать конкретную версию проекта, выполните следующую команду, заменив X.Y.Z на нужную версию выпуска.
```
$ git checkout vX.Y.Z
```
Чтобы восстановить конфигурацию резервного копирования из более ранней версии, скопируйте существующий файл конфигурации в локальный каталог репозитория. Замените путь в команде на расположение файла, сохраненного в шаге 2.
```
$ cp PATH/TO/BACKUP/FROM/STEP/2 backup.config
```
Примечание. Вы можете выбрать, куда восстановить файл конфигурации резервного копирования после клонирования. Дополнительные сведения о возможном расположении файлов конфигурации см. в разделе Начало работы в документации проекта "GitHub Enterprise Server Backup Utilities".
Чтобы проверить правильность путей к каталогам или скриптам в файле конфигурации резервного копирования, просмотрите файл в текстовом редакторе.
Для проверки, что обновление установлено, выполните следующую команду.
```
./bin/ghe-backup --version
```
Чтобы проверить SSH-подключение настроенных продуктов GitHub Enterprise Server, выполните следующую команду.
```
./bin/ghe-host-check
```
Удалите старый каталог служебных программ резервного копирования GitHub Enterprise Server из шага 1 (где находилась установка из сжатого архива).

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

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

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

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

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

Примечание. Перед восстановлением из резервной копии убедитесь в следующем:

На основном экземпляре включен режим обслуживания и завершены все активные процессы. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.
На всех репликах в конфигурациях с высоким уровнем доступности остановлена репликация. Дополнительные сведения см. в команде ghe-repl-stop в разделе "Сведения о настройке высокого уровня доступности".
Если экземпляр GitHub Enterprise Server включено GitHub Actions, необходимо сначала настроить внешний поставщик хранилища GitHub Actions на заменяющем устройстве. Дополнительные сведения см. в разделе Резервное копирование и восстановление сервера GitHub Enterprise с включенным GitHub Actions.

При выполнении команды 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-адресов. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.

Примечание.

Параметры сети исключаются из моментального снимка резервной копии. Вы должны вручную настроить сеть на целевом устройстве GitHub Enterprise Server в соответствии с требованиями для вашей среды.
При восстановлении на новые диски на существующем или пустом экземпляре GitHub Enterprise Server могут присутствовать устаревшие идентификаторы UUID, в результате чего Git и (или) Alambic репликации отчеты не синхронизированы. Устаревшие идентификаторы записей сервера могут быть результатом того, что устаревший узел в конфигурации высокой доступности по-прежнему присутствует в базе данных приложения, но не в восстановленной конфигурации репликации. Чтобы устранить неполадки, устаревшие идентификаторы UUID можно сносить с помощью ghe-repl-teardown после завершения восстановления и до начала репликации. В этом сценарии обратитесь за помощью в Поддержка GitHub Enterprise.

С командой ghe-restore можно использовать следующие дополнительные параметры.

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

Настройка резервных копий на устройстве

В этой статье