Попередження SMART у Debian 13: які атрибути дійсно передбачають відмову (та що робити)

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

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

Ви отримуєте сповіщення о 02:17. “SMART Usage Attribute: 0xC5 Current_Pending_Sector changed from 0 to 1.”
Ви дивитеся на нього, ніби це гороскоп. Диск помирає, чи у нього просто поганий день?

У Debian 13 попередження SMART або приходять рано, шумно і плутають — або пізно, тихо і дорого обходяться.
Секрет у тому, щоб знати, які атрибути насправді прогнозують відмову, які — це вигадки вендора з магією показників,
і який повинен бути наступний операційний крок, коли число сіпається.

SMART простими словами: що він може і не може сказати

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

Дві важливі істини тримають вас у розумі:

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

У Debian 13 інструменти зрілі: smartmontools (smartctl + smartd), сигнали з журналу ядра,
NVMe log pages та зворотний зв’язок зі стеку зберігання від mdadm, LVM, ZFS, btrfs і вашого гіпервізора.
Перемога — комбінувати ці сигнали у рішення: ігнорувати, спостерігати, тестувати або замінювати.

Факти та контекст, які роблять SMART зрозумілішим

Кілька пунктів контексту, які змінюють спосіб читання сповіщень:

SMART почався як вендор-залежний у 1990‑х; «стандартні» атрибути все ще по-різному інтерпретуються між вендорами.
Нормалізовані значення (VALUE/WORST/THRESH) — це шкала вендора, а не фізика. RAW ближчий до реальності, але також може бути закодований.
Пороги SMART часто встановлені, щоб уникнути RMA, а не щоб захистити ваші дані. «PASSED» не означає «здоровий».
Реаліокація існує, бо диски постачаються зі спарованими запасними секторами. Сучасні диски постійно переназначають — деяка реаліокація очікувана, але важливі тренди.
SSD ввели «знос» як першорядний режим відмови. SMART для SSD містить індикатори зносу, але не всі порівнянні між моделями.
NVMe визначив більш послідовні журнали здоров’я, ніж SATA/ATA SMART, але вендори все ще відрізняються в деталях і порогах.
Самотести і не те саме, що scrubs. SMART‑тести виконуються всередині пристрою; scrubs — це перевірка файлової системи/RAID рівня цілісності ваших реальних даних.
SMART не бачить проблем з кабелями напряму. UDMA CRC помилки — підказка, але багато проблем лінку спочатку проявляються в логах ядра.
Деякі відмови — «раптова смерть». Помилки прошивки, контролера або події живлення можуть вивести диск з ладу з чистою історією SMART.

Атрибути, які дійсно передбачають відмову (і чому)

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

1) Реаліоковані сектори: `Reallocated_Sector_Ct` (05)

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

Операційний зміст: Диск вже хоча б раз не зміг надійно зберегти дані в певному секторі.

Що прогнозує відмову:

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

2) Поточні очікувані сектори: `Current_Pending_Sector` (C5)

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

Pending‑сектори більш дієві, ніж реаліоковані, бо вони корелюють із
помилками читання, які можуть проявитися як I/O помилки зараз, а не просто як «щось сталося колись».

Рішення:

Будь-який ненульовий C5 на диску з важливими даними — це тригер для контрольованого тестування і планування заміни.
Якщо лічильник повертається до нуля після перезапису (або після scruba, що змушує читання), це все одно попереджувальний сигнал.
Якщо pending‑сектори зберігаються або зростають — замінюйте. Не домовляйтесь із ентропією.

3) Offline uncorrectable: `Offline_Uncorrectable` (C6)

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

Рішення:

Ненульовий C6 на диску з даними означає, що слід вважати, ніби у вас є непрочитувані блоки, поки не доведено протилежне.
Поєднуйте з перевірками файлової системи, RAID‑scrub і цільовими читаннями важливих областей (образи VM, бази даних).

4) Некоректовані помилки читання (варіанти вендора)

