Диск был здоров по SMART, а данные бились: виновником оказался кабель

MAATRIX

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

Симптомы: как выглядела тихая порча данных

Проблема заявила о себе не сразу и не эффектно — не было ни падений сервера, ни ошибок в логах уровня ядра, ни явного отказа диска. Симптомы были ровно такие, какими обычно бывает «silent data corruption» (тихая порча данных):

• периодически не совпадала контрольная сумма (checksum) уже сохранённых файлов при повторном чтении — файл, который явно записывался нормально, спустя время читался с другим содержимым;
• в базе данных изредка обнаруживались повреждённые записи — не потерянные, а именно испорченные: часть байт в строке не соответствовала ожидаемой структуре;
• частота была низкой и нерегулярной — проблема не воспроизводилась по требованию, что типично для аппаратных сбоев на грани помехоустойчивости, а не для программного бага;
• нагрузочные тесты и повторные операции чтения/записи «в моменте» иногда проходили чисто, что ещё больше сбивало с толку.

Важная деталь: ни один антивирус, ни проверка файловой системы (fsck/chkdsk), ни ревизия прав доступа ничего не находили. Это сразу отсекало типичные «программные» версии — оставались подозрения на память, диск и путь передачи данных.

Почему подозрение сразу пало на диск

Логика была прямой и в целом правильной: если данные бьются на хранилище — значит, скорее всего, дело в самом хранилище. Это самая частая причина такого рода проблем, и именно с неё разумно начинать любое расследование. Первым делом посмотрели именно на диск:

smartctl -a /dev/sda

Результат: SMART overall-health self-assessment test result: PASSED. Ни одного проблемного счётчика — ни Reallocated_Sector_Ct, ни Current_Pending_Sector, ни Offline_Uncorrectable, ни рост UDMA_CRC_Error_Count (о котором чуть ниже — он окажется важным). Диск выглядел образцово здоровым.

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

Фундаментальное ограничение SMART: что он видит, а что — нет

Здесь стоит остановиться и разобрать, что вообще измеряет SMART (Self-Monitoring, Analysis and Reporting Technology) и где проходит граница его компетенции.

SMART — это система самодиагностики, встроенная в электронику самого накопителя. Она отслеживает состояние:

• магнитных пластин (для HDD) или флеш-ячеек (для SSD) — количество переназначенных секторов, ошибки чтения на уровне носителя, деградацию ячеек;
• механики (для HDD) — время раскрутки шпинделя, ошибки позиционирования головок, вибрацию;
• встроенной электроники диска — температуру, количество включений/циклов, внутренние ошибки контроллера самого накопителя.

Иными словами, SMART отвечает на вопрос «здоров ли физический носитель и его собственная электроника внутри корпуса диска». Это критически полезная информация, но она описывает только внутреннюю зону ответственности диска — то, что происходит до момента, когда данные покидают его контроллер, и после того, как данные приходят на его контроллер.

А теперь ключевой момент: между диском и остальной системой есть путь передачи данных — кабель SATA или SAS, разъём на плате диска, разъём на материнской плате или на бэкплейне корзины, сам контроллер (встроенный в чипсет или отдельная HBA/RAID-карта), шина. Если данные искажаются именно на этом участке — уже после того, как они были корректно считаны с пластин/ячеек диска, или до того, как они корректно записываются на них — сам диск физически не может это заметить. Он честно отдал (или честно принял) правильные данные на своём конце провода; то, что случилось с ними дальше по пути, находится вне поля его зрения.

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

Куда искать, когда диск не виноват: диагностика тракта передачи

Когда стало ясно, что версия «дело в самом диске» тупиковая, расследование сместилось на путь передачи данных. Здесь пригодился один счётчик SMART, который на первом проходе не привлёк внимания, — UDMA_CRC_Error_Count.

194 Temperature_Celsius     0x0022   118   105   000    Old_age   Always       -       34
199 UDMA_CRC_Error_Count    0x0032   198   198   000    Old_age   Always       -       47

Этот атрибут — редкое исключение среди счётчиков SMART: он не про сам носитель, а именно про интерфейс передачи данных между диском и контроллером. Он считает ошибки контрольной суммы CRC, которые обнаруживаются и пересчитываются (retry) на уровне интерфейса SATA/SAS при передаче каждого блока данных. Ненулевое и растущее значение UDMA_CRC_Error_Count — это практически всегда сигнал именно про кабель, разъём или помехи на линии, а не про сам накопитель.

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

1. Снять показания UDMA_CRC_Error_Count до и после нагрузки. Запустили контролируемую последовательность операций записи/чтения с проверкой контрольных сумм каждого блока и сравнили счётчик до и после — он вырос, при этом smartctl -a по-прежнему показывал общий статус диска как «PASSED».
2. Физически заменить кабель как диагностический шаг. Это дешёвая и быстрая проверка: если после замены кабеля счётчик ошибок перестаёт расти при той же нагрузке — причина найдена. Так и произошло.
3. Повторить тот же тест записи/чтения через другой кабель для сравнения. Тот же набор операций, та же контрольная сумма, другой физический кабель — искажений не возникло. Это и стало финальным подтверждением: диск был ни при чём с самого начала, а система (файловая, приложение, ОС) — тем более.
4. Проверить механическую фиксацию разъёма. Отдельно стоит проверять именно фиксацию — плохо защёлкнутый или слегка подвижный разъём SATA даёт похожую картину: перемежающиеся ошибки, которые не воспроизводятся стабильно, потому что зависят от вибрации, температурного расширения контактов или случайного смещения при обслуживании сервера.

Корневая причина

По итогам диагностики причина оказалась именно в физическом кабеле: повреждённый (передавленный при монтаже), некачественный или недостаточно надёжно зафиксированный SATA-кабель создавал редкие ошибки передачи данных на участке между диском и контроллером. Эти ошибки:

• не были стабильными — проявлялись не при каждой передаче, а с низкой вероятностью, что и объясняло нерегулярность симптомов;
• частично перехватывались и пересчитывались (retry) на уровне интерфейса, о чём и говорил растущий UDMA_CRC_Error_Count — но не все ошибки такого рода гарантированно перехватываются механизмами коррекции, часть могла проходить как «успешная» передача с уже искажёнными битами;
• происходили строго после того, как диск корректно отработал свою часть — записал или прочитал данные с носителя без единой внутренней ошибки, что и объясняет, почему SMART оставался идеально чистым на всём протяжении инцидента.

Такие кабельные проблемы — довольно частая, но недооценённая причина «загадочной» порчи данных на серверах именно потому, что кабель редко проверяют в первую очередь: он не мигает лампочкой ошибки, не появляется в логах ОС напрямую и не входит в стандартный чек-лист «диск не работает — смотрим SMART».

Как выстроить проверку, чтобы не упереться в ту же ловушку

Главный практический вывод из этого инцидента: SMART — важный, но не единственный и не самодостаточный инструмент диагностики целостности хранения. Он покрывает свою зону ответственности — сам накопитель — и не покрывает путь передачи данных между диском и остальной системой. Если ограничиваться только им, часть причин порчи данных останется невидимой в принципе, не из-за невнимательности, а по архитектуре инструмента.

Практический порядок проверки при необъяснимой порче данных, который стоит держать под рукой:

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

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

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

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