Debian 13 mdadm RAID — деградований: заміна і відновлення без втрати даних

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

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

Ваш пейджер спрацьовує. Графік сховища «в порядку» (як завжди), але затримка додатку росте, і один вузол віддає помилки диска.
Ви заходите й бачите це: [U_], [UU_U] або страшний стан «inactive» масиву.
Ви можете відновити це чисто — або перетворити один збійний диск на інцидент із незворотною втратою даних.

Це продукційний посібник для Debian 13 і mdadm програмного RAID: швидка діагностика, безпечна заміна, моніторинг відновлення
і типові підводні камені, на які люди спотикаються. Він суб’єктивний, бо файловій системі байдуже до ваших емоцій.

Основні правила: що насправді означає “degraded”

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

Мета проста: відновити надмірність, не додавши нової невизначеності. На практиці це означає:

Не гадати, який диск упав. Ідентифікуйте за стабільними атрибутами (серійний номер, WWN, слот у шасі).
Не «форсовано збирати» масив, поки не розумієте метадані та режим відмови. «Force» — це потужний інструмент.
Не відновлюйте на диск, який тихо хворіє. SMART приховує, а не брешe прямо.
Не змінюйте дві речі одночасно. Замініть один диск; перевірте; потім продовжуйте.

Якщо ви використовуєте RAID5/6 і масив вже деградований, система живе в борг. Читання зачіпає всі решта диски,
частота помилок зросте, а вікно відновлення перетвориться на лотерею надійності. Ви все ще можете перемогти. Просто не будьте недбалими.

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

Найшвидший спосіб виправити деградований RAID — не робити «дій», доки не з’ясуєте, з чим маєте справу:
(1) справді померлий диск, (2) проблема підключення, (3) зміна імен пристроїв у ядрі, (4) приховані помилки медіа під навантаженням,
або (5) хтось уже намагався виправити проблему.

Перший крок: підтвердити стан масиву й чи відбувається зараз resync

Перевірте /proc/mdstat на предмет degraded, resync, recovery, reshape або check.
Підтвердьте, які md-пристрої існують і яка їхня «особистість» (raid1/5/6/10).
Вирішіть: зупинити зміни до завершення resync чи втрутитися зараз?

Другий крок: ідентифікуйте проблемний член за стабільною ідентичністю, не за /dev/sdX

Мапуйте членів md → розділи → базові блочні пристрої.
Зберіть серійний номер/WWN і, якщо є, відповідність слота в шасі.
Вирішіть: «відсутній» диск фактично відсутній чи просто не збирається?

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

Жорстка відмова: I/O-помилки, пристрій зник, SMART каже «failing now». Замінюйте диск.
Шлях/кабель/HBA: скиди лінку, CRC-помилки, «флапи» пристрою. Спочатку виправляйте підключення.
Метадані/збирання: невірний UUID, старий суперблок, невідповідність initramfs. Виправляйте конфігурацію mdadm і збирайте безпечно.
Проблеми консистентності: невідповідність лічильника, некоректне завершення. Після відновлення надмірності запустіть check.

Жарт №1: RAID означає «Redundant Array of Inexpensive Disks», але під час відновлення часто перекладається як «Really Anxious IT Department».

Цікаві факти та історія (чому mdadm поводиться як це)

Linux MD з’явився раніше за mdadm. Ранні програмні RAID у Linux використовували raidtools; mdadm став практичним стандартом із розвитком метаданих і збирання.
Версії суперблоку мають значення. Metadata 0.90 живе в кінці пристрою (старий сумісний формат), а 1.x — ближче до початку; це змінює поведінку завантаження і те, як старі метадані переживають очищення.
«Write hole» — реальна річ. Класичний RAID5 може втратити консистентність при краші посеред оновлення смуги; журналювання і write-intent битмапи допомагають, але не скасовують фізику.
Битмапи не завжди були поширені. Write-intent битмапи значно скорочують час resync після некоректного завершення, відстежуючи брудні регіони замість сканування всього масиву.
MD вміє робити reshape онлайн. Зміна layout, кількості дисків або рівня RAID можлива, але ризикована й ресурсномістка — особливо коли масив уже деградований.
«check» і «repair» в MD — різні режими. Check може бути нечуйним; repair записує корекції. Плутанина між ними — як люди «виправляють» дані в неправильний бік.
Імена пристроїв — не ідентичності. /dev/sda — пропозиція ядра на основі порядку виявлення; WWN — це ідентичність, що її несе апарат.
Debian історично схильний до консерватизму. Значення за замовчуванням в Debian (і культура навколо них) зазвичай віддають перевагу коректності й стабільності над «корисною автоматизацією», яка ховає стан.

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

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

