Debian 13: Файлова система змонтована лише для читання після помилок — кроки відновлення з мінімальною шкодою

October 7, 2025 • February 3, 2026 • Читання: 8 хв • Views: 12

Було корисно?

За мить служба працює нормально. Наступної миті вона не може записати PID-файли, логи перестають оновлюватися, а pipeline деплою починає кричати про «Read-only file system». Ядро не стало романтиком за ніч; воно захищає ваші дані, відмовляючись робити ситуацію гіршою.

Цей посібник — що робити далі в Debian 13, коли файлова система переходить у режим тільки для читання після помилок. Не «запусти fsck і молись» з байок. Реальні кроки для мінімізації шкоди: швидко діагностувати режим відмови, зберегти докази, вибрати найменш руйнівний шлях відновлення і лише потім повертати записи в продакшн.

Що насправді означає «змонтовано лише для читання» (і чого це не гарантує)

У Debian 13 (і в Linux загалом) файлова система, що перейшла в режим тільки для читання, зазвичай означає, що ядро або драйвер файлової системи вирішили: подальші записи ризикують перетворити відновлювану проблему на постійну втрату. Уявіть це як автоматичний вимикач, що захищає цілісність метаданих.

Два поширені шляхи потрапляння сюди

Автоматичне перемонтування в read-only: файлова система змонтована в rw, виникла серйозна помилка, і ядро перемонтувало її в ro (ext4 часто це робить). У логах ви побачите повідомлення на кшталт «Remounting filesystem read-only» або «Aborting journal.»
Змонтовано в read-only з самого початку: проблеми під час завантаження, явний параметр mount ro, systemd emergency mode або логіка initramfs вирішили, що безпечніше залишити її в режимі тільки для читання до ремонту.

Чого це не гарантує

Read-only не означає «дані в безпеці». Це означає «ми припинили погіршувати ситуацію». Якщо фізичний диск помирає або ваш RAID деградований і все ще корумпує дані при читанні, ви цілком можете втратити більше даних просто від активного читання (timeout-и, скиди контролера, баги прошивки тощо).

Також: змонтована в read-only файлова система не зупиняє всі зміни стану. Деякі підсистеми можуть і далі оновлювати щось поза файловою системою (кеші запису пристрою, метадані RAID, таблиці прошивки диска). Тому підхід: зберігайте докази, мінімізуйте записи і робіть свідомі кроки.

Факти та історія: чому Linux так робить

Трохи контексту допоможе приймати кращі рішення опів на третю. Ось короткі конкретні факти, що пояснюють, чому ваш Debian поводиться «надто обережно».

ext2 не мав журналювання. Колись втрата живлення означала довгі прогони fsck і ймовірну втрату метаданих. Журнальні файлові системи (ext3/ext4) зменшили це, але додали поняття «abort journal».
ext3 зробив журналювання мейнстрімом на Linux. ext3 (початок 2000-х) ввів журналювання в лінійку ext; ext4 пізніше покращив розподіл та масштабованість, але зберіг клапан безпеки «abort journal → remount ro».
XFS народився в середовищі високого класу UNIX. XFS походить з SGI і має суворе ставлення до цілісності метаданих. При виявленні корупції він часто вимикається, щоб зупинити подальшу шкоду.
Btrfs ставить контрольні суми на перший план. Він може виявляти тиху корупцію даних через контрольні суми і при наявності надмірності — самовідновлюватися. Без надмірності контрольні суми лише кажуть вам, що ви маєте проблему.
VFS ядра намагається зберегти систему живою. Перемонтування однієї файлової системи в read-only часто менш руйнівне, ніж паніка ядра чи жорстке падіння вузла.
Кеші запису дисків можуть «бреши». Диск може підтвердити запис до того, як дані безпечно потрапили на стабільне сховище. Втрата живлення плюс поведінка кешу — класичний рецепт проблем з журналом.
RAID-контролери можуть «допомагати» шкідливими способами. Деяка прошивка контролера повторно намагається, перенаправляє або переставляє операції, маскуючи проблеми, поки файлова система не вийде на непослідовні результати.
«errors=remount-ro» — політика, а не доля. Для ext4 опція mount errors=remount-ro вказує ядру, що робити при певних помилках. Можна обрати panic або continue, але «continue» — це спосіб отримати творчу корупцію.

Одна цитата, щоб руки не трусились: Надія — це не стратегія. (парафразована ідея, часто цитована в операційних колах)

Швидка діагностика (перший/другий/третій)

Це послідовність «перестаньте гадати». Мета — визначити, на якому рівні відмова: метадані файлової системи, блочний пристрій, RAID/LVM або щось вище, наприклад відсутність місця, яка була помилково сприйнята як корупція.

Перший: підтвердіть масштаб і вплив (30–90 секунд)

Це лише один монтувальний пункт чи кілька?
Чи зачіпає це кореневу файлову систему або тільки том із даними?
Додатки падають тому, що не можуть писати, чи через те, що пристрій таймаутиться?

Другий: прочитайте історію ядра (2–5 хвилин)

Шукайте I/O error, Buffer I/O error, EXT4-fs error, XFS (dm-*) forced shutdown, NVMe resets, SCSI sense data.
Визначте, чи це відмова носія (апаратна) або помилка метаданих/послідовності (рівень файлової системи).

