ZFS zpool status -v: як знайти точний пошкоджений файл

November 14, 2025 • February 3, 2026 • Читання: 7 хв • Views: 11

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

Коли ZFS каже, що виявлена корупція, воно дуже конкретне — якщо поставити правильні питання. Суть у тому, що першим ви зазвичай побачите не «/home/alice/report.xlsx пошкоджено», а стан пулу, vdev і лічильники checksum, які виглядають так, ніби їх придумав хтось, хто ненавидить сон.

Ця стаття про те, як перетворити zpool status -v з червоного тривожного вогню на дієвий список: що зламано, де це знаходиться, чи ZFS це виправив і як витягти точний(і) пошкоджений(і) файл(и), щоб відновити або перекопіювати їх з впевненістю. Ми робитимемо це так, як у продакшні: швидка триажна перевірка спочатку, глибока криміналістика потім і профілактика завжди.

Що `zpool status -v` насправді означає

На загальному рівні zpool status відповідає на питання: «Чи пул здоровий?» і «Який пристрій залучено?» Додавання -v — це різниця між «щось не так» і «ось конкретні файли, які зараз визнані поганими.»

Але ось що люди пропускають: zpool status -v не гарантує акуратний шлях до файлу щоразу. Воно виводить шляхи лише для постійних помилок, які ZFS може асоціювати з файловими даними та метаданими. Якщо ZFS виправив дані під час scrub (використовуючи надмірність), файл може ніколи не з’явитись у списку, тому що ніколи не було постійного пошкодження. Якщо помилка в метаданих, які не можна відобразити як шлях до файлу (або декодувати без глибшого огляду), ви побачите номери об’єктів або — гірше — лише «Permanent errors have been detected» без корисного списку.

Думайте про помилки ZFS у трьох категоріях:

Виправні: читання повернуло погані дані, але ZFS мав іншу копію (mirror/RAIDZ) і вилікував блок.
Невиправні але виявлені: ZFS знає, що контрольна сума не сходиться, але не має доброї копії. Саме тоді ви починаєте бачити «permanent errors».
Операційні: таймаути, I/O помилки, відключення. Вони можуть і не означати корупцію даних відразу, але часто призводять до неї, якщо спричиняють часткові записи на неатомарних пристроях або нестабільні шляхи.

Дві жартівливі замітки, як обіцяно — знадобляться:

Жарт №1: ZFS не «губить» дані — воно просто зберігає їх у місці, існування якого ви вже не можете довести.

Жарт №2: Єдина річ більш непохитна за контрольні суми ZFS — це директор, який питає, чи це «просто перезавантаження».

Як читати важливі частини виводу status

Ось типовий вихід на старті:

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Tue Dec 24 03:10:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     2
            ata-WDC_WD80...-part1   ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        tank/media/exports/2024-archive.tar
        tank/vmstore/vm-112-disk-0.qcow2

Що важливо:

state: «DEGRADED» може означати, що диск відсутній або є помилки. «ONLINE» не означає «все добре», воно означає «пристрій присутній».
READ/WRITE/CKSUM колонки: read/write — це I/O збої; cksum — це «дані повернені, але неправильні». Останнє часто свідчить про тиху корупцію.
scan: результати scrub/resilver. «0 errors» у рядку scrub не завжди означає «ніколи нічого не сталося», це означає «scrub не знайшов невиправлених проблем у той момент».
errors: список «Permanent errors…» — золота жила. Він теж може бути неповним, коли йдеться про метадані.

Факти та історичний контекст, що дійсно допомагають

Це не тривіальні факти заради факту — кожен впливає на те, що ви робитимете далі.

