Відновлення ext4 та XFS в Ubuntu 24.04: який інструмент запускати першим (і чому)

Головне правило: перший інструмент — «припиніть змінювати диск»

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

Що означає «перший» у реальному житті

Коли хтось каже «запустіть fsck» або «запустіть xfs_repair», найчастіше мають на увазі «виправіть зараз». В операціях «перший» має означати:

• Підтвердіть, яку файлову систему ви торкаєтеся. Люди помиляються частіше, ніж визнають.
• Підтвердіть відображення пристрою. LVM, mdraid, multipath, NVMe namespaces — ваша інтуїція щодо /dev/sdX не є стратегією.
• Підтвердіть домен відмови. Це файлову систему, блочний пристрій, контролер чи шар вище (наприклад dm-crypt, mdraid або віртуалізаційне сховище)?
• Зупиніть зміни диска. Якщо можете зняти снапшот — зробіть це. Якщо можете створити образ — зробіть це. Якщо хоча б можете перемонтувати в режим лише для читання — зробіть це.

Лише тоді обирайте перший інструмент, специфічний для файлової системи. Для ext4 це зазвичай fsck.ext4 (через e2fsck), але не завжди в режимі «виправити все». Для XFS це зазвичай xfs_repair — але часто попереджає xfs_repair -n або обдумане рішення щодо журналу (-L — не тепле обіймання).

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

Жарт 1: Запускати інструменти ремонту на мерехтливому диску — як фарбувати будинок під час землетрусу: це не вина фарби, але результат буде сумнівним.

І ще одна операційна істина, яку варто прикріпити до вашого інцидентного каналу:

«Надія — не стратегія.» — генерал Gordon R. Sullivan

Факти та контекст, що змінюють рішення

Це не дрібниці. Вони пояснюють, чому ext4 і XFS поводяться по-різному під час відмов і чому «перший інструмент» відрізняється.

1. ext4 походить від журналювальної лінії ext3, спроектований для широкої сумісності в Linux і передбачуваного відновлення. Його журнал часто робить монтування після збоїв більш життєздатним, ніж у старіших файлових систем.
2. XFS виник в SGI для високопродуктивних IRIX-систем і пізніше став основною файловою системою Linux; він побудований навколо агресивних структур метаданих і масштабованості.
3. XFS журналює метадані (лог), а не дані файлів за замовчуванням. Це означає, що після збою ви можете бачити «чистий» вміст файлів, який семантично неправильний, оскільки останні записи не були завершені — особливо для додатків, що не використовують дисципліну fsync.
4. Режим «ordered» у ext4 (поширений за замовчуванням) намагається скинути дані файлу перед фіксацією відповідних метаданих, зменшуючи деякі типи післязбоєвих «сміттєвих» вказівників, але з втратами в продуктивності.
5. XFS використовує групи алокацій (AG) для масштабування паралельних операцій з метаданими. Корупція може локалізуватися до AG, що добре; ремонт все одно часто вимагає повного сканування, яке не швидке на великих томах.
6. ext4 може виконувати «онлайнові перевірки метаданих» в обмежений спосіб, але серйозні невідповідності зазвичай вимагають відмонтування та запуску e2fsck. Ремонт XFS також є офлайн (не змонтований) для реальних виправлень.
7. XFS має механізм відтворення журналу при монтуванні. Якщо сам журнал пошкоджений, монтування може зірватися. Люди схильні використовувати xfs_repair -L, що відкидає журнал — іноді необхідно, іноді катастрофічно.
8. ext4 має контрольні суми метаданих і журналу в сучасних ядрах; це допомагає виявляти корупцію раніше, але також означає, що старі середовища для порятунку можуть «захлинутися» від нових прапорів функцій.
9. Середовища порятунку Ubuntu 24.04 мають значення: занадто старий live-ISO може не розуміти ваші функції ext4 або метадані XFS v5, що призведе до хибної діагностики «корупції», яка фактично є «старим інструментом».

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