Завдання 1: Читайте `/proc/mdstat` як дорослий

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid10]
md0 : active raid1 sda1[0] sdb1[1]
      976630336 blocks super 1.2 [2/1] [U_]
      bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: <none>

Що це означає: md0 — RAID1 з двома очікуваними членами. [2/1] означає 2 слоти, 1 робочий пристрій. [U_] означає, що перший диск підключений, другий відсутній/пошкоджений.

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

Завдання 2: Отримайте авторитетний звіт від mdadm

cr0x@server:~$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Mon Sep  2 11:40:18 2024
        Raid Level : raid1
        Array Size : 976630336 (931.51 GiB 1000.20 GB)
     Used Dev Size : 976630336 (931.51 GiB 1000.20 GB)
      Raid Devices : 2
     Total Devices : 1
       Persistence : Superblock is persistent

       Update Time : Mon Dec 29 09:11:22 2025
             State : clean, degraded
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

              Name : server:0
              UUID : 3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2
            Events : 41290

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       0        0        1      removed

Що це означає: mdadm погоджується, що стан — clean, degraded (не resync). Відсутній член позначено як «removed», не «failed». Так зазвичай буває після повторних I/O-помилок або ручного видалення.

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

Завдання 3: Знайдіть пристрої-члени та їхню стабільну ідентичність

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sda|sdb'
lrwxrwxrwx 1 root root  9 Dec 29 09:03 ata-SAMSUNG_MZ7L3960HCGR-00005_S4JNNX0T123456 -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 29 09:03 ata-SAMSUNG_MZ7L3960HCGR-00005_S4JNNX0T789012 -> ../../sdb

Що це означає: У вас два різні серійні номери. Навіть якщо /dev/sdX зміниться після перезавантаження, шляхи by-id збережуться.

Рішення: Відтепер у нотатках і плані змін використовуйте серійний номер/WWN, а не sdb.

Завдання 4: Підтвердіть, які розділи належать MD і чи чогось не вистачає

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,UUID
NAME        SIZE TYPE FSTYPE            MOUNTPOINTS UUID
sda       931.5G disk
├─sda1    931.5G part linux_raid_member            3b0d0f3b-5f2e-6d7a-8c6c-9b9b9dd5a1d2
└─sda2      512M part vfat              /boot/efi   1A2B-3C4D
sdb       931.5G disk
└─sdb1    931.5G part
md0       931.5G raid1 ext4             /          7b1e4d2d-6ad0-4f1e-bb0d-3b51f7e0f88a

Що це означає: sda1 — член RAID; sdb1 існує, але не має підпису linux_raid_member. Це може означати, що він новий/не розмічений, або що старий диск втратив таблицю розділів (менш імовірно, але не припускайте).

Рішення: Якщо sdb має стати заміною, ви розмітите його так само, як sda, а потім додасте до масиву. Якщо sdb — існуючий член, який «випав», розслідуйте, чому він втратив метадані.

Завдання 5: Прочитайте журнали ядра для справжньої причини відмови