Третій: вирішіть, чи можна залишатися онлайн, чи треба зупинити записи негайно

Якщо ви бачите повторювані скиди контролера, помилки medium або деградацію RAID: пріоритет — зняття образу/резервного копіювання і мінімізація читань/записів.
Якщо це чистий abort журналу після некоректного вимкнення і диск виглядає здоровим: можна планувати контрольоване вікно ремонту.

Правило: Якщо ви ще не знаєте, чи стабільний блочний пристрій, не запускайте руйнівні інструменти ремонту. «Ремонт» на диск, що відмовляє, часто швидко перетворює часткові дані на фарш.

Стабілізація пацієнта: зупинити «кровотечу» без паніки

Коли файлова система в read-only, спокуса — перемонтувати її в read-write і продовжити. Це чудовий спосіб дізнатися, як пахне корупція. Вам треба робити протилежне: зменшити число змінних.

Пріоритети стабілізації

Зібрати докази: журнали ядра, стан монтування, статус RAID/LVM, здоров’я SMART/NVMe.
Зупинити непотрібні записи: зупинити галасливі сервіси, вимкнути лог-спам, уникати «скриптів очищення», що б’ють по диску.
Визначити безпечну межу снапшоту/бекапу: снапшот LVM, снапшот VM, снапшот масиву зберігання або хоча б файлове копіювання критичних станів.
Тільки потім ремонтувати: вибрати правильний інструмент для вашої файлової системи та сценарію.

Жарт №1: Файлова система стала read-only, бо любить ваші дані більше, ніж вашу доступність. Це єдина підсистема на сервері з корисними межами.

Практичні завдання (команди, значення виводу, рішення)

Нижче — практичні завдання, які можна виконати в Debian 13. Кожне містить: команду, що зазвичай означає її вивід, і рішення, яке потрібно ухвалити. Використовуйте їх як чеклист інциденту, а не як шведський стіл.

Завдання 1: Перевірити, що саме змонтовано в read-only

cr0x@server:~$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | sed -n '1,5p'
TARGET SOURCE        FSTYPE OPTIONS
/      /dev/sda2     ext4   rw,relatime,errors=remount-ro
/var   /dev/vg0/var  xfs    ro,relatime,attr2,inode64,logbufs=8,logbsize=32k
/home  /dev/sdb1     ext4   rw,relatime

Що це означає: /var наразі змонтований як ro. Root все ще rw, але має errors=remount-ro, тому може теж переключитися.

Рішення: Оцініть радіус ураження. Якщо лише даний том — можна тримати систему в роботі під час триажу. Якщо root — готуйтеся до режиму обслуговування.

Завдання 2: Підтвердити, що ядро перемонтувало в read-only (і чому)

cr0x@server:~$ journalctl -k -b --no-pager | tail -n 40
Dec 29 02:11:06 server kernel: XFS (dm-2): metadata I/O error in "xlog_iodone" at daddr 0x1a2c8 len 16 error 5
Dec 29 02:11:06 server kernel: XFS (dm-2): Log I/O Error Detected. Shutting down filesystem
Dec 29 02:11:06 server kernel: XFS (dm-2): Please unmount the filesystem and rectify the problem(s)
Dec 29 02:11:06 server kernel: XFS (dm-2): Corruption of in-memory data detected. Shutting down filesystem
Dec 29 02:11:07 server kernel: XFS (dm-2): Filesystem has been shut down due to log error (0x2).
Dec 29 02:11:07 server kernel: systemd-journald[301]: Failed to write entry (22 items, 812 bytes), ignoring: Read-only file system

Що це означає: XFS зафіксував помилку Log I/O. Це часто не означає «XFS зламався», а «блочний шар не доставив узгоджені читання/записи». Помилка 5 — це EIO.

Рішення: Спочатку трактуйте як можливу нестабільність сховища. Не поспішайте запускати xfs_repair, поки не перевірите підлеглі пристрої.

Завдання 3: Перевірити очевидні помилки пристрою і скиди

cr0x@server:~$ dmesg -T | egrep -i 'blk_update_request|I/O error|reset|nvme|medium error|critical medium|sense key' | tail -n 30
[Sun Dec 29 02:10:58 2025] nvme nvme0: I/O 112 QID 4 timeout, aborting
[Sun Dec 29 02:10:58 2025] nvme nvme0: Abort status: 0x371
[Sun Dec 29 02:10:59 2025] nvme nvme0: Resetting controller
[Sun Dec 29 02:11:06 2025] blk_update_request: I/O error, dev dm-2, sector 171720 write
[Sun Dec 29 02:11:06 2025] XFS (dm-2): Log I/O Error Detected. Shutting down filesystem

Що це означає: NVMe таймаути й скиди контролера корелюють із відключенням файлової системи.

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

Завдання 4: Відобразити уражений монтувальний пункт на реальний стек блочних пристроїв

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,PKNAME
NAME           TYPE  SIZE FSTYPE MOUNTPOINTS PKNAME
sda            disk  1.8T                    -
sda2           part  1.8T ext4   /           sda
nvme0n1        disk  1.9T                    -
nvme0n1p1      part    1G vfat   /boot/efi   nvme0n1
nvme0n1p2      part  1.9T LVM2_member        nvme0n1
vg0-var        lvm   800G xfs    /var        -
vg0-data       lvm  1000G ext4   /data       -