У таблицях SATA/ATA SMART ви побачите атрибути на кшталт Raw_Read_Error_Rate (01) і
Seek_Error_Rate (07). Нормалізовані значення часто марні (особливо на Seagate).
Але деякі диски відкривають додаткові лічильники некоректованих помилок.

Ключ не в назві «rate». Ключ у тому: чи повертає диск некоректовані помилки читання хосту?
Це надійніше проявляється в:

записах SMART error log
невдачах у self‑test log
повідомленнях ядра про I/O помилки
помилках контрольних сум RAID/ZFS

5) Помилки в журналі self-test (не атрибут, а вердикт)

Якщо довгий self‑test закінчується «Completed: read failure» або «Completed: unknown failure», це визнання диска,
що він не може надійно читати власну медіа.

Рішення: Якщо диск містить щось важливе, заміна — це значення за замовчуванням.

6) NVMe «critical warning» та помилки медіа

Звітування здоров’я NVMe відрізняється. Дві NVMe‑поля мають велике значення:

Critical Warning (бітова маска): якщо встановлено, пристрій піднімає руку за увагу.
Media and Data Integrity Errors: рахує відмови, які контролер не зміг відновити.

Також слідкуйте за Percentage Used (знос). Саме по собі воно не є предиктором відмов, але високий знос
разом із помилками медіа — погана комбінація.

7) Помилки рівня інтерфейсу: `UDMA_CRC_Error_Count` (C7)

Це не прогноз відмови диска. Це прогноз нестабільності кабелю, бекплейну або контролера.
Якщо C7 росте, ви псуєте собі життя помилками лінку.

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

Один цитат, який передають команди операцій десятиліттями:
«Надія — не стратегія.» — James Cameron

Жарт #1: SMART «PASSED» — як дитина, що каже «я не ламав». Цікавий індикатор, не сертифікат.

Атрибути, які марнують ваш час (більшість випадків)

Деякі SMART‑атрибути відомі переважно тому, що друкуються в кожному виводі smartctl,
а не тому, що вони прогнозують інциденти у вашій інфраструктурі.

`Raw_Read_Error_Rate` (01) і `Seek_Error_Rate` (07)

У багатьох вендорів ці RAW‑значення — величезні лічильники, що постійно зростають і нічого не означають без
пропрієтарного контексту. Люди панікують, бо число виглядає страшно. Це зрозуміло: воно велике, підписане «error», і люди схильні шукати закономірності.

Коли вони мають значення: коли у логу self‑test, SMART error log або в логах ядра також є реальні помилки читання.

`Power_On_Hours` (09) і `Start_Stop_Count` (04)

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

`Temperature_Celsius` (194/190)

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

Години польоту головки, цикли завантаження, лічильники вібрації

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

«Overall-health self-assessment test result: PASSED»

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

NVMe vs SATA: різна телеметрія, різні пастки

Debian 13 полегшує запуск як ATA SMART, так і NVMe журналів, але ментальна модель відрізняється:

SATA/ATA SMART відкриває багато атрибутів; інтерпретація частково фольклор, частково досвід, частково вендорські документи, яких у вас немає.
NVMe відкриває більш структурований журнал здоров’я з чіткішими лічильниками: media errors, unsafe shutdowns, відсоток зносу і температурні події.

Пастка з NVMe — думати, що він завжди «кращий». NVMe‑диски можуть відмовити миттєво (помилки прошивки/контролера),
і «Percentage Used» може заспокоїти людей: «Лише 12% використано, значить все добре». Помилки медіа не звертають уваги на ваш оптимізм.

Пастка з SATA — навпаки: вважати, що кожен атрибут інтерпретується. Багато з них — ні. Краще зосередитися на невеликому наборі,
який надійно відображає відмови: реаліокації, pending, uncorrectable, self‑test failures і реальні журнали помилок.

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

Коли надходить попередження SMART, ви хочете швидко відповісти на два питання:
Чи дані зараз під загрозою? і проблема в диску чи в шляху до диска?

Перше: підтвердіть, що симптом — не галюцинація моніторингу

