Ext4/XFS remount-ro на VDS: journal errors, XFS shutdown и восстановление файловой системы

Что означает remount-ro и почему это важно

Ситуация выглядит так: сервисы начинают «сыпаться», в логах появляются ошибки записи, а попытки создать файл или обновить конфиг заканчиваются сообщением Read-only filesystem. При этом сервер живой, сеть доступна, но запись на диск «запрещена».

В Linux это защитный механизм. Для ext4 типичный сценарий — ошибка журнала (часто ищут как ext4 journal error) или цепочка ошибок ввода-вывода, после чего ядро перемонтирует файловую систему в режим ro, чтобы не усугубить повреждение. Для XFS аналогом выступает аварийное выключение файловой системы (XFS shutdown), когда XFS считает дальнейшую работу небезопасной.

Remount-ro — не «причина», а симптом. Задача — выяснить, что именно сломалось: виртуальный диск/хранилище, сбой питания/перезагрузка, ошибки блочного слоя, баги драйвера, перегрузка по I/O.

Типовые симптомы в логах: на что смотреть

Первое место, где обычно видно первопричину: dmesg и journalctl -k. Важно смотреть не только строки ext4/XFS, но и любые I/O-ошибки на уровне блочного устройства.

Ext4: journal error и перемонтирование в ro

Часто встречаются строки вида:

EXT4-fs error (device vda1): ext4_journal_check_start:56: Detected aborted journal
EXT4-fs (vda1): Remounting filesystem read-only

Если в выводе монтирования видите опцию errors=remount-ro, это штатное поведение: при обнаружении ошибки ext4 уходит в ro, чтобы остановить запись и снизить риск дальнейшей порчи.

XFS: shutdown и требование xfs_repair

Для XFS типично:

XFS (vda1): metadata I/O error: block 0x..., error 5
XFS (vda1): Corruption detected. Unmount and run xfs_repair
XFS (vda1): xfs_do_force_shutdown(0x8) called from line ...

После XFS shutdown операции записи падают, а иногда затрагиваются и чтения. Обычно это означает, что нужно планировать обслуживание (downtime) и ремонт метаданных.

Сообщения блочного слоя: blk_update_request

Если в dmesg вы видите blk_update_request: I/O error или Buffer I/O error, это сильный индикатор проблем нижнего слоя хранения (диск, виртуальный диск, контроллер, таймауты):

blk_update_request: I/O error, dev vda, sector 123456 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
Buffer I/O error on dev vda1, logical block 15432, lost async page write

Такие записи часто предшествуют remount-ro. Важно: бесконечные fsck/xfs_repair без устранения I/O-причины часто дают краткосрочный эффект или усугубляют ситуацию.

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

План действий: что делать сразу, чтобы не усугубить

1) Зафиксируйте статус и остановите запись

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

• Оцените, что именно стало read-only: корень, отдельный раздел, отдельный том (например, /var или /home).
• Остановите «шумные» сервисы (БД, очереди, воркеры, обработчики загрузок), чтобы не множить ошибки и не раздувать очереди.

Проверьте текущее состояние:

mount | grep -E ' / |/var|/home'
findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /

2) Соберите логи, пока они доступны

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

dmesg -T | tail -n 200
journalctl -k -b --no-pager | tail -n 300

Совет: если /var на отдельном разделе, проверьте, не ушёл ли именно он в ro — тогда симптомы могут быть «везде», хотя корень остаётся rw.

3) Проверьте свободное место и inodes (вдруг это не I/O)

Переполнение диска обычно не вызывает remount-ro напрямую, но может быть сопутствующим фактором и ломать приложения «похожими» симптомами.

df -hT
df -ih

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

Шаг A: отличить повреждение ФС от проблем блочного слоя

Если в логах есть blk_update_request: I/O error, Buffer I/O error, таймауты устройства, ресеты контроллера — начинайте с проверки устройства/хранилища. Ремонт файловой системы без устранения I/O-причины часто заканчивается повтором аварии и дополнительной порчей.

Если I/O-ошибок нет, а есть только сообщения ext4/XFS о метаданных/журнале, возможно это «чистая» порча ФС из-за падения/жёсткой перезагрузки, и тогда ремонт действительно поможет.

Шаг B: SMART (smartctl) и NVMe (nvme-cli)

На VDS доступность SMART зависит от виртуализации и политики провайдера: иногда в гостевую ОС он не пробрасывается. Но проверить стоит.

Для SATA/SAS:

smartctl -a /dev/vda
smartctl -a /dev/sda

Для NVMe:

nvme list
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0

На что смотреть: растущие счётчики ошибок, media_errors, unsafe_shutdowns, повторяющиеся записи в error-log, подозрительно высокий износ.

Шаг C: подтвердить ro-режим и исключить «ручные» причины

Убедитесь, что это именно remount-ro, а не опция ro в /etc/fstab или особенности initramfs. Смотрите опции монтирования:

findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
cat /etc/fstab

Если видите errors=remount-ro, это нормальная страховка ext4. Менять её на errors=panic или errors=continue без понимания последствий не стоит: первое может уронить систему, второе — увеличить риск «тихой» порчи.

Если параллельно вы настраиваете дисковые опции и обслуживание томов, полезно держать под рукой шпаргалку по росту раздела/ФС на виртуалке: как расширить диск на VDS и корректно увеличить файловую систему.

Восстановление ext4 после remount-ro и journal error

Ключевой момент: полноценный fsck для корневого раздела требует, чтобы раздел был размонтирован. На боевой машине это обычно означает загрузку в rescue/recovery режим или подключение диска к другой системе.

