Як перевірити програмний RAID і здоров’я дисків на сервері

Оновлено 4 жовтня 2026 10 хв читання Read in English

Зміст статті

Стаття для адміністратора виділеного сервера з двома або більше дисками. За пів години ви перевірите стан програмного RAID і самих дисків, налаштуєте сповіщення про збої та знатимете, що робити, коли диск вийде з ладу.

Що знадобиться#

Вхід по SSH користувачем із правами sudo (команди нижче виконуйте від root, після sudo -i) або права адміністратора Windows Server.
Debian 13, Ubuntu 24.04 або 26.04 — назви пакетів і служб перевірено для цих випусків.
Свіжа резервна копія поза сервером — перш ніж щось робити з розділами чи масивом.

apt update
apt install smartmontools nvme-cli gdisk dosfstools

Як розмічено диски#

Якщо в сервері два чи більше дисків, систему типово ставлять на всі диски з програмним RAID 1 (дзеркалом). Типова розмітка Linux (UEFI): розділ EFI (ESP) — свій на кожному диску, поза RAID, змонтовано лише один, як /boot/efi; /boot — у RAID 1, зазвичай /dev/md2; корінь / — у RAID 1, зазвичай /dev/md3; swap — окремий розділ на кожному диску, поза RAID. На Debian 13, Proxmox VE 9 і Ubuntu 26.04 розділ EFI теж дзеркалюється.

Імена /dev/sda, /dev/sdb і номери розділів далі — приклад; диски NVMe називаються на зразок /dev/nvme0n1, їхні розділи — /dev/nvme0n1p2.

Крок 1 Стан масиву#

cat /proc/mdstat
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
mdadm --detail /dev/md3

У /proc/mdstat дивіться на квадратні дужки біля кожного масиву: [2/2] [UU] — обидва диски на місці, [2/1] [U_] — масив деградував і працює на одному диску.

У виводі mdadm --detail важливі рядок State (clean чи active — норма, degraded — надлишковості немає), лічильник Failed Devices і стан кожного розділу внизу: active sync, faulty, removed.

Крок 2 Здоров’я дисків#

lsblk -d -o NAME,MODEL,SERIAL,SIZE,ROTA,TRAN
smartctl -H /dev/sda
smartctl -a /dev/sda
smartctl -a /dev/nvme0
nvme smart-log /dev/nvme0

smartctl -H показує, як диск сам оцінює свій стан. FAILED — диск треба негайно міняти, але й PASSED нічого не обіцяє: диски нерідко виходять з ладу і з такою оцінкою. Дивіться на окремі показники.

Показник	Що має насторожити
SATA: `5 Reallocated_Sector_Ct`	`RAW_VALUE` більше нуля і зростає
SATA: `197 Current_Pending_Sector`, `198 Offline_Uncorrectable`	будь-яке ненульове значення
SATA SSD: показник зношення, наприклад `Wear_Leveling_Count` (назва залежить від виробника)	`VALUE` наближається до порога `THRESH`
NVMe: `Critical Warning`	будь-що, крім `0x00`
NVMe: `Available Spare`	знижується до `Available Spare Threshold`
NVMe: `Percentage Used`	наближається до 100%
NVMe: `Media and Data Integrity Errors`	більше нуля

Крок 3 Сповіщення і періодична звірка#

У файлі /etc/mdadm/mdadm.conf у рядку MAILADDR типово вказано root. Замініть його на адресу, яку справді читають, перезапустіть моніторинг і надішліть тестовий лист:

systemctl restart mdmonitor.service
mdadm --monitor --scan --oneshot --test

Листи mdadm надсилає через локальний sendmail, тож потрібна поштова служба, що пересилає пошту назовні (наприклад, Postfix). Інакше сповіщення залишаться на сервері, а про деградацію ви дізнаєтеся, лише коли відмовить другий диск.

mdmonitor.service надсилає лист одразу після збою, mdmonitor-oneshot.timer щодня нагадує про деградований масив, а mdcheck_start.timer і mdcheck_continue.timer щомісяця звіряють масиви: читають диски повністю і вчасно виявляють сектори, що не читаються. Після звірки cat /sys/block/md3/md/mismatch_cnt у нормі показує 0.