Перевірте логи ядра на I/O помилки та скидання лінків.
Перевірте поточні значення smartctl та журнали error/self‑test.
Перевірте, чи атрибут змінився один раз або є тренд.

Друге: класифікуйте режим відмови

Деградація медіа: pending/reallocated/uncorrectable сектори, self‑test read failures.
Інтерфейс/шлях: CRC помилки, SATA link resets, таймаути, проблеми HBA, живлення/бекплейн.
Обумовлено навантаженням: помилки виявляються лише при інтенсивному читанні або лише на конкретних LBA (поганий регіон).
Здоров’я контролера NVMe: встановлено critical warning, зростають media errors, термічний троттлінг, багато unsafe shutdowns.

Третє: швидко вирішіть — замінити зараз, тестувати, або спостерігати

Замінити зараз: будь‑який стійкий ненульовий C5/C6, self‑test failures, media errors на NVMe або I/O помилки ядра на важливих дисках.
Тестувати зараз: одноразовий pending сектор, що очищується, одна реаліокація без тренду, або підозрілі але не-фатальні лічильники (запустіть long test + scrub).
Спостерігати: CRC помилки без помилок медіа після ремонту кабелів; проблеми з температурою після виправлення повітряного потоку; «PASSED» без іншого.

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

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

Завдання 1: Ідентифікуйте диск і його шлях (не гадати)

cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,TRAN,ROTA,MOUNTPOINTS
NAME   MODEL              SERIAL          SIZE TYPE TRAN ROTA MOUNTPOINTS
sda    ST8000NM000A-2KE1  ZR123ABC        7.3T disk sata    1
├─sda1                     512M part           1 /boot/efi
└─sda2                     7.3T part           1
nvme0n1 Samsung SSD 990    S7KX...         1.8T disk nvme    0
└─nvme0n1p1                               1.8T part           0 /

Що це означає: Підтвердіть, який пристрій обертовий (ROTA=1) проти SSD (ROTA=0), і зіставте mountpoints.

Рішення: Використовуйте правильний шлях до інструменту (/dev/sda vs /dev/nvme0 або /dev/nvme0n1) і не міняйте невірний диск.

Завдання 2: Отримати SMART‑зведення для SATA/ATA дисків

cr0x@server:~$ sudo smartctl -a /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
=== START OF INFORMATION SECTION ===
Model Family:     Seagate Exos 7E8
Device Model:     ST8000NM000A-2KE1
Serial Number:    ZR123ABC
User Capacity:    8,001,563,222,016 bytes [8.00 TB]
SMART support is: Enabled

=== 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       -       8
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       8
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Що це означає: «PASSED» тут не має значення; C5=1 і C6=1 — активний ризик. Reallocated=8 показує попередні переназначення.

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

Завдання 3: Дістати SMART/health журнал NVMe правильним способом

cr0x@server:~$ sudo smartctl -a /dev/nvme0
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990 PRO 2TB
Serial Number:                      S7KX...
Firmware Version:                   5B2QJXD7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 2,000,398,934,016 [2.00 TB]

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        45 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    6%
Data Units Read:                    18,345,112
Data Units Written:                 11,902,771
Host Read Commands:                 247,110,004
Host Write Commands:                183,991,201
Controller Busy Time:               2,401
Media and Data Integrity Errors:    0
Unsafe Shutdowns:                   7

Що це означає: Здоровий NVMe: немає critical warning, немає media errors, низький знос. Unsafe shutdowns можуть бути проблемою інфраструктури/живлення.

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

Завдання 4: Перевірити SMART error log (ATA), щоб побачити реальні відмови, а не лише лічильники

cr0x@server:~$ sudo smartctl -l error /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
SMART Error Log Version: 1
ATA Error Count: 2
  CR = Command Register [HEX]
  FR = Features Register [HEX]
  SC = Sector Count Register [HEX]
  SN = Sector Number Register [HEX]
  CL = Cylinder Low Register [HEX]
  CH = Cylinder High Register [HEX]
  DH = Device/Head Register [HEX]
  DC = Device Command Register [HEX]
  ER = Error register [HEX]
  ST = Status register [HEX]
