Відновлення помилок диска під час завантаження: що робити, поки не стало гірше

Що насправді означає «Відновлення помилок диска» (і чого це не означає)

Це повідомлення під час завантаження зазвичай означає одне з трьох:

• Запускається перевірка послідовності файлової системи (Windows: CHKDSK; Linux: fsck; macOS: fsck_apfs). Це може бути планова дія після некоректного вимкнення або спрацьовувати через виявлену корупцію.
• ОС відтворює журнал (поширено на ext4, XFS, NTFS). Журнальні файлові системи намагаються відновити консистентність після збою. Більшість відтворень журналу проходять швидко. Якщо повільно — це підказка.
• Шар зберігання незадоволений: диск повертає помилки читання/запису, надто довго відповідає або контролер скидається. У такому випадку «відновлення» — це спроба ОС прочитати метадані та переписати структури, поки диск періодично відмовляє.

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

Практична установка мислення: ставтеся до повідомлень під час завантаження як до симптому, а не до вирішення. Ваша мета — визначити, чи маєте ви справу з (a) одноразовим нечистим вимкненням, (b) повторною корупцією через софт/прошивку/живлення, або (c) неминучим виходом диска з ладу.

Одна перефразована ідея, бо це правильна установка для цієї ситуації: парафразована думка Вернера Вогельса (подумки про надійність): усе рано чи пізно виходить з ладу; проектуйте й експлуатуйте так, ніби це гарантовано.

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

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

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

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

• Якщо є доступ до shell або середовища відновлення, витягніть SMART/NVMe health та журнали ядра.
• Шукайте: перерозподілені сектори, pending sectors, uncorrectable errors, CRC помилки, NVMe media errors, скидання контролера, таймаути I/O.
• Рішення: якщо ці показники присутні або зростають, припиніть «відновлювати» і почніть «копіювати». Спершу клон/образуйте диск.

Друге: визначте, чи файлова система пошкоджена, але апарат у порядку

• Перевірте помилки монтажу, цикли відтворення журналу та чи fsck/chkdsk повідомляє стабільну кількість виправлень.
• Рішення: якщо SMART виглядає чистим, а помилки пов’язані з втратою живлення чи примусовими скиданнями, можна продовжити з офлайн-відновленням — але після резервного копіювання.

Третє: перевірте, чи ви не заблоковані іншою проблемою (не диском)

• UEFI/BIOS, що неправильно визначає порядок завантаження, RAID-контролер у деградованому стані, поганий SATA-кабель, ненадійна панель, зламаний initramfs або драйвер ядра можуть маскуватися під «помилки диска».
• Рішення: якщо журнали показують чисті I/O, але завантаження падає при монтуванні root, зосередьтесь на bootloader/initramfs і змінах імен пристроїв.

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

Цікаві факти та історичний контекст (чому це повторюється)

• Факт 1: CHKDSK походить із ранніх DOS-утиліт; його сучасні форми все ще наслідують ту саму місію: зробити файлову систему консистентною, навіть якщо це означає видалити сумнівні записи.
• Факт 2: Журнальні файлові системи (як ext3/ext4, NTFS, XFS) стали масовими частково тому, що післяаварійні відновлення для не-журнальних систем могли тривати години або вимагати повних сканів на великих дисках.
• Факт 3: Перехід від обертових дисків до SSD зменшив деякі механічні відмови, але приніс нові: баги прошивки, зношування, read disturb та раптові переходи в режим «read-only» на деяких пристроях.
• Факт 4: Помилки лінку SATA (CRC errors) часто викликані кабелями/бэкплейнами, а не медіа диска. Вони виглядають лякаюче в логах і часто вирішуються $6 кабелем та кращим маршрутом.
• Факт 5: «Погані сектори» не завжди постійні. Диски можуть ремапити сектори, і іноді тимчасова помилка читання стає знову читабельною — прямо перед тим, як знову вийти з ладу. Тому «воно раз спрацювало» — пастка.
• Факт 6: Файлові системи — не бази даних. Вони не відстежують бізнес-інваріанти, і інструменти відновлення не можуть вгадати ваші наміри; вони лише відновлюють внутрішню структуру.
• Факт 7: RAID ніколи не був резервною копією, і галузь повторює це з моменту його популяризації на серверах. Це досі правда.
• Факт 8: Перевірки файлових систем під час завантаження раніше планувалися агресивніше (наприклад, перевірка лічильника монтувань в ext2/ext3). Сучасні системи часто зменшують ці перевірки заради швидшого завантаження — іноді ховаючи повільно зростаючу корупцію.

