Для системного администратора

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

Почему готовность к аварийному восстановлению неизменно является одной из самых горячих тем в отрасли ИТ? Исследования показывают, что компании теряют в среднем 80 000 – 90 000 долларов США за час простоя и что очень немногие из компаний, страдающих от катастрофической потери данных, могут прожить долго. В этой статье будет представлено введение в аварийное восстановление с использованием платформы виртуализации Майкрософт, а также углубленное рассмотрение вариантов и соображений для резервного копирования и восстановления Hyper-V от Windows Server 2008.

Введение в планирование аварийного восстановления

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

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

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

Определения и приоритетность служб Что именно определяет службу, которую необходимо защитить, в целом и насколько важна она для организации?

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

Соглашения об уровне обслуживания (SLA) Соглашение об уровне обслуживания — это соглашение или контракт между поставщиком услуг ИТ и клиентской организацией, определяющее уровни доступности определенной службы. Они могут быть очень длинными, либо весьма короткими и благозвучными; например: «Система электронной почты будет доступна 99,95 процентов времени в течение основного времени работы предприятия и 98 процентов времени в течение прочего времени работы предприятия, исключая ежемесячные периоды запланированного обслуживания». Обычно эти соглашения разбиваются на уровни, устанавливаемые для заранее определенного промежутка времени, на которые можно назначать службы ИТ.

Соглашения об эксплуатационном уровне (OLA) Эти соглашения, по сути, описывают соглашения между различными группами ИТ, работающими над поддержкой соглашения об уровне обслуживания, включая соглашения о временах обработки и ответа для предоставления их служб. Предположим, что имеется необходимый для работы веб-узел с установленной целью соглашения об уровне обслуживания в 99,99%, но база данных, на которой размещено его содержимое, нацелена на доступность в течении лишь 95% времени. Соглашения об эксплуатационном уровне помогают прояснить эти несовпадения и направляют группы ИТ на единую цель.

Целевые точки и целевые значения времени восстановления (RPO/RTO) Целевое значение времени определяет, сколько служба может недоступной до возникновения разрыва в работе, а целевая точка — допустимый для организации уровень потерь данных. Следовательно, если соглашение об уровне обслуживания требует месячной доступности в 99%, то его целевое значение времени — 7 часов 18 минут. Если использовать сочетание с целевой точкой восстановления, скажем, в 24 часа, то можно точно определить свои методики и расписания резервного копирования.

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

Категоризация данных Следует также подумать о природе данных. Если разбить данные на категории, то можно сразу увидеть, что не всем данным требуется одинаковый уровень внимания к их аварийному восстановлению. Например, требования доступности к единственной базе данных могут отличаться от Active Directory с несколькими контроллерами домена, каждый из которых содержит копию каталога. Аналогично, процедуры восстановления для данных файлового сервера могут весьма сильно отличаться от процедур восстановления для данных CRM.

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

* Потеря всего филиала
* Потеря одного центра данных
* Потеря системы (операционной системы или сбой оборудования)
* Потеря данных (удаление или порча данных)
* Потеря ключевой зависимости

Очевидно, что для восстановления после потери целого филиала предъявляются совсем другие требования, чем после потери одной системы. Необходимо также определить пороги восстановления, основываясь на соглашении об уровне обслуживания. Например, предположим, что весь филиал перешел в автономный режим из-за крупного перебоя в работе сети поставщика услуг доступа к Интернету. Если соглашение об уровне обслуживания для затронутой службы предусматривает 8 часов на восстановление службы и 48 часов на восстановление данных, то можно будет выполнить процесс перевода службы на резервный узел, но не приступать к процессу восстановления данных, поскольку можно предвидеть скорое возвращение на рабочий узел.

Уф! Столько работы, и мы даже еще не начали говорить о технологиях! Важность планирования нельзя недооценивать. Реализация аварийного восстановления без документированного плана — это просто «надежда на аварийное восстановление».

Аварийное восстановление и виртуализация

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

В наше время господствует теория, согласно которой некоторые или все задачи аварийного восстановления можно решить с помощью решений высокой доступности (High Availability – HA). Идея состоит в том, что при наличии узлов кластеров в различных физических местоположениях с синхронизацией данных между узлами работа после сбоя может быть восстановлена на пассивном узле, что дает возможность восстановления почти в реальном времени.

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

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

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