Error 2 occurred at disk power-on lifetime: 28421 hours (1184 days + 5 hours)
  When the command that caused the error occurred, the device was active or idle.
  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 00 00 00 40  Error: UNC at LBA = 0x00a1b2c3 = 10629827

Що це означає: UNC = uncorrectable. Диск повернув невиправну помилку читання в конкретному LBA.

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

Завдання 5: Переглянути журнал self‑test (кабінет сповідань диска)

cr0x@server:~$ sudo smartctl -l selftest /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     28422         10629827
# 2  Short offline       Completed without error       00%     28420         -

Що це означає: Короткий тест пройшов; довгий знайшов помилку читання в LBA. Це часто: короткі тести не зачіпають достатньо поверхні.

Рішення: Заміна диска. Також запустіть вищого рівня перевірки (scrub), щоб переконатися, що надлишковість виправила дані.

Завдання 6: Запустити короткий SMART‑тест (швидка тріаж)

cr0x@server:~$ sudo smartctl -t short /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
Testing has begun.
Please wait 2 minutes for test to complete.
Test will complete after Tue Dec 29 03:14:12 2025

Що це означає: Диск прийняв запит на тест. Це не доводить здоров’я; перевіряє базові речі.

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

Завдання 7: Запустити довгий SMART‑тест (покриття поверхні)

cr0x@server:~$ sudo smartctl -t long /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
Testing has begun.
Please wait 822 minutes for test to complete.
Test will complete after Tue Dec 29 17:02:41 2025

Що це означає: Час довгого тесту реалістичний для великих HDD. Він навантажить читаннями всю поверхню.

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

Завдання 8: Слідкуйте за I/O помилками на рівні ядра та скиданнями лінків

cr0x@server:~$ sudo journalctl -k -S -2h | egrep -i 'ata[0-9]|i/o error|reset|nvme|blk_update_request|medium error' | tail -n 30
Dec 29 01:42:18 server kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 29 01:42:18 server kernel: ata3.00: failed command: READ FPDMA QUEUED
Dec 29 01:42:18 server kernel: blk_update_request: I/O error, dev sda, sector 10629827 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 29 01:42:19 server kernel: ata3: hard resetting link
Dec 29 01:42:24 server kernel: ata3: link is slow to respond, please be patient (ready=0)
Dec 29 01:42:29 server kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Що це означає: I/O помилка в секторі співпадає з LBA‑помилкою у SMART: проблема медіа. Скидання лінку можуть бути вторинними (диск бореться) або через кабель/бекплейн.

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

Завдання 9: Перевірити ріст UDMA CRC помилок (проблема шляху)

cr0x@server:~$ sudo smartctl -A /dev/sda | egrep 'UDMA_CRC_Error_Count|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       8
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       12

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

Рішення: Замініть диск (медіа). Паралельно переставте/замініть кабель або перевірте бекплейн, щоб не дозволити наступному диску успадкувати ту саму історію CRC.

Завдання 10: Запустити RAID scrub/check (mdadm) і інтерпретувати результат

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5]
md0 : active raid1 sda2[0] sdb2[1]
      7813772288 blocks super 1.2 [2/2] [UU]
      [==>..................]  check = 12.4% (970000000/7813772288) finish=420.0min speed=270000K/sec

unused devices: <none>

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

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

Завдання 11: Для ZFS — scrub і перевірка контрольних сум/помилок читання

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device or restore the affected file(s) from backup.
  scan: scrub repaired 0B in 01:12:33 with 0 errors on Tue Dec 29 02:10:01 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            sda     DEGRADED     5     0     2
            sdb     ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/vmstore:vm-102-disk-0

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

Рішення: Замініть sda, потім відновіть уражений датасет/файл з бекапу або копії. Після resilver запустіть scrub ще раз.

