Восстановление файловой системы через LiveCD в 2026: ext4, NTFS, GRUB, testdisk — пошагово с SystemRescue и GParted

Подготовка к восстановлению: минимизация рисков и выбор инструмента

Повреждение файловой системы или загрузчика требует немедленных, но взвешенных действий. Типичные критические ситуации, которые решает эта статья: система не видит диск после сбоя, пропали файлы и разделы, загрузчик GRUB перестал работать, диск определяется, но разделы отображаются как «unknown». Главный принцип: сначала диагностика и резервное копирование, только потом восстановление. Загрузка с LiveCD - единственный корректный метод, когда основная операционная система не стартует. Вы получаете контроль над дисками, не монтируя повреждённые разделы в режиме записи. Всё, что ниже, — это восстановление файловой системы ext4 и NTFS через LiveCD: проверенные на практике команды, актуальные для 2026 года, и пошаговые рецепты для GRUB, GPT/MBR и потерянных разделов.

Что вы получите:

• пошаговые рецепты для fsck (ext4), ntfsfix (NTFS), восстановления загрузчика GRUB и таблиц GPT/MBR;
• готовый чек-лист «5 команд за 2 минуты» для экспресс-диагностики;
• таблицу сравнения инструментов — fsck, testdisk, photorec, dd/gddrescue;
• проверенные сценарии с SystemRescue, Ubuntu Live и GParted Live.

Кому и когда пригодится. Руководство рассчитано на DevOps-инженеров и системных администраторов, которым нужно быстро вернуть работоспособность сервера или рабочей станции, не перечитывая официальную документацию. Типовые сценарии:

• Linux не загружается и выдаёт GRUB rescue, Boot device not found или Invalid EFI file path — восстановление загрузчика GRUB2;
• раздел ext4 не монтируется, а в dmesg видны ошибки вида EXT4-fs error — восстановление файловой системы через fsck;
• NTFS-раздел помечен как грязный или недоступен — исправление через ntfsfix и chkdsk;
• пропали разделы или файлы после удаления и форматирования — поиск через testdisk и photorec.

Работайте в read-only режиме на первом этапе. Подключите внешний накопитель или сетевое хранилище для сохранения резервных копий и логов. Убедитесь, что питание стабильно. Любой сбой во время процедуры может привести к необратимой потере данных.

Содержание руководства:

1. Подготовка к восстановлению: минимизация рисков и выбор инструмента
2. Диагностика проблемы: определяем состояние дисков и файловых систем
3. Рецепт 1: Восстановление файловых систем ext4, ext2/3 и NTFS с помощью fsck
4. Рецепт 2: Восстановление загрузчика GRUB2 для UEFI и BIOS
5. Рецепт 3: Работа с повреждённой таблицей разделов (GPT/MBR)
6. Рецепт 4: Восстановление удалённых разделов и файлов с помощью testdisk и photorec
7. Сравнение инструментов для восстановления данных
8. Особые случаи и устранение неполадок
9. Часто задаваемые вопросы (FAQ)

Первый и обязательный шаг: создание посекторной резервной копии (dd/gddrescue)

Прямое копирование файлов с поврежденной файловой системы часто невозможно. Посекторное копирование всего диска или раздела создает точный образ, с которым можно безопасно экспериментировать. Утилита dd подходит для стабильных носителей. Для дисков с аппаратными ошибками используйте gddrescue (GNU ddrescue), который сохраняет прогресс и повторяет чтение проблемных секторов.

Команда для создания образа стабильного диска:

dd if=/dev/sdX of=/путь/к/внешнему/диску/backup.img bs=4M status=progress conv=noerror,sync

Замените /dev/sdX на идентификатор проблемного устройства (например, /dev/sda). Параметр bs=4M ускоряет операцию. Ключи conv=noerror,sync позволяют продолжить копирование при ошибках чтения, заполняя плохие секторы нулями.

Если диск издает щелчки, система зависает при обращении к нему, или SMART показывает много переназначенных секторов, запустите gddrescue:

gddrescue -v /dev/sdX /путь/к/образу.img /путь/к/логу.log

Программа сохранит карту восстановления в файл лога. После первого прохода можно выполнить повторные попытки для спасения оставшихся данных:

gddrescue -v -r 3 /dev/sdX /путь/к/образу.img /путь/к/логу.log

