Ви замінили диск 4 ТБ у масиві Synology SHR на диск 8 ТБ. Перебудова почалася, тривала деякий час — а потім зупинилася. У DSM відображається стан Degraded або Crashed, або індикатор прогресу не рухається вже годинами. NAS може повністю перестати відповідати. У цій статті розглядається відновлення даних після збою перебудови SHR: що насправді сталося всередині масиву, як прочитати поточний стан без ризику погіршити ситуацію та як повернути ваші файли.
Перш ніж робити будь-які дії
Коли процес відновлення (rebuild) зависає, здається логічним виконати три дії — проте всі вони можуть перетворити відновлювану ситуацію на незворотну:
Перезавантаження NAS
Масив у режимі degraded зберігає стан своїх учасників в оперативній пам’яті. Перезавантаження змушує mdadm перечитати суперблоки з дисків — якщо ці суперблоки виявляться розсинхронізованими через перерване відновлення, масив після перезавантаження може взагалі не зібратися.
Виймання дисків
Навіть диск, який DSM позначає як «Faulty», може бути читабельним. Видалення учасника змінює кількість елементів у масиві та змушує mdadm оновити суперблоки на решті дисків, фіксуючи видалення як постійну подію. Це може назавжди вивести з масиву диск, який насправді був доступний для читання.
Натискання «Repair» у Storage Manager
Команда «Repair» запускає нову спробу відновлення (rebuild). Якщо початкове відновлення не вдалося через помилки читання на існуючому диску, друга спроба знову читає ті самі сектори — це посилює пошкодження на вже навантаженому диску та підвищує ризик повторної відмови.
Примусове вимкнення живлення
Раптове відключення живлення під час активної (навіть «замороженої») відбудови може записати часткові блоки парності на новий диск, внаслідок чого масив опиниться в стані, коли ні старі, ні нові дані не є послідовними. Якщо інтерфейс досі доступний, завжди використовуйте процедуру завершення роботи DSM.
Запуск fsck або btrfs check
Інструменти відновлення файлової системи працюють на рівні томів — на один рівень вище від масиву. Запуск їх на деградованому масиві означає, що вони читають реконструйовані дані, які можуть містити помилки парності, і можуть записати пошкоджені метадані назад на диск.
Додавання ще одного диска
Вставлення запасного диска в масив зі статусом «Crashed» призводить до того, що DSM намагається виконати автоматичне відновлення (rebuild). Не з’ясувавши причини невдачі першого відновлення, повторна спроба потрапляє в ту саму проблему — і до того ж спричиняє ще один раунд повних зчитувань усього масиву на вже перевантаженому обладнанні.
Чому відновлення не вдалося
Коли SHR замінює диск іншого обсягу, воно виконує значно більше, ніж просто копіювання даних. Послідовність виглядає так:
mdadm зчитує всі розділи з даними з решти дисків при постійній послідовній пропускній здатності — це може тривати години або дні на масивах розміром у кілька терабайт.
Паритет обчислюється і записується на новий диск. Для SHR зі змішаними розмірами дисків mdadm використовує кілька md-пристроїв різного розміру, складених разом, тому обчислення паритету складніше, ніж у RAID 5 з фіксованою геометрією.
LVM перераховує розподіл фізичних екстентів по розширеному пулу сховища. Якщо новий диск має більшу ємність, це означає перепризначення макета групи томів (Volume Group) — окрема операція, яка виконується паралельно з або після mdadm rebuild.
Будь-яка помилка на будь-якому етапі припиняє цю послідовність. Три основні причини пояснюють більшість відмов при відновленні SHR:
Незворотні помилки читання (URE)
Споживчі накопичувачі мають ймовірність URE приблизно 1 на 1014 біт, що зчитуються. На диску ємністю 4 ТБ це означає, що при повному послідовному проході статистично ймовірна помилка читання десь на диску. Під час звичайної експлуатації ці сектори рідко зачіпаються. Під час відновлення (rebuild) зчитується кожен сектор — і один незчитуваний сектор припиняє обчислення паритету для всього стріпу. Диску не обов’язково має статися відмова; достатньо, щоб він видав одну помилку читання у невдалий момент.
Таймаути SATA під навантаженням
Кабельне або бекплейн-з’єднання, яке при звичайних навантаженнях працює на межі, може відмовляти під час тривалих високопропускних зчитувань під час відновлення. Ядро реєструє помилку SATA, mdadm трактує диск як недоступний і позначає його як Faulty — навіть якщо сам диск фізично справний. Диск повертається після повторного підключення, але mdadm уже вилучив його з масиву.
Фонові завдання DSM
Synology автоматично планує тести S.M.A.R.T., індексацію медіатеки (для Photo Station, Video Station) та операції scrub файлової системи Btrfs. Будь-яка з цих процедур, що виконується одночасно з відновленням (rebuild), конкурує за ту саму пропускну здатність дискового вводу/виводу. На системі, яка вже виконує тривале повне читання диска, додаткові операції вводу/виводу можуть збільшити затримку читання настільки, що це спричинить таймаути дисків — з тим самим результатом, що й фізична проблема з підключенням.
Для ширшого порівняння ризиків відновлення (rebuild) і прямого відновлення даних див. нашу статтю на Відновлення RAID (rebuild) проти програмного відновлення.
Перевірте поточний стан масиву
Перед будь-якою спробою відновлення точно визначте, що саме повідомляє mdadm. Якщо є доступ по SSH, два наведені нижче команди дадуть повну картину. Для повного покрокового розбору тлумачення виводу mdadm див. наш mdadm RAID recovery guide. Нижче — конкретні шаблони, на які слід звернути увагу в цій ситуації.
cat /proc/mdstat — показує статус складання і, якщо відбувається відновлення, поточний прогрес та швидкість.
Зависле відновлення виглядає так:
Personalities : [raid5] [raid6] [raid1] md3 : active raid5 sdb3[0] sdc3[1] sdd3[2] 5860468736 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/2] [UU_] [================>....] recovery = 83.2% (2436352/2930234) finish=∞ speed=0K/sec unused devices: <none>
finish=∞ і speed=0K/sec підтверджують, що відновлення застрягло — mdadm чекає сектор, який не може прочитати.
Зашифрований (crashed) масив виглядає так:
Personalities : [raid5] [raid6] [raid1] md3 : inactive sdb3[0](S) sdc3[1](S) 5860468736 blocks super 1.2 unused devices: <none>
inactive з позначками (S) (spare) означає, що mdadm не має активного масиву — пристрої присутні, але масив не зібрано. Дані фізично на дисках, але недоступні.
Таблиця нижче зіставляє статуси DSM з тим, що насправді відбувається, і які кроки виконувати далі:
| Що показує DSM | Що це означає | Чого не робити | Наступний крок |
|---|---|---|---|
| Відновлення зависло, speed = 0 Пошкоджено | Помилка неперевіреного читання (URE) на існуючому диску блокує запис паритету. Масив деградований, але цілий. | Не чекати; не перезапускати відновлення | RS RAID Retrieve |
| Один диск позначено як Faulty, відновлення зупинилося Пошкоджено | mdadm відключив диск після повторних помилок читання або SATA-помилок. Працює без резервування. | Не видаляти диск, позначений як Faulty | S.M.A.R.T. перевірка, потім RS RAID Retrieve |
| Сховище: Crashed Зламано | mdadm не може підтримати кворум. Масив неактивний — дані на дисках, але недоступні. | Не натискати Repair; не перезавантажувати | RS RAID Retrieve |
| NAS не відповідає, DSM не завантажується Невідомо | Можливе зависання ядра під час I/O відновлення. Стан масиву невідомий. | Не вимикати живлення примусово, якщо це можна уникнути | Акуратне відключення через утримання кнопки живлення, потім RS RAID Retrieve |
Відновлення даних за допомогою RS RAID Retrieve
RS RAID Retrieve відтворює конфігурацію масиву SHR із суперблоків mdadm на наявних дисках, працює з деградованими масивами, в яких один учасник відсутній або позначений як Faulty, та надає доступ тільки для читання до тому для вибіркового відновлення файлів — без ініціювання повторної спроби відновлення.
Крок 1 — Підключіть диски та перевірте S.M.A.R.T.
Якщо можливо, коректно вимкніть NAS. Підключіть усі диски — включно з тим, який DSM позначив як “Faulty” — до машини для відновлення й відкрийте вбудований S.M.A.R.T.-монітор у RS RAID Retrieve. Перевіряйте кожен диск, а не тільки той, що відмовив. Під час відновлення масиву диск, який здається здоровим, часто виявляється причиною проблем через помилки читання на наявному члені масиву.
Крок 2 — Зробіть образ будь-якого диска з підвищеними значеннями S.M.A.R.T.
Якщо будь-який диск показує ненульові значення Reallocated Sector Count (кількість перемаркірованих секторів), Pending Sectors (сектора в очікуванні) або Uncorrectable Errors (невиправні помилки), перед скануванням створіть секторний образ цього диска за допомогою вбудованої функції створення образів RS RAID Retrieve. Усі подальші роботи з відновлення виконуються над образом. Це захищає вихідний диск від додаткових операцій читання під час сканування та запобігає подальшому погіршенню стану вже навантаженого диска.
Крок 3 — Автоматичне відновлення масиву
RS RAID Retrieve читає суперконтролер (superblock) mdadm з кожного підключеного диска або образу, визначає UUID масиву, ролі учасників, рівень RAID та параметри стріпінгу і відновлює структуру тома SHR. Для деградованого масиву з одним відсутнім або пошкодженим учасником програма може виконати реконструкцію за допомогою наявних дисків — обчислюючи відсутні дані з паритету так само, як це робить mdadm у деградованому режимі, але без запису будь-яких даних назад на диск.
Крок 4 — Перегляд та відновлення файлів
Якщо можливо, коректно вимкніть NAS. Підключіть усі накопичувачі — включно з тим, який DSM позначив як Faulty — до комп’ютера для відновлення та відкрийте вбудований монітор S.M.A.R.T. у RS RAID Retrieve. Перевіряйте кожен диск, а не лише той, що вийшов з ладу. Під час відновлення (rebuild) диск, який здається здоровим, часто є тим, що спричинив помилку через проблеми читання на існуючому члені масиву.
Працює з деградованими та аварійними масивами
Відновлює томи SHR із наявних учасників (дисків) без потреби в повному здоровому масиві — включно з неактивними масивами, які mdadm відмовляється збирати.
Моніторинг S.M.A.R.T.
Оцініть стан диска перед скануванням. Визначає, який диск спричинив збій процесу відновлення (rebuild), і чи потрібно створити образ диска перед відновленням.
Створення образу диска
Створіть секторний образ пошкодженого диска перед відновленням. Усі роботи виконуються з цим образом — це захищає оригінал від додаткових циклів читання.
Підключення по SSH
Якщо NAS усе ще увімкнено та доступне в мережі, RS RAID Retrieve може підключитися через SSH — без необхідності фізично виймати диски з шасі.
Коли програмного відновлення замало
Якщо кілька дисків не з’являються після підключення до машини відновлення, або якщо S.M.A.R.T. показує критичні показники для більш ніж одного учасника масиву, ситуація вийшла за межі можливостей програмного забезпечення. Масив SHR‑1 із двома несправними дисками не має парності для реконструкції — немає математичного шляху відновити відсутні дані тільки за допомогою програмних засобів.
Зупиніться та зв’яжіться з лабораторією відновлення, якщо ви помітили
- Два або більше дисків не визначаються або одразу показують помилку S.M.A.R.T. при подачі живлення
- Клацання, скрегіт або повторні невдалі спроби розкрутити шпиндель на будь-якому диску
- RS RAID Retrieve не може відтворити масив навіть у ручному режимі
- Диски стають гарячими на дотик вже за кілька хвилин після підключення
Фізичне відновлення — заміна головок, перенос пластин — потребує чистої кімнати (cleanroom). Кожний додатковий цикл увімкнення живлення на механічно несправному диску зменшує ймовірність успішного відновлення.
Після відновлення: запобігання наступному збою під час перебудови
Збій перебудови під час заміни диска не є випадковим. Він експлуатує конкретну вразливість: усі інші диски перебувають під максимальною постійною навантаженістю на читання у той самий момент, коли масив позбавлений резервування. Нижче наведені кроки зменшують ймовірність повторення цієї ситуації.
Перевірте S.M.A.R.T. перед заміною диска
Перед тим як витягувати старий диск, запустіть повний розширений тест S.M.A.R.T. на всіх інших дисках. Диск із переназначеними секторами або з секторами у стані очікування (pending) найімовірніше спричинить URE під час подальшого відновлення масиву.
Вимкніть фонові завдання DSM під час перебудови
Перейдіть у Панель керування → Планувальник завдань і тимчасово призупиніть заплановані тести S.M.A.R.T., Btrfs scrubs (перевірки файлової системи Btrfs) та сканування медіатеки на час перебудови. Конкурентні операції вводу/виводу (I/O) — одна з найпростіших для запобігання причин відмови перебудови.
Перепідключіть SATA-кабелі перед початком
Ненадійне з’єднання, яке працює при невеликому навантаженні, може вийти з ладу під час тривалого обміну даними в процесі відновлення, що триває кілька днів. Відключіть і повторно підключіть усі SATA-кабелі даних та живлення перед початком процедури заміни.
Не змішуйте накопичувачі з різних виробничих партій
Накопичувачі, придбані одночасно й з однієї виробничої партії, зношуються приблизно з однаковою швидкістю. Коли один виходить з ладу, інші статистично ймовірно вийдуть з ладу незабаром. Придбайте замінні накопичувачі від іншого виробника або з іншої виробничої партії.
Увімкніть сповіщення електронною поштою в DSM
Панель керування → Сповіщення → Електронна пошта. DSM може сповістити вас одразу, щойно диск позначено як ‘Faulty’ або стан пулу зберігання починає погіршуватися. Раннє виявлення збою — до того, як процес відновлення (rebuild) триватиме 60 годин — дає більше можливостей для відновлення.
Тримайте незалежну резервну копію
SHR забезпечує відмовостійкість, але не замінює резервне копіювання. Масив у стані деградації під час відновлення не захищений від другої відмови. Hyper Backup на зовнішній диск або в хмарне сховище — єдина гарантія, що збій під час відновлення не перетвориться на незворотну втрату даних.
Збій відновлення під час заміни диска — один із найпоширеніших сценаріїв втрати даних у SHR, оскільки відбувається в найневдаліший момент: максимальне навантаження вводу‑виводу на найстаріше обладнання масиву при відсутності резервного запасу. Після відновлення даних розгляньте цю подію як сигнал — не лише про диск, що вийшов з ладу, а й про стан усього обладнання, з яким він працював.
