Порятунок даних із сервера — відновлення RAID, HP ProLiant, Dell PowerEdge

Відповідь одразу: Якщо ваш сервер HP ProLiant, Dell PowerEdge або інша машина з апаратним RAID-контролером перейшла в стан «Degraded» або «Offline», негайно вимкніть його. Не намагайтеся наосліп імпортувати «Foreign config» після заміни контролера, не запускайте rebuild деградованого масиву й у жодному разі не ініціалізуйте новий віртуальний диск. Кожна спроба запису або відновлення конфігурації суттєво знижує шанс на порятунок даних, оскільки пропрієтарні метадані контролерів, як-от HP Smart Array чи Dell PERC, перезаписуються за мілісекунди. Шанс на порятунок за умови негайного вимкнення сервера та правильного підходу в лабораторії є високим, навіть якщо масив повідомляє «Failed» або коли виходить з ладу сам контролер. Діагностика у нас завжди безкоштовна, а ціну ми повідомляємо заздалегідь, тож ви нічим не ризикуєте.

У серверному RAID підступність полягає в тому, що адміністрування часто пропонує простий вибір: імпортувати конфігурацію, запустити rebuild, створити новий віртуальний диск. Але в момент, коли масив уже повідомляє Degraded, Offline або Foreign Config, немає впевненості, чи контролер усе ще правильно зчитує оригінальну карту. Те, що виглядає як рутинне обслуговування, після одного підтвердження може перетворитися на перезаписані метадані та втрачений VMFS datastore.

Швидка орієнтація за повідомленням на сервері

Коли сервер повідомляє Foreign Config, Virtual Drive Offline або недоступний VMware datastore, справа не лише в дисках. Одночасно вирішуються питання з контролером, порядком відсіків, метаданими RAID і файловою системою віртуалізації.

• Foreign Configuration: не імпортувати й не очищати без аналізу. Спочатку позначити диски та з’ясувати, чому конфігурація визначається як чужа.
• Virtual Drive Offline / Failed: вимкнути сервер. Повторні перезавантаження можуть запустити ініціалізацію або подальші записи в метадані.
• Unconfigured Good після заміни контролера: не означає, що диски порожні. Це означає, що новий контролер не бачить оригінальну конфігурацію.
• Rebuild failed у RAID 5/6: наступна спроба, як правило, знову навантажує ті самі диски. Без секторних клонів це ризик.
• VMware VMFS datastore inaccessible: не натискати Format, Resignature і не створювати новий datastore. Це призводить до втрати структури віртуальних машин.

Безпечний підхід однаковий для HP Smart Array, Dell PERC та LSI MegaRAID: зберегти фізичний порядок дисків, від’єднати масив від записів, клонувати кожен диск окремо й лише потім із копій перевірити, як було складено масив.

1. Чому апаратний RAID на сервері — це інша ліга

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

Пропрієтарні метадані та пастка під назвою «Foreign Config»

Контролери, як-от HP Smart Array (серії Pxxx), Dell PERC (H710, H730, H740), Broadcom/LSI MegaRAID або Adaptec/Microsemi, створюють на дисках власні конфігураційні сектори, що містять інформацію про рівень RAID, stripe size, порядок дисків і позицію в межах масиву. Ці метадані не є переносними між виробниками, а часто навіть між різними поколіннями контролерів однієї компанії. Якщо контролер після запуску не бачить очікуваної конфігурації, він повідомляє «Foreign Configuration». Подальший вибір «Import Foreign» або «Clear» без глибокого розуміння ситуації виконує запис на диски й може перезаписати останню відому коректну карту масиву.

Віртуалізація поверх RAID: невидимий додатковий рівень