cr0x@server:~$ sudo journalctl -k -b | grep -E 'md0|sdb|I/O error|reset|fail' | tail -n 30
Dec 29 08:52:11 server kernel: ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0x6 frozen
Dec 29 08:52:11 server kernel: ata2.00: irq_stat 0x08000000, interface fatal error
Dec 29 08:52:12 server kernel: ata2: hard resetting link
Dec 29 08:52:17 server kernel: sd 1:0:0:0: [sdb] tag#19 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Dec 29 08:52:17 server kernel: blk_update_request: I/O error, dev sdb, sector 1953525160 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 29 08:52:17 server kernel: md/raid1:md0: Disk failure on sdb1, disabling device.
Dec 29 08:52:17 server kernel: md/raid1:md0: Operation continuing on 1 devices.

Що це означає: Це не «mdadm поводиться дивно». Це скиди лінку й I/O-помилки. Часто це знак проблеми з диском, але також може бути кабель, backplane або порт HBA.

Рішення: Перед відновленням вирішіть, чи довіряєте шляху. Якщо це hot-swap відсік, перепідключіть або перемістіть диск у відомо хороший слот. Якщо сервер з старими SATA-кабелями — замініть кабель. Відновлення легко перетворює маргінальне на мертве.

Завдання 6: Перевірте SMART підозрілого пристрою (і інтерпретуйте песимістично)

cr0x@server:~$ sudo smartctl -a /dev/sdb | sed -n '1,120p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0-amd64] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       SAMSUNG MZ7L3960HCGR-00005
Serial Number:                      S4JNNX0T789012
Firmware Version:                   EDA7902Q
User Capacity:                      960,197,124,096 bytes [960 GB]
SMART overall-health self-assessment test result: PASSED

=== START OF SMART DATA SECTION ===
Critical Warning:                   0x00
Media and Data Integrity Errors:    14
Error Information Log Entries:      27
Warning  Comp. Temperature Time:    0
Unsafe Shutdowns:                   9

Що це означає: «PASSED» — це не чиста довідка про здоров’я. NVMe/SATA-пристрої можуть «пройти», водночас логуючи помилки медіа. Media and Data Integrity Errors > 0 — червоний прапорець у деградованому масиві.

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

Завдання 7: Переконайтеся, що масив змонтовано і нічого небезпечного не відбувається

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/md0 / ext4 rw,relatime,errors=remount-ro

Що це означає: Root знаходиться на /dev/md0. Це важливо, бо ви не можете легковажно зупиняти масив.

Рішення: Будь-який план відновлення має бути онлайн і обережним. Якщо потрібно зупинити/зібрати, робіть це з rescue-media — не експериментуйте на живому root-масиві.

Завдання 8: Підтвердіть, що конфіг mdadm знає про масив (перевірка надійності при завантаженні)

cr0x@server:~$ grep -R "UUID=3b0d0f3b" /etc/mdadm /etc/mdadm/mdadm.conf
/etc/mdadm/mdadm.conf:ARRAY /dev/md0 metadata=1.2 UUID=3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2 name=server:0

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

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

Завдання 9: Перевірте «примарні метадані» на диску-заміщенні перед додаванням

cr0x@server:~$ sudo mdadm --examine /dev/sdb1
mdadm: No md superblock detected on /dev/sdb1.

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

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

Завдання 10: Клонувати таблицю розділів з хорошого диска на новий

cr0x@server:~$ sudo sfdisk -d /dev/sda | sudo sfdisk /dev/sdb
Checking that no-one is using this disk right now ... OK

Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: SAMSUNG MZ7L3960HCGR-00005
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

sfdisk: Successfully wrote the new partition table.
Syncing disks.

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

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

Завдання 11: Перечитати таблицю розділів і підтвердити, що ядро бачить новий розділ

cr0x@server:~$ sudo partprobe /dev/sdb
cr0x@server:~$ lsblk /dev/sdb
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sdb      8:16   0 931.5G  0 disk
├─sdb1   8:17   0 931.5G  0 part
└─sdb2   8:18   0   512M  0 part

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

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

Завдання 12: Додайте новий член до масиву і спостерігайте, як починається відновлення

cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdb1
mdadm: added /dev/sdb1
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid10]
md0 : active raid1 sdb1[2] sda1[0]
      976630336 blocks super 1.2 [2/1] [U_]
      [=>...................]  recovery =  7.3% (71680000/976630336) finish=58.4min speed=258432K/sec
      bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: <none>