За самими дисками стежить служба smartd з пакета smartmontools. У /etc/smartd.conf у рядку DEVICESCAN замініть root після -m на свою адресу і виконайте systemctl restart smartmontools.service. Для перевірки тимчасово допишіть у кінець рядка -M test — після перезапуску надійде тестовий лист (потрібна команда mail з пакета bsd-mailx або mailutils).

Що робити, коли масив деградував#

Не перезавантажуйте сервер і нічого не «лагодьте» навмання: на одному диску масив працює, але другої відмови не переживе.
Зробіть свіжу резервну копію поза сервером — див. правило 3-2-1.
З’ясуйте, який диск збійний, і запишіть серійні номери всіх дисків:
```
mdadm --detail /dev/md3
lsblk -d -o NAME,MODEL,SERIAL,SIZE
smartctl -i /dev/sdb
nvme list
```
Якщо збійного диска в системі вже не видно, знайти його допоможуть номери справних.
Зверніться до технічної підтримки (працює 24/7): телефон +38 044 206 08 08, пошта info@united.net.ua. Диск замінюють працівники дата-центру. У заявці вкажіть адресу сервера, серійні номери збійного диска і всіх інших дисків, додайте вивід cat /proc/mdstat та smartctl -a. Підтвердьте, що дані скопійовано й ви розумієте ризик їх утрати, та назвіть зручний час — заміну роблять цілодобово.

На серверах без апаратного RAID диск міняють на вимкненому сервері, тож заплануйте простій; «на гарячу», без вимкнення, диски міняють лише на серверах з RAID-контролером. Якщо якісь розділи збійного диска ще залишаються в масивах, перед заміною виведіть їх звідти.

Увага. Двічі перевірте ім’я розділу: якщо позначити збійним розділ єдиного справного диска, масив залишиться без робочої копії даних.

mdadm --manage /dev/md3 --fail /dev/sdb3
mdadm --manage /dev/md3 --remove /dev/sdb3

Після заміни: повертаємо диск у масив#

Програмний RAID після заміни ви збираєте самі. У прикладі /dev/sda — справний диск із даними, /dev/sdb — новий порожній.

Увага. Після заміни імена дисків можуть помінятися місцями. Перед кожною командою перевіряйте за серійним номером, де який диск: новий не має розділів і не входить до жодного масиву.

lsblk -o NAME,SIZE,TYPE,FSTYPE,SERIAL,MOUNTPOINTS
cat /proc/mdstat

1. Скопіюйте таблицю розділів#

Увага. У команді sgdisk --replicate диск після знака «=» — приймач (новий диск, його таблицю буде перезаписано), а останній аргумент — джерело (справний диск). Якщо їх переплутати, порожня таблиця затре таблицю справного диска; тоді, не перезавантажуючи сервер, одразу відновіть її: sgdisk --load-backup=/root/sda-gpt.bak /dev/sda. --randomize-guids теж застосовуйте лише до нового диска.

sgdisk --backup=/root/sda-gpt.bak /dev/sda
sgdisk --replicate=/dev/sdb /dev/sda
sgdisk --randomize-guids /dev/sdb
sgdisk --print /dev/sdb

Команди розраховано на таблицю GPT (lsblk -d -o NAME,PTTYPE показує gpt); для MBR (dos) — sfdisk -d /dev/sda | sfdisk /dev/sdb, ліворуч джерело.

2. Додайте розділи до масивів#

Який розділ до якого масиву належить, видно з mdadm --detail: якщо в /dev/md2 працює /dev/sda2, додавайте /dev/sdb2. Якщо розділ EFI теж у дзеркалі (Debian 13, Proxmox VE 9, Ubuntu 26.04), так само додайте до його масиву розділ EFI нового диска.

mdadm --manage /dev/md2 --add /dev/sdb2
mdadm --manage /dev/md3 --add /dev/sdb3
watch -n 5 cat /proc/mdstat

Рядок recovery показує відсоток і орієнтовний час; на великих HDD синхронізація триває години. Сервер працює, але повільніше; до її завершення краще його не перезавантажувати.

3. Розділ EFI і завантажувач#

Без завантажувача на новому диску сервер не завантажиться, коли відмовить старий. Спершу з’ясуйте режим завантаження:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

BIOS. Виконайте grub-install /dev/sdb, потім dpkg-reconfigure grub-pc і позначте обидва диски, щоб оновлення GRUB потрапляли на кожен.

