Восстановление на «голое железо» для виртуальных машин в Hyper-V (часть 2)

Введение

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

Давайте начнем

Как вы помните из моей первой статьи, основной линией защиты, которую я использую для защиты своей сети, является Microsoft System Center Data Protection Manager 2007 (DPM 2007). Я настроил DPM 2007 на создание инкрементной резервной копии на уровне блоков каждого из моих виртуальных жестких дисков каждые пятнадцать минут.

Мне повезло: мой сервер DPM 2007 и массив хранения, подключенный к нему, пережили удар молнии. Однако одной из основных жертв стал хост-сервер Hyper-V, содержащий несколько критически важных виртуальных машин.

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

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

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

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

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

После того, как я восстановил работоспособность всех своих серверов, со мной начали происходить некоторые вещи. Во-первых, мой процесс восстановления занял целую неделю, что было бы совершенно неприемлемо для большинства организаций. Конечно, на ожидание замены оборудования ушло несколько дней, но даже сам процесс восстановления занял несколько дней. В некотором смысле этого следовало ожидать просто из-за огромного объема данных, которые я восстанавливал, но нельзя отрицать, что процесс пошел бы намного быстрее, если бы мне не приходилось выполнять два отдельных восстановления (восстановление из экспортированное изображение и второе восстановление из DPM 2007).

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

Прежде чем я расскажу вам о своей новой стратегии аварийного восстановления, я уверен, что некоторые из вас, вероятно, задаются вопросом, как DPM 2007 обычно способен восстанавливать сервер после катастрофического сбоя. Обычно, когда компьютер, защищенный DPM 2007, выходит из строя, остальные серверы в сети все еще находятся в сети. Пока Active Directory все еще работает, вы можете использовать консоль «Пользователи и компьютеры Active Directory», чтобы сбросить учетную запись «Компьютер» для отказавшего сервера.

Как я упоминал ранее, DPM 2007 зависит от Active Directory. Вы можете восстановить резервную копию только в том случае, если на защищенном сервере есть агент, способный взаимодействовать с сервером DPM. Кроме того, агент может быть развернут только в том случае, если сервер является членом домена.

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

Прежде чем вы сможете завершить процесс восстановления, вы все равно должны развернуть агент на сервере, но сделать это несложно. Вы можете использовать консоль управления DPM 2007 для развертывания агента, и после установки агента вы можете восстановить резервную копию сервера.

Однако даже этот метод не является полностью надежным. Как я упоминал ранее, это будет работать только до тех пор, пока активен каталог Active Directory. Другая проблема, связанная с этим методом, заключается в том, что Windows не позволит вам сбросить учетную запись компьютера для контроллера домена (по крайней мере, таким образом, чтобы облегчить замену мертвого сервера). Таким образом, метод, который я только что описал, можно использовать только для восстановления рядовых серверов. Это не будет работать для контроллеров домена.