Глава 10. Резервное копирование/ восстановление ВМ

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

Одним из наиболее популярных вариантов для хранения резервных копий является NFS. В корпоративных или критически важных средах рекомендуемой практикой является выделение для резервных копий кластера со встроенной избыточностью. В средах меньшего размера хорошая избыточность может быть достигнута при применении таких вариантов хранилищ как Gluster или DRBD. После добавления ZFS и Gluster в Proxmox VE, теперь это жизнеспособный вариант превращения узла Proxmox в узел резервного копирования с применением Gluster поверх ZFS, при том что узел всё ещё будет управляться через GUI Proxmox. {Прим. пер.: отметим, что Gluster здесь применяется исключительно для кластеризации ZFS. Это распространённый трюк о котором следует помнить.} К сожалению мы не можем сохранять файлы в хранилище Ceph RBD. {Прим. пер.: Однако, можем настроить NFS поверх CephFS.}

Для отдельного узла хранения резервных копий великолепным решением является FreeNAS без кластерной избыточности. В зависимости от того какая система хранения применяется, первичная цель состоит в хранении резервной копии на отдельном узле вместо использования вычислительного узла. Отсылаем вас к Главе 4, Системы хранения для получения информации о том, как подключать различные системы хранения к Proxmox. Когда хранилище настроено и подключено к Proxmox, нам необходимо убедиться, что тип сохраняемого содержимого настроен надлежащим образом для хранения файлов резервного копирования и количества ротаций резервных копий. Существует два варианта в блоке диалога вашего хранилища для выбора типа содержимого и определения количества ротаций резервных копий. Следующий снимок отображает блок диалога хранилища для хранилища NFS в нашем примере кластера:

В предыдущем снимке экрана мы выбрали VZDump backup file в ниспадающем списке и ввели 3 в закладке Max backups или закладке количества ротаций резервных копий. Это означает, что хранилище позволит вам сохранять файлы резервной копии и всегда будут оставаться три последние резервные копии. Более старые копии будут автоматически удаляться. Это будет происходить исключительно автоматически в процессе обработки расписания резервного копирования.

При выполнении резервного копирования вручную данное численное значение в действительности не даст вам возможности фиксировать резервные копии вручную если уже существует три хранимые резервные копии в вашем хранилище для ВМ. В этом случае мы должны удалить более старые резервные копии вручную или увеличить это значение для размещения новых делаемых вручную резервных копий. Мы можем удалять файлы резервных копий для определённой ВМ в меню закладки резервных копий данной ВМ или непосредственно из устройства хранения в закладке содержимого. Нам необходимо выбрать подлежащий удалению файл резервной копии и затем кликнуть Remove. Следующий снимок экрана отображает закладку меню резервных копий для нашего контейнера #101:

В зависимости от избранной стратегии резервного копирования и деловых потребностей может существовать необходимость хранить определённые периоды истории резервных копий. Proxmox допускает как автоматическое, так и ручное удаление любых выходящих за пределы требуемого исторического диапазона копий. Автоматическое удаление выполняется через определённое значение Max backups в блоке диалога резервных копий. Мы можем ввести любое численное значение в пределах от 0 до 365 в качестве Max backups. Например, наше хранилище NFS имеет значение Max backups равное 3. Это означает, что в процессе полного резервного копирования Proxmox будет сохранять три самые новые копии каждой виртуальной машины и удалять все более старые.

Если нам нужно фиксировать резервные копии ежедневно, мы потенциально можем хранить 365 дней или значение резервных копий 1 года на любой определённый момент. Если мы делаем резервную копию каждый второй день, то это будет значение резервных копий 2 лет.

Все полные резервные копии находятся в формате tar

, содержащем как файл настройки, так и файл образа виртуального диска. Файлы резервных копий это всё, что вам нужно для восстановления виртуальной машины на любых узлах и в любом хранилище. Файлы полных резервных копий именуются в виде ряда следующих форматов как для виртуальных машин KVM, так и для LXC:

vzdump-lxc-<ct_id>-YYYY_MM_DD-HH_MM_SS.tar
vzdump-lxc-<ct_id>-YYYY_MM_DD-HH_MM_SS.tar.lzo
vzdump-lxc-<ct_id>-YYYY_MM_DD-HH_MM_SS.tar.gz

vzdump-qemu-<vm_id>-YYYY_MM_DD-HH_MM_SS.vma
vzdump-qemu-<vm_id>-YYYY_MM_DD-HH_MM_SS.vma.lzo
vzdump-qemu-<vm_id>-YYYY_MM_DD-HH_MM_SS.vma.fz
 	   

Следующий снимок отображает перечень файлов резервных копий на узле их хранения в том виде, как он виден в GUI Proxmox:

В Proxmox мы можем составлять расписание автоматизации задач резервного копирования или фиксировать резервные копии вручную для каждой виртуальной машины. Будь то резервное копирование по расписанию или вручную, и для виртуальных машин KVM, и для LXC процесс один и тот же.

расписания можно создавать в параметрах Backup в меню с закладками Центра данных. В последующих разделах мы подробнее рассмотрим каждый блок параметров. Параметры резервного копирования отображают перечень уже созданных расписаний Backup с параметрами для задач Add, Remove и Edit. Блок диалога расписания один и тот же для задач добавления, удаления и изменения. Мы можем кликнуть на добавление для открытия такого блока диалога, как это отображено на следующем экранном снимке:

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

  Node

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

  Storage

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

Серверы резервного копирования намного более экономные чем вычислительные узлы, поскольку они не должны выполнять никакие виртуальные машины. Некоторые узлы хранения, например, ZFS, нуждаются в приличных объёмах памяти для надлежащей работы. Допустим, мы выбрали хранилище NFS.

  Day of week

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

  Start Time

В отличие от Day of week может быть выбран только один пункт. Невозможно выбрать множество времён для резервного копирования в различное время данного дня.

  Selection mode

Этот ниспадающий перечень используется для определения того, как ВМ выбираются для резервных копирований. Существует три варианта доступные для выбора. Режим All выберет все виртуальные машины в пределах целого кластера Proxmox или узла, в зависимости от сделанного в ниспадающем списке Node. Режим Exclude selected VMs возьмёт за основу все ВМ за исключением отобранных. Include selected VMs возмёт за основу только выбранные ВМ. Допустим, мы выбрали Include selected VMs.

  Send e-mail to

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

  E-mail notification

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

  Compression

Данный ниспадающий список используется для выбора уровня сжатия для данной задачи резервного копирования. Для ознакомления с разницей в различных уровнях сжатия отсылаем вас к разделу Сжатие резервных копий ранее в этой главе. По умолчанию выбран метод сжатия LZO.

  Mode

Этот ниспадающий перечень применяется для определения режима резервного копирования данной задачи. Для ознакомления разницы между различными режимами резервного копирования вернитесь к разделу Режимы полного резервного копирования ранее в этой главе. По умолчанию резервное копирование всех работающих виртуальных машин происходит с вариантом Снимка.

  Enable

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

Ниже показан вариант Backup с нашей вновь созданной задачей резервного копирования в списке.

Резервное копирование вручную может быть выполнено на определённой виртуальной машине в любой момент времени с помощью GUI Proxmox. Параметр резервного копирования Manual доступен через меню с закладками Backup для каждой виртуальной машины. Из одного и того же меню резервного копирования мы можем выполнять резервное копирование, восстановление и удаление файлов резервных копий.

Для открытия блока диалога создания резервной копии нам нужно кликнуть по кнопке Backup now. Блок диалога резервного копирования Manual чрезвычайно прост. Нам нужно всего лишь выбрать узел получатель Storage, Mode резервного копирования и уровень Compression, как это отображено на экранном снимке ниже:

Снимки являются великолепным способом для консервации определённого состояния виртуальной машины. Это гораздо быстрее чем полное резервное копирование, поскольку при нём не копируются все необходимые данные. Снимок не является действительной резервной копией при таком подходе и не выполняет резервное копирование гранулированного уровня. Он захватывает состояние в определённый момент времени и позволяет выполнять откат к такому предыдущему состоянию.

Снимок является великолепным функционалом, который можно применять между полным резервным копированием. Параметр Snapshot можно найти в меню с закладками Snapshots определённой виртуальной машины. Заново установленные ВМ без каких- либо снимков появятся в меню Snapshots, как это показано на следующем снимке экрана:

Сам процесс создания моментального снимка очень прост. Для открытия диалогового блока кликните Take Snapshot, а затем просто введите Name, сделайте выбор содержимого RAM или отмените его, а также наберите некоторое описание. Текстовый блок Name не допускает никаких пробелов, а имя должно начинаться с буквы из набора букв и цифр. Следующий снимок экрана отображает блок диалога создания Snapshots для нашего примера VM #112.

Функциональность Snapshot доступна как для виртуальных машин KVM, так и для LXC. Следующий снимок экрана отображает параметр Snapshot со вновь созданным снимком:

Если мы хотим вернуться назад к образу моментального снимка, просто выберите соответствующий снимок для возврата и кликните Rollback. Он выдаст вам вопрос действительно ли вы хотите откатить, как это отображено на следующем снимке экрана:

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

На предыдущем снимке экрана мы находимся в опции Backup для VM #112. Так как опция резервного копирования отображает список всех хранимых на таком узле хранения резервных копий их файлов, мы можем увидеть файлы резервных копий для VM #110. Если выберем файл резервной копии и затем кликнем на Restore, у нас не будет возможности восстановить VM #110 на самого себя. Вместо этого он в действительности заменит VM #112. Следующий снимок отображает блок диалога Restore в случае, когда VM ID не определён:

Чтобы восстановить файл резервной копии с его первоначальным VM ID, нам нужно выбрать файл резервной копии из меню с закладками содержимого нашего хранилища, как это отображено на следующем экранном снимке:

Если мы выберем файл резервной копии для VM #110 из нашего списка содержимого, а затем кликнем на Restore, у нас будет возможность определить VM ID в блоке диалога Restore, как это показано на снимке экрана ниже:

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

В случае, если процесс резервного копирования и восстановления в Proxmox не доступен через GUI, он может быть выполнен из командной строки.

Команда для фиксации резервной копии и в виртуальных машинах KVM, и в LXC одна и та же. Ниже приведём формат для резервного копирования:

# vzdump <vmid> <options>
 	   

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

Параметр	Описание
-all	Значение по умолчанию равно 0. Этот параметр будет делать резервные копии всех доступных машин узла Proxmox.
-bwlimit	Регулирует полосу пропускания вашего резервного копирования в KBPS.
-compress	Значение по умолчанию установлено в lzo. Эта настройка устанавливает тип сжатия или запрещает его. Доступными значениями являются 0, 1, gzip и lzo.
-mailto	Это адрес электронной почты применяемый для отправки отчётов о резервном копировании.
-maxfiles	Содержит численное значение. Устанавливает максимальное число сохраняемых файлов резервных копий.
-mode	Значение по умолчанию Stop. Устанавливает режим резервного копирования. Доступны параметры snapshot, stop и suspend.
-remove	Значение по умолчанию равно 1. Устанавливает удаление более старые резервные копии если действие приводит к превышению значения maxfiles.
-lockwait	Максимальное время в минутах ожидания глобальной блокировки. Значение по умолчанию равно 180.
-storage	Определяет значение идентификатора хранилища для хранилища получателя резервной копии.
-tmpdir	Определяет значение временного каталога для хранения файлов в процессе резервного копирования. Это необязательная опция.

Хотя для резервного копирования и применяется одна и та же команда для KVM и LXC, для восстановления виртуальных машин KVM и LXC доступны отдельные команды:

Ниже приводится формат команды для восстановления ВМ KVM из командной строки:

#qmrestore <backup_file> <new/old_vmid> <options>
 	   

Основываясь на предыдущем {формате}, если мы хотим выполнить восстановление нашего примера KVM #110 из резервной копии в локальное хранилище, это приведёт к следующему:

#qmrestore /var/lib/vz/dump/vzdump-qemu-110-2015_12_13-20_24_26.vma.lzo 110 –storage local
 	   

Ниже приводятся параметры, которые можно применять с командой qmrestore:

Параметр	Описание
-force <int>	Булево значение равно 0 или 1. Этот параметр позволяет перезаписывать существующую ВМ. Используйте его с предосторожностями.
-unique <int>	Булево значение равно 0 или 1. Этот параметр назначает произвольный случайно выбранный уникальный адрес Ethernet для интерфейса создаваемой виртуальной машины.
-pool <string>	Эта имя пула для добавления к создаваемой ВМ.
-storage <string>	Это идентификатор хранилища для хранилища получателя, в котором будет восстанавливаться образ диска данной ВМ.

Ниже приводится формат команды восстановления контейнеров LXC из командной строки:

#pct restore <ct_id> <backupfile> <options>
 	   

Основываясь на предыдущем формате команды, если нам нужно восстановить наш пример контейнера #101 в локальное хранилище, то это приведёт к следующему:

#pct restore 101 /var/lib/vz/dump/vzdump-lxc-101-2016_02_25-18_49_04.tar.lzo –storage local
 	   

Ниже приводятся параметры, которые можно применять с командой pct restore:

Параметр	Описание
-force <int>	Булево значение равно 0 или 1. Этот параметр позволяет перезаписывать существующий контейнер. Используйте его с предосторожностями.
-cpulimit <int>	Значение из диапазона от 0 до 128 со значением по умолчанию, равным 0. Определяет число ЦПУ или время ЦПУ. Значение 0 определяет отсутствие ограничений.
-cpuunits <int>	Значение из диапазона от 0 до 500 000 со значением по умолчанию, равным 1 024. Определяет вес ЦПУ данной ВМ относительно остальных ВМ.
-console <int>	Значение по умолчанию равно 1. Определяет число подключённых к контейнеру консолей.
-hostname <string>	Устанавливает имя хоста данного контейнера после выполнения команды восстановления.
-memory <int>	Значение по умолчанию равно 512. Определяет объём выделяемой контейнеру памяти.
-swap <int>	Значение по умолчанию равно 512. Определяет размер области подкачки для данного контейнера.
-password <string>	Устанавливает пароль root в данном контейнере по окончанию комадны восстановления.
-storage <string>	Определяет идентификатор хранилища для хранилища получателя, в котором будет восстанавливаться данный контейнер.

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

