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

XC_VM поддерживает автоматическое и ручное резервное копирование баз данных с помощью локального хранилища и дополнительной загрузки в Dropbox. Управление резервными копиями осуществляется с помощью панели администратора, команд CLI и задания cron.

Что создается в резервной Копии¶

Резервные копии содержат полную структуру базы данных и данные, кроме следующие таблицы:

detect_restream_logs, epg_data, lines_activity, lines_live,
lines_logs, login_logs, mag_claims, mag_logs, mysql_syslog,
panel_logs, panel_stats, servers_stats, signals,
streams_errors, streams_logs, streams_stats, syskill_log,
users_credits_logs, users_logs, watch_logs

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

Резервные копии включают в себя нет:

Данные файловой системы (записи, VOD-файлы, EPG XML)
Файлы конфигурации (config/)
Двоичные зависимости (bin/)
Временные файлы (tmp/)

Конфигурация¶

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

Установка	По умолчанию	Описание
`automatic_backups`	`off`	частота: `off`, `hourly`, `daily`, `weekly`, `monthly`
`backups_to_keep`	`0`	количество локальных хранилищ (0 = неограниченно)
`dropbox_remote`	`0`	включить загрузку в Dropbox
`dropbox_keep`	`0`	количество удаленных записей (0 = неограниченно)
`dropbox_token`	`''`	Токен API Dropbox

Создание резервных копий¶

Руководство пользователя (панель администратора)¶

Нажмите Создайте резервную копию прямо сейчас на странице резервных копий. При этом задание cron будет запущено в принудительном режиме:

/home/xc_vm/console.php cron:backups 1

Автоматический (cron)¶

Задание cron:backups проверяет расписание при каждом запуске:

График	Интервал
`hourly`	3600 - е годы
`daily`	86400-е годы
`weekly`	604800-е годы
`monthly`	2419200 - е годы

Запускается только на главном сервере (is_main=1). Используется блокировка на основе PID для предотвращения дублирования запусков.

Процесс резервного копирования¶

Закройте соединение с MySQL перед сбросом.
Запустите mysqldump --no-data (структура) + mysqldump --ignore-table (данные, исключая таблицы журнала).
Проверьте размер файла (пустые файлы удаляются).
Если включен Dropbox: загружайте с отслеживанием статуса.
Примените политику хранения (удалите самые старые файлы, превышающие установленный лимит).

Расположение файла¶

/home/xc_vm/backups/backup_YYYY-MM-DD_HH:MM:SS.sql

Восстановление резервных копий¶

Из панели администратора¶

Нажмите Восстанавливать на любой записи резервной копии. Требуется подтверждение.

Процесс:

Если существует локальный файл, используйте его. В противном случае загрузите из Dropbox в /home/xc_vm/tmp/restore.sql.
Удалите базу данных и создайте ее заново.
Импортируйте SQL-файл.
Повторно загрузите структуру после импорта.

BackupService::restore($filename, $config)

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

Из CLI¶

Для сценариев миграции с выборочным импортом таблиц:

sudo /home/xc_vm/console.php tools migration /path/to/backup.sql

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

Удержание¶

Локальное удержание¶

Если backups_to_keep > 0: сохраняются только N самых последних файлов. Сначала удаляются самые старые.
If backups_to_keep = 0: сохраняет все файлы (неограниченно).

Удаленное хранение¶

Если dropbox_keep > 0: сохраняются только N самых последних файлов в Dropbox. Самые старые удаляются первыми.
If dropbox_keep = 0: сохраняет все удаленные файлы (неограниченное количество).

Очистка выполняется автоматически после каждого резервного копирования с помощью BackupsCronJob.

Интеграция с Dropbox¶

Файл: src/Core/Storage/DropboxClient.php

Когда параметр dropbox_remote включен:

После создания локальной резервной копии загрузите ее в Dropbox.
Во время загрузки создается файл маркера .uploading.
В случае успеха: .uploading удаляется.
On failure: .error file is created with the error message.

Индикаторы состояния панели администратора:

Показатель	Значение
Зеленый	успешно загружен
Желтый	текущая загрузка (менее 10 минут назад)
Красный	ошибка загрузки (наведите курсор на сообщение об ошибке)
Серый	не загружен