Що це означає: Recovery триває. Зауважте: на початку все ще показує [U_]; коли синхронізовано достатньо регіонів, має стати [UU] після завершення.

Рішення: Не чіпайте масив без потреби. Ваше завдання — моніторити помилки й тримати систему спокійною (CPU, I/O, термальний режим).

Завдання 13: Стежте за прогресом відновлення з більшим контекстом

cr0x@server:~$ watch -n 2 'cat /proc/mdstat; echo; sudo mdadm --detail /dev/md0 | egrep "State|Rebuild|Resync|Raid Devices|Active Devices|Working Devices|Failed Devices"'
Every 2.0s: cat /proc/mdstat; echo; sudo mdadm --detail /dev/md0 | egrep "State|Rebuild|Resync|Raid Devices|Active Devices|Working Devices|Failed Devices"

md0 : active raid1 sdb1[2] sda1[0]
      976630336 blocks super 1.2 [2/2] [UU]
      bitmap: 0/8 pages [0KB], 65536KB chunk

             State : clean
      Raid Devices : 2
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0

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

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

Завдання 14: Оновіть конфіг mdadm і initramfs, щоб наступне перезавантаження не було проблемним

cr0x@server:~$ sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
ARRAY /dev/md0 metadata=1.2 UUID=3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2 name=server:0
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

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

Рішення: Якщо це root-масив, цей крок не опціональний. Відновлення повертає надмірність; initramfs убезпечить наступний раунд завантажень.

Завдання 15: Запустіть неагресивну перевірку консистентності (після відновлення)

cr0x@server:~$ echo check | sudo tee /sys/block/md0/md/sync_action
check
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid10]
md0 : active raid1 sdb1[2] sda1[0]
      976630336 blocks super 1.2 [2/2] [UU]
      [==>.................]  check = 11.6% (113246208/976630336) finish=45.2min speed=317120K/sec

unused devices: <none>

Що це означає: Це читає й порівнює дзеркала. На RAID5/6 check читає паритет; він може виявити латентні помилки.

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

Завдання 16: Перевірте лічильники mismatch (і вирішіть, чи «repair»)

cr0x@server:~$ cat /sys/block/md0/md/mismatch_cnt
0

Що це означає: Нуль невідповідностей — це бажаний результат. На RAID5/6 невідповідності можуть вказувати на write hole, погану оперативну пам’ять або ненадійний диск/контролер, який бреше під навантаженням.

Рішення: Не запускайте repair автоматично. Repair записує корекції — використовуйте його лише коли знаєте, яка сторона вірна (часто: після перевірки апаратури і наявності бекапів).

Контрольні списки / покроковий план (безпечна заміна диска)

Ось план, що працює під тиском. Він свідомо нудний. Нудність — це добре; вона зберігає ваші дані.

Чекліст A: Перед тим як щось чіпати

Підтвердіть, що бекапи справжні. Не «у нас є снепшоти». Справжнє, протестоване відновлення для даних на цьому масиві.
Збережіть поточний стан: /proc/mdstat, mdadm --detail, lsblk, останні журнали ядра.
Ідентифікуйте проблемний шлях за серійним номером/WWN. Запишіть його. Зробіть фото етикетки шасі, якщо вона фізична.
Перевірте, чи масив уже resync. Якщо так, ваша втручання може його сповільнити або дестабілізувати.
Встановіть очікування. У RAID5/6 час відновлення під навантаженням не дорівнює рекламним цифрам вендора.

Чекліст B: Якщо диск все ще видимий, але «faulty»

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

cr0x@server:~$ sudo mdadm --detail /dev/md0 | egrep "faulty|removed|active"
      RaidDevice State
      active sync   /dev/sda1
      removed
cr0x@server:~$ sudo mdadm /dev/md0 --fail /dev/sdb1
mdadm: set /dev/sdb1 faulty in /dev/md0
cr0x@server:~$ sudo mdadm /dev/md0 --remove /dev/sdb1
mdadm: hot removed /dev/sdb1 from /dev/md0

