Инструменты пользователя
Добавление пропавшего диска в пул DPM
Ситуация следующая. Банальная. В массиве RAID10 вышел из строя один диск. Моментально подхватился запасной и массив успешно перестроился. Мертвый диск перестал видеться в системе.
Все бы хорошо, но!.. После перезагрузки он начал видеться, зато перестала загружаться система вовсе! – такое бывает, когда на контроллере есть совсем уже плохой диск и в этом случае, если в UEFI нет возможности отключить канал программно, помогает только физическое отключение диска, однако, сразу добраться до сервера не было возможности и на ночь я его просто выключил.
Утром решил зайти в UEFI дабы уточнить, на каком конкретно порту висит больной диск, и внезапно оказалось, что диск в общем-то жив и сейчас пребывает в состоянии потерянного… Затем он прекрасно сбросился в состояние «Non RAID»1), а система вполне бодро запустилась…
Что это был за морок пока не понятно, ибо пока нареканий на диск нет – у него и SMART в норме, он и форматируется и вообще работает… и даже Victoria HDD очень бодро и без нареканий его сканирует… Хмм?
Проблема
Однако, в связи со всеми этими пертурбациями, этот диск пропал из пула носителей Data Protection Manager 2019. Точнее не совсем пропал – строчка в оснастке DPM на закладке «Управление» в разделе «Дисковый накопитель» была, но все цифровые колонки были по нулям, а на закладке «Наблюдение» куча критических предупреждений «Отсутствует том» с текстом «Данные для восстановления <НАЗВАНИЕ> на <НАЗВАНИЕ> в группе защиты <НАЗВАНИЕ> находятся в томе, который не удалось обнаружить. Все последующие действия по защите, связанные с источником данных <НАЗВАНИЕ>, будут завершаться ошибкой до тех пор, пока этот том не вернется в оперативный режим или реплика не будет создана повторно. (ID: 3101)»2) и несколько «Том пула хранилища отсутствует» с «Том пула хранилища DPM <БУКВА> отсутствует. (Идентификатор 33518)». Также эти ошибки дублировались в оснастке «Просмотр событий» с кодом события «3101» от источника «DPM-EM».
В проводнике же этот раздел выглядел, в одном случае, как обычно, но с другой буквой, а в другом, вовсе отсутствовал. Со старой же буквой висел некий недоступный раздел.
В оснастке же «Управление дисками» отображался виновник событий, по объему равный всему массиву RAID10, чего, понятно, быть не могло, ибо каждый диск, это 1/2 от общего объема, с RAW-разделом, который как раз и имел букву старого. В случае, если в проводнике нет «рабочего» массива, тут, в оснастке, он будет отображаться в режиме «Вне сети».
Вот тут-то собака, вероятно, и порылась! Не могу гарантировать, но предположу, что в системе этот диск оказался со старым GUID, а восстановленный массив этот GUID поменял… или наоборот… или как-то так… но, не важно! Главное, что проблема крылась именно в появлении в системе вывалившегося ранее из массива диске. Если бы он не ожил или если бы я его еще в BIOS сразу же пометил, как «запасной», и в системе он бы не отразился, то, скорее все, проблемы можно было бы избежать. Но, как получилось.
Пошел гуглить.
- Совет от Microsoft был краток и бесполезен, ибо нажатие кнопки «Повторное сканирование», это и так было первым, что я сделал.
В общем, я уже устал искать, а Интернет все не давал хоть сколько-нибудь полезную подсказу, хотя надежда оставалась, ибо сами по себе данные и их структура остались же целыми и не тронутыми! Осталось придумать, как…
Изыскания
Для начала я удалил RAW-раздел выпавшего диска, через diskpart очистил всю информацию на нем и отформатировал в NTFS, указав самую дальнюю букву. После этих стандартных манипуляций он приобрел нормальный вид, как и должен выглядеть диск на 2 терабайта3). Вернул разделу с данными старую букву.
Потом, для полноты картины, добавил этот пустой диск в пул дисков DPM с меткой «test» и от балды, ибо это совершенно не важно, т.к. необходимо, чтобы процесс просто запустился, назначил на него задание защиты. Наконец запустил SQL Server Management Studio, открыл базу данных «DPMDB_<НАЗВАНИЕ>» и углубился в изучение таблиц!
Список дисков для пула я обнаружил в таблице «tbl_STM_Volume»4), а соответствия томов реплик с их хранилищами в таблице «tbl_PRM_ReplicaVolume».
Решение
Далее оказалось все максимально просто:
- закрываем оснастку DPM, останавливаем службы DPM и DPM AccessManager выполнив команду
net stop MSDPM & net stop DPMAMService5); - открываем в SQL Server Management Studio (SSMS) на чтение6) таблицу «tbl_STM_Volume» и копируем все содержимое в блокнот;
- далее действуем в зависимости от того, производились ли какие-то действия, к примеру, описанные в разделе выше:
- открываем для изменения9) таблицу «tbl_STM_Volume» и удаляем из нее строку, у которой «Status» равен «1»;
- сохраняем, закрываем и перезагружаемся!
После этих манипуляций диск отобразился в пуле носителей DPM, на закладке «Восстановление» все вернулось на места, а задания начали успешно выполняться. 
Дисклеймер
- Использование материалов данной базы знаний разрешено на условиях лицензии, указанной внизу каждой страницы! При использовании материалов активная гиперссылка на соответствующую страницу данной базы знаний обязательна!
- Автор не несет и не может нести какую либо ответственность за последствия использования материалов, размещенных в данной базе знаний. Все материалы предоставляются по принципу «как есть». Используйте их исключительно на свой страх и риск.
- Все высказывания, мысли или идеи автора, размещенные в материалах данной базе знаний, являются исключительно его личным субъективным мнением и могут не совпадать с мнением читателей!
- При размещении ссылок в данной базе знаний на интернет-страницы третьих лиц автор не несет ответственности за их техническую функциональность (особенно отсутствие вирусов) и содержание! При обнаружении таких ссылок, можно и желательно сообщить о них в комментариях к соответствующей статье.
Обсуждение