Мониторинг здоровья дисков SMART и бэкапов: разница между плановой заменой и потерей базы 1С

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

Два сценария выхода диска из строя — и почему их нельзя путать

Когда клиент говорит «у нас упал диск», я всегда уточняю, какой из двух сценариев произошёл на самом деле, потому что стоимость ошибки отличается на порядки.

Сценарий А — плановая замена. Диск деградирует постепенно: растёт счётчик переназначенных секторов, увеличивается время отклика, появляются единичные ошибки чтения. SMART фиксирует это за 2-8 недель до отказа в подавляющем большинстве случаев, которые я видел на практике. Администратор видит алерт, заказывает диск, в плановое окно (обычно ночь с пятницы на субботу) переносит массив на новый носитель через ребилд RAID или штатную миграцию, простой — 0-15 минут на переключение путей. Стоимость инцидента — цена диска плюс час работы инженера.

Сценарий Б — безвозвратная потеря. Диск выходит из строя внезапно (физический удар, отказ контроллера, скачок питания без исправного ИБП) ИЛИ деградация была, но её никто не мониторил, и одновременно с отказом диска выясняется, что последняя рабочая резервная копия базы 1С — трёхнедельной давности, потому что задание бэкапа неделями падало с ошибкой, на которую никто не смотрел. Вот тут разговор идёт не о цене диска, а о цене трёх недель бухгалтерских проводок, которые нужно вносить заново, либо о невозможности сдать отчётность в срок.

Ключевой тезис этой статьи: SMART без мониторинга бэкапа закрывает только половину риска. Диск может быть в идеальном состоянии, а бэкап может месяцами писаться в лог с ошибкой, которую никто не читает — я такое видел у клиентов, где Windows Server Backup исправно работал внешне, но реально писал 0 байт из-за занятого VSS-writer'а. Поэтому оба потока — SMART-алерты и алерты бэкапа — должны сходиться в одну систему эскалации, и в конце статьи я покажу, как именно я это делаю.

Что реально измеряет SMART: не «здоровье» в процентах, а счётчики предикторов отказа

SMART (Self-Monitoring, Analysis and Reporting Technology) — это не единая метрика «здоровье 87%», как любят показывать некоторые утилиты. Это набор из полутора-двух сотен возможных атрибутов, где для прогноза отказа реально важны 6-8 штук, а остальное — производственный шум. Разработчику и директору полезно держать в голове не проценты, а конкретные ID атрибутов и их значение — потому что именно по ID я настраиваю пороги в smartd и Zabbix.

Отдельно стоят NVMe-накопители — там нет классических Attribute ID, вместо них стандартный NVMe SMART/Health Information Log с полями Critical Warning (битовая маска — ненулевое значение уже означает деградированный или read-only режим, аппаратный сбой или превышение температурного порога), Percentage Used (оценка процента выработанного ресурса, может превышать 100%) и парой Available Spare / Available Spare Threshold — переход спейра ниже порога документация NVM Express прямо классифицирует как критическое событие. smartctl читает этот лог опцией -l nvme-smart-log либо в составе -a/-x для устройств типа -d nvme.

Важная оговорка, которую я всегда проговариваю с клиентами: SMART предсказывает не 100% отказов. По независимым исследованиям больших пулов дисков (в первую очередь Backblaze) значимая часть физических отказов происходит без предупреждения по SMART вообще. Поэтому SMART — это снижение риска, а не его исключение; резервное копирование остаётся обязательным независимо от того, что показывают счётчики.

smartctl и smartd: разворачиваем мониторинг на сервере 1С за один заход

На всех серверах с Linux (в том числе на серверах 1С под PostgreSQL, которые я всё чаще ставлю клиентам вместо MS SQL для снижения лицензионных издержек) я использую пакет smartmontools: утилиту smartctl для разовых проверок и фоновый демон smartd, который читает /etc/smartd.conf и следит за атрибутами постоянно, шлёт почту и пишет в syslog при выходе за пороги.

Разовая диагностика диска:

Общий вердикт -H (SMART overall-health self-assessment) полагается на встроенную логику диска и может показывать PASSED даже при ненулевом Current_Pending_Sector — поэтому в проде я никогда не ограничиваюсь одной этой проверкой, а гоняю полный -a и парсю конкретные атрибуты.

