Коротка відповідь: Кнопка Repair у Synology DSM і Rebuild RAID Group у QNAP QTS безпечна лише тоді, коли одночасно виконуються три умови: у вас є резервна копія, з якої нещодавно справді щось відновлювали; ви знаєте, який саме диск вибув і чому; а в журналах інших дисків немає помилок чи зростання кількості пошкоджених секторів. Якщо хоча б одна з цих умов не виконується, rebuild — це не ремонт, а найдовший безперервний запис, якого масив зазнає за весь час роботи, причому саме поверх даних, які потрібно врятувати.
Межа проходить не між брендами, а між «ще працює» та «вже відмовило»
Люди дослівно вводять повідомлення в пошуковик, адже інтерфейс NAS навіть у чеській компанії часто залишається англомовним: storage pool degraded, storage pool crashed, volume crashed, system partition failed у Synology; RAID group degraded, volume read-only, volume not active, storage pool inactive у QNAP. На перший погляд, це два різні набори проблем. Насправді межа одна, і обидва виробники проводять її в тому самому місці.
Synology визначає її так: Degraded означає, що один або кілька дисків несправні, але масив і далі доступний, а дані не втрачено — Repair може повернути його до справного стану. Crashed означає, що користувач уже не може відновити масив, зазвичай через відмову надто великої кількості дисків, а цілісність даних не гарантована.
У QNAP ця сама межа називається інакше. Read-Only — це не легший варіант деградації, а стан, у якому QTS самостійно обмежив запис, бо у storage pool щось не узгоджується, а деякі RAID group уже можуть мати стан Not Active.
Практичний переклад: degraded — це попередження, crashed і read-only — це інцидент. А між ними лише одне натискання — Repair у масиві, де другий диск уже непомітно почав помилятися.
Що саме означає кожне повідомлення та який наступний крок безпечніший, докладно пояснюють дві окремі сторінки: повідомлення Storage Pool Degraded, Volume Crashed і System Partition Failed у DSM та стани RAID Group Degraded, Read-Only і Volume not active у QTS. У цьому матеріалі йдеться про спільне для обох випадків: як перевірити три вирішальні речі, перш ніж щось натискати.
Три вирішальні запитання — і де знайти відповіді в DSM та QTS
Перш ніж робити будь-що інше, збережіть знімки екрана: Storage Manager або Storage & Snapshots, список дисків із моделями та відсіками, точний текст повідомлення й записи журналу. Без цього згодом доведеться лише здогадуватися, яким був стан до втручання.
1. Резервну копію перевірено чи вона лише позначена зеленим? Зелений статус завдання означає, що воно завершилося, а не те, що з копії можна відновити дані. Перевірка цілісності Hyper Backup засвідчує, що завдання може тривати й резервну копію можна відновити; самі дані під час цієї перевірки не передаються. Це не тестове відновлення. Правильне запитання звучить так: коли востаннє хтось справді відновлював із цієї копії файл або цілу систему?
2. Ви знаєте, який диск вибув і чому? У DSM це можна побачити в Storage Manager для конкретного диска (Health Info: стан Warning або Critical, кількість пошкоджених, переназначених та очікуваних секторів) і в Log Center, а в QTS — у Storage & Snapshots, стані IHM та системних журналах. Шукайте помилки I/O, скидання шини та повторні від’єднання того самого відсіку. Остерігайтеся пастки: S.M.A.R.T. залишається зеленим, доки сам диск остаточно не здасться — деградацію частіше виявляють за зростанням кількості переназначень і затримки, а не за загальним вердиктом.
3. Інші диски справді чисті? Це найважливіше запитання й водночас те, яке найчастіше пропускають, бо всю увагу привертає диск, що вибув. Проте rebuild зачіпає всі інші диски: з них безперервно зчитується величезний обсяг даних, який потім записується на новий диск. Для чотиридискового RAID 5 із дисками на 4 ТБ під час відновлення потрібно зчитати приблизно 12 ТБ даних, а з дисками на 8 ТБ — 24 ТБ. Водночас виробники споживчих дисків указують як нижню межу один нечитабельний сектор на 10^14 прочитаних бітів, тобто приблизно на 12,5 ТБ. Це число є консервативною специфікацією, а не прогнозом втрати даних, однак беззаперечний висновок один: rebuild — статистично найризикованіша операція, якої зазнає масив.
Усі три перевірки передбачають лише читання. Вони нічого не записують, тому варто витратити на них пів години.
Що насправді записує кожна кнопка
Інтерфейс NAS сам пропонує функції виправлення одразу після аварії. Але пункт у GUI — це не рекомендація саме для вашої ситуації, а стандартна функція для стандартного обслуговування.
| Дія в інтерфейсі | Що насправді відбувається з дисками | Коли це припустимо |
|---|---|---|
| Repair / Rebuild RAID Group | Безперервне читання з усіх уцілілих дисків і запис на новий; перезаписується паритет, який може знадобитися для відновлення | Лише коли виконуються всі три наведені вище умови |
| Recover RAID (QuTS hero) | Спроба повернути до масиву диски, які були тимчасово від’єднані | Лише для диска, який витягнули й одразу повернули до того самого відсіку, — не для диска, що вибув через несправність |
| Create / Initialize / новий том | Створює порожній масив і знищує суперблоки mdadm, метадані LVM та структури файлової системи | Ніколи, якщо важливі дані |
Check File System, fsck, btrfs check --repair, zpool scrub | Запис у метадані файлової системи. Інструмент сприймає пошкоджений паритет як дефект файлової системи та видаляє чинні записи | Не на пошкодженому масиві |
| Переставляння дисків між відсіками | На більшості платформ запускає автоматичну спробу rebuild або запис метаданих | Ніколи без попереднього маркування порядку |
| Перемикання QTS ↔ QuTS hero | QNAP попереджає прямо: «Перехід на QuTS hero видалить усі дані з вашого NAS». Це діє в обох напрямках | Лише з готовою та перевіреною резервною копією |
| Підключення дисків із NAS до Windows | Windows не монтує ext4, Btrfs або XFS і пропонує «ініціалізувати диск», що перезапише таблицю розділів і метадані RAID | Ніколи |
Для Btrfs варто окремо пояснити, чому виправлення «на місці» настільки підступне: воно перезаписує корені поколінь дерев copy-on-write, тобто саме ті структури, на яких ґрунтується подальше відновлення. Метадані з пошкодженого тому потрібно читати інструментом btrfs-restore, а не виправляти монтуванням.
І ще одна річ, яку лабораторії називають найпоширенішою та найруйнівнішою помилкою: примусовий rebuild без упевненості, який диск насправді несправний. Не екзотичне втручання й не командний рядок, а звичайне натискання кнопки, яку пропонує інтерфейс.
П’ять ситуацій, коли «degraded» не означає несправний диск
Сценарій «диск вибув, отже я його заміню» відповідає лише одному конкретному випадку. Ось п’ять ситуацій, у яких він не працює.
- Справний диск вибув через timeout. Настільний SATA-диск не має обмеженого в часі відновлення після помилки й може зациклитися на слабкому секторі на десятки секунд або навіть дві хвилини. Контролер, який чекає від 7 до 30 секунд, сприймає це як несправність і вилучає диск із масиву; NAS-диски мають TLER, ERC або CCTL і припиняють спроби приблизно через сім секунд. Підступність у тому, що окрему перевірку такий диск потім може пройти без помилок.
- У масиві є SMR-диск. Під час rebuild на нього надходить тривалий безперервний запис. Щойно заповнюється його буферна зона, диск починає в реальному часі перезаписувати цілі смуги методом read-modify-write, а пропускна здатність падає до кількох МБ/с. Контролер перевищує timeout і вилучає диск із масиву — повторні спроби лише погіршують ситуацію.
- Вийшов із ладу SSD кешу NVMe. Кеш містить непідтверджені записи, призначені для масиву; це не копія, яку можна просто відкинути. Якщо SSD відмовить, може впасти весь том Btrfs, хоча всі механічні диски залишаються справними.
- Сталося вимкнення електроенергії. Живлення зникає між записом даних та оновленням блоку паритету, через що масив стає неузгодженим. Найпідступніше те, що NAS потім запускається й виглядає справним, хоча каталог резервних копій, база даних або образ віртуальної машини вже пошкоджені.
- Не збігаються event counter у суперблоках mdadm. Масив відмовляється складатися з дисків, які вважає застарілими, хоча дані на них є. Команда
mdadm --assemble --forceбез знання event count, зміщень і порядку дисків — це ризик, а не ремонт.
Спільний знаменник: у жодній із цих п’яти ситуацій rebuild не є розв’язанням проблеми. І в усіх п’яти інтерфейс охоче його запропонує.
Два задокументовані випадки: найнебезпечніше — планове обслуговування
Synology DS2015xs, RAID 6, шість дисків по 6 ТБ. Масив складався з п’яти дисків WD60EFRX (CMR) та одного WD60EFAX (SMR), який установили замість несправного CMR-диска. Новий диск почав помилятися, продуктивність впала до неприйнятного рівня, NAS неможливо було коректно вимкнути чи перезапустити, а зрештою він узагалі перестав вмикатися. Лабораторія, яка працювала над цим випадком, підсумувала його фразою, яку варто прочитати двічі: «NAS справді не повідомив про жодні збої чи простої». Записи про помилки в журналі були. Попереджень для користувача — жодного.
Netgear ReadyNAS, X-RAID поверх Btrfs. Сценарій «збільшуємо місткість без зупинення роботи»: три диски по 3 ТБ послідовно замінювали на диски по 6 ТБ, щоразу відновлюючи масив між замінами. Щойно встановлений диск на 6 ТБ посеред процесу почав повідомляти про помилки ATA, а з масиву вибув і другий диск — той, який згодом пройшов окрему перевірку без помилок. Незавершений rebuild пошкодив метадані та файлову систему.
З обох випадків випливає одне: найнебезпечніший момент у житті NAS — не аварія, а планове обслуговування: заміна диска, розширення місткості чи міграція. А система моніторингу, на яку покладається компанія, може взагалі нічого не повідомити. Тому варто перевірити навіть таку банальність, як надходження сповіщень із DSM або QTS на адресу, яку хтось справді читає.
Коли потрібно негайно припинити натискати будь-що
- Стан — crashed, inactive або read-only.
- Помилки виникають більш ніж на одному диску.
- Диск клацає, постійно зникає або на ньому зростає кількість очікуваних і переназначених секторів.
- Repair або rebuild уже запускали, але він не завершився, або завершився, та стан не покращився.
- Хтось уже пробував скидання, перевстановлення системи, заміну кількох дисків або переставляння їх між відсіками.
- Дані існують лише тут.
У таких випадках наступне натискання — це не спроба виправлення, а запис у єдину копію. Вимкнені носії залишаються стабільними. Якщо дані не вдається отримати навіть після вимкнення NAS і підключення дисків до іншої системи, можливості та пов’язані з ними ризики описано в матеріалі про те, як витягти дані з NAS, коли NAS відмовив.
Що підготувати перед зверненням по допомогу
- Модель NAS і версію системи (DSM, QTS, QuTS hero).
- Кількість дисків, їхні точні моделі, місткість і порядок відсіків.
- Тип масиву (RAID 1/5/6/10, SHR-1, SHR-2, X-RAID) і файлову систему (ext4, Btrfs, ZFS).
- Коли востаннє все працювало та що відбувалося безпосередньо перед проблемою: заміна диска, вимкнення електроенергії, оновлення чи міграція.
- Що вже пробували. Насамперед — чи запускали rebuild, initialize, перевірку файлової системи або підключали диски до Windows. Це питання не про пошук винного, а про те, що ще залишилося на дисках.
- Чи існує будь-яка резервна копія та коли з неї востаннє щось відновлювали.
Поширені запитання
DSM пропонує Repair. Хіба це не означає, що дія безпечна?
Ні. Repair — це стандартна функція для стандартної ситуації: деградованого масиву, де точно відомо, який диск вибув, а решта дисків справні. Інтерфейс не знає стану ваших резервних копій і того, що відбувалося з масивом минулого тижня. Наявність кнопки не є оцінкою ризику.
Масив має стан degraded, але спільні папки доступні. Чи можна скопіювати дані?
Якщо диски не видають підозрілих механічних звуків, а в журналі немає помилок інших дисків, доцільно скопіювати найважливіші папки, а не запускати повне резервне копіювання на багато годин. Суцільне читання нестабільного масиву створює навантаження, здатне прискорити саме те, чого ви намагаєтеся уникнути. Спочатку зупиніть завдання резервного копіювання, індексацію, запис із камер і заплановані SMART-тести.
Після заміни диск пройшов перевірку як справний. Чи можна повернути його назад?
Фізично так, але це не дає відповіді на запитання, чому він вибув. Диск, вилучений із масиву через timeout або поведінку SMR-прошивки, може пройти окрему перевірку без помилок, але в масиві поводитиметься так само, як і раніше.
Чи допоможе програма відновлення, яку я маю у Windows?
Для багатодискового масиву — ні. Такі програми сканують кожен диск окремо й не вміють скласти масив, тому не відновлять файл, розподілений між смугами.
Ваш масив має стан degraded, crashed або read-only і ви боїтеся натиснути не ту кнопку? Надішліть нам знімок екрана з DSM або QTS і напишіть, що вже відбувалося. Ми скажемо, чи це ще звичайне сервісне втручання, чи безпечніше вимкнути NAS і працювати з копіями дисків. Як відбувається відновлення даних із RAID і NAS, зокрема що роблять з оригінальними дисками, описано на сторінці послуги.
Джерела
- Synology: Repair і Storage Pool (визначення Degraded та Crashed) — kb.synology.com
- Synology: What can I do if one of my volumes crashed? — kb.synology.com
- QNAP QTS 5.2: стан Storage pool (Read-Only, Not Active, Inactive) — docs.qnap.com
- QNAP QTS 5.1: відновлення RAID Group зі станом Degraded — docs.qnap.com
- QNAP: Can I switch my NAS OS? (перемикання QTS ↔ QuTS hero видаляє дані) — qnap.com
- Rossmann Repair Group: What Happens During a NAS Crash (Btrfs, кеш NVMe,
btrfs-restore) — rossmanngroup.com - Rossmann Repair Group: Why Rebuilding a Degraded RAID Destroys Data — rossmanngroup.com
- SmallNetBuilder: The Seven Biggest Mistakes When Attempting Data Recovery — smallnetbuilder.com
- Wikipedia: Error recovery control (TLER, ERC, CCTL) — en.wikipedia.org
- EXALAB: відновлення даних із RAID після відмови HDD у NAS (випадок Synology DS2015xs) — exalab.cz
- EXALAB: відновлення даних із NAS Netgear після відмови RAID 5 (випадок X-RAID і Btrfs) — exalab.cz
Де нас знайти
ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.
Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).