Debian/Ubuntu: XFS metadata corruption и emergency read-only — пошаговое восстановление

XFS давно считается надёжной файловой системой для серверов с высокой нагрузкой, большими томами и предсказуемым I/O. Но если в журнале появляются сообщения вроде xfs metadata corruption, xfs log inconsistent или ядро делает filesystem remounted read-only, инцидент быстро становится аварийным. На практике это выглядит просто: сайт перестаёт писать логи и кэш, база данных падает на ошибках записи, а после перезагрузки система попадает в emergency mode или не монтирует раздел.

Хорошая новость в том, что XFS обычно оставляет достаточно понятные следы в логах, а восстановление во многих случаях проходит штатно. Плохая — неправильный порядок действий легко усугубляет ситуацию. Самые неприятные ошибки здесь предсказуемы: запуск xfs_repair на смонтированном разделе, повторные перезагрузки «на удачу», очистка журнала без оценки последствий и ремонт без попытки сохранить данные.

Ниже — не просто набор команд, а практический сценарий: как определить проблемный том, как собрать диагностику, когда нужен rescue-режим, в каком порядке запускать xfs_repair и что обязательно проверить после восстановления.

Как распознать проблему: типичные симптомы XFS corruption

Обычно администратор сначала замечает не саму файловую систему, а её последствия. Приложения начинают получать ошибки записи, команды вроде touch или echo > file отвечают Read-only file system, а в dmesg и journalctl -k появляются сообщения о повреждении метаданных или сбое журнала.

Типичные формулировки в логах:

• XFS (...) Corruption detected. Unmount and run xfs_repair
• metadata corruption detected
• log mount/recovery failed
• Structure needs cleaning
• filesystem has been shut down
• Remounting filesystem read-only

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

Первое правило простое: не чините XFS вслепую. Сначала нужно понять, действительно ли повреждена файловая система, не деградирует ли диск и не вызван ли read-only remount проблемой ниже по стеку — на уровне блока, контроллера или гипервизора.

Почему XFS уходит в read-only

Ошибка сама по себе не означает, что виновата только файловая система. Чаще XFS лишь честно сообщает о проблеме и защищает данные, переводя том в режим только чтения.

Сбой диска, RAID, NVMe или storage backend

Это самый неприятный сценарий. В логах рядом с XFS часто появляются I/O error, таймауты, reset контроллера, ошибки NVMe или обрывы работы блочного устройства. В таком случае xfs_repair может исправить последствия, но не устранит первопричину.

Жёсткая перезагрузка или потеря питания

Внезапное выключение, зависание хоста, форсированная перезагрузка ВМ, kernel panic — всё это может оставить журнал XFS в неконсистентном состоянии. Отсюда и сообщения уровня xfs log inconsistent.

Проблемы на виртуальной платформе

На виртуальных серверах часть инцидентов приходит не изнутри гостевой ОС, а со стороны нижележащего хранилища. Если вы используете VDS, а в системе внезапно пошли I/O-ошибки без понятной локальной причины, стоит сразу проверить, не было ли инцидента на стороне платформы.

Аппаратная нестабильность

Реже, но встречаются ошибки памяти, неисправности контроллера, нестабильная железная конфигурация. Если XFS corruption повторяется без очевидной привязки к питанию или storage, смотреть нужно шире, а не только на сам раздел.

Что делать в первую очередь

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

1. Определите проблемный раздел или логический том.
2. Проверьте, смонтирован ли он и в каком режиме.
3. Соберите логи ядра и systemd.
4. По возможности сделайте резервную копию или образ устройства.
5. Только после этого переходите к офлайн-проверке и ремонту.

Если проблема затронула отдельный дата-раздел, обычно безопаснее остановить сервисы, размонтировать том и чинить его офлайн. Если повреждён root-раздел, чаще всего правильный путь — загрузка в rescue/live-окружение.

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

Если вы только выбираете площадку под такие задачи, имеет смысл смотреть на VDS с удобным доступом к системному восстановлению.

Диагностика до ремонта: какие команды запускать

Сначала нужно понять, где находится XFS и какое именно устройство пострадало.

findmnt -t xfs
lsblk -f
mount | grep xfs
cat /etc/fstab

После этого смотрим логи текущей загрузки и сообщения ядра.

dmesg -T | grep -Ei 'xfs|I/O error|metadata corruption|read-only|reset|abort|nvme|sd[a-z]'
journalctl -k -b | grep -Ei 'xfs|I/O error|read-only|nvme|buffer|blk|reset'
journalctl -xb | grep -Ei 'xfs|emergency|mount|fsck|repair'

Если раздел был принудительно переведён в ro, это почти всегда видно именно здесь. Заодно полезно проверить, нет ли признаков деградации самого накопителя.

smartctl -a /dev/sda
smartctl -a /dev/nvme0n1

На VPS SMART может быть недоступен, но логи ядра всё равно остаются главным источником информации. Если в них видны блоковые ошибки, стоит отдельно проверить и общую дисковую конфигурацию. Для этого может пригодиться материал про расширение и разметку дисков на VDS.

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

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

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

Подробнее

Нужно ли сразу запускать xfs_repair

Нет. Сначала убедитесь, что раздел не смонтирован. Для XFS офлайн-ремонт — это не пожелание, а нормальная обязательная практика.

mount | grep '/dev/sd'
findmnt /dev/sda2

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

systemctl stop nginx
systemctl stop php8.2-fpm
systemctl stop mysql
umount /dev/sda2

Если том занят, выясните, кто держит открытые файлы.

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

Проверка XFS без внесения изменений

Перед реальным ремонтом полезно выполнить безопасную проверку без модификаций. Для этого используется xfs_repair -n.

apt update
apt install xfsprogs
xfs_repair -n /dev/sda2

Ключ -n означает no modify. Утилита ничего не исправляет, а только показывает предполагаемые проблемы. Если в выводе подтверждается порча метаданных, ошибки allocation group, inode B-tree или проблемы с журналом, у вас уже есть основание переходить к реальному ремонту.

При этом важно помнить ограничение: xfs_repair -n может упереться в проблемный лог и сообщить, что полноценная проверка невозможна без дополнительных действий. Это ещё не повод сразу использовать жёсткие ключи.

Когда система загружается в emergency mode

Такой сценарий обычно возникает, если проблемный раздел указан в /etc/fstab как обязательный для монтирования или если повреждён корень. В emergency shell сначала нужно понять, какой именно mount unit сломался.

journalctl -xb
systemctl --failed
lsblk -f
cat /etc/fstab

Если проблема не в корневом разделе, а, например, в /var, /home или отдельном томе данных, иногда можно временно исправить запись в /etc/fstab, загрузить систему и уже потом чинить том офлайн. Но если повреждён rootfs, безопаснее использовать rescue-режим провайдера или live-образ.

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

Как правильно запускать xfs_repair

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

xfs_repair /dev/sda2

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

mount /dev/sda2 /mnt
dmesg -T | tail -n 50

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

Что делать при xfs log inconsistent

Самый спорный момент — повреждённый лог. Иногда обычный xfs_repair отказывается продолжать и рекомендует использовать ключ -L, который обнуляет журнал XFS.

xfs_repair -L /dev/sda2

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

xfs_repair -L — это не стандартный первый шаг, а вынужденная мера, когда обычный ремонт невозможен, а журнал не удаётся корректно проиграть. Если данные действительно важны, сначала делайте копию или работайте с образом устройства.

Если диск нестабилен, лучше сначала снять поблочную копию и уже потом экспериментировать с восстановлением. В таких сценариях обычно используют ddrescue, а не обычный dd, потому что он лучше переживает ошибки чтения и умеет работать повторными проходами.

Корневой раздел XFS: безопасный сценарий восстановления

Если сломан root-раздел, лучший путь — загрузиться в rescue или live-среду совместимой версии Debian/Ubuntu. Дальше нужно определить диск, при необходимости активировать LVM и выполнять проверку уже на неиспользуемой системе.

lsblk -f
vgchange -ay
xfs_repair -n /dev/mapper/vg0-root
xfs_repair /dev/mapper/vg0-root

Если обычный ремонт невозможен именно из-за повреждённого лога:

