Важно! Перед любыми операциями с массивами бэкап важных данных обязателен!
В теме обсуждаем вопросы и проблемы организации (выбор структуры), создания, эксплуатации, модернизации (перенос/расширение) и восстановления (ребилда), а также сопутствующие этим вопросам моменты.
Обсуждение выбора RAID-контроллеров ведётся здесь.
Подобрать накопители для массива поможет эта ветка.
Обоснованный выбор оптимального размера страйпа для производительных RAID 0 посредством тестирования в HAB.
Померяться производительностью стоит тут.

В случае описания вопроса выбора, скорости и связанных с этим проблем, просьба ссылаться на посты в соответствующих ветках.

Основы теории массивов: http://wikipedia.org/wiki/RAID
Общая информация по массивам доступна в виде мини-бета-FAQ.
Познавательная статья по контроллерам от програмного массива к аппаратному - Игры с RAID
Полезная статья по восстановлению RAID.
Полезные сведения по работе с RAID-контроллером 3ware 9550SX-8LP, в качестве примера.

Задавая вопрос, постарайтесь как можно полнее описать конфигурацию массива и компьютера в профиле, то что, проделали и текущий результат. Не забываем пользоваться поиском в данной теме и по всему Internet'у!

Intel® Rapid Storage Technology не поддерживает 3TB диски в RAID-режиме, а Rapid Storage Technology enterprise(X79, C600) - работает с ними.

Скорость случайного доступа у JBOD выше, чем у RAID-0, и почти равна скорости одиночного диска. Надежность тоже выше, чем у RAID-0, т. к. данные при отказе одного из участников на остальных дисках никуда не денутся, по-сути, можно считать, что это отдельные накопители, но с возможностью объединения объема. Линейка у JBOD тоже на уровне одного диска, но есть одно но: если запустить несколько потоков, работающих с данными, размещенными на разных участниках, скорость практически не падает, в отличие от страйпа или одиночника, тут только миррор на хорошем контроллере с упреждающим чтением сравняется. Ну и нужный объем всегда можно добить накопителями любой емкости, тогда как зеркало или страйп обрежется по меньшему объему из участников.

Сцылку дашь?..
Когда JBOD находится некоторое время в эксплуатации - там данные между дисками так перепутаются, что... и потом - хочу ещё одну сцылку - на то, как восстановить данные с JBOD при выходе из строя одного из накопителей?..
Ещё хочу сцылку на способ, позволяющий распределить заранее данные по накопителям в составе JBOD так, чтобы потом можно было "с данными на разных участках"...

P.S. Если что - все вопросы чисто риторические, ибо подтверждения своим измышлениям ты всё равно не сможешь найти...

#77
R-Studio - не, не слышал (с). Любой прогой, которая поднимает из RAW.

Я еще во времена MS-DOS и 3.11 на одиночном диске с помощью NSD делал так, чтобы всё системное и критичное к скорости лежало в начале диска, а шлак - в конце. Другое дело, что конкретная реализация этого способа может различаться в зависимости от специфики задач: неизменяемые данные распределить куда проще, чем постоянно меняющиеся. Но и это решаемо.

Ну во первых ясное дело, для этого ссд ставил и систему на него
Во вторых на ссд я всё не поставлю, а в рейд0 скорость чтение/записи повышается (следовательно особенно для определенных приложений и игр это важно, некоторые приходится даже на ССД ставить для быстродействия, а так не буду ССД нагружать)
В третьих на кой фиг тогда данная тех. если её нельзя использовать, ясное дело, что в мат плату за 300$ никто рейд контролер за 200-300$ ставить не будет, но нерабочий тоже ставить не будут, рассчитано на уровне домашнего пользования..
В четвертых я не сервак делаю, 200 юзеров диск одновременно юзать не будут, исключительно для домашнего пользования (когда нужно...), к тому же читал в форумах, есть люди у кого рейд0 уже 5-6 лет стоит и нечего у них не падает и не глючит (причем у них система на нем стоит, точно ссыль не дам, но читал)..
В пятых

Я бы с удовольствием вам поверил, но в этом месте обычно пример приводят, что мол так и так или ссылку на данное обоснование (причем свежее а не 3-5 летней давности, технологии меняются, так что и пример должен соответствовать), я не критикую и за совет конечно спасибо, но обоснование, обоснование и еще раз обоснование...))
В шестых как я уже писал выше для меня главное скорость,а не долговечность (ну не нужен мне медленный HDD 10 лет работающий), я бы мог конечно купить сразу HDD с большим rpm и большей скоростью чтения, но не купил, теперь хочу поставить такой вариант..

Если я неправ, то неправ, но для начала разубедите!)))

"Поднимает из RAW" - это мощно Мощнее только восстановить то, чего нет:

Можно в картинках, как R-Studio дорисовывает то, что хранилось на неисправном диске? Или она уже и диски ремонтирует?

Ничего, что "во времена DOS" дисковое пространство несколько иначе адресовалось? Каким образом Вы собираетесь заставить диск хранить данные только в определенных LBA? Или JBOD - только на одном из дисков? Даже если теоретически представить себе, что можно в JBOD разместить данные только на один диск, то нафига такой JBOD нужен - поставьте один диск и радуйтесь.
P.S. а что по-Вашему за "страшный зверь" RAW?

Sumen
Очевидно же, что речь идёт о данных на исправном диске.
В RAID0 при сбое одного из дисков теряются данные на всех дисках в массиве.

Что значит - "дорисовывает"? Речь о вытаскивании данных на оставшихся в живых участниках, если вы не поняли. Этих данных будет куда больше, чем при падении одного из участников страйпа - там вообще вытащится только то, что целиком в страйп вмещалось. RAW - раздел, лишенный таблиц ФС, то есть в данном случае идет посекторное сканирование области данных и поиск файлов по заголовку, а если и его нет - то по телу файла. Структура ФС при этом значения не имеет, но если одна из таблиц оказалась на неповрежденном участке - можно восстановить и всё дерево структуры папок и файлов с рута и далее, просто из данных вытащится только то, что осталось на неповрежденных участниках.
Если вы записали данные в одну область, логично, что туда ничего не запишется, пока вы не удалите их или не переместите физичски. Кто мешает использовать любой дефрагментатор, имеющий функцию ручного указания, куда переместить папку - в начало или в конец? При записи новой инфы она ессно будет писаться в первое же свободное место. По поводу LBA и нескольких дисков - LBA начинается только с контроллера самого диска, винде это фиолетово, для нее идут блоки первого участника JBOD, потом второго, третьего и т. д. Логично, что если первый диск имеет объем в Х Гб, то и в JBOD первые X Гб придутся именно на него. Ну и т. д. Ничего сверхестественного там нет, объединяется само дисковое пространство, вся организация ФС типа МБР/БРn/ФСn1-ФСn2 остаётся такой же, какой и была бы на накопителе суммарного объема. На самом деле и там не все данные теряются - если фрагмент целиком умещается в страйпы оставшихся в живых участников - его можно вытащить. Просто процент таких данных обычно очень невелик, отсюда и стереотип, что теряется именно всё.

Ну да, "стереотип" Данные, которые в страйп уместятся, по телефону продиктовать можно было бы, настолько они маленького размера должны быть

nanoflooder Ну почему? Если файлы изначально мелкие (БД, сообщения какие-то и т. д.), а страйп большой - можно вытащить. Просто вытащить можно только некоторую часть, поэтому ценность спасенных данных не велика. Но иногда - может сильно помочь Пароли, крипта, приватный ключ биткоина, еще какая уникальная и невосстановимая инфа. Всякое бывает...

У Вас, вероятно, какой-то "свой RAW"...
Заблуждение относительно существования такого типа файловой системы как RAW пришло из "Управления дисками" в ОС Windows. Ошибочное - потому что такой ФС не существует. Сообщение "Файловая система RAW" появляется в случае таких повреждений файловой системы, когда она не может быть нормально примонтирована для работы, не обязательно должен быть

достаточно "бэд блока" на элементах MFT. Сразу по поводу таблиц: о каких таблицах идет речь? Вот тут:


Если речь идет об Master File Table файловой системы NTFS (а скорее всего, именно эту систему собирался использовать автор обсуждаемого массива), то MFT представляет из себя набор файлов, расположенных в строго отведенных местах, копии не имеет (за исключением первых записей MFT, копия которых имеется). Так по какой из таблиц Вы данные восстанавливаете? По единственной копии? Так в этом случае при выходе из строя первого диска (на котором по умолчанию будет расположено как минимум, начало MFT) можно будет получить только нефрагментированные (!) части файлов, имеющих уникальные (!) сигнатуры (заголовки, иногда даже footer). Присутствие обрывка MFT на втором диске может быть только следствием ну очень сильной фрагментации полного диска, но как следует из:

Дефрагментация будет после каждой транзакции, чтобы не допустить рассредоточения файлов...
Чтобы

Нужно иметь как минимум файловые записи восстанавливаемых объектов, запись о Root и индексы от этих элементов. То есть практически живую ФС. И никакого "волшебства" по "поднятию инфы даже из RAW" тут нет.
Если Вы говорите о "копиях таблиц", то вероятнее всего, имеете ввиду файловую систему из семейства FAT (заметьте, я не утверждаю, что о других ФС Вы не слышали). Но и здесь есть "подвох": последний релиз данной ФС, FAT32 (почему-то 64-разрядную писать не стали) не поддерживает том размером более 2 Тб на диске с сектором 512 байт. Да и я очень далек от мысли, что на обсуждаемом массиве будет использоваться именно FAT.

LBA диска начинается с LBA диска (извините за тавтологию, но нумерация секторов не может идти не с сектора, как нумерация полок в вагоне не начинается с номера пути).

Винде это не только "фиолетово", но и недоступно: ОС не работает напрямую с адресами секторов, она работает с кластерами, которые ей транслирует файловая система. Единственная файловая система, работающая иначе - ZFS, но так как Вы говорили о каких-то таблицах, она тоже не в счет.
Касаемо второго диска JBOD. На массиве, созданном средствами контроллера, последующие диски могут (и чаще всего так и есть) не иметь даже тома. То есть там даже не будет "файловая система RAW", просто "не проинициализирован". В то же время JBOD, созданный с применением LDM или LVM будет иметь том, причем в случае с LDM ОС будет писать что-то вроде "вне сети".

Не все страйпы состоят из двух дисков. И при определенной удаче (а это именно удача, случай) восстанавливаются довольно большие куски файлов размером ({количество_дисков}-{количество_неисправных})*{размер_страйпа}. При количестве дисков в массиве с размером страйпа 128 Кб 10 шт и запиленном одном диске можно получить максимальный размер куска около 1 Мб. В результате это может быть спасенной частью фотоархива, документами Office и прочей мелочевкой.

Добавлено спустя 1 минуту 57 секунд:

А по каким критериям Вы собираетесь найти:
1. пароли, сохраненные в формате txt
2. приватный ключ биткоина?
И кто такая "крипта", что ее можно по сигнатурам восстановить? И какие у нее сигнатуры?

В данном случае я придерживаюсь определений, применяемых производителями софта по восстановлению. В моем понимании - достаточно точном: RAW - сырой. Если вы считаете, что мое упоминание слова "RAW" имеет отношение к какому-либо типу ФС - у меня для вас как для специалиста по DR плохие новости=)Слышал, трогал и тестировал на отказоустойчивость другие ФС - "шатал" даже ReFS, о чем отписывался здесь, но зуб даю, что подавляющее большинство форумчан сидят именно на NTFS. А копия первых записей для нее имеется, вы сами с этим согласны, а дальше уже можно разматывать клубочек по адресам.Ессно. Но сигнатуры начала и конца файлов никто не отменял.Опять непонятна привязка к типу ФС. RAW - это RAW, он изначально рековерится как не имеющий таблиц ФС. К чему флуд?
О чем и речь.
Если знать, что искать, найти куда проще, согласитесь? Крипта - алгоритм шифрования с нелинейным сдвигом: цифровые подписи, сертификаты и т. д. Если нет всего куска - не поднять, в общем.

Угу-угу...
Начнём со ссылки на thg: буквально на следующей странице результаты тестов RAID0 - ты эту следующую страницу смотрел? Ничего, что в RAID0 результаты выше, чем в JBOD?
Далее, по поводу R-Studio... Тут фигня в том, что каждый конкретный файл легко может оказаться "размазан" по нескольким накопителям; чем там R-Studio "поможет", если один из этих накопителей вышел из строя?!.
"Начало" и "конец" - это зачОтно; а как ты "это" сможешь разложить по конкретным накопителям в сговняканом JBOD? Особенно с учётом того, что MFT там лежит только на первом накопителе из цепочки, на остальных - данные (и лежат они так, как лягут, а не так как тебе захочется)...
Если у тебя лично RAID0 рассыплется через 2..3 месяца... чем тебе поможет то, что у кого-то где-то "на форуме" похожий RAID0 "проработал 5..6 лет"?..
В JBOD при выходе из строя одного из накопителей точно так же "ничего не собрать" - ибо не существует способа расположить какой-то конкретный файл на конкретном накопителе в составе JBOD; а если "гавкнулся" первый из цепочки накопителей - с остальных уже ваще только руками по содержимому можно что-то пытаться "собрать"...
P.S. Если коротко - JBOD имеет все недостатки RAID0, но не имеет ни одного преимущества RAID0...

Только до 4 накопителей и при минимальной глубине очереди. Вы, наверное, не обратили внимание на то, что масштаб по оси глубины очереди разный. А кто-то возлагал на нее большие надежды? Перечитайте, в ответе на какой ваш вопрос я ее упомянул, и не приписывайте большего.
Ну, больше трех участников я JBOD не собирал, хотя можно и на большем числе участников распределить данные, просто телодвижений больше, а по поводу бреда о том, что МFT в одном экземпляре хранится - см. выше. И к вопросу распределения данных - там нет никакого рандома: если сегмент влезет в ближайшее свободное место - он будет туда записан. Метод помещения данных туда, куда хочется методом заполнения пространства начала диска с последующим после записи его освобождением никто не отменял: я в период параноидальной молодости даже место под свап резервировал записью файла нужного размера в начало диска еще до установки винды. Теперь поступаю проще - вообще на отдельный раздел выношу, созданный в начале массива, благо проблема 8032Мб уже давно решена.

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


пример приведите, пожалуйста. Какие записи у MFT продублированы и как Вы "мотаете клубочек", если остальных записей не будет? Повторяю: это не FAT, там нет таблиц в двух экземплярах. И если Вы не в курсе, то у меня для "тестировщика файловых систем" плохие новости.
На искомые файловые записи (с пользовательскими данными) файловой системе плевать, имея только копии первых записей MFT восстанавливается работа тома. Не более того, данных не будет! Хотя Вы "твой NTFS труба шатал"...

К тому, что читать надо повнимательнее. И отличать понятия "носитель", "том/диск" и "файловая система". И к тому, что диск не может быть RAW, слово "RAW" пишется в поле "файловая система", в то время как понятие "файловая система" относится к тому (на картинке нарисовано). Кстати, о картинке: у данного диска не "нет таблиц", зато есть вся MFT и поврежден файл $MFT (по обеим копиям).

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

Добавлено спустя 2 минуты 24 секунды:

О, самое время упомянуть "самописный софт". А чем плоха R-Studio?

Ссылку на опровержение бреда можно? И еще желательно, где написано, что это две таблицы.

Я тоже не переводчик. Поэтому взаимно.Первые 16 - метафайлы, включая сам MFT. Поскольку их положение фиксировано, найти их либо можно изначально, либо - нет.И? Где и что я невнимательно прочитал и что не так назвал, по вашему мнению?Опять - и? Что такое RF, VDL и EOF вы знаете, как я полагаю? Я тоже. Дальше что? Доказывать, что возможно поднять данные, не имея в наличии целую ФС в любом виде? А оно мне надо - что-то вам доказывать? А кто сказал, что она плоха? Софт делает то, что от него ожидается - умеет подымать с исправных накопителей либо их копий данные из разделов с убитой ФС, не больше, и не меньше.А вас, простите, в гугле забанили? Ну ок, просвещайтесь. И да, почитайте хотя бы в wiki, что же за "файловая система" такая - RAW =)

Чем старше человек, тем больше ему лет.
И что, ну найдете 16 метафайлов, описывающих параметры (заметьте: параметры, а не содержимое) файловой системы. А данные где?

Да доказывать-то не надо, просто на вопрос ответьте

Прям светоч! Хоть бы запрос правильно написали, а то "структура ФС на NTFS". И где там про полную копию MFT? Ну и по поводу Wiki: Вы бы сами почитали для начала. Я уже третий пост про это пишу, а Вы мне что RAW- это такое свойство диска. Хотя я понял, откуда это суждение...

Точно, это вольный перевод одного из обзоров на "ихнемязыке", где была формулировка "RAW Images" . Так это про несжатый образ диска, посекторную копию. Короче, гугл-транслятор Вас подвел...
Интересно, а как же Вы так тестировали на устойчивость файловую систему NTFS, если не только не знаете ее устройства (ну не две таблицы там...), но и в качестве "контраргумента" приводите не спецификацию (которую тестер должен знать "от корки до корки"), а говноссылку? Да еще и с неправильным поисковым запросом. Структура файловой системы на файловой системе Подскажу, как правильно начать изучение: открываем поисковик и пишем "структура файловой системы NTFS" (чувствуете разницу?), или "NTFS specification" ну или на худой конец пользуйтесь

Добавлено спустя 5 минут 33 секунды:

как-то не стыкуется с:

Про сигнатуры вопрос остается в силе Аббревиатуры - это не аргумент. Я конечно, понимаю, что в Вашем понимании "восстанавливаю данные" = "ставлю галочку напротив соответствующего пункта", но раз уж Вы не только тестировщик файловых систем, но еще и критик ПО во восстановлению данных, то привести пример сигнатур для упомянутых Вами типов файлов Вам не должно составить труда.

В области данных. Наличие или отсутствие MFT не определяет возможность их восстановления, оно лишь ее облегчает.
Еще раз - "Лишенный" в данном контексте следует читать как "не имеющий", "имеющий, но не читаемые, ошибочные" и т. д.А где у меня про полную копию???
На русский переведите, что вы пытались сказать, будьте добры.Интересно, а когда вам надоест передергивать то, что я вам отвечаю, если вы разницы между NTFS и ReFS не видите? Я в тексте упоминал только о тестировнии ReFS, причем я отказался от ее использования даже на RAID-5 в пользу NTFS, но не суть. Ну, после этого я считаю фазу попыток перейти в русло конструктивного диалога законченной, троллить меня смысла нет - я на форуме давно, и равнодушен к троллям, специфику перевода и трактовки аббревиатуры NTFS оставляю вам на откуп, спецификации тоже себе оставьте - ссыль некликабельный, да и не интересный. А в вашей оценке моих качеств и способностей я тем более не нуждаюсь.

Конечно, неинтересный. Там же не по-русски написано. Это же не википедия.

Я бы, конечно, спросил, как Вы собираетесь восстанавливать фрагментированные (или не имеющие уникальных сингатур в заголовках) файлы, но Вы же "давно на форуме", поэтому можно и за слова не отвечать:


Вообще-то выражение:

адекватный человек интерпретирует как "полная копия". Даже если под "одна из таблиц" подразумевалось "16 первых записей MFT", то вопрос:

остается открытым. Как и:

Так будет ответ хоть на один вопрос, или только обвинения в профанстве, троллинге и прочем?

А что "выше"? Вот что об этом Руссинович пишет: Это уж никак не похоже на полноценную копию MFT...

Этих метафайлов достаточно для восстановления файловой системы на томе. Только файловой системы, без пользовательских данных. Так что "мотать клубочек" не получится: "ниточка" заканчивается.