Демон запускается директивой DEVICESCAN в /etc/smartd.conf, либо явным перечислением устройств, что я предпочитаю на серверах — так нет риска пропустить новый диск без реакции скрипта или, наоборот, поймать шумные алерты по временно воткнутой флешке:

Разбор директив, за которыми я слежу отдельно:

• -a — включает полный набор проверок для ATA-дисков, в том числе -C 197 (мониторинг Current_Pending_Sector) и -U 198 (мониторинг Offline_Uncorrectable) по умолчанию — это подтверждённое поведение демона, отдельно эти два флага прописывать не нужно, если они не отличаются от дефолтных ID.
• -o on — включает offline-тестирование диска самим диском в простое.
• -S on — включает автосохранение атрибутов диском между циклами питания.
• -s (S/../.././03|L/../../6/04) — расписание: короткий self-test каждый день в 03:00, длинный (extended) по субботам в 04:00. Короткий тест на современных дисках занимает 1-2 минуты и проверяет электронику и часть поверхности, длинный — до нескольких часов и всю поверхность.
• -W 4,45,50 — температурный контроль по схеме DIFF,INFO,CRIT: писать в лог при изменении температуры на 4°C и больше, информационное сообщение от 45°C, критический алерт с почтой от 50°C.
• -m и -M exec — почта и вызов внешнего скрипта (у меня это обычно обёртка, которая параллельно шлёт то же самое в Telegram-бот, потому что почту в 3 часа ночи никто не читает).

После правки конфига — не забыть systemctl restart smartd и проверить, что демон реально стартовал: systemctl status smartd и хвост journalctl -u smartd -n 50. Частая ошибка новичков — поправили конфиг, а демон не перечитал его и продолжает жить со старыми порогами до следующего ребута.

Windows-серверы без централизованного мониторинга: CrystalDiskInfo и встроенный WMI

Не у всех клиентов есть Zabbix и выделенный Linux-хост под него — у части (обычно это компании до 15-20 РМ) вся инфраструктура — это один Windows Server со встроенным Hyper-V или просто файл-сервер плюс терминалка. Там я ставлю связку попроще.

CrystalDiskInfo — бесплатная утилита, которая читает те же атрибуты SMART через тот же ATA/NVMe-интерфейс, что и smartctl, но даёт наглядный светофор (голубой/жёлтый/красный) и умеет сворачиваться в трей с уведомлением при ухудшении статуса. Для одиночного сервера без выделенного мониторинга это разумный минимум — я ставлю её в автозапуск с опцией уведомления в трей и дополнительно настраиваю копию оповещения на email через встроенный SMTP-алерт в её настройках, чтобы предупреждение не потерялось, если сервер обслуживает инженер, который редко смотрит на экран консоли.

Второй уровень для Windows — штатный класс WMI MSStorageDriver_FailurePredictStatus (пространство имён root\wmi), который отдаёт булево «диск предсказывает отказ» без деталей по атрибутам, и класс MSStorageDriver_FailurePredictData, который отдаёт уже сырые байты VendorSpecific — по сути тот же блок атрибутов SMART, но его придётся парсить самостоятельно (сдвиги совпадают со стандартной структурой ATA SMART Attribute Table). Практический смысл: если Zabbix ещё не развёрнут, можно временно опрашивать этот WMI-класс PowerShell-скриптом по расписанию через планировщик и слать результат на почту — это не заменяет полноценный smartctl/Zabbix, но закрывает риск на переходный период, пока внедряется постоянный мониторинг.

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

Zabbix: сводим SMART с десятков серверов в одну панель с триггерами

Начиная с версии Zabbix 6.2 существует официальный шаблон-модуль SMART для Zabbix agent 2 (входит в поставку самого агента как загружаемый модуль/плагин, без внешних Perl/Python-скриптов), который работает через тот же smartmontools версии 7.1 и выше — сам агент дергает smartctl в формате JSON (smartctl -a --json) и парсит результат. Это удобнее самописных UserParameter-скриптов, которые я использовал раньше и которые ломались при обновлении smartmontools из-за смены формата вывода.

Логика шаблона в двух LLD-правилах (Low-Level Discovery):