Дальнейшую диагностику и восстановление проводите с файлом образа, смонтировав его как loop-устройство. Это гарантирует, что исходный носитель не пострадает от ошибочных команд.

Выбор Live-дистрибутива: SystemRescue, Ubuntu Live или GParted Live?

Выбор дистрибутива влияет на доступный инструментарий и сложность настройки.

• SystemRescue - специализированный набор для аварийного восстановления. Включает утилиты: testdisk, photorec, fsck для всех популярных файловых систем, gdisk, ddrescue, редакторы hex, инструменты для работы с сетью. Идеален для сложных случаев, когда тип повреждения неизвестен. Базируется на Arch Linux, использует пакетный менеджер pacman.
• Ubuntu Live / Debian Live - знакомое окружение для администраторов. Позволяет использовать apt для установки дополнительных пакетов (testdisk, gddrescue, smartmontools). Подходит, если нужна стандартная среда и вы планируете использовать преимущественно родные утилиты Linux. Для восстановления Windows-разделов может потребовать установки ntfs-3g.
• GParted Live - узконаправленный дистрибутив для работы с разделами. Содержит графическую утилиту GParted и базовый набор консольных инструментов (fdisk, fsck). Оптимален, если проблема точно связана с таблицей разделов (GPT/MBR) и не требуется глубокий анализ файловых систем.

Рекомендация для большинства сценариев: используйте SystemRescue. Он покрывает 95% задач по восстановлению и диагностике. Запишите его на USB-накопитель с помощью dd или утилиты Ventoy, которая позволяет хранить несколько ISO-образов на одной флешке. Подробнее о создании универсального аварийного набора читайте в руководстве Загрузочная флешка с дисковыми утилитами: создание и актуальный набор инструментов на 2026 год.

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

После загрузки с LiveCD откройте терминал с правами root. Ваша цель - построить полную картину: какие диски видны, их размер, состояние разделов, типы файловых систем, наличие ошибок в ядре.

Как определить повреждение файловой системы ext4/NTFS

Логическое повреждение ext4/NTFS обычно выдаёт себя косвенно: раздел не монтируется, в dmesg появляются ошибки ввода-вывода, а blkid не определяет тип ФС. Краткий вывод: если диск определяется и читается, а ошибки касаются метаданных — это задача для fsck; если не читается сам носитель — сначала посекторное копирование через ddrescue. Дальше соберите факты по чек-листу ниже.

Чек-лист «5 команд за 2 минуты»

1. lsblk -f — увидеть диски, разделы, типы ФС и точки монтирования.
2. blkid — проверить UUID и типы файловых систем.
3. dmesg | tail -100 — найти ошибки ввода-вывода и сбои файловых систем.
4. smartctl -a /dev/sdX — оценить физическое состояние накопителя по SMART.
5. fsck -n /dev/sdX1 — просканировать файловую систему без внесения изменений.

Пяти команд достаточно, чтобы за пару минут понять характер проблемы: логическая ошибка ФС, деградация железа или повреждение таблицы разделов.

Базовые команды: lsblk, fdisk, blkid и dmesg | tail

1. lsblk показывает дерево блочных устройств, точки монтирования и файловые системы.

lsblk -f

Обратите внимание на столбцы FSTYPE (тип ФС) и MOUNTPOINTS. Отсутствие типа ФС или наличие метки unknown указывает на повреждение. Если раздел смонтирован, размонтируйте его перед проверкой: umount /dev/sdX1.

2. fdisk выводит таблицу разделов.

fdisk -l /dev/sdX

Проверьте, соответствуют ли размеры разделов ожидаемым. Для дисков GPT используйте gdisk -l /dev/sdX.

3. blkid отображает UUID и типы файловых систем, которые ядро может определить.

blkid

Сравните UUID с записями в /etc/fstab вашей системы (если доступно). Несоответствие может быть причиной ошибок загрузки.

4. dmesg содержит логи ядра. Ищите ошибки ввода-вывода (I/O errors), сообщения о сбоях файловых систем.

dmesg | tail -100

Фразы типа "EXT4-fs error (device sda1): ext4_find_entry: reading directory" прямо указывают на повреждение структуры ext4.

5. Проверка аппаратного состояния (SMART). Установите пакет smartmontools если его нет. Для SATA-диска:

smartctl -a /dev/sdX