Перше правило: захистіть дані перед тим, як «виправляти» щось

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

Що означає «захистити дані» на практиці:

• Якщо система ще завантажується: спершу скопіюйте найцінніші дані (бази даних, домашні директорії, конфіги, ключі). Не починайте з повної перевірки диска.
• Якщо не завантажується: використайте live-середовище, змонтуйте в режимі тільки для читання або зробіть образ диска.
• Якщо це сервер з надлишковістю (RAID/ZFS/Ceph): зосередьтеся на заміни дефектного компонента і безпечному відновленні. Не запускайте руйнівні перевірки на деградованому масиві, якщо не впевнені, що саме вони змінюють.

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

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

Ці завдання припускають Linux, бо саме там ви побачите найбільш прямі сигнали, але логіка переноситься на Windows/macOS: спостерігайте health, захопіть дані, ремонтуйте офлайн, верифікуйте і запобігайте повторенню.

Завдання 1: Визначте, на якому блочному пристрої знаходиться root

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
NAME   TYPE  SIZE FSTYPE MOUNTPOINTS MODEL            SERIAL
sda    disk  1.8T        ST2000DM008  ZFL123AB
├─sda1 part  512M vfat   /boot/efi
├─sda2 part    2G ext4   /boot
└─sda3 part  1.8T ext4   /

Що це означає: Тепер ви знаєте, який диск залучений (sda) і які розділи важливі (sda3 — root). Якщо бачите LVM, mdraid, dm-crypt або ZFS, ваш «диск» — це стек — не пропускайте нижчі рівні.

Рішення: Якщо root на складному стеку, потрібно збирати дані про здоровʼя як від фізичних пристроїв, так і з логічного шару (mdadm, LVM, ZFS).

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

cr0x@server:~$ sudo dmesg -T | egrep -i "error|fail|reset|timeout|I/O|ata|nvme" | tail -n 30
[Mon Feb  5 09:11:22 2026] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Mon Feb  5 09:11:22 2026] ata1.00: failed command: READ DMA EXT
[Mon Feb  5 09:11:22 2026] blk_update_request: I/O error, dev sda, sector 1953525160 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Mon Feb  5 09:11:23 2026] ata1: soft resetting link
[Mon Feb  5 09:11:28 2026] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Що це означає: Реальні I/O помилки на блочному рівні. ОС спробувала прочитати сектор, а диск/контролер не зміг віддати дані. Скидання лінку вказує на нестабільність диска або шляху.

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

Завдання 3: Витягніть SMART health для SATA/SAS дисків

cr0x@server:~$ sudo smartctl -a /dev/sda
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   097   097   010    Pre-fail  Always       -       24
197 Current_Pending_Sector  0x0012   098   098   000    Old_age   Always       -       8
198 Offline_Uncorrectable   0x0010   098   098   000    Old_age   Offline      -       8
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Що це означає: «PASSED» — не запорука безпеки; це лише означає, що диск не перевищив поріг від виробника. Pending sectors і uncorrectables — поганий знак: диск не може надійно читати деякі локації. Reallocated сектори означають, що він уже ремапив пошкоджені ділянки.

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

Завдання 4: Отримайте здоровʼя NVMe (media errors, percentage used)

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

Що це означає: Ненульовий media_errors — це еквівалент того, що пристрій не зміг коректно читати/записати дані. Це не косметичний показник.

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

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

cr0x@server:~$ sudo tune2fs -l /dev/sda3 | egrep -i "Filesystem state|Errors behavior|Last checked|Last mount time|Mount count|Check interval"
Filesystem state:         clean
Errors behavior:          Continue
Last mount time:          Mon Feb  5 09:02:10 2026
Last checked:             Mon Feb  5 09:01:55 2026
Mount count:              34
Check interval:           0 (<none>)

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

Рішення: Якщо ви бачили відновлення під час завантаження повторно, змініть поведінку помилок на «remount-ro» після стабілізації і виправте джерело проблем (живлення, диск, контролер).

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