ZFS створено з недовірою до носіїв. Контрольні суми працюють «від краю до краю»: дані перевіряються після зчитування з диска, а не тільки під час запису.
«CKSUM помилки» часто звинувачують шлях, а не лише диск: SATA-кабелі, HBA, бекплейни, прошивка експандера та живлення можуть перевертати біти або скидати команди.
Scrub — це проактивний аудит цілісності. Він читає кожен блок і перевіряє контрольні суми; resilver лише відтворює те, що потрібно для збереження надмірності після події пристрою.
ZFS зберігає кілька шарів метаданих. Частина корупції впливає на файл, частина — на метадані, що маплять блоки на файли. Останнє важче відобразити як шлях до файлу.
Блокові вказівники включають контрольні суми і фізичне розташування, саме так ZFS виявляє неправильні дані навіть коли диск відповів «успішно».
Копії можуть існувати без mirror: ZFS підтримує множинні копії метаданих (і за бажанням даних) через властивості на кшталт copies=2. Це змінює поведінку відновлення.
«ashift» назавжди (для того vdev). Неправильне вирівнювання розміру сектора може підвищити записову ампліфікацію і навантаження на пристрої — іноді це стає повільною причиною майбутньої корупції.
Стиснення змінює радіус ураження. Стиснуті блоки означають, що логічні офсети файлу не відображаються 1:1 на фізичні блоки, тож відповідь «яка частина пошкоджена?» може бути «запис», а не «сектор».
ZFS може лікувати при читанні. На надмірних пулах читання пошкодженого блоку може спричинити відновлення ще до того, як scrub запуститься.

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

Це послідовність, якою користуюсь коли приймаю виклики й пул тільки-но став «жовтим» — або команда додатку кричить, бо образ VM не завантажується.

1) Підтвердити область ураження: по всьому пулу чи один dataset/file?

cr0x@server:~$ sudo zpool status -v
  ...

Інтерпретація: Якщо ви бачите «Permanent errors…» зі шляхами файлів, у вас уже є список цілей. Якщо бачите лише помилки пристроїв або «too many errors», ви в зоні «спочатку стабілізація»: зупиніть кровотечу перед криміналістикою.

2) Вирішіть, чи це корупція, чи проблеми підключення

cr0x@server:~$ sudo zpool status tank
  ...
        NAME                        STATE     READ WRITE CKSUM
        ata-WDC...                  ONLINE       0     0    54

Інтерпретація: Зростаючий CKSUM з низькими READ/WRITE часто означає, що повертаються «погані» дані (носій, контролер, кабель). Зростаючі READ/WRITE або OFFLINE/FAULTED вказують більше на скиди лінку, живлення або помираючий диск.

3) Перевірте, чи scrub вже виправив проблему

cr0x@server:~$ sudo zpool status -v tank
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Tue Dec 24 03:10:11 2025

Інтерпретація: «Repaired X» означає, що ZFS знайшов погані блоки і виправив їх, використовуючи надмірність. Якщо дані виправлено, перезапустіть робоче навантаження, яке зазнало збою, і перевірте, чи проблема зникла. Якщо лишаються «Permanent errors», надмірність не вистачило для тих блоків.

4) Визначте домен відмови: один диск, один HBA, одна лінія бекплейну?

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WDC_WD80 | head
  ...

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

5) Якщо пул нестабільний, стабілізуйте його перед глибоким мапуванням

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

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

Це завдання, які я реально виконував під тиском. Кожне включає, що означає вивід і яке рішення це має спричинити.

Завдання 1: Отримати високо-сигнальний огляд пулу

cr0x@server:~$ sudo zpool status -xv
all pools are healthy

Інтерпретація: -x показує тільки проблемні пули; -v додає списки файлів, якщо вони доступні. Якщо бачите «healthy», не копайте далі. Якщо ні — працюйте далі.

Завдання 2: Витягнути детальний статус конкретного пулу

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
...
errors: Permanent errors have been detected in the following files:

        tank/projects/build-cache/index.sqlite

Інтерпретація: Навіть «ONLINE» може означати, що сталася корупція даних. Якщо написано, що «Applications may be affected», ставтесь до цього як до «вже порушено» поки не доведено протилежне.

Завдання 3: Знайти, коли почалися помилки (історія подій)

