Восстановление 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 — это вовсе не бэкап. 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 сразу.