xfs_repair -L /dev/mapper/vg0-root

После ремонта можно смонтировать корень и проверить критичные каталоги.

mount /dev/mapper/vg0-root /mnt
ls -la /mnt
ls -la /mnt/var
ls -la /mnt/etc

Если на сервере есть отдельные разделы для /boot, /var или /home, проверьте и их. После возврата к обычной загрузке сразу собирайте журналы новой сессии — это поможет понять, устранена ли первопричина или проблема продолжается на уровне storage.

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

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

Что проверить после восстановления

Успешный запуск xfs_repair — это не финал, а только переход к валидации. После возврата раздела в строй стоит пройтись по короткому чек-листу.

• Файловая система монтируется без ошибок.
• В dmesg и journalctl -k нет новых сообщений о corruption.
• Сервисы могут писать в свои каталоги данных, кэша и логов.
• Нет повторяющихся I/O errors на уровне блока.
• Для СУБД выполнена собственная проверка целостности и тестовый запуск.

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

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

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

Подробнее

Почему проблема может повториться

Это частая история: администратор запускает ремонт, система оживает, а через несколько дней том снова уходит в read-only. Обычно это значит, что был устранён симптом, но не причина.

Если в логах были ошибки чтения, таймауты NVMe, reset устройства, проблемы контроллера или сбои на уровне гипервизора, нужен не только ремонт XFS, но и разбор состояния самого хранилища. Если инцидент произошёл после жёсткой перезагрузки, стоит отдельно проверить события питания, watchdog, стабильность ядра и историю panic/reboot.

На VPS и облачных серверах полезно сопоставлять момент ошибки с тем, что происходило внутри системы: резервное копирование, снапшоты, пиковая нагрузка по I/O, переполнение диска, зависание сервисов. Иногда XFS — не причина, а первый компонент, который корректно сообщил об аварии.

Практические советы по профилактике

Держите рабочие резервные копии

Нужны не просто архивы «на всякий случай», а проверяемые бэкапы с тестовым восстановлением. Именно они позволяют принимать спокойные решения, если обычный ремонт упирается в риск потери данных.

Следите за логами ядра и storage

Алерты по ключевым словам XFS, I/O error, blk_update_request, nvme timeout, Buffer I/O error помогают поймать деградацию до аварийного remount.

Не игнорируйте единичные эпизоды read-only

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

Планируйте rescue-доступ заранее

Для продакшн-серверов заранее проверьте доступ к консоли, recovery-режиму и процедуре подключения диска к другой машине. Такие задачи проще и безопаснее решать на сервере с понятным доступом к дискам и журналам платформы, чем в среде, где инфраструктура скрыта за несколькими слоями абстракции.

Держите установленный пакет xfsprogs

Если вы используете XFS, пакет xfsprogs должен быть под рукой. В аварии это экономит время и снижает шанс на лишние импровизации.

Короткий runbook: если XFS стал read-only

1. Не пытайтесь писать на проблемный раздел.
2. Соберите dmesg и journalctl, определите устройство через lsblk -f.
3. Проверьте, есть ли I/O-ошибки и признаки деградации диска.
4. Остановите сервисы и размонтируйте раздел.
5. Запустите xfs_repair -n.
6. Если диагноз подтверждён — выполните xfs_repair.
7. Если мешает повреждённый лог и других вариантов нет — только после оценки риска используйте xfs_repair -L.
8. Смонтируйте раздел, проверьте логи и затем валидируйте приложения.
9. Обязательно разберите первопричину, иначе инцидент почти наверняка повторится.

Итог

Ошибки уровня xfs metadata corruption, xfs log inconsistent и filesystem remounted read-only выглядят пугающе, но в большинстве случаев это рабочий инцидент, а не приговор данным. Ключ к нормальному восстановлению — дисциплина: сначала диагностика, потом офлайн-проверка, затем аккуратный ремонт и обязательный разбор первопричины.

Если избежать типовых ошибок — не чинить смонтированный раздел, не применять -L без понимания последствий и не игнорировать аппаратные симптомы — шансы на успешное восстановление обычно очень хорошие.