В предыдущем руководстве вы преобразовали первую виртуальную машину в многократно используемый шаблон и клонировали её за считанные секунды вместо минут - а именно web02, полноценную рабочую копию с уже зафиксированными собственными идентификационными данными. Ни этот клон, ни лежащий в его основе шаблон пока нигде больше не существуют, поэтому, прежде чем в них появятся данные, без которых клиенту будет не обойтись, вам сначала нужно настроить собственную систему резервного копирования Proxmox полностью через панель управления.
Запланировать задание резервного копирования
Выбрав в левом дереве пункт «Центр обработки данных» → «Резервное копирование», открывается список заданий, который на новом узле изначально совершенно пуст. Пока что единственной полезной кнопкой является «Добавить», которая открывает диалоговое окно, в котором в одном месте собирается вся необходимая информация для запланированного резервного копирования: какие виртуальные машины, какое хранилище, когда и как долго хранить полученные данные.
Выберите, что и когда нужно скопировать
В таблице «Гости для включения» на вкладке «Общие» перечислены все виртуальные машины на узле с флажками рядом с ними - те же три виртуальные машины, что и в двух предыдущих руководствах. Установив флажок только напротив web02, а не напротив шаблона или его неиспользуемой «сестры», вы обеспечите, что это первое задание будет сосредоточено на той единственной виртуальной машине, которую действительно стоит восстановить в случае возникновения проблем.
Параметр «Node stays on - All -» стоит оставить без изменений даже в такой одноузловой лабораторной среде, как эта: в реальном многоузловом кластере это означает, что задание будет выполняться там, где в данный момент находится каждый выбранный гостевой ОС, а не завершится с ошибкой без уведомления, если виртуальная машина будет перенесена с узла, к которому было привязано задание. В поле «Расписание» можно указать либо календарное выражение в стиле systemd, либо, как в данном случае, простое время суток, а режим «Снимок» создает резервную копию работающей виртуальной машины без её приостановки, автоматически переключаясь на простое копирование файлов, если виртуальная машина оказывается остановленной - именно так и произошло с web02 в данной лабораторной задаче.
Настроить политику хранения данных
На вкладке «Хранение» задание перестает быть просто расписанием и превращается в полноценную политику: если не внести никаких изменений, каждый отдельный запуск будет сохранять свой собственный архив навсегда, постепенно заполняя целевое хранилище одной резервной копией за другой.
Параметры «Хранить последние», «Хранить ежедневно», «Хранить еженедельно», «Хранить ежемесячно» и «Хранить ежегодно» суммируются, а не переопределяют друг друга - это та же многоуровневая схема хранения, которую используют большинство инструментов резервного копирования, когда политике требуется сохранять данные дольше, чем результаты нескольких последних запусков. Стоит внимательно прочитать примечание под полями: если оставить все поля пустыми, это не означает неограниченное хранение - это означает, что Proxmox будет использовать настройки, заданные для самого хранилища или для узла vzdump.conf уже определено, что на узле, который ещё никто не настраивал, может храниться гораздо меньше данных, чем ожидалось.
При нажатии кнопки «Создать» обе вкладки отправляются как одно задание, и в том же списке, который сначала был пуст, теперь отображается именно то, что было настроено:
«Следующий запуск» - это реальное значение, рассчитанное на основе расписания в момент сохранения задания, а не заполненное заметкой-заполнителем. С помощью «Симулятора расписания», расположенного на той же панели инструментов, можно таким же образом проверить более сложное календарное выражение на соответствие будущим датам, прежде чем его утвердить.
Запустите резервное копирование и просмотрите журнал
Ждать до 02:30, чтобы действительно протестировать совершенно новое задание, редко бывает целесообразно, поэтому кнопка «Запустить сейчас», расположенная на той же панели инструментов, запускает это задание сразу же после появления одного диалогового окна подтверждения. Результат этого запуска стоит прочитать полностью хотя бы один раз, поскольку каждое последующее резервное копирование, выполняемое этим заданием, проходит точно по той же последовательности действий:
Proxmox действительно запускает виртуальную машину только для того, чтобы создать её резервную копию?
Нет. starting kvm to execute backup task и stopping kvm after backup task Вместо этого запустите кратковременный вспомогательный процесс: экземпляр QEMU, который монтирует диск web02 и передаёт его потоком через QMP, что полностью отделено от самой процедуры загрузки Debian внутри него. Именно поэтому в журнале сообщается: backup mode: stop несмотря на то, что в диалоговом окне был выбран режим «Снимок»: web02 уже был остановлен на момент выполнения задания, поэтому изначально не было запущенного гостевого системы, для которой можно было бы создать снимок, и Proxmox автоматически переходит к более простому варианту, а не завершает задание с ошибкой.
На процентных линиях в центре рядом с каждой из них указаны реальные значения пропускной способности - это подлинные данные о ходе процесса, а не фиксированная анимация: показатели росли с 556,7 MiB/с в начале и снижались до 4,4 MiB/s по мере того, как к концу последовательность чтения становилась менее упорядоченной. backup is sparse: 14.94 GiB (93%) total zero data В этой строке объясняется самое большое отдельное число во всём этом журнале: из номинального объёма диска в 16,0 GiB только 7 % содержали данные, которые Proxmox действительно нужно было скопировать.
Проверьте архив и его фактический размер
На вкладке «Резервное копирование» каждой виртуальной машины отображается история архивов именно этой виртуальной машины, независимо от того, в рамках какого задания или на каком хранилище был создан тот или иной архив.
Эти 563,53 МБ - это сумма результатов обнаружения разреженных данных из журнала задач и сжатия ZSTD: 93 %, которые и так состояли из нулей, практически ничего не стоили при хранении, а всё, что осталось, всё равно сжалось значительно больше, чем его исходный размер. Такой пустой диск - это лучший вариант, который может предложить новая виртуальная машина, и с этого момента объём данных будет только расти, по мере того как web02 будет заполняться реальным развёртыванием, и именно поэтому ограничения на хранение, упомянутые в предыдущем разделе, имеют значение задолго до того, как этот рост станет проблемой.
Запустить резервное копирование по требованию
Функция «Резервное копирование сейчас», расположенная на той же вкладке «Резервное копирование виртуальной машины», использует тот же механизм vzdump, что и запланированное задание, только без ожидания наступления времени, указанного в расписании, и без охватывания всех гостевых систем, которые в противном случае могли бы быть включены в задание.
Именно из этого поля «Примечания» и происходит значение «web02», которое уже было видно в архиве в предыдущем разделе: {{guestname}} - это переменная динамического шаблона, которая при резервном копировании заполняется собственным именем данной виртуальной машины, а в подсказке под полем перечислены другие доступные варианты для более подробного описания. О параметре «Защищено», который здесь не отмечен галочкой, стоит знать ещё до того, как он понадобится: его активация исключает данный архив из всех правил хранения и из самой функции «Удалить» - это единственный параметр, который отделяет случайное удаление от резервной копии, действительно необходимой команде для продолжения работы.
Восстановление из резервной копии
Если выбрать архив из этого же списка и нажать кнопку «Восстановить», откроется диалоговое окно, название которого уже ясно указывает на риск:
Прежде чем нажать кнопку «Восстановить» для существующего идентификатора виртуальной машины, убедитесь, что на текущем диске виртуальной машины нет данных, которые стоит сохранить. Именно по этой причине заголовок диалогового окна гласит «Восстановление с перезаписью», и после этого экрана не предусмотрено отдельного этапа подтверждения.
Восстановление на другой, неиспользуемый идентификатор виртуальной машины позволяет полностью избежать этого риска, что полезно для проверки работоспособности архива без вмешательства в действующую виртуальную машину, с которой он был создан. В этом случае функция «Unique» (Уникальный) заново генерирует сетевой MAC-адрес таким же образом, как это делалось при клонировании шаблона в инструкции, опубликованной двумя руководствами ранее, поскольку две виртуальные машины, использующие один и тот же MAC-адрес на одном мосту, вступили бы в конфликт в момент их запуска. Настройки переопределения заранее заполняют поля «Имя», «Память», «Ядра» и «Сокеты» непосредственно из сохраненной конфигурации самой резервной копии; их можно отредактировать здесь до того, как функция «Восстановление» их фиксирует - это последняя контрольная точка перед тем, как фактически появится первый реальный путь аварийного восстановления на этой платформе.
В заключение
- Запланированное задание резервного копирования объединяет выбор гостевых систем, хранилище, расписание и срок хранения в один объект на уровне центра обработки данных.
- Настоящая резервная копия создается с помощью кратковременного вспомогательного процесса, а не самой гостевой ОС.
- Благодаря сочетанию технологий обнаружения редкозаполненных блоков и сжатия объем диска, номинально равного 16 ГиБ, можно уменьшить до нескольких сотен реальных мегабайт.
- Восстановление с использованием существующего идентификатора виртуальной машины приводит к его перезаписи; для безопасного тестирования архива лучше использовать другой идентификатор и параметр «Unique».
В следующем руководстве вы добавите функции мониторинга и оповещения к тому, что уже работает.