cr0x@server:~$ sudo fsck.ext4 -n /dev/sda3
e2fsck 1.46.5 (30-Dec-2021)
/dev/sda3: clean, 412156/117440512 files, 98123456/469760000 blocks

Що це означає: -n не модифікує файлову систему. «clean» вказує на те, що файлову систему визнано консистентною.

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

Завдання 7: Виконайте офлайн-відновлення (тільки коли шлях до диска стабільний)

cr0x@server:~$ sudo fsck.ext4 -f -y /dev/sda3
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Inode 924844 has invalid mode.  Clear? yes
Pass 2: Checking directory structure
Entry 'cache.tmp' in /var/tmp (924900) has deleted/unused inode 924844.  Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda3: 412155/117440512 files, 98123450/469760000 blocks

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

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

Завдання 8: Перевірте, чи шлях до диска не «бреше» (SATA CRC errors та стабільність лінку)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "UDMA_CRC_Error_Count|SATA Version|Error"
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       214

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

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

Завдання 9: Перевірте systemd на збої при монтуванні (поширено на Linux серверах)

cr0x@server:~$ systemctl --failed
  UNIT                          LOAD   ACTIVE SUB    DESCRIPTION
● boot.mount                    loaded failed failed /boot
● local-fs.target               loaded failed failed Local File Systems

Що це означає: Завантаження падає на етапі монтажу файлових систем. Це може бути корупція, відсутній пристрій, невірний UUID або незібраний RAID.

Рішення: Далі перевірте журнали, щоб дізнатися, чому монтаж впав, потім перевірте UUID і наявність блочного пристрою.

Завдання 10: Проаналізуйте журнали journal на предмет «superblock» та «wrong fs type» помилок

cr0x@server:~$ sudo journalctl -b -p err --no-pager | tail -n 30
Feb 05 09:01:44 server kernel: EXT4-fs (sda3): bad geometry: block count 469760000 exceeds size of device (0)
Feb 05 09:01:44 server systemd[1]: Failed to mount /.
Feb 05 09:01:44 server systemd[1]: Dependency failed for Local File Systems.

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

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

Завдання 11: Підтвердіть, що ємність пристрою стабільна й не «зменшується»

cr0x@server:~$ sudo blockdev --getsize64 /dev/sda
2000398934016

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

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

Завдання 12: Зберіть і перевірте стан mdraid (якщо застосовано)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      976630336 blocks super 1.2 [2/1] [U_]
      [==============>......]  recovery = 72.3% (706000000/976630336) finish=45.0min speed=100000K/sec

Що це означає: RAID1 деградований: одна сторона відсутня ([U_]). Іде відновлення, що створює велике навантаження I/O.

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

Завдання 13: Перевірте стан ZFS pool і статус scrub (якщо застосовано)

cr0x@server:~$ sudo zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device and run 'zpool clear'.
  scan: scrub repaired 0B in 00:12:31 with 3 errors on Mon Feb  5 08:40:22 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     FAULTED     12     0     3  too many errors

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

Рішення: Замініть faulted-пристрій, потім повторно scrub. Також перевірте кабелі/прошивку HBA; ZFS часто раніше інших стеків виявляє upstream проблеми.

Завдання 14: Створіть образ проблемного диска з мінімальною кількістю повторів (ddrescue)

cr0x@server:~$ sudo ddrescue -f -n /dev/sda /mnt/recovery/sda.img /mnt/recovery/sda.map
GNU ddrescue 1.26
Press Ctrl-C to interrupt
rescued:   1999 GB,  errsize:   1024 kB,  current rate:   120 MB/s
ipos:   2000 GB,  errors:      12,  average rate:   118 MB/s
opos:   2000 GB,  time from start:   04:45:12
Finished

Що це означає: Ви отримали майже все; mapfile фіксує те, що не вдалося. -n робить перший прохід без агресивного сканування — менше стресу. Залишкові помилки можуть бути відновлені другим проходом або вважатися втраченими.

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

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

