Главная > Bare Metal Recovery > Все, что вы хотели знать о DPM 2010 Bare Metal Recovery, но боялись спросить (часть 3)

Все, что вы хотели знать о DPM 2010 Bare Metal Recovery, но боялись спросить (часть 3)

Сейчас уже сложно сказать, кто является автором расхожего убеждения о том, что технология Bare Metal Recovery в DPM позволяет восстановить сервер на отличное от изначального аппаратное обеспечение. На данный момент эта информация получила очень широкое распространение, встречается в различных источниках и переведена на множество языков. Вырванное из контекста огромного списка условий и требований это утверждение, на мой взгляд, является серьезным заблуждением. В третьей части цикла статей, посвященного BMR, мы рассмотрим этот вопрос подробно.

Итак, кто-то когда-то решил заявить в функционале DPM 2010 возможность восстанавливать исходное состояние системы серверов Windows 2008 и Windows 2008 R2 на «другое железо». Сделано это было, вполне очевидно, для дополнительной раскрутки продукта на тесном рынке решений для резервного копирования. Это привело к тому, что спустя год после выхода продукта, часто можно встретить просьбы о помощи и вопросы, связанные с различными проблемами, проявляющимися после выполнения таких восстановлений. Вполне ожидаемым было и появление администраторов, получивших синие экраны смерти при крайне неверной трактовке заявленного функционала — использовании BMR для миграции с физических серверов в виртуальные.

В чем же подвох? Ведь даже разработчики DPM в своем блоге указывали на то, что это работает (Performing a Bare Metal Restore with DPM 2010):

Since theoretically the system in question is completely down (due to corruption of the operating system) or even new (in the case of hardware replacement), I have discovered is that the easiest way to restore these systems is by booting to the Windows media (Windows 2008 or Windows 2008 R2 DVD) and initiating the recovery.

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

Как мы знаем из первой части статьи, для осуществления защиты исходного состояния системы DPM использует компонент операционной системы – систему архивации данных Windows Server (Windows Server Backup, WSB). Если быть точным, получение актуальной резервной копии BMR защищаемого сервера происходит следующим образом: агент экземпляра SQL сервера, на котором находится база данных DPM по заданному в свойствах группы защиты расписанию инициирует выполнение задачи, которая через службу агента на защищаемом сервере стартует файл сценария BmrBackup.cmd, находящийся в папке C:\Program Files\Microsoft Data Protection Manager\DPM\bin. Структура файла очень проста:

@echo off

if not exist %SystemRoot%\system32\wbadmin.exe goto returnError

rem Start a wbadmin.exe to create a BMR backup
start  /WAIT %SystemRoot%\system32\wbadmin.exe start backup -allcritical -quiet -backuptarget:%1

rem If return error code, Pass this error code to caller else check whether it actually succeeded or not
if %ERRORLEVEL% == 0 goto returnSuccess
exit /B %ERRORLEVEL%

:returnSuccess
exit /B 0

:returnError
exit /B 1

Жирным шрифтом я выделил интересующую нас команду. Через переменную %1 агент защиты передает в сценарий путь к репликам на сервере DPM.

Как мы видим, все банально. И если вы готовы отказаться от централизованного мониторинга, отчетов, единой консоли и прочих прелестей «правильного» администрирования, все это можно сделать и вручную. Особенно принимая во внимание требование лицензии Enterprise ML для защиты BMR и необходимость кучи манипуляций для его восстановления. При восстановлении BMR, DPM просто вывалит копию данных в указанную администратором папку и дальше все придется делать вручную. Восстановление BMR на исходные тома сервера целиком отдано тому же компоненту архивации, присутствующему в среде восстановления Windows (Windows Recovery Environment, WinRE) загружаемой с установочного диска.

