153 Windows Server, AD и Роли

Event ID 153 Disk: Повторная попытка операции ввода-вывода (IO Retried)

Обновлено: 15.08.2026 · Официальная документация ↗

Архитектура дискового I/O и симптомы задержек

Событие 153 логируется в журнале System источником Disk. Сообщение: «Повторная попытка выполнения операции ввода-вывода по логическому адресу блока [LBA] для диска [Номер]». Это предвестник катастрофы. Ядро Windows (драйвер classpnp.sys) обнаружило, что отправленный на жесткий диск запрос на чтение/запись не выполнился в отведенный таймаут (от 15 до 60 секунд). ОС сбросила запрос и пытается выполнить его повторно. Симптомы: сервер кратковременно замирает (Freeze), SQL базы тормозят, а ВМ в кластере Hyper-V могут отвалиться с >ошибкой 5120 (CSV Lost).

Структура LBA (Logical Block Address)

Событие точно указывает LBA (Адрес блока). Если при новых событиях 153 адрес LBA один и тот же — это физически поврежденный сектор на диске (Бэд блок). Контроллер безуспешно пытается его прочитать. Если адреса LBA постоянно разные — это общая перегрузка СХД или сетевая проблема iSCSI.

Пошаговое дерево решений (Диагностика СХД и RAID)

Сценарий 1: Аппаратная перегрузка СХД (SAN)

Если диск подключен по сети (iSCSI / Fibre Channel), 153 означает потерю пакетов в сети хранения данных (Storage Network) или перегрузку кэша массива.

Определение диска: В сообщении указан 'Диск 2'. Откройте Управление дисками (diskmgmt.msc), чтобы понять, какой это LUN или RAID-массив.
Анализ очередей MPIO: Проверьте логи Multipath I/O (событие 23). Если пути мигают (Flapping), проблема в свитчах SAN (FC Switches).
Выравнивание нагрузки: Убедитесь, что бэкапы (Veeam) не запускаются одновременно с тяжелыми регламентными заданиями SQL Server. СХД просто не успевает отвечать (IOPS Bottleneck).

Сценарий 2: Локальные диски (SSD/HDD) и Bad Blocks

Для локальных серверов 153 (особенно в паре с >событиями 129) — это 100% признак появления битых секторов. Драйвер диска уходит в 'Deep Recovery', пытаясь вычитать данные.

# Запуск проверки целостности файловой системы и секторов (потребует ребута)
chkdsk C: /f /r

Немедленно проверьте статус массива (Hardware Health) в консоли iLO/IPMI сервера. Деградирующий диск нужно заменить (Hot-Swap).

Типовые ошибки администраторов

Изменение таймаутов в реестре: Многие админы пытаются 'вылечить' 153, увеличивая ключ Disk\TimeOutValue до 120 секунд. Это скрывает симптом, но убивает базы данных. Задержка I/O в 120 секунд заставит 1С и SQL отвалиться по собственным таймаутам приложений (Lock Wait Timeout). Лечите железо, а не реестр.

Базы данных тормозят, а серверы регулярно "подвисают" на 15 секунд?
Дисковые задержки (Storage Latency) разрушают производительность Enterprise систем. Возьмем физическую инфраструктуру и СХД на обслуживание: проанализируем I/O очереди, обновим Firmware RAID-контроллеров, оптимизируем MPIO/iSCSI и вернем серверам скорость NVMe.

💡 Практика специалистов: При виртуализации VMware (ESXi) внутри гостевой ОС Windows часто спамит ошибка 153. Это возникает при бэкапе ВМ через VADP (Veeam Backup). Гипервизор аппаратно 'глушит' ВМ (состояние Stun) на этапе удаления VM Snapshot. I/O останавливается, и Windows пишет ошибку 153. Это нормальное архитектурное (хоть и неприятное) поведение платформ виртуализации.

Частые вопросы (FAQ)

Чем 153 отличается от 129 (Storport Reset)?

Событие 153 (Disk) ловит проблему на верхнем уровне — логическом диске LUN. Событие 129 (Storport) ловит проблему ниже — на уровне самого физического HBA-адаптера или RAID-контроллера. Обычно они появляются парой: контроллер завис (129), диск не дождался ответа и повторил запрос (153).

Почему 153 спамит при создании снимка виртуальной машины (Checkpoint)?

При создании снимка VSS-провайдер 'замораживает' (Freeze) дисковый I/O на несколько секунд, чтобы скинуть данные из RAM на диск. Если СХД медленная, заморозка превышает таймаут (15 сек), и Windows бьет тревогу. Это частая проблема 'медленных' гипервизоров.

Может ли старый кабель вызвать 153?

Да. Перебитый SAS или SATA кабель внутри сервера вызывает аппаратные ошибки передачи (CRC Errors). Контроллер бракует пакеты и запрашивает их повторно (Retried).

Поможет ли форматирование диска?

Если проблема в физических сбойных секторах (Bad Blocks), то при полном форматировании (не быстром) контроллер диска переназначит их в резервную область (Reallocated Sector Count). Это временно спасет ситуацию, но диск уже начал 'сыпаться'.

Как найти процесс, который так сильно грузит диск?

Откройте Монитор ресурсов (resmon.exe), вкладка 'Диск'. Раскройте секцию 'Работа процессов с диском'. Отсортируйте по 'Всего (Б/сек)'. Вы увидите .exe файлы, которые генерируют максимальный I/O.