Халатность сисадмина

Однажды утром раздался звонок. Молодой человек сообщил, что у него упал RAID5 массив из пяти SCSI винчестеров и требуется восстановление данных. Сказал что из области и приедет через пару часов. С учетом московских пробок приехал только под закрытие, оставив нам на диагностику полчаса. Сервер привез целиком, около 30 кг :)

Получаса хватило, что бы констатировать страшный факт. Данные на всех винчестерах из массива: уничтожены!!!

Со слов системного администратора, ситуация была следующая. Сервер работал, к нему обращались пользователи…. документы, 1С бухгалтерия и т.п. Заметили, что к одному из дисков нет обращения, не моргает лампочка. БИОС RAID контроллера показывает что массив поврежден (Array DEGRADED), но данные при этом читаются, хоть и скорость работы сервера заметно упала. Решили сделать «благое» дело. Вставить вместо сломанного винчестера новый и воспользоваться функцией REBUILD. Собственно RAID5 на это и рассчитан. После долгой работы REBUILD сервер перестал загружаться вообще.

Когда диски попали к нам, на обычном SCSI контроллере, через ДискЕдитор, на всех дисках были видны НУЛИ, по всей поверхности.

.RAID5 организован таким образом, что данные пишутся секторами на все диски последоватьно, то есть данные существуют на всех дисках одновременно. На примере RAID5 из 5 дисков, четыре сектора запишутся последовательно на четыре диска, а на пятом сформируется специальная контрольная сумма от этих четырех секторов, и так далее, до конца дисков. Сектора с контрольной суммой циклически повторяются и перемещаются последовательно по всем дискам в массиве. Сделано это для того что бы при выходе из строя любого одного диска, можно вставить исправный чистый диск, сделать ребилд, с помощью контрольных сумм чистый диск заполнится информацией сломанного, и рейд продолжит функционирование, в обычном режиме. RAID может работать и в аварийном режиме, то есть: «на ходу» ломается диск, контроллер продолжит высчитывать контрольную сумму, но не писать её на диски, скорость его работы при этом замедляется, RAID начнет противно пищать.

В данном случае, вместо пересчета с рабочих дисков с информацией на новый чистый, REBUILD произошел «наоборот». Нули с нового диска записались на все остальные, тем самым данные уничтожились.

Вывод

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

Это был заказ №5808

Добавить oтзыв

[1-5]

Михаил (27.01.2009 08:12)

Доброго времени суток, коллеги! С интересом читаю описаные Вами случаи потери данных. Разумеется следует копировать данные прежде чем предпринять какие либо действия с винчестером. Это обычная разумная мера предосторожности. Однако не всегда это возможно сделать. Описаный Вами случай (заказ №580 очень похож либо на ошибку в контроллере RAID (сервер самодельный или noname) или же это ошибка оператора (сисадмина) если ребилд инициируется явно оператором а не автоматически контроллером как и должно быть. Ведь на то и контрольные суммы что бы восстанавливать данные на новый диск! это грубейший брак контроллера или вообще дешевая поделка если контроллер не понимает что куда переносить - данные с контр суммой на ЧИСТЫЙ диск или НИЧЕГО с этого читсого диска неважно куда.... Какой то странный случай Вы описываете и нет внятной информации - почему же так произошло? В чем причина такого странного поведения RAID ....

ответить на это сообщение

Admin: В данном случае мы не ставили целью выяснить почему это произошло, да и времени не было выяснять особенности работы используемого контроллера, так как нам его не оставляли. Отчасти я с вами согласен, что использование рейд массивов с избыточностью предполагают восстановление их работоспособности при выходе из строя одного (или двух) НЖМД. Основная ошибка сисадмина, как нам кажется, заключалась в том, что массив работал и "...данные при этом читаются, хоть и скорость работы сервера заметно упала." и надо было бы в это время копировать необходимые данные, а лишь потом производить все дальнейшие манипуляции. А также никто не мешал снять образа еще рабочих винчестеров. Как показыват опыт нашей работы действительно потеря данных может случиться как по вине аппаратных средств (рейд контроллеров), так и по вине оператора, который либо по не знанию, либо по неопытности, либо потому что "понадеялся" на контроллер, запустил "долгие" процессы.

Витун (26.05.2008 03:23)

На кой хрен тогда нужен этот RAID5 если REBUILD будет идти с потерей данных. Тут проблема в другом. Так сказать человеческих фактор.

ответить на это сообщение

Admin: Об этом и речь.

Александр (11.01.2008 19:12)

дело было не в ребилде, он идет без проблем и потери данных, а сисадмин нажал кнопку инициализации массива... операция легкодоступная в аппаратном рэйд контроллере , но совершенно деструктивная... я так уже терял данные. (на intel srcs16) Рабочий массив НЕЛЬЗЯ инициализировать - затрёт нулями.

ответить на это сообщение

Дмитрий (03.01.2008 20:44)

А смысл тогда делать rebuild, если теряешь данные???

ответить на это сообщение

Admin: вообще они не должны пропасть, но как известно в компьютерной технике бывает такая вещь как ГЛЮКИ. Плюс допустим вылет еще одного жесткого диска в процессе ребилда, хотя такое редко бывает.

Виталий (22.10.2007 19:26)

хм... я всегда думал что REBUILD идет с потерей данных. Кроме того, у разных контроллеров свое представление о RAID и командах.

ответить на это сообщение