Періодично пошкоджені системні файли: корінна причина (і як це зупинити)

Що насправді означає «повторюване пошкодження»

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

Два шаблони, які варто розпізнати

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

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

Що таке пошкодження (а що — ні)

Пошкодження не завжди — файл, наповнений випадковими байтами. Це може бути:

• Обрізаний файл (характерно при втраті живлення, нестачі місця або багатому семантиці flush).
• Пошкодження метаданих (неправильні записи в директоріях, inode, що вказують на нісенітницю).
• Логічна невідповідність (пошкодження на рівні додатка, наприклад збій контрольної суми сторінки БД).
• Застарілі дані (система «успішно» записала, але пізніше читає старий вміст).

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

Парафразована ідея від John Allspaw: «Інциденти не вирішують за допомогою присікань людей; ви виправляєте систему, яка зробила наслідок імовірним.»

І так, я бачив, як команди тижнями звинувачували космічні промені, коли насправді проблема була в хиткому SATA power splitter. Всесвіт великий, але ваш стій ближчий.

Швидкий план діагностики

Це порядок дій, який швидко знаходить вузьке місце у реальному продакшені. Він не ідеальний. Він швидкий.

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

1. Підтвердіть симптом: які файли пошкоджені, коли вони змінюються і на яких хостах?
2. Перевірте логи на проблеми I/O: повідомлення ядра, помилки файлової системи, скидання контролера.
3. З’ясуйте, чи пошкодження відбувається під час читання чи запису: чи контрольні суми ламаються при читанні старих даних, або тільки після нових записів?

Друге: тріаж стеку цілісності знизу вгору

1. Стан сховища: SMART, помилки носія, стан RAID/mdadm, результати scrub у ZFS/Btrfs.
2. Транспорт/контролер: скидання лінків, журнали помилок NVMe, повідомлення прошивки HBA.
3. Пам’ять: EDAC/MCE логи, memtest, лічильники ECC.
4. Живлення та історія вимкнень: раптова втрата живлення, події PSU, «брудні» вимкнення, логи UPS якщо є.

Третє: виключіть «це наша автоматизація»

1. Перевірка артефактів: чи підписки пакетів проходять верифікацію? чи шари контейнера відповідають очікуваним digest?
2. Дрейф конфігур менеджменту: чи є плейбук, що на кожному запуску застосовує той самий «поганий» файл?
3. Поведінка відкатів/сніпшотів: чи ви відновлюєте відомий-поганий сніпшот?

Дії, що зупиняють кровотечу (робіть їх рано)

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

Режими відмов, які призводять до повторів

1) Фальшива логіка «файлова система це зробила»

Ext4, XFS, ZFS, Btrfs — жодна з них не імунна до того, що їй передали погані дані. Файлова система може виявити деякі класи помилок (особливо з контрольними сумами), але не може магічно виправити те, що CPU+RAM+контролер вже пошкодили, якщо в вас немає надлишковості та наскрізної цілісності.

Якщо ви постійно бачите пошкодження після «ремонту файлової системи», ви, ймовірно, виправили симптоми метаданих, а не причину.

2) Нестабільні носії: нудна класика

Диски не завжди вмирають драматично. Часто вони деградують. Ви побачите зростання реаліоцьованих секторів, некориговні помилки або помилки NVMe. Іноді причина — кабель або бекплейн, що дає переривчасті скидання лінку, які під навантаженням виглядають як «random I/O errors».

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

3) Порядок записів і брехня кешу (aka «він сказав, що записав»)

Стек сховища багатошаровий: application → libc → kernel page cache → filesystem → block layer → controller → device cache → flash translation layer → actual media. Кожен шар може підтверджувати успіх раніше за інших задля продуктивності. Це нормально, поки втрата харчування або баг у шляху flush не роблять ці «успішні» записи зникаючими або не впорядковують їх неправильно.

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

4) Погана пам’ять: тихий автор ваших зламаних файлів

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

5) Баги в прошивці та драйверах: пастка «все в порядку»

Сучасні NVMe-диски — це комп’ютери з підключеною флеш-пам’яттю. HBA і RAID-контролери працюють на прошивці, яка може мати творчі помилки. Драйвери ядра еволюціонують. Ідеально здоровий диск може породжувати пошкодження в парі з проблемною комбінацією прошивки+драйвера, особливо під високою чергою, при переходах енергозбереження або під час відновлення помилок.

6) Віртуалізація і сніпшоти: мандрівка в часі з наслідками

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

