Debian 13 «Read-only file system»: найшвидший шлях до причини й відновлення

Все починається з малого: деплой, який «не може записати в /var», завдання logrotate, що мовчки завершується з помилкою, або установка пакета, яка зупиняється посередині. Потім ви помічаєте це: Read-only file system. У Debian 13 це не «настройка настрою». Це ядро, яке каже, що воно помітило щось настільки серйозне, що перестало довіряти вашому диску.

Ваше завдання — не просто «зробити записуваним». Ваше завдання — з’ясувати чому система вирішила, що писати небезпечно, зберегти докази та відновити систему так, щоб не перетворити відновлюваний інцидент на історію про втрату даних.

Що насправді означає «read-only file system» (і чому Debian так робить)

Коли ви бачите «Read-only file system», зазвичай це одна з трьох реальностей:

1. Файлова система змонтована в режимі лише для читання (або під час завантаження, або вона була перемонтована в ro під час роботи).
2. Блоковий пристрій відмовляється приймати запис (на рівні пристрою встановлено захист від запису, носій виходить з ладу, проблеми SAN/віртуального диска).
3. Ви фактично не пишете туди, куди думаєте (overlay/контейнери, bind-монти, права доступу або повний/тільки для читання верхній шар).

У Debian 13 з ext4 (яка досі за замовчуванням у багатьох інсталяціях) типовий «сюрприз» виглядає так: запис не вдається в спосіб, що вказує на корупцію або нестабільність I/O; ext4 вирішує, що продовження робіт ризикує призвести до більшого збитку; ядро перемонтовує файлову систему в режим лише для читання, щоб зупинити втрати. XFS має подібну поведінку «я тут не буду гратися», коли виявляє певні класи проблем.

Це не театр з боку ОС. Це ОС, яка робить найменш-невірну річ у ситуації невизначеності щодо сховища.

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

Цитата для стіни: «Hope is not a strategy.» — Gene Kranz. В реагуванні на інциденти це не мотивація; це нагадування не «просто перезавантажитись і подивитись».

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

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

Перший: підтвердьте, що саме є read-only і чи змінилось це під час роботи

• Це root-файлова система чи том даних?
• Чи є ro у прапорах монтування?
• Чи перемонтувало ядро через помилки?

Другий: проскануйте журнали ядра на рядок-тригер

• ext4: «Errors detected… remounting filesystem read-only»
• XFS: «Log I/O error» або «xfs_do_force_shutdown»
• блоковий шар: «I/O error», «timeout», «reset», «aborted command»
• пристрої: NVMe «media errors», SATA «UNC», SCSI «sense key»

Третій: вирішіть, чи маєте справу з апаратним збоєм або відновлюваною корупцією

• Якщо є повторювані I/O помилки/таймаути/цикли скидання: сприймайте це як перш за все проблему апаратури/платформи. Плануйте заміну/міграцію.
• Якщо це одиночний сплеск (втрата живлення, краш) і стан пристрою виглядає чистим: ймовірно, можна виконати fsck і продовжити роботу.

Якщо ви на виклику й вас тягне негайно перемонтувати в rw, пам’ятайте: ви не зможете «переналаштувати» помираючий NVMe контролер.

Цікаві факти і контекст (коротко, конкретно, корисно)

• Факт 1: ext4 успадкувала поведінку при помилках з епохи ext3: коли сумнівається цілісність метаданих, перемонтування в ro — це запобіжний клапан.
• Факт 2: опція монтування ext4 errors=remount-ro багато років є стандартною на багатьох дистрибутивах, бо «продовжувати писати» — це як корупція поширюється.
• Факт 3: XFS не «fsck» у традиційному сенсі; він використовує xfs_repair і може примусово відключити файлову систему при виявленні невідповідностей журналу або I/O помилок.
• Факт 4: NVMe диски відображають лічильники «Media and Data Integrity Errors»; ненульове значення не завжди означає неминучу відмову, але зростання значень — тривожний знак.
• Факт 5: Гіпервізор може представити диск як лише для читання, коли датастор переповнений, коли знімки ланцюжаться некоректно або коли виявлена проблема нижчого рівня сховища.
• Факт 6: Linux може чисто змонтувати файлову систему лише для читання під час завантаження, якщо виявив, що потрібен відновлення журналу, але не може його безпечно виконати (або відновлення журналу зазнало невдачі).
• Факт 7: LVM і dm-crypt зазвичай передають I/O помилки вище; файлова система — шар, який вирішує «я зараз стану лише для читання». Ось чому корінь проблеми часто під файловою системою.
• Факт 8: Багато інцидентів «тільки читання» спричинені таймаутами, а не корупцією: транзієнтні проблеми лінку (кабель/backplane SATA, прошивка HBA, флапи шляху SAN) можуть спричинити достатньо невдалих записів, щоб спрацював захист.
• Факт 9: Історія відновлення в Debian значно покращилася з появою systemd та стандартизації режимів emergency/rescue; тепер можна отримати shell без вгадувань runlevel.

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

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