Завдання 12: Для btrfs — перевірити статистику пристрою (це не SMART, але це реальність)

cr0x@server:~$ sudo btrfs device stats /mnt/data
[/dev/sda2].write_io_errs    0
[/dev/sda2].read_io_errs     3
[/dev/sda2].flush_io_errs    0
[/dev/sda2].corruption_errs  2
[/dev/sda2].generation_errs  0

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

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

Завдання 13: Увімкнути і налаштувати smartd для корисних сповіщень

cr0x@server:~$ sudo apt update
...
cr0x@server:~$ sudo apt install -y smartmontools
...
cr0x@server:~$ sudo systemctl enable --now smartd
Created symlink /etc/systemd/system/multi-user.target.wants/smartd.service → /lib/systemd/system/smartd.service.

Що це означає: smartd тепер запущений і може періодично моніторити пристрої.

Рішення: Не зупиняйтесь тут. Потрібно налаштувати /etc/smartd.conf, щоб моніторити правильні пристрої (особливо за HBA) і запускати тести.

Завдання 14: Перевірити, що smartd стежить за потрібними дисками

cr0x@server:~$ sudo smartd -q showtests
smartd 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
Device: /dev/sda, will do test schedule 'S/../.././02|L/../../6/03'
Device: /dev/nvme0, will do test schedule 'S/../.././02|L/../../6/03'

Що це означає: smartd розібрав ваші розклади і буде запускати короткі тести щодня о 02:00 і довгі щосуботи о 03:00.

Рішення: Якщо критичні диски відсутні — виправте виявлення (sat passthrough, megaraid, відображення SCSI‑пристроїв) перед тим, як довіряти сповіщенням.

Завдання 15: Переглянути журнали Debian 13 від smartd

cr0x@server:~$ sudo journalctl -u smartd -S -24h | tail -n 40
Dec 29 02:00:01 server smartd[1321]: Device: /dev/sda, starting scheduled Short self-test.
Dec 29 02:02:15 server smartd[1321]: Device: /dev/sda, SMART Self-test log error count increased from 0 to 1
Dec 29 02:02:15 server smartd[1321]: Device: /dev/sda, SMART Prefailure Attribute: 5 Reallocated_Sector_Ct changed from 7 to 8

Що це означає: smartd виконує свою роботу: він запустив тест, побачив нову проблему в self‑test логі і зафіксував ріст атрибуту.

Рішення: Це територія заміни. Також збережіть повний smartctl -a вивід для тікета і постмортему.

Завдання 16: Якщо диск за HBA/RAID контролером — працюйте з цим явно

cr0x@server:~$ sudo smartctl -a -d sat /dev/sdb
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     WDC WD80EFAX-68KNBN0
Serial Number:    7SG...
...
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       34

Що це означає: Медіа виглядає добре; CRC помилки високі. Це вказує в бік шляху, а не поверхні пластини.

Рішення: Пересадіть/замініть SATA‑кабель/слот бекплейну, перевірте прошивку HBA і спостерігайте, чи C7 перестане зростати.

Жарт #2: Якщо ваша стратегія зберігання — «ми дізнаємося, що щось пішло не так, коли воно перестане працювати», вітаю з кар’єрою в службі екстреного реагування.

Три корпоративні міні‑історії з фронту SMART

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

Середня SaaS‑компанія мала флот Debian‑серверів зі локальними SSD для кешу і HDD для масиву даних.
Моніторинг сповістив про Reallocated_Sector_Ct для кількох HDD. Інженер на чергуванні кинулив оком на
«SMART overall-health: PASSED» і закрив алерт як шум. Припущення було просте: «Якщо SMART каже passed, все гаразд».

Через два дні нічна аналітична задача почала падати. Не катастрофічно — достатньо, щоб повторюватись і забивати чергу.
Латентність для панелей клієнтів поволі зросла. Графіки зберігання були заплутаними: сплески iowait, потім спокій; патерн, що виглядав як «завантажена система», а не «померлий диск».

