У данной схемы есть ряд преимуществ (догадаться о которых не составляет особого труда), главное из которых состоит в легкой переносимости управляющего сервера в случае острой необходимости на любой физический сервер с ролью HYPERV. Само собой подразумевается наличие отдельного массива на управляемом сервере под группы хранения или хранилищ типа DAS/SAN.

Итак, если возникла вышеописанная ситуация, то первое с чем мы столкнемся после установки DPM – это потенциальная невозможность работы (установки) агента DPM на управляемом сервере. Потенциальная именно из-за того, что ее может и не быть. А будет она в том случае, если у физического сервера имеется по меньшей мере два активных (но не обязательно подключенных) сетевых интерфейса (что является нормой в наше время). Все дело в том, что данный продукт плотно использует архитектуру DCOM, что подразумевает наличие источника данных (как на управляющем сервере, так и на управляемом) и множества клиентов, обращающихся к источнику. DCOM за все время своего существования не претерпел сколь-либо значимых изменений. Эта технология на основе разновидности RPC позволяет COM-компонентам взаимодействовать друг с другом по сети. Сеть является ключевым моментом в описываемой ситуации. Поскольку мы имеем дело с HYPERV, то реализация виртуальных сетевых интерфейсов подразумевает ряд неких программных ухищрений (довольно размыто описанных самой Microsoft), которые, возможно, кроют в себе причину в невозможности нормального взаимодействия между службами DCOM на обоих серверах. Есть подозрения, что использование собственной DCOM-технологии является одной из причин, по которой невозможно резервировать сервер, на котором стоит продукт MS SC DPM2007.

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

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

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

Но мы столкнулись с ситуацией, что старые резервные копии DPM не удаляет. Они так и копятся на диске – и, рано или поздно, наступает время, когда места под новую резервную копию уже не хватает, и DPM вываливается с ошибкой «Recovery Point Volume threshold exceeded».

Для удаления устаревших резервных копий в DPM есть скрипт PruneShadowCopies.ps1, который можно запустить и вручную. Но – данный скрипт не работает. Выдает ошибку:


Index operation failed; the array index evaluated to null.
At C:\Program Files\Microsoft DPM\DPM\bin\pruneshadowcopies.ps1:205 char:18
+     $replicaList[$ <<<< inactiveDs.ReplicaPath] =
$inactiveDs.RecoveryRangeinDays
Index operation failed; the array index evaluated to null.
At C:\Program Files\Microsoft DPM\DPM\bin\pruneshadowcopies.ps1:206 char:23
+     $latestScDateList[$ <<<< inactiveDs.ReplicaPath] = new-object DateTime


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

В июне 2009 года Microsoft выпустила обновление 970267 для Data Protection Manager, среди прочих решающее и эту проблему. Скачать его можно здесь. Процесс установки таков:

• Скачиваем три файла, нужной нам платформы – в зависимости от того, 32- или 64-битная версия DPM установлена у нас. Кстати, ставится это обновление на Data Protection Manager 2007 Service Pack 1.
• Запускаем файл DataProtectionManager2007-KB970867.exe и производим обновление сервера. Чтобы не перезагружать сервер после обновления – убедимся, что DPM Administrator Console и DPM Management Shell не запущены.
• Если база данных SQL, в которой хранится конфигурационная информация DPM, находится не на том же сервере, где сам DPM – запускаем на этом сервере файл SqlPrep-KB970867.msp. Если мы ставили SQL Express вместе с DPM на ту же машину - обновление запускать не нужно.
• Если мы используем DPM Management Shell не на том же сервере, где сам DPM – запускаем на этом сервере файл DPMManagementShell2007-KB970867.msp. Если все находится на одном сервере – обновление запускать не нужно.
• Заходим в DPM Administrator Console, выбираем Management – Agents, и обновляем все клиентские агенты DPM до новой версии – версия DPM и агентов после этого обновления становится 2.0.8844.0. При обновлении нужно указать Manual restart – потому что на самом деле перезагружать серверы не нужно.

Все. После завершения обновления скрипт PruneShadowCopies.ps1 должен выполняться без ошибок.

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


$VerbosePreference = "continue"


После этого запускать скрипт.