В таком случае нам необходимо разблокировать данную ВМ вручную для восстановления её нормальной работы. Подобная разблокировка не может быть выполнена в GUI Proxmox и выполняется исключительно в CLI. Команда должна выполняться на том узле, на котором находится данная ВМ. Следующая команда выполнит разблокирование заблокированной на узле Proxmox ВМ:

# qm unlock <vm_id>
 	   

Файла настройки резервного копирования в Proxmox делает доступным применение более расширенных возможностей. Например, если вы хотите ограничить скорость резервного копирования таким образом, чтобы задача резервного копирования не потребляла всю доступную полосу пропускания сетевой среды, мы можем ограничить её при помощи параметра bwlimit. В Proxmox VE 4.1 файл настройки не может быть изменён в GUI. Это должно быть выполнено при помощи CLI с использованием редактора. Файл настройки резервного копирования можно найти в /etc/vzdump.conf. Ниже приведён файл vzdump.conf по умолчанию во вновь созданном кластере Proxmox:

# tmpdir: DIR
# dumpdir: DIR
# storage: STORAGE_ID
# mode: snapshot|suspend|stop
# bwlimit: KBPS
# ionice: PRI
# lockwait: MINUTES
# stopwait: MINUTES
# size: MB
# maxfiles: N
# script: FILENAME
# exclude-path: PATHLIST
# pigz: N:
 	   

Все параметры по умолчанию ограждены комментарием в этом файле, так как Proxmox имеет набор параметров по умолчанию, уже закодированных в операционной системе. Изменение файла vzdump.conf перепишет установки по умолчанию и позволит нам выполнить персональные настройки резервного копирования Proxmox.

Наиболее часто вариантом изменения параметра в vzdump.conf является регулировка скорости резервного копирования. Обычно это делается в случае удалённо сохраняемых резервных копий и перегруженных интерфейсов в случаях, когда интерфейс резервного копирования тот же, что применяется для обмена вашими производственными ВМ. Значение должно определяться в кБ/c или килоБайтах в секунду. Например, чтобы ограничить резервное копирование в 200МБ/с, выполните следующую регулировку:

bwlimit: 200000
 	   

Резервное копирование Proxmox применяет глобальную блокировку файла для предотвращения одновременной работы множества экземпляров. Большее число экземпляров размещают дополнительную нагрузку на ваш сервер. Значение ожидания блокировки по умолчанию в Proxmox равно 180 минутам. В зависимости от различных виртуальных окружений и числа виртуальных машин, значение времени ожидания блокировки может иметь потребность в его увеличении. Если предел требует значения 10 часов, или 600 минут, отрегулируйте этот параметр следующим образом:

lockwait: 600
 	   

Блокировка предотвращает миграцию или выключение ВМ в процессе выполнения задачи резервного копирования.

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

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

script: /etc/pve/script/my-script.pl
 	   

Чтобы игнорировать определённые каталоги при резервном копировании воспользуйтесь параметром исключения пути. Все пути должны вводиться в одной строке без прерываний. Имейте в виду, что этот параметр действует исключительно для контейнеров OpenVZ:

exclude-path: "/log/.+" "/var/cache/.+"
 	   

Предыдущий пример исключит все файлы и каталоги в /log и /var/cache. Чтобы исключить вручную из резервного копирования другие каталоги, просто используйте следующий формат:

exclude-path: "/<directory_tree>/.+"
 	   

Говоря проще, pigz делает возможным применение множества потоков при множестве ядер в процессе резервного копирования со сжатием gzip. Стандартный процесс gzip использует единственное ядро, что объясняет более медленное резервное копирование. Используя пакет pigz, мы можем известить свой процесс резервного копирования применять множество ядер, тем самым ускоряя процесс резервного копирования и восстановления. Pigz в своей основе является gzip, однако с поддержкой множества ядер. По умолчанию он не установлен в Proxmox. Мы можем установить его при помощи следующей команды:

# apt-get install pigz
 	   

Чтобы разрешить pigz для резервного копирования, нам необходимо выбрать уровень сжатия для резервного копирования gzip в GUI. Затем, следующая опция pigz в файле настройки резервного копирования делает доступной функциональность pigz:

pigz: 1
 	   

По умолчанию, это значение установлено в значение 0 и используется для запрета использования pigz. Значение 1 использует половину от общего числа ядер в узле, в то время как значение, большее чем 1 создаёт заданной число потоков на основе этого значения. Определяемое значение не должно превосходить максимального числа ядер ЦПУ данного узла.

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

В следующей главе мы собираемся рассмотреть потребности поддержания кластера в соответствии с требованиями времени и то как применять новые редакции или исправления на регулярной основе.