Попередження SMART у Proxmox: які атрибути справді прогнозують відмову

Як SMART реально працює (і як Proxmox це споживає)

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

SMART дає три види сигналів, що мають оперативне значення:

• Флаги відмови (загальний SMART «PASSED/FAILED», NVMe «critical_warning»). Це грубий інструмент. Деякі диски відмовляють, не активувавши їх. Інші активують їх запізно.
• Лічильники деградації носія (reallocated sectors, pending sectors, uncorrectables, NVMe media errors). Вони корелюють із проблемами поверхні або NAND і краще передбачають майбутнє, ніж більшість інших показників.
• Лічильники транспорту та середовища (CRC errors, історія температур, unsafe shutdowns). Часто це про кабелі, бекплейни, живлення й поведінку.

Proxmox зазвичай отримує дані SMART через smartmontools (smartctl/smartd) для SATA/SAS і через журнали NVMe для NVMe. В інтерфейсі ви часто бачите підсумоване «Health» плюс кілька атрибутів. Підсуми потрібні людям. Інциденти — для сирих даних.

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

Цитата, яку варто тримати поруч із записником на викликах: Надія — це не стратегія. — генерал Гордон Р. Салліван. Це не лише про сховища, але чудово підходить до рішень «воно, мабуть, нормально» щодо дисків.

Жарт №1: SMART — як звіт про травми у малюка: галасує не про те, що варто, тихо про те, що страшно.

Цікаві факти та коротка історія, що змінюють сприйняття SMART

• SMART виник до сучасних SSD. Він став популярним у 1990-х для обертових дисків, і багато атрибутів досі носять HDD-припущення.
• «Нормалізовані» значення — це вигадка вендора. Атрибут «VALUE/WORST/THRESH» масштабований і визначається виробником; raw-лічильник часто більш придатний для дій.
• Ранні SMART був про «прогнозування відмови». Оригінальна обіцянка — попередження перед відмовою. На практиці багато відмов бувають раптовими (електроніка, прошивка, живлення).
• Флотові дослідження на кшталт Backblaze популяризували кілька атрибутів. Великі дані зробили відомими reallocated і pending сектора для HDD, але їхній зв’язок не ідентичний для всіх моделей.
• SMART для SSD менш стандартизований, ніж думають. Індикатори зношення (percentage used, media wearout) корисні, але вендорозалежні журнали все ще мають значення.
• Тести SMART — «офлайн», але не безпечні. Довгі тести можуть навантажити сумнівні диски й уповільнити продуктивність; це корисно, коли ви верифікуєте рішення про заміну.
• Помилки транспорту часто не пов’язані з диском. Зростання CRC error сигналить «кабель/бекплейн» більше, ніж «пошкодження носія».
• ZFS і Ceph вже роблять власну перевірку істини. ZFS checksum errors і Ceph «bluestore» помилки можуть виявити корупцію навіть коли SMART мовчить.
• Прошивка диска може прозоро перемаповувати сектори. Reallocation іноді відбувається проактивно; диск може замінити слабкі сектори, перш ніж ви побачите uncorrectable read.

Атрибути SMART, які справді прогнозують відмову

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

Для SATA HDD: три великі, що мають найбільше значення

1) Reallocated Sector Count (ID 5)

Це канонічний показник «носій деградує». Reallocated sector — це сектор, який диск не зміг надійно читати/записувати й замінив на запасний сектор.

Як трактувати в продукції:

• Нуль — базове значення. Ненульовий показник означає, що диск уже використав спари.
• Стабільний ненульовий може бути прийнятним, якщо він не зростає тижнями і scrubs не показують помилок читання.
• Зростання reallocations — тригер на заміну. Не через саму цифру, а тому що диск повідомляє, що продовжує програвати боротьбу.

2) Current Pending Sector (ID 197)

Pending sectors гірші за reallocations у короткій перспективі. Це сектори, які диск важко читає й ще не перемапував — часто тому, що потрібен успішний запис, щоб підтвердити, чи можна перемапувати.

Оперативне значення: у вас є дані, які диск не може послідовно прочитати. Це викликає таймаути, повільні читання і зрештою uncorrectable errors.