Який інструмент запускати першим (ext4 vs XFS): таблиця рішень

Перш ніж використовувати інструменти файлової системи: універсальні перші кроки

Перший «інструмент» має бути набором дій, а не командою:

• Зупиніть записи: зупиніть сервіси, відмонтуйте по можливості або перемонтуйте в режим лише для читання.
• Перевірте шлях до пристрою: підтвердіть, чи це розділ, LVM LV, mdraid або dm-crypt-маппінг.
• Шукайте апаратні помилки: dmesg, SMART/NVMe журнали, статус RAID.
• Зробіть снапшот або образ, якщо дані важливі: LVM snapshot, снапшот сховища або ddrescue, якщо апарат погано працює.

Тепер специфічний перший інструмент для файлової системи

Ось набір правил з мого досвіду в продакшені.

ext4: першим інструментом зазвичай є e2fsck, але почніть з «дивись, не чіпай»

• Якщо файлову систему не можна змонтувати або вона монтується лише для читання через помилки: спочатку запустіть e2fsck -fn (без змін), щоб оцінити обсяг пошкоджень і ризик. Потім вирішіть, чи робити снапшот/образ і запускати пропуск виправлень.
• Якщо підозрюєте серйозну корупцію або апаратні проблеми: спочатку виконайте перевірки SMART/NVMe і розгляньте створення образу, потім запускайте e2fsck на образі або снапшоті.
• Якщо журнал підозрілий: можливо, знадобиться e2fsck -f і, в окремих випадках, відновлення журналу за допомогою tune2fs — але не починайте з цього.

XFS: першим інструментом є xfs_repair -n (dry-run), а не xfs_repair

• Якщо монтування зривається через помилки журналу: спочатку запустіть xfs_repair -n, щоб побачити, що він зробить. Якщо він повідомляє, що журнал «брудний/пошкоджений», обережно вирішіть, чи монтувати із відновленням, чи відкидати журнал.
• Використовуйте xfs_repair -L лише коли готові втратити нещодавні метадані. Це може повернути файлову систему, але ціною забуття «недавньої історії». Іноді це означає втрату файлів або записів каталогів, створених перед збоєм.
• Якщо апарат поводиться нестабільно: спочатку зробіть образ. Ремонт XFS інтенсивно працює з метаданими і сильно навантажить хворий диск.

Жарт 2: xfs_repair -L — це як видалити історію браузера: вирішує проблему, але не завжди ту, яка вам справді потрібна.

Коротка відповідь: чому порядок відрізняється

Робочий процес відновлення ext4 побудований навколо fsck як авторитетного засобу виправлення, і він часто може відтворити або узгодити журнали досить детерміновано. XFS розраховує на відтворення журналу під час монтування для типового відновлення, і коли це не вдається, журнал стає точкою прийняття рішення. Ось чому xfs_repair -n — правильний перший інструмент для XFS: він показує, чи збираєтеся ви братися за журнал бензопилою.

Швидкий план діагностики (швидко знайти вузьке місце)

Коли час обмежений, мета — не «бути ретельним». Мета — «визначити, який шар вас обманює». Ось швидкий порядок, що працює на Ubuntu 24.04 у реальних кластерах.

Крок 1: Це апарат або транспорт?

• Перевірте журнали ядра на предмет помилок I/O/таймаутів. Якщо бачите такі записи, розглядайте симптоми файлової системи як вторинні.
• Швидко перевірте SMART/NVMe стан. Перерозподілені сектори, помилки носія, CRC-помилки або прапори «critical_warning» у NVMe змінюють усе.
• Якщо це RAID: підтвердіть стан масиву перед запуском інструментів відновлення. Ремонт поверх деградованого/відновлюваного масиву може бути прийнятним, але ремонт на «тихо неконсистентному» масиві — як створювати мистецтво.

Крок 2: Чи правильне відображення блоків?