Методы:

BackupService::checkRemoteConnection()        // validate Dropbox token
BackupService::uploadRemote($path, $filename, $overwrite = true)  // upload backup
BackupService::downloadRemote($path, $filename) // download backup
BackupService::deleteRemote($path)             // delete remote backup
BackupService::getRemote()                     // list remote backups

Команды CLI¶

cron:резервные копии¶

Автоматическое задание cron для резервного копирования. Может быть задано принудительно с аргументом 1:

sudo -u xc_vm /home/xc_vm/console.php cron:backups
sudo -u xc_vm /home/xc_vm/console.php cron:backups 1  # force

миграция инструментов¶

Восстановите резервную копию в базе данных миграции для выборочного импорта:

sudo /home/xc_vm/console.php tools migration /path/to/backup.sql

Резервное копирование всегда выполняется в операторах xc_vm_migrate: USE и CREATE DATABASE в дамп (записанный с помощью mysqldump --databases / --all-databases) опущен, потому что в противном случае mysql восстановился бы в базе данных, которую они называют — live panel, когда это xc_vm — и оставьте xc_vm_migrate пустым. Команда завершается ошибкой, если xc_vm_migrate по-прежнему пуст после восстановления. Затем запустите sudo /home/xc_vm/console.php migrate.

база данных инструментов - подтвердите¶

Сброс в пустую базу данных (уничтожает все данные):

sudo /home/xc_vm/console.php tools database --confirm

инструменты mysql¶

Повторная авторизация подсистем балансировки нагрузки в MySQL:

sudo /home/xc_vm/console.php tools mysql

Конечная точка API¶

Действие: backup (требуется разрешение adv:database)

Вспомогательное действие	Описание
`backup`	запуск немедленного резервного копирования (в фоновом режиме)
`delete`	удалить локальную резервную копию + копию из Dropbox
`restore`	восстановление базы данных из резервной копии

Ключи кластера (ОСНОВНАЯ замена)¶

Резервная копия базы данных не содержит ключей MAIN ключи кластера. Когда включен cluster API, зарегистрированные средства балансировки нагрузки доверяют этим ключам и xcvm_core привязывают их к компьютеру MAIN. Резервная копия, созданная на одном компьютере, не может быть прочитана на другом. Без отдельного экспорта замена аппаратного обеспечения MAIN означает повторную регистрацию каждого узла.

Экспорт (на главном экране, после включения cluster API, и снова, когда захотите):

php console.php cluster:export-keys /root/cluster-keys.xcdr

Вы вводите ключевую фразу дважды; она не повторяется. Для этого требуется более 20 символов или более 12, используя три класса символов. --passphrase-file=<path> вместо этого считывает ее из файла.
Пакет записывается как 0600 и никогда не перезаписывает существующий файл.
Для получения ключа требуется около 1 гигабайта памяти в течение нескольких секунд.
Сохраняйте пакет и кодовую фразу отдельно, и оба они должны быть отключены от основной. Пакет открывается только внутри xcvm_core и только с помощью кодовой фразы.

Импорт (на заменяющем главном сервере, после восстановления базы данных и до повторного подключения любого узла):

php console.php cluster:import-keys /root/cluster-keys.xcdr

Сначала уберите старую МАГИСТРАЛЬ. Две сети, использующие одни и те же ключи, выдают токены независимо, и узел, отозванный на одной из них, остается действительным на другой.
Отозванные узлы остаются отозванными. Импорт не позволяет заменить другой набор ключей, который уже находится на компьютере. Импорт одного и того же пакета дважды ничего не меняет.
Узлы сами повторно подключаются, как только попадают на новый MAIN. Токены, выданные старым MAIN, не открываются на новом компьютере, и агенты заменяют их автоматически.

Никакого свертка: сначала восстановите базу данных. Затем запустите php console.php cluster:init на новой главной, которая создаст новые ключи и запишет, что root изменился. Затем повторно зарегистрируйте каждый узел по SSH с помощью cluster:reenrol:

Запишите SSH-учетные данные узлов в файл, предназначенный только для владельца, в bin/install/. Верхний уровень применяется к каждому узлу; nodes переопределяет его для каждого идентификатора сервера:
```
sudo -u xc_vm sh -c 'umask 077; cat > /home/xc_vm/bin/install/fleet.cred' <<'EOF'
{"u": "root", "p": "root-password",
 "nodes": {"7": {"p": "other-password", "port": 2222, "hostkey": "SHA1:…"}}}
EOF
```

Узлу требуется значение hostkey, если в базе данных для него ничего не указано (узел был установлен до того, как были записаны ключи хоста) или если в базе данных есть старый ключ (с тех пор узел был перестроен). Прочитайте его на узле с помощью ssh-keygen -l -E sha1 -f /etc/ssh/ssh_host_ed25519_key.pub. С узлом, у которого вообще нет ключа, никогда не связываются.

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

Проверьте, что произойдет. Повторный запуск не связывается ни с одним узлом и сохраняет файл:
```
sudo -u xc_vm /home/xc_vm/console.php cluster:reenrol --all --cred-file=/home/xc_vm/bin/install/fleet.cred --dry-run
```
Повторно зарегистрируйте один узел по идентификатору и проверьте, отображается ли он на Серверах → Узлах кластера. Затем повторно зарегистрируйте остальные по идентификатору или с помощью --all (для этого снова используется первый узел). Запуск без --dry-run приводит к удалению файла сразу после запуска, даже если он отказывается запускаться, поэтому перед каждым запуском записывайте файл заново. Файл, который могут прочитать другие пользователи, отклоняется и также удаляется:
```
sudo -u xc_vm /home/xc_vm/console.php cluster:reenrol 7 --cred-file=/home/xc_vm/bin/install/fleet.cred
sudo -u xc_vm /home/xc_vm/console.php cluster:reenrol --all --cred-file=/home/xc_vm/bin/install/fleet.cred
```
--all принимает узлы, которые зарегистрированы или активны. Отозванные узлы и узлы, помещенные на карантин, остаются такими, какие они есть, если только вы не назовете их или не передадите --state=. Узел, который вы отзываете во время выполнения, пропускается, когда выполняется его выполнение.
--all --pending не учитывает узлы, которые активны и были зарегистрированы с момента создания новых ключей cluster:init, поэтому запуск после первого узла или после частичного сбоя выполняется только для остальных. Он отказывает на панели, ключи которой были созданы до того, как это было записано: назовите узлы по их идентификатору.
Одновременно выполняется только один cluster:reenrol, и узел никогда не регистрируется server:enrol и cluster:reenrol одновременно.
В списке узлов, на которых произошел сбой, указывается причина, и запуск продолжается: например, изменен ключ хоста, узел, на котором еще не запущен этот выпуск, или узел, который не может подключиться к кластерному API MAIN. Устраните причину и назовите узел при новом запуске. Агент узла уже был остановлен и получил новые ключи, если запуск дошел до проверки достижимости, поэтому он может не сработать снова до нового запуска.
Отказ в выдаче лицензии останавливает запуск до перехода к следующему узлу.
Каждый повторно зарегистрированный узел запускается заново, как новый узел: в режиме New Node Mode (Настройки → Кластер), который задается при отключении каждого потока. Снова включите его потоки на Серверах → Узлах кластера.
server:enrol по-прежнему повторно регистрирует один узел.

Связанные файлы¶

Файл	Цель
`src/Core/Backup/BackupService.php`	логика резервного копирования/восстановления
`src/Core/Storage/DropboxClient.php`	Клиент Dropbox API
`src/Cli/CronJobs/BackupsCronJob.php`	автоматизированный cron для резервного копирования
`src/Cli/Commands/ToolsCommand.php`	Инструменты миграции командной строки и базы данных
`src/Cli/Commands/ClusterExportKeysCommand.php`, `ClusterImportKeysCommand.php`	экспорт и импорт ключей кластера
`src/Cli/Commands/ClusterReenrolCommand.php`	повторно регистрирует автопарк по SSH после замены основного сервера без ключей
`src/Public/Views/admin/backups.php`	пользовательский интерфейс панели администратора
`src/Public/Views/admin/api.php`	Обработчик конечной точки API
`src/Public/Controllers/Admin/BackupsController.php`	административный контроллер