Алгоритмы восстановления файловой системы ext4

[!INFO] Применимость
ALT Linux 10.4–11.x · ext4 · локальная работа через CLI/TTY · доступ root

Заметка содержит отдельные самодостаточные алгоритмы для ext4 на:

• HDD;
• SSD и NVMe;
• Linux Software RAID;
• LVM;
• Multipath и SAN LUN;
• NFS;
• SMB/DFS.

Все операции восстановления выполняются только после определения нижележащего уровня хранения.

Оглавление

• [[#Основные запреты|Основные запреты]]
• [[#Коды завершения e2fsck|Коды завершения e2fsck]]
• [[#Когда ext4 ремонтировать нельзя|Когда ext4 ремонтировать нельзя]]
• [[#Алгоритм 1. ext4 на исправном HDD|Алгоритм 1. ext4 на исправном HDD]]
• [[#Алгоритм 2. ext4 на HDD с ошибками чтения или SMART|Алгоритм 2. ext4 на HDD с ошибками чтения или SMART]]
• [[#Алгоритм 3. ext4 на исправном SSD или NVMe|Алгоритм 3. ext4 на исправном SSD или NVMe]]
• [[#Алгоритм 4. ext4 на отказывающем SSD или NVMe|Алгоритм 4. ext4 на отказывающем SSD или NVMe]]
• [[#Алгоритм 5. ext4 на Linux Software RAID|Алгоритм 5. ext4 на Linux Software RAID]]
• [[#Алгоритм 6. ext4 на LVM|Алгоритм 6. ext4 на LVM]]
• [[#Алгоритм 7. ext4 на Multipath или SAN LUN|Алгоритм 7. ext4 на Multipath или SAN LUN]]
• [[#Алгоритм 8. каталог подключён по NFS|Алгоритм 8. каталог подключён по NFS]]
• [[#Алгоритм 9. каталог подключён по SMB или DFS|Алгоритм 9. каталог подключён по SMB или DFS]]
• [[#Алгоритм 10. повреждён основной суперблок ext4|Алгоритм 10. повреждён основной суперблок ext4]]
• [[#Алгоритм 11. e2fsck не может завершить восстановление|Алгоритм 11. e2fsck не может завершить восстановление]]
• [[#Проверка после ремонта|Проверка после ремонта]]
• [[#Источники|Источники]]

Основные запреты

Не запускать e2fsck на смонтированной файловой системе

Проверить:

findmnt --source <устройство_ext4>

Если команда показывает точку монтирования, файловую систему нужно отключить:

sudo umount <точка_монтирования>

Если это корневая файловая система /, загрузиться с установочного носителя ALT Linux 10.4 в режиме:

Восстановление системы

или:

Rescue LiveCD

После загрузки Rescue LiveCD убедиться, что раздел не смонтирован:

findmnt --source <устройство_ext4>

Не использовать устройство нижнего уровня вместо ext4

Нельзя запускать e2fsck на:

• целом диске, если ext4 находится в разделе;
• компоненте RAID;
• физическом томе LVM;
• отдельном SCSI-пути Multipath;
• NFS или DFS-каталоге.

Правильная цель определяется командой:

lsblk -e 7 -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS

Запускать e2fsck нужно только на устройстве, у которого:

FSTYPE=ext4

Не использовать автоматическое согласие на все исправления

Не применять без отдельного решения:

e2fsck -y

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

Не запускать badblocks на отказывающем носителе

Не выполнять:

badblocks
e2fsck -c
e2fsck -cc

если обнаружены:

• ошибки I/O;
• ожидающие или неисправимые сектора;
• исчезновение устройства;
• сбросы контроллера;
• ошибки NVMe media/data integrity;
• нестабильный RAID или Multipath.

Полное чтение поверхности создаёт дополнительную нагрузку и может добить носитель раньше копирования данных.

Коды завершения e2fsck

После выполнения:

echo $?

Когда ext4 ремонтировать нельзя

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

I/O error
Buffer I/O error
critical medium error
Current_Pending_Sector > 0
Offline_Uncorrectable > 0
SMART FAILED
NVMe critical_warning != 0
media_errors > 0
устройство исчезает из системы
повторяются reset или timeout
RAID dirty и degraded
в RAID отсутствует больше устройств, чем допускает уровень
Multipath потерял все пути
LVM отмечен partial

В этих ситуациях сначала:

1. прекратить запись;
2. отключить файловую систему;
3. скопировать доступные файлы либо создать посекторный образ;
4. выполнять e2fsck только на копии или исправном клоне.

Алгоритм 1. ext4 на исправном HDD

Применять, если ext4 расположена на локальном HDD и отсутствуют признаки физического отказа.

1. Определить диск, раздел и точку монтирования

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

Пример правильной цели:

/dev/sda2  part  ext4

Запомнить:

Диск:    /dev/sda
Раздел:  /dev/sda2

2. Проверить журнал ядра

journalctl -k -b --no-pager | grep -Ei \
'sda|I/O error|Buffer I/O|critical medium|reset|timeout|EXT4-fs|JBD2'

Ремонт разрешён, если нет повторяющихся:

I/O error
critical medium error
uncorrectable
reset
timeout

3. Проверить SMART

sudo smartctl -x /dev/sda

Ремонт разрешён, если:

• SMART не сообщает FAILED;
• Current_Pending_Sector равен 0;
• Offline_Uncorrectable равен 0;
• ошибки чтения не растут;
• диск не исчезает из системы.

Если smartctl отсутствует, не считать диск автоматически исправным. Оценить хотя бы журнал ядра и поведение устройства.

4. Отключить файловую систему

Остановить службы, использующие точку монтирования:

sudo fuser -vm <точка_монтирования>

Отключить:

sudo umount <точка_монтирования>

Проверить:

findmnt --source /dev/sda2

Если /dev/sda2 является корневой ФС, загрузиться в Rescue LiveCD и повторно убедиться, что раздел не смонтирован.

5. Сохранить метаданные ext4

Сохранять файл на другой исправный носитель:

sudo e2image /dev/sda2 /mnt/healthy/ext4-sda2-before.e2i

Это не копия пользовательских данных. Файл содержит критические метаданные ext4 для последующего анализа.

6. Выполнить проверку без изменений

sudo e2fsck -fn /dev/sda2

Если проверка показывает I/O-ошибки, прекратить ремонт и перейти к копированию носителя.

7. Выполнить безопасные автоматические исправления

sudo e2fsck -f -p /dev/sda2

Проверить код:

echo $?

Если код 0, 1 или 2, перейти к повторной проверке.

Если код 4, выполнить интерактивный ремонт:

sudo e2fsck -f /dev/sda2

Подтверждать только исправления структур ext4. Если появляются ошибки чтения или устройство зависает, прекратить проверку.

8. Повторить проверку без изменений

sudo e2fsck -fn /dev/sda2

Ожидается завершение с кодом:

0

9. Проверить содержимое в режиме чтения

sudo mount -o ro /dev/sda2 <временная_точка>

Проверить:

• открываются ли основные каталоги;
• присутствуют ли важные файлы;
• появился ли каталог lost+found;
• нет ли новых ошибок ядра.

journalctl -k -b -n 100 --no-pager

После проверки:

sudo umount <временная_точка>

Только после этого вернуть обычное монтирование.

Алгоритм 2. ext4 на HDD с ошибками чтения или SMART

Применять при:

• I/O error;
• critical medium error;
• Current_Pending_Sector > 0;
• Offline_Uncorrectable > 0;
• SMART FAILED;
• повторяющихся зависаниях или исчезновении HDD.

1. Определить исходный диск

lsblk -d -o NAME,PATH,SIZE,MODEL,SERIAL

Пример:

Исходный диск: /dev/sda

2. Прекратить запись

Если файловая система смонтирована:

sudo umount <точка_монтирования>

Если отключение невозможно из-за корневой ФС, выключить систему штатно и загрузиться в Rescue LiveCD.

Не запускать:

e2fsck
badblocks
длительный SMART self-test

на исходном HDD.

3. Зафиксировать SMART и журнал

sudo smartctl -x /dev/sda > /mnt/healthy/smart-sda.txt

journalctl -k -b --no-pager > /mnt/healthy/kernel-storage.txt

Если диск постоянно отключается, щёлкает или не определяется, прекратить самостоятельные попытки и передать его на аппаратное восстановление.

4. Подготовить исправный носитель

Нужна файловая система с объёмом свободного места не меньше полного размера исходного диска:

df -hT /mnt/recovery

GNU ddrescue является отдельным пакетом. Проверить наличие:

command -v ddrescue

5. Снять образ без повторных попыток чтения

sudo ddrescue -n \
  /dev/sda \
  /mnt/recovery/sda.img \
  /mnt/recovery/sda.map

Файл карты обязателен. Он позволяет продолжить копирование без повторного чтения уже сохранённых областей.

6. Решить, допустим ли второй проход

Если диск остаётся стабильным:

sudo ddrescue -d -r3 \
  /dev/sda \
  /mnt/recovery/sda.img \
  /mnt/recovery/sda.map

Если после первого прохода диск:

• исчезает;
• перегревается;
• резко замедляется;
• издаёт механические звуки;
• создаёт новые ошибки;

второй проход не запускать.

7. Подключить образ

sudo losetup -Pf --show /mnt/recovery/sda.img

Команда вернёт устройство, например:

/dev/loop0

Показать разделы:

lsblk -f /dev/loop0

Пример ext4-раздела:

/dev/loop0p2

8. Ремонтировать только копию

Проверка без изменений:

sudo e2fsck -fn /dev/loop0p2

Ремонт:

sudo e2fsck -f /dev/loop0p2

Повторная проверка:

sudo e2fsck -fn /dev/loop0p2

9. Скопировать данные с восстановленного образа

sudo mount -o ro /dev/loop0p2 <временная_точка>

Копировать данные на третий исправный носитель. Не считать образ единственной резервной копией.

Исходный HDD после появления физических ошибок не возвращать в эксплуатацию.

Алгоритм 3. ext4 на исправном SSD или NVMe

Применять, если носитель стабилен и не сообщает критических ошибок.

1. Определить устройство

SATA SSD:

lsblk -d -o NAME,PATH,SIZE,ROTA,TRAN,MODEL,SERIAL

NVMe:

lsblk -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

Примеры:

SATA SSD:  /dev/sda
Раздел:    /dev/sda2

NVMe:      /dev/nvme0n1
Раздел:    /dev/nvme0n1p2

2. Проверить состояние носителя

SATA SSD:

sudo smartctl -x /dev/sda

NVMe:

sudo smartctl -x /dev/nvme0

При наличии nvme-cli:

sudo nvme smart-log /dev/nvme0

Ремонт разрешён, если:

• critical_warning равен 0;
• media_errors равен 0;
• SMART не сообщает FAILED;
• устройство не сбрасывается;
• журнал ядра не содержит повторяющихся I/O timeout.

3. Проверить журнал ядра

journalctl -k -b --no-pager | grep -Ei \
'I/O error|Buffer I/O|nvme|reset|timeout|EXT4-fs|JBD2'

При повторяющихся reset, timeout или media errors прекратить этот алгоритм и перейти к копированию носителя.

4. Отключить ext4

sudo umount <точка_монтирования>

Проверить:

findmnt --source <устройство_ext4>

Для корневой ФС загрузиться в Rescue LiveCD.

5. Сохранить метаданные

sudo e2image <устройство_ext4> /mnt/healthy/ext4-before.e2i

6. Проверить без изменений

sudo e2fsck -fn <устройство_ext4>

7. Выполнить ремонт

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

sudo e2fsck -f -p <устройство_ext4>

Если код завершения 4:

sudo e2fsck -f <устройство_ext4>

Не использовать:

badblocks
e2fsck -c
e2fsck -cc

для обычной диагностики SSD и NVMe.

8. Проверить результат

sudo e2fsck -fn <устройство_ext4>

Затем:

sudo mount -o ro <устройство_ext4> <временная_точка>

Проверить данные и журнал ядра. При повторном появлении ошибок вывести накопитель из эксплуатации и скопировать данные.

Алгоритм 4. ext4 на отказывающем SSD или NVMe

Применять при:

• SMART FAILED;
• NVMe critical_warning != 0;
• media_errors > 0;
• повторяющихся I/O timeout;
• переходе SSD в аппаратный read-only;
• исчезновении контроллера;
• росте ошибок целостности данных.

1. Определить устройство данных

SATA SSD:

/dev/sda

NVMe namespace:

/dev/nvme0n1

Для копирования используется namespace /dev/nvme0n1, а не контроллер /dev/nvme0.

2. Прекратить запись

sudo umount <точка_монтирования>

Для корневой ФС загрузиться в Rescue LiveCD.

Не запускать на исходном носителе:

e2fsck
badblocks
длительный SMART self-test
nvme device-self-test
fstrim

3. Зафиксировать состояние

SATA SSD:

sudo smartctl -x /dev/sda > /mnt/healthy/smart-ssd.txt

NVMe:

sudo smartctl -x /dev/nvme0 > /mnt/healthy/smart-nvme.txt

journalctl -k -b --no-pager > /mnt/healthy/kernel-storage.txt

4. Снять образ

SATA SSD:

sudo ddrescue -n \
  /dev/sda \
  /mnt/recovery/ssd.img \
  /mnt/recovery/ssd.map

NVMe:

sudo ddrescue -n \
  /dev/nvme0n1 \
  /mnt/recovery/nvme.img \
  /mnt/recovery/nvme.map

Повторный проход выполнять только при стабильном устройстве:

sudo ddrescue -d -r3 \
  <исходное_устройство> \
  <файл_образа> \
  <файл_карты>

5. Работать с образом

sudo losetup -Pf --show <файл_образа>

Определить ext4:

lsblk -f /dev/loop0

Проверить и ремонтировать только loop-раздел:

sudo e2fsck -fn /dev/loop0p2
sudo e2fsck -f /dev/loop0p2
sudo e2fsck -fn /dev/loop0p2

6. Завершение

Скопировать данные с образа на исправный носитель. Отказывающий SSD или NVMe не возвращать в рабочую эксплуатацию, даже если ext4 после ремонта монтируется.

Алгоритм 5. ext4 на Linux Software RAID

Применять для массивов /dev/md*.

1. Определить структуру

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS

cat /proc/mdstat

sudo mdadm --detail /dev/md0

Убедиться, что ext4 находится:

• непосредственно на /dev/md0; либо
• на LVM-томе поверх /dev/md0.

Никогда не запускать e2fsck на отдельных компонентах:

/dev/sda1
/dev/sdb1

если они являются членами массива.

2. Определить допустимость ремонта

Ремонт допускается, если:

• массив активен;
• все обязательные участники присутствуют;
• состояние массива не dirty degraded;
• нет повторяющихся I/O-ошибок участников;
• не выполняется проблемный rebuild;
• устройство ext4 стабильно читается.

Для RAID1/10 нормальное обозначение всех участников:

[UU]

Для массива с отсутствующим устройством:

[U_]

3. Если RAID деградирован

Если RAID1 или RAID10 деградирован, но читается:

1. прекратить запись;
2. скопировать важные данные;
3. заменить неисправный участник;
4. дождаться завершения recovery/resync;
5. только после стабилизации массива проверять ext4.

Если RAID5/6 одновременно dirty и degraded:

• не запускать e2fsck;
• не собирать массив с --force;
• не считать паритет достоверным;
• сначала восстановить массив или снять образ доступного логического устройства.

4. Отключить ext4

Если ext4 находится прямо на RAID:

sudo umount <точка_монтирования>

Цель ремонта:

/dev/md0

Если ext4 находится на LVM поверх RAID, цель ремонта будет логическим томом:

/dev/mapper/<VG>-<LV>

Проверить отсутствие монтирования:

findmnt --source <устройство_ext4>

5. Сохранить сведения и метаданные

cat /proc/mdstat > /mnt/healthy/mdstat-before.txt

sudo mdadm --detail /dev/md0 > /mnt/healthy/md0-before.txt

sudo e2image <устройство_ext4> /mnt/healthy/ext4-raid-before.e2i

6. Проверить и исправить ext4

sudo e2fsck -fn <устройство_ext4>

sudo e2fsck -f -p <устройство_ext4>

Если код 4:

sudo e2fsck -f <устройство_ext4>

7. Проверить результат

sudo e2fsck -fn <устройство_ext4>

cat /proc/mdstat

sudo mdadm --detail /dev/md0

После ремонта массив должен оставаться активным и не получать новых I/O-ошибок.

Алгоритм 6. ext4 на LVM

Применять, если lsblk показывает тип:

lvm

1. Определить уровни хранения

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS

sudo pvs
sudo vgs
sudo lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent,devices

Определить:

PV — физический том
VG — группа томов
LV — логический том с ext4

Пример цели:

/dev/mapper/vg_data-lv_home

Нельзя запускать e2fsck на PV:

/dev/sda2

если ext4 находится на LV.

2. Проверить целостность нижнего уровня

Проверить журнал:

journalctl -k -b --no-pager | grep -Ei \
'I/O error|Buffer I/O|device-mapper|dm-[0-9]+|timeout|reset'

Проверить, что:

• все PV присутствуют;
• VG не является partial;
• LV не является partial;
• нижний HDD, SSD, RAID или Multipath стабилен;
• thin pool не заполнен полностью.

Критично:

Data% = 100
Meta% = 100

Ремонт ext4 не исправляет переполненный thin pool.

3. Если LVM partial или отсутствует PV

Не выполнять:

e2fsck
vgchange --partial
lvchange --partial

для попытки ремонта ext4.

Сначала:

1. восстановить отсутствующий PV или нижележащий путь;
2. либо скопировать доступные данные с текущего LV;
3. только после полного и стабильного отображения LV запускать проверку ext4.

4. Активировать полный VG

Если VG не активна:

sudo vgchange -ay <VG>

Проверить:

sudo lvs -a -o lv_name,vg_name,lv_attr,devices

5. Сохранить конфигурацию LVM

На другой исправный носитель:

sudo vgcfgbackup -f /mnt/healthy/<VG>-before.conf <VG>

Сохранить метаданные ext4:

sudo e2image /dev/mapper/<VG>-<LV> \
  /mnt/healthy/ext4-lvm-before.e2i

6. Отключить LV

sudo umount <точка_монтирования>

Проверить:

findmnt --source /dev/mapper/<VG>-<LV>

Для корневого LV загрузиться в Rescue LiveCD, активировать VG и убедиться, что LV не смонтирован.

7. Проверить и исправить ext4

sudo e2fsck -fn /dev/mapper/<VG>-<LV>

sudo e2fsck -f -p /dev/mapper/<VG>-<LV>

Если код 4:

sudo e2fsck -f /dev/mapper/<VG>-<LV>

8. Проверить результат

sudo e2fsck -fn /dev/mapper/<VG>-<LV>

sudo mount -o ro /dev/mapper/<VG>-<LV> <временная_точка>

Если ошибки ext4 появляются повторно, проверить физические PV и Device Mapper. Повторный e2fsck без устранения нижнего уровня не выполнять.

Алгоритм 7. ext4 на Multipath или SAN LUN

Применять, если одно блочное устройство доступно по нескольким SAN-путям.

1. Определить карту Multipath

sudo multipath -ll

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Правильная цель может выглядеть так:

/dev/mapper/mpatha
/dev/mapper/<WWID>

Если поверх Multipath используется LVM, правильной целью ext4 будет:

/dev/mapper/<VG>-<LV>

Нельзя запускать e2fsck на отдельных путях:

/dev/sda
/dev/sdb
/dev/sdc

Все они могут представлять один и тот же LUN.

2. Проверить службу и пути

systemctl is-active multipathd

sudo multipath -ll

Допустимые рабочие состояния обычно содержат:

active
ready
running

Неисправные состояния:

failed
faulty
offline
all paths down
no usable paths

3. Проверить исключительное владение LUN

Перед отключением и e2fsck необходимо убедиться, что тот же LUN не смонтирован в rw на другом сервере.

Если ext4 использует MMP (Multiple Mount Protection):

sudo e2mmpstatus <устройство_ext4>

MMP не заменяет проверку на стороне кластера и СХД.

4. Определить допустимость ремонта

Ремонт разрешён, если:

• карта Multipath присутствует;
• рабочие пути стабильны;
• нет повторяющихся SCSI timeout;
• LUN не используется другим хостом;
• ext4 отключена;
• нижележащая СХД не сообщает об аварии.

Если потерян один путь, но другие работают, сначала устранить путь или получить подтверждение допустимости работы.

Если потеряны все пути, e2fsck не запускать.

5. Отключить ext4

sudo umount <точка_монтирования>

Проверить:

findmnt --source <устройство_ext4>

Остановить приложение или кластерный ресурс, который может автоматически подключить ФС обратно.

6. Сохранить состояние

sudo multipath -ll > /mnt/healthy/multipath-before.txt

Если используется LVM:

sudo pvs > /mnt/healthy/pvs-before.txt
sudo vgs > /mnt/healthy/vgs-before.txt
sudo lvs -a -o +devices > /mnt/healthy/lvs-before.txt

Метаданные ext4:

sudo e2image <устройство_ext4> /mnt/healthy/ext4-san-before.e2i

7. Проверить и исправить ext4

sudo e2fsck -fn <устройство_ext4>

sudo e2fsck -f -p <устройство_ext4>

Если код 4:

sudo e2fsck -f <устройство_ext4>

8. Проверить результат и пути

sudo e2fsck -fn <устройство_ext4>

sudo multipath -ll

journalctl -k -b --no-pager | grep -Ei \
'multipath|scsi|timeout|offline|I/O error'

Только после успешной проверки вернуть файловую систему приложению или кластеру.

Алгоритм 8. Каталог подключён по NFS

NFS предоставляет клиенту удалённую файловую систему, а не локальное блочное устройство ext4.

1. Подтвердить NFS

findmnt --target <каталог>

Пример:

SOURCE=server:/export/data
FSTYPE=nfs4

2. Не запускать локальный e2fsck

На клиенте отсутствует устройство ext4 сервера.

Нельзя выполнять:

e2fsck server:/export/data
e2fsck <локальная_точка_NFS>

Эти команды не лечат серверную файловую систему.

3. Проверить доступность данных

ls -la <каталог>

df -hT <каталог>

Проверить журнал:

journalctl -k -b --no-pager | grep -Ei \
'nfs|server not responding|stale file handle|I/O error'

4. Если данные читаются

Скопировать критичные данные на локальный исправный носитель:

sudo cp -a <каталог>/. <локальный_каталог>/

Если установлен rsync:

sudo rsync -aHAX --numeric-ids \
  <каталог>/ \
  <локальный_каталог>/

Проверить объём и выборочно открыть файлы.

5. Если NFS зависает или возвращает ошибки

Не создавать дополнительную нагрузку массовым чтением.

Зафиксировать:

findmnt --target <каталог>

journalctl -k -b --no-pager | grep -i nfs

6. Серверное восстановление

Если на NFS-сервере экспорт расположен на ext4, администратор сервера должен:

1. остановить доступ клиентов;
2. отключить экспорт или сервис приложения;
3. размонтировать локальную ext4;
4. проверить нижний уровень хранения;
5. выполнить e2fsck на локальном блочном устройстве сервера;
6. проверить данные;
7. вернуть экспорт.

С клиента выполнить этот ремонт невозможно.

Алгоритм 9. Каталог подключён по SMB или DFS

SMB/CIFS и DFS предоставляют сетевой файловый ресурс. Клиент ALT Linux не видит локальную файловую систему сервера.

1. Подтвердить SMB/CIFS

findmnt --target <каталог>

Пример:

SOURCE=//domain.local/dfs
FSTYPE=cifs

DFS-переходы также обслуживаются клиентом CIFS и могут вести на другой сервер.

2. Не запускать e2fsck

Нельзя выполнять e2fsck для:

//server/share
//domain/dfs
локальной точки монтирования cifs

На целевом сервере может находиться:

• NTFS или ReFS на Windows;
• ext4, XFS или другая ФС на Samba-сервере;
• кластерное хранилище.

Клиент этого не определяет.

3. Проверить доступность

ls -la <каталог>

df -hT <каталог>

journalctl -k -b --no-pager | grep -Ei \
'CIFS|SMB|DFS|reconnect|server|I/O error'

4. Если данные читаются

Скопировать важные данные на исправный локальный носитель:

sudo cp -a <каталог>/. <локальный_каталог>/

При наличии rsync:

sudo rsync -aHAX \
  <каталог>/ \
  <локальный_каталог>/

Проверить, сохранились ли ACL, владельцы и расширенные атрибуты. Возможности зависят от сервера и параметров CIFS.

5. Если DFS или SMB недоступны

Зафиксировать:

findmnt --target <каталог>

journalctl -k -b --no-pager | grep -Ei 'CIFS|SMB|DFS'

6. Если конечный сервер использует ext4

Ремонт выполняется только на сервере Samba:

1. остановить SMB-доступ;
2. убедиться, что ресурс не используется другими узлами;
3. размонтировать ext4;
4. проверить физический носитель, RAID, LVM или Multipath;
5. выполнить e2fsck на серверном блочном устройстве;
6. проверить данные;
7. вернуть SMB-ресурс.

Если конечный сервер работает под Windows, ext4 к нему не относится.

Алгоритм 10. Повреждён основной суперблок ext4

Применять только на стабильном блочном устройстве без I/O-ошибок.

Типовые сообщения:

Bad magic number in super-block
Superblock invalid
Couldn't find valid filesystem superblock
unable to read superblock

1. Определить правильное устройство ext4

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Для RAID использовать /dev/md*, для LVM — /dev/mapper/<VG>-<LV>, для Multipath — карту или LV поверх неё.

Не использовать отдельный компонент или путь.

2. Проверить нижний уровень

journalctl -k -b --no-pager | grep -Ei \
'I/O error|Buffer I/O|critical medium|reset|timeout|offline'

Для HDD или SATA SSD:

sudo smartctl -x <физический_диск>

Для NVMe:

sudo smartctl -x /dev/nvme0

Для RAID:

cat /proc/mdstat
sudo mdadm --detail /dev/md0

Для Multipath:

sudo multipath -ll

При любой нестабильности сначала создавать образ или копировать данные.

3. Убедиться, что устройство не смонтировано

findmnt --source <устройство_ext4>

Если смонтировано:

sudo umount <точка_монтирования>

Для корневой ФС использовать Rescue LiveCD.

4. Попытаться прочитать параметры

sudo dumpe2fs -h <устройство_ext4>

Если команда показывает:

Block size
Filesystem features

зафиксировать размер блока.

5. Получить предполагаемые резервные суперблоки

Команда mke2fs -n не записывает файловую систему:

sudo mke2fs -n -t ext4 -b <размер_блока> <устройство_ext4>

Размер блока нельзя угадывать. Если он неизвестен, сначала создать полный образ устройства и работать с копией.

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

6. Проверить резервный суперблок без изменений

sudo e2fsck -fn \
  -b <резервный_суперблок> \
  -B <размер_блока> \
  <устройство_ext4>

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

sudo e2fsck -f \
  -b <резервный_суперблок> \
  -B <размер_блока> \
  <устройство_ext4>

7. Проверить основной суперблок после ремонта

sudo e2fsck -fn <устройство_ext4>

Если основной и все резервные суперблоки не читаются, не перебирать случайные номера. Создать образ и перейти к восстановлению файлов через специализированные инструменты.

Алгоритм 11. e2fsck не может завершить восстановление

Применять, если:

• e2fsck возвращает код 4 или 8;
• после ремонта повторяются те же ошибки;
• ошибки появляются на каждом проходе;
• формируется большое количество файлов в lost+found;
• устройство монтируется только частично или не монтируется.

1. Немедленно прекратить повторные циклы ремонта

Не запускать снова и снова:

e2fsck -y

Повторные изменения метаданных могут уменьшить шанс извлечения исходной структуры каталогов.

2. Проверить нижний уровень

journalctl -k -b --no-pager | grep -Ei \
'I/O error|Buffer I/O|critical medium|reset|timeout|offline'

Проверить соответствующий уровень:

HDD/SSD:     smartctl
NVMe:        smartctl или nvme smart-log
RAID:        /proc/mdstat и mdadm --detail
LVM:         pvs, vgs, lvs
Multipath:   multipath -ll

Если обнаружена нестабильность, прекратить ремонт оригинала и создать образ.

3. Создать полную копию

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

Для устройства с ошибками чтения использовать GNU ddrescue:

sudo ddrescue -n \
  <исходное_устройство> \
  /mnt/recovery/ext4.img \
  /mnt/recovery/ext4.map

Работать дальше только с копией.

4. Проверить возможность чтения без монтирования

debugfs по умолчанию открывает ext4 без записи:

sudo debugfs -R 'ls -l /' <копия_ext4>

Если структура каталогов видна, извлекать наиболее важные данные на другой носитель.

Пример извлечения одного файла:

sudo debugfs \
  -R 'dump -p <путь_в_ext4> <локальный_путь>' \
  <копия_ext4>

5. Проверить lost+found

Если после e2fsck файловая система монтируется:

sudo mount -o ro <копия_ext4> <временная_точка>

Проверить:

ls -la <временная_точка>/lost+found

Объекты в lost+found могут:

• не иметь исходных имён;
• потерять исходный путь;
• быть фрагментами файлов;
• сохранять часть содержимого.

6. Признать обычный ремонт исчерпанным

Дальнейший e2fsck нецелесообразен, если:

• все копии суперблока повреждены;
• таблицы inode не читаются;
• значительная часть метаданных находится в нечитаемых блоках;
• блоки были физически потеряны и отсутствует RAID-копия;
• поверх повреждённых блоков уже записаны новые данные;
• каждый проход создаёт новые ошибки;
• устройство продолжает физически деградировать.

В этой точке задача меняется с «починить ext4» на «извлечь максимум доступных файлов».

Проверка после ремонта

После любого успешного алгоритма выполнить полный цикл.

1. Проверка без изменений

sudo e2fsck -fn <устройство_ext4>

Ожидаемый код:

0

2. Монтирование только для чтения

sudo mount -o ro <устройство_ext4> <временная_точка>

3. Проверка данных

Проверить:

• основные каталоги;
• важные файлы;
• владельцев и права;
• объём файлов;
• каталог lost+found;
• журналы приложений;
• базы данных средствами самих приложений.

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

4. Проверка ядра

journalctl -k -b -n 200 --no-pager

Не должно появляться новых:

I/O error
EXT4-fs error
JBD2 error
remounting filesystem read-only

5. Возврат в работу

Отключить временное монтирование:

sudo umount <временная_точка>

Подключить файловую систему штатным способом:

sudo mount <штатная_точка>

Проверить:

findmnt --target <штатная_точка>
df -hT <штатная_точка>

После серьёзного повреждения данные должны быть скопированы на другой исправный носитель даже при успешном восстановлении ext4.

Источники

• Документация ALT Linux 10.4: Rescue LiveCD и восстановление системы
• e2fsck(8): проверка и восстановление ext2/ext3/ext4
• e2image(8): сохранение метаданных ext4
• dumpe2fs(8): информация о суперблоках ext4
• mke2fs(8): режим -n и расположение резервных суперблоков
• Документация ядра Linux: ext4
• Документация ядра Linux: Multiple Mount Protection
• Документация ядра Linux: MD RAID
• GNU ddrescue
• Пакет GNU ddrescue в ALT Linux
• Документация ядра Linux: NFS
• SambaWiki: Linux CIFS и DFS