Резервные копии виртуальных машин Proxmox: расписание по шагам

Зачем и для кого

Резервные копии виртуальных машин Proxmox лучше запускать по расписанию, а не помнить о них каждый раз. Согласно Proxmox VE: Backup and Restore (vzdump), задания копирования выполняются автоматически в заданные дни и время для выбранных узлов и гостевых систем. Ниже: как это настроить и проверить.

Инструкция касается компаний, которые держат собственные серверы на Proxmox VE: файловые серверы, терминальные серверы, серверы приложений, внутренние сервисы. Ориентируемся на документацию версии 9.2.13. Если ваши машины работают на Hyper-V или VMware либо в облаке, где копиями занимается провайдер, этот текст вам не нужен. Он также не заменяет копии внутри приложений: для базы 1С/BAS отдельные правила описаны в статье о резервных копиях 1С/BAS на MS SQL.

Для бизнеса последствия обычно будничные. Выходит из строя диск, неудачное обновление ломает систему в машине, кто-то удаляет не ту ВМ, а после внезапного отключения света сервер не стартует. Копия, которую нужно запускать вручную, зависит от того, вспомнил ли о ней конкретный человек. Расписание убирает этот фактор.

Приоритет такой. Если ни одного задания по расписанию ещё нет, настройте его на этой неделе, а для машин с учётом или базами запустите одну копию вручную уже сегодня. Если расписание есть, проверку из этой статьи достаточно проводить при плановом обслуживании.

Что понадобится

Нужен доступ администратора к узлу Proxmox VE, отдельное хранилище для копий и окно времени, когда нагрузка на сервер минимальна, обычно это ночь. Также полезно иметь список ВМ с пометкой, какие из них критичны для работы.

Хранилище для копий

Прежде чем копирование заработает, нужно определить хранилище (backup storage). Документация описывает два варианта: Proxmox Backup Server, где копии хранятся дедуплицированными блоками с метаданными, или файловое хранилище, где это обычные файлы. Для Proxmox Backup Server советуют отдельный хост, а NFS-сервер назван хорошей альтернативой. Не кладите копии на тот же диск, где лежат сами машины: выход диска из строя заберёт и ВМ, и копию.

Помните, что копии в Proxmox VE всегда полные: они содержат конфигурацию ВМ и все данные. Поэтому места нужно больше, чем кажется, если хранить несколько копий подряд. Для восстановления после пожара или потери помещения документация предлагает со временем переносить копии на ленту для архива вне площадки. Тот же принцип работает с любым удалённым хранилищем, это полезно и для защиты от программ-вымогателей.

Режим копирования

Режим (параметр mode) определяет баланс между согласованностью данных и простоем. Для ВМ есть три варианта. Режим stop корректно выключает машину, даёт наивысшую согласованность, но с коротким простоем. Режим snapshot копирует блоки, пока ВМ работает: простой минимальный, риск несогласованности небольшой. Режим suspend оставлен для совместимости, документация советует вместо него snapshot.

Для большинства рабочих серверов логично выбрать snapshot и включить гостевой агент (agent: 1). Если агент включён и работает, перед копированием и после него вызываются команды guest-fsfreeze-freeze и guest-fsfreeze-thaw, что улучшает согласованность. Для Windows-гостей агент нужно настроить, если внутри машины работает ещё и другая программа резервного копирования. Для контейнеров режимы работают иначе: stop может означать очень долгий простой, а snapshot требует хранилища со снимками.

Если нет своего администратора

Это типичная задача для обслуживания серверов, и требует она скорее регулярности, чем много времени. Если в вашей компании нет человека, который следит за серверами и резервными копиями, настройку расписания и проверку восстановления можно передать команде TakeIT.

Шаги