Enterprise-сервери, як правило, не зберігають файли безпосередньо. На апаратному томі RAID розгорнуто гіпервізор — найчастіше VMware ESXi з datastore VMFS або Microsoft Hyper-V з форматом VHDX. Коли масив виходить з ладу, ви втрачаєте не просто файлову систему, а цілий контейнер із віртуальними серверами. Лабораторна реконструкція, таким чином, не повинна закінчуватися на складанні блоків, а має йти глибше: знайти й відновити структуру VMFS, перевірити його таблиці та витягти віртуальні диски. Це ключовий контекст, який відрізняє сервер від простого зовнішнього боксу.

2. Типові сценарії виходу з ладу серверного масиву

Апаратний RAID на сервері є надійним, але його відмови зазвичай мають специфічний перебіг, який часто завершується фатальним станом offline.

Деградований RAID 5 і каскадна відмова

Найпоширеніший сценарій. RAID 5 витримує втрату одного диска. Адміністратор помічає блимання помаранчевого індикатора, замовляє новий диск і запускає заміну. Проблема в тому, що всі інші диски в масиві, як правило, того самого віку, з тієї самої виробничої партії та мають однакову кількість мотогодин. Повний rebuild, який триває десятки годин, є екстремальним навантаженням. Якщо на іншому диску з’явиться бодай один пошкоджений сектор, на якому rebuild зупиниться, масив переходить із Degraded одразу в Failed. У RAID 6 ситуація з двома дисками парності краща, але й тут діє нульова толерантність під час rebuild — див. реальний кейс із 20 дисками нижче.

Вихід з ладу контролера та «Foreign Config»

Апаратний контролер не вічний. Він може вийти з ладу через перенапругу, коротке замикання на backplane або просто після років експлуатації. Якщо ви візьмете диски та перемкнете їх в інший сервер (або інший слот), контролер повідомить про чужу конфігурацію. Імпортувати наосліп без знання оригінального stripe offset, вирівнювання та версії прошивки означає ризик того, що контролер запише нові метадані неправильно — особливо якщо між поколіннями контролерів змінилася геометрія розподілу даних. Просте перекидання дисків з одного сервера в інший може закінчитися затиранням карти масиву.

Пошкоджений VMFS datastore і збій розширювача

Особливо підступними є збої живлення або короткочасні несправності SAS-розширювача (backplane). Backplane може на мілісекунду від’єднати кілька дисків одночасно. Апаратний контролер миттєво оцінює їх як мертві та позначає як «Failed». При цьому жодної фізичної несправності не сталося, але масив зруйновано. Так само невдале втручання в ESXi (наприклад, створення нового розділу там, де був datastore) перетворює VMFS на нечитабельний набір метаданих.

3. Що НЕ МОЖНА робити із серверним RAID-контролером

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

• Не імпортуйте «Foreign Configuration» бездумно. Доки ви не знаєте, чому конфігурація визначається як чужа, Import є бомбою сповільненої дії. Особливо якщо було замінено контролер або переставлено диски.
• Не ініціалізуйте новий віртуальний диск. Якщо сервер не реагує на старий VD, ніколи не вибирайте «New Volume / New Logical Drive» на тих самих фізичних дисках. Цей крок перезаписує заголовок масиву й гарантовано знищує карту розділів.
• Не запускайте rebuild, якщо бачите два або більше пошкоджених дисків. Як тільки ви в RAID 5 опинилися в стані, де проблем більше, це не обслуговування, а порятунок. Кожна секунда навантаження читанням під час rebuild вбиває інші диски (див. каскадну відмову).
• Не переставляйте диски між позиціями методом спроб і помилок. Апаратний контролер ідентифікує слоти. Якщо ви не позначите їх перед витяганням, ми втрачаємо час і підвищуємо ризик.
• Не оновлюйте прошивку контролера чи гіпервізора на зруйнованому масиві. Спроба полагодити неробочий масив перепрошивкою новішої версії Smart Array / PERC firmware може змінити спосіб читання метаданих.
• У ESXi не створюйте новий datastore. Коли vCenter повідомляє «Inaccessible», не натискайте «Format» або «Resignature». Передайте це нам.