Правило рішення: Pending > 0 на члені ZFS/RAID заслуговує негайної перевірки: запустіть довгий тест і перевірте статус ZFS/Ceph. Якщо pending зберігається або збільшується — плануйте заміну.

3) Uncorrectable Sector Count / Offline Uncorrectable (ID 198) and Reported Uncorrectable Errors (ID 187)

Якщо диск визнає, що не зміг виправити читання під час офлайн-сканування (198) або під час нормальної роботи (187), розглядайте це як «ризик цілісності даних присутній».

У RAIDZ/дзеркалах ви можете вижити. У однодискових файлових системах — можливо, ні. У будь-якому випадку диск вже не «нудний», а «нудність» — бажаний стан.

Для SATA SSD: атрибути, що мають значення

1) Media Wearout Indicator / Percentage Used / Wear Leveling Count

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

• повільніші записи
• збільшення накладних витрат на виправлення помилок
• в деяких моделях — режим лише для читання

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

2) Reallocated sectors / reallocation events (варіюється)

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

3) Uncorrectable errors

Uncorrectables на SSD — поганий знак. Вони рідші ніж у вмираючих HDD, і коли виникають, часто означають проблеми з контролером/NAND, що не покращаться.

Для NVMe: кілька полів, що важать більше за десяток SATA-атрибутів

1) Critical Warning

Це бітова маска. Кожне ненульове значення потребує уваги. Воно може вказувати на низький резерв, проблеми з температурою або режим only-read для носія.

2) Percentage Used

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

3) Media and Data Integrity Errors

Часто виводиться як «Media and Data Integrity Errors» у NVMe SMART. Ненульове і зростаюче значення означає, що пристрій не може доставити коректні дані без відновлення.

4) Error Information Log Entries

Це лічильник «щось постійно йде не так». Він може інкрементуватися і для відновлюваних помилок, тому корелюйте з латентністю, I/O error у логах та ZFS checksum errors.

Тренд важливіший за поріг

Більшість SMART «THRESH» виставлені так низько, що коли вони спрацьовують — у вас уже був поганий тиждень. Ваші операційні пороги мають бути консервативнішими:

• Будь-яке збільшення pending або uncorrectables потребує негайного розслідування.
• Reallocated sectors, що зростають місяць у місяць — запускають планову заміну.
• NVMe media errors, що зростають — планування заміни; швидке зростання — термінова заміна.
• Транспортні помилки, що зростають — робота з кабелями/бекплейном/живленням перед тим, як звинувачувати диск.

Шумні атрибути, що марнують ваш час

Деякі SMART-атрибути відомо вводять в оману, бо виробники кодують кілька підлічильників в один raw-рядок або тому, що атрибут залежить від навантаження. Панелі люблять ці показники, бо вони рухаються. Інженери їх ненавидять, бо вони не відповідають на питання «випаде цей диск?»

Raw Read Error Rate (ID 1) та Seek Error Rate (ID 7)

У багатьох моделей Seagate ці raw-числа виглядають жахливо і постійно ростуть навіть на здорових дисках. Це не ваш інцидент. Трендуйте нормалізоване значення, якщо треба, але не міняйте диск тільки через страшний raw read error rate.

Hardware ECC Recovered (ID 195)

Високі лічильники відновленої ECC часто означають, що механізм корекції помилок працює. Це не обов’язково погано. Стає цікавим лише якщо це поєднується з uncorrectables, таймаутами або ZFS checksum errors.

Spin Retry Count (ID 10) та Start/Stop Count (ID 4)

Це залежить від навантаження та енергоменеджменту. Start/stop counts особливо страждають від агресивного паркування голівки. Високі значення не обов’язково прогнозують відмову; вони прогнозують, що ви налаштували енергоменеджмент як на ноуті.

Power-On Hours (ID 9)

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

Temperature (ID 194/190)

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

Де Proxmox показує SMART і що це насправді означає

У Proxmox VE ви зазвичай бачите SMART під node → Disks → SMART. Він також може відобразити статус у вью сховища залежно від налаштувань. UI зручний для швидкого погляду, але не там роблять root cause analysis.