Що це означає: /var — це XFS на LVM LV, який підкріплений nvme0n1p2. Помилки диска вище до цього стосуються.

Рішення: Ваш план ремонту має включати перевірку здоров’я NVMe і, можливо, переміщення даних з цього пристрою.

Завдання 5: Перевірити стан LVM і чи можна безпечно зробити снапшот

cr0x@server:~$ vgs; lvs -a -o +devices
  VG  #PV #LV #SN Attr   VSize VFree
  vg0   1   2   0 wz--n- 1.90t 120.00g
  LV   VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  var  vg0 -wi-ao---- 800.00g                                                     /dev/nvme0n1p2(0)
  data vg0 -wi-ao---- 1000.00g                                                    /dev/nvme0n1p2(204800)

Що це означає: У VG є 120G вільного місця — потенційно для снапшота, але снапшоти не чарівні: на ненадійному пристрої CoW-навантаження може погіршити ситуацію.

Рішення: Якщо пристрій стабільний і потрібна точка відкату — зробіть снапшот. Якщо диск таймаутиться — пропустіть снапшоти і робіть зовнішній бекап/образ.

Завдання 6: Перевірити здоров’я NVMe (для NVMe-пристроїв)

cr0x@server:~$ nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x01
temperature                         : 49 C
available_spare                     : 96%
percentage_used                     : 21%
media_errors                        : 12
num_err_log_entries                 : 187
warning_temp_time                   : 0
critical_comp_time                  : 0

Що це означає: critical_warning 0x01 — не добре, а media_errors — це явний індикатор. Контролер визнає помилки на рівні NAND/носія.

Рішення: Трактуйте це як неминучу відмову пристрою. Пріоритет — копіювання даних. Ремонти можуть «працювати» і залишити вам бомбу уповільненої дії.

Завдання 7: Перевірити SMART (для SATA/SAS-пристроїв)

cr0x@server:~$ smartctl -a /dev/sda | egrep -i 'SMART overall|Reallocated_Sector|Current_Pending_Sector|Offline_Uncorrectable|CRC_Error_Count'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Що це означає: «PASSED» — не гарантія. Pending/uncorrectable сектори вказують, що диск не зміг надійно прочитати дані і ще не перемапував їх.

Рішення: Якщо уражена файлова система на цьому диску — плануйте заміну та міграцію даних. Якщо ні — тримайте під пильним наглядом.

Завдання 8: Підтвердити вільне місце та виснаження інодів (так, це може каскадувати)

cr0x@server:~$ df -hT /var; df -i /var
Filesystem          Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg0-var xfs   800G  799G  1.2G 100% /var
Filesystem          Inodes  IUsed   IFree IUse% Mounted on
/dev/mapper/vg0-var       0      0       0     - /var

Що це означає: XFS не звітує про кількість інодів так, як ext4, але ключове — використання 100%. Повні файлові системи провокують дивну поведінку додатків і можуть виявляти приховані баги, але зазвичай самі по собі не змушують перемонтуватися в read-only.

Рішення: Якщо повна — потрібно звільнити місце після стабілізації пристрою і підтвердження, що це не сцена I/O-помилок. Не видаляйте випадкові файли на потенційно корумпованій файловій системі, поки не вирішите, що безпечно писати.

Завдання 9: Перевірити деградацію RAID (mdadm)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid10]
md0 : active raid1 sdb1[0] sdc1[1]
      976630336 blocks super 1.2 [2/2] [UU]

md1 : active raid10 sdd1[0] sde1[1] sdf1[2] sdg1[3]
      3906885632 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
      [>....................]  recovery =  5.1% (100000000/1953442816) finish=240.0min speed=120000K/sec

Що це означає: md1 деградований ([4/3]). Проводиться відновлення, що створює велике I/O-навантаження і може посилити приховані проблеми на дисках.

Рішення: Розгляньте паузу для відновлення, якщо воно погіршує ситуацію і вам потрібно вивести дані. Це залежить від обставин; не припиняйте відновлення, якщо ви в одному кроці від повної втрати.

Завдання 10: Перевірити погляд systemd (чи завантажилися в emergency через fsck?)

cr0x@server:~$ systemctl --failed
  UNIT                      LOAD   ACTIVE SUB    DESCRIPTION
● systemd-fsck@dev-disk-by\x2duuid-1a2b.service loaded failed failed File System Check on /dev/disk/by-uuid/1a2b
● var.mount                 loaded failed failed /var

Що це означає: Юніт fsck під час завантаження завершився невдало, і монтування не вдалося. Debian може впасти в emergency mode або продовжити з частковими монтуваннями залежно від конфігурації.

Рішення: Не перезавантажуйтеся в надії, що «само виправиться». З’ясуйте, чому fsck не пройшов: неправильний пристрій, відсутній драйвер, реальна корупція або помираючий диск.

Завдання 11: Визначити процеси, що все ще намагаються писати (і зазнають невдачі)

cr0x@server:~$ journalctl -b --no-pager | egrep -i 'Read-only file system|EROFS' | tail -n 20
Dec 29 02:11:07 server systemd[1]: Failed to start Rotate log files.
Dec 29 02:11:08 server nginx[1337]: open() "/var/log/nginx/access.log" failed (30: Read-only file system)
Dec 29 02:11:09 server postgres[2020]: could not write lock file "postmaster.pid": Read-only file system