cr0x@server:~$ sudo zpool events -v | tail -n 30
  ...

Інтерпретація: Шукайте події видалення пристрою, події контрольних сум, або початок/завершення resilver. Це часто корелює з вікнами обслуговування, оновленнями ядра або тим, що хтось «прибрав кабелі».

Завдання 4: Запустити (або перезапустити) scrub навмисно

cr0x@server:~$ sudo zpool scrub tank

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

Завдання 5: Слідкувати за прогресом scrub без гадань

cr0x@server:~$ watch -n 5 "sudo zpool status tank | sed -n '1,25p'"
Every 5.0s: sudo zpool status tank | sed -n '1,25p'

  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 01:10:11 2025
        612G scanned at 1.20G/s, 110G issued at 220M/s, 4.21T total
        0B repaired, 2.61% done, 0:52:01 to go

Інтерпретація: «scanned» vs «issued» показує, чи scrub обмежений I/O. Якщо issued низький, можливо, ви упираєтесь у затримки vdev, поведінку SMR або троттлінг.

Завдання 6: Очистити помилки (тільки після розуміння, що ви чистите)

cr0x@server:~$ sudo zpool clear tank

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

Завдання 7: Перевірити, чи «CKSUM» досі зростає

cr0x@server:~$ sudo zpool status tank | awk 'NR==1,NR==40 {print}'
  ...

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

Завдання 8: Перевірити здоров’я пристрою (SMART) для конкретного підозрюваного

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "realloc|pending|uncorrect|crc|error|self-test"
  199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       23
  197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0

Інтерпретація: UDMA CRC помилки криком говорять «кабель/бекплейн/контролер», а не «носій». Перерозподілені/очікувані сектори вказують на деградацію самого диска. Жоден із цих показників не є абсолютним оракулом; використовуйте їх, щоб вибрати, що міняти в першу чергу.

Завдання 9: Перевірити журнали ядра на наявність скидів і I/O помилок

cr0x@server:~$ sudo dmesg -T | egrep -i "zfs|sd.*error|ata.*error|reset|I/O error|checksum" | tail -n 40
  ...

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

Завдання 10: Отримати точки монтування dataset і підтвердити, що шлях реальний

cr0x@server:~$ zfs list -o name,mountpoint,compression,recordsize -r tank | head -n 20
NAME                     MOUNTPOINT              COMPRESS  RECORDSIZE
tank                     /tank                   lz4       128K
tank/media               /tank/media             lz4       1M
tank/vmstore             /tank/vmstore           lz4       128K

Інтерпретація: Якщо zpool status -v перераховує tank/vmstore/..., потрібно знати, де це фізично монтується (/tank/vmstore) і які recordsize/compression можуть означати для відновлення на рівні додатка.

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

cr0x@server:~$ sudo dd if=/tank/media/exports/2024-archive.tar of=/dev/null bs=4M status=progress
  2147483648 bytes (2.1 GB, 2.0 GiB) copied, 4 s, 536 MB/s
  ...

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

Завдання 12: Якщо є снапшоти — відновіть лише файл

cr0x@server:~$ zfs list -t snapshot -o name,creation -S creation | head
NAME                          CREATION
tank/media@autosnap_2025-12-24_0300  Tue Dec 24 03:00 2025
tank/media@autosnap_2025-12-23_0300  Mon Dec 23 03:00 2025

cr0x@server:~$ sudo cp -a /tank/media/.zfs/snapshot/autosnap_2025-12-24_0300/exports/2024-archive.tar /tank/media/exports/2024-archive.tar

Інтерпретація: Це часто найшвидший «фікс»: замінити пошкоджений файл відомо-цілим варіантом. Якщо це VM-диск, краще відновити у новий файл і провести перевірки цілісності перед заміною.

Завдання 13: Якщо немає снапшотів — перевірити репліку або перекопіювати з джерела

