Перейти к содержанию

Резервное копирование виртуальной машины

Список основных возможностей резервного копирования виртуальных машин

  • Создание резервной копии включенной ВМ.
  • Создание и восстановление ВМ с сохранением дерева сохраненных состояний.
  • Возможность инкремента резервной копии.
  • Сжатие в формат Zstandard.
  • Создание и инкремент по расписанию.
  • Резервное копирование тонких клонов.
  • Автоматическое удаление старых копий при создании по расписанию.
  • Импорт из OVF и OVA версии 1.0.
  • Просмотр конфигурации ВМ в резервной копии.
  • Проверка целостности файла резервной копии.

Примечания по резервному копированию

  • Резервное копирование с mediated-устройствами необходимо выполнять на выключенных ВМ.

  • Посмотреть имеющиеся резервные копии у виртуальной машины и создать новую можно во вкладке на боковой панели Резервное копирование.

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

  • При создании инкрементальной резервной копии в Снимки появляется новое сохранённое состояние ВМ, и при дальнейшем инкрементировании каждый раз будет создаваться новое. При удалении хотя бы одного сохраненного состояния, все резервные копии ВМ перестают быть инкрементальными.

    Внимание

    Автоматически созданное сохраненное состояние может содержать снимки памяти. Снимки памяти не будут создаваться в случае выключенной ВМ, а также если используется гостевой агент, который требуется для создания консистентного снимка.

  • При создании резервной копии не будет создана копия LUN-устройства, присоединённого к ВМ. При восстановлении LUN-устройство будет присоединено, в случае если оно доступно и не занято.

  • Нельзя сделать резервную копию, если имеются диски на lvm, thinlvm, lvm-shared, также нельзя сохранить резервную копию на них. Нельзя сделать резервную копию, если имеются сохраненные состояния с дисками на пуле данных zfs, также с дисками на zfs нельзя сделать резервные копии с возможностью инкремента.

  • Резервная копия виртуальной машины является файлом. Копия, созданная штатными средствами SpaceVM, представляет собой простой tar-архив с расширением .tar или сжатый в формат Zstandard .tar.zst, в котором хранятся файлы дисков ВМ .qcow2, снимки от них .snapshot, хотя это тоже файлы формата qcow2, снимки памяти .memory, iso-образы .iso, примонтированные к cdrom, и xml-файлы конфигурации формата, используемого libvirt Domain XML. Резервная копия должна содержать минимум один конфигурационный xml-файл. В резервной копии могут содержаться несколько конфигурационных файлов вследствие инкрементирования копии, так как операция удаления файла из tar-архива очень накладна, старые версии остаются. Актуальной является последняя, содержащая большее число в префиксе в названия xml-файла, это число является unix временной меткой.

  • При открытии файла резервной копии, кроме обычных для файла кнопок (Обновить, Копировать, Скачать, Удалить), имеется кнопки:

    • Обновить информацию о резервной копии - читает файл резервной копии, что может занять длительное время, особенно, если копия сжата. Эта кнопка присутствует у загруженных файлов tar, xml, OVA и OVF. После того как файл прочитается (кроме OVF), она заменяется кнопкой Конфигурация копии ВМ. Так как OVF зависит от того, загружены в этот пул данных файлы дисков или нет, возможность обновить информацию в ручную должна сохраняться.

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

    • Сжать или Разжать - позволяют сжать резервную копию ВМ SpaceVM в формат Zstandard или разжать. Zstandard выбран как достаточно быстрый формат сжатия.

  • В окне Конфигурация копии ВМ идентификаторы UUID могут отличаться от идентификаторов в восстановленной ВМ. Пути к дискам и образам предыдущие и могут изменяться в зависимости от способа восстановления, доступного места и наличия их на узле.

  • При нажатии кнопки Восстановление ВМ в окне Конфигурация копии ВМ можно выбрать сервер из списка тех, на которых доступен файл резервной копии, а также пул данных, на который будут извлечены диски и iso-образы. Если пул данных не указывать, файлы будут восстанавливаться по прежним путям, а в тех случаях, когда на пуле данных недостаточно места, будет выбираться пул данных, на котором находится файл резервной копии. Если по старому пути iso-образ уже существует, то будет использоваться уже существующий файл.

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

  • У сторонних резервных копий формата OVA в окне Конфигурация копии ВМ помимо кнопки Восстановление ВМ имеется кнопка Конвертация, при нажатии на которую появится окно с выбором узла и пула данных, а также флагом Сжать, указывающий, что сконвертированную резервную копию нужно создать в сжатом виде формата Zstandard. По аналогии с восстановлением выбрать можно только те узлы, с которых доступен файл резервной копии. Если пул данных не указывать, то сконвертированная резервная копия создается в том же пуле, что и начальная копия. Поддерживается OVA с версией OVF 1.0.

  • У резервной копии, сконвертированной из формата OVA, путей восстановления нет, поэтому все файлы восстановятся или в указанный пул данных, или в пул данных, содержащий эту резервную копию.

  • Восстановление ВМ возможно также из файла XML-формата, поддерживаемого libvirt, а также файла OVF с версией OVF 1.0. При нажатии Восстановление ВМ у этих файлов восстановление или подключение имеющихся дисков и блочных устройств не происходит. У OVF файла помимо кнопки Восстановление ВМ имеются кнопки Восстановление с дисками и Конвертация. Операция Восстановление с дисками аналогична Восстановление ВМ из OVA, как и действие Конвертация, только файлы дисков и iso берутся из директории, в которой находится OVF файл.

  • При конвертации из формата OVA, характерного продуктам Vmware, параметры ВМ, которые не могут быть корректно интерпретированы из-за ограниченного лицензиями виртуального оборудования Vmware, будут заменены аналогом для KVM или проигнорированы.

  • После восстановления ВМ из формата OVA следует проверить её конфигурацию перед запуском. Также необходимо учитывать, что при импорте virtual appliance все скрипты из состава образа будут проигнорированы.

  • Во всех операциях, которые ведут к изменению файловой системы, нельзя выбрать пул данных только на чтение. К ним относится и outside-пул. Соответственно, если файл резервной копии находится на таком пуле данных, то выбор пула будет обязательным, и в списке доступных текущего пула данных не будет.

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

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

    • Ограничение на количество одновременно запущенных задач - поле ограничивающее количество параллельно запущенных задач создания резервной копии, при указании "0" ограничение не действует, все задачи запускаются одновременно. Для сетевых файловых систем, рекомендуется использовать не более двух параллельных задач.

    • Ограничение на количество инкрементов перед удалением всех сохраненных состояний - поле, ограничивающее количество инкрементов. После указанного количества происходит выполнение задачи удаления всех сохраненных состояний у ВМ.

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

    • Включить удаление старых резервных копий, сохраняя не более указанного числа - позволяет указать, какое количество резервных копий хранить. При создании новой резервной копии, если копий становится больше указанного лимита, то самая старая будет удалена.

    • Включить удаление резервных копий старее указанного числа дней - позволяет задать количество дней для хранения резервной копии. При создании новой резервной копии проверяется наличие копий старее указанного периода, и все копии старее него будут удалены.