Що це означає: Ваші додатки намагаються інтенсивно писати. Це додає шуму і плутанини (повторні спроби, таймаути, каскадні відмови).

Рішення: Коректно зупиніть високонавантажені сервіси. Найкращий ремонт відбувається на тихій системі.

Завдання 12: Якщо ext4: оглянути стан файлової системи без запису

cr0x@server:~$ tune2fs -l /dev/sda2 | egrep -i 'Filesystem state|Errors behavior|Last mount time|Last checked|Mount count'
Filesystem state:         clean with errors
Errors behavior:          Remount read-only
Last mount time:          Sun Dec 29 02:05:10 2025
Last checked:             Wed Nov  6 10:12:44 2025
Mount count:              31
Maximum mount count:      -1

Що це означає: ext4 вважає стан «clean with errors», що по суті означає «журнал каже зупинитися».

Рішення: Плануйте офлайн fsck (відмонтована файлова система). Якщо диск виглядає ненадійним, зніміть образ спочатку.

Завдання 13: Якщо XFS: перевірити, чи потрібно відтворення журналу (перевірка тільки для читання)

cr0x@server:~$ xfs_repair -n /dev/mapper/vg0-var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed.
Mount the filesystem to replay the log, and unmount it before re-running xfs_repair.

Що це означає: XFS виявив незавершені транзакції в журналі. Зазвичай монтування відтворює журнал. Але якщо I/O журналу був проблемою, відтворення може не вдались або знову викликати відключення.

Рішення: Якщо пристрій зараз стабільний, можна спробувати змонтувати (можливо read-only) для відтворення журналу. Якщо нестабільний — спочатку бекап/образ, потім вже xfs_repair, розуміючи, що при форсуванні він може викинути зміни журналу.

Завдання 14: Якщо Btrfs: перевірка read-only і статус scrub

cr0x@server:~$ btrfs device stats /data
[/dev/sdb1].write_io_errs    0
[/dev/sdb1].read_io_errs     3
[/dev/sdb1].flush_io_errs    0
[/dev/sdb1].corruption_errs  1
[/dev/sdb1].generation_errs  0

Що це означає: Btrfs фіксує помилки читання і корупцію. При наявності надмірності (RAID1/10) він може самостійно вилікуватися; без надмірності контрольні суми лише повідомляють про проблему.

Рішення: Якщо є надмірність — запустіть scrub і замініть пошкоджений пристрій. Якщо немає — відновлюйте з бекапу або копіюйте те, що можна, потім створюйте файлову систему заново.

Завдання 15: Зробити безпечний мінімальний обхід для writable логів (tmpfs)

cr0x@server:~$ mount -t tmpfs -o mode=0755,size=512M tmpfs /mnt/tmp-logs
cr0x@server:~$ systemctl stop nginx postgresql
cr0x@server:~$ ln -sfn /mnt/tmp-logs /var/log

Що це означає: Ви перенаправляєте логи в RAM, щоб вузол міг тимчасово працювати для діагностики без записів на підозрілу файлову систему. Це пластир, не лікування.

Рішення: Використовуйте лише якщо треба підтримати мінімальні сервіси короткий час. Краще віддати трафік на інший вузол, якщо він є.

Завдання 16: Зробити форензійний знімок логів і стану (низький ризик)

cr0x@server:~$ mkdir -p /root/ro-incident
cr0x@server:~$ journalctl -b --no-pager > /root/ro-incident/journal.txt
cr0x@server:~$ findmnt -a > /root/ro-incident/findmnt.txt
cr0x@server:~$ lsblk -f > /root/ro-incident/lsblk.txt

Що це означає: Ви зберегли історію, поки вона свіжа. Якщо наступний reboot змінить імена пристроїв або машина не підніметься — у вас лишаться підказки.

Рішення: Якщо сховище нестабільне — скопіюйте цей каталог за межі хоста (scp на бастіон, додайте до тікета тощо).

Стратегії ремонту за типом файлової системи (ext4, XFS, Btrfs)

Різні файлові системи поводяться по-різному при відмовах. Неправильний підхід до ремонту перетворює керований інцидент у багатоденне відновлення. Ваш основний принцип: ремонтуйте офлайн, коли це можливо, і ніколи не ремонтуйте на пристрої, якому ви не довіряєте.

ext4: abort журналу і «errors=remount-ro»

ext4 зазвичай перемонтовує в read-only після виявлення помилки, достатньо серйозної, щоб abort журналу. Часто це викликають I/O помилки, іноді бага, інколи диск повернув «сміття». ext4 — обережна. Слухайте її.

Переважний шлях для ext4

Підтвердьте стабільність стеку пристроїв (SMART/NVMe, dmesg, статус RAID).
Заплануйте простій або завантаження в rescue mode, щоб ціля файлова система була відмонтована.
Спочатку запустіть недеструктивну перевірку (fsck без автоматичних виправлень, якщо хочете бачити, що зміниться).
Запустіть ремонт і перевірте ще раз.

cr0x@server:~$ umount /dev/sda2
umount: /: target is busy.

Значення: Ви не можете відмонтвати root під час роботи. Використайте rescue boot, initramfs shell або приєднайте том до іншого хоста.