• Підтвердіть ідентичність пристрою (UUID, WWN, серійний номер). Не довіряйте /dev/sdX.
• Підтвердіть шари: dm-crypt? LVM? mdraid? multipath? хмарний том?

Крок 3: Яка це файлова система і що вона про себе каже?

• Ідентифікуйте тип ФС та її функції без монтування (або змонтуйте лише для читання, якщо безпечно).
• Для ext4: робіть недеструктивний прохід fsck, щоб побачити масштаби.
• Для XFS: робіть dry-run відновлення, щоб зрозуміти, чи журнал є проблемою.

Крок 4: Оберіть найбезпечніший шлях відновлення

• Дані незамінні: спочатку образ/снапшот, потім ремонт.
• Сервіс незамінний: спочатку переключіться на інший вузол, ремонт робіть на боці.
• Потрібно повернути сервер за 10 хвилин: вас потягне «просто запустити фіксер». Зробіть хоча б один прохід лише для читання, щоб знати, на що ви ризикуєте.

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

Ці завдання навмисне операційні: кожне містить команду, приклад виводу, що це означає, і що робити далі. Запускайте їх з консолі порятунку коли можливо (або хоча б у single-user режимі). Уважно замінюйте імена пристроїв.

Завдання 1: Підтвердити, що саме відмовляє (помилки монтування і поточний стан)

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

Значення: /var — це XFS і вже в режимі лише для читання. Це підказка: або XFS виявив невідповідність, або ядро перевело його через I/O-помилки.

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

Завдання 2: Ідентифікувати тип файлової системи по блочному пристрої (без домислів)

cr0x@server:~$ lsblk -f /dev/nvme0n1
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1  vfat   FAT32       4C3A-1B2F                             510M     2% /boot/efi
├─nvme0n1p2
└─nvme0n1p3  xfs               3a2d0a3e-3f2e-4f2d-9d8a-0c2c8c9d6f11                /var

Значення: Це XFS на /dev/nvme0n1p3. Без двозначностей.

Рішення: Використовуйте інструменти XFS (xfs_repair, xfs_metadump), а не fsck (що не підходить для XFS у тому ж сенсі).

Завдання 3: Перевірте журнали ядра на предмет I/O-помилок перед «ремонтом» корупції

cr0x@server:~$ dmesg -T | egrep -i "I/O error|blk_update_request|nvme|ata|reset|xfs|ext4" | tail -n 25
[Mon Dec 29 09:41:11 2025] nvme nvme0: I/O 123 QID 6 timeout, aborting
[Mon Dec 29 09:41:12 2025] nvme nvme0: Abort status: 0x371
[Mon Dec 29 09:41:14 2025] XFS (nvme0n1p3): log I/O error -5
[Mon Dec 29 09:41:14 2025] XFS (nvme0n1p3): Log I/O Error Detected. Shutting down filesystem
[Mon Dec 29 09:41:14 2025] XFS (nvme0n1p3): Please unmount the filesystem and rectify the problem(s)

Значення: Це не «рандомна корупція файлової системи». Помилка I/O журналу спричинена таймаутами NVMe.

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

Завдання 4: Швидка перевірка SMART для SATA/SAS дисків (якщо застосовно)

cr0x@server:~$ sudo smartctl -H -A /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0-xx-generic] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x003e   199   199   000    Old_age   Always       -       12

Значення: CRC-помилки вказують на проблеми з кабелем/контролером навіть якщо диск «проходить» тест. Це може пошкоджувати записи і викликати відключення файлової системи.

Рішення: Виправте транспорт (кабель/бекаплейн/HBA) перед ремонтом. Якщо сервер з hot-swap, переустановіть/замініть і перевірте знову.

Завдання 5: Перевірка стану NVMe (поширено в кластерах Ubuntu 24.04)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 47 C
available_spare                     : 100%
percentage_used                     : 3%
media_errors                        : 0
num_err_log_entries                 : 18

Значення: Медійних помилок немає, але є записи журналу помилок. У поєднанні з таймаутами в dmesg це вказує на проблеми контролера/шляху, а не на смерть NAND.