Коли вони нарешті виконали smartctl -l selftest, довгий тест вже показав read failure на стабільному LBA.
ZFS (в одному кластері) би гучно повідомив, але цей датасет був на ext4 поверх mdadm,
і помилки проявилися як періодичні I/O помилки в логах ядра, які ніхто не зв’язав зі SMART‑попередженням.

Виправлення було нудне: замінити диск, відбудувати дзеркало, перезапустити задачу. Постмортем же дав корисні висновки.
Вони змінили політику: будь‑які pending/uncorrectable сектори на bulk‑дисках викликають планування заміни, незалежно від «PASSED».
Також навчили команду дивитися SMART error log і self‑test log, не лише на стрічку з підсумком.

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

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

Через кілька місяців один диск почав нарощувати Current_Pending_Sector. Ніхто не помітив, бо smartd робив лише короткі тести,
а pending‑сектори були в холодному регіоні, рідко читаному. Продакшн виглядав здоровим. Бекапи були «успішними», бо були інкрементальними і не торкались поганих блоків.

Потім сталося подвійне: другий диск у тому ж RAID‑групі вийшов з ладу (контролер його відкинув).
Ребілд завантажив залишковий диск, змусивши читати всю поверхню. Тоді pending‑сектори перетворилися на uncorrectable.
Масив не зміг реконструювати кілька блоків. Не весь датасет, але достатньо, щоб пошкодити кілька образів VM.

Корінна причина не в тому, що RAID марний. Корінна причина — видалення механізмів, що примушували латентні помилки проявитися при наявній надлишковості: регулярні scrubs і довгі тести.
Вони повернули щомісячні scrubs і щотижневі long tests для HDD, обмежили швидкість і планували їх у непіковий час. Скарги на латентність зменшилися.

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

Компанія зі строгим контролем змін запускала Debian 13 на базі даних із дзеркальними NVMe.
У них була політика: кожен тікет на заміну диска має містити smartctl -a,
останні 24 години логів ядра для пристрою і вивід перевірки надлишковості (mdadm check або ZFS scrub).

Якось тижня моніторинг видав алерт: NVMe «Unsafe Shutdowns» зросли. Ніхто не панікував. Диск «PASSED», нема media errors, немає critical warning.
Але політика вимагала зібрати докази, тож на чергуванні ще й подивилися останні логи ядра і помітили короткі події відключення живлення на шині PCIe.

Вони простежили до незакріпленого з’єднання розподілу живлення в PDU стійки (не драматично — трохи недозакручено після обслуговування).
Якби вони замінили NVMe, це нічого не вирішило б і приховало б проблему інфраструктури. Натомість стабілізували живлення і спостерігали лічильники.
Нових unsafe shutdowns не з’явилося. Корупції не було.

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

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

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

1) «SMART PASSED, але логи аплікації показують I/O помилки»

Симптом: База даних або хост VM бачить спорадичні помилки читання; SMART overall‑health показує PASSED.

Корінна причина: Пороги вендора м’які; зведення здоров’я не спрацьовує до пізніх стадій. Помилки медіа перші проявляються в логах/self‑test.

Виправлення: Перевірте SMART error log і self‑test log; запустіть long self‑test; якщо є read failures — замініть диск і перевірте цілісність даних через scrub.

2) «UDMA_CRC_Error_Count росте; заміна дисків не допомагає»

Симптом: CRC помилки ростуть у кількох дисків у тому ж відсіку/шляху кабелю.

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

Виправлення: Замініть/посадіть кабелі; перемістіть диск в інший відсік; оновіть прошивку HBA; перевірте PSU/бекплейн; підтвердіть, що CRC зупинився.

3) «Current_Pending_Sector = 1, потім повернувся в 0, отже все добре»

Симптом: C5 мигнув і очистився після тесту.

Корінна причина: Слабкий сектор був перезаписаний/переназначений; це може бути раннім знаком деградації поверхні.

Виправлення: Запустіть long test і scrub файлової системи/RAID; моніторьте тренд щотижня. Якщо з’являються нові pending‑сектори — замініть.