7) «Пошкодження», спричинене вашим пайплайном

Іноді файл «пошкоджений», тому що процес деплою записав неправильну збірку, обрізав артефакт або замінив бінарник на текстовий файл (так, таке буває). Якщо той самий файл ламається однаково після кожного деплою, ймовірно, це не SSD. Це ваш CI/CD, сховище артефактів, конфіг менеджмент або процес побудови образу.

Жарт #1: RAID — це не бекап. Це просто дуже впевнена методика втратити дані вдвічі швидше, якщо вам не пощастить.

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

Нижче — практичні завдання, які можна виконати на Linux-сервері. Кожне включає: команду, що типовий вивід означає та яке рішення прийняти. Тема постійна: збирайте докази, а потім приймайте незворотні дії.

Завдання 1: Визначте, що саме змінилося (і коли)

cr0x@server:~$ stat /usr/bin/sudo
  File: /usr/bin/sudo
  Size: 182000     Blocks: 360        IO Block: 4096   regular file
Device: 259,2 Inode: 131091      Links: 1
Access: 2026-02-05 10:11:44.000000000 +0000
Modify: 2026-02-05 09:58:12.000000000 +0000
Change: 2026-02-05 09:58:12.000000000 +0000
 Birth: 2025-12-01 03:14:55.000000000 +0000

Що означає: позначки часу Modify/Change вказують, коли змінились вміст або метадані. Якщо пошкодження з’явилося «після перезавантаження», але Modify було значно раніше, ваше перезавантаження не було причиною — лише моментом виявлення.

Рішення: Зіставте час Modify з деплоєм, cron-завданнями, logrotate, оновленнями пакетів і перезавантаженнями. Якщо немає легітимної події запису, підозрюйте сховище/RAM.

Завдання 2: Перевірте файли, керовані пакетним менеджером (виявлення широкомасштабного пошкодження)

cr0x@server:~$ sudo debsums -s
/usr/bin/sudo
/lib/x86_64-linux-gnu/libc.so.6

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

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

Завдання 3: Перевірте логи ядра на помилки I/O і скидання

cr0x@server:~$ sudo dmesg -T | egrep -i "I/O error|buffer I/O|blk_update_request|reset|nvme|ata|scsi|EXT4-fs error|XFS|BTRFS"
[Wed Feb  5 09:55:03 2026] nvme nvme0: I/O 123 QID 6 timeout, aborting
[Wed Feb  5 09:55:03 2026] nvme nvme0: Abort status: 0x371
[Wed Feb  5 09:55:05 2026] EXT4-fs error (device dm-0): ext4_find_entry:1453: inode #262402: comm systemd: reading directory lblock 0

Що означає: тайм-аути і abort говорять про некоректну поведінку пристрою або шляху. Помилки файлової системи часто — вторинні наслідки.

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

Завдання 4: Перегляньте системний журнал на предмет повторних підозрюваних

cr0x@server:~$ sudo journalctl -b -p warning..alert --no-pager | head -n 20
Feb 05 09:55:06 server kernel: EXT4-fs error (device dm-0): ext4_journal_check_start:83: Detected aborted journal
Feb 05 09:55:06 server kernel: Buffer I/O error on dev dm-0, logical block 0, lost async page write

Що означає: «Aborted journal» і «lost async page write» — не тонкі натяки. Вони вказують, що ядро не могло надійно завершити записи.

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

Завдання 5: Перевірте стан файлової системи (приклад ext4)

cr0x@server:~$ sudo tune2fs -l /dev/mapper/vg0-root | egrep -i "Filesystem state|Errors behavior|Last checked|Last mount time|Mount count|Maximum mount count"
Filesystem state:         clean
Errors behavior:          Continue
Last mount time:          Wed Feb  5 09:54:58 2026
Last checked:             Sun Jan 12 02:00:01 2026
Mount count:              39
Maximum mount count:      40

Що означає: «Errors behavior: Continue» означає, що ext4 намагатиметься продовжувати роботу після помилок. Це іноді корисно, але також може розмазувати пошкодження по файловій системі.

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

Завдання 6: Запустіть read-only перевірку файлової системи (досить безпечно)

cr0x@server:~$ sudo fsck.ext4 -fn /dev/mapper/vg0-root
e2fsck 1.46.5 (30-Dec-2021)
/dev/mapper/vg0-root: clean, 412351/6553600 files, 8123456/26214400 blocks