Інтерпретація: Позначення як faulty, а потім видалення створює чистий слот. Це також перешкоджає випадковим частковим читанням з вмираючого диска.

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

Чекліст C: Правильна підготовка диска-заміни

Є два великі правила: відповідати схемі розділів і переконатися, що старі RAID-метадані не залишилися.

Розмітьте його так, щоб збігався з існуючим членом. Використовуйте клонування sfdisk, а не ручне створення.
Очистіть старі md суперблоки, якщо вони є. Використовуйте mdadm --zero-superblock на розділах-членах, а не на всьому диску, якщо можете уникнути.
Перевірте розміри секторів. 4Kn диск в масиві 512e може створити проблеми сумісності залежно від контролерів і розмітки.

cr0x@server:~$ sudo mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 1.2
           UUID : 11111111:22222222:33333333:44444444
     Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing)
cr0x@server:~$ sudo mdadm --zero-superblock /dev/sdb1
mdadm: Unrecognised md component device - /dev/sdb1
cr0x@server:~$ sudo wipefs -n /dev/sdb1
offset               type
0x00000400           linux_raid_member   [raid]

Інтерпретація: Приклад показує суперечливі сигнали, які ви побачите на практиці: застарілі метадані і інструменти, що не погоджуються, коли пристрої напівініціалізовані.
Якщо wipefs -n показує linux_raid_member, потрібно видалити його перед додаванням у новий масив.

Рішення: Використайте wipefs для стирання сигнатури, потім перевірте mdadm --examine, щоб переконатися, що вона справді зникла.

cr0x@server:~$ sudo wipefs -a /dev/sdb1
/dev/sdb1: 8 bytes were erased at offset 0x00000400 (linux_raid_member): a9 2b 4e fc 00 00 00 00
cr0x@server:~$ sudo mdadm --examine /dev/sdb1
mdadm: No md superblock detected on /dev/sdb1.

Чекліст D: Додати диск і контролювати вплив відновлення

Відновлення дуже інтенсивне по I/O. Ви можете обміняти швидкість на безпеку (нижче навантаження) або швидкість на ризик (максимальне навантаження).
У продакшні я віддаю перевагу «закінчити надійно», а не «закінчити швидко і можливо померти посередині».

cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_min
1000
cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_max
200000
cr0x@server:~$ echo 50000 | sudo tee /proc/sys/dev/raid/speed_limit_max
50000

Інтерпретація: Це обмеження в KiB/s. Обмеження max швидкості може зберегти прийнятну затримку для клієнтів і зменшити тепловий стрес. Це подовжить час відновлення.

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

cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdb1
mdadm: added /dev/sdb1

Чекліст E: Після відновлення — укріпіть, щоб не повторювалось

Оновіть mdadm.conf і перебудуйте initramfs.
Запустіть check і перегляньте лічильники mismatch.
Виправте джерело проблеми: замініть кабель/backplane, обновіть прошивки, налаштуйте моніторинг.
Налаштуйте моніторинг для подій md і попереджень SMART.

cr0x@server:~$ sudo systemctl enable --now mdadm --quiet || true
cr0x@server:~$ sudo systemctl status mdadm --no-pager
● mdadm.service - MD array assembly and monitoring
     Loaded: loaded (/lib/systemd/system/mdadm.service; enabled; preset: enabled)
     Active: active (exited) since Mon 2025-12-29 09:30:14 UTC; 2min ago

Інтерпретація: У Debian поведінка сервісу може бути «active (exited)» і при цьому бути правильною; він збирає масив і передає моніторинг іншим юнітам/конфігураціям.

Рішення: Переконайтеся, що у вас є реальне оповіщення (email, Prometheus exporter або інше). «Enabled» без приймача — це театральність.

Особливі випадки: RAID1 vs RAID5/6 vs RAID10, битмапи та reshape

RAID1: найпростіше відновлення, тому тут люди розслабляються