Обратите внимание на атрибуты Reallocated_Sector_Ct, Current_Pending_Sector, Uncorrectable_Sector_Ct. Высокие значения сигнализируют о физической деградации носителя. В этом случае приоритет - посекторное копирование данных, а не восстановление ФС на этом же диске. Как выстроить постоянный контроль состояния накопителей, разобрано в руководстве Мониторинг здоровья дисков и массивов: SMART, ZED и алертинг в 2026 году.

Рецепт 1: Восстановление файловых систем ext4, ext2/3 и NTFS с помощью fsck

Утилита fsck (file system check) - основной инструмент исправления логических ошибок в файловых системах. Для ext2/3/4 она вызывает e2fsck, для NTFS - ntfsfix. Перед запуском убедитесь, что раздел не смонтирован.

Сначала выполните проверку без внесения изменений:

fsck -n /dev/sdX1

Утилита просканирует метаданные и выведет список проблем: неверные указатели inode, битые блоки, несоответствия счетчиков. Если ошибок немного, запустите исправление с ключом -y (автоматический ответ «yes» на все запросы):

fsck -y /dev/sdX1

Для принудительной проверки, даже если файловая система помечена как чистая, используйте -f. Для подробного вывода добавьте -v.

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

Если fsck зависает на определенном проценте, это может указывать на серьезное повреждение метаданных или физический bad block. Прервите процесс (Ctrl+C), создайте посекторный образ проблемного раздела с помощью ddrescue и попробуйте запустить fsck уже на образе. Или переходите к восстановлению через запасные суперблоки.

Если fsck сообщает о необходимости ручного вмешательства (например, «UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY»), не спешите соглашаться на автоматическое исправление. Сначала создайте бэкап текущего состояния. Иногда ручное вмешательство через debugfs безопаснее. Основные команды: debugfs /dev/sdX1, затем в интерактивном режиме stat <inode_number> для проверки конкретного inode, testb <block_number> для проверки блока.

Использование запасных суперблоков для критических повреждений ext*

Суперблок - это заголовок файловой системы ext*, хранящий критическую информацию: размер блока, количество inode, список свободных блоков. В начале раздела создаются его резервные копии. Если основной суперблок поврежден, система не смонтирует раздел.

Сначала найдите расположение запасных суперблоков. Команда mke2fs -n покажет их, не записывая ничего на диск.

mke2fs -n /dev/sdX1

Вывод будет содержать строку типа: Superblock backups stored on blocks: 32768, 98304, 163840, 229376....

Укажите один из этих номеров блока в fsck с ключом -b:

fsck -b 32768 /dev/sdX1

Если первый запасной суперблок также поврежден, попробуйте следующий из списка. После успешного восстановления суперблока выполните полную проверку fsck -y /dev/sdX1.

Как проверить результат восстановления суперблока:

После команды fsck -b попробуйте смонтировать раздел в режиме чтения: mount -o ro /dev/sdX1 /mnt/test. Если монтирование прошло успешно и вы видите структуру каталогов, суперблок восстановлен. Запустите полную проверку для исправления остальных ошибок.

Что делать, если не помогло: Если ни один из запасных суперблоков не работает, возможно, повреждена не только эта структура. Переходите к использованию testdisk для поиска и восстановления потерянного раздела или к посекторному копированию данных с последующим использованием photorec.

Более детальные методы ручного восстановления структур ext4, XFS и Btrfs, включая работу с журналами транзакций, описаны в отдельном руководстве: Диагностика и восстановление файловых систем Linux: ext4, XFS и Btrfs.

Для файловых систем NTFS в Linux используется утилита ntfsfix. Она исправляет распространенные ошибки и сбрасывает флаги, которые Windows устанавливает при некорректном завершении работы.

ntfsfix /dev/sdX1

Эта команда не выполняет глубокую проверку целостности данных. Для этого потребуется загрузка с Windows PE и запуск chkdsk /f. Полный цикл ремонта NTFS-разделов средствами Windows (chkdsk, sfc, DISM) разобран в руководстве Ремонт файловой системы Windows: полное руководство по chkdsk, sfc и DISM для NTFS и ReFS (2026).

Рецепт 2: Восстановление загрузчика GRUB2 для UEFI и BIOS

Симптомы сбоя загрузчика: сообщения «GRUB rescue», «Boot device not found», «Invalid EFI file path». Алгоритм восстановления различается для старых систем с BIOS (MBR) и современных с UEFI.

