Восстановление RAID5 в офисе: реальный кейс с WD Red Pro и Seagate IronWolf

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15 лет работы с офисными серверами малого и среднего бизнеса в Москве я разбирал десятки развалившихся RAID-массивов — от простых отказов одного диска до жёстких ситуаций, когда в пятницу вечером одновременно умирают два. Расскажу про свежий кейс: юридическая фирма на 24 рабочих места, файловый сервер с RAID5 из четырёх WD Red Pro, умершие диски, документы клиентов за 11 лет и то, как мы всё это собрали обратно.

Ситуация: RAID5 из 4 дисков WD Red Pro по 4 ТБ

Звонок поступил в пятницу в 16:20. Руководитель юридической фирмы «Правовой актив» (21 сотрудник + 3 стажёра, офис на Большой Лубянке) сообщил: файловый сервер выдаёт «ошибку сетевого пути», работать нельзя, клиенты ждут документы. Уже на месте через час я увидел типовую картину.

Конфигурация сервера HP ProLiant ML350 Gen10, поставленного в 2019 году:

• ОС — Ubuntu Server 22.04 LTS
• RAID-контроллер — встроенный HPE Smart Array P408i-a в режиме HBA (программный mdadm RAID через Linux)
• Диски: 4 × WD Red Pro 4 ТБ (WD4003FFBX), собраны в RAID5 → полезный объём 12 ТБ
• Файловая система — ext4, занято 8.4 ТБ
• Данные: судебные дела, договоры, скан-копии документов, переписка с доверителями за 2014–2026

Диагностика mdadm --detail /dev/md0 показала: массив в состоянии inactive, два диска (/dev/sda и /dev/sdc) помечены как faulty. Два оставшихся (/dev/sdb, /dev/sdd) ещё живы. RAID5 штатно выдерживает отказ одного диска — два отказа ведут к остановке массива.

Бэкапы делались... в отдельную папку того же RAID5. Классика. Директор уточнил: «Мы думали, RAID — это и есть бэкап». Это не бэкап. RAID — это защита от единичного отказа железа, но не от шифровальщиков, удаления по ошибке, пожара и — главное в нашем случае — одновременного отказа нескольких дисков.

Шаг 1: SMART по всем дискам — что умерло, а что живо

Прежде чем что-то пробовать, я всегда собираю SMART-отчёты по всем дискам массива. Две важные причины: (1) понять, какой из «умерших» дисков читается лучше, (2) оценить состояние оставшихся «живых» — вдруг они на грани.

# Проверяем SMART всех дисков в массиве
for d in sda sdb sdc sdd; do
  echo "=== /dev/$d ==="
  sudo smartctl -H /dev/$d | grep -E "SMART overall|result"
  sudo smartctl -A /dev/$d | grep -E "Reallocated_Sector|Current_Pending|Offline_Uncorrectable|Power_On_Hours"
  echo
done

Результаты по четырём дискам WD Red Pro 4 ТБ (WD4003FFBX):

56 тысяч часов — это 6.4 года непрерывной работы. Ресурс MTBF у WD Red Pro заявлен 1 млн часов, но это статистика, а не гарантия для каждого экземпляра. Более того — диски одной партии часто отказывают в близкие временные окна, потому что произведены из одного материала в одной смене. Это та самая причина, по которой я рекомендую покупать диски разных партий или разных производителей в один массив.

Хорошая новость — диск /dev/sda читается на 99.3 % по предварительному замеру. Этого достаточно, чтобы пересобрать RAID5. Диск /dev/sdc в плохом состоянии, но нам он и не нужен — достаточно одного из двух «мёртвых».

Шаг 2: посекторные образы через ddrescue

Главное правило работы с умирающими дисками — никогда не работать с оригиналами. Каждая попытка чтения с повреждённого диска может ухудшить ситуацию: сектор, который сейчас читается с 10-й попытки, через час не прочитается вообще. Поэтому все дальнейшие действия делаем с посекторными копиями на отдельном хранилище.

В субботу утром я привёз в офис внешний бокс на 20 ТБ (4 × Seagate IronWolf 6 ТБ в RAID0 — специально на такой случай, стоит у нас в лаборатории). Подключил к серверу по USB 3.1 Gen 2 и начал копирование через ddrescue:

# Копируем самый повреждённый диск в первую очередь
# --no-scrape: первый проход без попыток вычитать плохие сектора
# -d: прямой доступ минуя кеш ядра
# -r3: до 3 попыток чтения при повторных проходах
sudo ddrescue -d --no-scrape /dev/sda /mnt/rescue/sda.img /mnt/rescue/sda.log

# Первый проход занял 8 часов 14 минут
# rescued: 3998.22 GB, errsize: 1.78 GB
# Второй проход — повторные попытки вычитать битые области
sudo ddrescue -d -r3 /dev/sda /mnt/rescue/sda.img /mnt/rescue/sda.log
# После второго прохода: 3999.61 GB rescued, 0.39 GB errors

# Худший диск — пробуем, но без фанатизма (он не критичен)
sudo ddrescue -d --no-scrape /dev/sdc /mnt/rescue/sdc.img /mnt/rescue/sdc.log
# 3.58 TB rescued, остальное — непрерывные bad sectors

# Здоровые диски тоже клонируем — на всякий случай
sudo ddrescue -d /dev/sdb /mnt/rescue/sdb.img /mnt/rescue/sdb.log
sudo ddrescue -d /dev/sdd /mnt/rescue/sdd.img /mnt/rescue/sdd.log

Суммарно копирование всех четырёх дисков заняло 22 часа (до воскресенья утра). Клиенту я в субботу вечером объяснил: «Работы будут делаться с образами, оригинальные диски мы больше не трогаем. В понедельник к обеду скажу, что получилось».

Шаг 3: анализ метаданных и выбор, с какого диска собирать

С образами можно экспериментировать сколько угодно — если что-то пойдёт не так, всегда есть возможность начать сначала. Подключаем образы как loop-устройства и читаем суперблоки mdadm:

# Подключаем образы
sudo losetup /dev/loop0 /mnt/rescue/sda.img
sudo losetup /dev/loop1 /mnt/rescue/sdb.img
sudo losetup /dev/loop2 /mnt/rescue/sdc.img
sudo losetup /dev/loop3 /mnt/rescue/sdd.img

# Читаем метаданные RAID с каждого
for i in 0 1 2 3; do
  echo "=== loop$i ==="
  sudo mdadm --examine /dev/loop$i | grep -E "Events|Array State|Update Time|Role"
done

Ключевой параметр — Events counter. Это внутренний счётчик изменений массива; у «живых» дисков он всегда одинаковый, у выпавших — отстаёт на столько, сколько прошло между отказом и текущим моментом.

Выводы: первым отказал sdc в 11:28 пятницы. Администратор, видимо, этого не заметил (мониторинга не было). Через 4 часа 46 минут выпал второй диск sda, и массив остановился. У sda разрыв всего 30 events от актуального состояния — это значит, что его данные почти полностью свежие и пригодны для пересборки.

Выбор очевиден: собираем RAID5 из трёх дисков (loop0, loop1, loop3), четвёртый слот — missing. Использовать loop2 нельзя — его данные отстают на 9 часов, и при сборке получим битую файловую систему.

Шаг 4: сборка массива в degraded-режиме

Это самая напряжённая часть работы. Один неверный флаг команды mdadm --create — и parity пересчитается поверх актуальных данных, массив превратится в мусор. Поэтому сначала пробуем штатный assemble:

# Пытаемся собрать массив по сохранённым метаданным
sudo mdadm --assemble /dev/md127 /dev/loop0 /dev/loop1 /dev/loop3 --force

# Смотрим состояние
sudo mdadm --detail /dev/md127
# State : clean, degraded
# Active Devices : 3
# Working Devices : 3
# Failed Devices : 0
# Spare Devices : 0
#
# Number  Major  Minor  RaidDevice State
#    0    7      0      0          active sync   /dev/loop0
#    1    7      1      1          active sync   /dev/loop1
#    -    0      0      2          removed
#    3    7      3      3          active sync   /dev/loop3

Массив собрался с первой попытки благодаря метаданным, которые mdadm хранит в конце каждого диска. В случаях, когда assemble отказывает (например, метаданные затёрты), приходится использовать --create --assume-clean с указанием точного порядка дисков, chunk size и layout, и это уже высокий риск. В нашем случае обошлось штатными средствами.