1. Подготовьте хранилище. Добавьте в Proxmox VE хранилище для копий (Proxmox Backup Server на отдельном хосте или NFS) по разделу документации о storage. Проверка: хранилище появилось в интерфейсе, доступно узлу и позволяет хранить резервные копии.
2. Составьте список машин и выберите режим для каждой. Для большинства ВМ подойдёт snapshot, для тех, что переносят короткую остановку и требуют максимальной согласованности, stop. Проверка: в конфигурации ВМ, которые копируются в режиме snapshot, есть agent: 1, а агент в гостевой системе действительно запущен.
3. Создайте задание резервного копирования по расписанию. В веб-интерфейсе найдите настройки заданий (Backup Jobs), укажите узлы, нужные гостевые системы, хранилище, режим, дни и время. Запускайте ночью и не разносите критичные машины по разным заданиям без необходимости. Проверка: задание сохранено и видно в списке вместе с выбранными ВМ.
4. Для нагруженных машин включите fleecing. Когда копирование стартует, новые записи в ещё не скопированные участки ждут, пока старые данные уйдут в хранилище копий, поэтому скорость хранилища влияет на работу ВМ. Fleecing кеширует эти данные в отдельном образе, что может помочь и даже избежать зависаний, но требует дополнительного места. В интерфейсе настройка есть на вкладке Advanced при редактировании задания, а fleecing-хранилище должно быть быстрым локальным, с thin provisioning и поддержкой discard, например LVM-thin, RBD или ZFS. Проверка: во время пробного запуска ВМ не подвисает, а на fleecing-хранилище хватает места.
5. Запустите пробную копию вручную. Копию можно начать из интерфейса или командой vzdump, например для машины 123 с fleecing: vzdump 123 --fleecing enabled=1,storage=local-lvm. Проверка: задание завершилось без ошибок, а архив появился в хранилище с правильной датой и разумным размером.
6. Дождитесь первого запуска по расписанию. Проверка: на следующее утро в журнале задания нет ошибок, а для каждой ВМ из списка есть свежая копия.

Как проверить результат

Успешная запись в журнале ещё не означает, что копию можно восстановить. Поэтому проверка состоит из трёх уровней. Первый: раз в неделю смотрите, есть ли для всех ВМ свежие копии и не растёт ли размер так, что хранилище скоро закончится. Второй: после изменений в конфигурации (новая ВМ, новый диск) обновляете список в задании. Третий: раз в несколько месяцев восстанавливаете копию как отдельную тестовую машину, не трогая рабочую, и убеждаетесь, что система стартует, а данные на месте.

Не пугайтесь, если во время копирования выключенная ВМ в списке выглядит запущенной. Документация объясняет: копию выполняет фоновый процесс QEMU, который читает диски, а сама машина не загружается. Как вписать восстановление в более широкую практику компании, читайте на странице о резервном копировании и восстановлении.

Типичные ошибки

Копии лежат рядом с оригиналом

Хранилище на том же диске или в том же массиве, что и ВМ, защищает только от ошибок в системе внутри машины. От поломки железа или потери помещения оно не спасёт. Желательно иметь хотя бы одну копию на другом устройстве, а лучше ещё и за пределами офиса.

Не все диски и точки монтирования попали в копию

Для контейнеров дополнительные точки монтирования, кроме корневого диска, по умолчанию не копируются. Устройства и bind-монтирования не копируются никогда, потому что их содержимое управляется вне хранилища Proxmox VE. Если важные данные лежат именно там, их нужно защищать отдельно.

Режим snapshot без гостевого агента

Без агента копия создаётся, но согласованность данных ниже. Для машин с базами это критично: проверьте агент в ВМ и, где нужно, добавьте отдельные копии самих баз.

Выбор suspend по привычке

Режим suspend дольше останавливает машину и не обязательно улучшает согласованность. Документация советует snapshot, а для максимальной согласованности stop.

Копии никогда не восстанавливали

Бывает, что расписание работает годами, а восстановление впервые пробуют во время аварии. Тестовое восстановление, описанное в разделе о проверке, помогает заметить проблему заранее.

Вывод

После настройки расписание каждый раз запускает копирование само, а вам остаётся периодически просматривать отчёты и пробовать восстановление. Начните с одной критичной машины, убедитесь, что её копия восстанавливается, и добавляйте остальные по очереди.

Источники

Proxmox VE: Backup and Restore (vzdump), официальная документация, версия 9.2.13, дата: 2026-11-04.