Общие подготовительные шаги:

1. Загрузитесь с LiveCD и откройте терминал.
2. Определите корневой раздел вашей системы (/) с помощью lsblk -f и смонтируйте его. Например, если это /dev/sda2:

mount /dev/sda2 /mnt

3. Если у вас отдельный раздел /boot или /boot/efi (для UEFI), смонтируйте их в соответствующие подкаталоги:

# Для /boot
mount /dev/sda1 /mnt/boot
# Для EFI-раздела (обычно FAT32)
mount /dev/sda1 /mnt/boot/efi

Подготовка окружения chroot: монтирование /proc, /sys, /dev

Для корректной работы установщика GRUB внутри восстановленной системы необходимо примонтировать виртуальные файловые системы ядра и устройства. Без этого команда grub-install может завершиться ошибкой.

mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts

Теперь перейдите в окружение chroot:

chroot /mnt

Для систем с UEFI: Убедитесь, что пакет grub-efi-amd64 (или grub-efi-amd64-signed для Secure Boot) установлен. Установите загрузчик:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB

Обновите конфигурацию GRUB:

update-grub

Для систем с BIOS (MBR): Установите загрузчик в MBR диска:

grub-install --target=i386-pc /dev/sda

Здесь /dev/sda - это диск (устройство), а не раздел. После этого также выполните update-grub.

Частые ошибки при восстановлении GRUB и их решение

Ошибка «grub-install: error: cannot find EFI directory». Убедитесь, что EFI-раздел смонтирован именно в /boot/efi внутри chroot. Проверьте его тип командой blkid; он должен быть FAT32. Если раздел не найден, возможно, повреждена таблица разделов или сигнатура EFI. Восстановите ее с помощью gdisk как описано ниже.

Ошибка «grub-install: warning: File system ‘ext2’ doesn't support embedding». Это не ошибка, а предупреждение для систем BIOS. Если установка завершилась, загрузчик должен работать. Проверьте с помощью grub-install --target=i386-pc --recheck /dev/sda.

Выйдите из chroot (exit), перезагрузитесь и извлеките Live-носитель.

Рецепт 3: Работа с поврежденной таблицей разделов (GPT/MBR)

Если диск определяется, но разделы не отображаются в lsblk или отображаются как «unknown», вероятно, повреждена таблица разделов. GPT хранит резервную копию в конце диска, что повышает шансы на восстановление.

Восстановление GPT с помощью gdisk:

gdisk /dev/sdX

В интерактивном режиме gdisk:

1. Введите r для перехода в меню восстановления.
2. Введите v для проверки целостности таблицы. Программа укажет на проблемы.
3. Введите b для создания резервной копии текущей (поврежденной) таблицы в файл.
4. Введите c для восстановления основной таблицы разделов из резервной копии в конце диска.
5. Используйте w для записи изменений на диск.

Если gdisk не видит разделов или зависает:

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

Общий обзор консольных и графических утилит для работы с разделами приведён в руководстве Управление дисками в Linux: fdisk, parted, gdisk, GNOME Disks, KDE Partition Manager.

Рецепт 4: Восстановление удаленных разделов и файлов с помощью testdisk и photorec

Когда раздел был удален или диск отформатирован, данные часто остаются на диске, но теряется ссылка на них в таблице разделов. Утилиты testdisk (для восстановления структуры) и photorec (для восстановления файлов по сигнатурам) решают эту задачу.

Пошаговое восстановление раздела с помощью testdisk

testdisk /dev/sdX

1. В появившемся меню выберите [Create] для создания лога (рекомендуется).
2. Выберите диск, с которым работаете.
3. Выберите тип таблицы разделов: [Intel] для MBR или [EFI GPT] для GPT.
4. Выберите [Analyse] для анализа текущей структуры и поиска удаленных разделов.
5. Выберите [Quick Search]. Testdisk просканирует диск и отобразит найденные разделы, включая удаленные (помечены как P или D).
6. С помощью клавиш ↑/↓ выберите потерянный раздел. Нажмите p для просмотра файлов внутри. Это проверка, что раздел найден верно.
7. Если файлы отображаются корректно, нажмите Enter, вернитесь в меню и выберите [Write] для записи структуры раздела на диск.

ВАЖНО: Перед записью обязательно создайте резервную копию текущего состояния диска через опцию [Backup] в главном меню testdisk. После восстановления раздела смонтируйте его и проверьте доступность данных.

