Пряма відповідь: Якщо RAID або NAS повідомляє degraded, critical, failed disk або незавершений rebuild, і дані важливі, не запускайте наступний rebuild наосліп. Зупиніть записи, задокументуйте порядок дисків, зробіть скріншоти повідомлень та безпечно вимкніть масив. Професійне відновлення починається не з перебудови масиву на оригінальних дисках, а з посекторного клонування кожного диска та офлайн-реконструкції з копій.
Один клік. 160 ТБ ємності. Чотири роки проєктів компанії. І рішення адміністратора, яке на перший погляд виглядало як рутина: замінити несправний диск і запустити rebuild.
Саме так до нас потрапив 20-дисковий масив RAID 6 з проєктної фірми у Брно. NAS зберігав CAD-документацію, історичні проєкти та частину операційних резервних копій. RAID 6 при цьому за принципом є двопаритетним масивом, тож мав би пережити вихід з ладу двох дисків. Але «мав би» не означає «безпечно робити rebuild старого масиву без перевірки».
Що означає degraded RAID
Стан degraded не означає, що дані втрачено. Це означає, що RAID втратив частину надлишковості та працює в аварійному режимі.
- RAID 1: один дзеркальний диск відсутній, дані є на другому.
- RAID 5: відсутній один диск, наступна помилка може означати втрату масиву.
- RAID 6: відсутні один або два диски, але при двох виходах з ладу вже немає запасу на наступну помилку.
- RAID 10: залежить від того, в якій дзеркальній парі вийшов з ладу диск.
Найбільша помилка – сприймати стан degraded як команду до негайного rebuild за будь-яку ціну. Для невеликого нового масиву зі свіжим бекапом це може бути розумно. Для NAS, який пропрацював чотири роки, з десятками терабайт і без перевіреного позамайданчикового бекапу – це авантюра.
Хронологія збою
У нашому випадку йшлося про корпоративний NAS з 20 дисками в RAID 6. Масив безперервно працював кілька років. Користувачі мали на ньому активні проєкти та архів.
Понеділок, ранок: вийшов з ладу диск номер 7. Масив перейшов у стан degraded, але дані були доступні. Адміністратор замовив диск на заміну та планував вечірню заміну.
Вівторок, ранок: ще до доставки диска на заміну повідомив про критичну помилку диск номер 12. RAID 6 все ще був теоретично читабельним, але вже з нульовою толерантністю до наступної помилки.
Вівторок, по обіді: диск на заміну надійшов, і було запущено rebuild. Контролер почав читати всю поверхню решти дисків, перераховувати парність і записувати нову копію відсутніх даних.
Через тридцять годин: rebuild зупинився на збійних секторах диска номер 5. Раніше він виглядав як справний. Однак інтенсивне читання під час rebuild виявило приховані помилки, які не були помітні у звичайному режимі роботи.
Середа, ранок: масив був офлайн, і стандартними засобами його не можна було підключити.
Це саме той момент, коли ще одна спроба rebuild, «force online», зміна порядку дисків або ініціалізація нового масиву може знищити навіть те, що ще можна відновити.
Чому rebuild вбиває старий масив
Rebuild – це не відновлення даних. Rebuild – це масштабне стрес-тестування всіх дисків, що залишилися.
При звичайній роботі NAS читає лише активні файли та метадані. Під час rebuild контролер повинен пройти значну частину поверхні всіх дисків, часто безперервно протягом годин або й днів. Саме тоді на старих дисках проявляються:
- приховані збійні сектори,
- тайм-аути при читанні,
- слабкі головки,
- погіршені показники SMART,
- проблеми з живленням або охолодженням відсіку,
- невідповідність парності після попередніх збоїв.
Чим більші диски, тим довший rebuild і тим більше вікно ризику. Для RAID 5 проблема ще гостріша, оскільки одна додаткова помилка під час rebuild може означати кінець. RAID 6 має більший запас, але не нескінченний. Якщо два диски вже вийшли з ладу, а третій починає видавати помилки, двопаритетного захисту вже недостатньо.
Що мало передувати rebuild
Безпечний алгоритм для важливого degraded RAID виглядає інакше:
- Зупинити записи. В ідеалі – відключити спільні папки, вимкнути служби, зупинити віртуалізацію та бази даних.
- Записати стан. Скріншоти адміністрування NAS, логи, порядок дисків, серійні номери, слоти, тип RAID, розмір страйпу, тип файлової системи.
- Перевірити SMART усіх дисків. Не лише того, який NAS позначив як несправний.
- Перевірити бекап. Не «десь має бути», а реально відкрити останній backup і перевірити дані.
- Для критичних даних – клонувати перед rebuild. Кожен оригінальний диск посекторно зчитати на інший носій. Rebuild виконувати лише з копій або після чіткої оцінки ризику.
Якщо ви не впевнені, найбезпечніший крок – нічого більше не перезаписувати. Це стосується Synology, QNAP, TrueNAS, linux mdadm, ZFS, а також апаратних контролерів Dell/HP/LSI.
Як ми діяли в лабораторії
Після отримання ми спершу позначили диски відповідно до оригінальних позицій. При відновленні RAID порядок є визначальним. Диски не перемішуються, не запускається автоматична ініціалізація, і не приймається пропозиція «repair» в адмініструванні.
Першою фазою було посекторне клонування всіх дисків. Несправні диски читаються за іншою стратегією, ніж справні: спочатку стабільні області, потім гірші місця, за потреби – читання у зворотному напрямку та повторні спроби над слабкими секторами. Мета – не отримати гарний звіт SMART. Мета – отримати якомога більше читабельних секторів, перш ніж диск погіршиться.
Другою фазою був офлайн-аналіз. Для великих масивів недостатньо знати, що «це був RAID 6». Нам потрібна точна геометрія:
- порядок дисків,
- розмір страйпу,
- обертання парності,
- початковий зсув,
- можливі метадані виробника NAS,
- стан файлової системи над масивом.
Лише після цього збирається віртуальний масив із клонів. На цьому етапі ми вже не хочемо навантажувати оригінали. Якщо реконструкція не вдасться з першого разу, параметри змінюються на копіях, а не на дисках клієнта.
У цьому випадку вдалося відновити 100 % даних клієнта. Клієнт перевіряв випадково вибрані CAD-проєкти за кілька років, контрольні файли та архівні папки. Поточні проєкти пріоритету A ми витягли раніше, ніж решту масиву, щоб компанія могла продовжувати роботу, поки тривала повна реконструкція.
Детальніший технічний кейс доступний на сторінці відновлення з 20-дискового RAID 6 в NAS.
Що робити, якщо RAID щойно повідомив про помилку
Якщо ви читаєте цю статтю в момент, коли NAS пищить, або адміністрування світиться червоним:
- Не запускайте rebuild повторно. Одного невдалого rebuild достатньо як попередження.
- Не створюйте новий масив на тих самих дисках. Ініціалізація може перезаписати метадані.
- Не змінюйте порядок дисків. Сфотографуйте відсіки, запишіть слоти та серійні номери.
- Залиште масив без запису. Кожен новий файл ускладнює стан файлової системи.
- Не комбінуйте поради з форумів. mdadm, ZFS, Synology SHR, QNAP LVM та апаратний RAID мають різні структури метаданих.
- Якщо існує бекап, перевірте його. Відкрити файли краще, ніж просто бачити, що завдання бекапу «завершилося».
Якщо йдеться про дані, втрату яких ви не можете собі дозволити, зупиніться перед дією, яка записує на диски. Відновлення даних є найуспішнішим у момент, коли оригінальний стан ще не був перезаписаний.
RAID – це не бекап
RAID забезпечує доступність. Бекап забезпечує повернення до даних після катастрофи.
RAID може вас виручити, коли виходить з ладу один диск, а вам потрібно продовжувати роботу. Він не захистить вас від видалення папки, програм-вимагачів, помилки адміністратора, несправного контролера, пожежі, затоплення або збою rebuild. Тому для корпоративних даних має сенс комбінація:
- RAID/NAS для операційної доступності,
- регулярний scrub або patrol read,
- моніторинг SMART і температур,
- офлайн або позамайданчиковий backup,
- тест відновлення принаймні для критичних папок.
Якщо у вас NAS – єдине місце, де існують дані, це не бекап. Це єдина копія в дорожчій коробці.
Швидкий FAQ
У мене Synology/QNAP у стані degraded. Чи вставляти новий диск?
Спочатку перевірте стан усіх дисків і бекап. Якщо дані важливі, а масив старий, безпечніше проконсультуватися щодо подальших дій перед rebuild. Вставлення диска часто автоматично запускає процес, який уже нелегко скасувати.
Rebuild уже виконується. Чи зупиняти його?
Залежить від стану. Якщо він виконується без помилок і у вас є перевірений бекап, він може завершитися. Якщо з’являються помилки читання, тайм-аути, ще один диск зі статусом failed або незвичні звуки, подальше навантаження може зашкодити. У такій ситуації краще зупинити записи, задокументувати стан і вирішувати питання з клонуванням.
Чи допоможе ddrescue вдома?
Для одного диска ddrescue може бути корисним інструментом, якщо ви знаєте, що робите, і читаєте на інший носій. Але для RAID недостатньо клонувати «щось». Вам потрібні правильний порядок дисків, зсув, парність і файлова система. Неправильні дії можуть перезаписати метадані або погіршити стан дисків.
Скільки коштує відновлення даних з RAID?
Залежить від кількості дисків, ємності, типу RAID, стану носіїв і обсягу необхідної ручної реконструкції. Діагностика RAID/NAS у нас безкоштовна, і перед самим відновленням ви отримаєте оцінку. Почати має сенс через запит на відновлення даних з RAID або контакт.
Якщо у вас degraded RAID, невдалий rebuild або NAS офлайн, не робіть подальших спроб ремонту наосліп. Телефонуйте +420 775 556 063, пишіть на zachranadat@ithope.cz або надсилайте опис через контакт. Лабораторія знаходиться у Брно-Жіденіце, випадки з RAID/NAS вирішуємо з усієї Чехії.