Pull to refresh

Comments 42

Очень мощно написано. Я испугался тех изображений…
С RAID5 будет куда сложнее, но тоже решабельно :) Имхо, проще готовую тулзу найти, наверняка есть.
=) если и да — то не скоро. если б не мои косяки — я бы и эту статью не написал.
Честно — бросил читать с места «для восстановления RAID0 достаточно узнать, который из дисков первый».

Не знаю, как устроен NVidia fake-RAID 0, но Linux Software RAID0 устроен так: каждый из дисков можно использовать сам по себе, «без RAID», поскольку они идентичны. Совершенно пофигу, какой из них первый, какой второй, какой третий — на них всех (сколько ни объединишь) хранится ровно одна и та же (полезная) информация, а метаданные при «починке» деградировавшего RAIDа восстанавливаются сами собой.

Кстати, и LVM использовать совершенно необязательно. (Если хотите аццкой производительности, то как раз не использовать обязательно. Зато теряете в гибкости.)

См. также www.tldp.org/HOWTO/Software-RAID-HOWTO.html (официальная документация по Linux Software RAID)
Да, кстати, и «просто так» такой RAID не расформируешь. То, что раздел — часть RAID хранится в виде типа раздела (помимо Linux Swap 0x82 и Linux 0x83, есть Linux RAID Auto 0xfd, а ещё Linux LVM 0x8e)
UFO landed and left these words here
Упс. Точно. Простите меня, хабрачеловеки.

/me посыпает голову пеплом
Я очень хорошо запомнил в чем разница между RAID0 и RAID1 после прочтения следующей цитаты на bash.org:

sterano: Whats the difference between Raid_0 and Raid_1?
Steve: In Raid_0 the zero stands for how many files you are going to get back if something goes wrong.

(http://bash.org/?854608)
Вы, таки, сильно путаете Raid0 и Raid1. У raid1 инфа на дисках идентична, за исключением самого raid-заголовка. В Raid0, Raid5, 6 и т.д. инфа размазана по дискам.
Я больше не буду! Честно-честно.
>Не знаю, как устроен NVidia fake-RAID 0, но Linux Software RAID0 устроен так: каждый
> из дисков можно использовать сам по себе, «без RAID», поскольку они идентичны.


Может Вы просто спутали? Человек же использовал RAID 0, данные записываются на диски параллельно, часть файла на одном диске, а часть на другом, так что данные на дисках не идентичны.
Да, я прочитал комментарий и ответил на него. Да, я не видел, что тут уже два подобных коммента. Ну ничего с этим не поделаешь… :)
UFO landed and left these words here
так точно. =) но у меня не получилось — радиус кривизны рук слишком мал. пришлось выдумывать.
Фил, ты дважды молодец — написал таки статью, ну и восстановил данные!
молодцом!
хорошее начало.
скрипт с заботливыми комментариями
if ($timert1 == 16192) { # останавливаем время от времени операцию, давая дискам остыть
$timert1 = 0;
print («So hot! Sleeping for 33 sec...\n»);

тож порадовал.

надеюсь, парсер не лох )
напрягает комментирование после '{'? =)
хех. нет. все вполне аккуратно. даже на тебя не похоже =))
Я думаю, радует то, что где-то таймаута может и не быть и диски поджарятся. Ну это про таких горе-программистов как я, которым проще попробовать, чем еще раз подумать, я надеюсь, автор не такой :)
Слова «ложить» нету, а «положить» есть.
А за статью спасибо, будем надается не пригодится)
Отличная статья, спасибо!

Сам поволновался на этих выходных, когда свежесобранный Raid5 массив со всеми слитыми на него данными, отформатированный в ext4, развопился при очередной перезагрузке.
Но mkfs с правильными параметрами меня спасла. )

Я правильно понимаю, что размер страйпа это параметр chunk size, с которым запускаеся mdadm --create?

> Но mkfs с правильными параметрами меня спасла. )

e2fsck, конечно же. )
Автор — Монстр!
За статью — спасибо! Но надеюсь, что никогда не пригодиться… :-)
Теоретически можно было собрать исходный массив через mdadm. Времени на это понадобилось бы меньше, но риск что-нибудь сломать в процессе был бы больше.
собственно, согласен.
этой же логике я и следовал: какие изменения будет вносить mdadm, пока я буду пытаться подобрать правильные команды, я не знаю. а вот что делает dd — это мне вполне понятно. в случае с mdadm я бы не решился ничего делать, пока заранее не снял бы посекторные резервные копии с обоих винтов тем же dd.
Считайте меня ханжой, но за фактический украденный у клиента винчестер уволил бы, потом бы руки оторвал, а затем приклеил их обратно — пожизненно восстанавливать мертвые массивы.
считайте меня мазальщиком, но я ничего не крал.
фактический украденный? при наличии 10ка штук такой же модели?
гм. вы ханжа.
если бы клиенту понадобился этот винчестер — Фил бы его отдал без разговоров. и получил бы любой другой подходящий.
бэкапить, бэкапить и ещё раз бэкапить
труъ хакеръ!
респект :)

а картинки с визуальным определением уровня энтропии и паттернов напомнили случай из детства,
когда пришлось руками собирать удалённый архив огромных размеров на сильнофрагментированном fat.
Размер одного диска в секторах можно узнать с помощью Victoria, либо посмотрев на наклейку на диске (LBA).
Разве линуксовый fdisk не может показать размеры партиций в секторах и для этого нужно лезть в Windows или вынимать диски из стойки? O_o
может и умеет, сиё мне неизвестно. =)
«RAID 0 из двух Samsung'ов» какраз идеальная тема для раздела «Я безумный». У кого много винтов самсунга, тот поймет :)
у меня много винтов самсунга. =) 4 штуки. намёк ваш понятен, да вот беда: самсунги мои работают нормально и уже давно. более того, на работе через наш бракотдел сильно чаще, нежели самсунговские, проходят винты другого производителя, тоже на букву «с». особенно часто — в последние месяцы, кто работает в сервисе — тот поймёт.
конечно, мало. для статистики. лично для меня того факта, что пара из этих винтов нормально отработала 4 года — вполне достаточно для того, чтобы считать, что нормальная работа этих девайсов — скорее правило, чем исключение. =)
статистику надо бы на работе мне как-нить сварганить, да всё руки не доходят.
сильно нервничали пока копировали? Ведь, как я понимаю, одна ошибка в рассчётах и начинать всё сначала)
нервничал не сильно. =) единственное, что я мог потерять — это время. при восстановлении не использовались никакие команды, которые могли бы затереть данные на дисках из бывшего рейда. ну, вернее, 'dd' могла затереть, если бы я попутал местами 'if' и 'of', так что просто был предельно внимателен. а если ошибся где-то в рассчётах — то таки да, пришлось бы править скрипт, снова пытаться определить размер страйпа и терять ещё 1 день на копирование.
В статье отсутсвует самое главное — вывод о том, что все эти тн «чипсетные» рейды понижают устойчивость к сбоям, а не повышают (как должно бы было). Если жалко денег на приличный контроллер, лучше RAID средствами операционки (чисто софтовый). Даже на «поиграться» большинство чипсетных поделок не тянет.
должен заметить. не спорю, fake raid драйверозависим и негибок. однако, исходя из своего печального опыта, хочу заметить: в первую очередь надёжность raid понижает невнимательное и халатное к нему отношение, начиная со стадии выбора комплектующих для raid (я приобрёл говномобайлреки, которые работали с костылями, и, как оказалось впоследствии, херово) и заканчивая его поддержкой (я отключил бипер рейда — бухгалтеру мешал — и забыл его включить по окончании работ). полностью аппаратный рейд — тоже вещь капризная и требовательная к грамотной его реализации. меня спасла утилита проверки файловой системы reiserfs, однако пока я до неё добрался — через дебри LVM и LUKS — по всем правилам восстановления данных (посекторное снятие раздела reiserfs размером 890 ГБ, лежащего внутри LVM, лежащего внутри LUKS), я осознал правильность нескольких устверждений:
1. бэкапы.
2. всё в первую очередь для рейда, во вторую — для бухов / директоров / прочих недовольних.
3. то, что меня спасла утилита проверки reiserfs, не обязательно повторится в следующий раз, если я буду пренебрегать пунктами 1-2.
Only those users with full accounts are able to leave comments. Log in, please.