cr0x@server:~$ sudo rsync -avh --inplace --checksum /mnt/source/2024-archive.tar /tank/media/exports/2024-archive.tar
sending incremental file list
2024-archive.tar
          4.21T 100%  1.05GB/s    1:04:10 (xfr#1, to-chk=0/1)

Інтерпретація: --checksum змушує верифікацію поза часовими мітками; --inplace контроверсійний на COW-системах, але може бути доречним, коли ви хочете перезаписати блоки без створення другої повної копії. Використовуйте обережно (див. розділ про помилки).

Завдання 14: Чисто замінити деградуючий диск

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80...-old /dev/disk/by-id/ata-WDC_WD80...-new
cr0x@server:~$ sudo zpool status tank
  scan: resilver in progress since Wed Dec 25 02:11:12 2025
        310G scanned at 1.05G/s, 92.1G issued at 320M/s, 4.21T total
        0B resilvered, 2.19% done, 3:40:21 to go

Інтерпретація: Заміна усуває корінний ризик. Вона не виправляє автоматично вже пошкоджені блоки, якщо не було надмірності і пул не може реконструювати їх під час scrub/resilver читань.

Завдання 15: Використати контрольні суми ZFS для перевірки dataset (швидка санітарна перевірка)

cr0x@server:~$ sudo zfs set readonly=on tank/media
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zfs set readonly=off tank/media

Інтерпретація: Тимчасове встановлення dataset тільки для читання зменшує змінність під час розслідування і може не дозволити додатку перезаписати докази. Не робіть цього на живих датасетах без координації з командами додатку.

Як зіставити помилки пулу з точними файлами (реальний робочий процес)

Якщо zpool status -v вже виводить шляхи файлів — вітаю, ви попереду звичайного випадку. Вам все ще треба відповісти на три питання:

Файл справді зараз пошкоджений, чи його вже виправили?
Чи корупція обмежується цим файлом, чи це ознака глибшої проблеми?
Яка найшвидша безпечна дія для відновлення?

Коли `zpool status -v` дає вам шляхи файлів

ZFS покаже шляхи, які воно може асоціювати з постійними помилками. Для кожного шляху виконайте:

Спробуйте дочитати його повністю (або принаймні критичну частину).
Якщо є надмірність, перевірте, чи читання викликає лікування (стежте за CKSUM і наступними scrub).
Відновіть зі снапшота або перекопіюйте з джерела.
Очистіть помилки і прогайте scrub ще раз, щоб підтвердити чистоту пулу.

Приклад циклу перевірки:

cr0x@server:~$ sudo zpool status -v tank
errors: Permanent errors have been detected in the following files:
        tank/projects/build-cache/index.sqlite

cr0x@server:~$ sudo sqlite3 /tank/projects/build-cache/index.sqlite "PRAGMA integrity_check;"
*** in database main ***
On tree page 914 cell 27: Rowid 188394 out of order
database disk image is malformed

Інтерпретація: База даних справді пошкоджена на рівні додатку. ZFS зробило свою роботу, сказавши «цей файл недовірений». Ваше завдання — відновити/перебудувати базу, а не сперечатися з нею.

Коли `zpool status -v` НЕ дає шляхів файлів

Це цікавіший випадок. Ви можете бачити:

«Permanent errors have been detected…» але без списку
«too many errors»
помилки, які приписуються метаданим (іноді показуються як <metadata> або ідентифікатори об’єктів залежно від платформи)

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

Визначте dataset, який містить пошкоджені блоки (часто підказано у статусі або за впливом на навантаження).
Використайте zdb для інспекції об’єктів dataset і знайдіть постраждалі номери об’єктів.
Зіставте номери об’єктів зі шляхами (коли можливо) або щонайменше визначте тип файлу (zvol, dnode, директорія тощо).

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

Завдання: Визначити dataset і чи корупція ймовірно зачіпає zvol

cr0x@server:~$ zfs list -t filesystem,volume -o name,type,used,volsize -r tank
NAME                 TYPE        USED  VOLSIZE
tank                 filesystem  3.21T  -
tank/media           filesystem  1.88T  -
tank/vmstore         filesystem  1.02T  -
tank/vmstore/vm-112  volume      120G  120G

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

Завдання: Перевірити, чи вказаний шлях всередині снапшоту, клонованого або поточного файлового простору

cr0x@server:~$ sudo zpool status -v tank | sed -n '/Permanent errors/,$p'
errors: Permanent errors have been detected in the following files:
        tank/media/exports/2024-archive.tar

cr0x@server:~$ ls -lah /tank/media/exports/2024-archive.tar
-rw-r--r-- 1 root root 4.3T Dec 21 01:01 /tank/media/exports/2024-archive.tar

Інтерпретація: Підтвердіть, що файл існує там, де ви думаєте. Звучить очевидно; в реальному житті монтування змінюються, відбуваються bind-mounts і хтось наполягатиме, що він «під /srv».

Завдання: Використати `zdb` для мапування шляху на внутрішню інформацію об’єкта (просунуто)

На багатьох OpenZFS системах ви можете запросити у zdb інформацію про шлях файлу в dataset. Поширений патерн: знайти dataset, потім запитати zdb, щоб визначити dnode/об’єкт.

cr0x@server:~$ sudo zdb -ddd tank/media | head -n 25
Dataset tank/media [ZPL], ID 52, cr_txg 1, 1.88T, 9.21M objects

    Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
         1    1   128K    1K  16.0K     512  1.50K  100.00  ZFS master node
         2    1   128K    1K  16.0K     512  14.5K  100.00  ZFS directory
  ...

Інтерпретація: Це підтверджує тип dataset (ZPL filesystem) і що zdb може читати метадані. Якщо zdb сам видає I/O помилки — зупиніться й стабілізуйте апарат.

Завдання: Визначити inode/об’єкт файлу (переносимий підхід)

cr0x@server:~$ stat -c 'path=%n inode=%i size=%s' /tank/media/exports/2024-archive.tar
path=/tank/media/exports/2024-archive.tar inode=188394 size=4639123456789

Інтерпретація: На ZFS номер inode часто відповідає внутрішньому номеру об’єкта (dnode) для ZPL filesystem. Це може бути містком між «шляхом файлу» і «об’єктом 188394», який ви бачите в інших місцях.

Завдання: Глибоко дослідити конкретний об’єкт через `zdb` (криміналістичне мапування)

cr0x@server:~$ sudo zdb -dddd tank/media 188394 | sed -n '1,120p'
Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
188394    2   128K  128K  1.00M    512  4.21T   98.11  ZFS file
Bonus System attributes
  ZPL_SIZE 4639123456789
  ZPL_GEN  4821
Indirect blocks:
  ...

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

Завдання: Довести, чи корупція локалізована чи системна

cr0x@server:~$ sudo zpool status tank | egrep -A3 "NAME|raidz|mirror|ata-|nvme"
        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz1-0                  ONLINE       0     0     0
            ata-WDC...-part1        ONLINE       0     0     0
            ata-WDC...-part1        ONLINE       0     0     2
            ata-WDC...-part1        ONLINE       0     0     0

Інтерпретація: «2 CKSUM на одному диску» може бути одиничним випадком бит-рот або «чихом» кабелю. «Тисячі на кількох дисках» зазвичай — інфраструктурна проблема: HBA, бекплейн, прошивка, живлення або партія дефектних дисків.

Завдання: Якщо помилки на одному топ-рівневому vdev — зрозумійте радіус ураження

cr0x@server:~$ sudo zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH
tank        21.8T  16.2T  5.6T        -         -    22%    74%  1.00x  ONLINE
  raidz1-0  21.8T  16.2T  5.6T        -         -    22%    74%

Інтерпретація: Одно-vdev пулі — поширене явище. Якщо цей vdev має проблеми, цілісність всього пулу залежить від нього. Багато-vdev пули можуть мати ізоляцію відмов, але й більше операційної складності.

Завдання: Перевірити, чи задіяні спеціальні vdev або пристрої метаданих

cr0x@server:~$ sudo zpool status tank | sed -n '1,120p'
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ...
        special
          mirror-1                  ONLINE       0     0     0
            nvme-SAMSUNG...         ONLINE       0     0     0
            nvme-SAMSUNG...         ONLINE       0     0     0

Інтерпретація: Якщо спеціальний vdev (metadata/small blocks) деградує, ви можете бачити «випадкові» симптоми корупції по різних датасетах. Лікуйте special vdev як нервову систему пулу — бо воно нею і є.

Завдання: Якщо підозрюєте «погану RAM» або транзієнтну корупцію пам’яті

cr0x@server:~$ sudo zpool status -v tank
  status: One or more devices has experienced an error resulting in data corruption.
  ...

Інтерпретація: ZFS не імунний до поганої RAM. ECC допомагає. Без ECC можна працювати з ZFS, але треба бути більш параноїчним: повторювані помилки контрольних сум на різних дисках без чіткої апаратної причинності можуть натякати на пам’ять. Корелюйте з журналами системи, крахами та іншими аномаліями.

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

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

Компанія, з якою я працював, мала «просте» правило: якщо zpool status каже ONLINE, сховище в порядку. Це правило жило в рунебуку і зрештою піднялося від «корисного скорочення» до «політики».

Одного ранку образ VM не завантажився. Логи гіпервізора показували I/O помилки; нода зберігання показувала пул ONLINE. Тому відповідальний оголосив, що рівень зберігання «чистий» і штовхнув команду віртуалізації «ремонтувати гість». Класична гаряча картопля, але з більшою кількістю Slack-каналів.

Хтось нарешті запустив zpool status -v (не просто zpool status) і побачив постійну помилку з точним бек-файлом .qcow2. Пул був ONLINE, бо vdev присутні; дані були не в порядку, бо пул мав невиправні помилки контрольних сум у кількох блоках.

Неправильне припущення було не в «ZFS брешуть». Воно було в «ONLINE означає здоровий». ONLINE означає «пул доступний». Воно не гарантує, що кожен байт цілий. Після того команда змінила правило: сховище «зелений» лише якщо zpool status -xv чистий і останній scrub пройшов без невиправлених помилок.

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

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

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

На папері виглядало відповідально: менше scrub, менше I/O, приємніші прибори. На практиці це розтягнуло вікно виявлення. Один маргінальний SAS-кабель почав давати періодичні помилки контрольних сум. Нічого не падало. Пул продовжував лікувати, що міг. І через рідкість scrubs проблема лишалась невидимою досить довго, щоб другий диск розвинув справжні медіа-помилки.

До моменту місячного scrub він знайшов невиправні блоки, розсіяні по кількох dataset. zpool status -v перерахував ряд файлів, але ушкодження метаданих означало, що деякі помилки не були чітко софтмеповані на шляхи. Відновлення стало сумішшю відкатів зі снапшотів, перевірок баз даних і пояснень керівництву, чому «у нас RAIDZ, тож ми в безпеці» — не найкраща фраза в постмортемі.

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

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

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

Найуспішніший інцидент з корупцією, який я бачив, був майже антикліматичним. Нода зберігання повідомила кілька CKSUM помилок і zpool status -v перерахував два файли: експортований архів і невеликий сегмент WAL Postgres.

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

Вони зробили базову рутину: призупинили завдання інжесту, що торкалось датасету, відновили два файли зі снапшоту годиною раніше і прогнали scrub, щоб перевірити відсутність інших невиправлених помилок. Також подивилися SMART і помітили UDMA CRC помилки на одному диску, під час вікна техпідтримки поміняли кабель і спостерігали, як лічильник CKSUM перестав рухатись.

Без героїчного zdb спелункінгу. Без «можливо файл сам себе відновить». Просто дисциплінована гігієна. Пост-інцидентний огляд тривав 20 хвилин, бо драми майже не залишилось — саме такий огляд і кращий.

Мораль: снапшоти не запобігають корупції, але вони перетворюють її на незручність. А в корпоративному житті незручність — це часто вже перемога.

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

Помилка 1: Очищення помилок до відновлення файлів

Симптом: Ви виконуєте zpool clear, статус виглядає чистим, а потім додаток читає файл і знову падає — або ви втрачаєте слід, які файли були торкнуті.

Виправлення: Розглядайте список «Permanent errors» як артефакт інциденту. Скопіюйте його в тікет, відновіть/замініть файли, потім очистіть і програйте scrub, щоб підтвердити. Clear для перевірки повторення, а не для відмови.

Помилка 2: Припущення, що CKSUM означає «диск поганий» (може бути, але не завжди)

Симптом: Ви замінюєте диск, resilver завершується, а CKSUM помилки продовжують зростати — іноді на новому диску.

Виправлення: Перевірте SATA/SAS кабелі, бекплейни, HBA, прошивку експандера і стабільність живлення. Дивіться SMART UDMA CRC лічильники і журнали ядра на предмет скидів лінку.

Помилка 3: Запуск scrub на нестабільному обладнанні

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

Виправлення: Стабілізуйте спочатку. Scrub — це читання всієї поверхні. Якщо шлях ненадійний, ви змушуєте систему торкатися слабкого місця знову і знову. Замініть кабель/HBA/диск за потреби, потім scrub.

Помилка 4: Плутати «repaired 0B» з «ніколи не було корупції»

Симптом: Scrub показує «0B repaired», але ви все ще бачите постійні помилки або корупцію на рівні додатка.

Виправлення: «0B repaired» може означати або «нічого не було не так», або «нічого не можна було виправити». Завжди перевіряйте секцію «errors:» і лічильники помилок на пристроях.

Помилка 5: Ігнорування метаданих/спеціальних vdev

Симптом: Випадкові файли по різних dataset падають; zpool status -v вивід скупий або дивний; продуктивність стає непередбачуваною.

Виправлення: Перевірте, чи існують special vdev і чи вони здорові. Ставтесь до них критично. Якщо special vdev падає і у вас немає надмірності — пул фактично може бути втраченим, навіть якщо диски даних в порядку.

Помилка 6: Поводитися з файлом диска VM як із звичайним файлом під час відновлення

Симптом: Ви відновили .qcow2 або raw образ «на місці» поки VM працювала; згодом з’явилась тонка корупція файлової системи у гості.

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

Помилка 7: Увімкнення «оптимізації» без розуміння патернів запису

Симптом: Після зміни recordsize, compression або використання rsync --inplace ви бачите гіршу фрагментацію, довші scrubs або несподівані стрибки латентності.

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

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

Чекліст A: План дій при виявленій корупції

Зберіть докази: zpool status -v, zpool events -v, витяги з dmesg.
Визначте, чи пул стабільний (пристрої не флапають). Якщо нестабільний — пріоритет стабілізація апаратури.
Якщо zpool status -v перераховує файли — інвентаризуйте їх і класифікуйте: критичні БД/VM спочатку.
Запустіть або заплануйте scrub (коли стабільно). Моніторьте прогрес і помилки.
Відновіть/замініть пошкоджені файли зі снапшотів або джерела.
Очистіть помилки (zpool clear) тільки після ремедіації.
Повторно проскребіть, щоб верифікувати і стежити за регресією.
Визначте корінь проблеми апаратно: SMART, кабелі, прошивка контролера, події живлення.

Чекліст B: Покроково знайти «точний файл»

Запустіть zpool status -v. Якщо отримали шляхи файлів — зупиняйтесь, вони вже є.
Якщо шляхів немає — ідентифікуйте вражений vdev/диск через лічильники помилок.
Визначте ймовірний dataset за впливом на навантаження (який mountpoint/додаток показує помилки) і за історією подій.
Використайте stat на підозрілих файлах, щоб отримати inode/номери об’єктів.
Використайте zdb для інспекції dataset і деталей об’єкта; підтвердіть типи об’єктів.
Коли маєте підозрілий файл/об’єкт — спробуйте контрольовані читання для підтвердження.
Відновіть зі снапшоту/репліки; валідуйте на рівні додатка (перевірки БД, тести архівів, завантаження VM).

Чекліст C: Перевірка після виправлення

zpool status -xv має бути чистим.
Scrub завершується з 0 errors.
CKSUM лічильники припиняють зростання після відновлення нормального навантаження.
SMART і журнали ядра не показують скидів/таймаутів.
Тести відновлення доводять, що бекапи/снапшоти валідні.

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

1) Чи `zpool status -v` завжди показує точний шлях до файлу?