Рішення: Витягніть журнал помилок NVMe, перевірте PCIe AER події, розгляньте оновлення прошивки. Все одно зробіть снапшот/образ перед ремонтом, якщо дані критичні.

Завдання 6: Підтвердіть стан mdraid перед роботою з файловими системами зверху

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

unused devices: <none>

Значення: RAID1 здоровий ([UU]).

Рішення: Можна переходити до діагностики файлової системи. Якби було [U_] або відновлення, ви б призупинилися і стабілізували масив.

Завдання 7: Підтвердіть LVM-структуру і який LV ви збираєтесь оперувати

cr0x@server:~$ sudo lvs -a -o lv_name,vg_name,lv_size,lv_attr,devices
  LV   VG  LSize   Attr       Devices
  root vg0 80.00g  -wi-ao----  /dev/nvme0n1p2(0)
  var  vg0 200.00g -wi-ao----  /dev/nvme0n1p2(20480)
  home vg0 500.00g -wi-ao----  /dev/nvme0n1p2(71680)

Значення: /var може бути LV, а не сирим розділом (в цьому прикладі він на nvme0n1p2, а не на p3). Тут люди часто ремонтують не те.

Рішення: Ремонтуйте правильний блочний пристрій (шлях LV, наприклад /dev/vg0/var) і припиніть спиратися на припущення щодо розділів.

Завдання 8: Зробіть снапшот перед ремонтом (LVM)

cr0x@server:~$ sudo lvcreate -L 20G -s -n var-pre-repair /dev/vg0/var
  Logical volume "var-pre-repair" created.

Значення: Тепер у вас є copy-on-write снапшот. Це не повний бекап, але точка відкату на випадок помилок під час ремонту.

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

Завдання 9: Для ext4 почніть з недеструктивної перевірки

cr0x@server:~$ sudo e2fsck -fn /dev/vg0/home
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/home: ***** FILE SYSTEM WAS MODIFIED *****
/home: 219842/32768000 files (0.2% non-contiguous), 4123712/131072000 blocks

Значення: Навіть з -n (без змін) воно повідомляє «було б змінено». Це вказує на невідповідності, які e2fsck може виправити.

Рішення: Якщо апарат стабільний і у вас є снапшот/образ — переходьте до проходу виправлення (e2fsck -fy) у вікні простою. Якщо апарат нестабільний — спочатку зробіть образ.

Завдання 10: Для ext4 зробіть проход виправлення (контрольовано, з логуванням)

cr0x@server:~$ sudo e2fsck -fy /dev/vg0/home
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Inode 924518 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
Entry 'cache' in /user/alex (924612) has deleted/unused inode 1032211.  Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/home: ***** FILE SYSTEM WAS MODIFIED *****
/home: 219840/32768000 files (0.2% non-contiguous), 4123690/131072000 blocks

Значення: Воно виправило реальні невідповідності метаданих. Очікуйте, що деякі файли будуть переміщені в lost+found, якщо записи каталогів були пошкоджені.

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

Завдання 11: Для XFS спочатку сухий запуск ремонту

cr0x@server:~$ sudo xfs_repair -n /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
would zero log
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

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

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

Завдання 12: Для XFS спробуйте монтування лише для читання, щоб скопіювати дані (якщо можливо)

cr0x@server:~$ sudo mount -o ro,norecovery /dev/vg0/var /mnt/var_ro
mount: /mnt/var_ro: mount(2) system call failed: Structure needs cleaning.

Значення: Навіть лише для читання з відключеним відновленням не вдається змонтувати. Метадані ймовірно пошкоджені за межами терпимості монтування.

Рішення: Перейдіть до планування xfs_repair — бажано на снапшоті/образі.

Завдання 13: Для XFS виконайте ремонт (без -L, якщо ви цього не маєте на увазі)

cr0x@server:~$ sudo xfs_repair /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - found corruption in filesystem
        - resetting log...
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify link counts...
done