4) «Довгі SMART‑тести ламають продуктивність, тож ми їх відключили»

Симптом: Скарги користувачів під час тестів; фонові завдання вимкнені.

Корінна причина: Тести заплановані в піковий час, без обмеження I/O, без координації з навантаженням.

Виправлення: Плануйте на непіковий час; рознесіть диски у часі; обмежте швидкість scrub/check; прийміть вартість обслуговування, щоб уникнути сюрпризів під час ребілду.

5) «NVMe Percentage Used низький, але з’являються media errors»

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

Корінна причина: Проблеми контролера або NAND, не пов’язані зі зносом; дефекти прошивки або нестабільність температури/живлення.

Виправлення: Ставте media errors за реальні; оновіть прошивку, якщо політика дозволяє; перевірте температуру і події живлення; замініть пристрій, якщо помилки не зникають.

6) «Ми запустили SMART‑тест; він пройшов; корупція все ще є»

Симптом: SMART‑тести «Completed without error», але ZFS/btrfs повідомляє корупцію.

Корінна причина: SMART‑тести не перевіряють енд‑ту‑енд цілісність даних; вони можуть не торкнутися точних блоків або не виявити транзитні проблеми шляху.

Виправлення: Довіряйте контрольним сумам файлової системи над SMART. Scrub, знайдіть уражені файли, відновіть з бекапу і дослідіть контролер/кабелі.

7) «smartd запущений, але оповіщень немає»

Симптом: smartd активний; немає нотифікацій навіть коли диск явно відмовляє.

Корінна причина: smartd не налаштований стежити за всіма пристроями, особливо за HBA; або шлях оповіщень (email/alerting) зламаний.

Виправлення: Перевірте моніторинг пристроїв за допомогою smartd -q showtests; протестуйте шлях оповіщень; явно налаштуйте пристрої з правильними типами -d.

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

Чекліст A: Коли бачите pending/uncorrectable сектори (C5/C6) на SATA HDD

Зберіть докази: smartctl -a, -l error, -l selftest і останні логи ядра для пристрою.
Запустіть довгий self‑test (smartctl -t long), якщо система витримає навантаження читаннями.
Запустіть перевірку надлишковості (mdadm check / ZFS scrub / btrfs scrub) поки надлишковість ще ціла.
Якщо long test провалюється або C5/C6 зростає: негайно плануйте заміну.
Після заміни: відбудуйте/resilver, потім запустіть scrub ще раз, щоб переконатися, що помилки зникли.

Чекліст B: Коли бачите лише CRC помилки (C7) і немає помилок медіа

Підтвердіть, що C5/C6 = 0 і self‑tests чисті.
Пересадіть/замініть SATA‑кабель або перемістіть у інший слот/бекплейн.
Перевірте логи ядра на скидання лінків/таймаути.
Спостерігайте C7 протягом 24–72 годин. Він має перестати збільшуватися.
Якщо C7 продовжує зростати на декількох дисках — ескалація до HBA/бекплейн/джерела живлення.

Чекліст C: Попередження NVMe

Зберіть smartctl -a /dev/nvmeX (critical warning, media errors, температура, percentage used).
Перевірте логи ядра на PCIe AER, NVMe resets або таймаути.
Якщо встановлено critical warning або зростають media errors: замініть диск (і збережіть докази для вендора/RMA).
Якщо тільки зростають unsafe shutdowns: дослідіть живлення/PSU/PDU і раптові скидання перед тим, як звинувачувати SSD.

Чекліст D: Зробіть smartd дійсно корисним (не лише встановленим)

Оперуйте інвентар пристроїв: SATA, SAS, NVMe, USB‑мости, HBA.
Налаштуйте /etc/smartd.conf з правильними типами пристроїв і розкладами.
Перевірте парсинг і розклади: smartd -q showtests.
Перевірте оповіщення: симулюйте нотифікацію або переконайтеся, що journald інгорує в моніторинг.
Щотижня переглядайте: будь‑який ріст у realloc/pending/uncorrectable — це тікет з трендом і планом.

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

