Ремонт файловой системы Windows: полное руководство по CHKDSK, SFC и DISM для NTFS и ReFS (2026)

Ключевые выводы:

• Правильный порядок: сначала DISM (восстановление хранилища), затем SFC (проверка системных файлов), и только потом CHKDSK (исправление ошибок диска).
• CHKDSK для NTFS: используйте /f для логических ошибок и /r для поиска битых секторов. Для ReFS применяйте /scan и /spotfix.
• Ошибка «не может восстановить»: анализируйте CBS.log и dism.log. При отсутствии интернета указывайте локальный ISO-образ как источник для DISM.
• Система не загружается: работайте через WinRE с загрузочной флешки, используйте bootrec для восстановления загрузчика и автономный SFC.
• Профилактика ReFS: настройте еженедельное онлайн-сканирование томов через PowerShell для предотвращения деградации данных.

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

Это руководство предоставляет системным администраторам и IT-специалистам проверенные на практике пошаговые инструкции. Вы научитесь точно диагностировать проблему, выбирать правильный инструмент и безопасно выполнять восстановление для файловых систем NTFS и ReFS в клиентских Windows 10/11 и серверных редакциях Windows Server 2016–2025, минимизируя простой серверов и рабочих станций.

Что делать прямо сейчас: три шага

1. Windows загружается, но есть сбои приложений и ошибки DLL? Откройте командную строку от имени администратора и выполните DISM /Online /Cleanup-Image /RestoreHealth, затем sfc /scannow. DISM обычно занимает 10–30 минут, SFC добавляет ещё 5–15 минут. CHKDSK на этом этапе не нужен.
2. Ошибки доступа к файлам, диск работает медленно, проверка диска запускается при каждой загрузке? Сначала оцените S.M.A.R.T. накопителя, затем выполните chkdsk C: /f — обычно это минуты. При подозрении на битые сектора переходите к chkdsk C: /r: на больших томах такая проверка может идти от 30 минут до нескольких часов.
3. Windows не загружается, появляются "BOOTMGR is missing" или "Inaccessible boot device"? Загрузитесь в WinRE с установочного носителя: "Поиск и устранение неисправностей" -> "Дополнительные параметры" -> "Командная строка". Перед любыми операциями скопируйте важные данные на внешний носитель, если диск читается.

Что вы найдете в этом руководстве:

• Четкий алгоритм: CHKDSK, SFC или DISM — что запускать при конкретных симптомах (синий экран, ошибки DLL, диск не читается).
• Готовые команды для восстановления системных файлов и загрузчика, даже если Windows не запускается.
• Расшифровка логов и ошибок: что значит «не может восстановить» или «xxxxxx KB in bad sectors».
• Особенности работы с ReFS в Windows Server: онлайн-проверка и профилактика.
• Действия при критических сбоях: восстановление через WinRE и приоритетное копирование данных.

CHKDSK, SFC или DISM: выбираем инструмент для конкретной проблемы

Основная ошибка при восстановлении Windows — хаотичное применение утилит без понимания их назначения. Это приводит к потере времени и может усугубить ситуацию. Используйте следующий алгоритм для точной диагностики.

Правильная последовательность действий: сначала восстановите хранилище компонентов с помощью DISM, затем проверьте системные файлы утилитой SFC, и только в случае ошибок диска или проблем с файловой системой запускайте CHKDSK. Эта логика одинакова в клиентских Windows 10/11 и в Windows Server 2016–2025. Единственное исключение — тома ReFS: вместо /f и /r для них используются /scan и /spotfix.

Алгоритм диагностики: от симптома к решению

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

1. Система не загружается, появляются ошибки типа "BOOTMGR is missing", "Inaccessible boot device" или синий экран на раннем этапе загрузки. Это указывает на повреждение загрузочных записей или критических системных файлов. Перейдите к разделу "Действия при критических сбоях".
2. Система загружается, но наблюдаются случайные сбои приложений, ошибки DLL, сбои в работе Windows Update или странное поведение интерфейса. Запустите проверку системных файлов. Выполните последовательно команды DISM, затем SFC (раздел "Пошаговое восстановление системных файлов").
3. Появляются ошибки при доступе к файлам на определенном диске ("Файл поврежден", "Невозможно прочитать"), медленная работа с диском, CHKDSK запускается при каждой загрузке. Это признаки проблем с файловой системой или поверхностью диска. Перед проверкой посмотрите атрибуты S.M.A.R.T., затем запустите CHKDSK (раздел "Глубокая проверка и восстановление диска").
4. Работа с томами ReFS в Windows Server: необходимо провести профилактическую проверку или устранение ошибок целостности. Используйте специальные команды CHKDSK для ReFS (раздел "Особенности работы с файловой системой ReFS").