Що означає: -n означає «без змін», -f примусова перевірка. Clean — добре; це не виправдовує апарат, але зменшує ймовірність, що сама FS є первинною причиною.

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

Завдання 7: Перевірте SMART для SATA/SAS дисків

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

Що означає: «PASSED» — це маркетинг. Pending/uncorrectable сектора означають, що диск мав проблеми. CRC-помилки часто вказують на кабелі/бекплейн більше, ніж на сам носій.

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

Завдання 8: Перевірте стан NVMe і журнал помилок

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

Що означає: Media errors і зростаючий лічильник error log — червоні прапори. Вони можуть передувати відмові за тижні.

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

Завдання 9: Перевірте статус RAID/mdadm (програмний RAID)

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>

Що означає: [UU] — здорово. Якщо бачите [U_] або rebuild, масив деградований або відновлюється — ідеальний час для прояву латентних помилок читання.

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

Завдання 10: Перевірте LVM і device-mapper на помилки

cr0x@server:~$ sudo dmsetup status
vg0-root: 0 52428800 linear 
vg0-swap: 0 8388608 linear

Що означає: Для лінеарних відображень статус багато не покаже. Але якщо ви використовуєте dm-crypt або thin pools, статус може виявити збої, брак місця або проблеми з метаданими.

Рішення: Якщо метадані thin pool під стресом або майже повні — виправте це першочергово. Вичерпання thin pool може імітувати корупцію через I/O помилки і часткові записи.

Завдання 11: Виявлення помилок пам’яті через EDAC/MCE (системи з ECC)

cr0x@server:~$ sudo journalctl -k --no-pager | egrep -i "EDAC|MCE|Machine check|memory error" | tail -n 20
Feb 05 09:40:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0
Feb 05 09:40:12 server kernel: mce: [Hardware Error]: Machine check events logged

Що означає: Скоректовані помилки (CE) — це попередження. Вони можуть перейти в некориговані (UE). Постійний потік CE не є «нормою». Це сервер ввічливо каже, що іноді брешуть щодо стану пам’яті.

Рішення: Якщо бачите повторювані CE — заплануйте заміну DIMM. Якщо бачите UE або паніки — виводьте вузол негайно з експлуатації.

Завдання 12: Проведіть цільовий тест цілісності файлу з контрольними сумами

cr0x@server:~$ sudo sha256sum /usr/bin/sudo /lib/x86_64-linux-gnu/libc.so.6
c2b6d0b0a1e9a0d0f6c4b2f1e0d8a9f7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c2d1  /usr/bin/sudo
b4d1c2e3f4a5968778695a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4  /lib/x86_64-linux-gnu/libc.so.6

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

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

Завдання 13: Навантажте I/O та стежте за новими помилками ядра (контрольний тест)

cr0x@server:~$ sudo fio --name=verify --filename=/var/tmp/fio.dat --size=2G --rw=randwrite --bs=4k --ioengine=libaio --direct=1 --numjobs=1 --iodepth=32 --verify=crc32c --verify_fatal=1 --runtime=60 --time_based
verify: (groupid=0, jobs=1): err= 0: pid=22110: Wed Feb  5 10:05:12 2026
  write: IOPS=18.2k, BW=71.0MiB/s (74.5MB/s)(4262MiB/60001msec)
  lat (usec): min=45, max=21980, avg=172.1, stdev=311.4

Що означає: Помилки верифікації під час fio — дуже дієві. Якщо інструмент повідомляє verify mismatch — щось нижче користувацького простору пошкоджує дані.

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

Завдання 14: Перевірте на нестачу місця та вичерпання inode (тихий руйнівник)

cr0x@server:~$ df -h / /var /tmp
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/vg0-root    50G   49G  200M 100% /
/dev/mapper/vg0-var     80G   79G  300M 100% /var
tmpfs                  7.8G  1.2G  6.6G  16% /tmp

Що означає: Робота на 100% може призвести до обрізаних записів, невдалих атомарних перейменувань і напівзаписаних оновлень пакетів. З погляду додатка це виглядає як корупція.

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

Завдання 15: Підтвердіть, чи хост страждає від «брудних» вимкнень

cr0x@server:~$ last -x | head -n 12
reboot   system boot  5.15.0-94   Wed Feb  5 09:54   still running
shutdown system down  5.15.0-94   Tue Feb  4 22:10 - 22:10  (00:00)
reboot   system boot  5.15.0-94   Tue Feb  4 22:10 - 22:10  (00:00)
reboot   system boot  5.15.0-94   Tue Feb  4 17:31 - 22:10  (04:39)

