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

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

Що таке аварія RAID

RAID-масив може перейти в аварійний або деградований стан з різних причин. Найчастіше це фізичний вихід з ладу одного з дисків, поява великої кількості bad blocks, помилки читання, проблеми з кабелем, живленням, backplane, RAID-контролером або самим сервером.

У випадку RAID 1 система зазвичай продовжує працювати після відмови одного диска, бо дані дзеркаляться. У RAID 5 допускається відмова одного диска. У RAID 6 — двох дисків. У RAID 10 усе залежить від того, які саме диски вийшли з ладу: іноді масив витримує кілька аварій, а іноді один “невдалий” другий диск може покласти весь масив.

Проблема в тому, що RAID рідко “помирає красиво”. Часто один диск уже давно мав помилки, другий починає сипатися під час rebuild, третій має нестабільний контакт, а адміністратор бачить лише червону лампочку і повідомлення “degraded”. Тому перше правило — не панікувати і не робити дій, які змінюють структуру масиву, доки не зрозуміло, що саме сталося.

Перші дії при аварії RAID

Якщо сервер ще працює, головне завдання — зберегти дані. Не потрібно одразу бігти міняти диски, перезавантажувати сервер або “перезібрати RAID”. Спочатку потрібно оцінити стан.

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

Друге — потрібно зафіксувати поточний стан: які диски в масиві, який RAID-рівень, який диск позначений як failed, які є помилки у контролера, які серійні номери дисків, який порядок дисків у слотах. Це критично важливо. У RAID аваріях одна з найгірших помилок — витягнути не той диск.

Третє — не ініціалізувати масив. Якщо RAID-контролер пропонує “Initialize”, “Create new array”, “Clear configuration” або щось подібне — це не відновлення. Це може знищити метадані масиву або суттєво ускладнити відновлення.

Як діагностувати RAID-масив

Діагностику потрібно починати з RAID-контролера або програмного RAID, залежно від того, яка технологія використовується.

Якщо це апаратний RAID, стан можна перевірити через утиліти виробника: MegaCLI, StorCLI, perccli, arcconf, hpssacli, утиліти Dell PERC, HP Smart Array, Broadcom/LSI, Adaptec та інші. Вони показують стан virtual drive, physical drive, battery/BBU/cache, помилки читання, predictive failure, rebuild progress, foreign configuration.

Якщо це програмний RAID у Linux, наприклад mdadm, стан дивляться через:

cat /proc/mdstat
mdadm --detail /dev/md0

Для ZFS перевіряють:

zpool status

Для Proxmox, якщо використовуються ZFS або mdadm, також важливо дивитися системні журнали:

dmesg
journalctl -xe
journalctl -k

Окремо потрібно перевірити SMART-стан дисків:

smartctl -a /dev/sdX

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

Особливу увагу варто звертати на такі показники: Reallocated Sector Count, Current Pending Sector, Offline Uncorrectable, UDMA CRC Error Count, Read Error Rate, Media Wearout Indicator для SSD, Percentage Used, Wear Leveling Count, помилки інтерфейсу та температури.

Якщо є UDMA CRC errors, це часто може бути не сам диск, а кабель, backplane, контролер або поганий контакт. Якщо є pending sectors або uncorrectable errors — це вже серйозний сигнал, що диск має проблеми з поверхнею або пам’яттю.

Чого не можна робити при аварії RAID

Найперше — не створювати новий RAID-масив поверх старого. Деякі адміністратори в паніці заходять у BIOS RAID-контролера, бачать, що масив “зник”, і створюють новий з такими самими дисками. Це дуже небезпечна дія.

Не можна міняти кілька дисків одночасно, якщо немає повного розуміння, які з них справді вийшли з ладу. Не можна запускати rebuild на сумнівних дисках без резервної копії, якщо дані критичні. Не можна робити “force online” навмання, особливо якщо невідомо, який диск випав першим, а який другим.

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

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

Як правильно відновлювати RAID

Правильне відновлення починається не з заміни диска, а з резервної копії. Якщо масив ще читається, потрібно максимально швидко скопіювати критичні дані на інший сервер, NAS, backup-сховище або зовнішнє сховище. Особливо це стосується баз даних, віртуальних машин, бухгалтерських систем, CRM, ERP, поштових серверів і файлових архівів.

Після цього потрібно визначити, який диск справді несправний. Для апаратного RAID слід подивитися статус фізичних дисків, серійні номери, predictive failure та журнал подій контролера. Для програмного RAID — перевірити mdadm, ZFS або іншу систему керування масивом.