Ні. Воно показує шляхи файлів, коли ZFS може зіставити постійні помилки з файлом у ZPL filesystem. Якщо корупція в метаданих, зачіпає немаповані об’єкти, стосується zvol або ZFS не може безпечно вирішити шлях — ви можете не отримати ім’я файлу або побачити лише посилання як об’єкти.

2) У чому різниця між READ, WRITE і CKSUM помилками?

READ/WRITE — це I/O збої (пристрій не зміг прочитати/записати успішно). CKSUM означає, що пристрій повернув дані, але вони не збігаються з очікуваною контрольної сумою — часто вказує на тиху корупцію або проблеми шляху (кабель/HBA/бекплейн).

3) Якщо ZFS виправив дані під час scrub, чи треба щось робити?

Так: потрібно з’ясувати корінну причину. Виправлення означає, що надмірність врятувала вас цього разу. Перевірте лічильники пристроїв, SMART і журнали. Одна виправлена подія може бути космічним лучем; повторювані виправлення — апаратна проблема, що претендує на повну зайнятість.

4) Чи слід одразу запускати scrub після виявлення помилок?

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

5) Який найшвидший спосіб «виправити» перелічений пошкоджений файл?

Відновіть його зі снапшоту (/path/.zfs/snapshot/...) або перекопіюйте з відомо-цілого джерела. Потім очистіть помилки і прогляньте scrub, щоб верифікувати. Для баз даних і образів VM робіть також перевірки на рівні додатка.