RAID1 відновлення — просте: md копіює блоки з хорошого диска на новий. Найбільший ризик — людський:
поміняти не той диск або відновити не з тієї сторони у split-brain ситуації (рідко на одному хості, але трапляється після дивних ресетів контролера й панічних перезавантажень).

RAID1 може бути clean, degraded і водночас консистентним. Не плутайте «degraded» із «dirty».
Відновлення безпечне, якщо залишився диск здоровий.

RAID5/6: деградація означає, що кожне читання — групова операція

У паритетному RAID відсутній диск означає реконструкцію на читання (або читання по всіх залишках) і велике I/O-навантаження.
Під час відновлення ви сильно навантажуєте всі вцілілі диски — саме тоді виявляються маргінальні пристрої.

Практичні наслідки:

Каденс scrub має значення. Якщо ви ніколи не робите scrub, латентні помилки виявляться під час відновлення. Це найгірший момент.
Продуктивність хитатиметься. Очікуйте спалахи латентності. Плануйте обмеження відновлення.
Маєте умову зупинки. Якщо другий диск починає видавати помилки під час відновлення RAID5, зупиніться й переоцініть. Продовження може знищити те, що залишилося.

RAID10: відновлення локалізовані, але не розслабляйтесь

RAID10 відновлює пари дзеркал. Це зазвичай швидше й менш стресово, ніж RAID5/6, але не чарівно.
Якщо ви втрачаєте диск у парі, і його дзеркальний партнер старий, відновлення читає весь партнер — знову ж таки, навантаження.

Битмапи: ваш друг після некоректного завершення

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

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

Reshape: не робіть цього під час деградації, якщо не любите трилери

mdadm може reshape — змінювати рівень RAID, додавати диски, змінювати розмір chunk тощо. Це потужно.
Це також операція, де «майже правильно» — неприпустимо.

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

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

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

Середня SaaS-компанія мала Debian-сервери з mdadm RAID1 для завантаження і RAID10 для даних. Вузол повідомив про деградований RAID1 на md0.
Інженер на виклику побачив, що пропав /dev/sdb, і припустив «диск 2 помер», бо це зручна історія:
Linux називає диски у приємному стабільному порядку, і всесвіт добрий.

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

Через два дні відбулося планове перезавантаження. Система впала в initramfs із повідомленням, що не може зібрати root.
Що змінилося? Перенумерація. Оновлення прошивки і трохи інший порядок виявлення поміняли /dev/sda і /dev/sdb.
Диск, з якого робили rebuild, не був тим, ким усі думали. Масив не збирався консистентно, бо mdadm.conf не оновили і initramfs мав застарілі підказки.

Відновлення було не героїчним, а обережним. Вони завантажили rescue-media, зібрали за UUID, підтвердили, який член має останній лічильник подій,
і відновили правильне дзеркало. Справжній урок: /dev/sdX не є ідентичністю.

Після цього вони промаркували відсіки серійними номерами і оновили runbook: кожна операція з диском починається з /dev/disk/by-id,
а кожна зміна mdadm закінчується update-initramfs -u.

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

Інша організація мала велику аналітичну навантаженість і хотіла, щоб відновлення проходили швидше. Хтось знайшов обмеження швидкості md і підняв
speed_limit_max до великого числа по всьому парку. В наступному збої відновлення летіло.
Дашборд виглядав чудово. Час до відновлення впав. В чаті лунали п’ятірки.

Але під час робочих годин латентність теж стрибнула. Не трохи. Відновлення конкурувало з продакшн-читаннями, насичувало чергу HBA
і підвищувало температуру пристроїв. Один із «здорових» дисків почав логувати UDMA CRC-помилки — класичний знак маргінального лінку.
Потім він почав таймаутитися під навантаженням. md його виключив. На RAID6 це переживається; на RAID5 — ні.

Найгірше: спочатку це навіть не була проблема диска. Кабель був трохи неплотно підключений місяцями, але нічого не трясло його достатньо,
щоб показати симптоми. Відновлення перетворило латентну проблему на outage.

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

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

