Заменили диск и потеряли массив: типичная цепочка ошибок

MAATRIX

Вы всё сделали «по инструкции»: мониторинг показал деградацию диска, вы поставили замену и запустили восстановление массива — а через несколько часов вместо живого RAID получили полностью развалившийся массив и недоступные данные. Это не редкость и не невезение. Почти всегда за такой историей стоит не одна фатальная ошибка, а цепочка из двух-трёх мелких, каждая из которых сама по себе не критична. Разберём по шагам, где именно ломается сценарий «штатная замена диска» и что нужно сделать иначе, чтобы плановая операция не превращалась в восстановление с нуля.

Как это обычно происходит: цепочка мелких ошибок

Классический разбор инцидента почти всегда сводится к одному из двух сценариев — а часто к их сочетанию.

Сценарий первый: вынули не тот диск. Массив показал деградацию по одному логическому устройству, но физически из корзины сервера достали соседний накопитель — рабочий. В результате массив, который до этого спокойно жил в деградированном режиме с одним неисправным диском, в момент изъятия живого диска мгновенно теряет избыточность два раза подряд. Для RAID 5 это означает полную потерю данных на месте — массиву просто не из чего собирать недостающие блоки.

Сценарий второй: диск вынули правильно, но второй диск массива на самом деле уже был на грани отказа — просто эта деградация не бросалась в глаза, потому что при обычной нагрузке проблемные сектора почти не задействовались. Замена запускает ребилд — самую тяжёлую операцию для дисков массива, — и именно в этот момент скрытая проблема на «здоровом» диске проявляется по-настоящему.

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

Ошибка №1: перепутали физический слот с логическим номером

Это самая частая техническая причина «вынули не тот диск». Проблема в том, что связь между логическим именем устройства в системе (/dev/sda, /dev/sdb, /dev/sdc...) и физическим слотом в дисковой корзине не гарантирована и не постоянна.

Имена /dev/sdX в Linux назначаются в порядке обнаружения дисков контроллером при загрузке, и это порядок может измениться после перезагрузки, замены контроллера или даже без видимой причины — особенно если используется несколько контроллеров или экспандеров SAS. Человек, который помнит, что «неисправный диск — это sdc», через неделю после инцидента может обнаружить, что sdc — это уже физически другой накопитель.

Второй источник путаницы — отсутствие маркировки корзины. Если слоты сервера не подписаны понятно (или подписи стёрлись, или сервер брали не с самого начала работы), администратор ориентируется на предположение «второй слот сверху — это, наверное, второй диск в массиве». Это предположение и есть корень проблемы: логический номер устройства в RAID (RaidDevice в выводе mdadm) не обязан совпадать с физической позицией диска в корзине.

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

Ошибка №2: диск, который на самом деле уже был на грани

Второй сценарий тоньше первого, потому что формально всё сделано верно: вынут именно тот диск, который отмечен неисправным. Проблема в состоянии оставшихся дисков массива.

RAID из дисков, купленных и введённых в эксплуатацию одновременно (типичная ситуация для сервера, который не апгрейдили частями), стареет синхронно. Если один диск партии деградировал первым, вероятность, что соседние диски той же партии, того же возраста и с той же наработкой часов тоже близки к пределу ресурса, заметно выше средней — это не гарантия, но статистически значимый риск, который стоит держать в голове.

При этом штатный мониторинг может «молчать» не потому, что он сломан, а потому что не настроен на то, что действительно важно. Частые причины ложного спокойствия:

• Проверяются только явные атрибуты SMART (Reallocated_Sector_Ct, Current_Pending_Sector), но не отслеживается их динамика — счётчик может расти медленно и не пересекать порог тревоги до самого отказа.
• Не запускаются периодические smartctl -t long (полный поверхностный тест) — без него диск с уже накопленными нечитаемыми секторами может выглядеть «здоровым» в коротком тесте, потому что проблемные области физически не были прочитаны с момента предыдущей записи.
• Диски за аппаратным RAID-контроллером вообще не видны штатным smartctl без специальных флагов передачи команд через контроллер (-d megaraid,N, -d areca,N и т.п.) — и мониторинг диска на уровне ОС в такой конфигурации попросту не работает, создавая ложное ощущение, что «мониторинг настроен».

Подробнее о том, как выстроить контроль состояния дисков и остального железа, — в статье про мониторинг здоровья железа. Здесь важно зафиксировать главный вывод: то, что второй диск «не подавал признаков беды» в логах мониторинга, не означает, что он был действительно здоров — это может означать только то, что мониторинг не проверял то, что нужно.

Почему именно ребилд — самый опасный момент

Ребилд (rebuild, восстановление массива) — это процесс, при котором контроллер или программный RAID пересобирает данные для нового диска на основе оставшихся. Для parity-массивов (RAID 5, RAID 6) это означает последовательное чтение практически всего объёма каждого оставшегося диска массива, чтобы вычислить недостающие блоки через XOR контрольных сумм. Для зеркальных массивов (RAID 1, RAID 10) это прямое копирование всего объёма диска-донора.

В обоих случаях нагрузка на оставшиеся диски резко и надолго вырастает — это не пиковая нагрузка на секунды, а часы устойчивого интенсивного чтения (а для RAID 1/10 — ещё и записи) по всей поверхности диска, включая области, которые при обычной работе сервера могли не читаться месяцами. Именно поэтому ребилд — это стресс-тест для дисков, которые до этого молча жили с накопленными, но не проявившимися дефектами:

• Секторы, которые давно не читались, могут оказаться физически повреждёнными — при обычной работе туда просто не обращались.
• Повышенная температура и механическая нагрузка на протяжении нескольких часов подряд может добить диск, который и так был близок к пределу ресурса.
• Для больших по объёму дисков вероятность встретить хотя бы один нечитаемый сектор (unrecoverable read error) при полном последовательном чтении всего объёма выше, чем при типичной случайной нагрузке — это одна из причин, по которой для очень объёмных дисков в проде часто выбирают RAID 6 или RAID 10 вместо RAID 5: разница именно в том, сколько дисков может отказать одновременно без потери данных.

Итог простой: пока массив не начал ребилд, скрытая проблема на соседнем диске может годами оставаться незамеченной. Ребилд — это ровно тот момент, который её вскрывает, причём в худший из возможных моментов — когда избыточности у массива уже нет.

Что нужно было сделать иначе: точная идентификация диска

Правило одно: диск для замены идентифицируется по серийному номеру, а не по логическому предположению о том, «какой это, наверное, слот».

Для программного RAID (mdadm) порядок такой. Сначала смотрим состояние массива и какое устройство помечено как failed:

mdadm --detail /dev/md0

В выводе интересует блок с перечислением устройств — колонки Major, Minor, RaidDevice, State и путь устройства (/dev/sdX). Устройство в состоянии faulty или отсутствующее в списке (removed) — это то, что нужно менять.

Дальше — привязка логического имени к серийному номеру:

lsblk -o NAME,SERIAL,SIZE,MODEL,STATE
smartctl -i /dev/sdc | grep -i serial

Ещё надёжнее — использовать стабильные идентификаторы вместо /dev/sdX, которые могут «переехать» после перезагрузки:

ls -la /dev/disk/by-id/ | grep sdc

Здесь видно, какой ata-МОДЕЛЬ_СЕРИЙНИК соответствует текущему /dev/sdc. Серийный номер из этого вывода сверяется с серийным номером, физически напечатанным на наклейке диска — только такое сопоставление даёт гарантию, что вы вынимаете именно тот накопитель.

Если в сервере есть поддержка LED-индикации (большинство серверных корзин это поддерживает), самый безопасный способ — включить индикатор locate именно на нужном диске перед тем, как его трогать руками:

ledctl locate=/dev/sdc

После физической замены — выключить индикатор ошибки и подтвердить, что мигает нужный отсек, прежде чем вынимать диск.

Для аппаратного RAID-контроллера логика та же, но инструмент другой — используется утилита производителя контроллера (storcli/perccli/MegaCli в зависимости от модели), которая показывает список физических дисков со слотами и серийниками одной командой (например, storcli /c0 /eall /sall show для LSI/Broadcom-контроллеров) и умеет включать locate-индикатор конкретного диска по номеру слота.

И второе правило, которое важнее любых команд: свежий бэкап делается ДО любой операции с массивом — не после того, как рискнули, а заранее, как обязательное условие для начала работы. Ребилд массива — это не гарантированно успешная операция, а процедура с ненулевым риском отказа второго диска, и полагаться на то, что «RAID сам всё восстановит», нельзя. Если бэкапа нет — сначала бэкап, потом замена диска, даже если это займёт лишний час. Пошаговый порядок безопасной замены диска на живом массиве разобран отдельно в статье замена диска без простоя на RAID, а общий механизм того, что происходит при отказе диска в разных уровнях RAID, — в статье как работает RAID при отказе диска.

Восстановление после потери массива

Если массив всё же развалился, дальнейший сценарий целиком зависит от того, есть ли рабочий бэкап.

Если бэкап есть: это самый быстрый и предсказуемый путь. Массив пересоздаётся с нуля (новый mdadm --create с правильными параметрами уровня, размера чанка и порядка дисков — важно не перепутать порядок, иначе данные не соберутся даже с верными дисками), данные восстанавливаются из последней резервной копии, сервис поднимается заново. Именно поэтому бэкап — это не формальность «на всякий случай», а единственный по-настоящему надёжный план Б для операций с RAID.

Если бэкапа нет, ситуация принципиально хуже. Восстановление данных с развалившегося массива без бэкапа — это уже не системное администрирование, а задача для профессиональной лаборатории восстановления данных, и даже там результат не гарантирован по нескольким причинам:

• Для parity-массивов (RAID 5/6) данные каждого файла физически размазаны полосами (stripe) по всем дискам массива с чередованием контрольных сумм. Чтобы восстановить хоть что-то, нужны все диски массива (или почти все — в зависимости от уровня) и точное знание исходных параметров сборки (порядок дисков, размер чанка, версия метаданных). Если один из дисков физически повреждён — а именно так чаще всего и случается при потере массива на ребилде — часть данных может быть невосстановима принципиально, не из-за нехватки квалификации, а потому что информации физически не существует ни на одном из оставшихся носителей.
• Восстановление в специализированной лаборатории — это недели ожидания и стоимость, которая на порядок выше, чем стоимость системы резервного копирования, которая предотвратила бы саму ситуацию.
• Даже частичное восстановление файлов не гарантирует их целостность — для баз данных, например, восстановленный файл может быть логически повреждён (разорванные транзакции), даже если байты физически «читаются».

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

Частые вопросы