4. Як лабораторія вирішує проблему порятунку серверного масиву

Секрет у тому, щоб перестати покладатися на логіку контролера й почати працювати з необробленими даними.

1. Секторне клонування. Кожен окремий диск (SAS і SATA) ми переміщуємо на спеціалізовані станції клонування (PC-3000, DeepSpar Disk Imager). Мета — сектор за сектором зчитати всі читабельні дані до того, як диски розсиплються. Пошкоджені сектори ми обробляємо апаратно, а не програмним тайм-аутом контролера. Диски з пошкодженими головками потрапляють до ламінарного боксу.
2. Офлайн-аналіз пропрієтарного layout. З клонів ми витягуємо бінарні метадані. Тут HP Smart Array відрізняється від Dell PERC. Ми шукаємо параметри: stripe size, ротацію парності (left/right, синхронна/асинхронна) і, головне, реальний порядок дисків та offset початку даних (деякі контролери залишають перед даними резерв). Ми нічого не припускаємо — все підтверджуємо за структурою файлової системи.
3. Віртуальна реконструкція масиву. На нашому обчислювальному сховищі (staging 120 ТБ SATA RAID 10) ми складаємо клони у віртуальний блоковий пристрій. Ми не використовуємо оригінальний серверний контролер. Якщо на масиві працює VMware, настає ключова фаза: реконструкція таблиць VMFS — superblock, вказівники розподілу, прив’язка VMDK і VHDX.
4. Екстракція на staging. Отримані дані (часто десятки ТБ) ми витягуємо на перевірену файлову систему. Якщо замовнику потрібна лише конкретна віртуальна машина, ми витягаємо тільки її файл VMDK.

5. Реальний кейс: enterprise-реконструкція 20-дискового RAID 6

Точно в дусі описаних вище ризиків відбувався порятунок для проєктної фірми в Брно. Йшлося про 160ТБ-масив із 20 дисками в RAID 6, але ситуація повністю застосовна до будь-якого великого сервера з апаратним RAID.

У понеділок вийшов з ладу диск #7. Адміністратор замовив заміну й запустив важкий rebuild. У вівторок вийшов з ладу диск #12 — масив перейшов у критичний стан, але все ще працював (дві парності мали це витримати). Однак через 30 годин rebuild зупинився на пошкодженому секторі «здорового» диска #5. Помилковий сектор виник саме через брутальне навантаження під час rebuild, і враз масив мав три проблемні місця — реконструкція парності не вдалася, масив перейшов в offline. Рішення вимагало клонування всіх 20 дисків, офлайн-пошуку пропрієтарного stripe offset та порядку, а також екстракції даних на наш staging. Це тривало 11 днів, результат — 100 % усіх даних. Деталі: 20-дисковий RAID 6.

Часті запитання

Контролер мертвий, я втрачу весь масив?

Ні. Якщо мертвий лише контролер (а диски механічно в порядку), дані на пластинах залишаються. Ми вирішуємо це так: клонуємо диски та складаємо масив програмно за пропрієтарними метаданими, які залишилися на дисках. Нам не обов’язково потрібен ідентичний контролер на заміну, що є ключовим, оскільки старі моделі HP чи Dell вже не дістати. Загальне правило: що швидше ви це вимкнете, то краще. Більше про правила для RAID див. Порятунок RAID і NAS.

Після заміни контролера сервер повідомляє «Foreign Config». Що тепер?

Вимкнути, позначити позиції дисків і взагалі нічого не робити в BIOS контролера. Коли ви надішлете масив до нас, ми з клонів дисків офлайн зчитаємо стару конфігурацію та перевіримо її за структурою файлової системи. Вибір «Import Foreign» — це ризик, оскільки ви не знаєте, чи має новий контролер таке саме вирівнювання та логіку читання, як старий.

Чи можу я диски з HP ProLiant під’єднати до іншого сервера та імпортувати масив?

