Перед настройкой службы резервного копирования убедитесь, что у вас есть:
- Экземпляр GitHub Enterprise Server с версией 3.17 или более поздней.
- Выделенный том хранилища, подготовленный и управляемый для использования в качестве целевого объекта резервного копирования.
Требования к системе хранения данных
Чтобы обеспечить надежную и производительность резервных копий, хранилище должно соответствовать следующим требованиям:
-
Емкость. Выделите по крайней мере пять раз объем хранилища, используемого основным диском данных GitHub устройства. Это учитывает исторические моментальные снимки и будущий рост.
-
Поддержка файловой системы: служба резервного копирования использует жесткие ссылки для эффективного хранения, а экземпляр GitHub использует символьные ссылки. Целевой объект резервного копирования должен поддерживать символьные и жесткие ссылки, и он должен использовать файловую систему с учетом регистра, чтобы предотвратить конфликты.
Вы можете проверить, поддерживает ли файловая система символьные ссылки жесткой связи, выполнив следующие действия:
cd /data/backup sudo touch file sudo ln -s file symlink sudo ln symlink hardlink ls -la`ln symlink hardlink` Если команда успешно завершится, файловая система поддерживается. -
Производительность. Используйте высокопроизводительный хранилище с низкой задержкой и высоким числом операций ввода-вывода в секунду, чтобы избежать медленных резервных копий и восстановления.
-
NFS. Избегайте использования подключения NFS для каталога резервного копирования (обычно
/data/backup), так как это может привести к истечении времени ожидания и снижению производительности.
Настройка службы резервного копирования
Можно настроить GitHub Enterprise Server Backup Service с помощью Консоль управления.
Настройка целевого объекта резервного копирования
Перед настройкой службы необходимо подготовить том хранилища, в котором будут храниться резервные копии.
Использование нового блочного устройства
Если вы используете выделенное блочное устройство в качестве целевого объекта резервного копирования, необходимо инициализировать его с помощью SSH, прежде чем продолжить работу в Консоль управления. Этот процесс будет форматировать устройство и удалять все существующие данные.
-
Подключитесь к экземпляру
adminчерез SSH от имени пользователя. См . раздел AUTOTITLE. -
Подключите устройство резервного копирования к экземпляру.
-
Определите имя устройства, используя
lsblkдля перечисления доступных блочных устройств. Убедитесь, что выбрано правильное устройство, чтобы избежать потери данных.lsblk -
Выполните команду инициализации, заменив
YOUR_DEVICE_NAMEфактическое имя устройства, определенное на предыдущем шаге.Предупреждение
Эта команда будет окончательно удалять все данные на указанном устройстве. Перед продолжением дважды проверьте имя устройства и создайте резервную копию всех важных данных.
ghe-storage-init-backup /dev/YOUR_DEVICE_NAMEКоманда:
-
Форматирует устройство (удаляет все данные).
-
Подготавливает его к использованию службой резервного копирования.
-
Устанавливает автоматическое монтирование при
/data/backupзагрузке. -
Если в кластерной среде, настраиваем узел в
cluster.confсbackup-serverроль.
-
Отсоединить резервный диск
Предупреждение
Перед отсоединением резервного диска убедитесь, что в настоящее время не происходит резервное копирование или восстановление. Отсоединение диска во время его работы может привести к потере данных или перерыву сервиса.
Если вам нужно отсоединить резервный диск от GitHub Enterprise Server, пожалуйста, выполните следующие шаги
-
Перечислите блокировку устройств и отключите
/data/backup.sudo lsblk sudo umount /data/backup -
Перечислите логические тома и отключите логический том.
sudo lvs sudo lvchange -an <backup_VG>/<backup_LV> -
Отсоединение диска с помощью консоли или CLI, предоставленного облачным провайдером или гипервизором.
-
Уберите точку крепления.
sudo rmdir /data/backup
Повторное использованием ранее инициализированного диска
Если устройство уже инициализировано с помощью ghe-storage-init-backup, его можно повторно использовать без переформатирования:
-
Подключитесь к экземпляру
adminчерез SSH от имени пользователя. -
Подключите диск к экземпляру.
-
Создайте точку подключения, если она не существует.
sudo mkdir -p /data/backup -
Включите и запустите службу подключения.
sudo systemctl enable ghe-backup-disk.service sudo systemctl start ghe-backup-disk.serviceЭто приведет к подключению устройства
/data/backupи гарантирует автоматическое подключение устройства в будущем.
Настройка параметров резервного копирования
После монтировки целевой резервной копии страница службы резервного копирования станет доступна в разделе Консоль управления. Если ваш экземпляр является частью кластерной среды, страница Backup Service будет доступна после ghe-config-apply.
Примечание.
Страница настроек появится, пока резервное хранилище не будет смонтировано /data/backup после выполнения вышеуказанных шагов инициализации или крепления.
При миграции из GitHub Enterprise Server Backup Utilitiesможно перенести конфигурацию одним из двух способов:
-
**Настройка** вручную. Повторно создайте параметры непосредственно в Консоль управления. -
**Миграция** командной строки: SSH в экземпляр, скопируйте `backup.config` файл из backup-utils и выполните следующую команду:ghe-migrate-backup-config /path/to/your/backup.configИспользуйте флаг для предварительного
--dry-runпросмотра изменений, не применяя их.
Возьми запасной вариант
После настройки сервиса вы можете сделать резервную копию вручную, выполнив следующие шаги:
- В Консоль управленияоткройте вкладку "Резервные копии" в верхнем меню.
-
**Нажмите «Резервная копия сейчас**».
Будет сделана резервная копия GitHub Enterprise Server и отображаться в списке.
Планирование автоматических резервных копий
После настройки службы можно определить расписание резервного копирования.
- В разделе Консоль управления откройте вкладку «Настройки» в верхнем меню.
- В разделе «Резервное копирование» выберите заранее определённое расписание (например, ежедневное) или введите пользовательское выражение cron.
- Нажмите «Сохранить настройки », чтобы применить изменения.
Первый запуск будет полной резервной копией. Будущие запуски будут добавочными. Если новая попытка резервного копирования начинается во время выполнения предыдущей, она может быть пропущена или не выполнена. В этом случае настройте расписание, чтобы избежать перекрытия.