Значення: Воно скинуло журнал у процесі ремонту (деякі ремонти можуть передбачати обробку журналу). В інших ситуаціях вам доведеться обирати -L.

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

Завдання 14: Для XFS, коли журнал неможливо відновити: явне рішення про -L

cr0x@server:~$ sudo xfs_repair -L /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero 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 link counts...
done

Значення: Ви відкинули журнал. Всі метадані-транзакції, що були лише в журналі, зникли. Це може сиротити нещодавні файли або відкотити зміни в каталогах.

Рішення: Робіть це лише якщо (a) у вас є бекапи, (b) ви прийняли втрату недавніх змін, і (c) альтернатива — «файлова система залишається недоступною». Задокументуйте вибір.

Завдання 15: Перевірте монтування і слідкуйте за повторними переходами в режим лише для читання після ремонту

cr0x@server:~$ sudo mount /dev/vg0/var /var
cr0x@server:~$ findmnt -no OPTIONS /var
rw,relatime,attr2,inode64,logbufs=8,logbsize=32k

Значення: Змонтувався в режимі читання-запису з нормальними опціями XFS. Добрий знак.

Рішення: Слідкуйте за dmesg щодо свіжих I/O-помилок. Якщо він знову перейде в режим лише для читання, ви женетеся за апаратною нестабільністю, а не за одноразовим збоєм.

Завдання 16: Перевірте журнал ext4 і функції (допомагає при проблемах «старого інструменту»)

cr0x@server:~$ sudo tune2fs -l /dev/vg0/home | egrep -i "Filesystem features|Filesystem state|Errors behavior|Journal"
Filesystem state:         clean
Errors behavior:          Continue
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit metadata_csum
Journal inode:            8

Значення: Сучасні функції ext4 як metadata_csum вимагають досить нового e2fsck. Ubuntu 24.04 підходить; старі середовища порятунку можуть не зрозуміти ці прапори.

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

Завдання 17: Підтвердіть версію метаданих XFS (v5 чи старіша)

cr0x@server:~$ sudo xfs_info /dev/vg0/var
meta-data=/dev/vg0/var          isize=512    agcount=64, agsize=819200 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
data     =                       bsize=4096  blocks=52428800, imaxpct=25
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal               bsize=4096   blocks=25600, version=2
realtime =none                   extsz=4096   blocks=0, rtextents=0

Значення: crc=1 вказує на контрольні суми метаданих (функції XFS v5). Знову ж: старі утиліти можуть некоректно працювати.

Рішення: Переконайтесь, що ваше rescue-середовище сучасне (Ubuntu 24.04 або подібне) перед тим, як інтерпретувати помилки як «корупцію».

Завдання 18: Коли диск помирає, створіть образ за допомогою ddrescue (не dd)

cr0x@server:~$ sudo ddrescue -f -n /dev/nvme0n1 /mnt/recovery/nvme0n1.img /mnt/recovery/nvme0n1.map
GNU ddrescue 1.28
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued:      0 B,  errsize:      0 B,  current rate:       0 B/s
ipos:         0 B,   errors:       0,    average rate:       0 B/s
opos:         0 B, run time:         0s,  remaining time:         0s
Finished

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

Рішення: Виконуйте ремонти файлової системи на образі (через loopback) або на клоні диска. Не навантажуйте джерело повторними скануваннями метаданих.

Три корпоративні міні-історії з полів ремонту

1) Інцидент через неправильне припущення

У них була група Ubuntu VM, більшість з яких використовували ext4, бо так було в базовому образі роки тому. Одного дня критичний аналітичний вузол перестав монтувати /data. On-call побачив «Structure needs cleaning», знизав плечима і набрав fsck -y /dev/sdb, бо «м’язова пам’ять» непереможна.