Що означає: «reboot» без відповідного «shutdown» може вказувати на краш, втрату живлення або примусові ресети.

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

Три міні-історії з промислових баталій

Міні-історія 1: Інцидент через хибне припущення

Компанія: середній SaaS з флотом «ідентичних» Linux-хостів і активною ротацією on-call. Симптом: спорадичні відмови почались з повідомлень пакетного менеджера. На кількох вузлах спостерігали, що спільні бібліотеки мали «неочікуваний розмір» або не проходили перевірку контрольних сум. Перше припущення було заспокійливим: «Це просто поганий деплой.»

Вони відкотилися. Помилки повернулись. Вони переобразили систему. Та сама історія, інший тиждень. Хтось нарешті порівняв падаючі вузли і знайшов тиху спільну рису: усі вони були в одній стійці, на одному top-of-rack свічі та на тій же PDU-стрічці. Сховище було локальним NVMe, тож мережа здавалася не при справах. Це припущення — «мережа не може спричинити корупцію на локальних дисках» — стало пасткою.

Реальною причиною були брудні події живлення. Короткі провали не були достатніми, щоб перезавантажити кожен сервер, але вони створювали brownout-поведінку: контролери скидалися під час запису, пристрої зникали на мілісекунди, а ОС продовжувала працювати, поки шлях до сховища мав невдалий день. Вузли не завжди перезавантажувались. Вони просто продовжували, іноді підтверджуючи запис, що ніколи не потрапив на диск.

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

Виправлення було буденним і негайним: стабілізували живлення (заміна несправного модуля PDU, перенесення живлення стійки, валідація поведінки UPS), потім переобразили уражені хости. І, що важливо, вони змінили runbook: будь-який вузол з помилками файлової системи плюс скидання пристроїв — спочатку дренувати, потім дебажити. Ця політика запобігла тижням whack-a-mole.

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

Велика корпоративна команда хотіла прискорити збірки на внутрішньому build farm. Вони змонтували спільний файловий простір для артефактів і підкрутили налаштування: агресивний writeback, пом’якшена поведінка sync у шарі додатка та загальна установка «швидко — добре». Було швидко. Потім стало не добре.

Перші ознаки були тонкими: випадкові «archive corrupted» помилки, збої тестів, що зникали при повторному запуску, і бінарники, що падали лише в CI. Інженери звинувачували flaky tests (вічна традиція) і додавали ретраї. Ретраї «виправляли» симптом, приховуючи його.

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

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

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

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

Невелика фінансова команда мала кілька критичних Linux-вузлів. Ніякого захоплюючого заліза. Нічого передового. Їх «секрет» — дисципліна: періодичні scrub там, де підтримується, моніторинг SMART з порогами, що триггерять заміну до катастрофи, і щотижневі перевірки цілісності вибірки системних бінарників.

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

Коли DIMM витягли, він виглядав як будь-який інший: невинний і мовчазний. Але логи були чіткі — рівень помилок зростав. Якби вони чекали, наступним кроком могли бути некориговані помилки, kernel panic або гірше: прихована корупція даних, яка робить ваші виходи неправильними, поки статус задачі каже «success».

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

Їх практика була нудною: моніторинг, рання заміна, верифікація виходів і зберігання золотих образів. Вона врятувала їх від сценарію, де «все виглядало зеленим», тоді як бізнес-метрики потихеньку були неправильні.

Жарт #2: Якщо колись чуєте «воно ламається іноді», то це просто «воно ламається» у кращому костюмі.

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

1) «fsck виправив — значить ми закінчили»

Симптом: з’являються помилки файлової системи, ви запускаєте fsck, система завантажується, потім корупція повертається.

Корінна причина: підлягаюча I/O нестабільність (диск, NVMe, контролер, живлення) продовжує псувати дані.

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

2) «SMART каже PASSED»

Симптом: корупція триває; SMART overall health каже PASSED.

Корінна причина: SMART «PASSED» не прогнозує; ви ігнорували тренди атрибутів (pending sectors, CRC errors, media errors).

Виправлення: Відстежуйте дельти SMART-атрибутів. Міняйте диски на підставі зростання reallocated/pending/uncorrectable або NVMe media errors — не за однією лінією PASSED.

3) Корупція після кожного перезавантаження

Симптом: система повертається з непрацюючими пакетами або нечитаємими файлам після циклів живлення.

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

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

