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

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

18 мая 2026 15 мин. чтения
Содержание статьи

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

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

Кому и когда пригодится. Руководство рассчитано на 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. Ваша цель - построить полную картину: какие диски видны, их размер, состояние разделов, типы файловых систем, наличие ошибок в ядре.

Чек-лист «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-специалистов.

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

Инструмент Для чего Плюсы Минусы Когда использовать
fsck (e2fsck, ntfsfix) Исправление логических ошибок в существующей файловой системе. Стандартная утилита, быстро исправляет типовые ошибки. Бесполезна при физических повреждениях или удаленных разделах. Риск повреждения данных при агрессивном использовании. Система не монтируется, но раздел виден. Есть ошибки в журнале ядра.
testdisk Восстановление удаленных разделов, перезаписанных MBR/GPT. Мощное сканирование сигнатур, может вернуть структуру раздела с данными. Интерфейс псевдографический, требует понимания структуры диска. Разделы пропали после случайного удаления, форматирования, перезаписи MBR.
photorec Восстановление файлов по сигнатурам без файловой системы. Спасает данные даже при полностью уничтоженной ФС. Много поддерживаемых форматов. Не восстанавливает имена файлов и структуру каталогов. Требует много места для результатов. Крайний случай: ФС разрушена, testdisk не помог, нужны файлы любого качества.
ddrescue (gddrescue) Посекторное копирование поврежденных носителей. Спасает данные с битых дисков, сохраняет логи, возобновляемо. Работает на низком уровне, не понимает файловых систем. Диск щелкает, зависает, много bad blocks. Первый шаг перед любым восстановлением ФС.

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

1. Диски с шифрованием LUKS. Сначала разблокируйте контейнер, чтобы получить доступ к файловой системы внутри.

cryptsetup luksOpen /dev/sdX1 my_volume

После ввода пароля появится блочное устройство /dev/mapper/my_volume. Проводите диагностику и восстановление ФС уже с ним: fsck /dev/mapper/my_volume.

2. Аппаратные RAID-массивы. Загрузите необходимые модули ядра для вашего контроллера RAID (например, mdadm для программного RAID, megaraid_sas для LSI). Соберите массив вручную:

mdadm --assemble --scan

После этого диски массива станут доступны как виртуальное устройство (например, /dev/md0).

3. Системы с включенным Secure Boot. Многие Live-дистрибутивы (включая SystemRescue) имеют подписанные загрузчики. Если загрузка не происходит, отключите Secure Boot в настройках UEFI вашего компьютера или сервера.

4. Файловые системы Btrfs и ZFS. Используйте их родные утилиты. Для Btrfs:

btrfs check --repair /dev/sdX1

Ключ --repair используйте с крайней осторожностью и только после создания бэкапа. Для импорта пула ZFS:

zpool import -f pool_name

Затем проверьте целостность: zpool scrub pool_name.

5. Физически поврежденные HDD/SSD. Если диагностика SMART указывает на критический износ, а утилиты чтения зависают, приоритет - спасение данных, а не восстановление ФС. Используйте gddrescue для создания образа, как описано в первом разделе. Для сложных случаев с аппаратными дефектами изучите расширенное руководство: Восстановление данных с поврежденных HDD и SSD: практическое руководство для админов.

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

Q: Что делать, если после запуска fsck пропали файлы?
A: fsck не удаляет данные намеренно, но может отбросить повреждённые inode или переместить «осиротевшие» объекты в каталог /lost+found. Сначала проверьте /lost+found — часть файлов часто лежит именно там. Если нужных данных нет, немедленно размонтируйте раздел и работайте только с посекторным образом (gddrescue), чтобы не перезаписать оставшиеся блоки. Дальнейший поиск выполняйте через photorec по сигнатурам файлов.

Q: Можно ли восстановить ext4 без LiveCD?
A: Если корневой раздел занят работающей системой, полноценная проверка невозможна: fsck -y на смонтированном в режиме записи разделе опасен. Ограничьтесь диагностикой fsck -n, а для реального восстановления (суперблоки, битые inode, структура каталогов) загрузитесь с LiveCD или работайте с образом, смонтированным как loop-устройство.

Q: Чем gdisk отличается от testdisk?
A: gdisk работает на уровне GPT: проверяет целостность таблицы и восстанавливает её из резервной копии в конце диска. testdisk ищет потерянные разделы, сканируя сигнатуры файловых систем, и поддерживает как GPT, так и MBR. Если повреждена только служебная структура GPT — быстрее gdisk; если разделы удалены или перезаписаны — нужен testdisk.

Q: Обязательно ли делать посекторный образ перед восстановлением?
A: Да, если данные ценны или диск показывает ошибки чтения. Образ (dd или gddrescue) фиксирует текущее состояние и позволяет повторять эксперименты без риска для оригинала. На «живом» носителе каждая команда может ухудшить ситуацию.

Q: Что делать, если NTFS не монтируется в Linux?
A: Убедитесь, что раздел не смонтирован и не занят Windows (гибернация, Fast Startup). Затем запустите ntfsfix /dev/sdX1, чтобы сбросить флаги. Помните, что ntfsfix не заменяет полную проверку — глубокий ремонт структуры NTFS выполняет chkdsk /f в Windows или Windows PE.

Поделиться:
Сохранить гайд? В закладки браузера