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

Введение

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

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

Совместимость с любой гостевой операционной системой

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

Представьте, например, что агенты для вашего приложения резервного копирования совместимы только с Windows Server 2003 и Windows Server 2008. Это нормально, если вы используете только эти серверные операционные системы, но если у вас есть Серверы Linux или устаревшие серверы Windows.

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

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

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

Восстановление с нуля

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

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

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

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

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

Лицензионные сборы для приложений резервного копирования

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

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

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

Вывод

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

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