Рис 2. Многоузловой кластер Hyper-V

В области репликации и синхронизации данных существуют некоторые весьма интересные разработки, но на данный момент Майкрософт не предоставляет их. В этой связи заслуживают внимания партнеры, представленные на странице многоузловой кластеризации Windows Server 2008 (microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx). Еще один материал — каталог Windows Server (см. windowsservercatalog.com), в котором перечислены поставщики хранилищ с технологиями репликации, сертифицированными для Windows Server 2008.

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

Преобразование физических систем в виртуальные

Очевидно, что виртуализация предлагает уникальные возможности восстановления, но как насчет физических систем, мало подходящих для виртуализации? В System Center Virtual Machine Manager (SCVMM) входит возможность выполнять преобразования работающих серверов Windows из физических в виртуальные (P2V), что приводит к созданию загрузочного виртуального компьютера Hyper-V, являющегося точной копией существующего физического сервера. Теперь этот виртуальный компьютер можно воспроизводить точно так же, как его виртуализованные аналоги, в других частях города или страны, добиваясь аналогичных времен восстановления.

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

Хотя в составе SCVMM нет планировщика для преобразований P2V, поскольку графический интерфейс целиком работает поверх Windows PowerShell, для этого легко создать сценарий, используя командлет New-P2V. На деле, все мастера в SCVMM будут показывать код, используемый ими для исполнения работы, а этот код можно скопировать из тестового P2V в своей среде и приспособить для дальнейшего автоматического использования. На Рис. 3 показан пример кода; мастер преобразования физических систем в виртуальные SCVMM можно запустить в своей среде для получения уникального и настраиваемого сценария Windows PowerShell.

$Credential = get-credentialNew-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"-Credential $Credential -RunAsynchronously$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup

e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"

-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External"

-MachineConfig $MachineConfig

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}

$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup

e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig

$Credential = get-credential

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}

$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path

"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup

e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig

$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM

-UseHardwareAssistedVirtualization $false -StopAction SaveVM

Рис. 3 Код, создаваемый мастером преобразования физических систем в виртуальные из состава SCVMM

Моментальные снимки виртуального компьютера

Хотя технически и не являясь резервной копией, моментальный снимок виртуального компьютера (VM) предоставляет точку во времени, к которой можно вернуться, используя разностные диски и копию файла настройки виртуальной машины. Если при аварии происходит случайное удаление данных внутри виртуального компьютера, это может считаться функцией аварийного восстановления, поскольку виртуальный компьютер можно откатить обратно до моментального снимка, устраняя ущерб. (Мгновенные снимки службы теневого копирования томов (Volume Shadow Copy Service – VSS) мы рассмотрим позже.)

Резервное копирование Hyper-V

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

Значительным улучшением в истории резервного копирования Windows Server стали выход Windows Server 2003 и распространение VSS, предоставляющего стандартный набор расширяемых интерфейсов API, используемых модулями записи VSS (привязками в приложениях и службах, помогающими предоставлять согласованные теневые копии) для создания резервных копий открытых файлов и приложений. С помощью службы, поставщиков и модулей записи VSS приложение резервного копирования может очень быстро создать копию тома на определенный момент времени, о которой оно будет осведомлено, и сможет обработать ее должным образом.

Hyper-V поставляется с собственным модулем записи VSS, позволяющим создателям программного обеспечения создавать свои привлекательные решения резервного копирования. Модуль записи позволяет приложениям резервного копирования создавать резервные копии VSS работающих виртуальных компьютеров на основе компьютера размещения. Если на операционной системе, работающей внутри виртуального компьютера, установлены компоненты интеграции Hyper-V, а также служба VSS (доступная в Windows XP с пакетом обновления 1, Windows Server 2003 и более поздних системах), резервное копирование на основе компьютера размещения будет происходить, как если бы оно выполнялось внутри гостевого компьютера; резервная копия будет создана на работающем виртуальном компьютере, и данные будут согласованы (см. Рис. 4).