Використовуйте UI, щоб помітити «щось змінилося». Потім переходьте до shell і витягніть:

• повний набір SMART-атрибутів (не лише ті, що UI рендерить)
• SMART error log
• історію self-test
• ядрові логи, що показують таймаути/ресети
• статус ZFS/Ceph scrub та checksum

Також: Proxmox часто працює на хостах з HBA, бекплейнами і іноді RAID-контролерами. SMART passthrough може бути неповним. Якщо SMART відсутній або завжди повертає «UNKNOWN», це не тому, що диск загадковий; це ваш шлях до сховища непрозорий.

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

Це ті завдання, які я насправді виконую, коли з’являються попередження SMART у Proxmox. Кожне містить «а що далі» рішення, бо збирати числа без рішень — просто конкурсне накопичення логів.

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

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINT
NAME   SIZE MODEL               SERIAL            TYPE MOUNTPOINT
sda   3.6T  ST4000NM0035-1V4    ZC1ABC12          disk
sdb   3.6T  ST4000NM0035-1V4    ZC1ABD34          disk
nvme0n1 1.8T INTEL SSDPE2KX020T8 PHBT1234001      disk

Значення: Зіставте імена Linux з фізичними дисками (модель + serial). Імена пристроїв у Proxmox можуть змінюватися після перезавантажень або змін HBA.

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

Завдання 2: Витягніть повний SMART summary для SATA/SAS диска

cr0x@server:~$ sudo smartctl -a /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-3-pve] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     ST4000NM0035-1V4107
Serial Number:    ZC1ABC12
LU WWN Device Id: 5 000c50 0a1b2c3d4
Firmware Version: SN04
User Capacity:    4,000,787,030,016 bytes [4.00 TB]
SMART support is: Available - device has SMART capability.
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   098   098   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Значення: «PASSED» не скасовує pending/uncorrectables. Тут ми маємо reallocations, pending сектори й offline uncorrectables: класична проблема носія.

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