Если все действия по резервному копированию и восстановлению выполняет система архивации данных, то можно посмотреть — а что говорит документация к этому компоненту ОС о восстановлении BMR на отличном от изначального аппаратном обеспечении. На эту тему есть очень подробный, постоянно обновляемый документ — How to move a Windows installation to different hardware (и не вздумайте читать унылую поделку, датированную 2007-ым годом, которой является русскоязычный перевод этой статьи.) Указанная публикация проливает свет на условия успешности восстановления резервной копии BMR:

  1. HAL (слой аппаратных абстракций) исходного и конечного серверов должен совпадать (здесь и далее исходный сервер — источник резервной копии, конечный — сервер, на котором планируется восстановление). Единственное исключение здесь — многопроцессорный ACPI (усовершенствованный интерфейс конфигурации и управления питанием) может быть восстановлен на однопроцессорный ACPI и наоборот. Тоже самое касается однопроцессорной и многопроцессорной MPS (мультипроцессорной спецификации).
  2. Версии операционных систем исходного и конечного серверов должны совпадать. В контексте BMR это можно изложить так — необходим загрузочный диск с дистрибутивом ОС, совпадающей с той, которую необходимо восстанавливать (обязательно соответствие платформ х86 или х64 дистрибутива и ОС, с которой был создан архив).
  3. Удалите сторонние драйверы-фильтры на исходном компьютере перед выполнением резервного копирования. Этот тип драйверов может являться источником проблем при восстановлении на другое аппаратное обеспечение.
  4. Удаление на конечном компьютере любого аппаратного компонента, присутствие которого не требуется для завершения процесса восстановления, повышает вероятность успешного восстановления.
  5. Жесткие диски конечного сервера должны быть большего или одинакового с исходным сервером размера.
  6. ОС архитектуры х86 может быть восстановлена только на конечный сервер с процессором архитектуры х86 или х64, ОС х64 — только на сервер х64 и IA-64 (Itanium) только на IA-64.

Неслабый список, особенно оговорки про удаление драйверов. И, на мой взгляд, от некоторых пунктов явно отдает неуверенностью в благоприятном исходе восстановления. Но, таки, работает же. И при выполнении условий, описанных в статье базы знаний, даже официально поддерживается. Только вот, применительно к DPM, почти все эти оговорки куда-то пропали. Заявляется поддержка восстановления на другое аппаратное обеспечение без условий, «прямо из коробки», ставь и пользуйся. Как-то не совсем корректно. Тут отлично подходит старая поговорка — «Доверяй, но проверяй».

В следующей части мы рассмотрим методику эффективной защиты и восстановления BMR для серверов с «сюрпризами» на системном разделе, вроде папки C:\ClusterStorage на несколько терабайт.

Предыдущие части доступны по ссылкам:

Все, что вы хотели знать о DPM 2010 Bare Metal Recovery, но боялись спросить (часть 1)

Все, что вы хотели знать о DPM 2010 Bare Metal Recovery, но боялись спросить (часть 2)

Все, что вы хотели знать о DPM 2010 Bare Metal Recovery, но боялись спросить (часть 4)

Реклама
Рубрики:Bare Metal Recovery Метки: , , ,
  1. Александр Ващуков
    11.10.2011 в 17:50

    Спасибо за заметку! Вот бы прочитать её на пару месяцев по раньше. Не пришлось бы тратить кучу времени ходя по граблям.

  2. 12.10.2011 в 09:37

    >Сейчас уже сложно сказать, кто является автором расхожего убеждения о том, что технология Bare Metal Recovery в DPM позволяет восстановить сервер на отличное от изначального аппаратное обеспечение

    Хмм…
    >7. С помощью BMR можно восстановить сервер на отличную от оригинальной аппаратную платформу.
    https://ystartsev.wordpress.com/2010/08/18/dpm2010bmr/
    Как вариант :)

    • 12.10.2011 в 09:41

      Да, я как раз думал об этом, когда писал третью часть — я тоже поучаствовал в распространении неполных сведений :D
      Но до авторства далеко. Добавлю-ка я туда ссылку. И спасибо за напоминание.

  3. 12.10.2011 в 10:04

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

    А вообще за тему спасибо, довольно полезно для меня

  4. 1
    25.10.2011 в 22:04

    Спасибо! Продолжайте в том же духе!

  5. Tamaz
    28.03.2013 в 14:49

    Да уж проблема с откатом на другое железо все еще не решена. Спасибо за статью, позновательно

  6. Константин
    10.11.2013 в 18:24

    Вот здесь http://support.microsoft.com/kb/249694#method3 говорится о том, что BMR на отличное от оригинального железа будет работать (привожу выдержку):

    — Server unbootable/Server-migration scenario (planned and unplanned):

    In this scenario, you can protect the server by performing a BMR backup of all critical volumes on the server. You then recover the server by performing a BMR recovery through Windows Recovery. In this scenario, BMR is supported to different hardware.

    P.S. У вас статьи написаны очень понятным языком — спасибо ! :)

    • 11.11.2013 в 10:28

      Константин, спасибо за информативный комментарий и положительный отзыв :)

  1. 11.10.2011 в 17:30
  2. 12.10.2011 в 09:45
  3. 18.03.2013 в 15:57

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: