Файловая система ушла в read-only: что делать в первые 10 минут

MAATRIX

Сервер работал нормально, а потом приложение вдруг не может сохранить файл, cron-задача падает с непонятной ошибкой, а в логе мелькает Read-only file system. Первая реакция — перезагрузить и понадеяться, что само пройдёт. Это ровно то, чего делать не стоит: read-only — это не поломка сама по себе, а защитный механизм ядра, и грубая перезагрузка вслепую может превратить восстановимую ситуацию в потерю данных. Разберём, что происходит на самом деле и что сделать в первые десять минут, пока ничего не испорчено.

Первый признак: тихая ошибка там, где раньше всё работало

Read-only редко объявляет о себе явно. Обычно всё начинается с одного из таких симптомов:

• приложение падает при попытке что-то записать — например, веб-сервер возвращает 500 при сохранении файла или загрузке изображения;
• логи перестают писаться — journalctl живой, но файлы в /var/log не растут, а при попытке logrotate или ручной записи в лог вылезает ошибка;
• база данных отказывается принимать запросы на запись — PostgreSQL или MySQL начинают кидать ошибки вида could not write to file или полностью останавливаются;
• любая простая команда падает неожиданно: touch test.txt, mkdir tmp, apt install — и все они говорят одно и то же: Read-only file system.

Стоит проверить это напрямую:

mount | grep ' / '

Если в выводе вместо rw стоит ro:

/dev/sda1 on / type ext4 (ro,relatime)

— значит, ядро уже перевело корневой (или другой) раздел в режим только для чтения. Это не глюк приложения и не баг конкретного сервиса — сломался более низкий уровень, и все верхние сервисы просто отражают эту поломку каждый на свой лад. Если в ro ушёл не корень, а, скажем, отдельный раздел с данными (/var, /data), — хорошая новость: система в целом жива, и можно спокойно работать по SSH, не опасаясь, что сессия оборвётся посреди диагностики.

Почему ядро само уходит в read-only — и это не баг, а защита

Ключевая вещь, которую важно понять до того, как что-то предпринимать: ядро Linux никогда не переводит файловую систему в read-only просто так. Это осознанный защитный механизм, встроенный в ext4, XFS и большинство других журналируемых ФС.

Логика такая: во время работы ФС постоянно сверяет метаданные — структуры, которые описывают, где лежат файлы, какие блоки свободны, какие заняты, что записано в журнале транзакций. Если при очередной операции ядро обнаруживает несовпадение — блок помечен свободным, но на него ссылается живой файл, или структура журнала повреждена — оно делает вывод, что дальнейшая запись рискует усугубить повреждение, и вместо попытки записать поверх нарушенной структуры просто останавливает запись. Это называется remount-ro, и в ext4 такое поведение задаётся параметром errors=remount-ro (проверить: tune2fs -l /dev/sdXN | grep -i errors).

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

1. Сам диск начал сбоить физически (bad-блоки, отказ контроллера, деградация NAND у SSD) — и именно поэтому ФС на нём видит противоречивые данные.
2. Файловая система повредилась логически — из-за резкого выключения питания, зависания гипервизора, бага в самой ФС или в драйвере — а с диском физически всё в порядке.

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

Первые 10 минут: не паниковать, не перезагружать вслепую

Самая частая ошибка в этой ситуации — сразу выполнить reboot в надежде, что при следующей загрузке всё само себя поправит. Иногда это действительно срабатывает: система на старте прогоняет автоматическую проверку и remount проходит нормально. Но если причина в диске, который реально умирает, безусловная перезагрузка ничего не диагностирует и может застать сервер в худший момент — например, посреди попытки записи, которая раньше падала на read-only, а теперь может пройти частично и оставить файл битым.

Порядок действий на первые 10 минут:

1. Зафиксируйте, что вообще произошло, прежде чем трогать систему:

   mount | grep ro,
   uptime
   who -b

Если сервер не перезагружался (who -b показывает старую дату), значит remount-ro произошёл «на живую» — это важная деталь для дальнейшей диагностики.

1. Посмотрите dmesg — здесь обычно вся правда:

   dmesg -T | grep -iE 'error|ext4|xfs|remount|i/o|ata|nvme'

Если сервер уже перезагружался и буфер dmesg очищен, ищите то же самое в системном журнале: ``bash journalctl -k --since "2 hours ago" | grep -iE 'error|ext4|xfs|i/o' ``

1. Не запускайте fsck на смонтированном разделе и тем более не пытайтесь «на всякий случай» перемонтировать в rw командой mount -o remount,rw / до того, как понятна причина — если дело в физическом диске, принудительная запись может ускорить его смерть и добить данные, которые ещё можно спасти.

1. Если это не корневой раздел — остановите сервисы, которые в него пишут (СУБД, очереди, приложение), чтобы они не продолжали пытаться писать и не забивали логи однотипными ошибками, пока вы разбираетесь.

Дальше всё зависит от того, что покажет dmesg — а покажет он одно из двух: ошибку конкретного диска (аппаратная проблема) или ошибку структур самой файловой системы.

Как отличить по dmesg: умирает диск или сломалась структура ФС

В выводе dmesg обычно видно один из двух характерных паттернов.

Признаки аппаратной проблемы с диском — сообщения о самом устройстве, ещё до упоминания файловой системы:

[12345.678] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[12345.680] blk_update_request: I/O error, dev sda, sector 123456789
[12345.681] Buffer I/O error on device sda1, logical block 654321

Для NVMe картина похожая: nvme0n1: I/O error, dev nvme0n1, sector 123456789 или nvme nvme0: I/O 12 QID 3 timeout, aborting. Ключевые слова — I/O error, ata exception, nvme timeout, обращение к конкретному сектору. Это значит, что ядро не смогло прочитать или записать данные на уровне блочного устройства — проблема ниже файловой системы, на уровне самого диска, кабеля SATA или прошивки SSD.