Якщо вийшов з ладу один диск у RAID 1, RAID 5, RAID 6 або RAID 10, і решта дисків у нормальному стані, стандартна процедура така: несправний диск виводиться з масиву, фізично замінюється на новий такого самого або більшого обсягу, після чого запускається rebuild. У багатьох апаратних RAID-контролерах rebuild стартує автоматично після вставлення нового диска. В інших випадках його потрібно запустити вручну.

Для mdadm типова логіка така:

mdadm /dev/md0 --fail /dev/sdX1
mdadm /dev/md0 --remove /dev/sdX1

Після заміни диска потрібно створити аналогічну розмітку і додати новий розділ у масив:

mdadm /dev/md0 --add /dev/sdY1

Після цього стан rebuild можна дивитися так:

cat /proc/mdstat

Але ці команди не можна виконувати механічно. Потрібно точно знати, який саме диск вийшов з ладу, який масив використовується і яка структура розділів.

Rebuild RAID: найнебезпечніший етап

Rebuild — це не просто “відновлення”. Це інтенсивне читання з усіх живих дисків і запис на новий диск. Якщо інші диски старі або мають приховані помилки, саме під час rebuild вони можуть почати сипатися.

Тому перед rebuild бажано мати актуальний backup. Якщо backup немає, а дані критичні, краще спочатку зробити посекторні копії дисків або звернутися до спеціалістів з відновлення даних. Особливо це стосується випадків, коли одночасно випало кілька дисків, RAID-контролер бачить foreign configuration, масив не монтується, файлова система пошкоджена або невідомий порядок дисків.

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

Якщо RAID не піднімається

Якщо RAID-масив не визначається або контролер показує foreign configuration, не потрібно одразу очищати конфігурацію. “Foreign” означає, що контролер бачить на дисках метадані масиву, які не збігаються з поточною конфігурацією контролера. У багатьох випадках foreign configuration можна імпортувати, але робити це треба обережно.

Якщо масив не піднявся після збою контролера, можливо, самі диски справні, а проблема в контролері. У такому випадку іноді допомагає заміна RAID-контролера на аналогічний або сумісний. Але перед цим потрібно зафіксувати конфігурацію: RAID-рівень, stripe size, порядок дисків, cache policy, кількість дисків, розмір virtual drive.

Якщо було кілька failed-дисків, ситуація складніша. Один диск міг випасти давно, а другий — щойно. Для RAID 5 це може означати втрату масиву. Але іноді перший “failed” диск ще частково читається, і саме він потрібен для відновлення. У таких випадках не можна просто вибрати “найновіші” або “найменш червоні” диски. Потрібен аналіз журналів, часу випадіння, SMART-стану і посекторне копіювання.

Відновлення даних з RAID

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

Для Linux часто використовують ddrescue, бо він краще працює з дисками, які мають помилки читання:

ddrescue -f -n /dev/sdX /mnt/backup/disk1.img /mnt/backup/disk1.log

Після створення образів можна аналізувати структуру RAID, порядок дисків, stripe size, parity rotation і намагатися зібрати масив у read-only режимі. Але це вже зона складного відновлення, де помилка може коштувати всього масиву.

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

RAID і резервні копії: чому це різні речі

RAID не замінює backup. Це потрібно повторювати щоразу, коли хтось каже: “У нас же RAID, навіщо ще резервні копії?”

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

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

Профілактика аварій RAID

Найкраще відновлення RAID — це ситуація, до якої підготувалися заздалегідь.

На сервері має бути налаштований моніторинг стану RAID-контролера, SMART, температур, помилок дисків і файлової системи. Повідомлення про degraded array мають приходити адміністратору одразу, а не через місяць, коли другий диск уже теж почав помирати.

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

Для важливих серверів бажано мати запасні диски тієї самої моделі або сумісного класу. У RAID не варто використовувати випадковий набір старих дисків різного віку, різної швидкості та невідомого стану. Особливо небезпечно збирати RAID 5 на великих старих HDD без нормального backup — rebuild такого масиву може стати лотереєю.

Що робити після відновлення

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

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

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

Висновок

Аварія RAID — це не катастрофа, якщо до неї готові. Але вона легко стає катастрофою, якщо діяти навмання.

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

RAID — це корисний інструмент, але він не пробачає самовпевненості. Сервери ламаються, диски помирають, контролери збоять, а людський фактор іноді небезпечніший за bad blocks. Тому справжня надійність — це не тільки RAID, а комплекс: моніторинг, backup, перевірене відновлення, документація, дисципліна і холодна голова адміністратора в момент аварії.