Завдання 1: Підтвердіть прапори монтування (ro проти rw) і масштаб

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /
/ /dev/mapper/vg0-root ext4 rw,relatime,errors=remount-ro

Значення: Root наразі записуваний (rw). Якщо ви все ще бачите помилки, це може бути інший монтувальний шлях, наприклад /var або /srv, або overlay в контейнері.

Рішення: Якщо бачите ro, продовжуйте. Якщо rw, знайдіть конкретний шлях/пристрій, який є тільки для читання, за допомогою findmnt -R /path або перевірте mount контейнера/сервісу.

Завдання 2: Визначте, яка файлова система містить невдалий шлях

cr0x@server:~$ findmnt -T /var/lib/postgresql -no TARGET,SOURCE,FSTYPE,OPTIONS
/var /dev/mapper/vg0-var ext4 ro,relatime,errors=remount-ro

Значення: Це /var, а не root. Це змінює відновлення: можна відмонтувати лише /var в single-user режимі і відремонтувати його, залишивши root недоторканим.

Рішення: Визначте пристрій (/dev/mapper/vg0-var) і зосередьте діагностику там.

Завдання 3: Перевірте кільце ядра на першу помилку

cr0x@server:~$ dmesg -T | egrep -i 'EXT4-fs error|remounting filesystem read-only|I/O error|blk_update_request|Buffer I/O error|nvme|ata[0-9]|reset|timed out' | tail -n 25
[Sat Dec 28 11:04:10 2025] EXT4-fs error (device dm-2): ext4_journal_check_start:83: Detected aborted journal
[Sat Dec 28 11:04:10 2025] EXT4-fs (dm-2): Remounting filesystem read-only

Значення: ext4 відхилив журнал на dm-2 (ймовірно ваш LVM LV). Це або корупція після некоректного вимкнення, або проблеми I/O на більш нижчому рівні.

Рішення: Тепер потрібно визначити, чи аборт був спричинений I/O помилками знизу (диск, шлях, контролер), чи це одиничний краш.

Завдання 4: Порахувати журнал у часі між завантаженнями

cr0x@server:~$ journalctl -k -b -1 -g 'Remounting filesystem read-only|I/O error|nvme|ata|sd ' --no-pager | tail -n 60
Dec 28 10:12:03 server kernel: nvme nvme0: I/O 123 QID 5 timeout, aborting
Dec 28 10:12:04 server kernel: nvme nvme0: Abort status: 0x371
Dec 28 10:12:05 server kernel: EXT4-fs (dm-2): I/O error while writing superblock
Dec 28 10:12:05 server kernel: EXT4-fs (dm-2): Remounting filesystem read-only

Значення: Це не «некоректне вимкнення». Це таймаут диска. ext4 не може записати метадані і переходить у режим лише для читання.

Рішення: Сприймайте це як нестабільність зі сховищем. Плануйте міграцію/заміну. Не «fsck і забудьте».

Завдання 5: Відобразіть імена device-mapper на реальні диски

cr0x@server:~$ lsblk -o NAME,KNAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
nvme0n1     nvme0n1  disk  1.8T
├─nvme0n1p1 nvme0n1p1 part  1G  vfat   /boot/efi
└─nvme0n1p2 nvme0n1p2 part  1.8T LVM2_member
  ├─vg0-root dm-0    lvm   80G  ext4   /
  ├─vg0-var  dm-2    lvm  200G  ext4   /var
  └─vg0-home dm-3    lvm  100G  ext4   /home