cr0x@server:~$ fsck.ext4 -f -n /dev/sda2
e2fsck 1.47.2 (1-Jan-2025)
/dev/sda2: clean, 812345/122101760 files, 44444444/488378368 blocks

Значення: «clean» — хороший сигнал. Якщо в режимі -n повідомляє про помилки, маєте вибір: ремонтувати негайно або зробити образ, якщо апарат підозрілий.

cr0x@server:~$ fsck.ext4 -f -y /dev/sda2
e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Inode 1234567 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
Entry 'tmp' in /var/tmp (98765) has deleted/unused inode 1234567.  Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****

Значення: Сталася корекція. Тепер треба запустити fsck вдруге, поки він не повідомить про чистоту, бо перший прогін може виявити більше проблем.

Рішення: Якщо кожен раз знаходить нові проблеми — припиніть і перегляньте апаратну частину. На стабільному носії файлові системи зазвичай не «генерують» нескінченну кількість помилок.

XFS: примусове вимкнення і проблеми журналу

XFS не робить fsck під час монтування так, як ext-файлові системи. Його журнал (log) є критичним, і XFS нетерпимий до проблем з I/O журналу. Це добре для коректності, але дратує для доступності.

Переважний шлях для XFS

Спочатку виправте шлях до сховища: кабелі, скиди контролера, проблемний NVMe, деградований RAID, ненадійний multipath.
Спробуйте коректне відмонтовання. Якщо він зайнятий і вже вимкнений — зупиніть сервіси і відмонтовать.
Спробуйте змонтувати, щоб відтворити журнал (якщо безпечно). Якщо монтування не вдається — переходьте до ремонту.
Запустіть xfs_repair. Розглядайте log-zeroing лише як останній засіб.

cr0x@server:~$ fuser -vm /var
                     USER        PID ACCESS COMMAND
/var:                root      1022 f....  rsyslogd
                     postgres   2020 f....  postgres
                     root      1337 f....  nginx

Значення: Ці процеси тримають монтування зайнятим.

Рішення: Зупиніть їх. Якщо не можете — ви не робите «ремонт», ви займаєтеся «непланованими дослідами корупції».

cr0x@server:~$ systemctl stop rsyslog nginx postgresql
cr0x@server:~$ umount /var
cr0x@server:~$ xfs_repair /dev/mapper/vg0-var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
Phase 3 - for each AG...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify and correct link counts...
done

Значення: Ремонт пройшов успішно. Це не означає, що сховище здорове. Це означає, що XFS збудував узгоджені метадані з того, що має.

Рішення: Перемонтуйте і перевірте дані додатків. Якщо I/O-помилки залишаються — мігруйте негайно.

Про xfs_repair -L: Він може очистити журнал («zero log»). Це може відкинути недавні зміни метаданих. Це може бути прийнятно для кеш-томів; катастрофічно для баз даних. Використовуйте лише коли готові прийняти втрату даних заради монтування.

Btrfs: read-only режим, контрольні суми, scrub і правило «не запускати repair легковажно»

Btrfs потужний, але має гострі кути. Найбільший операційний нюанс: btrfs check --repair — не рутина. У багатьох випадках перевага: змонтувати тільки для читання, скопіювати дані, відтворити.

Переважний шлях для Btrfs

Змонтруйте як read-only, якщо ще не змонтовано.
Якщо є надмірність — запустіть scrub для лікування.
Замініть погані пристрої, потім знову scrub.
Якщо немає надмірності і є корупція: копіюйте критичні дані й відтворюйте файлову систему.

cr0x@server:~$ mount -o ro,subvolid=5 /dev/sdb1 /mnt
cr0x@server:~$ btrfs scrub start -Bd /mnt
scrub started on /mnt, fsid 1b2c3d4e-....
Starting scrub on devid 1
Scrub device /dev/sdb1 (id 1) done
Scrub started:    Sun Dec 29 02:20:01 2025
Status:           finished
Duration:         0:10:12
Total to scrub:   900.00GiB
Error summary:    read=3, csum=1, verify=0, super=0, malloc=0, uncorrectable=1

Значення: Є щонайменше одна невиправна помилка. Без дзеркального копіювання Btrfs не може відновити відсутню істину.

Рішення: Якщо том важливий — відновіть з бекапу або копіюйте те, що можна, і перевідтворіть. Продовжувати роботу — повільний інцидент.

Коли це не файлова система: сховище, RAID і причини на рівні ядра

Файлові системи отримують звинувачення, бо вони — месенджери. Насправді «read-only після помилок» часто є відмовою блочного шару: таймаути, скиди, medium errors або некоректні віртуальні пристрої.

Моделі відмов, що маскуються під корупцію файлової системи

Проблеми прошивки/контролера NVMe: періодичні скиди під навантаженням, баги APST/power state, термальне дроселювання що призводить до таймаутів.
Проблеми SATA/SAS лінку: CRC помилки, ненадійні кабелі/бекплейни, дивна поведінка expander-ів. CRC помилки — подарунок: вони голосно кричать «проблема транспорту».
Навантаження під час rebuild RAID: rebuild посилює читання; слабкі диски відмовляють під час rebuild; файлова система отримує часткові читання і «панікує».
Thin-provisioned LVM снапшоти: снапшот заповнюється, пристрій повертає I/O помилки, файлові системи захищають метадані.
Глюки віртуалізованого сховища: iSCSI path flaps, NFS server stalls, латентність на гіпервізорі. Гість бачить EIO; файлова система здається і переходить в read-only.

