Перед обновлением домашнего Proxmox я проверял резервные копии виртуальных машин. Архивы были созданы, задания завершились успешно. Но перед изменением гипервизора мне хотелось получить более конкретный ответ: смогу ли я запустить систему из сохранённой копии?
Поэтому подготовка включала два этапа: полную проверку архивов и пробное восстановление одной виртуальной машины. Во время проверки я отдельно следил за тем, чтобы восстановленная копия не вмешалась в работу домашней сети.
Наличие файла — только начало
Архив с подходящей датой и ожидаемым размером выглядит убедительно. Однако просмотр каталога не показывает, удастся ли прочитать файл целиком.
Перед обновлением я проверил пять архивов ВМ. Это были резервные копии в формате VMA, сжатые Zstandard. Проверка последовательно распаковывала данные и передавала их утилите проверки VMA:
zstd -dc → vma verifyЗдесь показана схема обработки, а не готовая команда: конкретный запуск зависит от имени архива и параметров утилит.
Все пять архивов прошли полную проверку. Это подтвердило, что сохранённые файлы читаются и проходят проверку формата. Но гостевые системы на этом этапе я ещё не запускал.
Одну машину я восстановил отдельно
Для пробного восстановления я выбрал виртуальную машину с контроллером домашней сети.
Копию восстановил под отдельным временным идентификатором. Рабочую ВМ не заменял и не останавливал ради этого теста. В Proxmox для восстановления резервных копий QEMU используется qmrestore; параметры описаны в официальной документации.
Перед первым запуском временной машины я удалил из её конфигурации сетевой адаптер и отключил автоматический запуск вместе с хостом.
Для этого теста мне требовалось проверить загрузку системы и состояние службы приложения. Подключение копии к рабочей сети для такой проверки было лишним.
Зачем я отключил сеть
Восстановленная машина содержит настройки исходной системы. Если запустить её без подготовки, в домашней сети может появиться второй экземпляр того же сервиса с сохранёнными сетевыми параметрами.
Особенно внимательно я отношусь к таким проверкам, когда приложение управляет другими устройствами. Мне не нужно, чтобы тестовая копия контроллера пыталась участвовать в управлении сетью.
Поэтому в этом случае я выбрал простую изоляцию: у временной ВМ вообще не было сетевого адаптера.
Это ограничивало глубину проверки. Я не мог открыть её веб-панель по сети или проверить взаимодействие с устройствами. Зато мог проверить запуск, сохраняя рабочее окружение отдельно от тестового.
Что удалось проверить без сетевого подключения
После запуска я получил состояние гостевой системы через QEMU Guest Agent — канал взаимодействия между гипервизором и гостевой ОС.
Проверка подтвердила три результата:
- гостевая операционная система загрузилась;
- служба контроллера находилась в активном состоянии;
- внутри гостевой системы оставался только интерфейс loopback.
Последний пункт подтверждал выбранную изоляцию. Активная служба показывала, что приложение смогло запуститься после восстановления.
При этом я не проверял все функции контроллера, его веб-интерфейс и связь с оборудованием. Было бы неправильно называть такой тест полной проверкой работоспособности сервиса.
Для следующего уровня проверки понадобилось бы отдельное тестовое сетевое окружение.
После теста я удалил временную ВМ
Когда проверка завершилась, я штатно выключил восстановленную машину и удалил её. Исходная рабочая ВМ осталась без изменений.
Отключённый автозапуск был дополнительной мерой на время теста: временная копия не должна была неожиданно подняться после перезагрузки хоста.
Для меня завершённая проверка — это ещё и понятное состояние после неё. Тестовая машина не должна оставаться забытым экземпляром, назначение которого придётся вспоминать через несколько недель.
Где результат проверки заканчивается
Пять архивов прошли проверку целостности, но пробное восстановление я выполнил только для одной ВМ.
Поэтому результат я разделяю так:
| Проверка | Что я подтвердил |
|---|---|
| Полное чтение и проверка пяти архивов | Архивы читаются и проходят проверку формата |
| Восстановление одной ВМ | Из выбранной копии удалось создать временную машину |
| Загрузка гостевой ОС | Восстановленная система запускается |
| Проверка службы | Приложение запускается внутри гостевой системы |
Из этого не следует, что остальные четыре ВМ тоже прошли проверку запуском. Не следует и то, что у восстановленного приложения проверены все функции.
Такое разделение помогает мне понимать, на какие результаты я действительно могу опереться перед изменениями.
Копия на том же сервере не решает все задачи
На момент подготовки архивы хранились на самом хосте. Они давали возможность восстановления при некоторых проблемах обновления, пока сервер и хранилище оставались доступны.
Но потерю всего хоста или хранилища такое размещение не покрывало. Независимой внешней копией эти архивы я не считаю.
Также отдельно я сохранил конфигурацию гипервизора. Архив виртуальной машины не заменяет настройки самого хоста: после серьёзного сбоя могут понадобиться и гостевые системы, и возможность заново собрать окружение для их запуска.
Что дала эта проверка
Перед обновлением у меня было подтверждение успешного создания резервных копий. После проверки появилось больше информации: пять архивов полностью прочитаны, а из одного удалось восстановить и запустить гостевую систему со службой приложения.
Проверка не закрыла все возможные сценарии восстановления. Но она заменила предположение «копия должна работать» конкретным результатом.
Теперь, оценивая резервное копирование, я задаю себе следующий вопрос: что именно я уже проверил — создание архива, его чтение, загрузку системы или работу нужного сервиса? От ответа зависит, насколько уверенно я могу рассчитывать на эту копию.