Завдання 3: Витягніть NVMe health і критичний warning

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-3-pve] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       INTEL SSDPE2KX020T8
Serial Number:                      PHBT1234001
Firmware Version:                   VDV10131
PCI Vendor/Subsystem ID:            0x8086
IEEE OUI Identifier:                0x5cd2e4
Total NVM Capacity:                 2,000,398,934,016 [2.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       1.4
Number of Namespaces:               1

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Critical Warning:                   0x00
Temperature:                        44 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    63%
Media and Data Integrity Errors:    0
Error Information Log Entries:      18

Значення: Percentage Used вже помітний (63%), але сам по собі не означає кінець ресурсу. «Error Information Log Entries» ненульові; корелюйте з логами й симптомами продуктивності.

Рішення: Якщо Critical Warning ненульовий або Media and Data Integrity Errors зростає — плануйте заміну. Якщо лише error log entries зростають, але немає integrity errors, спочатку дослідіть прошивку/драйвер/тайм-аути.

Завдання 4: Перевірте SMART error log (список сповідей диска)

cr0x@server:~$ sudo smartctl -l error /dev/sda
SMART Error Log Version: 1
ATA Error Count: 3
  CR = Command Register [HEX]
  FR = Features Register [HEX]
  SC = Sector Count Register [HEX]
  SN = Sector Number Register [HEX]
  ...
Error 3 occurred at disk power-on lifetime: 4231 hours
  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  ...
  40 -- 51 0008  0000001a2b3c  ...
  Commands leading to the command that caused the error were:
  READ FPDMA QUEUED

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

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

Завдання 5: Перевірте історію self-test

cr0x@server:~$ sudo smartctl -l selftest /dev/sda
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       10%      4232         0x0000001a2b3c
# 2  Short offline       Completed without error       00%      4200         -

Значення: Довгий тест натрапив на помилку читання на вказаному LBA. Це не «поспостерігаємо». Це «плануйте заміну».

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

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

cr0x@server:~$ sudo smartctl -t short /dev/sda
Please wait 2 minutes for test to complete.
Test will complete after Tue Dec 26 02:16:04 2025
Use smartctl -l selftest /dev/sda to read test results.

Значення: Короткі тести швидко ловлять очевидні проблеми. Вони не повністю сканують поверхню.

Рішення: Якщо короткий тест провалюється — дискусій немає. Замінюйте. Якщо він пройшов, але є pending/uncorrectables — запустіть extended далі.

Завдання 7: Запустіть розширений SMART тест (surface scan, «доведіть це» тест)

cr0x@server:~$ sudo smartctl -t long /dev/sda
Please wait 411 minutes for test to complete.
Test will complete after Tue Dec 26 09:06:11 2025
Use smartctl -l selftest /dev/sda to read test results.

Значення: Розширені тести сканують поверхню і виводять маргінальні сектори на яв.

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

Завдання 8: Визначте, чи CRC помилки — це кабель/бекплейн, а не диск

cr0x@server:~$ sudo smartctl -A /dev/sda | egrep 'UDMA_CRC_Error_Count|CRC|199'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       47

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

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

Завдання 9: Корелюйте з ядровими логами на предмет таймаутів і ресетів

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i 'ata[0-9]|reset|timeout|I/O error|nvme'
Dec 26 01:41:08 server kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 26 01:41:08 server kernel: ata3.00: failed command: READ FPDMA QUEUED
Dec 26 01:41:09 server kernel: ata3: hard resetting link
Dec 26 01:41:14 server kernel: blk_update_request: I/O error, dev sda, sector 43905102 op 0x0:(READ)

Значення: Ресети лінку плюс I/O errors: може бути носій, а може бути транспорт. Поєднайте це з SMART 199 і 5/197/198.

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

Завдання 10: ZFS health: що файловa система думає (зазвичай правду)

cr0x@server:~$ sudo zpool status -v
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device and run 'zpool clear' or 'zpool replace'.
  scan: scrub repaired 0B in 00:18:11 with 0 errors on Tue Dec 24 03:12:18 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        rpool                       DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            ata-ST4000NM0035_ZC1ABC12  FAULTED     12    0    34  too many errors
            ata-ST4000NM0035_ZC1ABD34  ONLINE      0    0     0

errors: Permanent errors have been detected in the following files:
/rpool/vm-100-disk-0

Значення: ZFS бачить реальні помилки читання/checksum і відмовив пристрій. Це більше, ніж «SMART warning»; це інцидент цілісності.

Рішення: Замініть диск негайно. Потім опрацюйте постійні помилки: відновіть із реплікації/резервної копії для уражених блоків або VM-дисків.

Завдання 11: ZFS scrub за потреби (коли потрібна правда, а не втіха)

cr0x@server:~$ sudo zpool scrub rpool
cr0x@server:~$ sudo zpool status rpool
  pool: rpool
 state: ONLINE
  scan: scrub in progress since Tue Dec 26 02:22:10 2025
        215G scanned at 1.20G/s, 48.1G issued at 273M/s, 2.10T total
        0B repaired, 2.31% done, 02:41:18 to go
config:

        NAME                       STATE     READ WRITE CKSUM
        rpool                      ONLINE       0     0     0
          mirror-0                 ONLINE       0     0     0
            ata-ST4000NM0035_ZC1ABC12  ONLINE       0     0     0
            ata-ST4000NM0035_ZC1ABD34  ONLINE       0     0     0

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

Рішення: Якщо scrub повідомляє помилки — дійте негайно. Якщо scrub чистий, але SMART показує pending/uncorrectables — все одно плануйте заміну: scrub може пропустити сектори, які зараз не задіяні.

Завдання 12: Швидка перевірка Ceph (якщо ваш кластер Proxmox її використовує)

cr0x@server:~$ sudo ceph -s
  cluster:
    id:     8f3c2d3e-1b2a-4c5d-9e10-1a2b3c4d5e6f
    health: HEALTH_WARN
            1 osds down
            2 slow ops, oldest one blocked for 31 sec

  services:
    mon: 3 daemons, quorum a,b,c (age 4h)
    mgr: a(active, since 2d)
    osd: 12 osds: 11 up (since 3m), 12 in (since 7d)

  data:
    pools:   4 pools, 256 pgs
    objects: 1.2M objects, 4.3 TiB
    usage:   13 TiB used, 24 TiB / 37 TiB avail
    pgs:     254 active+clean, 2 active+degraded

Значення: Ceph каже, що один OSD down і операції сповільнюються. SMART може бути причетним, але пріоритет — стан Ceph.

Рішення: Ідентифікуйте хост і диск down OSD, перевірте SMART/NVMe логи і замініть/відновіть OSD. Не залипайте на SMART, поки Ceph втрачає кров.

Завдання 13: Зіставте Ceph OSD з фізичним диском (припиніть гадати)

cr0x@server:~$ sudo ceph-volume lvm list
====== osd.4 ======
  [block]       /dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC1ABC12
  [block.db]    /dev/nvme0n1p2
  devices       /dev/sda

====== osd.5 ======
  [block]       /dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC1ABD34
  [block.db]    /dev/nvme0n1p3
  devices       /dev/sdb

Значення: Тепер ви можете прив’язати «osd.4» до конкретного серійного номера й відсіку.

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

Завдання 14: Шукайте SATA/NVMe PCIe помилки (коли «проблема диска» — насправді проблема платформи)

cr0x@server:~$ sudo journalctl -k --since "24 hours ago" | egrep -i 'pcie|aer|nvme.*reset|controller is down'
Dec 25 18:12:44 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:02:00.0
Dec 25 18:12:44 server kernel: nvme nvme0: controller reset
Dec 25 18:12:46 server kernel: nvme nvme0: I/O 37 QID 5 timeout, aborting

Значення: PCIe AER corrected errors і ресети контролера часто про power management, баги прошивки, riseri або сумнівні слоти — не про зношення NAND.

Рішення: Перед RMA NVMe перевірте BIOS/прошивку, відключіть агресивний PCIe ASPM якщо треба, пересядьте пристрій і валідуйте термальні умови. Замініть диск, якщо з’являться media errors або ресети триватимуть після виправлень платформи.

Завдання 15: Трендуйте SMART-атрибути з часом (бо «чи стає гірше?» — реальне питання)

cr0x@server:~$ sudo smartctl -A /dev/sda | awk 'NR==1 || $1 ~ /5|187|197|198|199/ {print}'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       -       12
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       2
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Значення: Це ваш «топ-порушники» для SATA HDD. Фіксуйте його щодня або щотижня.

Рішення: Будь-який висхідний тренд в 197/198/187 — план заміни. 199, що росте — план по кабелям/бекплейну.

Завдання 16: Валідуйте ідентифікацію диска by-id (стабільні імена для автоматизації і заміни)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ZC1ABC12|nvme-INTEL'
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-ST4000NM0035-1V4107_ZC1ABC12 -> ../../sda
lrwxrwxrwx 1 root root 13 Dec 26 01:10 nvme-INTEL_SSDPE2KX020T8_PHBT1234001 -> ../../nvme0n1

Значення: Використовуйте ці стабільні ідентифікатори в шляхах vdev ZFS за-id і у вашій документації.

Рішення: Якщо ваш pool використовує /dev/sdX імена — заплануйте перехід на by-id перед тим, як у вас станеться інцидент заміни.

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

Це рутина «у вас п’ять хвилин до зустрічі і 30 секунд до ескалації пейджера». Мета — не ідеальна істина; мова про швидке сортування: деградація носія vs транспортний шум vs платформа vs файловa система.

Перший: визначте, чи це інцидент цілісності

• ZFS: zpool status -v. Якщо ви бачите CKSUM errors, faulted devices або permanent errors — вважайте це ризиком цілісності зараз.
• Ceph: ceph -s. Якщо OSD down, slow ops, degraded PGs — вважайте це нестабільністю сервісу сховища прямо зараз.
• Ядрові логи: дивіться на I/O errors і ресети за останню годину.

Другий: відокремте деградацію носія від транспортного шуму

• Витягніть SMART/NVMe health (smartctl -a).
• Індикатори носія: pending (197), uncorrectables (198/187), reallocated (5), NVMe media errors.
• Індикатори транспорту: CRC (199), ресети лінку, SAS phy resets, PCIe AER, NVMe controller resets без media errors.

Третій: змусьте проблему проявитись контролюваним тестом

• Запустіть SMART short test, потім long test за потреби.
• Запустіть ZFS scrub або Ceph deep-scrub, якщо кластер витримає навантаження.
• Спостерігайте лічильники після тесту. Якщо pending очищається і нові помилки не з’являються — пощастило. Якщо лічильники зростають — замінюйте.

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

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

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

Середня компанія мала Proxmox кластер з ZFS дзеркалами. На виклику побачили SMART «PASSED» і попередження Proxmox про кілька reallocated секторів. Вони вирішили, що все гаразд, бо пул ще ONLINE і VM працюють.

Тонка деталь: диск також мав невеликий, але ненульовий Current_Pending_Sector. Це не було виділено на дашборді. Ніхто не трендив значення. Ніхто не запускaв довгий тест. Життя йшло далі.

Через два тижні звичайний ZFS scrub почався. Він натрапив на один з pending секторів під час читання, диск таймаутнув, і HBA ресетнув лінк. ZFS продовжував спроби. Латентність зросла, I/O VM застопорилось. Кластер не «втратив дані», але втратив інше: час.

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

Виправлення було нудним: щоденні знімки SMART для 5/197/198 і автоматичний тикет, якщо 197 ненульовий або росте. Це не зупинило відмови повністю. Зупинило сюрпризи.

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

Ще одна команда хотіла менше шумних алертів. Proxmox UI показував часто SMART «temperature» і «UDMA CRC error count» попередження на кількох вузлах. Люди почали ігнорувати повідомлення і, природно, пропускати реальні.

Тому вони «оптимізували» алерти: підвищили пороги і приглушили CRC попередження, бо «це завжди бекплейн». Вони також приглушили попередження температури, бо «диски завжди гарячі під час відновлення». Дашборд заспокоївся. Усім стало краще.

Через місяці виникли періодичні паузи VM на одному хості. У SMART нічого очевидного. Нема reallocations, нема pending. Але ядрові логи показували хвилі ресетів лінку і збільшення CRC під час пікового навантаження. Виявилось, що один порт SAS expander був маргінальний. Помилки приходили хвилями.

Оскільки CRC оповіщення були приглушені, апаратна проблема тягнулася. Expander деградував далі і почав викликати мульти-дискові таймаути під час scrub. Тоді ZFS почав показувати checksum errors. Система не впала через один диск. Вона впала через те, що «шумний» алерт був раннім попередженням про компонент, що використовується спільно.

Виправлення не було «включити алерти назад і страждати». Краще було: оповіщати про швидкість зміни CRC (rate), а не про абсолютне значення, і корелювати з конкретним портом/відсіком через інвентар. Вони замінили expander, а не гору невинних дисків.

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

Фінансова організація мала Proxmox з Ceph. Їхня політика була нудною: кожен диск маркували етикеткою з серіалом, відсіком і OSD ID; щотижня вони зберігали SMART/NVMe зведення в маленькому time-series сховищі; щомісяця запускали рознесені довгі тести по вузлах.

Одного дня Ceph пішов в HEALTH_WARN через кілька slow ops. Нічого не впало. На виклику перевірили трендовий дашборд і побачили, що у одного NVMe «Media and Data Integrity Errors» піднявся з 0 до 1 за останню добу. Одне — не драматично. Але воно було новим.

Вони дренували хост, вивели OSD і замінили NVMe у робочий час. RMA вендора підтвердив ранню відмову носія. Якби вони чекали, поки «Critical Warning» спрацює, відмова сталася б під час іншого техобслуговування, коли кластер був вже навантажений.

Практика, що врятувала їх, була не в хитрих інструментах. Це була звичка трактувати нові помилки цілісності як такі, що потребують дії, навіть коли вони малі, і робити заміни за своїм графіком.

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

1) «SMART PASSED, але Proxmox показує попередження»