Подключение диска к другой ВМ для систем резервного копирования

  • Подключение реализовано для систем резервного копирования дисков, в частности, для Кибер Бэкап 15.

  • Функционал доступен только через REST API и не предполагает визуальный интерфейс.

  • Подключение реализовано с помощью создания сохраненного состояния на ВМ, диски которой будут подключаться ко второй ВМ. Все диски этой ВМ будут подключаться от одного сохраненного состояния, то есть при подключении первого диска, будет создано сохраненное состояние с именем vdisks_attached_to_another_domains, и при подключении второго диска будет использоваться то же сохраненное состояние. Это означает, что второй диск будет иметь состояние на тот же момент времени, что и первый. Сохраненное состояние vdisks_attached_to_another_domains нельзя удалить, пока имеются диски, подключенные к другой ВМ, а также нельзя создать новое сохраненное состояние, и, соответственно, выполнить операции, которые этого требуют. Кроме того, большинство операций над ВМ и её дисками будут запрещены.

  • Диски ко второй ВМ подключаются в режиме только на чтение.

  • Подключение и отключение диска ко второй ВМ осуществляется аналогичным запросом, как и в случае подключения и отключения к одной ВМ. Но есть определенные различия: при присоединении диска игнорируются переданные параметры, кроме UUID диска, и диск подключается с типом шины virtio и типом кэширования none. И так как подключается не сам диск, а сохраненное состояние диска, то для ВМ, к которой он подключается, будет подключаться объект снимка диска, а не объект оригинального диска, а в случае диска на zfs-пуле данных будет клон диска, то есть связанный объект диска, но с другим UUID. Поэтому в списке подключенных дисков у второй ВМ не найдется дисков, которые подключали. Для того чтобы отключить диск от второй ВМ, следует передать UUID оригинального диска, а не UUID объектов, к нему подключенных. Пример, пусть имеется ВМ vm1(53f2d6ce-65f7-4189-91b5-dd35b9d14ec4) с диском vm1_disk_1(55522015-292a-436b-921a-1a962e7274d9) и требуется подключить этот диск ко второй ВМ vm2(f36c8ea6-7a8d-429b-956c-5e63edeeb82a), тогда запросы подключения и отключения будут такими:

    Пример присоединения диска

    POST /api/domains/f36c8ea6-7a8d-429b-956c-5e63edeeb82a/attach-vdisk/
{"vdisk":"55522015-292a-436b-921a-1a962e7274d9"}

    Пример отключения диска

    POST /api/domains/f36c8ea6-7a8d-429b-956c-5e63edeeb82a/detach-vdisk/
{"vdisk":"55522015-292a-436b-921a-1a962e7274d9"}

    Пример получения списка дисков, подключенных от других ВМ

    GET /api/vdisks/?another_domain=f36c8ea6-7a8d-429b-956c-5e63edeeb82a
{"count": 1,
"next": null,
"previous": null,
"results": [
    {"id": "55522015-292a-436b-921a-1a962e7274d9",
    "status": "ACTIVE",
    "verbose_name": "vm1_disk_1",
    "size": 0.1,
    "datapool": {...},
    "domain": {"id": "53f2d6ce-65f7-4189-91b5-dd35b9d14ec4", "verbose_name": "vm1"},
    "hints": 0,
    "shareable": false
    }]}
    Запрос вернет только диски, имеющие своим вторым подключением ВМ, переданным параметром another_domain. Вернутся объекты оригинальных дисков, которые можно использовать в запросе для отключения.

  • Если первая ВМ, от которой подключаем диск, является тонким клоном, то в запрос присоединения и отключения диска нужно передавать параметр thin_clone с UUID этого тонкого клона. Так как, если это диск не на zfs, то тонкий клон использует диск шаблона ВМ, но у него свое текущее состояние. Если просто передать диск, то диск будет присоединен от шаблона с его текущим состоянием. Если это диск на zfs-пуле данных, то разницы не будет, так как тонкий клон использует клон диска от диска шаблона. Запросы подключения и отключения будут такими:

    !!! example "Пример присоединения диска от тонкого клона" 

    POST /api/domains/f36c8ea6-7a8d-429b-956c-5e63edeeb82a/attach-vdisk/
{"vdisk":"55522015-292a-436b-921a-1a962e7274d9",
 "thin_clone":"53f2d6ce-65f7-4189-91b5-dd35b9d14ec4"}

    !!! example "Пример отключения диска тонкого клона" 

    POST /api/domains/f36c8ea6-7a8d-429b-956c-5e63edeeb82a/detach-vdisk/
{"vdisk":"55522015-292a-436b-921a-1a962e7274d9",
 "thin_clone":"53f2d6ce-65f7-4189-91b5-dd35b9d14ec4"}

  • После отключения последнего диска от других ВМ на первой ВМ сохраненное состояние с именем vdisks_attached_to_another_domains будет удалено.

  • Диск отключается от второй ВМ корректно только, когда на второй ВМ запущена ОС, или ВМ находится в выключенном состоянии, иначе с большой вероятностью произойдет ошибка с сообщением вида "Domain f36c8ea6-7a8d-429b-956c-5e63edeeb82a device did not detach."

  • Если вторая ВМ будет удалена, то присоединенные диски от другой ВМ будут отключены, и если на первой ВМ были отсоединены таким образом все диски, то сохраненное состояние vdisks_attached_to_another_domains будет удалено.

  • Если диск был на zfs-пуле данных, то присоединен ко второй ВМ будет клон диска, созданный средствами zfs, и если этот диск отсоединить, используя его UUID, а не UUID оригинального диска, то клон просто отсоединится без удаления, и сохраненное состояние vdisks_attached_to_another_domains нельзя будет удалить, пока этот клон не будет удален.