1) Які SMART‑атрибути мають будити мене вночі?

Pending‑сектори (C5), offline uncorrectable (C6), реаліокації з трендом вгору (05),
записи SMART error log із UNC, та невдачі self‑test. Для NVMe: critical warning і media/data integrity errors.

2) Чи означає ненульовий Reallocated_Sector_Ct негайну заміну?

Не завжди. Стабільна, мала кількість на старішому HDD може працювати ще довго. Але ріст — особливо під час scrubs/testів — це план заміни.
Якщо також є C5/C6 або self‑test failures — припиняйте дебати і міняйте.

3) Чому Current_Pending_Sector повернувся до нуля?

Тому що сектор успішно перезаписано або переназначено. Це очищає список pending. Це не скасовує факт, що диск мав читання, яке він не зміг коригувати. Розглядайте це як раннє попередження і слідкуйте за повторенням.

4) Чи може SMART передбачити раптову смерть SSD через помилки прошивки?

Іноді ви побачите скидання, critical warnings або зростання лічильників. Часто — ні. Помилки прошивки/контролера можуть бути раптовими.
Ось навіщо потрібні надлишковість і бекапи: щоб впоратися з відмовами без попередження.

5) Чи слід довіряти RAW чи нормалізованим SMART‑значенням?

Віддавайте перевагу RAW для лічильників, як reallocations/pending/uncorrectables/CRC. Нормалізовані значення — це шкала вендора і можуть вводити в оману.
Але не ігноруйте перетини нормалізованих порогів — вони зазвичай означають, що вендор готовий визнати диск непрацездатним.

6) Чи варто запускати короткі тести?

Так, як швидка перевірка здорового стану і для автоматизації. Ні, вони недостатні для валідації поверхні.
Якщо ви розслідуєте попередження — long test (плюс scrub/check) — це дорослий крок.

7) SMART каже, що диск у порядку, але ZFS показує помилки контрольних сум — що робити?

Довіряйте ZFS. Контрольні суми файлової системи ловлять енд‑ту‑енд корупцію, яку SMART може не побачити. Scrub, знайдіть уражені файли,
замініть підозріле залізо (диск, кабель, HBA) і відновіть з бекапу при потребі.

8) Як часто варто запускати long SMART‑тести на HDD?

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

9) Чи означають CRC‑помилки, що дані пошкоджені?

CRC‑помилки вказують на проблеми передачі по лінку; протокол виявляє і повторює. Зазвичай ви отримуєте повтори і збільшену латентність,
а не тиху корупцію. Але часті помилки лінку можуть викликати таймаути і збій вищих рівнів, тож виправте шлях.

10) Що найкорисніше зберегти в тікеті при SMART‑попередженні?

Повний вивід smartctl -a плюс SMART error log і self‑test log, та останні релевантні логи ядра.
Дані тренду (що змінилося від минулого тижня) краще за один знімок.

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

SMART‑попередження — це не філософська дискусія. Це вхід до рішення в умовах невизначеності.
Ваше завдання в Debian 13 — прийняти рішення швидко, із правильними сигналами і без забобонів.

Зосередьтесь на предиктивних сигналах: pending (C5), uncorrectable (C6), реаліокації з трендом (05), self‑test failures, записи SMART error log з UNC, NVMe critical warnings і media errors.
Розрізняйте медіа та шлях: C7 і скидання лінків часто — це кабелі/бекплейн/HBA, а не пластини.
Комбінуйте рівні: SMART + логи ядра + результати scrub/check. Файлові системи з контрольними сумами (ZFS/btrfs) безжально чесні — використовуйте їх.
Зробіть smartd реальним: налаштуйте розклади, підтвердіть моніторинг пристроїв, перевірте доставку сповіщень і зберігайте докази в тікетах.
Коли сумніви й дані важливі: евакуюйте, замініть і підтвердіть через scrub. Диски дешевші за дзвінки вночі.