Значення: Проблемна файлова система на dm-2, яка відповідає /dev/mapper/vg0-var на nvme0n1p2.

Рішення: Радіус ураження включає все на тому NVMe. Готуйтеся до інциденту повного диска, а не окремого LV.

Завдання 6: Перевірте, чи сам блоковий пристрій встановлений як тільки для читання

cr0x@server:~$ cat /sys/block/nvme0n1/ro
0

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

Рішення: Продовжуйте перевірки стану пристрою; не припускайте «апаратний замок».

Завдання 7: Знімок SMART / стан NVMe

cr0x@server:~$ smartctl -a /dev/nvme0n1 | egrep -i 'model number|firmware|critical warning|media and data integrity errors|error information log entries|percentage used|available spare|temperature'
Model Number:                       ACME NVMe 2TB
Firmware Version:                   3B2QEXM7
Critical Warning:                   0x00
Temperature:                        63 Celsius
Available Spare:                    100%
Percentage Used:                    7%
Media and Data Integrity Errors:    12
Error Information Log Entries:      57

Значення: Ненульові медіа/інтегріті помилки плюс багато записів у журналі помилок — це не «гаразд». Можливо, він працюватиме ще місяці, можливо, помре сьогодні. У будь-якому випадку — у нього є історія.

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

Завдання 8: SATA/SCSI диски: перевірте скидання лінку та погані сектори

cr0x@server:~$ dmesg -T | egrep -i 'ata[0-9].*reset|SATA link|UNC|I/O error|failed command|sense key|medium error' | tail -n 20
[Sat Dec 28 09:58:31 2025] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Sat Dec 28 09:58:33 2025] ata2.00: failed command: WRITE FPDMA QUEUED
[Sat Dec 28 09:58:33 2025] blk_update_request: I/O error, dev sdb, sector 918273645 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0

Значення: Флапи лінку + невдалі записи. Це може бути проблема носія, контролера, backplane, кабелю, живлення або просто невезіння.

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

Завдання 9: Визначте, чи файлова система вважає, що мали місце помилки (ext4)

cr0x@server:~$ tune2fs -l /dev/mapper/vg0-var | egrep -i 'Filesystem state|Errors behavior|Last error|Last mount time|Last checked'
Filesystem state:         clean with errors
Errors behavior:          Remount read-only
Last error:               ext4_journal_check_start: Detected aborted journal
Last mount time:          Sat Dec 28 10:11:57 2025
Last checked:             Tue Dec 10 02:14:18 2025

Значення: ext4 зафіксувала стан помилки. Навіть якщо ви перемонтуєте в rw, ви зараз працюєте з файловою системою, яка визнає, що мала «поганий день».

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

Завдання 10: Перевірте, чи «диск повний маскує read-only»

cr0x@server:~$ df -hT /var
Filesystem              Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg0-var     ext4  197G  197G     0 100% /var

Значення: Заповнені файлові системи зазвичай викликають «No space left on device», а не «read-only file system». Але вони можуть спричинити каскадні збої: проблеми з журналом, краші додатків і подальші небезпечні стани.

Рішення: Усе ще виправляйте тиск за простором негайно (безпечне видалення, ротація логів, переміщення кешів). Але якщо монтування ro, вам також потрібен реальний тригер із логів.

Завдання 11: Підтвердіть, чи systemd перевів вас в emergency через невдачу fsck

cr0x@server:~$ systemctl status
● server
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Sat 2025-12-28 11:07:12 UTC; 2min 13s ago

cr0x@server:~$ systemctl --failed
  UNIT          LOAD   ACTIVE SUB    DESCRIPTION
● var.mount     loaded failed failed /var

Значення: Завантаження пройшло, але mount unit завершився з помилкою. Іноді systemd опускає в emergency shell; іноді він продовжує з частковою доступністю сервісів.

Рішення: Сфокусуйтеся на неуспішному юніті та його пристрої; не женіться за випадковими помилками додатків перш за все.

Завдання 12: Спробуйте безпечне перемонтування, щоб зібрати логи (тільки якщо сховище виглядає стабільним)

cr0x@server:~$ mount -o remount,rw /var
mount: /var: cannot remount /dev/mapper/vg0-var read-write, is write-protected.

Значення: Або ядро змусило його в ro через помилки, або шар пристрою відмовляє в записах.

Рішення: Не повторюйте цю команду в циклі. Поверніться до логів і стану пристрою; розгляньте завантаження в режимі відновлення і офлайн fsck.

Завдання 13: Перевірте стан mdadm RAID (якщо застосовно)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
      976630336 blocks super 1.2 [2/1] [U_]
      bitmap: 1/8 pages [4KB], 65536KB chunk

unused devices: <none>

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

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

Завдання 14: Перевірте LVM на відсутні PV або активацію в режимі лише для читання

cr0x@server:~$ pvs -o pv_name,vg_name,pv_size,pv_free,pv_attr
  PV             VG  PSize  PFree  Attr
  /dev/nvme0n1p2  vg0 1.80t  1.42t  a--

Значення: PV присутній і активний. Якби ви бачили відсутні PV або часткову активацію, це відразу вказувало б на проблеми кабелю/шляху зберігання.

Рішення: Продовжуйте перевірки файлової системи/пристрою; LVM тут не є негайним підозрюваним.

Завдання 15: Перевірте, чи ви в overlay-ситуації контейнера

cr0x@server:~$ mount | egrep -i 'overlay|docker|containerd' | head
overlay on /var/lib/docker/overlay2/abc123/merged type overlay (ro,relatime,lowerdir=...,upperdir=...,workdir=...)

Значення: Overlay-монтування лише для читання; це може статися, якщо upperdir лежить на файловій системі, що стала ro, або якщо runtime перемонтував його через проблеми.

Рішення: Не звинувачуйте «баг Docker». Знайдіть upperdir, на якому базується overlay, і діагностуйте цей монтувальний шлях/пристрій.

Карта кореневих причин: сховище, файлові системи, блок-шар і користувацькі тригери

1) Файлова система захистила себе після реальної I/O помилки

Це найпоширеніша й найважливіша причина. ext4 та XFS не переходять у режим лише для читання від нудьги. Вони роблять це тому, що ядро повідомило про невдалий запис, або файлові системи виявили внутрішню невідповідність.

Типові рядки в журналі ядра включають:

• blk_update_request: I/O error
• Buffer I/O error
• EXT4-fs error ... Detected aborted journal
• XFS (dm-0): log I/O error

Підлягаючі причини варіюються від виходу з ладу SSD до ненадійних HBA, від нестабільності шляху SAN до «хтось зачепив силовий кабель». Ваше завдання — ідентифікувати, який шар першим дав збій.

2) Пристрій (або гіпервізор) фактично встановив захист від запису

Навіть якщо Linux показує /sys/block/.../ro як 0, ваші записи все одно можуть не доходити, бо платформа їх відхиляє. У VM «тільки читання» може бути ввічливою формою «датастор переповнений» або «ланцюжок знімків пошкоджений». На SAN це може бути режим захисту масиву після виявлення проблеми.

Підказка: ви бачите SCSI sense-коди, постійні таймаути або дивно послідовні збої на всіх файлових системах одночасно.

3) Файлова система змонтована лише для читання під час завантаження, бо відновлення не вдалося

Якщо відтворення журналу не вдається, або файлову систему помітено як ту, що потребує перевірки, і послідовність завантаження не може виконати її безпечно, ви можете отримати ro монтування або потрапити в emergency mode.

У такому сценарії система фактично каже: «Я можу змонтувати це, але я не довіряю достатньо, щоб дозволити записи без нагляду». Це розумна межа.

4) Ви не на звичайній файловій системі

OverlayFS, squashfs, live-образи, незмінні базові образи та деякі налаштування з жорстким захистом можуть робити «тільки читання» запланованим за замовчуванням. Різниця: заплановане лише для читання — послідовне і чисте; випадкове лише для читання супроводжується помилками в журналі ядра і зазвичай має конкретний часовий штамп, коли щось пішло не так.

5) Система в порядку, але ваша припущення — ні

Іноді файлова система записувальна; ваш додаток пише в read-only bind-монт, або намагається записати в export NFS тільки для читання, або політика SELinux/AppArmor змушує помилку виглядати як «тільки читання» на рівні додатка. Debian 13 тут не виняток, але сучасні розгортання мають стільки шарів, що вони вміють брехати переконливо.

Жарт №1: Збої зі сховищем — як наради: якщо ви думаєте, що впораєтеся за 15 хвилин, ви просто ще не знайшли справжню повістку.

Три корпоративні міні-історії (анонімізовані, правдоподібні та повчальні)

Міні-історія 1: Інцидент через неправильне припущення

Компанія тримала акуратний флот Debian на пристойному обладнанні. В один п’ятничний день один продакшн-хост почав видавати «Read-only file system» під час рутинного оновлення пакету. On-call зробив те, що багато з нас роблять під тиском: перемонтував root в rw, перезапустив оновлення і оголосив перемогу.

Неправильне припущення було тонким: вони вважали, що перемонтування в ro сталося через некоректне вимкнення тиждень тому. Це нормальна причина, і хост дійсно нещодавно перезавантажувався. Когнітивна узгодженість приваблива.

Але в логах ядра були два рядки, що не вписувалися в історію: інтермітентні NVMe таймаути і abort-команди. Вони були проігноровані, бо машина «здавалася швидкою», а моніторинг показував нормальні латентності більшість часу.

Протягом уїк-енду режим відмови накопичувався. Метаданні записи частіше не вдавалися, файлова система знову перекидалася в ro, і база даних почала журналити куди руки потрапляли — поки це не стало неможливо. У понеділок нас очікував не тільки простій, а й брудне відновлення: часткові WAL-сегменти, неконсистентний стан додатку й рішення відновлювати з бекапу під тиском керівництва.

Виправлення було просте. Вони замінили NVMe, відновилися чисто і оновили руни: будь-яке перемонтування в ro вимагає перевірки помилок нижнього шару перед тим, як щось робити з файловою системою. Коли це сталося знову через кілька місяців, реакція була нудною і швидкою. Нудно — це комплімент.

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

Інша організація мала «команду тигрів продуктивності». Вони тонко налаштовували високонаписні навантаження і хотіли менше стрибків латентності. Хтось запропонував агресивні опції монтування і тюнінг черг, а також збільшили інтервали опитування стану дисків, щоб зменшити шум у моніторингу. Це трохи відрізало шум з графіків — і всі почувалися розумними.

Потім один хост почав бачити рідкі таймаути по шляху зберігання. З рідшим опитуванням стану і меншою ранньою сигналізацією першим видимим симптомом стало перемонтування busy data тому ext4 в ro. До того часу, як хтось звернув увагу, навантаження вже накопичило помилки й повтори, що посилило таймаути на рівні додатку.

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

Урок був приземлений: тримайте телеметрію здоров’я достатньо частою, щоб помічати дрейф. Пара додаткових метрик дешевша за обідньогодинний простій. Вони відкотили зміну опитувань і додали алерт на події «filesystem remounted read-only», витягнуті з журналу ядра.

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

Фінансова компанія тримала Debian-системи з суворим контролем змін і звичкою, що здавалася майже старомодною: кожен хост зі сховищем мав протестований план евакуації і відомий ISO відновлення, доступний через віддалене управління. Вони також тримали невеликий окремий розділ /var/log, адекватно розмірений і з агресивною ротацією. Не захопливо. Дуже відповідально.

Одного ранку хост перевів /var у ro. Команда додатку запанікувала, бо здалося, що «сервер мертвий». SRE на чергуванні дістав плейбук: перевірити прапори монтування, подивитися логи ядра, підтвердити помилки NVMe і припинити писати.

Оскільки логи були на окремому монтуванні з достатнім простором, слід помилки лишився цілим. Вони зібрали journalctl, зберегли SMART-дані і ініціювали плановане переключення на стендбай-ноду. Потім завантажили аварійний хост у режим відновлення, виконали перевірку в режимі тільки для читання і лише після евакуації даних відновили та замінили диск. Ніякої героїчної ночної операції.

Пояснити керівництву, чому «замініть диск» зайняло більше часу, ніж утримати сервіс у робочому стані, виявилось складніше, ніж сама операція. Але саме так треба.

Шаблони відновлення, що не роблять гірше

Пріоритет 1: Зупиніть кровотечу, збережіть докази

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

• Зупиніть інтенсивних записувачів (БД, шипери логів, черги).
• Якщо це не root-том, відмонтуйте його, якщо це можливо.
• Зберіть докази: уривок журналу ядра, SMART-дані, відображення lsblk і таблицю монтувань.

Пріоритет 2: Вирішіть, евакуюєте чи ремонтуєте на місці

Говоря прямо: якщо бачите повторювані таймаути пристрою, aborts, цикли скидання або тренд зростання SMART-помилок, спочатку евакуюйте. Ремонт файлової системи на ненадійному обладнанні — це гра в азартні ігри, а фізика не слухає надій.

Пріоритет 3: Використовуйте правильний інструмент ремонту, у правильному режимі, у правильний час

• ext4: fsck.ext4 (або e2fsck). Почніть з read-only перевірки, коли це можливо.
• XFS: xfs_repair. Якщо файлову систему було змонтовано, спочатку відмонтуйте. xfs_repair може бути руйнівним при неправильному використанні.
• btrfs: відновлення — інша методика (scrub, check, статистика пристроїв). Не застосовуйте поради для ext4 бездумно.

Пріоритет 4: Перемонтуйте в rw тільки після усунення причини

Перемонтування rw — це не «виправлення». Це рішення відновити записи. Робіть це тільки коли:

• шар пристрою стабільний (немає поточних I/O помилок/таймаутів), і
• файлова система консистентна (fsck/відтворення журналу виконано), і
• ви прийняли ризик (або виконали міграцію).

Жарт №2: Найшвидший спосіб зробити файлову систему записуваною — запросити її на обід і пообіцяти, що наступного разу ви не ігноруватимете SMART-попереджень.

Чек-лісти / покроковий план

Чек-ліст A: Тріяж живої системи (5–10 хвилин)

1. Визначте проблемний монтувальний шлях: findmnt -T /path
2. Підтвердіть, що він дійсно ro: findmnt -no OPTIONS /mount
3. Витягніть рядок-тригер з журналу ядра: journalctl -k -b фільтруйте по I/O помилках і подіях remount
4. Відобразіть dm/LVM на фізичні пристрої: lsblk
5. Зробіть знімок стану пристрою: smartctl -a (або інструменти вендора)
6. Зменшіть записи: зупиніть сервіси; розгляньте перемикання в режим лише для читання на рівні додатку
7. Вирішіть: евакуювати чи намагатися ремонтувати

Чек-ліст B: Контрольоване відновлення ext4 на не-root монті

1. Зупиніть сервіси, що використовують монтування (спочатку бази даних).
2. Спробуйте чисте відмонтування:

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

   Значення: Щось все ще тримає файли відкритими.

   Рішення: Ідентифікуйте і зупиніть винуватців, перш ніж форсувати щось.

3. Знайдіть відкриті файли:

   cr0x@server:~$ lsof +f -- /var | head
   COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
   rsyslogd  612 syslog  1w   REG  253,2  1048576  123 /var/log/syslog
   

   Значення: Логи все ще пишуться.

   Рішення: Зупиніть rsyslog/journald persistence (обачно) або тимчасово перенаправте логи.

4. Після відмонтування виконайте read-only fsck:

   cr0x@server:~$ fsck.ext4 -fn /dev/mapper/vg0-var
   e2fsck 1.47.2 (1-Jan-2025)
   Pass 1: Checking inodes, blocks, and sizes
   Inode 513124 has illegal block(s).  Clear? no
   
   /dev/mapper/vg0-var: ********** WARNING: Filesystem still has errors **********
   /dev/mapper/vg0-var: 123456/13107200 files, 9876543/52428800 blocks
   

   Значення: Існують помилки; опція -n відмовилася модифікувати. Добре. Тепер ви знаєте, що потрібен ремонт.

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

5. Відремонтуйте з fsck (це змінить структури на диску):

   cr0x@server:~$ fsck.ext4 -fy /dev/mapper/vg0-var
   e2fsck 1.47.2 (1-Jan-2025)
   Pass 1: Checking inodes, blocks, and sizes
   Inode 513124 has illegal block(s).  Clear? yes
   Pass 2: Checking directory structure
   Pass 3: Checking directory connectivity
   Pass 4: Checking reference counts
   Pass 5: Checking group summary information
   /dev/mapper/vg0-var: FILE SYSTEM WAS MODIFIED
   /dev/mapper/vg0-var: 123455/13107200 files, 9876501/52428800 blocks
   

   Значення: Ремонти застосовано.

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

6. Перемонтування:

   cr0x@server:~$ mount /var
   

   Значення: Якщо це проходить і монтується rw, файлова система відновлена.

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

Чек-ліст C: Відновлення root-файлової системи (реаліті-шоу версія)

Якщо root (/) — лише для читання і ви не можете відновити онлайн, використайте середовище відновлення. Залежно від налаштувань це консоль через віддалене керування, rescue ISO або initramfs shell.

1. Завантажтесь у rescue/emergency режим (або live-образ) і впевніться, що root не змонтовано в rw.
2. Ідентифікуйте блочний пристрій root:

   cr0x@server:~$ blkid | egrep 'ext4|xfs|btrfs|LVM2_member'
   /dev/nvme0n1p2: UUID="..." TYPE="LVM2_member"
   /dev/mapper/vg0-root: UUID="..." TYPE="ext4"
   

   Значення: Root — ext4 LV.

   Рішення: Продовжуйте за робочим процесом ext4.

3. Запустіть fsck офлайн:

   cr0x@server:~$ fsck.ext4 -fy /dev/mapper/vg0-root
   e2fsck 1.47.2 (1-Jan-2025)
   /dev/mapper/vg0-root: recovering journal
   /dev/mapper/vg0-root: clean
   

   Значення: Відтворення журналу пройшло; файлова система тепер консистентна.

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

Типові помилки: симптом → корінна причина → виправлення

Помилка 1: «Все лише для читання» після однієї помилки додатку

Симптом: Один сервіс логить «Read-only file system», але findmnt показує файлову систему як rw.

Корінь проблеми: Сервіс пише в інший монтувальний шлях (bind-монт, overlay контейнера), або пише в readonly export NFS, або проблема з правами/політикою неправильно інтерпретується.

Виправлення: Використайте findmnt -T /path і перевірте монтування контейнера. Підтвердіть прямим тестом запису в тому ж неймспейсі, що й процес.

Помилка 2: Негайний перезавантаження, щоб «очистити» read-only

Симптом: Сервер впав у ro; хтось перезавантажив; усе повернулося; інцидент «вирішено» … доки не повториться.

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

Виправлення: Перед перезавантаженням зафіксуйте journalctl -k, smartctl і відображення пристроїв. Якщо це VM — перевірте стан датастору гіпервізора. Потім вирішіть: ремонт чи евакуація.

Помилка 3: Запуск fsck на змонтованій файловій системі

Симптом: Хтось запустив fsck.ext4 на /dev/mapper/vg0-var, поки /var все ще змонтовано.

Корінь проблеми: Паніка + м’язова пам’ять.

Виправлення: Відмонтуйте спочатку (або завантажіться в recovery). Якщо не вдається відмонтувати через зайнятість, зупиніть сервіси; якщо це root — використайте офлайн-відновлення.

Помилка 4: «Це корупція файлової системи», коли насправді проблема транспорту сховища

Симптом: ext4 відхилив журнал; fsck «виправляє»; повтор через день.

Корінь проблеми: Підлягаючі I/O помилки/таймаути від NVMe, SATA лінку, прошивки HBA, флапів шляху SAN.

Виправлення: Сприймайте I/O помилки як первинні. Замініть диск, оновіть прошивку, пересадіть кабелі/backplane, дослідіть multipath. Тільки після цього ремонтуйте файлову систему.

Помилка 5: Перемонтування rw і продовження інтенсивних записів, щоб «виграти час»

Симптом: mount -o remount,rw спрацьовує і все виглядає добре 20 хвилин.

Корінь проблеми: Умова помилки досі присутня; наступний невдалий запис знову поверне вас у ro, іноді з більшим збитком.

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

Помилка 6: Ігнорувати повну файлову систему, бо «тільки читання — це реальна проблема»

Симптом: /var 100% заповнений, сервіси падають, потім файлова система поводиться дивно.

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

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

ЧАСТІ ПИТАННЯ

1) Чому Debian перемонтовує ext4 в режим лише для читання замість того, щоб просто відмовити один запис?

Тому що цілісність метаданих важлива. Якщо ext4 бачить умови, що можуть означати невідповідність (або не може безпечно закомітити транзакції журналу), продовження записів ризикує поширити корупцію. Режим лише для читання — це ізоляція.

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

Можете, але ви робите явну ставку, що первинна причина зникла. Якщо в логах ядра є I/O помилки або таймаути, ця ставка зазвичай програшна. Використовуйте remount rw для контрольованої евакуації, а не заперечення проблеми.

3) Якщо fsck виправив, чи означає це, що апаратура в порядку?

Ні. Файлові системи часто «падають» після того, як спочатку відмовив пристрій. Чистий результат fsck лише говорить, що структура на диску зараз консистентна. Перевірте SMART, I/O помилки ядра і логи платформи.

4) Як визначити, чи це втрата живлення чи помираючий диск?

Втрата живлення зазвичай показує некоректне вимкнення і потребу в replay журналу, але не повторювані таймаути/скидання пристрою. Похідні диска показують I/O помилки, abort-команди, скидання або зростаючі лічильники помилок SMART.

5) Чому я бачу це в контейнері, коли хостова файлова система в порядку?

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

6) Яка найбезпечніша перша команда fsck для ext4?

Почніть з недеструктивної перевірки лише для читання: fsck.ext4 -fn /dev/DEVICE. Вона покаже, чи потрібні ремонти, не змінюючи нічого. Потім вирішіть, коли і де виконувати реальні ремонти.

7) Чи робить XFS ту саму поведінку «перемонтуй ro»?

Механізм інший, але намір той самий. XFS може виконати примусове вимкнення файлової системи при певних помилках; результат функціонально схожий: записи не виконуються, і потрібен офлайн-ремонт з xfs_repair.

8) Чи тримати систему увімкненою, щоб скопіювати дані, чи вимкнути негайно?

Якщо пристрій активно видає помилки (таймаути/цикли скидання), тримайте runtime мінімальним і пріоритезуйте евакуацію. Якщо він стабільний, але файлова система ro, зазвичай можна тримати систему увімкненою достатньо, щоб зібрати логи і спланувати контрольований ремонт.

9) Якщо root лише для читання і я не можу увійти нормально?

Використайте консольний доступ і завантажтесь у rescue/emergency режим. Якщо потрапили в initramfs, ви все одно можете іноді переглянути логи (хоч із обмеженнями) і виконати офлайн-перевірки, коли пристрій видно.

10) Після відновлення що моніторити, щоб вловити це раніше наступного разу?

Як мінімум: шаблони журналу ядра для I/O помилок і «remounting filesystem read-only», критичні лічильники SMART, та латентні/таймаути сховища. Також ставте алерти на файлові системи, що наближаються до заповнення, особливо /var.

Наступні кроки, які ви можете зробити сьогодні

1. Додайте хук виявлення: налаштуйте алерт на повідомлення ядра, що містять «Remounting filesystem read-only» і помилки блок-шару I/O.
2. Потренуйте шлях відновлення: переконайтеся, що ви можете завантажитись у rescue режим і отримати доступ до зашифрованих/LVM томів під реальними операційними обліковими даними.
3. Розділіть радіуси ураження: розгляньте окремі монти для /var, баз даних і логів, з реалістичним запасом вільного місця.
4. Зробіть евакуацію нудною: документуйте, як перемикати навантаження або переміщувати сервіси, коли сховище хоста починає брехати.
5. Не довіряйте «він знову в мережі» як вирішення: після будь-якого перемонтування в ro вимагайте запису з корінною причиною: рядок-тригер з журналу, знімок стану пристрою і рішення з ремедіації.

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