Команда не «виправила» нічого. Вона також не явно не впала, що створило паніку. Це частина пастки: generic fsck може вибирати допоміжні інструменти, але коли тип ФС неправильно визначений або пристрій невірний, ви або нічого не зробите корисного, або — гірше — пошкодите сусідню файлову систему, бо працювали з невірним шаром (розділ vs LV vs цілий диск).

Справжня проблема: /data був XFS на LVM LV, а пристрій, який вони ремонтували, був підлягаючий PV-розділ. Тобто вони запустили невідповідний інструмент на неправильній цілі, тоді як справжній LV продовжував помилятися.

Коли приєднався старший інженер, вони зробили неефектні кроки: lsblk -f, lvs і findmnt. Потім xfs_repair -n показав, що журнал пошкоджений. Фікс виявився xfs_repair -L — погоджена втрата останніх кількох хвилин оновлень директорій — з подальшим відновленням невеликого набору результатів додатка з upstream.

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

2) Оптимізація, що обернулася проти

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

Потім подія з живленням вивела з ладу UPS у стояку. Сервери вціліли, здебільшого. Але кілька вузлів повернулися з повідомленнями XFS про відновлення журналу. Команда вирішила стандартизувати автоматичний крок: якщо монтування не вдається, запускати xfs_repair -L і перезавантажуватись. Це працювало в тестах. Це працювало в стейджингу. І працювало, як гарний ніж «працює».

На продукції це повернуло монтування, але дані додатка стали неконсистентними. Деякі каталоги втратили недавно створені файли. Деякі файли з’явилися з нульовою довжиною. Найгірше: сервіс був «up», отже downstream системи споживали погані результати, перш ніж хтось помітив. Це коштувало більше, ніж зайвий час простою.

Провал не в XFS. Провал у припущенні, що «файлова система доступна» — означає «додаток коректний», і що відкидання журналу — безпечний стандарт. Відкидання журналу XFS — це останній засіб, а не рядок у скрипті перезавантаження.

Після цього запровадили дві політики: (1) ніколи не виконувати автоматичне відкидання журналу без затвердження людиною, і (2) для критичних наборів даних переключатися на резервний вузол і відновлюватися з відомих контрольних точок, а не змушувати файлову систему повертатися в «хворому» стані.

3) Нудна, але правильна практика, яка врятувала день

Фінансова компанія мала правило, яке дратувало всіх: перед будь-яким інструментом ремонту — знімати снапшот або клон. Без винятків. Інженери жартували, що політика снапшотів існує, щоб захистити їх від самих себе. Жарт був близький до правди.

Під час квартального звіту VM для пакетної обробки потрапила у гік у сховищі на хості. Ядро гостя почало логувати I/O-помилки, потім перемонтувало ext4-томи в режим лише для читання. Це саме по собі було добрим поведінкою: ext4 намагався запобігти подальшій шкоді. Тиск був величезний, бо затримки кварталу мають особливу здатність підніматися управлінською ланцюжком.

On-call дотримався плану: зупинив записи, підтвердив апаратну стабільність на стороні гіпервізора, зробив LVM-снапшот на шарі зберігання, потім запустив e2fsck -fn щоб оцінити пошкодження. Звіт показав inode- і директорні проблеми, які можна виправити. Вони запустили e2fsck -fy спочатку на клоні снапшота, перевірили цілісність додатка, а потім відремонтували реальний том.

Під час ремонту e2fsck зробив дію, яка була би незручною без можливості відкату: очистив деякі записи каталогу, що вказували на невірні inode. Тома повернувся в чистому стані, але одне дерево каталогів частково перемістилося в lost+found. Оскільки був снапшот, вони змогли відновити конкретні файли за inode зі стану до ремонту, замість відновлення всього світу.

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

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

1) «Я запустив fsck і це не допомогло»

Симптоми: Ви запустили fsck, проблема залишається або воно скаржилось на «bad magic number».

Коренева причина: Невірний тип ФС або невірний цільовий пристрій (розділ/PV замість LV, md-пристрій замість учасника диска).