Симптом: Загальний SMART статус PASSED; Proxmox все одно сигналізує про здоров’я диска.

Корінь проблеми: Загальний статус — грубий поріг виробника; значущі лічильники (pending/uncorrectable) можуть бути ненульовими, хоча overall все ще PASSED.

Виправлення: Ігноруйте «PASSED» як заспокійливу ковдру. Перевірте raw 5/187/197/198 (SATA) або NVMe media errors/critical warning. Трендуйте їх.

2) «UDMA CRC Error Count росте; замінили диск, проблема лишається»

Симптом: SMART атрибут 199 інкрементує; з’являються I/O помилки; заміна диска не зупиняє проблему.

Корінь проблеми: Транспортна проблема: SATA кабель, бекплейн конектор, expander, HBA порт або нестабільність живлення.

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

3) «ZFS checksum errors, але SMART чистий»

Симптом: ZFS повідомляє CKSUM errors; SMART не показує reallocations/pending.

Корінь проблеми: Корупція у транспорті (кабелі/HBA), нестабільна RAM (рідко, але катастрофічно), або баги прошивки/драйвера. SMART вимірює тільки диск, а не весь шлях.

Виправлення: Перевірте ядрові логи на ресети, CRC, PCIe помилки. Перевірте ECC RAM (edac). Поміняйте HBA/кабелі. Запустіть scrub знову. Не звинувачуйте SMART за те, що він не універсальний.

