Диск в сервере посыпался: как быстро понять состояние RAID-массива и не потерять базу 1С

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

Почему один упавший диск — это ещё не катастрофа, а вот второй — уже да

RAID придумали как раз для того, чтобы отказ одного диска не убивал данные. RAID1, RAID5, RAID10 — неважно, какой у вас, суть одна: есть избыточность, и потеря одного элемента массива не должна ронять базу. Сервер продолжает работать, 1С открывается, кассиры пробивают чеки, бухгалтер формирует накладные. Внешне всё нормально.

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

У меня в практике был клиент — небольшая торговая компания, 18 рабочих мест. RAID5 на четырёх дисках, контроллер PERC H700. Диск вылетел в пятницу вечером, никто не заметил — индикатор на морде сервера мигал жёлтым, но кто на него смотрит, если он в шкафу под лестницей. В понедельник вылетел второй. Итог: три дня простоя, восстановление базы из бэкапа месячной давности, потерянные накладные за месяц пришлось вбивать заново вручную. Это стоило компании больше, чем замена дисков на пять лет вперёд.

Первый признак: сервер стал работать медленнее, чем обычно

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

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

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

Как посмотреть статус RAID без специальных знаний

Способ проверки зависит от контроллера. У большинства серверов начального и среднего уровня — Dell PowerEdge, HPE ProLiant, Supermicro — стоит аппаратный RAID-контроллер: LSI/Broadcom, PERC (это тот же LSI, просто с логотипом Dell), Smart Array у HPE. У каждого своя утилита командной строки, но логика одинаковая: заходите, смотрите статус каждого виртуального диска и каждого физического диска отдельно.

Для Dell PERC это утилита perccli (или устаревшая megacli). Команда perccli /c0/vall show покажет виртуальные диски и их состояние — если видите Optimal, всё хорошо, если Degraded или Partially Degraded — один диск уже выбыл. Команда perccli /c0/eall/sall show покажет физические диски — там будите искать статус Online, Rebuild или, что хуже всего, Failed. Для HPE аналогичная история через утилиту ssacli: ssacli controller slot=0 physicaldrive all show status.

Если у вас программный RAID на Linux (mdadm) — там всё ещё проще, команда cat /proc/mdstat покажет состояние прямо в консоли: строка вида [UU] означает, что оба диска в строю, а [U_] — что один выбыл. Для Windows Server с программным зеркалированием смотрите в Диспетчере серверов, раздел «Файловые службы и службы хранилища» — там статус тома подсвечивается красным при деградации. Занимает эта проверка три минуты, а информации даёт достаточно, чтобы понять — паниковать или нет.

SMART диска — второй слой диагностики, который часто игнорируют

Статус RAID говорит «диск выпал из массива». А вот почему он выпал и что будет со вторым — расскажет SMART-атрибуты самого диска. На Linux это делается утилитой smartctl из пакета smartmontools: smartctl -a /dev/sda покажет десятки параметров, но реально важных — три-четыре. Reallocated Sector Count — количество секторов, которые диск уже переназначил из-за повреждений. Если там ноль — диск в порядке. Если растёт от проверки к проверке — это тикающая бомба.

Current Pending Sector — секторы, которые диск подозревает в проблеме, но ещё не переназначил. Ненулевое значение — повод для беспокойства даже если Reallocated ещё на нуле. И Reported Uncorrectable Errors — ошибки, которые диск не смог исправить самостоятельно. Любое ненулевое значение здесь — сигнал менять диск, не дожидаясь полного отказа.

На серверах за аппаратным RAID-контроллером просто так smartctl не сработает — контроллер прячет диски от операционной системы. Нужно указывать тип устройства явно, например smartctl -a -d megaraid,0 /dev/sda для LSI/PERC-контроллеров, перебирая номера дисков 0, 1, 2 и так далее. Да, это чуть муторнее, но именно так вы увидите реальную картину по каждому физическому диску, а не только общий статус массива.

Что делать прямо сейчас, если массив уже деградирован

Первое и самое важное — сделать бэкап базы 1С немедленно, руками, прямо сейчас, не дожидаясь ночного расписания. Если у вас настроено регулярное резервное копирование через встроенные средства 1С или сторонний Veeam — запустите внеплановое задание. Если бэкапа нет вообще — это отдельная и более серьёзная проблема, но сейчас не время её обсуждать, сейчас нужно скопировать файл базы .1CD или сделать выгрузку .dt на внешний носитель, который физически не в этом сервере. Флешка, сетевая папка на другой машине, облако — что угодно, лишь бы не тот же RAID.

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

Третье — заказывайте диск на замену того же типа, желательно из другой партии поставки, и не тяните. Ребилд массива после замены диска — процесс небыстрый, для RAID5 на дисках по 2-4 ТБ это может занять от нескольких часов до суток, и всё это время нагрузка на оставшиеся диски повышенная. У меня было так, что клиент купил замену через три недели после первого отказа — просто «руки не дошли». За эти три недели второй диск успел выдать первые ошибки в SMART. Успели среагировать, но нервов потратили прилично.

Мониторинг — чтобы в следующий раз узнать раньше вас же самих

Ручная проверка раз в месяц — это лучше, чем ничего, но людям свойственно забывать. У нас в компании для клиентов настроен автоматический мониторинг через Zabbix, который опрашивает статус RAID-контроллеров и SMART-атрибуты дисков каждые несколько минут и присылает алерт в Telegram при малейшем отклонении от нормы — задолго до того, как это заметит пользователь по тормозящей 1С.

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

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

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

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

Можно ли просто вынуть неисправный диск и вставить новый без остановки сервера?
Да, если диски у вас в hot-swap корзинах, а такое почти всегда стоит на серверах уровня Dell PowerEdge, HPE ProLiant, Supermicro — это штатная операция, сервер продолжает работать. Контроллер сам запустит ребилд после установки нового диска. Важно только убедиться, что вынимаете именно неисправный диск, а не рабочий — перепутать слоты при усталости в конце рабочего дня проще, чем кажется.

Сколько по времени идёт восстановление RAID после замены диска и можно ли в это время работать в 1С?
Для RAID5 или RAID6 на дисках объёмом 2-4 ТБ ребилд обычно занимает от 4 до 20 часов в зависимости от загрузки сервера и модели контроллера, для RAID1/RAID10 заметно быстрее. Работать в 1С в это время можно, но производительность будет ниже обычной — контроллер делит ресурсы диска между пересборкой массива и обычными операциями. Крупные регламентные операции вроде закрытия месяца лучше на этот период отложить.

Стоит ли переходить на SSD, чтобы избежать таких проблем в будущем?
SSD снижают вероятность механического отказа, потому что там нет движущихся частей, и заметно ускоряют работу 1С на операциях с большой базой. Но SSD тоже выходят из строя, просто по другой причине — исчерпание ресурса ячеек памяти, и там тоже нужен мониторинг SMART-атрибутов, только других — Media Wearout Indicator или Percentage Used. Так что переход на SSD решает проблему скорости и отчасти надёжности, но не отменяет необходимость следить за состоянием диска и делать бэкапы.