Рис. 4 Резервное копирование VSS

Но если гостевая операционная система не поддерживает компоненты интеграции VSS, процесс резервного копирования потребует помещения гостевого компьютера в сохраненное состояние и снятия основанного на компьютере размещения моментального снимка VSS с файлов данных виртуального компьютера, который можно использовать для восстановления состояния на определенный момент времени. Моментальные снимки сохраненного состояния VSS вызовут некоторые простои виртуального компьютера (обычно их можно ограничить 5-10 минутами), а полные процедуры резервного копирования на ленту можно будет выполнить уже на основе созданной VSS копии данных.

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

Система архивации данных Windows Server

В Windows Server 2008 входит поддерживающая VSS система архивации данных Windows Server (Windows Server Backup – WSB), которую можно использовать для создания резервных копий Hyper-V своих виртуальных компьютеров на основе компьютеров размещения и гостевых компьютеров. Поскольку она полностью поддерживает VSS, она может создавать резервные копии работающих виртуальных компьютеров на основе компьютеров размещения, что, конечно же, предпочтительно.

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

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

Как вариант, резервное копирование можно выполнить изнутри виртуального компьютера, как если бы он был физическим компьютером, используя NTBackup или WSB, в зависимости от ОС в виртуальном компьютере. Давайте взглянем, как использовать WSB для поддерживаемых гостевых компьютеров, на которых установлены компоненты интеграции.

Резервное копирование виртуальных компьютеров с помощью WSB

Hyper-V не регистрирует свой модуль записи VSS для использования с WSB автоматически. Необходимо вручную ввести раздел и параметр реестра, показанные на Рис. 5, прежде чем WSB поддержит резервную копию Hyper-V. Их можно добавить посредством командной строки следующим образом:

reg add "HKLM\Software\Microsoft\windows nt\
currentversion\WindowsServerBackup\Application
Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
currentversion\WindowsServerBackup\Application
Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
"Application Identifier" /t REG_SZ /d Hyper-v

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

reg query "HKLM\Software\Microsoft\windows nt\
currentversion\WindowsServerBackup\Application
Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s

WSB устанавливается следующим образом. Нажмите кнопку Пуск и выберите пункт Server Manager (Диспетчер серверов). На левой панели выберите «Features» (Компоненты), затем нажмите кнопку «Add Features» (Добавить компоненты) на правой панели. На странице выбора компонентов разверните компоненты системы архивации данных Windows Server и установите флажки для системы архивации данных Windows Server и средств командной строки. Для настройки своего процесса резервного копирования выполните следующие действия:

1. Нажмите кнопку «Пуск», выберите «Администрирование» | «Система архивации данных Windows Server».
2. При резервном копировании удаленного компьютера размещения выберите подключение к удаленному компьютеру и наберите компьютер размещения Hyper-V.
3. Выберите либо однократное резервное копирование, либо копирование по расписанию.
4. Выберите настройку резервной копии — сервер целиком или специальную. Во втором случае убедитесь, что будут скопированы все тома, содержащие данные, относящиеся к нужному виртуальному компьютеру, включая данные настройки виртуального компьютера, виртуальные диски и моментальные снимки.
5. Выберите место для хранения резервной копии.
6. Выберите либо полную, либо копирующую архивацию VSS. Для резервного копирования на основе компьютера размещения, где с виртуальных компьютеров не снимается других резервных копий, выберите полную архивацию VSS.
7. После того, как все подробности подтверждены, выберите «Архивация».

О чем стоит подумать

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

Восстановление виртуальных компьютеров с помощью WSB

Хотя WSB и имеет возможность восстановления отдельных файлов, эта функция не использует VSS и, следовательно, может привести к несогласованному восстановлению, если виртуальный компьютер работал в момент создания резервной копии. Для восстановления работающих виртуальных компьютеров необходимо восстановить весь том (или тома).

Чтобы сделать это, необходимо нажать кнопку «Пуск» и выбрать «Администрирование» | «Система архивации данных Windows Server» и на панели «Действия» нажать кнопку «Восстановить». Выберите сервер, с которого восстанавливать данные (тот, где расположены данные резервной копии WSB), затем выберите дату, на которую следует восстановить данные. Теперь можно выбрать тип восстановления.

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

