Давно уже на NAS’е у одного или двух (не помню уже) дисков начал сигналить SMART о том, что диск потихоньку сыпется. У меня RAID6, так что отдельные вылеты можно было пережить, но о покупке новых дисков уже начал задумываться. Глянул по рынку, оптимальный вариант – 16-18 ТБ. На тот момент это был пока теоретический интерес. Но недавно пришлось начать активнее шевелиться – полностью посыпался один диск.

Диски у меня нарезаны на 3 части по 1 ТБ; потом эти куски соединены в RAID, а дальше RAID’ы уже сшиваются в LVM. В итоге накладных расходов почти никаких, зато в случае повреждения только участка диска остальная часть продолжает работать. И таки да, на какое-то время это выручило – 2/3 проблемного диска продолжали работать. Правда, под конец вылетел еще один кусочек, но к тому времени я был уже готов целиком исключить диск.

В плане дисков – у меня 10 шт по 3 ТБ + в свое время ввел в массив отдельный диск на 1 ТБ – подумал, чего ему зря лежать? А моя схема позволяла делать такие финты. В итоге массив данных размещался у меня на RAID6 @ 10 HDD + RAID6 @ 11 HDD + RAID6 @ 10 HDD.

Так или иначе, когда начал активно сыпаться один из 3 ТБ дисков – спешно заказал 2 16-ки. Выбор пал на TOSHIBA MG08ACA16TE – чуть дешевле, больше кэш, а в остальном плюс-минус паритет с Exos’ом.

Можно было, конечно, просто купить пару 3 ТБ на замену, но хотелось потихоньку апгрейдить и этот момент и двигаться в сторону более объемных дисков. Поэтому – 16 ТБ.

У меня еще оставался один свободный порт на pci-e-контроллере, подключил 16-ку туда, но чтобы не нагружать БП NAS’а – запитал его от внешнего блока. Все увиделось и определилось, создал разделы и массив на новом диске, начал копировать данные. А где-то после пары сотен ГБ все развалилось – выпало сразу 4 диска из старого массива. Не знаю, возможно подвис контроллер или что-то в этом роде. Сложно сказать, куда были подключены именно выпавшие диски – для этого потребовалось бы разобрать NAS целиком.

Так или иначе, инфу надо было спасать. Массив автоматом не собирался, метаданные на части дисков ушли вперед. Почитал, погуглил – оставалось только принудительно собрать RAID. Для анализа использовал команды в стиле:

num=4 ; for i in /dev/sd?${num} ; do echo -n "$i " ; mdadm --examine $i | grep Events ; done

Обычно одна часть дисков отстояла от другой на несколько event’ов – 3-5. Выбираем нужные (в моем случае поначалу использовал все доступные). Для простоты выборки – доработал команду:

num=6 ; for i in /dev/sd?${num} ; do echo -n "$i " ; mdadm --examine $i | grep Events ; done | cut -d' ' -f-1 | tr '\n' ' '

И дальше уже копировал строку (с редактированием, если надо) в строку сборки:

mdadm -A --force /dev/md4 /dev/sda6 /dev/sdb6 /dev/sdc6 /dev/sdd6 /dev/sdg6 /dev/sdh6 /dev/sdi6 /dev/sdj6 /dev/sdl6

Реиндекс занял примерно полдня, закончилось все плюс-минус успешно. Проверил архив музыки – он у меня с внешними контрольными суммами. Ничего не побилось.

Ок, пробую снова копировать. В этот раз (вроде так, уже не помню детали) 16-ку поставил на место одного из старых дисков, а старый снаружи корпуса. И через время снова получил отвал. В этот момент уже заметил, что активно рассыпающийся диск начал доставлять больше проблем – отвалилась еще одна “треть”. Решил в следующий раз исключить его целиком. Сделал синхронизацию, убрав диск, смог успешно перелить данные. Добавил вторую 16-ку, убрав еще один старый диск (т.е., массив теперь становился не отказоустойчивым), сделал зеркало. Проверил данные:

rsync -avxcn --delete --progress /storage/ /newstorage/ --exclude='video/*/2023'

Ну что ж, в итоге около 40 файлов оказались битые. В большинстве своем – видеонаблюдение и базы криптонод, что легко заменялось в дальнейшем. Из плюс-минус критичных оставалось штук 7 файлов. Ради интереса сравнил один из битых файлов – серию сериала. Напрямую открыть пару 2 ГБ файлов в kdiff не вышло, решил пойти иначе: набросал скрипт, который режет пару файлов на куски и сравнивает куски отдельно, а потом пишет, если что-то различается:

for i in $(seq 0 $(ls -l 05.\ По\ новой.mkv | awk '{OFMT="%.0f"; print $5/1000000}'))

do

file1=$(dd if=05.\ По\ новой.mkv bs=1M count=1 skip=$i 2>/dev/null | md5sum | cut -d' ' -f1)

file2=$(dd if=file123.mkv bs=1M count=1 skip=$i 2>/dev/null | md5sum | cut -d' ' -f1)

[ "${file1}" != "${file2}" ] && echo $i : $file1 $file2

done

Повреждения были точечные – например, в подопытном файле побилось 2 кусочка по 2 байта в каждом. На видеофайле это вряд ли как-то особо сказалось. Решил не заморачиваться. Во-первых, данные некритичны, во-вторых – восстановимы. В-третьих, со старого массива без ошибок их уже было не достать. Массив, кстати, в какой-то момент снова развалился, но уже было не важно.

Что показательно, оба сыпящихся диска – что полностью развалившийся, что тот, который только начал сыпаться, были одной модели – TOSHIBA DT01ACA300. Первый – 2015 года с наработкой 7 лет, второй – 2016 с наработкой 6,5 лет. И, как выяснилось, я один уже менял – и тоже той же модели. А вот известный своими проблемами Seagate ST3000DM001 (я один в свое время поменял по гарантии, второй остался) до сих пор вполне живой. TOSHIBA HDWD130 (в массиве их 4 штуки) пока без проблем.

Так или иначе, сейчас все перечисленные диски сняты с использования и дальнейшая судьба их пока не определена, а в работе только пара на 16 ТБ. Но надо будет добавить еще пару дисков для реализации RAID6, потому что как выяснилось, это единственный вариант, где доступна полноценная коррекция ошибок: во всех остальных случаях массив не в состоянии определить, где именно случилась ошибка (если это не полный сбой диска):

RAID 6 algorithms operate byte-by-byte just as RAID 5, and if a single byte on any one drive is corrupt, even with no error indicated by the drive, it can be detected AND CORRECTED.

И да, на нем я получал множество таких сообщений в процессе:

kernel: [44309.531302] md/raid:md3: read error corrected (8 sectors at 693250304 on sdf5)

sdf в данном случае – тот рассыпавшийся диск.

Так что для сохранности данных стоит все же потратиться на еще одну пару дисков.