Признаки логической ошибки файловой системы — сообщения непосредственно от драйвера ext4/XFS про несовпадение структур:

[12345.678] EXT4-fs error (device sda1): ext4_find_entry:1436: inode #131074: comm nginx
[12345.679] EXT4-fs (sda1): error count since last fsck: 3
[12345.680] EXT4-fs (sda1): Remounting filesystem read-only

Для XFS — XFS (sda1): Metadata corruption detected и Unmounting filesystem due to corruption. Ключевые слова — EXT4-fs error, Metadata corruption, error count since last fsck, Remounting filesystem read-only. Диск при этом физически может отвечать нормально — просто структуры на нём внутренне противоречивы.

Бывает и смешанный случай: сначала идут I/O error, а через несколько строк — EXT4-fs error. Это значит, что физическая проблема диска и есть причина повреждения метаданных: диск не смог прочитать/записать блок, из-за этого ФС увидела противоречие и ушла в защиту. В этом случае действовать нужно по ветке «диск», а не «файловая система» — чинить логику ФС на умирающем железе бессмысленно.

Ветка «виноват диск»: SMART, готовим замену

Если в dmesg преобладают I/O error и обращения к блочному устройству, следующий шаг — проверить состояние диска напрямую, не трогая файловую систему.

smartctl -a /dev/sda

Обратите внимание на несколько полей:

Для NVMe: nvme smart-log /dev/nvme0 — смотрите на media_errors и percentage_used (близко к 100% — ресурс исчерпан). Полезно прогнать короткий самотест: smartctl -t short /dev/sda, через пару минут — smartctl -l selftest /dev/sda.

Если тест или атрибуты показывают деградацию — считайте, что диск на пути к отказу, даже если формально ещё «жив»:

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

   ddrescue -d -r3 /dev/sda /mnt/backup/sda.img /mnt/backup/sda.log

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

1. Готовьте замену диска, не дожидаясь полного отказа. На арендованном сервере обратитесь в поддержку провайдера с диагностикой на руках (вывод smartctl, сектор из dmesg) — так замена происходит быстрее.
2. Восстанавливайте сервисы на новом диске из свежего бэкапа, а не пытайтесь «долечить» старый — рост Reallocated/Pending секторов это тренд, а не разовая случайность.

Ветка «виновата файловая система»: сначала копия, потом fsck

Если dmesg показывает именно ошибки ext4/XFS без признаков I/O-проблем диска — вероятно, повреждение логическое: например, сервер завис или получил hard reset (сброс по питанию, зависший гипервизор, OOM-killer убил процесс посреди записи) в момент, когда журнал транзакций был не в консистентном состоянии.

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

1. Ещё раз убедитесь, что дело не в диске — прогоните smartctl, даже если dmesg выглядит как чисто ФС-ошибка: логическое повреждение и умирающий диск не исключают друг друга.
2. Скопируйте то, что можно, пока раздел ещё смонтирован в ro — read-only не мешает чтению:

   rsync -aAX /mnt/broken/ /mnt/backup/

Если есть недавний автоматический бэкап (снапшот у провайдера, borgbackup, restic) — сверьте, что он свежий, прежде чем что-либо менять на разделе.

1. Размонтируйте раздел и прогоните fsck в режиме dry-run, не внося изменений:

   umount /dev/sdXN
   fsck.ext4 -n /dev/sdXN

Флаг -n покажет, что fsck собирается исправить, но ничего не тронет — так видно масштаб повреждений заранее.

1. Если масштаб приемлем и бэкап на месте — запускайте fsck по-настоящему: fsck.ext4 -y /dev/sdXN (флаг -y отвечает «да» на все вопросы). Для XFS: xfs_repair /dev/sdXN — команда работает только на размонтированном разделе, не в ro.
2. После успешного fsck смонтируйте раздел обратно в rw и проверьте целостность данных на уровне приложений — открывается ли база, не побиты ли файлы, которые как раз писались в момент сбоя:

   mount -o remount,rw /dev/sdXN /mnt/point

Если fsck находит серьёзные повреждения — множество orphaned inode, битые директории — и свежего бэкапа нет, иногда разумнее не гнаться за восстановлением «на месте», а поднять сервисы на чистом разделе из последней резервной копии, а старый раздел сохранить как есть для восстановления отдельных файлов через photorec или аналогичные инструменты. Медленнее, но предсказуемее, чем агрессивный fsck на разделе с непонятным масштабом повреждений.

Что сделать, чтобы не оказаться здесь снова

Read-only обычно не бывает совсем без предупреждения — просто предупреждения раньше никто не читал:

• Мониторинг SMART с оповещением — рост Reallocated_Sector_Ct или Current_Pending_Sector виден за недели до отказа. Простой вариант — smartd с уведомлениями по почте или в мессенджер.
• Регулярные автоматические бэкапы, а не «по случаю» — тогда аварийное восстановление сводится к развёртыванию новой машины, а не к спасению повреждённого раздела под давлением времени.
• Алерт на ключевые слова в dmesg/journalctl (I/O error, EXT4-fs error, remount-ro) — единичные ошибки часто появляются за дни до полного ухода в read-only.
• Готовая точка восстановления для важных сервисов — снапшот у провайдера или образ системы, чтобы разворачивание на новом сервере занимало минуты.
• Не отключайте журналирование ФС ради скорости — именно журнал (data=ordered/data=journal в ext4) позволяет ФС аккуратно уйти в защиту вместо тихого повреждения данных.

Частые вопросы