UEFI. Завантажувач міститься на розділі ESP (FAT32). Якщо ESP у дзеркалі (у lsblk під ним видно масив raid1), його вже повернуто на попередньому кроці. Якщо на кожному диску окремий ESP, на новому він порожній: створіть файлову систему і скопіюйте вміст зі справного диска. Якщо /etc/fstab монтує /boot/efi за міткою (LABEL=), дайте новому ESP таку саму мітку параметром -n команди mkfs.vfat.

Увага. mkfs.vfat знищує вміст розділу. Переконайтеся, що /dev/sdb1 — ESP нового диска, а findmnt показує /boot/efi зі справного. Якщо його не змонтовано, змонтуйте ESP справного диска; якщо /etc/fstab указує його за UUID, виправте UUID (покаже blkid), інакше наступне завантаження може зупинитися в аварійному режимі.

findmnt /boot/efi
mkfs.vfat -F 32 /dev/sdb1
mkdir -p /mnt/esp-new
mount /dev/sdb1 /mnt/esp-new
cp -r /boot/efi/. /mnt/esp-new/
umount /mnt/esp-new
efibootmgr -v

efibootmgr -v показує записи завантаження UEFI; чи потрібен запис для нового диска і чи можна змінювати порядок завантаження, уточніть у підтримки. Після оновлень GRUB повторюйте копіювання.

4. Створіть swap на новому диску#

Swap не входить до RAID: створіть його на розділі нового диска з тим самим номером, що й swap на справному. Якщо /etc/fstab указує swap за UUID, перед swapon -a замініть там UUID зі старого диска на виведений blkid.

mkswap /dev/sdb4
blkid -s UUID -o value /dev/sdb4
swapon -a
swapon --show

Якщо сервер не завантажується#

Попросіть у підтримки режим відновлення: сервер перезавантажать у тимчасову систему Linux з доступом по SSH (пароль надішлють листом, або вхід буде за вашим публічним ключем). У ній можна змонтувати диски, зробити chroot, полагодити завантажувач і скопіювати дані. Щоб вийти з режиму відновлення, знову зверніться до підтримки — сервер перезавантажать з диска. Для Windows є окремий режим відновлення.

Апаратний RAID#

На частині моделей стоїть апаратний RAID-контролер (у картці конфігурації — «апаратний RAID»). Система тоді бачить один логічний диск, а в /proc/mdstat масивів немає. Стан масиву і дисків перевіряють утилітою контролера, наприклад storcli або MegaCLI. Після заміни диска такий масив перебудовується сам.

Windows Server#

На Windows Server дзеркало зібрано засобами Windows на динамічних дисках. Стан дисків покаже PowerShell, запущений від імені адміністратора:

Get-PhysicalDisk | Format-Table DeviceId, FriendlyName, SerialNumber, HealthStatus, OperationalStatus

HealthStatus має бути Healthy; Warning або Unhealthy — привід звернутися до підтримки. Стан дзеркала покажуть команди list disk і list volume у diskpart: Healthy — норма, Failed Rd — надлишковість втрачено, Rebuild — триває синхронізація. У разі збою — спершу резервна копія, потім заявка в підтримку із серійними номерами всіх дисків.

Як перевірити результат#

У /proc/mdstat усі масиви показують [UU].
smartctl -H для кожного диска показує PASSED, показники з таблиці в нормі.
Тестові листи від mdadm і smartd дійшли.
Після заміни диска swapon --show показує swap на обох дисках, а сервер завантажується без помилок. Перевірте це плановим перезавантаженням у зручний час; заздалегідь попросіть у підтримки віддалену консоль (на Лайт її може не бути) і вкажіть у запиті свою публічну IP-адресу: посилання діє лише з неї й обмежений час.

Типові помилки#

RAID вважають резервною копією. RAID рятує лише від відмови диска: видалений файл, невдале оновлення чи шифрувальник одразу зачіпають обидва диски. Резервні копії потрібні окремо — див. правило 3-2-1.

Що далі#

Налаштуйте резервні копії: restic для Linux, вбудовані засоби Windows Server, бази даних. На основних лінійках є місце для резервних копій на окремому сховищі; копіювання ви налаштовуєте самі.