Ситуация следующая. Банальная. В массиве 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 сразу же пометил, как «запасной», и в системе он бы не отразился, то, скорее все, проблемы можно было бы избежать. Но, как получилось.
Пошел гуглить.
В общем, я уже устал искать, а Интернет все не давал хоть сколько-нибудь полезную подсказу, хотя надежда оставалась, ибо сами по себе данные и их структура остались же целыми и не тронутыми! Осталось придумать, как…
Для начала я удалил RAW-раздел выпавшего диска, через diskpart очистил всю информацию на нем и отформатировал в NTFS, указав самую дальнюю букву. После этих стандартных манипуляций он приобрел нормальный вид, как и должен выглядеть диск на 2 терабайта3). Вернул разделу с данными старую букву.
Потом, для полноты картины, добавил этот пустой диск в пул дисков DPM с меткой «test» и от балды, ибо это совершенно не важно, т.к. необходимо, чтобы процесс просто запустился, назначил на него задание защиты. Наконец запустил SQL Server Management Studio, открыл базу данных «DPMDB_<НАЗВАНИЕ>» и углубился в изучение таблиц!
Список дисков для пула я обнаружил в таблице «tbl_STM_Volume»4), а соответствия томов реплик с их хранилищами в таблице «tbl_PRM_ReplicaVolume».
Далее оказалось все максимально просто:
net stop msdpm
5);
После этих манипуляций диск отобразился в пуле носителей DPM, на закладке «Восстановление» все вернулось на места, а задания начали успешно выполняться.
Обсуждение