Melkij

стримить по веб

А ваша малинка вообще может утилизировать сеть?
Чтобы хотя бы заикаться о производительности диска.

1) рассчитывайте на срок порядка суток. Под интенсивной нагрузкой ещё больше.
2) неправильно понимаете. Кроме просадки производительности ввода-вывода больше ребилд и деградировавший массив стороннему наблюдателю ничем не отличаются от здорового.
3) важно понимать, что рейд - это избыточность только одного расходного материала - дисков. От уборщицы, электрика и прочих неожиданностей он не поможет. Возможно, вам этого уже достаточно. Возможно, вам нужна вообще кластерная ФС.
4) чем отличается добавление диска в рейд5 от добавления в рейд6? рейд6 для файлохранилища вполне хороший выбор для такого числа дисков.

Посмотрите SMART, там стап-стопы фиксируются.

RAID не про сохранности данных. Это технология повышения доступности.
Сделайте случайно rm и всё, приплыли.

На 4 дисках минимальная сохранность данных:
пару в зеркало как страховка рантаймовых данных
где-то неподалёку диск для бекапов
где-то далеко ещё один диск для бекапов

https://help.ubuntu.com/community/Installation/Sof...

20тб без резервирования? Ваша задача точно допускает такое использование?
JBOD или RAID0 даст такую ёмкость на ваших дисках. Выпадение диска - потеря всех данных на этом томе или вообще всех соответственно для jbod и raid0

Что вы хотите получить в итоге?

Вставляете эти два диска.
Инициализируете raid10 на этих дисках как "диск missing диск missing". RAID10 переживёт пропуск вообще любого диска или до половины дисков, но только в определённых местах (каких - зависит от стиля размещения данных по дискам, их есть несколько, если интересно - в мане описаны).
Ставите загрузчик на новые диски
Переносите систему (для lvm - штатными средствами), для других - погуглите.
Перезагружаетесь с raid10
Разбираете raid1 и добавляете эти диски в raid10. Ждёте конец ребилда массива, всё.

Разумеется, с бекапами. Сам процесс довольно простой, чаще угробить всё можно опечаткой.

Дико извиняюсь, курсивом выделены пункты вам нафиг не нужные, это для случая, если система на этом же рейде.
И для переноса данных, если нет lvm, то остановки сервисов (а не всей системы) и rsync'а вполне хватит.

Можно. Но без бекапа не пробуйте.
0) останавливаете массив
1) делаете посекторную копию раздела на новый диск (dd)
2) обнуляете суперблок на старом диске
3) собираете массив (через mdadm --assemble, а не create)

Сперва-наперво, сделайте полную посекторную копию всех 4 дисков. Да, понадобятся доноры, куда это записать. Но это дешевле, чем случайным косяком убить всё. И так же дешевле, чем спец. конторы по восстановлению - им тоже доноры нести надо будет.

Затем, когда всё посекторно забекапили, возьмите linux с mdadm и попробуйте собрать массив. mdadm знает некоторое число популярных рейдов и вполне может подхватить массив. (а может у вашего nas'а непосредственно mdadm и не использовался)

Почему вам кажется странным смарт?

Как диски себя ведут вне рейда? На другой машине?
Софтрейд у вас работает замечательно. Успел прочитать даже больше, чем при попытке читать с дисков по-отдельности.
Надеюсь, разумеется, что ребилд массива уже закончен и vmstat в целом по серверу показывает полное отсутствие нагрузки.

Попробуйте пометить сбойным, удалить, удалить суперблок и добавить обратно:
mdadm /dev/md3 -f /dev/sdb4
mdadm /dev/md3 -r /dev/sdb4
mdadm --zero-superblock /dev/sdb4
mdadm /dev/md3 -a /dev/sdb4

Служебная область mdadm занимает 2048 секторов в начале каждого раздела(или диска)-элемента массива. Если вы создадите таблицу разделов аккуратно с нужного смещения по последний сектор используемого размера массива — вы получите неповреждённую исходную ФС со всеми данными.

В общем, всё зависит от того, как сейчас размечено и что получить надо.

SMART не панацея.
Вынимайте диск, прогоните MHDD/Vicroria.

С полгода назад на одном диске тоже хаотично переставали читаться некоторые сектора — помогла замена кабеля.

Такс, раздельно и по порядку:
Собственное видео и фото всё равно бекапить надо.
И выставлять права только на чтение.

Когда, кем, что удалено — не подскажу, к сожалению.

Программный RAID5 или 6 — стоит. Способы восстановления рейдов уже проторены и руководства есть, я лично восстанавливал рейд5 после выпадания 2 винтов — т.е. фатальный развал массива.
Но надо учитывать, что рейд спасёт только от физической кончины диска. От логической ошибки — нет.
Касательно оптимизации производительности mdadm'а: habrahabr.ru/blogs/linux/111036/

Сами диски — для файлопомойки WD green оптимальны.

Температура HDD — 35-45C. habrahabr.ru/blogs/hardware/13560/

Сам использую пару WD20EARS и пару ST31000528AS, 4х900гб в рейд5, поверх XFS уже несколько лет под Debian Lenny, потом Squeeze. Пережили, как уже писал выпадение пары накопителей разом (питание отошло), миграцию на перечисленные диски, расширение массива.

Ок, с разделами разобрались. Это не тот массив.
Ищите свой третий диск. С HPшными рейдами не знаком, так что подсказать не смогу.

Поищите определение дисков в выводе dmesg, в /dev/sd* и /dev/hd*
Если нету — идите в конфигуратор рейда, ищите возможность подключить диск без рейда

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