RAID контроллеры LSI и ПО

[IgorianT]

Здравствуйте, хочу спросить совета по работе с RAID контроллерами LSI и общие рекомендации, чтобы не вляпаться в следующий раз.
Нечаянно вытащил диск из корзины сервера SuperMicro, который входил в RAID1 на котором лежали SQL и файловые базы 1С и множество другой информации, соответственно диск вставил обратно. Но перед его включением в массив бегло просмотрел интернет на описание подобных ситуаций, и вроде бы везде всё просто диск из состояния OFFLINE переводят в ONLINE либо ищут как потерянный и всё хорошо работает дальше. Я так и сделал и после ввода на всякий случай запустил процедуру проверки консистентности массива (она шла около 8 часов и закончилась успешно, но не для меня).
На следующий день одна из файловых баз выпала с критической ошибкой - починил с помощью chkdbf, вечером переносил рабочую SQL базу 1С на новое хранилище и получил неисправимую ошибку в базе. Пришлось после попыток её реанимации откатываться на крайний доступный бэкап который оказался 2-ух дневной давности. Всё это время SQL база работала и ошибок не выдавала, только бэкап из неё не лился т.к. не проходила проверку целостности.
В результате сам себе создал проблему и потерял фрагмент информации из 1С SQL базы за 1.5 дня.

[Уваров А.С.]

Я так и сделал и после ввода на всякий случай запустил процедуру проверки консистентности массива (она шла около 8 часов и закончилась успешно, но не для меня).

Средствами контроллера? Тогда понятно.

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

Это вы еще легко отделались, у одного нашего клиента помощник админа таким макаром ушатал RAID6 на 3 ТБ - общий том для виртуальных машин. После этого около суток разворачивали машины из бекапов.

[IgorianT]

Залез в логи MegaRAID Manager к сожалению не нашел там никакой информации о фоновом ребилде, о проверке на консистентность и изменениях записи есть. Может я не прав поправьте я считал что
1. ребилд выполняется при вышедшем из строя диске массива и фактически эта таже проверка на консистентность и одновременно две процедуры над одним массивом выполняться не могут.
2. Сам контроллер должен знать что тот диск который был изъят уже не является родным либо эталонным для массива и должен быть проверен на зеркальность ONLINE диску, работавшему постоянно. Причем последний имеет наивысший приоритет над "потерянным" диском.
Получается чтобы так не попасть необходимо было вернуть диск в массив и оставить его в надежде на дальнейшую фоновую проверку. По работе сталкивался с разными контроллерами, но проблемы получил именно с LSI

[Уваров А.С.]

Сам контроллер должен знать

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

А чтобы не попасть нужно меньше заниматься самодеятельностью. Диск вновь введенный из OFFLINE или как потерянный в обязательном порядке проверяется на консистентность, на новый диск делается ребилд. Иначе массив не будет иметь статуса ONLINE или OK.