> For the complete documentation index, see [llms.txt](https://kb.pvhostvm.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.pvhostvm.ru/hostvm-server/rukovodstvo-po-administrirovaniyu/chasto-zadavaemye-voprosy/administrirovanie-hostvm-manager/rezervnoe-kopirovanie-i-avariinoe-vosstanovlenie-bd-hostvm-manager.md). # Резервное копирование и аварийное восстановление БД HOSTVM Manager Данная инструкция описывает процесс создания резервной копии базы данных управляющей машины HOSTVM Manager и её восстановление. Создание резервной копии базы данных является обязательным этапом перед внесением любых изменений в систему. Это обеспечивает возможность безопасного отката к предыдущему рабочему состоянию в случае возникновения ошибок или нештатных ситуаций. {% hint style="warning" %} Критические требования и ограничения 1. На время выполнения операции восстановления базы данных: * Веб-портал HOSTVM Manager будет полностью недоступен; * API и интеграции (включая VDI-сессии) будут недоступны; * Все активные операции (создание снапшотов, клонирование ВМ, миграции, запуск/остановка ВМ) должны быть завершены; * Запрещается запускать новые задачи в период восстановления; * Все пользователи должны быть уведомлены о плановых работах и отключены от системы. 2. Восстановление БД из дампа полностью стирает все данные, добавленные или изменённые в системе после даты создания резервной копии. Это касается: бэкапов ВМ, снапшотов, конфигураций, истории операций и данных data warehouse. 3. Несоблюдение этих требований может привести к: * Повреждению данных ВМ; * Зависанию операций в состоянии "locked"; * Некорректному восстановлению состояния системы; * Потере данных, созданных после момента снимка БД; * Конфликтам при повторной синхронизации хостов/ Решение о восстановлении принимается только после оценки всех рисков и получения согласования от ответственных лиц. {% endhint %} ### Создание дампа базы данных Подключитесь к консоли HOSTVM Manager и выполните команду для создания SQL-дампа текущего состояния базы данных: ``` su - postgres -c "pg_dump engine > /tmp/engine_backup_$(date +%Y%m%d_%H%M%S).sql" ``` Убедитесь, что файл дампа создан успешно: ``` ls -lh /tmp/engine_backup_*.sql ``` Пример вывода: ``` rw-r--r-- 1 postgres postgres 245M Sep 1 12:35 /tmp/engine_backup_20260901_123555.sql ``` {% hint style="warning" %} Скопируйте созданный дамп на внешнее надёжное хранилище, чтобы исключить возможность его потери при сбое ВМ или файловой системы. {% endhint %} ### Восстановление базы данных из дампа {% hint style="warning" %} Перед восстановлением сделайте резервную копию текущей БД — даже если она повреждена, это может пригодиться для диагностики. {% endhint %} Подключитесь по SSH к хосту, на котором запущена ВМ HOSTVM Manager, и выполните включение глобального режима обслуживания: ``` hosted-engine --set-maintenance --mode=global ``` Убедитесь, что режим обслуживания включен: ``` hosted-engine --vm-status ``` Подключитесь по SSH к ВМ HOSTVM Manager и последовательно остановите следующие службы: ``` systemctl stop ovirt-engine-dwhd systemctl stop ovirt-fence-kdump-listener systemctl stop ovirt-imageio systemctl stop ovirt-provider-ovn systemctl stop ovirt-vmconsole-proxy-sshd systemctl stop ovirt-websocket-proxy systemctl stop ovirt-engine ``` Убедитесь, что не осталось работающих служб, связанных с ovirt: ``` systemctl list-units | grep -i ovirt | grep running ``` Команда **не должна** выводить строки. Если службы продолжают работать — остановите их принудительно. Завершите все активные подключения к базе данных `engine`, кроме текущего: ``` su - postgres -c "psql -c \"SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'engine' AND pid <> pg_backend_pid();\"" ``` Убедитесь, что внешние подключения к базе `engine` отсутствуют: ``` su - postgres -c "psql -c \"SELECT count(*) FROM pg_stat_activity WHERE datname = 'engine';\"" ``` При корректном выполнении должно быть `0` (или `1`, если проверка выполняется из самой БД engine). Убедитесь, что файл дампа существует и доступен для чтения: ``` ls -lh /tmp/engine_backup_20260901_123555.sql ``` Вместо указанного примера подставьте фактический путь к вашему файлу дампа и его имя. Удалите существующую базу данных: ``` su - postgres -c "psql -c 'DROP DATABASE IF EXISTS engine;'" ``` Создайте новую базу данных с владельцем engine: ``` su - postgres -c "psql -c 'CREATE DATABASE engine OWNER engine;'" ``` Восстановите базу данных из созданного дампа: ``` su - postgres -c "psql -d engine < /tmp/engine_backup_20260901_123555.sql" ``` Замените путь к файлу дампа и его имя на актуальный. После успешного восстановления БД запустите остановленные службы в указанном порядке: ``` systemctl start ovirt-engine systemctl start ovirt-engine-dwhd systemctl start ovirt-fence-kdump-listener systemctl start ovirt-imageio systemctl start ovirt-provider-ovn systemctl start ovirt-vmconsole-proxy-sshd systemctl start ovirt-websocket-proxy ``` На хосте с ВМ HOSTVM Manager выполните отключение режима обслуживания: ``` hosted-engine --set-maintenance --mode=none ``` Убедитесь, что окружение вышло из режима обслуживания: ``` hosted-engine --vm-status ``` ### Проверка работы HOSTVM Manager после восстановления После завершения процесса восстановления базы данных и запуска всех сервисов необходимо выполнить комплексную проверку работоспособности управляющей платформы HOSTVM Manager. Данный этап является обязательным и позволяет убедиться в корректности выполненного восстановления, а также своевременно выявить возможные проблемы. 1. Откройте веб-браузер и перейдите по адресу административного портала HOSTVM Manager. Авторизуйтесь в системе, используя учётные данные пользователя с правами администратора. Убедитесь, что страница входа и панель управления загружаются без ошибок и задержек. 2. Последовательно перейдите в соответствующие разделы портала и проверьте корректность отображения следующей информации: * Кластеров * Хостов * Виртуальных машин * Хранилищ 3. Для выявления скрытых ошибок, которые могут не проявляться на уровне интерфейса, выполните анализ системных журналов: ``` journalctl -u ovirt-engine -f ```