Восстановление файлов после случайного форматирования или повреждения ФС

Если восстановить структуру раздела не удается (например, после полного форматирования), используйте photorec. Она игнорирует файловую систему и ищет файлы по заголовкам (сигнатурам).

photorec /dev/sdX

1. Выберите диск, затем раздел (или [Whole disk]).
2. Выберите тип файловой системы, которая была на диске ([ext2/ext3], [Other] и т.д.). Для широкого поиска можно оставить [Whole].
3. Укажите файловую систему назначения (куда сохранять восстановленные файлы) – это ДОЛЖЕН быть другой физический диск или раздел.
4. Нажмите [Search]. Photorec начнет сканирование и будет сохранять найденные файлы в указанное место, восстанавливая имена, где это возможно.

Как проверить результат: После завершения работы photorec проверьте папку назначения. Файлы будут сгруппированы по расширениям (например, в папках recup_dir.1, recup_dir.2). Для изображений и документов предпросмотр поможет оценить успешность.

Что делать, если восстановленные файлы есть, но не открываются: Это может означать их частичное повреждение. Попробуйте восстановить их снова, но на этот раз с посекторного образа диска, созданного ddrescue. Используйте ключ -d в photorec для игнорирования разбиения на разделы.

Подробный алгоритм действий в таких сценариях описан в руководстве Восстановление данных с жесткого диска: пошаговый алгоритм для IT-специалистов.

Сравнение инструментов для восстановления данных

Особые случаи и устранение неполадок

RAID, LVM и шифрованные разделы

Если система использует программный RAID, LVM или LUKS, проверять ФС напрямую по /dev/sdX1 нельзя — сначала соберите верхний уровень хранилища:

# Программный RAID
mdadm --assemble --scan
# LVM
vgchange -ay
# LUKS
cryptsetup luksOpen /dev/sdX1 cryptroot

Только после этого fsck запускается по устройству верхнего уровня — /dev/md0 или /dev/mapper/cryptroot. Сборка программных массивов и типовые ошибки разобраны в руководстве Программные RAID-массивы на Linux в 2026: практическое руководство по mdadm, ZFS и LVM.

Диск не определяется вообще

Если lsblk не показывает накопитель, проблема лежит ниже уровня файловой системы. Проверьте dmesg на ошибки контроллера и линка (ata, I/O error), смените SATA-порт и кабель, попробуйте подключить диск через USB-адаптер. Дальше оцените физическое состояние по SMART и при деградации сразу переходите к ddrescue.

Когда стоит остановиться

Если диск издаёт щелчки, SMART показывает стремительный рост переназначенных секторов, а ddrescue почти не продвигается, дальнейшие попытки чтения могут ухудшить состояние носителя. В такой ситуации корректно остановиться и передать диск специалистам по восстановлению. Практика работы с деградирующими HDD/SSD описана в материале Восстановление данных с повреждённых HDD и SSD: практическое руководство для админов.

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

Запустится ли fsck на смонтированном разделе?

Нет. Для ext2/3/4 утилита e2fsck откажется работать с примонтированной файловой системой, чтобы не повредить данные. Сначала размонтируйте раздел: umount /dev/sdX1. Корневой раздел проверяется только с LiveCD.

Чем testdisk отличается от photorec?

testdisk восстанавливает структуру разделов и таблицу GPT/MBR, сохраняя имена файлов и каталоги. photorec работает без файловой системы, ищет файлы по сигнатурам, но теряет имена и структуру каталогов. Сначала пробуйте testdisk.

Достаточно ли ntfsfix вместо chkdsk?

ntfsfix сбрасывает флаги «грязного» раздела и исправляет типовые ошибки, но не выполняет полную проверку целостности. Для глубокого ремонта NTFS нужен chkdsk /f с Windows PE.

Опасен ли fsck -y для данных?

Ключ -y автоматически подтверждает все исправления. На сильно повреждённой ФС это может удалить часть метаданных. Перед запуском снимите посекторный образ через ddrescue и проводите эксперименты с копией.

Что делать, если после восстановления GRUB система всё равно не грузится?

Проверьте, что UUID корневого раздела в grub.cfg совпадает с выводом blkid, а EFI-раздел смонтирован в /boot/efi. Для UEFI убедитесь, что запись загрузчика активна: efibootmgr.