4) «Pending sectors з’явилися після відключення живлення»

Симптом: 197 > 0 після жорсткого вимкнення або втрати живлення.

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

Виправлення: Запустіть довгий SMART тест, потім перевірте, чи pending зник. Якщо pending залишається або з’являються uncorrectables — замініть. Також виправте проблему живлення: UPS, резервні блоки живлення, коректні вимкнення.

5) «NVMe ресетиться під навантаженням; SMART виглядає нормально»

Симптом: NVMe контролер ресетиться і I/O таймаути; media errors відсутні.

Корінь проблеми: Питання платформи/PCIe: терміни, прошивка, ASPM, riseri, маргінальний слот, доставка живлення.

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

6) «SMART long test уповільнює VM, тому ми його ніколи не запускаємо»

Симптом: Ви уникаєте довгих тестів через їхній вплив на продуктивність.

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

Виправлення: Рознесіть тести по вузлах і дисках у періоди низького навантаження. Якщо ви не можете дозволити SMART long test, ви також не зможете дозволити собі resilver у піку навантаження.

7) «Ми алертимо на кожне ненульове SMART raw значення»

Симптом: Постійні алерти; всі їх ігнорують.

Корінь проблеми: Алертування по шумних атрибутах без логіки тренду/швидкості зміни.

