Важно! Перед любыми операциями с массивами бэкап важных данных обязателен!
В теме обсуждаем вопросы и проблемы организации (выбор структуры), создания, эксплуатации, модернизации (перенос/расширение) и восстановления (ребилда), а также сопутствующие этим вопросам моменты.
Обсуждение выбора 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) - работает с ними.

Да, но с зеркала больше вероятность снять информацию не повреждённой или вообще что-либо снять, чем с одиночного носителя.

Бэкап должен храниться на внешнем, желательно diskAshur DT

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

Добавлено спустя 1 минуту 27 секунд:
P.S. Опыт показывает, что одного-единственного восстановления информации в DRC (а это штука крайне недешёвая, Ага ) бывает вполне достаточно, чтобы клиент уже начал делать бэкапы.

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

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

O Smirnoff писал(а):

чтобы клиент уже начал делать бэкапы.

Ага, лежит сейчас в работе такое чудо: базы 1С + их бэкапы в .... (барабанная дробь) соседней папке! А что, нам второй NAS что ли покупать надо было?

На самом деле та же ситуация, что и "с рейдом, но без бэкапов". Бэкапы в соседней папке помогут если кто-то что-то испортил в базе, а рейд поможет при сбое винта, но не наоборот

А вообще бэкапный nas - удобная вещь. Складывать туда бэкапы и сервера(-ов), и рабочих станций. Если там стоит конфигурабельная ОС (винда, линукс, и т.д.), то можно ещё красивее сделать - например, по очереди ночью будить машины по wake on lan, а также сами бэкапы инкрементально на другой диск/raid копировать (уже внутри nas)

То есть бэкап, "лежащий" на соседнем диске/массиве в ситуации "кто-то что-то в базе испортил" не поможет? И при сбое винта поможет. А еще рэйды ломаются - и диски в них летят, и контроллеры из строя выходят, да мало ли чего еще может произойти с RAID, чтобы данные потерялись.

Нет, я не к этому, я про то что есть те кто бэкап в папку рядом кладёт, и есть те кто думает что raid=бэкап, и они примерно одинаково заблуждаются

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

O Smirnoff писал(а):

Возились долго, ибо там был весьма продвинутый RAID-контроллер, и из 4-х SCSI HDD два были зазеркалены, а уже в виде зеркала входили в RAID5 вместе с ещё двумя "одинокими" дисками; что курил их админ, когда создал такой массив - мы так и не выяснили: его успели уволить раньше окончания наших разборок с конфигурацией массива...

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

Так и бэкапы лучше на зеркале хранить или ещё на каком-нибудь RAID51EE. Хотя, если что случиться с RAID5, то точно проблем не оберёшься. Нет уж, лучше на RAID1.

Добавлено спустя 34 минуты 18 секунд:
Pavel12, чушь! В этой коробке один носитель, а не RAID из носителей. Я б не доверил бы такому DAS свои бэкапы. Хотя у меня в ZM-VE400 установлен SmartBuy Firestone 240G, а не HDD, но всё равно боязно. Я в ZM-VE400 уже сменил два HDD и больше свои бэкапы терять не собираюсь! Бэкапы храню только в NAS RAID1 на достаточно надёжных, как мне кажется, специальных для этого HDD. А ZM-VE400 с SmartBuy Firestone 240G - это у меня переносной оперативный временный бэкап, а не постоянный, который ест-но дублирован. И никто ещё не отменял небольшой временный бэкап на зеркале в компе!

Только не на том, где оригиналы лежат. И не на том, что к тому-же контроллеру подключено. И не на том, что в том-же кейсе стоит. И лучше - чтобы оно было в другом помещении. А так-то - "да"...

Это желательно, но не обязательно. Если контроллер сдохнет, а не носители, то инфу легко будет увидеть, подключив один носитель из зеркала отдельно. И потом, массивы созданyтые (слово какое интересное получилось) на софтверных контролерах ICHxR/C2xx, скорей всего нормально заработают и на другой материнке с похожим контроллером. По крайней мере у меня RAID0 легко перенёсся два раза с ICH7R (SATA2) на ICH9R (SATA2) и с ICH9R на C200-B3 (SATA3), при замене материнки. Вот сей час я уже не помню, разбирал ли я RAID0, когда пересаживал его с VT8237 (SATA1) на ICH7R (SATA2).
С RAID1 не страшен в принципе вылет контроллера, если только контроллер, при вылете, не попытается попортить данные в массиве. Страшен именно вылет носителя.

У меня на работе один раз курьёз был, когда рассыпалось софтверное зеркало на ICH10R. Сперва подключили один винт и прогнали chkdsk. Вместо того, чтобы второй винт сперва очистить, а потом подключить на горячую к уже стартованному, который после chkdsk был снова признан контроллером в массиве, подключили его сразу при старте материнки. Так второй винт с кривой файловой системой контроллером был опознан и инициализирован как первый и понёсся Rebild с кривого носителя. Хорошо, что после прохождения chkdsk, с первого носителя был снят образ.

Самое "разумное" решение для важных данных. Это даже не "шаг в сторону" от их доступности, а прямо прыжок к тому, чтобы вместо (например) фрагментированного файла *.1CD поиметь в скрытой папке Found.000 куски размером в кластер. А потом удивляться "куда же база делась, вроде все по уму делали"...
Вот именно от таких действий и защитит бэкап на другом контроллере/компьютере/в_другом_городе.

Sumen, а выбора не было, часть данных не читалась, не на первом носителе, не на втором.

Ключевые слова я выделил, Ага.
Про то, что находящийся в том-же кейсе БП может (совершенно случайно!) угробить по питанию все диски в этом кейсе я уже скромно молчу...

Да, про БП я забыл!