cr0x@server:~$ sudo mount -o ro,norecovery /dev/sda3 /mnt
cr0x@server:~$ ls -lah /mnt | head
total 96K
drwxr-xr-x  24 root root 4.0K Feb  5 09:02 .
drwxr-xr-x   3 root root 4.0K Feb  5 08:59 ..
drwxr-xr-x   2 root root 4.0K Jan 20 11:10 bin
drwxr-xr-x   4 root root 4.0K Feb  4 18:12 boot

Що це означає: Монтирование тільки для читання зменшує записи. norecovery (де підтримується) уникає відтворення журналів при монтуванні, що могло б записувати на диск.

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

Завдання 16: Знайдіть файли, що лежать на поганих блоках (ext файлові системи)

cr0x@server:~$ sudo badblocks -sv /dev/sda3
Checking blocks 0 to 469760000
Checking for bad blocks (read-only test): done
Pass completed, 12 bad blocks found. (12/0/0 errors)

Що це означає: Є погані блоки. На обертовому диску це часто корелює з ростом відмов. На SSD «погані блоки» складніші через ремапінг, але uncorrectable помилки все одно мають значення.

Рішення: Не «помічайте їх і продовжуйте», якщо ви не готові працювати на компромісній системі. Замініть диск.

Завдання 17: Перевірте, чи оперативна пам’ять не співучасник (бо корупція не завжди від диска)

cr0x@server:~$ sudo journalctl -k --no-pager | egrep -i "mce|machine check|EDAC|memory error" | tail -n 20
Feb 05 08:58:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

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

Рішення: Якщо бачите ECC-помилки — заплануйте заміну DIMM і запустіть тести пам’яті. Не звинувачуйте файлову систему за те, що зламала підсистема пам’яті.

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

1) Інцидент, спричинений неправильною припущенням: «PASSED означає здоровий»

У середній компанії була група on-prem build-серверів. Один почав показувати під час завантаження «Відновлення помилок диска», але зрештою запускався. On-call перевірив SMART, побачив «PASSED» і закрив інцидент — бо пайплайн був червоний, і всім треба було хороші графіки до ранкового стендапу.

Машина шкутильгала тиждень. Білди стали повільніші, потім — переривчасті. Кожен ребут запускав ще один цикл відновлення. Робоче припущення стало: «це просто файлові зміни після подій живлення». Але сервер не мав подій живлення. Він мав повтори читання, таймаути та зростаючу кількість pending sectors, на які ніхто не звертав уваги, бо рядок підсумку виглядав добре.

Потім настав день, коли він не повернувся. Диск остаточно вийшов з ладу під час завантаження, саме тоді, коли інструмент файлової системи записував метадані. Найболючіше було не простою; це була невизначеність. Репозиторій кеша пошкоджено? Артефакти некоректні? Які білди підозрілі? Ніхто не хоче пояснювати менеджменту, що «дані можуть бути неправильними».

Післямова: вони припинили трактувати SMART «PASSED» як вирок. Вони почали оповіщати про окремі атрибути (pending/uncorrectable sectors, NVMe media errors, link CRC errors) і додали в рунабук: «Якщо відновлення при завантаженні повторюється — спершу зробити образ». Негламурно. Дієво.

2) Оптимізація, що обернулась проти: «Пропустити перевірки, щоб завантажуватись швидше»

Інша організація тримала latency-sensitive сервіси на bare metal. Швидкість завантаження була важлива через ролінгові перезавантаження. Хтось налаштував ext4, щоб мінімізувати планові перевірки й встановив опції монтування, що зберігають рух системи. Класичний «оптимізувати steady-state» хід.

Через місяці дрібний баг ядра плюс кілька різких watchdog reboots спричинили невідповідності метаданих. Системи все ще завантажувалися, здебільшого. Але вони частіше заходили в «відновлення помилок диска», і вікно відновлення збільшувалось щоразу. Ніхто не корелював це, бо перевірки рідкісні, а флот великий. Повільні відмови були розпорошеними — ідеально підходили для ігнорування.

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

Вони відкочували найагресивніші налаштування, ввели періодичні офлайн-скрабування/перевірки в низьку навантаження, і — що ключове — забезпечили, щоб кожен випадок «repair on boot» створював тикет. Не шквал алертів, а тикет з відповідальним. Оптимізації — добре; приховування доказів — ні.

3) Нудна, але правильна практика, що врятувала ситуацію: протестовані відновлення й поетапна заміна