Пошаговое восстановление системных файлов утилитами SFC и DISM

Повреждение системных файлов часто происходит из-за сбоев электропитания, действий вредоносного ПО, неудачных обновлений или ошибок жесткого диска. Восстановление выполняется из командной строки, запущенной с правами администратора.

1. Восстановление хранилища компонентов Windows с помощью DISM. Эта операция должна предшествовать запуску SFC.

DISM /Online /Cleanup-Image /RestoreHealth

Ключевые параметры:

• /Online — указывает на работу с текущей запущенной ОС.
• /Cleanup-Image — задает операцию обслуживания образа.
• /RestoreHealth — ключевой параметр, который инициирует поиск и замену поврежденных файлов в хранилище компонентов.

Процесс может занять 10–30 минут. Утилита автоматически подключится к серверам Microsoft для загрузки необходимых файлов, если есть доступ в интернет.

2. Проверка и восстановление системных файлов с помощью SFC. После успешного выполнения DISM запустите проверку.

sfc /scannow

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

• "Защита ресурсов Windows не обнаружила нарушений целостности." — проблем не найдено.
• "Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила." — проблема решена. Рекомендуется перезагрузка.
• "Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них." — это указывает на то, что либо не сработал DISM, либо повреждение критическое. Необходимо проанализировать логи.

Исправление ошибок DISM: работа с источниками обновлений

В корпоративных средах или при отсутствии интернета команда DISM /RestoreHealth может завершиться с ошибкой 0x800f081f "Источник файлов не найден". В этом случае используйте локальный ISO-образ Windows той же версии и сборки, что и установленная система, в качестве источника.

1. Смонтируйте ISO-образ Windows (например, в виртуальный привод E:).
2. Выполните команду, указав путь к файлу install.wim или install.esd:

   DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:E:\sources\install.wim:1 /LimitAccess

   Параметр /LimitAccess запрещает DISM обращаться к Центру обновления Windows.
3. Для Windows Server, где часто используется образ install.esd, команда будет аналогичной:

   DISM /Online /Cleanup-Image /RestoreHealth /Source:esd:E:\sources\install.esd:1 /LimitAccess

Расшифровка логов SFC и DISM: на что обратить внимание

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

Лог SFC (CBS.log): Находится по пути C:\Windows\Logs\CBS\CBS.log. Это большой файл. Для анализа откройте его в текстовом редакторе с поддержкой поиска (например, Notepad++) и найдите строки, содержащие "cannot repair" или "corrupt". В них будет указан конкретный поврежденный файл. Пример записи:

2026-05-18 10:15:23, Info CSI 000005b4 (F) STATUS: [0xc000009a] #ERROR# от CatDB: 0x800b0100 Corruption was detected in CatDB...

Эта информация поможет понять, какой компонент поврежден.

Лог DISM: Расположен в C:\Windows\Logs\DISM\dism.log. Ищите строки с уровнем "Error". Код ошибки (например, 0x800f081f) — это ключ к поиску решения в документации Microsoft. Частая ошибка — отсутствие доступа к источнику обновлений, что решается методом с локальным ISO, описанным выше. Пути к журналам и их формат не менялись: они одинаковы в клиентских Windows 10/11 и в Windows Server 2016–2025, включая Windows Server 2025, поэтому примеры выше применимы и к актуальным сборкам.

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

Глубокая проверка и восстановление диска с помощью CHKDSK

Утилита CHKDSK — это базовая проверка диска Windows: она предназначена для исправления логических ошибок файловой системы NTFS (а также exFAT и FAT32) и маркировки битых секторов. Её запуск на системном диске часто требует перезагрузки, так как для работы нужен эксклюзивный доступ к тому.

Ключевые параметры командной строки:

• chkdsk [буква_диска]: — выполняет проверку в режиме только для чтения, без исправлений.
• chkdsk [буква_диска]: /f — исправляет найденные ошибки файловой системы. Для системного тома потребует перезагрузки.
• chkdsk [буква_диска]: /r — находит поврежденные сектора и восстанавливает читаемую информацию. Включает в себя функциональность /f. Это самая долгая операция, которая может длиться часами на дисках большого объема.
• chkdsk [буква_диска]: /x — принудительно отключает том перед проверкой. Также включает /f.
• chkdsk [буква_диска]: /perf — ускоряет проверку за счет более интенсивного использования ресурсов системы. Доступен только для NTFS и применяется вместе с /r.

Пошаговая инструкция:

1. Предварительная проверка. Запустите chkdsk C: (без параметров), чтобы оценить состояние диска и увидеть, есть ли сообщения об ошибках. Это безопасно и не вносит изменений.
2. Исправление ошибок файловой системы. Если проверка выявила проблемы, запустите chkdsk C: /f. Для системного диска (C:) утилита предложит запланировать проверку при следующей перезагрузке. Подтвердите (Y), перезагрузите компьютер и дождитесь завершения сканирования до загрузки Windows.
3. Полная проверка с восстановлением данных. При подозрении на физические повреждения диска (щелчки, медленная работа, рост числа переназначенных секторов в S.M.A.R.T.) используйте chkdsk C: /r. Будьте готовы к длительному процессу.

Запуск CHKDSK из среды восстановления (WinRE): Если система не загружается или диск заблокирован, используйте загрузочный USB-накопитель с Windows или диск восстановления. Загрузитесь в среду восстановления, выберите "Поиск и устранение неисправностей" -> "Дополнительные параметры" -> "Командная строка" и выполните команду для нужного тома (его буква в WinRE может отличаться, используйте diskpart и list volume для уточнения).

Анализ отчета CHKDSK: понимание килобайт в bad-секторах

По завершении проверки с параметром /r CHKDSK выводит отчет. Строка "xxxxxx KB in bad sectors" часто вызывает тревогу. Важно правильно её интерпретировать.

Это значение показывает объем данных, которые находились в секторах, признанных нечитаемыми на момент проверки. CHKDSK пытается прочитать данные из сомнительного сектора. Если попытка неудачна, сектор помечается как "bad" (сбойный), и данные, которые должны были там храниться, теряются. Эти "килобайты в bad-секторах" — и есть потерянные данные.

Единичное небольшое значение (несколько килобайт) после однократного запуска /r — не катастрофа, это мог быть разовый сбой. Однако если это значение значительно (сотни мегабайт/гигабайты) или оно постоянно увеличивается при последующих проверках — это явный признак деградации поверхности жесткого диска или проблем с памятью NAND в SSD. В этом случае диск следует рассматривать как ненадежный и планировать его замену в ближайшее время. Рекомендуется немедленно создать резервную копию всех важных данных и ознакомиться с процедурами восстановления данных. Дальше держите накопители под постоянным контролем — подход к метрикам описан в материале о мониторинге и проактивном обслуживании дисковых массивов.

Особенности работы с файловой системой ReFS в Windows Server

Resilient File System (ReFS), начиная с версии 3.x в Windows Server, кардинально меняет подход к обслуживанию. Классический CHKDSK с параметрами /f и /r для неё не применяется. Вместо этого используется онлайн-проверка целостности и автоматическое восстановление с помощью тех же утилит, но с другими ключами.

Актуальные версии и сценарии. ReFS развивается вместе с платформой: ветка 1.x из Windows Server 2012/2012 R2 считается legacy (поддержка этих систем завершена, а набор команд обслуживания тома в них ограничен), ветка 3.x применяется в Windows Server 2016–2025. В Windows Server 2025 ReFS остается рекомендованной файловой системой для томов данных и Storage Spaces Direct, но системный том по-прежнему должен быть NTFS. В клиентских Windows 11 ReFS используется в сценарии Dev Drive для каталогов сборок и рабочих данных. Конвертации NTFS → ReFS как не было, так и нет: смена файловой системы выполняется созданием нового тома и переносом данных (см. пошаговые стратегии миграции данных между массивами), поэтому /scan и /spotfix остаются основным инструментом обслуживания.

Основные команды для ReFS:

• chkdsk [буква_диска]: /scan — запускает онлайн-проверку тома ReFS. Файловая система остается доступной для чтения и записи во время сканирования. Это основной инструмент для профилактики.
• chkdsk [буква_диска]: /spotfix — выполняет точечное исправление. Эта операция требует кратковременного отключения тома (несколько секунд). Используется, когда /scan выявил ошибки, требующие вмешательства с монопольным доступом.

Состояние томов ReFS можно быстро проверить в PowerShell:

Get-Volume | Select-Object DriveLetter, FileSystemType, HealthStatus, OperationalStatus

Для тома ReFS статус HealthStatus должен быть Healthy. Мониторинг событий также важен: в журнале "Приложения и службы" -> "Microsoft" -> "Windows" -> "ReFS" ищите события с ID 133 (начало проверки) и 134 (завершение проверки).

Профилактическое обслуживание ReFS для минимизации простоев

Сила ReFS — в предотвращении сбоев, а не в их исправлении. Внедрите регулярные проверки целостности.

Создайте PowerShell-скрипт для планировщика задач:

# Проверка всех томов ReFS и запуск онлайн-сканирования
Get-Volume | Where-Object {$_.FileSystemType -eq 'ReFS'} | ForEach-Object {
    Write-Host "Запуск онлайн-сканирования для тома $($_.DriveLetter):"
    chkdsk $($_.DriveLetter): /scan
}

Настройте задание в Планировщике задач Windows на еженедельный запуск этого скрипта в период наименьшей нагрузки (например, ночь воскресенья). Для высоконагруженных систем с большими томами (десятки ТБ) интервал можно увеличить до месяца, так как полное сканирование занимает значительное время. Регулярные проверки позволяют выявлять и исправлять проблемы с целостностью данных на ранней стадии, до того как они приведут к потере файлов или необходимости в операциях /spotfix, требующих кратковременной недоступности тома. Для комплексного управления инфраструктурой такие проверки стоит включить в общую базу знаний и процедуры обслуживания IT-систем.

Действия при критических сбоях: восстановление загрузки и данных

Когда Windows не загружается, стандартные методы не работают. В этом случае необходим структурированный подход через среду восстановления (Windows Recovery Environment, WinRE).

1. Создание загрузочного носителя. Используйте Media Creation Tool с официального сайта Microsoft или имеющийся установочный ISO-образ Windows для создания загрузочной USB-флешки.
2. Загрузка в WinRE. Загрузитесь с созданного носителя. На экране установки выберите "Восстановление системы" -> "Поиск и устранение неисправностей" -> "Дополнительные параметры" -> "Командная строка".
3. Восстановление загрузчика. В командной строке выполните последовательно команды:

   bootrec /fixmbr
   bootrec /fixboot
   bootrec /rebuildbcd

   Если bootrec /rebuildbcd не находит установленных систем, пересоздайте загрузочные файлы вручную: bcdboot D:\Windows (букву системного тома уточните через diskpart и list volume).
4. Проверка диска и системных файлов в автономном режиме. Определите букву системного раздела. Часто в WinRE буква C: присваивается зарезервированному разделу, а системный диск становится D:. Используйте dir D:\Windows для проверки. Затем выполните:

   chkdsk D: /r
   sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows

   Параметры /offbootdir и /offwindir указывают SFC на расположение автономной системы.
5. Приоритетное копирование данных. Перед агрессивными операциями, если диск определяется, скопируйте критически важные данные на внешний носитель. Используйте robocopy для надежного копирования с сохранением прав и атрибутов, а заодно проверьте, что регулярные копии настроены и протестированы — практические схемы собраны в руководстве по резервному копированию по стратегии 3-2-1. Если файловая система повреждена настолько, что данные не читаются стандартными средствами, потребуются специализированные инструменты для восстановления данных.
6. Решение о переустановке. Если после выполнения всех шагов система по-прежнему не загружается или работает нестабильно, а данные уже сохранены, наиболее эффективным решением часто становится чистая переустановка Windows. Это экономит время на дальнейшую диагностику неустранимых повреждений.

Частые ошибки и их решение

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

Ошибка: CHKDSK для диска постоянно "занят другим процессом".
Решение: Используйте параметр /x для принудительного отключения тома: chkdsk D: /f /x. Если это не помогает, отключите том вручную через diskpart (команды select volume X, затем offline volume), а после проверки верните том в строй командой online volume.

Ошибка: SFC не может восстановить повреждённые файлы, в CBS.log есть записи cannot repair или corrupt.
Решение: Сначала убедитесь, что DISM /RestoreHealth завершился успешно — SFC берёт целые копии именно из хранилища компонентов. Если источник недоступен, укажите локальный ISO через /Source и /LimitAccess и повторите sfc /scannow. Для единичного файла допустима ручная замена копией с рабочей системы той же сборки, но только после создания точки восстановления.

Ошибка: DISM завершается с кодом 0x800f081f "Источник файлов не найден" при отсутствии интернета.
Решение: Подключите ISO-образ Windows той же версии и сборки и повторите команду с параметрами /Source:wim:E:\sources\install.wim:1 /LimitAccess (или /Source:esd:... для install.esd). Параметр /LimitAccess запрещает обращение к Центру обновления, поэтому утилита берёт файлы только с указанного носителя.

Ошибка: CHKDSK зависает на 10–12% и не двигается дальше.
Решение: На этом этапе утилита обычно читает сбойные сектора, поэтому длительная пауза может быть нормальной — дайте процессу время, иногда это занимает несколько часов. Параллельно проверьте S.M.A.R.T.: рост переназначенных секторов указывает на деградацию накопителя. Если проверка не проходит даже в WinRE, сделайте резервную копию данных и планируйте замену диска, а для чтения повреждённого тома используйте специализированные инструменты.

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