Ключевая настройка, которую я всегда меняю сразу после привязки шаблона — пороги триггеров по умолчанию рассчитаны на общий случай, а для конкретной модели диска стоит свериться с паспортом производителя. Практический подход: я делаю override шаблона на уровне хоста для критичных серверов 1С, где выставляю триггер уровня Average при первом ненулевом значении Current_Pending_Sector (197) и Reallocated_Sector_Count (5), и триггер уровня High с эскалацией в Telegram при их дальнейшем росте между двумя опросами подряд (интервал опроса у меня обычно 1 час для серверов, дольше — для рабочих станций, чтобы не грузить агента). Отдельный триггер — на температуру: превышение критического порога сразу поднимает severity до Disaster, потому что перегрев обычно означает проблему с охлаждением всей корзины, а не одного диска, то есть под угрозой весь массив разом.

Для серверов за аппаратным RAID (например, LSI/Broadcom MegaRAID, HPE Smart Array) чистого /dev/sdX для SMART-опроса физических дисков недостаточно — контроллер прячет диски за собой, и smartctl нужно указывать тип устройства явно, например -d megaraid,2 или для HPE — через ssacli/hpssacli отдельно от smartctl, потому что часть RAID-контроллеров вообще не пробрасывает ATA SMART команды напрямую, а отдаёт только собственный статус диска (Predictive Failure, Failed, Rebuilding). Я всегда проверяю это в первый день после установки контроллера — иначе можно месяцами мониторить фантомные атрибуты, которые контроллер просто не транслирует.

Veeam Backup & Replication: где реально рвётся бэкап базы 1С и как это ловить

SMART закрывает риск отказа железа. Но у клиентов с виртуализацией на VMware/Hyper-V и Veeam Backup & Replication отдельный источник тихой катастрофы — задание бэкапа, которое формально «зелёное» в интерфейсе, но реально не даёт восстанавливаемую копию.

Три встроенных механизма, которые я включаю всем клиентам на Veeam без исключений:

• Health Check for Backup Files — по умолчанию выполняется в 5:00 в последнюю субботу месяца (расписание можно и нужно менять на еженедельное для баз 1С с высокой оборачиваемостью данных). Механизм делает CRC-проверку метаданных и хэш-проверку блоков данных в файле бэкапа — то есть проверяет не «прошло ли задание», а «читается ли реально записанное». Это отдельная настройка от самого задания резервного копирования, и на части инсталляций я находил её выключенной по умолчанию — обязательно проверять чекбокс в Storage-настройках задания.
• RPO Monitor — для заданий backup copy можно включить предупреждение, если новая точка восстановления не скопировалась в целевой репозиторий в пределах заданного RPO, отсчёт идёт от момента завершения основного задания-источника. Это тот механизм, который ловит ситуацию «бэкап на площадку Б перестал долетать», а не только «бэкап на площадке А не создался».
• SureBackup — в отличие от Health Check (который проверяет целостность байтов), SureBackup поднимает VM из бэкапа в изолированной песочнице и реально проверяет, что она загружается и отвечает — для сервера 1С это единственный способ убедиться, что из копии можно поднять именно рабочую систему, а не просто непротиворечивый набор блоков.

На практике для клиента с одним сервером 1С на выделенной VM я обычно настраиваю: ежедневный incremental backup job, еженедельный Health Check (не месячный дефолт), и один SureBackup-прогон в месяц по расписанию в нерабочее время с уведомлением на почту при провале любого из трёх шагов. Это дороже по ресурсам хранилища и CPU, чем дефолтная конфигурация, но именно эта комбинация ловит оба типа сбоя — «файл бэкапа битый» и «система из бэкапа не поднимается».

Мониторинг статусов заданий на масштабе (у клиентов с 30+ РМ и несколькими виртуальными серверами) я завожу через Veeam ONE или, если Veeam ONE не куплен отдельно, через опрос PowerShell-модуля Veeam (командлеты вроде Get-VBRBackupSession) по расписанию с отправкой в тот же Zabbix как trapper-элементы — так статус бэкапов и статус SMART дисков живут в одной панели и в одной цепочке эскалации, а не в двух разных консолях, за которыми нужно следить по отдельности.

Windows Server Backup: бюджетный контур без Veeam — и его слепые зоны

