26 ноября 2020, 12:17

Цитата дня:

Если захламленный стол означает беспорядок в голове, то что же означает пустой стол? Альберт Эйнштейн


Проблемы с Raid в NAS Thecus N12000

Автор FloXtoN, 09 января 2020, 20:42

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

Вниз

FloXtoN

После праздников, после включения NAS Thecus N12000, выяснилось что исчез Raid.
В данном NAS установлены 12 HDD по 4Тб каждый, 10 из них были соединены в Raid10 и 2 добавлены как Hot Spare.
Через телнет подключился и сделал восcтановление командой
mdadm --assemble --scan
Вместо md0, md 10 и  md50, получил кажется 6 штук, 3 из них были из одного диска. Разобрал все массивы с помощью команд
mdadm -S /dev/md*
Извлек диск который был отдельно, опять собрал через --scan.
Диски собрались почти мгновенно, но каталоги не появились, да и в информации о Raid'e не появилось о объемах занятого данными места.
Причем при сборке порядок дисков был непонятный, вперемешку. Убрал один из дисков который должен быть Hot Spare. Запустился ребилд raid массива.
Шел более 6-ти часов, но в результате, опять нет ни каталогов, ни информации о занятом данными месте.

Подскажите что делать, на дисках есть данные резервных копий которых не существует. Как можно собрать правильно Raid или восстановить данные с имеющихся дисков?

P.s. Ответить на вопросы смогу только завтра с утра, примерно с 9-ти часов по Москве.

Уваров А.С.

Подскажите что делать, на дисках есть данные резервных копий которых не существует.
В свете вышеописанного вот это вы сделали зря:

mdadm --assemble --scan
Остается надеяться, что вы знали как именно физические диски были объединены в массивы, что позволит попробовать собрать хотя бы часть массива, собрав RAID 0 хотя бы из двух дисков.



FloXtoN

Ясно, значит буду завтра дальше экспериментировать.  :-\

Уваров А.С.

Либо попробуйте R-Studio, она вроде бы умеет автоматически собирать разваленные массивы и поддерживает восстановление данных с Ext.

FloXtoN

Почитав статьи по восстановлению пришел к тому же, но у меня нет оборудования, для подключения одновременно всех 12 дисков, так что буду подключать по одному и сканировать, чтобы вытащить пофайлово.

Уваров А.С.

#5
10 января 2020, 09:02 Последнее редактирование: 10 января 2020, 09:06 от Уваров А.С.
По одному не получится, вам, как минимум нужно собрать живой страйп.

А портов можно и быстро добавить, купив что нибудь подобное: https://www.citilink.ru/catalog/computers_and_notebooks/parts/controllers/504733/

FloXtoN

Мне повезло, убрал диск из-за которого произошло разрушение Raid'a, вчера в том же варианте собирался, но данные не давал, сегодня же после запуска NAS все заработало само.
Так что сейчас активно сливаю данные которые не резервировались, после этого будем тестировать отдельно каждый диск, по необходимости менять, а потом собирать Raid заново.

P.s. Винчестер, который стал причиной падения, содержит 202 сбойных сектора были перенесены в незанятую область, при самотестировании найдено еще 1124, кроме того еще и 1130 секторов отмечены как слабые (софт бэд блоки). И при этом S.M.A.R.T. пишет что все GOOD. И как такую проблему отслеживать, с учетом того что на NAS'е нет возможности делать проверку на бэд блоки по расписанию.  :(

Уваров А.С.

Для современных дисков это "нормально", в статье про RAID мы как раз писали об этом: https://interface31.ru/tech_it/2019/05/raid-likbez.html
Если большую часть диска занимают "холодные" данные, то вероятность того, что диск сам обнаружит сбойный сектор, сделает его ребилд и просигнализирует в SMART крайне мала.

Проверять по расписанию - это тоже не выход, при современных объемах данных это будет занимать существенное время.

Выход - не использовать уровни RAID критичные к подобным отказам и регулярно делать бекапы.

Скажем RAID5 на массивах от 12 ТБ - это 100% способ угробить данные, даже без бед-блоков на дисках. В то время как RAID10 в 67% случаев переживет выход сразу двух дисков (здесь имеем ввиду не только физический выход из строя дисков, но и повреждение одинаковых областей с данными).

Также не стоит набирать большие массивы из дисков одной партии, лучше закупиться понемногу, но в разных местах. Дело не только в производственном браке, но и в условиях их хранения и транспортировки. Если ящик с винтами уронили на складе в магазине, то покупателей такой партии могут ждать неприятные сюрпризы.

P.S. Я в свое время успел поработать в компьютерном магазине, так что прекрасно знаю изнутри как разгружают, хранят, достают и т.д. С тех пор в лучшую сторону ничего не изменилось, а с приходом сетевых магазинов только усугубилось.

FloXtoN

#8
10 января 2020, 12:43 Последнее редактирование: 10 января 2020, 12:47 от FloXtoN
Цитировать
Для современных дисков это "нормально", в статье про RAID мы как раз писали об этом: https://interface31.ru/tech_it/2019/05/raid-likbez.html
Если большую часть диска занимают "холодные" данные, то вероятность того, что диск сам обнаружит сбойный сектор, сделает его ребилд и просигнализирует в SMART крайне мала.
Значит я читал не внимательно, пойду перечитаю. Потому что когда статья вышла прочел с большим удовольствием.

Цитировать
Проверять по расписанию - это тоже не выход, при современных объемах данных это будет занимать существенное время.
Когда запускаю в ручном режиме, за сутки успевает.

Цитировать
Скажем RAID5 на массивах от 12 ТБ - это 100% способ угробить данные, даже без бед-блоков на дисках. В то время как RAID10 в 67% случаев переживет выход сразу двух дисков (здесь имеем ввиду не только физический выход из строя дисков, но и повреждение одинаковых областей с данными).
Именно поэтому, при настройке хранилища выбрали Raid 10 из 10 дисков с добавлением 2 в качестве резервных.

Цитировать
Также не стоит набирать большие массивы из дисков одной партии, лучше закупиться понемногу, но в разных местах. Дело не только в производственном браке, но и в условиях их хранения и транспортировки. Если ящик с винтами уронили на складе в магазине, то покупателей такой партии могут ждать неприятные сюрпризы.
А вот за этот совет отдельное спасибо. Почему-то про такое даже не подумал.

FloXtoN

#9
10 января 2020, 15:08 Последнее редактирование: 10 января 2020, 15:10 от FloXtoN
Начал читать статью заметил опечатку:
Цитировать
Сразу возникает масса "претензий" к RAID, он все они беспочвенны. Главную задачу контроллер выполнил - сохранил работоспособность массива.
Наверное "но".

Кстати оказалось что действительно приличная часть статьи в памяти не отложилась.

Уваров А.С.

Да, спасибо, исправим.

FloXtoN

Прошу прощения, еще одна опечатка:
Цитировать
Т.е. в периоде износа отказы будут увеличиваться не постепенно, а не сразу, но, с какого-то момента стремительно.
Насколько я понимаю "не" лишняя.

Уваров А.С.

Эту мы уже сами нашли, но все равно спасибо.

Вверх