Фінансово орієнтована компанія (регульована, боїться сюрпризів) тримала критичні системи на зеркальному зберіганні з суворою дисципліною операцій. Одного ранку хост бази даних зайшов у режим відновлення. On-call не намагався бути героєм. Вони слідували рунабуку: збирати логи, перевіряти здоровʼя диска, вивести вузол з ротації і зробити фейловер.

SMART показав зростаючі uncorrectables на одному диску та декілька CRC помилок на іншому. Команда не сперечалася, який показник «важливіший». Вони замінили кабель, замінили диск і запланували контрольований рібілд. Поки тривав rebuild, вузол залишався поза критичним трафіком.

Ось частина, що здається нудною, поки не стане в пригоді: вони тестували відновлення. Коли хтось питав: «А якщо mirror rebuild пошкодить базу?» відповідь не була зустріччю. Відповідь була: «Ми можемо відновити знімок минулої ночі на свіжий хост; ми репетирували це минулого місяця».

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

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

1) Відновлення запускається кожен раз при завантаженні, але «воно зрештою працює»

Симптом: Відновлення під час завантаження з кожним разом займає довше; випадкові заморожування; рандомні падіння застосунків.

Корінь: Диск накопичує непричитувані сектори або контролер скидається під навантаженням.

Виправлення: Перевірте SMART/NVMe журнали і dmesg. Якщо є pending/uncorrectable/media errors — зробіть образ і замініть диск. Якщо домінують CRC помилки — замініть кабель/бекплейн і перетестуйте.

2) «Wrong fs type» або «bad superblock» після оновлення

Симптом: systemd падає в emergency mode; монтаж не вдається; інструмент ремонту каже, що не може знайти файлову систему.

Корінь: Зміни в іменах пристроїв (невідповідність UUID), RAID/LVM не зібрались або initramfs не містить потрібного драйвера.

Виправлення: Перевірте UUID у /etc/fstab і зіставте з blkid. Підтвердьте активацію mdraid/LVM в initramfs. Не запускайте fsck на невірному девайсі.

3) CHKDSK/fsck «виправляє» речі, але файли зникають

Симптом: Після ремонту в директоріях зʼявляються фрагменти у lost+found або відсутні файли.

Корінь: Метадані були пошкоджені, тому інструмент від’єднав сирітські іноди/записи. Це очікувана поведінка при пошкодженні.

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

4) Відновлення «застрягає» на певному відсотку

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

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

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

5) Починається RAID rebuild, а потім система починає «відновлювати помилки диска»

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

Корінь: Виживший диск вже був слабкий; стрес від rebuild виявив це. Або контролер/бекплейн маргінальний.

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

6) SSD раптово переходить у режим тільки для читання або зникає під час ремонту

Симптом: Монтаж переходить у read-only; NVMe скидається; цикл завантаження повторюється.

Корінь: Режим захисту прошивки SSD, проблеми з power-loss protection або вихід з ладу контролера. Іноді тригериться тепловими або живильними подіями.

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

Чеклісти / покроковий план (робіть це, потім те)

Сценарій A: Ноутбук/десктоп показав «Відновлення помилок диска» раз

1. Дайте йому завершити раз. Якщо все швидко завершилося й система завантажилась нормально — зафіксуйте це як попередження.
2. Після завантаження зберіть сигнали: SMART/NVMe, журнали ОС та недавні події живлення.
3. Негайно створіть резервну копію. Не пізніше.
4. Якщо SMART/NVMe показує pending/uncorrectable/media errors — замініть диск.
5. Якщо зʼявилися CRC/link помилки — перепідключіть/замініть кабелі (десктоп) або перевірте конектори.

Сценарій B: Це повторюється при кожному завантаженні або зависає

1. Припиніть постійно перезавантажувати. Ребути — це не діагностика; це стрес-тести.
2. Завантажте live-середовище (або recovery mode) і зберіть dmesg та SMART/NVMe логи.
3. Якщо зʼявилися апаратні помилки: зробіть образ за допомогою ddrescue, потім працюйте з образом.
4. Якщо апарат виглядає чистим: спершу запустіть read-only fsck; потім офлайн-відновлення за потреби.
5. Після ремонту валідуйте: перевірки цілісності файлів, перевірки застосунків і перегляд логів.