4) «Тільки один файл постійно ламається» (і ви його постійно замінюєте)

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

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

Виправлення: Аудитуйте запуски конфіг менеджменту та startup-скрипти. Підтвердіть атомарні патерни запису (запис у тимчасовий файл, fsync, rename) і перевірте місце на диску/inode.

5) «Бази даних пошкоджені, це має бути база»

Симптом: SQLite/Postgres/MySQL звітують про помилки контрольних сум або биті сторінки.

Корінна причина: підлягаюче сховище або пам’ять корумповані, або події «диск повний» призводять до часткових записів.

Виправлення: Перевірте цілісність на рівні хоста (SMART/NVMe, логи пам’яті), перевірте налаштування durability бази даних і переконайтеся, що під базою не закінчується місце.

6) Корупція одночасно на кількох хостах

Симптом: кілька вузлів показують схожі події «пошкоджених файлів» в один день.

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

Виправлення: Шукайте спільний радіус ураження. Порівняйте build ID, digest образів та фізичне розміщення. Зупиніть rollout, поки не доведете цілісність артефакту.

7) «Додамо ретраї»

Симптом: збірка або деплой іноді падає з mismatch контрольних сум; ретрай проходить.

Корінна причина: ви ховаєте джерело корупції (артефакт-стор, кеш, транспорт, диск) і перетворюєте це на приховану загрозу.

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

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

Крок 1: Локалізуйте шкоду

• Відключіть вузол від продакшен-трафіку або планувальників робіт.
• Зупиніть несуттєві записи (вимкніть гучні агенти, паузуйте пакетні завдання).
• Зробіть сніпшот або образ диска, якщо потрібна криміналістика, але не затягуйте заміну, коли дані під загрозою.

Крок 2: Доведіть, чи корупція триває

• Прогашуйте невелику групу стабільних бінарників і бібліотек; перевірте їх після стресу і перезавантаження.
• Запустіть I/O тест, орієнтований на цілісність (наприклад fio з verify) у контрольованому вікні.
• Перевірте пакети по системі (debsums або RPM-верифікація), щоб побачити радіус ураження.

Крок 3: Пройдіть стек від апаратури вгору

• Носій: SMART/NVMe логи, рівень помилок, тайм-аути.
• Транспорт: CRC-помилки, скидання лінків, логи HBA, перевірка кабелів/бекплейна.
• Пам’ять: EDAC/MCE, memtest, якщо дозволяє час простою.
• Живлення: частота «брудних» вимкнень, події UPS і PDU.

Крок 4: Виправлення — заміни та конфігурації, що тримаються

• Проактивно міняйте підозрілі диски. «Може бути нормально» — не SRE-стратегія.
• Замініть DIMM, якщо з’являються скоректовані помилки регулярно.
• Оновіть прошивку для NVMe/HBA, коли докази вказують на тайм-аути/скидання і у вас є відомо-гарні версії для середовища.
• Виправте нестабільність живлення; не намагайтесь лише покращити журналювання і сподіватися.

Крок 5: Перебудуйте з відомо-гарного, потім перевірте

• Переобразіть хост або перевстановіть ОС після підтвердження апаратної стабільності.
• Повторіть перевірки цілісності після перебудови: верифікація пакетів, базові хеші і короткий verify I/O тест.
• Лише після цього повертайте в продукцію.

Операційна політика, що запобігає повторенням

• Робіть mismatch контрольних сум і I/O помилки файлової системи сторінковими інцидентами.
• Тримайте «карантинний» стан для вузлів, підозрюваних у корупції записів.
• Відстежуйте дельти SMART/NVMe з часом, а не лише поточні значення.
• Валідуйте артефакти при публікації та споживанні з хешами.

Цікаві факти та історичний контекст