1) Определите устройство и раздел

lsblk -f
blkid

Запомните, где ваш ext4: например, /dev/vda1, /dev/vda2 или LVM-том.

2) Диагностическая проверка и затем ремонт

Сначала прогон «только чтение»:

fsck.ext4 -fn /dev/vda1

Затем ремонт (обычно в maintenance/rescue):

fsck.ext4 -fy /dev/vda1

• -f — принудительная проверка;
• -n — ничего не менять (диагностика);
• -y — автоматически отвечать «да» (удобно, но важно понимать: fsck будет чинить и может удалять повреждённые структуры).

3) После fsck: проверьте lost+found и целостность данных приложения

Если fsck восстанавливал «потерянные» inodes, они окажутся в lost+found. Для веб-сервера это может означать частичную потерю загрузок, для БД — риск логической порчи. После восстановления обязательно проверьте данные на уровне приложения (проверки таблиц/индексов, тестовые запросы, smoke-тест сайта).

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

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

Подробнее

Восстановление XFS после shutdown: xfs_repair

XFS устроен иначе: вместо fsck используется xfs_repair. И здесь особенно важно не запускать «ремонт наугад» на смонтированном томе.

1) Убедитесь, что раздел размонтирован

mount | grep xfs

Если это не корень и его можно снять:

umount /mount/point

2) Ремонт метаданных

xfs_repair /dev/vda1

Иногда при проблемах журнала XFS просит очистить лог. Это рискованно: можно потерять последние транзакции. Делайте только если xfs_repair явно указывает на необходимость, и желательно имея свежий бэкап или снапшот.

xfs_repair -L /dev/vda1

Если XFS «падает» повторно после ремонта, чаще всего причина ниже уровня ФС: повторяющиеся I/O-ошибки, таймауты, деградация хранилища.

Можно ли просто перемонтировать обратно в rw?

Часто хочется сделать:

mount -o remount,rw /

Иногда это срабатывает, но по сути вы не устраняете причину (I/O/журнал/метаданные) и рискуете усугубить повреждение при продолжении записи. Правильный подход: считать remount-ro аварийным режимом и планировать окно на проверку и восстановление.

Практичный чек-лист диагностики (с командами)

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

1. Определить, что именно стало read-only:

   findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
   mount | grep -E ' ro[,)]|\(ro'
   

2. Найти первичный триггер (ext4/XFS или blk layer):

   journalctl -k -b --no-pager | tail -n 400
   dmesg -T | grep -E 'EXT4-fs|XFS|blk_update_request|I/O error|Buffer I/O|reset|timeout' | tail -n 200
   

3. Снять карту дисков/ФС:

   lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
   lsblk -f
   blkid
   

4. Проверить метрики диска (если доступны):

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

5. Запланировать обслуживание: fsck или xfs_repair из rescue/maintenance.

Почему это часто случается на VDS: частые причины

• Проблемы в нижнем слое хранения: кратковременные ошибки чтения/записи, таймауты, деградация дисков, проблемы контроллера.
• Резкое выключение: аварийная перезагрузка, падение хоста, принудительный reset.
• Перегрузка по I/O: высокая latency, очереди, «шторм» от приложений.
• Ошибки гостевой ОС: некорректные драйверы virtio, редкие баги ядра.

Профилактика: как уменьшить шанс повторения remount-ro

Мониторинг сигналов I/O

Смысл — поймать проблему раньше, чем файловая система уйдёт в read-only:

• алерты по шаблонам в journalctl -k: blk_update_request, I/O error, EXT4-fs error, XFS (.*) shutdown;
• алерты на рост latency диска и времени ожидания I/O (особенно для БД);
• регулярная проверка SMART/NVMe health там, где это доступно.

Если вы выстраиваете алерты и квоты под проекты на одном сервере, пригодится отдельный материал: квоты и алерты для ext4/XFS, чтобы ловить проблемы раньше.

Бэкапы и проверка восстановления

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

Аккуратные mount options

Для ext4 опция errors=remount-ro — разумный дефолт. Не отключайте её ради «аптайма». Для XFS важнее дисциплина: при признаках XFS shutdown не пытайтесь «продавить» запись, а планируйте ремонт через xfs_repair.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Мини-FAQ по частым вопросам

Почему внезапно стало read-only, хотя места на диске достаточно?

Потому что read-only чаще связан не с заполнением, а с ошибками записи/журнала. Ищите blk_update_request, I/O errors и сообщения ext4/XFS в dmesg.

fsck/xfs_repair «починили», но через день снова remount-ro

Это типичный признак того, что первопричина ниже уровня ФС: деградация хранилища, повторяющиеся таймауты I/O, проблемы на стороне хоста. В таком случае ремонт ФС — временная мера.

Можно ли делать fsck на смонтированном ext4?

Технически есть режимы, но для корневого раздела и боевых данных правильный путь — проверка на размонтированном томе (rescue/maintenance). Это снижает риск дополнительной порчи.

Итоги

Если на VDS вы столкнулись с remount-ro, read-only filesystem, ext4 journal error или XFS shutdown, действуйте по схеме: зафиксируйте симптомы, найдите первопричину в dmesg/journalctl -k, отделите проблемы файловой системы от I/O на уровне устройства, затем выполните корректный ремонт (fsck для ext4, xfs_repair для XFS) в безопасном режиме обслуживания. И обязательно подумайте о профилактике: мониторинг I/O-ошибок и проверяемые бэкапы обычно дают больше пользы, чем попытки «вернуть rw любой ценой».