Виправлення: Повторно ідентифікуйте за допомогою lsblk -f та findmnt. Використовуйте e2fsck лише для ext* і xfs_repair для XFS. Ремонтуйте правильний шар (наприклад /dev/vg0/var, а не /dev/nvme0n1p2).

2) XFS не монтується і ви одразу використали xfs_repair -L

Симптоми: Після ремонту монтування працює, але «недавні» файли відсутні або каталоги виглядають відкотченими.

Коренева причина: Відкидання журналу втрачає метадані-транзакції, які не були зафіксовані в основних структурах.

Виправлення: Надавайте перевагу xfs_repair -n спочатку; якщо мусите використовувати -L, документуйте це і перевіряйте цілісність додатків. Відновіть відсутні виходи з резервних копій/контрольних точок. Для баз даних віддавайте перевагу інструментам відновлення бази даних і бекапам замість файлової героїки.

3) ext4 постійно перемонтовується в режим лише для читання після fsck «виправив» його

Симптоми: ext4 монтується, а потім переходить у ro; в журналах ядра видно I/O-помилки.

Коренева причина: Підлягаючі помилки диска/контролера або нестабільний шлях, а не невирішені метадані.

Виправлення: Перевірте dmesg і журнали SMART/NVMe. Замініть апарат, виправте кабелі/бекаплейн або мігруйте дані з пристрою. Інструменти ремонту не зроблять шину надійною.

4) Ремонти тривають вічно і ви думаєте, що інструмент завис

Симптоми: e2fsck або xfs_repair працюють годинами на терабайтних томах.

Коренева причина: Повні сканування метаданих дорогі; також диск з повільними повторними спробами робить усе схожим на зависле.

Виправлення: Переконайтесь, що диск не видає повторних спроб/таймаутів в dmesg. Використовуйте iostat, щоб перевірити, чи прогресує I/O. Якщо апарат хворий — створіть образ спочатку за допомогою ddrescue.

5) «Structure needs cleaning» на XFS і ви пробуєте монтувати в режим запису

Симптоми: Монтування не вдається; ви пробуєте різні опції монтування; зрештою монтування вдається, але корупція посилюється.

Коренева причина: Форсоване монтування або відновлення на пошкоджених метаданих може посилити пошкодження, особливо при подальших записах.

Виправлення: Зупиніть записи. Використовуйте xfs_repair -n і вирішіть: скопіюйте дані з RO, якщо можливо, або ремонтуйте офлайн на снапшоті.

6) Ви відремонтували файлову систему, але додаток досі зламаний

Симптоми: PostgreSQL не стартує, MySQL видає помилки або черга має пошкоджені сегменти, хоча fsck/ремонт чисті.

Коренева причина: Узгодженість файлової системи — не те саме, що транзакційна узгодженість додатка. Збої та відкидання журналу можуть порушити вищі рівні інваріантів.

Виправлення: Виконайте відновлення на рівні додатка (відновлення БД, WAL-replay, перебудова індексів) або відновіть з відомо-робочих бекапів. Розглядайте ремонт файлової системи як «зробити змонтованим», а не «зробити правильним».

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

Чекліст A: Перші 10 хвилин (будь-яка ФС)

1. Зупиніть записи: зупиніть сервіси, вимкніть cron/timers, якщо потрібно.
2. Збережіть докази: збережіть вивід dmesg і релевантні журнали.
3. Підтвердіть відображення: findmnt, lsblk -f, lvs, /proc/mdstat.
4. Перевірте апаратні індикатори: журнали SMART/NVMe, стан RAID, журнали контролера.
5. Вирішіть щодо снапшоту/образу: якщо дані цінні, створіть снапшот/образ зараз, а не пізніше.

Чекліст B: Порядок відновлення ext4 (спочатку безпечно)

1. Відмонтуйте файлову систему (переважно) або завантажтеся в rescue-режим.
2. Запустіть недеструктивну перевірку: e2fsck -fn /dev/...
3. Якщо є помилки і апарат стабільний: запустіть e2fsck -fy /dev/...
4. Спочатку змонтуйте лише для читання, якщо нервуєте, потім у режимі запису.
5. Перевірте dmesg на нові помилки; якщо чисто — переходьте до валідації на рівні додатка.