Команда фінансового сервісу працювала з mdadm RAID6 на наборі nearline-дисків. У них були дві звички, які ніхто не святкував:
щомісячні перевірки RAID і сувора процедура заміни з перевіркою серійного номера.

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

Оскільки вони регулярно робили щомісячні перевірки, команда вже знала, що лічильники mismatch стабільні і що інші диски не логують очікуваних секторів.
Також у них були свіжі базові показники SMART. Помилка другого диска була новою й ізольованою; вони понизили швидкість відновлення і дали йому закінчитись.
Потім запланували контрольовану заміну другого диска в наступне вікно.

Ніякої втрати даних. Ніяких вихідних. Ніякого драмату. Причина успіху — болісно неприваблива:
вони не виявили свої проблеми медіа вперше під час відновлення.

Коротка перефразована думка від адмірала Грейс Хоппер: «Найбільш небезпечна фраза — “ми завжди так робили”». Для сховищ: перевіряйте, не успадковуйте.

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

1) Симптом: Масив деградований після перезавантаження; диски виглядають «в порядку»

Причина: mdadm.conf/initramfs не містить правильних визначень ARRAY; збірка покладається на сканування і таймінг.

Виправлення: Відновіть конфіг та initramfs після стабілізації.

cr0x@server:~$ sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
ARRAY /dev/md0 metadata=1.2 UUID=3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2 name=server:0
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

2) Симптом: Додаєте диск, і mdadm каже «device has wrong UUID» або відмовляється додати

Причина: Диск-заміна ще має старий md суперблок або підписи файлових систем (поширено з повторно використаними спєрами).

Виправлення: Очистіть сигнатури на конкретному розділі-члені, потім додавайте.

cr0x@server:~$ sudo wipefs -n /dev/sdb1
offset               type
0x00000400           linux_raid_member   [raid]
cr0x@server:~$ sudo wipefs -a /dev/sdb1
/dev/sdb1: 8 bytes were erased at offset 0x00000400 (linux_raid_member): a9 2b 4e fc 00 00 00 00
cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdb1
mdadm: added /dev/sdb1

3) Симптом: Відновлення дуже повільне і латентність системи жахлива

Причина: Відновлення насичує I/O; планувальник/глибина черги взаємодіє погано з робочим навантаженням; помилки пристроїв викликають повтори.

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

cr0x@server:~$ echo 20000 | sudo tee /proc/sys/dev/raid/speed_limit_max
20000
cr0x@server:~$ sudo journalctl -k -b | grep -E 'reset|timeout|I/O error' | tail -n 20
Dec 29 09:12:04 server kernel: blk_update_request: I/O error, dev sdc, sector 1234567 op 0x0:(READ)

4) Симптом: Відновлення RAID5 завершується з «read error» на іншому диску

Причина: Під час відновлення знайдено латентний поганий сектор; RAID5 не може терпіти другу відмову або невідновлюваний читальний збій.

Виправлення: Зупиніться й оцініть: спробуйте ремап сектору шляхом читання проблемної області; розгляньте клонування; відновлення з бекапу якщо потрібно.

Чесно: RAID5 — це не бекап, і під час відновлення він не дає особливого відчуття надійності. Ставтеся до цього як до інциденту, а не попередження.

5) Симптом: Масив показує «clean», але лічильник mismatch зростає під час check

Причина: Попереднє некоректне завершення, write hole (RAID5), ненадійна RAM/контролер або тиха корупція, прихована раніше.

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

cr0x@server:~$ cat /sys/block/md0/md/mismatch_cnt
12

6) Симптом: Диск постійно викидають, але SMART виглядає нормально

Причина: Проблеми на рівні лінку (CRC), ресети контролера, проблеми backplane, енергопостачання.

Виправлення: Замініть кабель/слот backplane; перевірте живлення; перегляньте журнали ядра на предмет ресетів. Не продовжуйте підміняти «хороші» диски в поганому слоті.

7) Симптом: Ви не можете визначити, який фізичний диск — /dev/sdb

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