У части небольших клиентов (обычно до 15 РМ, один физический сервер, без виртуализации) стоит штатный Windows Server Backup — он бесплатен, но у него принципиально более узкий набор встроенной диагностики, и его обязательно нужно опрашивать снаружи, а не доверять единственному индикатору «зелёная галка» в консоли.

Базовая проверка статуса через PowerShell-модуль WindowsServerBackup:

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

Второй слепой участок — VSS (Volume Shadow Copy Service), через который Windows Server Backup снимает консистентный снимок работающей базы. Если VSS writer для SQL Server или для файловой службы 1С в состоянии ошибки (проверяется командой vssadmin list writers, статус должен быть [1] Stable, No error у каждого writer'а), бэкап может формально завершаться успешно, но без консистентного снимка базы данных — то есть точка восстановления существует, но восстановленная из неё база будет повреждена или неполна. Эту проверку я включаю отдельным пунктом в скрипт еженедельного контроля наравне со SMART-отчётом.

Практическая связка для клиента без Zabbix: простой PowerShell-скрипт по расписанию задачи планировщика, который последовательно вызывает Get-WBSummary, vssadmin list writers и (если диски локальные) Get-PhysicalDisk | Get-StorageReliabilityCounter — последний командлет, кстати, тоже читает часть тех же SMART-подобных счётчиков через Storage Spaces API (поля вроде ReadErrorsUncorrected, Wear для SSD) без установки smartctl вообще — и одним письмом раз в неделю присылает сводку по трём пунктам сразу: диск, VSS, факт последнего успешного бэкапа.

Как я свожу два потока алертов в одну эскалацию — регламент, а не две разрозненные системы

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

Отдельно фиксирую в регламенте с клиентом: критический алерт по диску без параллельной проверки свежести бэкапа — это неполная реакция. Первое, что я делаю при получении критического SMART-алерта на сервере с базой 1С, — это не заказ диска (это можно сделать и через час), а проверка даты последней подтверждённой точки восстановления. Если она свежая — есть время работать по плану. Если нет — приоритет №1 меняется: сначала любой ценой получить консистентный бэкап с деградирующего диска (даже ценой нагрузки на умирающий носитель), и только потом заниматься заменой железа.

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

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

Можно ли полностью полагаться на общий вердикт SMART (PASSED/FAILED) без разбора отдельных атрибутов?

Нет. Общий вердикт (SMART overall-health self-assessment, флаг -H в smartctl) строится на внутренней логике самого диска и на практике нередко показывает PASSED даже при ненулевом Current_Pending_Sector или растущем Reallocated_Sector_Count. Для прогноза отказа нужно смотреть конкретные атрибуты по ID, а не только итоговый вердикт.

SMART гарантированно предскажет отказ диска заранее?

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

В чём разница между Health Check и SureBackup в Veeam — нужны ли обе проверки?

Health Check проверяет целостность байтов в файле бэкапа (CRC метаданных и хэш блоков данных) и умеет чинить повреждённые блоки из следующей точки восстановления. SureBackup поднимает VM из бэкапа в изолированной среде и проверяет, что система реально загружается и отвечает. Это проверки разного уровня, и для сервера 1С я рекомендую обе: битый файл и файл, из которого система не поднимается — два разных сценария отказа.

Что делать, если у сервера аппаратный RAID-контроллер и smartctl не видит физические диски?

Указать тип устройства явно (например, -d megaraid,N для LSI/Broadcom) — так smartctl обращается к конкретному физическому диску за контроллером, а не к виртуальному логическому тому. Часть контроллеров (в первую очередь ряд моделей HPE Smart Array) вообще не транслирует ATA SMART-команды и отдаёт только собственный статус диска через фирменную утилиту — это нужно проверять сразу при установке сервера, а не постфактум при инциденте.

Как понять, что Windows Server Backup реально работает, а не только показывает зелёный статус?

Смотреть не факт запуска задания, а именно поле последнего успешного бэкапа (Get-WBSummary отдаёт оба значения отдельно), и дополнительно проверять статус VSS writer'ов командой vssadmin list writers — все должны быть в состоянии Stable, No error. Задание может формально завершаться, но без консистентного снимка базы, если writer для 1С/SQL был в состоянии ошибки на момент снятия копии.