Сценарій C: Сервер з RAID/ZFS і вплив на продакшн

1. Фейловер або зменшіть трафік, якщо може. Не дебажте під навантаженням, якщо не любите жалю.
2. Перевірте стан масиву/пулу перш ніж діяти (mdadm/zpool). Деградований набір змінює всі розрахунки ризику.
3. Визначте, який компонент відмовляє: диск, кабель, HBA чи бекплейн.
4. Замініть підозріле залізо, потім rebuild/resilver з моніторингом.
5. Запустіть scrub/check після rebuild і переконайтеся, що немає прихованих помилок.

Сценарій D: Вам потрібні дані, і диск явно вмирає

1. Пріоритет — створення образу, а не ремонт. Образ зберігає опціональність.
2. Використовуйте ddrescue з mapfile; зробіть низькостресовий перший прохід.
3. Працюйте з копією образу: намагайтесь змонтувати в read-only; запускайте файлові перевірки на дублікаті, а не на єдиній копії.
4. Лише при критичній необхідності робіть агресивні повторні зчитування з оригіналу, якщо відсутні дані варті ризику повної втрати.

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

1) Чи завжди «Відновлення помилок диска» означає, що диск помирає?

Ні. Це може бути нормальна реакція на некоректне вимкнення. Але якщо це повторюється, сповільнюється або супроводжується I/O помилками в логах — вважайте, що існує апаратний ризик, поки не доведено протилежне.

2) Чи варто переривати процес відновлення?

Якщо ви підозрюєте фізичну відмову диска (I/O errors, resets, pending sectors, NVMe media errors), то так — бо операції ремонту з записом можуть погіршити втрату. Якщо це одноразове відтворення журналу на здоровому обладнанні — дайте завершитись.

3) Чому SMART каже «PASSED», коли диск явно вмирає?

SMART «overall health» базується на порогах і специфіці виробника. Атрибути, як pending sectors, uncorrectables і media errors, часто більш корисні, ніж рядок підсумку.

4) У чому різниця між корупцією файлової системи і поганими секторами?

Корупція файлової системи — це зламані метадані/структури (часто від краху, багів або поганих записів). Погані сектори/media errors — це коли диск не в змозі надійно зберегти або прочитати дані. Корупцію можна відновити; погане медіа має тенденцію поширюватися.

5) Чи виправить fsck/chkdsk вихідний диск?

Ні. Вони можуть зробити файлову систему консистентною поверх помираючого диска, але не вилікують апарат. На вмираючому диску вони можуть прискорити відмову через велике випадкове I/O.

6) Якщо я заміню диск, чи можна довіряти відновленій копії файлової системи?

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

7) Чи запобігає RAID цій ситуації з відновленням при завантаженні?

Він зменшує час простою при одиничній відмові диска, але не запобігає перевіркам ФС, проблемам контролера, поганим кабелям, багам прошивки або корельованим відмовам декількох дисків. Також rebuild RAID часто саме той момент, коли другий диск здає позиції.

8) Який найбезпечніший спосіб відновити дані з вмираючого диска?

Зробіть образ за допомогою інструменту, призначеного для проблемних носіїв (ddrescue) з mapfile, потім працюйте з образом. Монтування в режимі тільки для читання і мінімальні повтори — ваші друзі.

9) Чому відновлення триває вічно на великих дисках?

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

10) Якщо бачу CRC помилки, чи все одно замінювати диск?

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

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

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

1. Зберіть сигнали: захопіть dmesg/journalctl та SMART/NVMe health для підлеглих пристроїв.
2. Прийміть рішення: якщо бачите media/pending/uncorrectable помилки або повторні скидання/таймаути — спершу зробіть образ і замініть залізо.
3. Ремонтуйте розумно: запускайте read-only перевірки перед офлайн-відновленнями; не повторюйте «ремонт» на вмираючому диску.
4. Перевірте: підтвердіть монтажі, запустіть перевірки застосунків, перегляньте логи і спостерігайте за повторними помилками в наступні дні.
5. Запобігайте повторенню: покращте стабільність живлення, кабелі/бекплейн, прошивку контролерів і налаштуйте оповіщення за змістовними атрибутами здоровʼя — не лише «PASSED».

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