Наполегливо не рекомендуємо. У лабораторії ми це робимо, але виключно для читання на обладнанні, яке не виконує запис на диски. Інший сервер під час завантаження може почати синхронізацію або одразу перевести диски в стан «Unconfigured Good» і тим самим стерти метадані RAID.

На ньому працює VMware ESXi — чи можна врятувати лише одну віртуальну машину?

Так. Як тільки ми віртуально реконструюємо весь VMFS datastore, ми можемо селективно витягти лише вибрані віртуальні диски (VMDK). Не обов’язково рятувати datastore як ціле, що особливо зручно за обмеженої місткості з вашого боку.

RAID 5 на Dell і один диск вийшов з ладу — чи потрібно негайно вирішувати питання порятунку?

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

Скільки часу займає порятунок серверного масиву?

Точний час залежить від місткості та ступеня пошкодження. Стандартний масив із 4–8 дисків ми вирішуємо впродовж кількох робочих днів. Масштабна реконструкція десятків терабайт (див. 20-дисковий RAID 6) може потребувати від двох до трьох тижнів. Точну оцінку ви отримаєте після діагностики.

Що робити зараз

1. Негайно вимкніть сервер. Якщо він не стартує, від’єднайте живлення. Не продовжуйте перезавантаження й не намагайтеся відновити вбудованими інструментами.
2. Фізично позначте диски. Перед маніпуляціями запишіть їхні позиції (слот 1, слот 2…). Для серверів HP і Dell із hot-swap відсіками порядок є критичним. Сфотографуйте також заднє під’єднання, якщо воно відкрите.
3. Не допускайте до цього звичайного IT-фахівця без досвіду лабораторного порятунку. Стандартний IT-технік, як правило, не має інструкції не втручатися в масив і не імпортувати конфігурацію наосліп.
4. Зв’яжіться з нашою лабораторією. Телефонуйте ЦІЛОДОБОВО за номером +420 775 556 063 або скористайтеся нашою безкоштовною консультацією. Ми домовимося про виїзд або безпечне транспортування дисків до Брно.
5. Розраховуйте на безкоштовну діагностику. У лабораторії ми оцінимо диски, перевіримо, чи не було на них запису, й повідомимо точну ціну за повне відновлення. Ви платите лише після успішно виконаної роботи, після перегляду списку врятованих файлів.

Підсумок

• Апаратні контролери (HP, Dell, LSI) використовують пропрієтарні метадані; заміна контролера «один на один» часто не вдається й закінчується втратою конфігурації.
• Каскадна відмова під час rebuild є основною причиною фатального виходу з ладу для старих дисків у RAID 5/6 — масив не можна далі навантажувати.
• При повідомленні «Foreign Config» будь-який імпорт без офлайн-аналізу є ризиком перезапису карти масиву.
• Віртуалізація додає додатковий рівень: після складання блоків лабораторія повинна відновити структури VMFS/NTFS та випрепарувати віртуальні диски (VMDK/VHDX).
• Netgear ReadyNAS (X-RAID) і великі enterprise-бокси вимагають однакового підходу — клон диска, розшифрування парності та офлайн-реконструкція.
• Лабораторія ITHOPE працює зі станціями клонування SAS і SATA, в чистому середовищі та зі staging 120 ТБ — і головне, офлайн, без жодного запису на оригінальні диски.

Ваш сервер перейшов у стан Degraded або Offline? Не запускайте rebuild і не імпортуйте чужу конфігурацію — кожна спроба зменшує шанси. Безкоштовна консультація · Діагностика безкоштовно · Контакт · +420 775 556 063 (ЦІЛОДОБОВО)

Див. також: Порятунок даних з RAID-масиву · Synology NAS · QNAP NAS · Порятунок RAID і NAS (послуга) · Case study: 20-дисковий RAID 6

Про автора

Ing. Miroslav Jaroš є власником і старшим техніком ITHOPE s.r