На вторичном сервере DPM (Secondary DPM) в одной из Protection Group, в которую были включены кластеризованные виртуальные машины Hyper-V, для некоторых виртуальных машин перестало работать создание точек восстановления по расписанию. Попытка вручную выполнить Consistency Check приводила к ошибке:
An unexpected error occurred while the job was running. (ID 104 Details: The device is not connected (0x8007048F))
Решение было обнаружено здесь: Secondary DPM does not sync with primary (3170 / 8007048F). Смысл его заключается в том, чтобы проверить на первичном сервере DPM наличие логических дисковых томов не имеющих информации о типе файловой системы (RAW тома), и если таковые будут обнаружены, – удалить их.
Быстро проверить на первичном сервере DPM (Primary DPM) список томов отобрав только те, у которых нет информации о типе файловой системы можно, например с помощью PowerShell:
Get-Volume | Where {$_.FileSystem -eq ""}
Если посмотреть в оснастку управления дисками diskmgmt.msc, там мы обнаружим это же количество томов без определения файловой системы, а также сможем увидеть их размер:
Чтобы исправить ситуацию, откроем командную строку с правами Администратора и вызовем утилиту DISKPART. Получив приглашение командной строки этой утилиты, чтобы получить список всех логических дисковых томов, выполним команду:
list volume
Внимательно просмотрим список томов и выпишем номера томов, которые не имеют определения файловой системы.
Выписываем себе номера RAW томов (в моём случае было обнаружено 3 таких тома - 78, 138, 143). Далее будем делать эти тома текущими и удалять. Удалять надо снизу вверх, то есть сначала тома с бОльшими номерами, так как после удаления выбранного тома нумерация всех томов сдвигается. Итак, выберем проблемный том с самым большим номером:
select volume=143
После того, как утилита сообщить о том, что том успешно выбран, выполняем удаление текущего выбранного тома командой:
delete volume
Таким образом удаляем все обнаруженные RAW тома.
После удаления повторно проверяем наличие проблемных томов любым ранее описанным методом, и если они отсутствуют, снова запускаем на вторичном сервере DPM процедуру Consistency Check, которая в этот раз должна пройти успешно.
Доброго времени суток. Скажите, никак ни где не наткнусь на разъяснение одного момента. Вы часто пишете о вторичном сервере DPM. Ткните где можно прочесть или понять что это. У нас возник вопрос о бекапи юзерских данных. Хотим купить два сервера 12 юнитовых и на них лить порядка 200 пользователей. Так вот и думаю, может есть какая то система объединения DPM серверов. Но что то не видел. Сейчас вся серверная инфраструктура бекапится именно им.
https://blog.it-kb.ru/2010/05/27/disaster-recovery-in-dpm-2010/
Алексей, спасибо! Не знаю почему не наткнулся на эту статью ((( Теперь все понятно. Ну значит буду рулить двумя серверами ..