Шаг 5: проверка файловой системы ext4

Массив собран, но он мог остановиться в середине записи — значит, файловая система в неконсистентном состоянии. Запускаем проверку в read-only сначала:

# Только проверка, без изменений
sudo e2fsck -nv /dev/md127

# Результат:
# /dev/md127: Inode 458732 has illegal block(s)
# /dev/md127: Inode 612094 has a bad extent header
# /dev/md127: Group descriptor 18 checksum is invalid
# UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

# Дальше — полная проверка с исправлением
sudo e2fsck -yfv /dev/md127
# 47 inode issues fixed
# 12 orphan inodes moved to lost+found
# Filesystem has been cleaned

Потеряли 12 файлов, которые попали в lost+found без имён. Позже разобрали их: 9 оказались временными файлами Office (lock-файлы открытых в момент сбоя документов), 2 — валидные документы бухгалтерии (восстановили из кешей Outlook у конкретных пользователей), 1 — бинарный файл непонятного происхождения.

Монтируем в режиме read-only, чтобы ничего случайно не повредить:

sudo mount -o ro /dev/md127 /mnt/restored
cd /mnt/restored
du -sh *
# 2.1T  contracts/
# 1.8T  court_cases/
# 3.4T  scans/
# 892G  correspondence/
# 178G  templates/
# 85G   administration/

find /mnt/restored -type f | wc -l
# 4 218 904 файла

Всё на месте. Для проверки целостности отдельных файлов я прогнал выборку из 500 случайных PDF-файлов через pdfinfo — 498 открылись, 2 повреждённых. Это погрешность в пределах нормы для восстановления после двойного отказа.

Шаг 6: перестройка массива и переход на RAID6

Восстановить данные — это только половина работы. Вторая половина — сделать так, чтобы ситуация не повторилась. В понедельник утром я привёз клиенту на замену 6 новых дисков: 3 × Seagate IronWolf Pro 6 ТБ (ST6000NT001) и 3 × WD Red Pro 6 ТБ (WD6003FFBX). Специально разных производителей — чтобы снизить риск одновременного отказа.

Собрали свежий RAID6 на 6 дисках:

# Создаём RAID6 на 6 дисков
# RAID6 выдерживает отказ ДВУХ дисков одновременно
sudo mdadm --create /dev/md0 --level=6 --raid-devices=6 \
  /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 \
  --chunk=256 --metadata=1.2

# Дополнительно — hot spare на случай отказа
# Добавим позже при расширении

# Полезный объём RAID6 из 6×6ТБ = 24 ТБ (6 - 2 на parity)
sudo mkfs.ext4 -L pravo_data -m 1 -L pravo_data /dev/md0
sudo mount /dev/md0 /mnt/data

# Копируем восстановленные данные обратно
sudo rsync -av --progress /mnt/restored/ /mnt/data/

На перезаливку 8.4 ТБ данных ушло 11 часов. К среде утру сервер работал как раньше, только уже на RAID6.

Шаг 7: мониторинг SMART и mdadm через Zabbix

Чтобы отказ первого диска не остался незамеченным, мы настроили мониторинг. Я использую Zabbix на отдельной виртуалке — он стоит в стойке нашего клиента и следит не только за RAID, но и за всей инфраструктурой. Ключевые метрики, по которым шлются алерты в Telegram:

• mdadm state — любое отклонение от clean/active → critical
• SMART health — если overall-health FAILING PRESENT → critical
• Reallocated_Sector_Ct — выше 50 warning, выше 200 critical
• Current_Pending_Sector — выше 10 → warning, выше 50 → critical
• Temperature — выше 50 °C → warning (WD Red Pro штатно работает до 55, но стабильность выше 45 падает)
• Power_On_Hours — каждые +8 760 часов (год) пишем в отчёт

Минимальная настройка без Zabbix — встроенный mdadm --monitor в daemon-режиме, который пишет email при изменении состояния массива. Стоит настроить за 5 минут, может спасти бизнес:

# /etc/mdadm/mdadm.conf
MAILADDR admin@company.ru
MAILFROM server@company.ru

# Включаем демон мониторинга
sudo systemctl enable mdmonitor
sudo systemctl start mdmonitor

# Тест — должен прийти email
sudo mdadm --monitor --scan --test --oneshot

