Аварийное восстановление для Hyper-V (часть 6)

Опубликовано: 22 Апреля, 2023

на нашу рассылку новостей о статьях VirtualizationAdmin.com в режиме реального времени

Введение

В предыдущей статье этой серии я рассказал о некоторых преимуществах резервного копирования VSS на уровне хоста. Поскольку я уже обсуждал основные недостатки резервного копирования на уровне хоста в части 4 этой серии, я хочу обратить внимание на резервное копирование на уровне гостя. Другими словами, я воспользуюсь этой возможностью, чтобы рассказать о преимуществах и недостатках резервного копирования отдельных виртуальных машин, а не резервного копирования вашего сервера Hyper-V в целом.

Гранулярность

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

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

Простота

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

Совместимость

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

Использование лицензии

Одним из возможных недостатков выполнения резервного копирования на уровне гостя является то, что вы можете использовать гораздо больше лицензий для своего приложения резервного копирования, чем если бы вы только что выполнили резервное копирование на уровне хоста. Большинство приложений резервного копирования, с которыми я работал, требуют приобретения лицензии агента для каждого сервера, для которого выполняется резервное копирование. Для выполнения резервного копирования на уровне хоста требуется только один агент (для которого обычно требуется одна лицензия), в то время как для резервного копирования отдельных виртуальных машин требуется отдельный агент для каждой виртуальной машины, что обычно требует (несколько лицензий).

Без восстановления исходного состояния

Возможно, самый большой недостаток выполнения резервного копирования отдельных виртуальных машин, а не резервного копирования Hyper-V в целом, заключается в том, что вы не сможете выполнить восстановление «с нуля», если в этом возникнет необходимость. Хорошо, я знаю, что на самом деле не существует такой вещи, как восстановление с нуля, когда вы имеете дело с виртуальными машинами, но позвольте мне объяснить, о чем я говорю.

Представьте на мгновение, что ваш сервер Hyper-V умирает ужасной смертью и вам необходимо полностью заменить серверное оборудование. После установки нового оборудования ваша следующая задача — установить Hyper-V, а затем вернуть все ваши виртуальные серверы в рабочее состояние. Достаточно легко, верно? Ну, не совсем.

Проблема с резервным копированием отдельных виртуальных машин заключается в том, что если вам нужно выполнить восстановление, ваше программное обеспечение для резервного копирования не распознает тот факт, что вы восстанавливаете виртуальный сервер. Хотя ваша резервная копия действительно содержит копию служб интеграции Hyper-V, виртуальная машина — это нечто большее, чем службы интеграции и операционная система Windows.

Если вы вспомните то время, когда вы первоначально настроили рассматриваемую виртуальную машину, вы вспомните, что вы должны были начать с предоставления Hyper-V некоторой базовой информации о ней. Например, вам нужно было указать Hyper-V, сколько памяти выделить виртуальной машине, какие файлы будут использоваться в качестве виртуальных жестких дисков, где эти файлы будут расположены и как виртуальная машина будет подключаться к вашей сети. Это (среди прочего) становится частью виртуальной машины.

Однако некоторые администраторы не понимают, что когда вы выполняете резервное копирование гостевой операционной системы, вы действительно копируете содержимое файлов виртуального жесткого диска виртуального сервера (файлы.VHD). Информация о низкоуровневой конфигурации, о которой я упоминал выше, не находится на виртуальном жестком диске. В конце концов, низкоуровневая информация о конфигурации сообщает Hyper-V, какие виртуальные жесткие диски использовать, поэтому Windows, безусловно, не может внедрить эту информацию в виртуальный жесткий диск.

Итак, что все это значит для того, кто должен восстановить отказавший сервер Hyper-V? Что ж, восстановить виртуальный сервер с помощью резервных копий гостевой операционной системы не представляется возможным. Просто процесс восстановления займет больше времени и потребует от администратора гораздо больше работы. Администратору придется вручную воссоздавать каждую виртуальную машину перед восстановлением отдельных резервных копий. Конечно, это верно только в случае катастрофического отказа. Если вам нужно восстановить только некоторые отдельные файлы, то восстановление виртуальной машины с использованием гостевой резервной копии ничем не отличается от восстановления на физическом сервере.

Вывод

Итак, теперь, когда я обсудил все плюсы и минусы, связанные с резервным копированием на уровне хоста и гостя, возникает большой вопрос, какой метод резервного копирования следует использовать. Я рекомендую использовать оба метода, но не делать это вслепую.

Я имею в виду, что большинство организаций должны убедиться, что их резервное копирование завершено в течение определенного периода времени (известного как окно резервного копирования). Также имеется ограниченный объем свободного места на резервном носителе. Проблема в том, что если вы выполняете резервное копирование как на уровне хоста, так и на уровне гостя, то вы выполняете резервное копирование большей части данных на сервере дважды. Это часто означает, что резервное копирование будет выполняться в два раза дольше и занимать вдвое больше места на вашем резервном носителе.

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