Чекліст C: Порядок відновлення XFS (діагностика, потім обдуманий ремонт)

1. Відмонтуйте файлову систему (необхідно для реального ремонту).
2. Спробуйте змонтувати лише для читання з мінімальним ризиком (опціонально): mount -o ro,norecovery, якщо вдається — копіюйте дані.
3. Запустіть xfs_repair -n, щоб побачити, що ремонтуватиметься.
4. Якщо журнал залучений, вирішіть, чи прийнятне відкидання журналу; для критичних транзакцій віддавайте перевагу відновленню з бекапів.
5. Запустіть xfs_repair (і лише за необхідності xfs_repair -L).
6. Змонтуйте і валідуйте; виконайте перевірки на рівні додатка.

Чекліст D: Коли апарат підозрілий

1. Негайно зупиніть усі записи.
2. Створіть образ за допомогою ddrescue або клон через платформу зберігання.
3. Запускайте ремонти на клоні/образі.
4. Плануйте заміну/міграцію; не «ремонтуйте-та-надійтесь» на нестабільному апараті.

Поширені запитання

1) Чи можна запускати fsck на XFS?

Не в тому сенсі, який ви маєте на увазі. XFS використовує xfs_repair. Generic fsck не зробить потрібної роботи для ремонту метаданих XFS і може витратити дорогоцінний час — або, що гірше, вцілитися в невірний пристрій.

2) Чи завжди потрібно відмонтовувати перед запуском інструментів ремонту?

Так для реальних ремонтів. ext4 e2fsck та XFS xfs_repair призначені для офлайн-ремонту. Запуск їх на змонтованій файловій системі — гарний шлях отримати «виправлену» корупцію плюс нову корупцію.

3) Чому xfs_repair -n такий важливий?

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

4) Коли виправданий xfs_repair -L?

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

5) ext4 каже «clean», але мій додаток все одно втратив дані. Чому?

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

6) Що робити, якщо rescue-середовище старіше за функції файлової системи?

Ви можете отримати хибні повідомлення про «корупцію» або відмову в операціях. Для ext4 і XFS епохи Ubuntu 24.04 (з контрольними сумами метаданих) використовуйте сучасне rescue-середовище. Не намагайтесь вимикати функції як ярлик.

7) Ремонтувати на оригінальному диску чи на клоні?

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

8) Як зрозуміти, чи «корупція» насправді апаратна?

Журнали ядра з таймаутами, ресетами, I/O-помилками, CRC-помилками або NVMe aborts — найсильніший сигнал. SMART/NVMe журнали і стан RAID контролера підтверджують картину. Якщо це є — стабілізуйте апарат перш за все.

9) Чи простіше відновлювати ext4, ніж XFS?

У багатьох рутинних випадках відновлення ext4 здається більш лінійним, оскільки e2fsck є стандартним шляхом. XFS дуже надійний, але рішення щодо журналу та поведінка ремонту вимагають більшої обережності.

10) Після ремонту що треба перевірити?

Опції монтування (rw vs ro), журнали ядра, кількість вільних блоків/inode, і — найважливіше — перевірки цілісності додатків (перевірки БД, відтворення WAL, перебудова індексів, контрольні суми якщо є).

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

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

• ext4: розпочніть з e2fsck -fn, щоб оцінити, потім e2fsck -fy, коли готові зафіксувати зміни.
• XFS: розпочніть з xfs_repair -n. Ставтеся до відкидання журналу (-L) як до обдуманого компромісу, а не як до рефлексу.

Зробіть ще одну річ, за яку подякує вам ваше майбутнє «я»: запишіть, що ви бачили в dmesg, який пристрій ви оперували, які прапори використовували і чому. Інцидентні ретроспективи люблять факти. Файлові системи — також.