Коротке, упереджене правило

Якщо ви бачите EIO в dmesg — припускайте апаратне, поки не доведено протилежне. Файлові системи не вигадують EIO заради розваги.
Якщо бачите одну чисту потребу відтворення журналу після відключення живлення — припускайте софт, поки не перевірите SMART/NVMe. Це дешева страховка.
Якщо пристрій нестабільний — ваш «ремонт» має починатися з копіювання даних. Інструменти ремонту не є інструментами бекапу.

Три корпоративні історії з практики

Міні-історія 1: Інцидент, викликаний неправильною припущенням

У них була невелика група Debian-серверів з write-heavy аналітичним pipeline. Один вузол почав раз на тиждень перемонтовувати /var в read-only. Дірекція on-call завжди робила одне й те саме: перезавантаження, все піднімалося, і всі забували.

Припущення було просте: «це просто ext4 бурчить після некоректного вимкнення». Був раніше подія відключення живлення місяць тому, і ця історія закріпилась. Людям подобається акуратний наратив, особливо коли він зручний.

Під час завантаженого тижня той же вузол перемкнувся в read-only під час інгесту. Цього разу це вимкнуло pipeline жорстко: система не могла писати спул-файли, і повторні спроби все погіршували. Хтось зробив те, що люди роблять під тиском: перемонтував у rw, щоб «пройти ніч». Це працювало годину, потім файлова система перестала монтуватися зовсім.

Постмортем був нудним і болючим. Насправді корінь проблеми — інтермітентні скиди контролера NVMe при високій черзі запитів. Лог здоров’я диска показував media errors тижнями, але ніхто не дивився, бо «SMART завжди каже PASSED».

Що змінило практику — не якийсь дорогий інструмент, а маленький чекліст: якщо бачите read-only remount, завжди перевіряйте помилки пристрою і метрики здоров’я перед тим, як чіпати ремонт файлової системи. Вони перестали вважати ядро драматичним. Час простою впав; дивно, що зменшилась і втрата даних.

Міні-історія 2: Оптимізація, що зіграла злий жарт

Інша команда хотіла швидкі «межі ремонту» для своїх станкових сервісів і сильно покладалася на LVM снапшоти. Ідея була елегантна: зробити снапшот LV, виконувати ризикові операції, відкотитися за потреби. У staging це працювало чудово.

Потім у проді сталась тимчасова проблема зі сховищем. Файлова система почала кидати помилки і перемонтувалась в read-only. On-call виконав runbook: «створи снапшот перед ремонтом». Снапшот створився, але вільного простору було мало.

Коли файлова система вже була в стані збудженості, CoW-усилля снапшоту посилили роботу диска. Записи накопичувались, латентність зросла, снапшот швидко заповнився. Коли він заповнився, тонкий снапшот перетворив майбутні записи на помилки блочного шару.

Команда отримала двошарову проблему: початкова помилка файлової системи плюс зміна поведінки блоку через заповнення снапшоту. Додатки бачили EIO і падали так, ніби це корупція даних. Їхній «механізм безпеки» став множником відмов.

Виправлення не було «ніколи не робити снапшоти». Воно полягало в «робити снапшот навмисно». Вони додали мінімальні вимоги вільного простору, моніторинг і правило: якщо диск вже нестабільний — не ускладнюй CoW. Робіть зовнішній образ або переключайтесь.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Велика організація запускала Debian вузли в транзакційній системі. Нічого екзотичного: більшість томів на ext4, XFS для великих логів. SRE усміхливо наполягали на двох речах: заплановані перевірки файлових систем у вікнах обслуговування і треновані відновлення.

Одного ранку оновлення ядра плюс невдале відключення живлення змусили частину вузлів завантажитись з позначками dirty. На двох вузлах ext4 abort журналу і перемонтував root в read-only під час раннього етапу завантаження. Інстинкт команд застосунків — «просто перемонтуй в rw».

SRE on-call не робив героїки. Він слідував нудному плану: завантажив у rescue mode, запустив fsck офлайн, перевірив монтування, потім піднімав сервіси в контрольованому порядку. Тим часом вони переключили трафік на здорові вузли.

Оскільки бекапи і відновлення були відрепетировані, вони також знали «аварійну двері»: якщо fsck викликає підозри або здоров’я диска сумнівне, стерти і відновити з бекапу краще, ніж імпровізувати. Цей варіант змінює психологію реагування: ви менше ризикуєте.

Вони повернулися в межі свого SLA, а пост-інцидентна зустріч була майже приємно спокійною. Урок не в «ми генії». Він у «нудна операційна гігієна перетворює драму в чеклист».

Поширені помилки: симптом → корінь проблеми → виправлення

Цей розділ навмисно конкретний. Вам не потрібна більше загальна порада. Вам потрібне коректне патерн-матчинг.

1) Симптом: «Remounting filesystem read-only» після сплеску записів

Корінь: abort журналу ext4 через підлеглі I/O помилки або таймаути; іноді викликано ненадійним шляхом сховища.

Виправлення: Перевірте dmesg/journal на EIO і скиди пристрою. Запустіть перевірки SMART/NVMe. Якщо апарат виглядає чистим — зробіть offline fsck. Якщо ні — зніміть образ/мігруйте спочатку.

2) Симптом: XFS показує «Log I/O Error Detected. Shutting down filesystem»

Корінь: Сховище ненадійно завершує записи/читання журналу. Може бути відмова пристрою, скиди контролера або проблеми шару dm.

Виправлення: Стабілізуйте апаратний шлях (замініть пристрій, виправте multipath, призупиніть rebuild при потребі). Потім відмонтруйте і запустіть xfs_repair. Уникайте -L, якщо не готові втратити недавні метадані.

3) Симптом: Btrfs переходить в read-only і scrub показує «uncorrectable»

Корінь: Виявлена корупція без дзеркальних копій для лікування (або забагато відмов).

Виправлення: Копіюйте те, що можна, відновлюйте з бекапу, перебудуйте файлову систему. Якщо є надмірність — замініть поганий пристрій і повторіть scrub.

4) Симптом: система завантажується в emergency mode; mount-юнити провалені

Корінь: fsck не пройшов, пристрій відсутній, неправильний UUID або реальна корупція. Іноді це викликано перейменуванням пристрою при зміні RAID/HBA.

Виправлення: Використовуйте systemctl --failed і journalctl -xb. Перевірте UUID в /etc/fstab через blkid. Ремонтуйте офлайн. Не перезавантажуйтеся в петлі.

5) Симптом: файлова система read-only, але диск «виглядає в порядку» і EIO немає

Корінь: Опції монтування (явний ro), логіка systemd remount, або попередній прапорець помилки, що не був очищений.

Виправлення: Перевірте findmnt опції, /etc/fstab і tune2fs -l для стану ext4. Якщо файлова система вважає, що є помилки — робіть offline fsck, навіть якщо пристрій здається стабільним.

6) Симптом: після «успішного» fsck файлова система швидко знову стає read-only

Корінь: Підлеглий пристрій все ще кидає помилки; fsck лікував симптом, а не хворобу.

Виправлення: Перепровірте SMART/NVMe і логи ядра після ремонту. Замініть підозрілі носії. Перевірте кабелю/бекплейн. Якщо віртуалізовано — дивіться латентність хоста та стабільність шляхів.

7) Симптом: існує тонкий LVM снапшот; раптом з’являються I/O помилки і FS вимикається

Корінь: Снапшот або thin pool вичерпався; dm шар повертає помилки; файлова система захищається.

Виправлення: Перевірте Data%/Meta% в lvs. Розширте thin pool або видаліть снапшот. Потім ремонтуйте файл систему за потреби. Додайте моніторинг і пороги.

Контрольні списки / покроковий план

Чеклист A: Коли вперше бачите «Read-only file system» у продакшні

Зупиніть нові записи: спустіть трафік, призупиніть пакетні джоби, зупиніть гучні сервіси.
Зареєструйте стан: збережіть журнали ядра, опції монтування, топологію пристроїв (journalctl, findmnt, lsblk).
Підтвердьте масштаб: які монтування ro і які додатки від них залежать.
Перевірте здоров’я пристрою: SMART/NVMe, dmesg на скиди/таймаути, статус RAID.
Визначте межу безпеки: снапшот якщо стабільно, бекап/образ якщо нестабільно.

Чеклист B: Контрольований план ремонту (мінімізувати шкоду)

Перейдіть в офлайн-середовище: rescue boot, initramfs shell або приєднайте том до іншого хоста.
Підтвердіть, що ремонтуєте правильний пристрій: зіставте mount → LV → PV → диск. Підтвердіть UUID.
Запустіть перевірку тільки для читання, де підтримується (fsck -n, xfs_repair -n).
Запустіть ремонт відповідним інструментом (fsck.ext4, xfs_repair).
Повторіть перевірку, поки не буде чисто.
Змонтуйте спочатку в read-only і перевірте ключові дані (файли БД, конфіг, стан додатків).
Змонтуйте в read-write, запускайте сервіси в порядку, слідкуйте за логами на предмет нових I/O помилок.
Моніторинг після відновлення: лічильники помилок, латентність, статус rebuild RAID, скиди NVMe.

Чеклист C: Якщо апарат виглядає погано (план «зберегти дані, а не файлову систему»)

Зупиніть сервіси, щоб зменшити навантаження і таймаути.
Змонтруйте read-only, якщо можна, скопіюйте критичні дані першими (конфіги, дампи БД якщо безпечно, ключові директорії).
Зніміть образ блочного пристрою, якщо потрібне форензійне відновлення (і якщо є куди його покласти).
Замініть пристрій, відновіть RAID/LVM, відтворіть файлову систему.
Відновіть з бекапу або з скопійованих даних.

Жарт №2: Якщо ваш перший крок відновлення — «force remount rw», вітаю — ви винайшли новий бенчмарк знищення даних.

Запобігання, яке дійсно працює (і що — лише атмосфера)

Запобігання — це не мораль. Це набір нудних контролів, що тримають «read-only remount» як одиночний інцидент, а не повторювану проблему.

Що працює