Пример создания резервных копий по расписанию

Задача. Создание резервных копий для группы ВМ. Расписание такое: бэкап делается раз в сутки в ночное время, в ночь с субботы на воскресенье делается полный бэкап, в остальные дни делается инкремент. Срок хранения файлов резервной копии 30 дней.

Порядок действий:

  1. В разделе Журнал - Задачи по расписанию основного меню нажимаем Добавить, выбираем тип сущности Виртуальная машина, из следующего списка сущностей выбираем нужные ВМ, нажимаем ОК.

  2. Открывается окно Создание задачи по расписанию. В поле Название напишем, к примеру, Ежедневное резервное копирование.

  3. Далее в Действие выбираем backup, в Периодичность - daily, в Дата запуска устанавливаем время на ближайшее воскресенье, к примеру, на 01:00.

  4. В поле Ограничение на количество инкрементов перед удалением всех сохраненных состояний устанавливаем 7, так как у нас недельный цикл. В ночь с пятницы на субботу, после создания последнего инкремента сразу же в этой задаче произойдет удаление всех сохраненных состояний, и файл резервной копии станет не инкрементируемым. На следующий день будет выполнено полное резервное копирование с возможностью инкремента.

  5. Включаем Инкрементировать последнюю резервную копию и, если требуется, включаем Выбрать пул данных, далее выбираем из доступных.

  6. Выставляем ограничение по времени хранения резервной копии в днях Включить удаление резервных копий старее указанного числа дней, поле Дней для сохранения, в нашем случае задаем 30.

  7. Нажимаем ОК, чтобы создать задачу.