6) Чи може поганий SATA/SAS кабель справді спричиняти помилки контрольних сум?

Абсолютно. Це одна з найпоширеніших «не може бути цього» причин. UDMA CRC лічильник в SMART і журнали ядра про скиди лінку — сильні сигнали. Замініть кабель, пересмикніть конектори і перевірте бекплейн.

7) Якщо я заміню диск, чи коруптований файл автоматично відновиться?

Лише якщо надмірність дозволяє реконструювати поганий блок і пул реально читає та відновлює його (scrub/heal-on-read). Якщо пул ніколи не мав доброї копії (або корупція була у всіх копіях), заміна заліза не відновить дані — потрібні снапшоти/бекапи.

8) Чому `zpool status` іноді каже «applications are unaffected», коли перераховує помилки?

Цей рядок зазвичай з’являється, коли ZFS виявив і виправив проблему (або вважає, що виправив). Сприймайте це як «немає негайних I/O збоїв, помічених додатками», а не як гарантію. Якщо є постійні помилки — частина даних непотрібна довірі.

9) Що означає «too many errors»?

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

10) Чи можна використати `zpool clear`, щоб позбутись страшного повідомлення?

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

Висновок

zpool status -v — один із рідкісних інструментів в інфраструктурі, який одночасно чесний і корисний: він каже те, що ZFS може довести, а не те, що ви хочете почути. Коли воно виводить список файлів, ставтесь до цього як до хірургічного чек-листа — перевірте, відновіть, валідуйте, потім очистіть і знову проскребіть. Коли шляхи не виводяться, не панікуйте; це означає, що корупція в метаданих або її важко зіставити, і це сигнал стабілізувати апарат і заглибитись у zdb та міркування на рівні об’єктів.

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