Сколько это стоило клиенту и сколько стоила бы профилактика

Конкретные цифры по этому кейсу:

• Восстановление и сборка массива (60 часов работы) — 168 000 руб.
• 6 новых дисков (3 × IronWolf Pro 6 ТБ + 3 × WD Red Pro 6 ТБ) — 148 000 руб.
• Внешний SSD для офлайн-бэкапов на 8 ТБ — 32 000 руб.
• Настройка мониторинга и новой бэкап-системы — 45 000 руб.
• 3 дня простоя юристов (оценочно) — около 380 000 руб. упущенной работы

Итого — 773 000 руб. Для сравнения: нормальное IT-обслуживание офиса на 24 РМ в тарифе «Стандарт» стоит 78 000 руб./мес, или 936 000 руб./год. В эту сумму входит мониторинг, плановые проверки SMART, грамотные бэкапы, плановая замена дисков при износе. То есть один год нормального обслуживания дороже, чем разовое восстановление, — но в долгосрочной перспективе десятки подобных инцидентов в сумме превышают стоимость обслуживания многократно.

Чек-лист по RAID для офиса до 50 РМ

Сводный список рекомендаций, которые я даю каждому новому клиенту при аудите:

• RAID6, а не RAID5 для любого массива из 4 и более дисков по 4 ТБ и больше
• Диски NAS-класса (WD Red Pro, IronWolf Pro, Toshiba MG) — у них поддерживается TLER и есть защита от вибраций
• Диски разных партий или производителей — минимум половина массива не должна совпадать по serial range
• Hot spare на массивах от 6 дисков — при отказе ребилд стартует автоматически
• Мониторинг SMART и состояния массива с алертами в Telegram или на email
• Полноценный бэкап на отдельное устройство — RAID не является бэкапом
• Ежеквартальная проверка SMART-статистики — записывать тренд Reallocated_Sector_Ct
• Замена дисков по возрасту: после 55 000 часов (6.3 года) — планово, не дожидаясь отказа
• Регулярный scrub массива — echo check > /sys/block/md0/md/sync_action раз в месяц

FAQ — частые вопросы по восстановлению RAID

Можно ли восстановить RAID5 при отказе двух дисков?

Да, если хотя бы один из отказавших дисков частично читается. Через ddrescue создаётся посекторный образ с пропуском битых секторов, затем массив собирается в degraded-режиме из трёх живых элементов. Если оба диска полностью мертвы (электроника сгорела, головки лежат) — восстановление только в лаборатории за 25 000–120 000 руб. за диск.

Что лучше для офисного файлового сервера — RAID5 или RAID6?

Для массивов из 4 и более дисков по 4 ТБ и больше — только RAID6. RAID5 при ребилде после отказа одного диска работает без избыточности 12–36 часов, и статистически второй диск нередко умирает именно в это окно. RAID6 выдерживает одновременный отказ двух дисков, что критично для бизнес-данных.

Какие диски выбирать для RAID в офисе?

Для NAS/файлового сервера — WD Red Pro, Seagate IronWolf Pro, Toshiba MG-серии. Это диски класса «24×7 для NAS/серверов» с вибростабилизацией и поддержкой TLER. Обычные WD Blue или Seagate Barracuda не подходят — в RAID они вылетают из-за долгого recovery при ошибке чтения. Покупайте диски разных партий и производителей, чтобы снизить риск одновременного отказа.

Как узнать, что RAID на сервере деградировал?

Настройте мониторинг mdadm через email (mdadm --monitor) или Prometheus с node_exporter. Важнее смотреть SMART-атрибуты заранее: Reallocated_Sector_Ct выше 50 — повод заменить диск, 200+ — срочная замена. Также отслеживайте Current_Pending_Sector и Offline_Uncorrectable. Без мониторинга первый умерший диск в RAID5 никто не заметит до второго — и тогда беда.

Сколько стоит восстановление RAID в офисе Москвы?

Наши работы по программному восстановлению (mdadm, ddrescue, fsck, сборка) — 35 000–85 000 руб. в зависимости от размера массива и количества повреждённых дисков. Если нужна замена головок или чистая комната — это уже лаборатория, 60 000–250 000 руб. за массив. Практически всегда дешевле купить хорошие диски WD Red Pro и настроить RAID6 сразу.