Відповідь одразу: Відновлення даних з RAID-масиву вимагає негайної зупинки всіх спроб самостійного відновлення. Щойно масив падає — особливо під час критичного rebuild — виникає ризик каскадного виходу з ладу інших дисків і остаточної втрати даних. Професійна лабораторія зчитує дані навіть з масиву, який є нечитабельним звичайними засобами, шляхом клонування на рівні секторів і ручної реконструкції парності, без навантаження на оригінальні носії. Шанси на успіх високі, якщо ви припинили запис на масив і не намагалися виконати повторні rebuild. Процедура зазвичай займає від кількох днів до кількох тижнів залежно від розміру та стану дисків.
До нас на стіл потрапив корпоративний NAS проектної фірми з Брно — двадцятидисковий масив RAID 6 ємністю 160 ТБ. Адміністратор зробив саме те, що в рамках плану відновлення зробив би майже кожен: замінив несправний диск і запустив rebuild. Проблема в тому, що план відновлення розрахований на ідеальний стан решти дисків. Реальні пластини після років експлуатації містять приховані пошкоджені сектори, які прокидаються саме під час екстремального навантаження при обчисленні нової парності. Результат? RAID-масив розпадається як картковий будиночок, і замість швидкого ремонту ви стикаєтеся з повною втратою корпоративних даних.
Ця стаття є путівником для розуміння логіки відмов дискових масивів, попередженням про фатальні помилки та описом методів відновлення. Якщо у вас конкретний пристрій, як-от Synology, QNAP або сервер з апаратним контролером, додатково діють специфічні особливості виробника — подробиці ви знайдете на сторінці Відновлення RAID та NAS.
Швидка орієнтація: ремонт RAID за симптомами
Слово «ремонт RAID» спокушає до того, щоб якнайшвидше знову запустити масив. Однак коли масив розпадається — повідомляє Degraded, переходить в offline або падає під час rebuild — метою є спочатку витягти дані з розпалого масиву, а вже потім вирішувати питання нового сховища. Залежно від симптомів дійте так:
- RAID повідомляє Degraded: не запускайте новий rebuild, не переконавшись, що всі інші диски читаються. Спочатку перевірте резервну копію, зупиніть записи та проконсультуйтеся щодо стану.
- Rebuild завис або припинився: вимкніть масив. Повторний rebuild зазвичай лише збільшує кількість пошкоджених секторів на решті дисків.
- RAID 5 перейшов у стан Offline після виходу другого диска: не намагайтеся «запустити» оригінальну конфігурацію. Для RAID 5 вирішальними є точний порядок дисків, розмір stripe та парність.
- RAID 6 впав при третій проблемі: залиште диски в тих самих слотах, позначте позиції та розв’язуйте проблему офлайн-реконструкції з клонів.
- RAID 0 після виходу диска з ладу: дані не є надлишковими, але якщо пошкоджений диск вдасться фізично прочитати або відремонтувати, структуру масиву можна скласти.
Це і є різниця між сервісним «ремонтом RAID» та лабораторним відновленням даних з RAID-масиву. Перший намагається знову запустити пристрій, другий захищає вміст, який залишився на дисках.
1. Міф під назвою «RAID = резервна копія»
Перш ніж занурюватися в технічні деталі, ми повинні розвінчати найнебезпечніший міф у цій галузі. RAID-масив (Redundant Array of Independent Disks) ніколи не розроблявся як резервна копія, а як інструмент для підвищення доступності та захисту від апаратного збою одного або кількох дисків.
Чому RAID не є резервною копією?
- Не захистить вас від видалення файлів через людську помилку.
- Не врятує вас від програм-вимагачів, які шифрують вміст логічного тому.
- Не допоможе при виході з ладу контролера, який запише на масив неправильні метадані.
- Не спрацює при випадковій реініціалізації або створенні нового масиву.
Якщо весь масив виходить з ладу через помилку прошивки, стрибок напруги в електроживленні або множинний вихід дисків з ладу, ви залишаєтеся без даних так само, як якщо б вони були на одному зовнішньому диску. Єдина справжня резервна копія — це фізично відокремлена копія даних, в ідеалі off-site або на іншому носії. Як тільки масив переходить у стан «offline», його відновлення потребує втручання фахівця, незалежно від того, який рівень RAID використовувався.
2. Рівні RAID та їх реальна стійкість під час збою
Різні рівні RAID вирішують проблему відмовостійкості по-різному. При відновленні даних з RAID критично важливо розуміти, що відбувається в масиві під час збою.
RAID 0 — striping без стійкості
Дані почергово записуються (stripe) на всі диски з метою досягнення максимальної продуктивності.
- Стійкість: відсутня. Вихід з ладу єдиного диска означає втрату всіх даних, оскільки файли розбиті на фрагменти по всіх дисках.
- Відновлення RAID 0: складне, але не неможливе. Ми повинні фізично відремонтувати пошкоджений диск (наприклад, заміною головок читання в чистому ламінарному боксі), клонувати його, а потім в офлайн-режимі скласти блоки даних з усіх дисків у правильному порядку. Відсутність парності спрощує математику, але відсутність надлишковості підвищує вимоги до бездоганного апаратного ремонту.
RAID 1 — дзеркалювання
Запис відбувається одночасно на обидва диски (або їхні пари). Вихід з ладу одного диска не обмежує функціональність. Ризик виникає при виході з ладу контролера або коли другий диск у дзеркалі також пошкоджений. Відновлення часто є лише питанням зчитування даних принаймні з одного працездатного носія.
RAID 5 — блокова парність
Завдяки розподіленій парності масив допускає вихід з ладу одного диска.
- Режим Degraded: при виході диска з ладу масив продовжує працювати, обчислюючи відсутні дані з парності. Це створює величезне навантаження на решту дисків.
- Збій відновлення: якщо в стані degraded відновлення зазнає невдачі (виявляється пошкоджений сектор на другому диску), весь масив переходить в offline. Проблема полягає в тому, щоб з’ясувати, де саме закінчується stripe і як обертається парність — тут і починається аналітична реконструкція в лабораторії.
RAID 6 — подвійна парність
Допускає вихід з ладу двох дисків одночасно. Це стандарт для великих корпоративних NAS.
- Сценарій з практики: навіть якщо масив переживає втрату двох дисків, катастрофа зазвичай трапляється під час операції rebuild, коли виходить з ладу третій диск (див. наш реальний випадок з 20-дисковим масивом нижче). Через дві площини парності складність офлайн-обчислень є величезною.
RAID 10 — дзеркальні stripe-и
Поєднує швидкість RAID 0 та надлишковість RAID 1. Може пережити вихід з ладу кількох дисків, якщо вони не знаходяться в одній дзеркальній парі. Якщо так, це руйнує весь stripe.
RAID 50/60
Коротко — поєднує striping з парністю. Складність відновлення тут помножується вкладеною структурою і вимагає поглибленого аналізу.
3. Типові сценарії збоїв, які ми бачимо щодня
У нашій лабораторії в Брно ми стикаємося з моделями поведінки, які призводять до катастрофи. Коли ви зрозумієте, що сталося, ви також зрозумієте, чому не можна просто «полагодити RAID» клацанням у BIOS.
(a) Вихід з ладу другого диска під час rebuild
Адміністратор замінює несправний диск. Щоб контролер обчислив дані для нового диска, він повинен прочитати кожен сектор усіх інших пластин. Старі диски, які роками працювали без помилок, раптово під жорстоким тиском виявляють слабкі місця і починають видавати помилкові сектори. Масив виходить з ладу повністю.
(b) Завислий rebuild
Rebuild не запускається або після десятків годин зависає на кількох відсотках і не продовжується. Контролер зіткнувся з поганим сектором і не знає, як його обійти. Продовжувати силою означає ризикувати знищенням механіки головок читання.
(c) Вихід з ладу контролера та пропрієтарний макет
Мертвий контролер порушує метадані. Новий контролер може розпізнати диски, але якщо він не знає оригінальний stripe offset та ротацію парності, він запропонує лише «Foreign configuration» та необхідність ініціалізації.
(d) Людська помилка
Хтось випадково від’єднує неправильний диск, переставляє позиції в шахтах і запускає масив. Або виконує реініціалізацію, побачивши повідомлення про помилку.
(e) Одночасний вихід з ладу кількох дисків
Вихід з ладу джерела живлення або backplane в NAS одночасно вбиває 3-4 диски. Після цього масив виглядає так, ніби логічний блок порожній або недоступний.
4. Чого не можна робити, якщо дані варті відновлення
Це найважливіша частина статті. Більшість остаточно втрачених даних зникли саме через панічні спроби відремонтувати RAID самотужки.
- Ніколи не повторюйте rebuild деградованого масиву. Якщо rebuild не вдався один раз, він не вдасться знову — і навантаження з кожною наступною спробою вбиває «здорові» диски. Саме цей сценарій обрушив 20-дисковий масив у вступному кейсі.
- Не переставляйте і не замінюйте диски методом проб і помилок. Для офлайн-масиву ви повинні знати точний порядок дисків. Випадкова перестановка в шахтах знищує шанс на логічну реконструкцію. Перед вийманням завжди позначайте позиції (Slot 1, Slot 2…).
- Не встановлюйте програмне забезпечення «RAID recovery» на живий масив. Ніколи не запускайте інструменти відновлення (типу R-Studio), якщо операційна система одночасно записує на масив. Кожен додатковий запис (логи, тимчасові файли) перезаписує залишки ваших оригінальних структур.
- Не залишайте масив працювати далі в стані degraded. Якщо один диск вийшов з ладу, не вимикайте сервер «аж завтра». Це гра в рулетку, чи переживе другий диск ще одну годину. Негайно припиніть запис і проконсультуйтеся з нами.
- Не використовуйте «Repair» або «Factory Reset». Не виконуйте оновлення прошивки (DSM/QTS) і не ініціалізуйте новий логічний том. Це знищить залишки опису файлової системи.
Якщо ви вже зробили щось із перерахованого вище, зупиніться. Ситуацію все ще можна вирішити, але необхідно негайно вимкнути масив.
5. Як професійна лабораторія вирішує проблему відновлення RAID-масиву
Наша робота полягає не у вгадуванні, а в технічній точності. Перш ніж перейти до логічного відновлення, ми повинні фізично захистити дані.
Клонування на рівні секторів
Ми ніколи не працюємо з оригінальними дисками. Кожен диск масиву — здоровий, пошкоджений або такий, що стукає — ми підключаємо до апаратних клонувальників (DeepSpar Disk Imager). Вони зчитують дані з нестабільних поверхонь надзвичайно делікатно, пропускають пошкоджені сектори і не мучать диски часовими обмеженнями операційної системи. Там, де звичайний комп’ютер зависає, DeepSpar отримує максимум даних.
Робота в чистому середовищі
Якщо механіка диска фізично вийшла з ладу (клацання, згоріла електроніка), ми виконуємо заміну головок читання в ламінарному боксі (clean room). Без цього мікроскопічна порошинка миттєво зруйнувала б пластину.
Офлайн-аналіз та розблокування пропрієтарних макетів
Після створення бітових копій (клонів) настає черга інтелектуального ядра всього відновлення:
- Визначення порядку дисків: фізичні слоти часто не відповідають порядку парності в контролері.
- Обчислення stripe size та offset: з’ясовуємо, де починається перший блок даних. Навіть зсув на один сектор означає абсолютно заплутану мішанину байтів.
- Ротація парності: у RAID 5/6 ми повинні виявити, в якому блоці знаходиться парність (left-symmetric, right-asymmetric тощо).
- Віртуальна реконструкція: використовуючи обладнання PC-3000 та власні скрипти, ми збираємо масив з бітових копій і будуємо віртуальний том, який перевіряємо на проміжному сховищі (120 ТБ SATA RAID 10).
Якщо у вас Synology, QNAP або сервер з апаратним контролером, додатково діють специфічні особливості — див. Відновлення даних з Synology NAS, QNAP NAS та відновлення даних з сервера.
6. Реальний крах 20-дискового RAID 6 — чому це сталося і з вами
Найкращою ілюстрацією є згаданий 20-дисковий RAID 6, який прибув до нас з проектної фірми в Брно.
Ситуація: корпоративний NAS, 20 дисків, 160 ТБ, RAID 6 (подвійна парність). У понеділок вийшов з ладу диск №7. Адміністратор замовив заміну і запустив rebuild на ніч. У вівторок вийшов з ладу другий диск №12 — масив перейшов у стан «degraded-critical», коли будь-яка інша проблема означає кінець. До такого масиву не можна було торкатися два дні, але rebuild продовжувався. Через 30 годин читання зіткнулося з пошкодженим сектором на, здавалося б, «здоровому» диску №5. Контролер оцінив це як вихід з ладу третього диска і перевів масив в offline. Звичайними засобами відновленню не підлягає.
Наше рішення: ми взяли всі 20 дисків. За допомогою DeepSpar ми клонували їх один за одним, вирішуючи проблему утрудненого повільного читання для диска №5. Офлайн-аналіз виявив пропрієтарний макет масиву (mdadm + LVM) — ми визначили фактичний порядок дисків, stripe offset та ротацію парності, і віртуальний масив із клонованих секторів вдалося зібрати. Це зайняло 11 днів, і замовник отримав назад 100% своїх файлів.
Якби адміністратор спробував rebuild знову, диск №5 помер би повністю, і відновлення даних з RAID перетворилося б на драматично дорожчу фізичну операцію.
7. Скільки це коштує і як довго триває
Вартість відновлення даних з RAID-масиву завжди залежить від конкретної ситуації. В ITHOPE ми діємо чесно: безкоштовна діагностика виявляє масштаб пошкодження. Ми досліджуємо, чи є проблема суто логічною (видалені метадані), чи необхідні фізичний ремонт та клонування. Ціну ми повідомляємо до початку робіт, а не після. Якщо дані врятувати неможливо (що у випадку зруйнованих метаданих без резервних копій трапляється в окремих випадках), ви не платите ні копійки.
Тривалість відновлення залежить від ємності та стану пластин — найповільнішою є робота з фізично пошкодженими механізмами. Загалом, чим з меншою кількістю спроб аматорського rebuild надходить масив, тим швидшим і дешевшим є відновлення.
Часті запитання
Чи можна спробувати rebuild ще раз?
Ні, ми настійно не рекомендуємо цього робити. Кожна спроба rebuild означає години інтенсивного читання всіх інших дисків. Якщо диски відмовляють, другий rebuild їх доконає — таким чином ви перетворюєте просте логічне відновлення на складне фізичне.
Чи витягне дані звичайне програмне забезпечення «RAID recovery»?
Якщо у вас працездатний масив із суто логічним пошкодженням, можливо, так. Але для пошкодженого (offline) масиву з неправильним offset, пошкодженою прошивкою диска або нечитабельними секторами звичайне програмне забезпечення не спрацює і часто, крім того, записує на диски тимчасові файли, що погіршує ситуацію.
Скільки часу займає відновлення даних з RAID у лабораторії?
Швидкі логічні реконструкції (здорові диски, відомі параметри) можна виконати за кілька днів. Складні випадки з фізичними дефектами, як-от 20-дисковий крах вище, вимагають від тижня до двох. Точну оцінку ви отримаєте після діагностики.
Чи можна врятувати RAID 0?
Так. Хоча RAID 0 не має парності і вихід з ладу будь-якого диска теоретично означає втрату всіх даних, ми можемо витягти дані завдяки фізичному ремонту пошкодженого диска (наприклад, заміна головок) та його точному клонуванню. Однак шанси зменшуються, якщо на здорові диски здійснювався запис, поки один був мертвий.
Скільки дисків має вийти з ладу, щоб це стало проблемою?
Для RAID 5 — один, для RAID 6 — два. На практиці ж для краху масиву часто достатньо комбінації одного мертвого диска та кількох пошкоджених секторів на іншому — тому деградований масив не можна продовжувати навантажувати.
Що робити зараз
- Припиніть запис і вимкніть масив. Жодних подальших rebuild, жодних «ще одна спроба». Кожна хвилина роботи деградованого масиву зменшує шанси.
- Не змінюйте порядок дисків. Якщо вам потрібно їх вийняти, спочатку позначте позиції маркером або стікером (Slot 1, Slot 2…).
- Не запускайте програмне забезпечення для відновлення на живому масиві та не ініціалізуйте новий том або «foreign config».
- Зверніться до лабораторії. Телефонуйте ЦІЛОДОБОВО за номером +420 775 556 063 або скористайтеся консультацією без зобов’язань. Ми домовимося про вивіз або безпечне транспортування до Брно.
- Розраховуйте на безкоштовну діагностику. Ми повідомимо масштаб пошкодження та вартість відновлення заздалегідь — ви платите лише за результат.
Резюме в пунктах
- RAID не є резервною копією — він не захищає від видалення, програм-вимагачів, виходу з ладу контролера або множинного виходу з ладу дисків.
- Найчастіша причина повної втрати — повторний rebuild деградованого масиву, який доконає старі «здорові» диски (каскадний збій).
- Кожен рівень RAID виходить з ладу по-різному — RAID 0 не має толерантності, RAID 5 — один диск, RAID 6 — два; відновлення завжди базується на порядку дисків, stripe offset та ротації парності.
- Відновлення = клонування кожного диска на рівні секторів + офлайн-реконструкція, ніколи не робота з оригіналами.
- Перед передачею масиву не торкайтеся rebuild, порядку дисків або нового тому — чим менше аматорських втручань, тим вищі шанси.
- Для конкретних пристроїв див. Synology, QNAP та сервер з HW контролером.
У вас деградований RAID-масив або масив, який перейшов в offline? Не намагайтеся виконати rebuild — кожна наступна спроба зменшує шанси. Консультація без зобов’язань · Безкоштовна діагностика · Контакт · +420 775 556 063 (ЦІЛОДОБОВО)
Див. також: Відновлення даних з Synology NAS · QNAP NAS · Відновлення даних з сервера · Відновлення RAID та NAS (послуга) · Кейс: 20-дисковий RAID 6 · Пошкоджені сектори HDD
Про автора
Ing. Miroslav Jaroš є власником і старшим техніком ITHOPE s.r.o. у Брно. Відновленням даних займається з 2008 року — за 18 років через лабораторію пройшло понад 2 500 замовлень, від окремих дисків до корпоративних RAID-масивів та NAS. Стаття пройшла фахову перевірку фактів (Tomáš Kopřiva) відповідно до реальної практики лабораторії ITHOPE. Описаний випадок 20-дискового RAID 6 заснований на реальному анонімізованому замовленні.