Debian/Ubuntu: как исправить ext4 orphan inodes и journal checksum errors

Ошибки ext4 редко возникают совсем без причины. Обычно администратор сначала замечает последствия: раздел внезапно перемонтирован в режим только для чтения, приложения получают ошибки записи, а в dmesg и журнале ядра появляются сообщения про orphan inodes, journal checksum error, EXT4-fs error или JBD2. После перезагрузки система может зависнуть на проверке диска или уйти в emergency mode.

На Debian и Ubuntu такие инциденты особенно неприятны на рабочих серверах: внешне всё выглядит как «сломался Linux», но на практике проблема обычно лежит в одном из нескольких слоёв — аварийное выключение, ошибки устройства хранения, проблемы памяти или уже повреждённая структура ext4.

Хорошая новость в том, что ext4 во многих случаях удаётся вернуть в рабочее состояние без полной потери данных. Плохая — если начать запускать исправление вслепую, можно усугубить повреждения. Поэтому ниже не просто набор команд, а пошаговый runbook: как подтвердить проблему, что проверить до fsck, когда нужен rescue-режим и как работать с резервными superblock.

Что означают orphan inodes и journal checksum errors

Сообщение про orphan inodes не всегда означает катастрофу. В ext4 есть механизм orphan list: туда попадают inode файлов, которые были удалены или усечены, но ещё не до конца обработаны файловой системой. После некорректного выключения ext4 при следующем монтировании может обнаружить такие inode и дочистить их штатно.

Гораздо тревожнее выглядят сообщения journal checksum error, JBD2: Invalid checksum или EXT4-fs: error loading journal. Журнал ext4 нужен для восстановления согласованности метаданных после сбоя. Если его контрольная сумма не сходится, это может означать повреждение журнала, ошибку записи на уровне диска, контроллера, гипервизора или возврат неверных данных снизу.

Практическое правило простое: orphan inodes после аварийного выключения — ещё не повод для паники, а вот journal checksum error, повторяющиеся ошибки чтения и записи блока и remount в read-only нужно рассматривать как потенциальное повреждение файловой системы или хранилища.

Важно также различать EXT4-fs warning и EXT4-fs error. Warning часто означает подозрительную, но ещё не критичную ситуацию. Error уже может запустить защитную реакцию: abort журнала, отказ монтирования или перемонтирование в режим только для чтения.

Типичные симптомы на Debian и Ubuntu

На живой системе такие инциденты обычно выглядят одинаково:

• корневой раздел или раздел с данными внезапно становится read-only;
• приложения получают Read-only file system или Input/output error;
• в dmesg появляются сообщения EXT4-fs error, JBD2, I/O error, Buffer I/O error;
• после перезагрузки запускается принудительная проверка fsck;
• раздел не монтируется автоматически, и система уходит в режим восстановления.

Особенно опасное сочетание — ошибки ext4 вместе с сообщениями блочного уровня: blk_update_request, I/O error, таймауты NVMe или SATA, сброс линка, SMART-предупреждения. В таком случае ext4 часто лишь первой сообщает о проблеме ниже по стеку.

Если сервер размещён на VDS, отдельно полезно зафиксировать время ошибки и понять, не совпадает ли инцидент с проблемами виртуального диска или хранилища на стороне платформы.

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

Если ext4 уже перемонтирована в read-only, не пытайтесь срочно вернуть запись через remount в rw. Обычно это плохая идея. Файловая система перешла в защитный режим не случайно, и принудительная запись может ухудшить состояние метаданных.

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

Для root-раздела почти всегда надёжнее планировать работу через recovery, rescue или live-среду, где проблемная файловая система не используется текущей ОС.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

С чего начать диагностику

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

mount | grep ' ext4 '
dmesg -T | grep -Ei 'ext4|jbd2|i/o error|buffer i/o|blk_update_request|nvme|ata'
journalctl -k -b -p warning
lsblk -f
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /
cat /etc/fstab

Если система уже перезагружалась, посмотрите и предыдущую загрузку:

journalctl -k -b -1 | grep -Ei 'ext4|jbd2|i/o error|buffer i/o|blk_update_request|nvme|ata'

На этом этапе нужно понять три вещи: какой именно раздел повреждён, есть ли признаки аппаратной проблемы и действительно ли файловая система ушла в ro из-за ошибки ext4, а не из-за опций монтирования.

Как быстро проверить, что раздел уже только для чтения

findmnt -no TARGET,OPTIONS /
findmnt -no TARGET,OPTIONS /var

Если в списке опций виден ro, ядро уже запретило запись. Некоторые сервисы ещё могут какое-то время работать за счёт кеша, но новые операции записи будут падать.

Проверьте, не проблема ли это диска или виртуального блока

Ошибка ext4 — не всегда первопричина. Нередко файловая система просто первой сообщает, что снизу пришли битые или неполные данные. Поэтому до любого ремонта обязательно проверьте само устройство.

smartctl -a /dev/sda
smartctl -a /dev/vda
nvme list
nvme smart-log /dev/nvme0

Ищите растущие ошибки чтения, media errors, перераспределённые сектора, критические предупреждения, большое число unsafe shutdowns. На виртуальных серверах SMART бывает ограничен, но сообщения ядра об ошибках ввода-вывода всё равно остаются важным признаком.

Если у вас регулярно заканчивается место, расширение диска и корректное увеличение раздела тоже стоит держать под рукой. Для этого пригодится материал про увеличение диска и раздела на VDS.

Когда можно запускать fsck, а когда нельзя

Самая частая ошибка — запуск fsck по смонтированной файловой системе в режиме записи. Так делать нельзя. Проверка и исправление ext4 должны выполняться по размонтированному разделу. Для root это обычно означает загрузку в recovery или rescue.

Сначала уточните устройство:

lsblk -f

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

systemctl stop nginx
systemctl stop php8.2-fpm
umount /dev/vdb1
fsck.ext4 -f /dev/vdb1

Если раздел занят, найдите процессы:

lsof +f -- /dev/vdb1
fuser -vm /dev/vdb1

Для корневой файловой системы используйте отдельную среду. На Debian и Ubuntu recovery mode иногда подходит для лёгких случаев, но при серьёзных повреждениях безопаснее rescue или live-среда.

Что означает вывод fsck и e2fsck

Утилиты fsck.ext4 и e2fsck проверяют inode, блоки, bitmap, каталоги, журнал и superblock. Если проблема ограничилась незавершённой транзакцией после сбоя питания, исправление часто проходит быстро. Если ошибок много, а вместе с ними есть I/O-проблемы, лучше сначала думать о копии данных или образе диска, а не о немедленном ремонте.

Базовый сценарий восстановления ext4 после сбоя

Если есть основания считать, что причиной был именно crash или power loss, а не деградирующее устройство, начните с классического сценария.

1. Остановите сервисы, пишущие на раздел.
2. Размонтируйте файловую систему или загрузитесь в rescue.
3. По возможности снимите резервную копию критичных данных.
4. Запустите e2fsck с подробным выводом.
5. После исправления повторите проверку.
6. Только затем возвращайте раздел в работу.

umount /dev/vdb1
e2fsck -f -v /dev/vdb1
e2fsck -f -v /dev/vdb1

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

Если раздел не монтируется: журнал и superblock

Когда система жалуется на superblock, это не обязательно означает полную потерю данных. У ext4 есть резервные superblock, и их можно использовать для проверки.

Сначала посмотрите параметры файловой системы:

dumpe2fs -h /dev/vdb1

Если основной superblock не читается, выведите расположение резервных:

mke2fs -n /dev/vdb1

Ключ -n ничего не форматирует, а только показывает предполагаемое расположение служебных структур. После этого можно попробовать проверку с альтернативным superblock:

e2fsck -b 32768 -f /dev/vdb1

Число 32768 приведено только как пример. Используйте значение, подходящее именно для вашего раздела. Если резервный superblock читается нормально, e2fsck сможет восстановить метаданные и вернуть файловую систему в консистентное состояние.

Для более общего понимания выбора файловой системы и особенностей ext4 полезно сравнить её с XFS в материале про сравнение ext4 и XFS на сервере.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Что делать, если root ext4 ушёл в read-only

Сценарий с root-разделом самый неприятный: ломаются логи, временные файлы, обновления пакетов и нормальная работа systemd. На практике это выглядит как каскадная авария: сначала приложение теряет возможность писать, затем systemd не может обновить состояние юнитов, после чего начинают сыпаться вторичные ошибки.

Если корень уже в ro, задача администратора — не оживить запись любой ценой, а стабилизировать ситуацию. Снимите вывод диагностики, при возможности сохраните конфиги и критичные данные на внешний носитель или по сети, затем готовьте перезагрузку в recovery или rescue.

dmesg -T | tail -n 100
mount | grep ' on / '
systemctl --failed

Если root расположен на LVM, после загрузки в rescue сначала активируйте группу томов:

vgchange -ay
lsblk -f
e2fsck -f /dev/mapper/vg0-root

Когда стоит сначала снимать образ, а не чинить раздел

Есть ситуации, когда немедленное исправление — плохой первый шаг. Если диск уже выдаёт ошибки чтения, smartctl показывает деградацию, а dmesg полон I/O errors, разумнее сначала получить блочную копию или хотя бы снять доступные критичные данные.

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

Как отличить единичный сбой от настоящей corruption

Практический критерий простой. Если был понятный инцидент — power loss, kernel panic, жёсткий reboot, сбой гипервизора — и после одного прохода e2fsck раздел стал чистым, а в логах больше не появляются новые ошибки, скорее всего, это разовый эффект.

Если же спустя день или неделю снова приходят journal checksum error, повторные orphan cleanup, remount в read-only, inode errors и особенно блочные I/O errors, значит проблема системная. В этом случае лечить нужно не только ext4, а искать источник повреждений: диск, контроллер, память, виртуализацию, питание или write cache.

Полезные команды для углублённой проверки ext4

Когда нужен более глубокий разбор, пригодятся утилиты из пакета e2fsprogs:

tune2fs -l /dev/vdb1
dumpe2fs -h /dev/vdb1
dumpe2fs /dev/vdb1 | grep -i 'superblock'
blkid /dev/vdb1

С их помощью можно увидеть UUID, параметры журнала, число монтирований, интервалы обязательной проверки и расположение резервных superblock. Это полезно и для восстановления, и для пост-инцидентного анализа.

После восстановления: что проверить обязательно

Успешный запуск e2fsck — ещё не конец истории. После возврата раздела в работу полезно провести короткий пост-инцидентный аудит.

• проверьте журналы ядра после монтирования и первых операций записи;
• убедитесь, что раздел монтируется в rw и без ошибок;
• посмотрите SMART или состояние виртуального диска ещё раз;
• проверьте, не пострадали ли приложения после аварийного remount;
• оцените целостность баз данных, если они жили на проблемном разделе;
• убедитесь, что актуальные резервные копии действительно читаются.

mount | grep ' ext4 '
dmesg -T | grep -Ei 'ext4|jbd2|i/o error|buffer i/o|blk_update_request'
journalctl -k -b -p warning

Как снизить риск повторения

Полностью исключить ошибки ext4 нельзя, но их вероятность можно заметно уменьшить. Нужны исправное хранилище, корректные shutdown и reboot, мониторинг SMART, наблюдение за ошибками ядра и нормальные резервные копии. Если сервер часто выключается аварийно или хранилище нестабильно, ext4 просто первой об этом сообщит.

Для проектов, которым важна предсказуемость и быстрое восстановление, стоит заранее держать понятный план миграции и резервирования. Если вы только подбираете площадку под сайт или сервис, имеет смысл сразу выбрать подходящий виртуальный хостинг или серверный тариф с удобным доступом к rescue-инструментам и бэкапам.

Если ext4 уже один раз ушла в read-only на продакшне, относитесь к этому как к полноценному инфраструктурному инциденту, даже если fsck исправил проблему за несколько минут.

Краткий runbook для администратора

1. Соберите ошибки из dmesg и journalctl -k.
2. Проверьте, не ушёл ли раздел в ro.
3. Оцените состояние устройства через SMART или NVMe health.
4. Остановите запись на проблемный раздел.
5. Размонтируйте файловую систему или загрузитесь в rescue.
6. Запустите e2fsck -f -v.
7. При жалобах на superblock используйте резервный superblock.
8. После исправления повторно проверьте раздел.
9. Верните его в работу и наблюдайте логи.
10. Если ошибки возвращаются, ищите проблему на уровне диска, памяти или платформы.

Итог

Связка orphan inodes, journal checksum error и внезапный режим read-only в Debian или Ubuntu — это не история про «само пройдёт после перезагрузки». Правильная реакция — остановить запись, собрать симптомы, проверить устройство, запускать fsck только на размонтированной файловой системе и при необходимости использовать резервные superblock.

Во многих случаях ext4 восстанавливается предсказуемо, если действовать аккуратно. Но если за ошибками стоят реальные I/O-сбои, никакой магический e2fsck не заменит замену проблемного диска или разбор проблем на уровне хранения. Именно это и определяет, вернётся ли сервер к нормальной работе надолго.