Ошибка «resize2fs: bad magic number in super-block»: причины и способы исправления

Ошибка resize2fs: Bad magic number in super-block while trying to open /dev/sdXN означает, что утилита resize2fs прочитала первый килобайт раздела и не нашла там сигнатуру файловой системы ext2/ext3/ext4 — магическое число 0xEF53 в суперблоке. Проще говоря, либо раздел содержит не ту файловую систему, которую вы ожидаете, либо его суперблок повреждён, либо команда обращается не к тому устройству.

Проблема часто возникает после расширения виртуального диска на VPS, при работе с LVM-томами, а также при попытке изменить размер раздела с XFS, NTFS или Btrfs инструментом, который с ними просто не работает. Ниже разберём диагностику по шагам и безопасные способы вернуть раздел в рабочее состояние.

Что означает «bad magic number in super-block»

Каждая файловая система семейства ext хранит в суперблоке служебную структуру, где по фиксированному смещению записано двухбайтовое значение 0xEF53. Именно по нему утилиты e2fsprogs — resize2fs, e2fsck, tune2fs — определяют, что перед ними ext-подобная ФС. Если байты на этом месте другие, утилита честно сообщает: «магическое число неверно, открыть не могу».

Важно понимать: это сообщение не всегда означает повреждение данных. В значительной части случаев раздел абсолютно исправен — просто на нём другая файловая система, и resize2fs для неё не предназначен. Поэтому первый шаг — не «чинить», а выяснить, что реально находится на устройстве.

Основные причины ошибки

Прежде чем что-либо исправлять, определите, какой из сценариев ваш. От этого зависит вся дальнейшая стратегия.

• 🔍 Неверный тип ФС. На разделе XFS, Btrfs, NTFS, exFAT или swap — resize2fs работает только с ext2/ext3/ext4.
• 🔀 Не то устройство. Команда направлена на диск целиком (/dev/sda) вместо раздела (/dev/sda1), на LVM-физический том или на wrong-раздел после переразметки.
• 🧩 LVM-прослойка. Файловая система живёт внутри логического тома /dev/mapper/vg-lv, а resize2fs запущен на физическом разделе, где лежит заголовок LVM.
• 💾 Повреждённый суперблок. Аварийное отключение питания, сбой диска или оборванная операция расширения испортили основной суперблок.
• 📏 Таблица разделов не обновлена. Диск расширили на гипервизоре, но раздел внутри не увеличили — и наоборот, раздел увеличен, а ФС пытаются растянуть некорректно.

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

Начните с команды, которая покажет фактический тип ФС на устройстве:

lsblk -f
blkid /dev/sdXN

Вывод blkid содержит поле TYPE="..." — вот он и есть ответ. Если там xfs, btrfs, ntfs или swap, то ошибка объясняется тривиально: resize2fs с этими ФС не работает, и ничего чинить не нужно. Для XFS используется xfs_growfs (только увеличение и только на смонтированной ФС), для Btrfs — btrfs filesystem resize.

Если blkid вообще ничего не вернул, проверьте, не является ли устройство контейнером для чего-то ещё:

file -s /dev/sdXN
pvs        # есть ли на устройстве LVM physical volume
cryptsetup isLuks /dev/sdXN   # не зашифрован ли раздел

⚠️ Внимание: не запускайте mkfs, fsck -y или любые «исправляющие» утилиты до тех пор, пока не поймёте, что находится на разделе. Автоматическое «исправление» чужой файловой системы способно уничтожить данные безвозвратно.

Сценарий 1: на разделе не ext-файловая система

Самый частый и самый безобидный случай. На многих современных дистрибутивах корневой раздел по умолчанию форматируется в XFS (например, в семействе RHEL/CentOS), а администратор по привычке запускает resize2fs. Решение — использовать правильный инструмент:

# Для XFS (ФС должна быть смонтирована):
xfs_growfs /mount/point

Для Btrfs:
btrfs filesystem resize max /mount/point

Для NTFS из Linux применяется ntfsresize из пакета ntfs-3g, причём перед этим раздел должен быть чисто размонтирован. Swap расширять не нужно вовсе — его пересоздают командами mkswap и swapon.

Сценарий 2: раздел внутри LVM

Если blkid показывает TYPE="LVM2_member", файловая система находится глубже — внутри логического тома. Обращаться resize2fs к физическому разделу бессмысленно: там лежит заголовок LVM, а не суперблок ext4. Посмотрите структуру томов:

lvs
vgs
lsblk

Дальше работа ведётся с логическим томом. Типовая последовательность расширения выглядит так:

# 1. Расширить логический том (пример: использовать всё свободное место VG)
lvextend -l +100%FREE /dev/vgname/lvname

2. Растянуть файловую систему внутри тома
resize2fs /dev/vgname/lvname        # для ext4
xfs_growfs /mount/point             # для XFS

Обратите внимание на порядок: сначала расширяется блочное устройство (LV), затем — файловая система на нём. При уменьшении порядок строго обратный: сначала сжать ФС, потом том, иначе суперблок окажется за границей устройства.

Сценарий 3: суперблок ext4 действительно повреждён

Если blkid молчит или file -s не опознаёт ФС, хотя там точно была ext4 — вероятно, основной суперблок испорчен. К счастью, ext-системы хранят резервные копии суперблока, разбросанные по группам блоков. Найти их позиции можно так:

# Показать расположение резервных суперблоков (работает даже на повреждённой ФС)
mke2fs -n /dev/sdXN
либо
dumpe2fs /dev/sdXN | grep -i superblock

⚠️ Внимание: ключ -n у mke2fs критически важен — он запускает «сухой прогон» без реальной записи на диск. Команда без этого ключа отформатирует раздел и уничтожит данные.

Затем запустите проверку с указанием альтернативного суперблока (номер возьмите из вывода предыдущей команды, например 32768):

e2fsck -b 32768 /dev/sdXN

Если проверка прошла и ФС восстановлена, смонтируйте раздел и убедитесь, что данные на месте. Только после этого имеет смысл возвращаться к resize2fs. Когда и резервные суперблоки недоступны, остаются инструменты каравайного восстановления вроде TestDisk или PhotoRec — либо восстановление из бэкапа.

Почему mke2fs -n показывает правильные позиции суперблоков

Расположение резервных суперблоков вычисляется из размера блока и геометрии ФС, а не читается с диска. Поэтому «сухой» запрос mke2fs -n с теми же параметрами, что использовались при создании ФС (обычно значения по умолчанию), выдаёт корректные номера блоков, даже если основной суперблок полностью стёрт.

Сценарий 4: расширение диска на VPS или виртуальной машине

Типичная цепочка при увеличении виртуального диска: гипервизор отдал больше места → нужно расширить раздел → затем файловую систему. Ошибка bad magic number здесь обычно означает, что шаг с разделом пропущен или выполнен некорректно, и resize2fs упёрся в неожиданную структуру.

Правильная последовательность для диска с GPT/MBR-разделом:

# 1. Убедиться, что ядро видит новый размер диска
lsblk /dev/sdX

2. Расширить раздел (пример для раздела 1)
growpart /dev/sdX 1

3. Растянуть ФС
resize2fs /dev/sdX1     # ext4
xfs_growfs /            # XFS, точка монтирования

Если lsblk показывает старый размер диска, возможно, требуется пересканирование шины или перезагрузка виртуальной машины — зависит от гипервизора. А если диск разбит через LVM, после growpart дополнительно выполняется pvresize /dev/sdXN, затем lvextend и только потом работа с ФС.

Как не потерять данные: общие правила

Операции с разделами и файловыми системами относятся к зоне повышенного риска. Несколько принципов, которые сводят этот риск к минимуму:

• 🗂️ Бэкап перед любыми изменениями. Хотя бы копия критичных файлов, в идеале — посекторный снимок через dd или снапшот диска на стороне гипервизора.
• 🧪 Сначала чтение, потом запись. Все диагностические команды (lsblk, blkid, file -s, dumpe2fs) ничего не меняют на диске — исчерпайте их полностью.
• ✅ e2fsck перед resize2fs. Утилита resize2fs сама требует чистую, проверенную ФС; принудительная проверка e2fsck -f /dev/sdXN — стандартный шаг.
• 🚫 Никаких -y и --force без понимания. Автоматическое согласие на все исправления может «починить» ФС до состояния нечитаемости.

Сводная таблица: причина → диагностика → решение

Причина	Как проверить	Решение
ФС не ext (XFS/Btrfs/NTFS)	blkid /dev/sdXN	Использовать xfs_growfs / btrfs / ntfsresize
Раздел — LVM physical volume	pvs, lsblk	Работать с LV: lvextend + resize2fs на /dev/vg/lv
Не тот раздел/диск	lsblk -f	Указать корректное устройство с разделом
Повреждён суперблок ext4	file -s, dumpe2fs	e2fsck -b с резервным суперблоком
Раздел не расширен после grow диска	lsblk vs размер диска	growpart, затем resize2fs/xfs_growfs

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

Можно ли запускать resize2fs на смонтированной файловой системе?

Увеличение ext4 в онлайн-режиме поддерживается и работает, если ядро и ФС это позволяют. Уменьшение — только на размонтированной ФС, без исключений. При любых сомнениях размонтируйте раздел или загрузитесь с Live-носителя.

blkid ничего не выводит — данные потеряны?

Не обязательно. Пустой вывод означает лишь, что утилита не опознала сигнатуру. Проверьте устройство через file -s, pvs и cryptsetup isLuks — возможно, это LVM, LUKS-контейнер или просто не тот раздел. Реальное повреждение подтверждается только после этих проверок.

Чем опасна команда e2fsck -y на повреждённом разделе?

Ключ -y автоматически соглашается на все исправления, включая удаление «битых» inode и обрезку файлов. На сильно повреждённой ФС это может превратить частично читаемые данные в набор обезличенных файлов в lost+found. Безопаснее сначала запустить проверку с -n (только чтение) и оценить масштаб проблем.

После расширения диска на VPS resize2fs пишет «nothing to do» — это та же ошибка?

Нет, это другая ситуация: ФС уже занимает весь доступный размер раздела. Значит, либо раздел не был расширен (нужен growpart), либо файловая система уже растянута. Сверьте вывод lsblk и df -h.

Поможет ли TestDisk, если резервные суперблоки не сработали?

TestDisk умеет искать следы файловых систем и восстанавливать таблицу разделов, а PhotoRec извлекает файлы по сигнатурам даже при полностью разрушенной ФС. Это шанс спасти данные, но не гарантия — при серьёзных повреждениях и ценных данных разумнее обратиться в профильную лабораторию восстановления.