Виправлення: Використовуйте by-id серійники, властивості udev і (якщо є) інструменти керування шасі; потім промаркуйте обладнання.

Жарт №2: Єдина річ більш крихка, ніж деградований RAID5, — це впевненість того, хто щойно набрав --force.

FAQ

1) Чи можу я тримати сервер увімкненим під час відновлення?

Зазвичай так. mdadm створений для онлайн-відновлень. Компроміс — продуктивність і ризик: навантаження відновлення може виявити латентні проблеми.
Якщо це ваш root-масив, онлайн часто є єдиним практичним варіантом без простою.

2) Чи слід негайно замінити диск або спочатку перепідключити його?

Якщо журнали показують скиди лінку/CRC-помилки і пристрій зникає/з’являється — спочатку перепідключіть і перевірте кабелі/backplane.
Якщо SMART показує помилки медіа/цілісності або переназначені/очікувані сектори (залежно від типу пристрою) — замініть диск.

3) Як зрозуміти, який диск витягнути в hot-swap шасі?

Використовуйте серійники в /dev/disk/by-id і звіряйте з етикетками дисків. Якщо є відображення слотів (SAS expander) — користуйтесь ним.
Не покладайтеся на /dev/sdX.

4) Який найнадійніший спосіб розмітити новий диск?

Клонувати таблицю розділів з відомо хорошого члена через sfdisk -d і передати в sfdisk.
Потім перевірити через lsblk і лише потім додавати в md.

5) mdadm каже масив «clean, degraded». Це погано?

Краще, ніж «dirty, degraded», але все ще немає надмірності. Друга проблема з диском може призвести до втрати даних залежно від рівня RAID.
Ставтеся до цього як до нагальної проблеми, а не паніки.

6) Чи слід запускати `sync_action=repair` після відновлення?

Не за замовчуванням. Repair записує корекції. Якщо є невідповідності, спочатку визначте, чи вони очікувані (некоректне завершення) або симптоматичні
(апарат/прошивка). Майте бекапи перед тим, як дозволяти будь-яким «repair» на блоці.

7) Чому відновлення зайняло стільки часу в порівнянні з рейтингом диска?

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

8) Чи потрібно оновлювати initramfs після заміни члена RAID?

Якщо масив бере участь у завантаженні (root, /boot) — так. Оновіть /etc/mdadm/mdadm.conf і виконайте update-initramfs -u.
Інакше ризикуєте помилкою завантаження або непослідовною збіркою масиву.

9) Що робити, якщо я замінив не той диск?

Зупиніться. Нічого не додавайте. Ідентифікуйте залишкові диски за серійними номерами, перегляньте суперблоки і визначте, який член має останній лічильник подій.
Якщо ви не впевнені — завантажте rescue-media і збирайте за UUID. Вгадування перетворює «відновлюване» на «навчання на кар’єрі».

10) Чи «безпечніший» mdadm порівняно з апаратним RAID?

mdadm цілком придатний для продукції при правильній експлуатації: моніторинг, протестоване відновлення і дисципліновані процедури.
Апаратний RAID може приховувати проблеми, поки вже не зможе їх приховати. Програмний RAID чесний — це незручно, але корисно.

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

Деградований mdadm RAID на Debian 13 піддається безболісному відновленню, якщо ви утримаєтесь від кнопки паніки і дотримаєтесь чіткої послідовності:
ідентифікуйте правильний диск за стабільною ідентичністю, підтвердьте режим відмови, замініть чисто, відновіть під контрольованим навантаженням, а потім перевірте консистентність.

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

Налаштуйте оповіщення mdadm, щоб «degraded» ставало пейджем, а не археологічним відкриттям.
Заплануйте періодичні check і відстежуйте mismatch counts з часом.
Промаркуйте диски серійними номерами і документуйте відповідність слотів. Майбутній ви купить нинішньому вам каву.
Після будь-яких робіт з дисками на завантажувальних масивах: оновіть mdadm.conf і перебудуйте initramfs.