Моніторинг здоров’я пристроїв, якому ви довіряєте: NVMe error logs, SMART-атрибути, що мають значення (pending/uncorrectable/CRC), і алерти на скиди/таймаути в логах ядра.
Гігієна RAID: моніторинг деградації, статусу rebuild і рівня помилок. Rebuild-и — час, коли слабкі диски показують себе.
Управління ємністю: повні файлові системи рідко самі по собі викликають read-only, але вони провокують помилки операторів і thrash додатків під час інцидентів.
Бекапи, які реально відновлюються: регулярно тестуйте restores. Можливість чистого відтворення — найкращий антидот для ризикових «ремонтів».
Вікна обслуговування для перевірок файлових систем: особливо для ext, якщо ви не запускаєте періодичні перевірки за часом.
Дизайн сервісів, що враховує запис: додатки, які коректно деградують при read-only (зупиняють записи, очищають помилки), зменшують побічні втрати.

Що не працює (або працює лише на слайді)

Припущення, що журналювання означає «немає корупції». Журнал зберігає узгодженість метаданих; він не робить апарат надійним.
Покладатися на «SMART PASSED». Це груба оцінка, а не гарантія. Цікаві атрибути і логи важливіші.
Ремонтити онлайн. Деякі інструменти дозволяють це, але ризик великий. Офлайн-ремонт повільніший, але безпечніший.
Ігнорувати логи помилок сховища бо «файлова система — проблема». Так ви заміните невірний компонент і продовжите отримувати ті самі інциденти.

Питання та відповіді

1) Чому Linux перемонтовує файлову систему в read-only замість того, щоб впасти?

Тому що продовження записів після помилок метаданих може викликати каскадну корупцію. Перемонтування в read-only зберігає систему частково робочою і запобігає подальшій шкоді.

2) Чи можна просто виконати `mount -o remount,rw` і продовжити?

Можна, і іноді це «працює» тимчасово. Якщо первинна помилка була через нестабільність I/O або abort журналу — ви, ймовірно, погіршите корупцію. Перемонтуйте в rw лише після діагностики і виправлення джерела.

3) Яка найшвидша безпечна дія, коли це відбувається на сервері бази даних?

Коректно зупиніть базу даних, збережіть журнали і підтвердіть, чи шар сховища кидає помилки. Якщо диск нестабільний, пріоритет — копіювання файлів даних або відновлення з бекапу, а не акробатика з інструментами ремонту.

4) ext4 каже «clean with errors». Це не суперечливо?

Це означає, що файлова система була чисто відмонтована або виглядає узгодженою, але в ній записані помилки (часто через abort журналу або виявлені невідповідності). Трактуйте це як «потрібен fsck офлайн».

5) XFS каже змонтуватися для відтворення журналу, але монтування раніше викликало shutdown. Що робити?

Спочатку виправте шлях до сховища. Якщо не вдається зробити його стабільним, відтворення може знову не вдатися. Після стабілізації спробуйте монтування (можливо read-only) для відтворення, потім відмонтруйте і запустіть xfs_repair. xfs_repair -L використовуйте лише якщо готові втратити недавні метадані.

6) Для Btrfs чи варто запускати `btrfs check --repair`?

Не як правило. Краще scrub (якщо змонтовано) і заміна пристроїв при наявній надмірності. Якщо є невиправна корупція і немає надмірності — копіюйте дані і перебудовуйте. Використовуйте --repair лише розуміючи ризики і маючи бекапи.

7) Чи означає read-only монтування, що мій диск виходить з ладу?

Не завжди. Це може бути адекватна відповідь на некоректне вимкнення або поодинокий баг. Але повторювані read-only, повідомлення EIO, таймаути, скиди, pending сектора або NVMe media errors сильно вказують на апаратну проблему.

8) Чи треба негайно перезавантажувати, щоб «виправити»?

Ні. Перезавантаження може знищити докази і ускладнити відновлення, якщо пристрій погіршиться. Збережіть логи і оцініть стан здоров’я диска спочатку. Перезавантажуйте лише в рамках контрольованого плану ремонту.

9) Якщо тільки `/var` read-only, чи можна продовжувати обслуговувати трафік?

Можливо, коротко, залежно від того, що лежить у /var (логи, спул, БД). Якщо додатки потребують цього для стану — ви вже несправні. Якщо це здебільшого логи, можна тимчасово використати tmpfs для логів і робити фейловер/ремонт коректно.

10) Як дізнатися, чи fsck викличе втрату даних?

Будь-який інструмент ремонту може видаляти або сирітити корумповані структури. Спочатку запустіть перевірку тільки для читання (fsck -n), щоб подивитися, що потрібно змінити. Якщо пристрій підозрілий — зніміть образ спочатку, щоб мати шлях відновлення.

Висновок: наступні кроки, які можна виконати

Коли Debian 13 перемонтовує файлову систему в read-only після помилок, ядро дає вам шанс відновити чисто. Не марнуйте його, змушуючи записи і перетворюючи одиночну відмову на кримінальне розслідування.

Зробіть наступне:

Виконайте швидку діагностику: підтвердіть масштаб, прочитайте логи ядра, перевірте здоров’я сховища.
Стабілізуйте: зупиніть write-heavy сервіси і збережіть докази.
Створіть межу безпеки: снапшот тільки якщо сховище стабільне; інакше спочатку бекап/образ.
Ремонтуйте офлайн відповідним інструментом для вашої файлової системи, потім валідуйте.
Після відновлення трактуйте повторні read-only події як інцидент апаратного шляху, поки не доведено протилежне.