Рис. 6 Восстановление с резервной копии Hyper-V

Если необходим только сам виртуальный жесткий диск, а данные настройки и моментальные снимками виртуального компьютера работоспособны, можно выбрать «Файлы и папки» и подобрать нужный файл виртуального диска. Заметьте, что в этом процессе не используется модуль записи VSS; резервную копию виртуального компьютера необходимо создавать, не забывая об этом, начиная с сохранения состояния.

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

Data Protection Manager

Мы рассмотрели действия и соображения по резервному копированию и восстановлению для компьютеров размещения и гостевых компьютеров Hyper-V с помощью надежного и бесплатного встроенного WSB, но WSB не является решением для защиты данных корпоративного уровня. Там, где его возможности заканчиваются, эстафету принимает Data Protection Manager (DPM) 2007 с пакетом обновления 1. DPM с пакетом обновления 1, выпуск которого сейчас запланирован на конец 2008 года, будет поддерживать Hyper-V и предлагать ряд интересных функций:

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

•Репликация «сервер DPM – сервер DPM».

* Поддержка для дисковых и ленточных носителей (диск – диск, диск – лента или диск – диск – лента).
* Возможности резервного копирования и восстановления по всему спектру данных, включающему компьютеры размещения и гостевые компьютеры Hyper-V; резервное копирование работающих гостевых компьютеров VSS без использования агента; поддержка восстановления отдельных виртуальных компьютеров; данные отказоустойчивых кластеров; лучшие в своем классе функции для конкретных приложений, включая SQL Server, Exchange, SharePoint, Hyper-V и Virtual Server.
* Написание сценариев для действий до и после резервного копирования.

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

Создание резервных копий по сценариям

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

На Рис. 7 показаны некоторые команды WBAdmin. Полную документацию WBAdmin можно найти на go.microsoft.com/fwlink/?LinkId=124380. Как можно заметить, в WBAdmin нет ничего для настройки самой политики резервного копирования, но для управления этими параметрами существует оснастка Windows PowerShell. Можно провести тест, чтобы увидеть, зарегистрирована ли эта оснастка, с помощью следующей команды:

Get-PSSnapin -Registered

Рис. 7 Команды WBAdmin

А следующую команду можно использовать для загрузки оснастки, именуемой Windows.ServerBackup:

Add-PSSnapin windows.serverBackup

После ее загрузки будет получен доступ к командлетам Windows PowerShell для WSB, как показано на Рис. 8. Для вывода подробного описания каждого командлета выполните следующую команду:

Get-Command -PSSnapin windows.serverBackup | select name | get-help –full

Рис. 8 Командлеты программы архивирования данных Windows Server

Существует еще одна служебная программа, встроенная в Windows Server 2008, которая также использует модуль записи VSS в Hyper-V и добавляет определенную гибкость к имеющимся вариантам сценариев. DiskShadow.exe позволяет создать и подключить как диск теневую копию, что позволяет администраторам создавать более избирательные резервные копии, чем возможно при использовании WSB. И важно помнить, что программа DiskShadow не принимает входные данные из конвейера Windows PowerShell; вместо этого она требует передачи ей команд через сценарий, что может выглядеть примерно следующим образом:

Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit

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

Диск С: получит идентификатор GUID для своего определения, и этот идентификатор GUID будет сохранен в переменной среды, именуемой “MyShadow”. По завершении этого теневая копия создана.

Резервная копия предоставляется как диск X: при помощи переменной среды. С данными на X: можно проделать различные вещи, после чего программа DiskShadow может быть запущена снова с помощью команды Unexpose X: для удаления диска.
Отметьте, что восстановление виртуальных компьютеров Hyper-V, резервные копии которых были созданы с помощью DiskShadow, является в настоящий момент процессом, выполняемым вручную (виртуальный компьютер необходимо воссоздать, снимки не сохраняются и т. д.). Хотя у этого есть очевидные недостатки, данные оказываются защищенными.

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

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

Автор: Адам Фазио

Постовой

Мощный, но дешевый дизельгенератор можно купить только в компании «Пневмотехника»

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