Виправлення: Попросіть алерти на зміни у високосигнальних атрибутах (pending, uncorrectable, reallocations, NVMe media errors) і на швидкість зміни для CRC/температури, а не на абсолютні значення.

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

Чекліст A: Коли Proxmox викидає SMART-попередження

1. Ідентифікуйте диск за серійним номером (lsblk, /dev/disk/by-id).
2. Витягніть повні SMART/NVMe дані (smartctl -a).
3. Витягніть атрибути з високим сигналом:
   • SATA: 5, 187, 197, 198, 199
   • NVMe: Critical Warning, Percentage Used, Media/Data Integrity Errors
4. Перевірте error log і self-test log (smartctl -l error, -l selftest).
5. Корелюйте з ядровими логами за той же проміжок часу (journalctl -k).
6. Перевірте стан ZFS/Ceph (zpool status -v або ceph -s).
7. Прийміть рішення:
   • Медіа-лічильники зростають → замінити диск (планово або терміново в залежності від швидкості)
   • CRC/ресети без медіа-лічильників → виправити транспорт/платформу спочатку
   • ZFS permanent errors → розглядайте як інцидент цілісності і відновлюйте блоки/VM-диски

Чекліст B: Правила прийняття рішення про заміну, які я використовую

• Миттєво замінити, якщо:
  • Будь-який SMART long test показує read failure
  • ZFS фолтить пристрій або показує permanent errors
  • 197 (pending) зберігається після long test або зростає
  • 198/187 зростають (uncorrectables) у нормальному навантаженні
  • NVMe Critical Warning ненульовий або media errors зростають
• Планувати заміну, якщо:
  • Reallocated sectors (5) ненульові і повільно зростають
  • SSD Percentage Used високий і ви наближаєтесь до політики життєвого циклу