• Ранні файлові системи довіряли апаратурі. Багато класичних дизайнів передбачали, що диски і контролери чесні; наскрізне контрольне сумування стало мейнстримом пізніше.
• Журналювання зменшило час відновлення, але не істину. Журнальні файлові системи (як ext3/ext4, XFS) допомагають відновити консистентність метаданих після крашів, але вони не гарантують, що дані перед потраплянням у журнал були коректними.
• Прихована корупція даних старша за SSD. Перевороти бітів і неправильні записи існували й на обертових дисках; SSD додали більше прошивки і шарів трансляції.
• ECC пам’ять раніше не була стандартом. Багато флотів досі працюють на non‑ECC з міркувань вартості, а потім дивуються «неможливим» корупціям.
• CRC-помилки часто означають кабелі. Зростання UDMA CRC помилок часто виправляється перестановкою або заміною SATA/SAS кабелів чи бекплейнів, а не заміною дисків.
• Контрольні суми стали функцією сховища, не лише додатка. Файлові системи як ZFS і Btrfs популяризували вбудовані контрольні суми для виявлення (і з надлишковістю — виправлення).
• Поведінка кешу записів має давню історію брехні. Індустрія неодноразово знаходила пристрої, що неправильно підтверджують flush, особливо між поколіннями прошивок.
• «Працювало у staging» — слабкий доказ. Корупція часто потребує специфічного тепла, навантаження, черги або умов живлення, які staging ніколи не відтворює.

FAQ

1) Чи може файлова система «самостійно вилікувати» повторюване пошкодження?

Ні, якщо в неї немає і виявлення, і надлишковості. Контрольні суми виявляють; дзеркала/парність дозволяють виправити. Без надлишковості файлова система може лише скаржитися, але не виправити.

2) Якщо я перевстановлюю ОС і корупція повертається, що найімовірніше?

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

3) Чи буває це просто «погане вимкнення»?

Один некоректний shutdown може спричинити пошкодження, так. Але якщо це повторюється — самі вимкнення теж симптом: нестабільне живлення, kernel panic, watchdog reset або проблема гіпервізора.

4) Як відрізнити корупцію диска від корупції пам’яті?

Проблеми диска часто породжують I/O помилки, тайм-аути, скидання, попередження SMART/NVMe і скарги файлової системи. Помилки пам’яті можуть давати дивні, широкомасштабні збої: помилки верифікації пакетів по незв’язаних файлах, випадкові segfault, помилки декомпресії і невідповідні результати між запусками. Логи ECC (EDAC/MCE) — найшвидша підказка, якщо вони доступні.

5) Чому корупція часто вражає спочатку бази пакетів і журнали?

Вони «гарячі»: часті дрібні записи, багато fsync/rename патернів і постійний churn. Якщо шлях сховища хиткий, гарячі файли отримують перший удар.

6) SSD більш схильні до корупції ніж HDD?

Жоден із них за замовчуванням не «безпечний». SSD мають більше складності прошивки і можуть відмовити різко; HDD деградують поступово. Найкращий захист — моніторинг, надлишковість і перевірка цілісності.

7) Що робити, якщо тільки одна VM показує корупцію, а хост виглядає нормальним?

Перевірте здоров’я сховища гіпервізора, thin provisioning і історію сніпшотів/відкатів. Симптоми лише в гості можуть все ще бути спричинені брехнею з боку хоста або виснаженням ресурсів на шарі віртуалізації.

8) Чи варто змінювати файлову систему, щоб це виправити?

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

9) Якщо fio verify проходить, чи означає це, що я чистий?

Не повністю. Це означає, що корупцію не відтворили під тим тестом. Інтермітуючі проблеми можуть залежати від температури, станів живлення або профілів навантаження. Трактуйте успіх як доказ, а не як виправдання.

10) Який найшвидший «дзвінок», який можна зробити в продакшені?

Якщо бачите скидання/тайм-аути пристрою в dmesg плюс помилки файлової системи: злокуйте вузол і замініть апарат або перемістіть його з підозрілого живлення/стійки. Не сперечайтеся з фізикою.

Наступні кроки, що працюють

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

1. Збирайте докази: dmesg помилки, SMART/NVMe логи, EDAC/MCE повідомлення і вивід перевірки пакетів.
2. Карантин: злокуйте вузол, щоб він не міг продукувати більше поганих записів або отруювати нижчі шари системи.
3. Доведіть поточну корупцію: базові хеші і короткий I/O тест з фокусом на верифікацію.
4. Виправте причину: міняйте диски з ростом помилок атрибутів, міняйте DIMM при повторюваних скоректованих помилках, вирішуйте проблеми з живленням і оновлюйте прошивки, коли вони відповідають спостережуваним моделям відмов.
5. Перебудуйте чисто: переобразіть з відомо-гарного джерела, потім валідуйте цілісність перед поверненням у сервіс.
6. Запобігайте повторенням: вимагайте верифікації контрольних сум на кордонах артефактів, відстежуйте дельти SMART/NVMe і тримайте runbook, що віддає пріоритет дренуванню перед запереченням проблеми.

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