• Не замінювати поки що, якщо:
  • Лише CRC помилки ростуть і медіа-лічильники чисті → виправляйте кабелі/бекплейн/HBA
  • Лише шумні атрибути лякають (raw read error rate) без кореляції

Чекліст C: Побудова адекватного SMART-моніторингу на Proxmox

1. Переконайтеся, що smartmontools встановлено і smartd запущено.
2. Використовуйте стабільні ідентифікатори пристроїв для відстеження (by-id symlinks).
3. Збирайте невеликий набір атрибутів і трендуйте їх (щоденні знімки достатні).
4. Алертуйте на зміну, а не на існування:
   • delta(197) > 0 → page
   • delta(198) > 0 → page
   • delta(5) > 0 → ticket
   • delta(199) > 0 → ticket; page якщо швидко зростає і корелює з I/O errors
5. Заплануйте SMART long tests рознесено по дисках і вузлах.
6. Переконайтеся, що ZFS scrubs або Ceph scrubbing відбуваються і їх переглядають.

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

1) Якщо SMART каже PASSED, чи можна ігнорувати попередження Proxmox?

Ні. «PASSED» часто означає «не перевищив катастрофічний поріг виробника». Pending сектора і uncorrectables можуть існувати, навіть якщо overall health ще PASSED.

2) Який одиночний HDD SMART-атрибут найбільш прогнозний?

Current_Pending_Sector (197) — той, що найшвидше змінює рішення. Він означає незчитувані сектори прямо зараз, а не історичне перемапування.

3) Чи завжди reallocated sectors — причина заміни?

Не завжди одразу. Малий, стабільний reallocated count може жити довго. Зростаючий лічильник — сам собою план заміни.

4) Що на практиці означає UDMA CRC error count?

Корупція даних на лінку між диском і контролером. Думайте про кабель, бекплейн, expander, HBA порт або шум живлення. Часто — не вина самого диска.

5) Чому ZFS показує checksum errors, коли SMART виглядає нормально?

Бо SMART вимірює внутрішній стан диска. ZFS перевіряє наскрізні контрольні суми і може впіймати корупцію через RAM, HBA, кабелі або баги прошивки.

6) Чи потрібно запускати SMART long tests на продуктивних хостах?

Так, але рознесено. Long test дешевший, ніж несподіваний rebuild в піку. Якщо вплив неприпустимий — це проблема планування ємності, а не проблема SMART.

7) Для NVMe що варто оповіщати?

Алертуйте при ненульовому Critical Warning, зростанні Media and Data Integrity Errors і раптових стрибках ресетів/таймаутів у ядрових логах. Percentage Used — для планування життєвого циклу.

8) Proxmox не може прочитати SMART за моїм RAID-контролером. Що робити?

Використовуйте інструменти контролера для здоров’я дисків або перемкніться на HBA/IT режим, де ОС бачить диски напряму. Якщо ви не можете спостерігати за кожним диском — ви працюєте напівсліпо; на масштабі це має наслідки.

9) Як вирішити між «заміна диска» і «ремонт кабелю»?

Якщо 5/197/198/187 (або NVMe media errors) зростають — справа в диску. Якщо лише CRC/link ресети зростають і медіа-лічильники чисті — справа в шляху.

10) Чи означає висока температура неминучу відмову?

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

Висновок: що робити далі, практично

Коли Proxmox махає попередженням SMART, не зачаровуйтесь загальним «PASSED». Ідіть одразу до кількох лічильників, що справді прогнозують проблему: pending сектори, uncorrectables, reallocations, NVMe media errors, і транспортні лічильники, що вказують на кабелі та бекплейн.

Кроки, що дають швидкий ефект:

1. Обрати невеликий, чіткий набір алертів: 5/187/197/198/199 для SATA; critical warning/media errors/percentage used для NVMe.
2. Трендуйте ці значення. Алерти на зміну, не на наявність.
3. Робіть ZFS/Ceph арбітром цілісності, а SMART — раннім попередженням.
4. Запишіть свої правила прийняття рішення про заміну і дотримуйтеся їх. Мета — послідовність, а не геройство.

Ваш стек сховища не потребує оптимізму. Потрібна нудна системність і легка недовіра до дашбордів.