Прежде чем предпринимать какие-либо действия

Когда процесс rebuild зависает, три действия кажутся логичными — однако каждое из них может превратить устранимую проблему в необратимую:

Перезагрузка NAS

Деградированный массив хранит состояние своих участников в оперативной памяти. Перезагрузка заставляет mdadm перечитать суперблоки на дисках — если эти суперблоки не синхронизированы из‑за прерванного процесса реконструкции, массив после перезагрузки может вовсе не собраться.

Извлечение дисков

Даже если DSM пометил диск как «Faulty», удаление участника изменяет количество устройств в массиве и заставляет mdadm обновить суперблоки на оставшихся дисках, зафиксировав удаление как постоянное событие. Это может привести к безвозвратному исключению диска, который на самом деле был читаем.

Нажатие «Восстановить» в диспетчере хранилища

Команда «Восстановить» инициирует новую попытку перестроения. Если первоначальное перестроение завершилось неудачей из‑за ошибок чтения на существующем диске, повторная попытка снова прочитает те же секторы — это может усугубить повреждения на и без того перегруженном диске и повысить риск его окончательной неисправности.

Принудительное отключение питания

Резкое отключение питания во время активного (даже «замороженного») процесса восстановления может привести к записи частичных блоков паритета на новый диск, в результате чего массив окажется в состоянии, когда ни старые, ни новые данные не соответствуют друг другу. Всегда используйте процедуру завершения работы DSM, если интерфейс всё ещё доступен.

Запуск fsck или btrfs check

Утилиты для восстановления файловых систем работают на уровне тома — на один уровень выше массива. Запуск их на деградированном массиве означает, что они читают реконструированные данные, которые могут содержать ошибки четности, и могут записать повреждённые метаданные обратно на диск.

Добавление ещё одного диска

Вставка запасного диска в массив со статусом Crashed приводит к тому, что DSM пытается автоматически выполнить восстановление. Если не выяснить причину неудачи первого восстановления, повторная попытка столкнётся с той же проблемой — при этом на уже перегруженное оборудование ляжет ещё один цикл полного чтения всего массива.

Почему восстановление не удалось

Когда SHR заменяет диск другого объёма, он выполняет гораздо больше действий, чем простое копирование данных. Последовательность выглядит так:

1. mdadm считывает все разделы с данными с оставшихся дисков при устойчивой последовательной пропускной способности — это может занимать часы или дни на массивах объёмом в несколько терабайт.

2. Вычисляется и записывается чётность на новый диск. В SHR с дисками разного объёма mdadm использует несколько md-устройств разного размера, объединённых между собой, поэтому расчёт чётности сложнее, чем в RAID 5 с фиксированной геометрией.

3. LVM перерассчитывает распределение физических экстентов по расширенному пулу хранения. Если новый диск больше, это означает переразметку схемы в группе томов (Volume Group) — отдельную операцию, которая выполняется параллельно с восстановлением mdadm или после него.

Любая ошибка на любом этапе прерывает последовательность. Три основные причины объясняют большинство сбоев восстановления SHR:

Неисправимые ошибки чтения (URE)

У потребительских накопителей вероятность URE составляет примерно 1 на 10¹⁴ прочитанных бит. На диске емкостью 4 ТБ это означает, что при полном последовательном проходе статистически вероятна по крайней мере одна ошибка чтения. В обычной эксплуатации эти сектора редко затрагиваются. При восстановлении (rebuild) каждый сектор читается — и один единственный нечитаемый сектор прерывает вычисление паритета для всего страйпа (полосы данных). Диску не обязательно полностью выходить из строя; достаточно одной ошибки чтения в неподходящий момент.

Таймауты SATA под нагрузкой

Кабель или соединение на бэкплейне, которые при обычных нагрузках работают на грани допустимого, могут стабильно отказывать при длительных интенсивных операциях чтения во время перестроения массива. Ядро регистрирует ошибку SATA, mdadm считает диск недоступным и помечает его как «Faulty» — даже если сам диск физически исправен. После переподключения диск снова появляется, но mdadm уже исключил его из массива.

Фоновые задачи DSM

Synology автоматически планирует тесты S.M.A.R.T., индексирование медиаконтента (для Photo Station и Video Station) и операции scrub файловой системы Btrfs. Любая из этих задач, выполняющаяся одновременно с операцией восстановления (rebuild), конкурирует за ту же полосу пропускания дисковых операций ввода‑вывода. На системе, где уже выполняется длительное полное чтение диска, дополнительная нагрузка ввода‑вывода может увеличить задержки чтения до уровня, при котором срабатывают таймауты диска — что даёт тот же эффект, что и физическая проблема с подключением.

Для более полного сравнения рисков восстановления (rebuild) и прямого восстановления данных программными средствами см. нашу статью: Восстановление RAID против программного восстановления.

Прочитайте текущее состояние массива

Перед любой попыткой восстановления точно выясните, что сообщает mdadm. Если есть доступ по SSH, две команды дадут полную картину. Для подробного пошагового разбора вывода mdadm смотрите наше руководство по восстановлению mdadm RAID. Ниже приведены конкретные шаблоны, на которые стоит обратить внимание в этой ситуации.

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) (запасной) означает, что у mdadm нет активного массива — устройства присутствуют, но не собрались. Данные физически находятся на дисках, но недоступны.

Ниже таблица сопоставляет статус DSM, который вы видите, с тем, что фактически происходит, и что следует сделать дальше:

Восстановление данных с помощью RS RAID Retrieve

RS RAID Retrieve Windows · Linux · macOS

Сложность:

Низкая

RS RAID Retrieve восстанавливает конфигурацию массива SHR по суперблокам mdadm на оставшихся дисках, поддерживает работу с деградированными массивами, в которых один участник отсутствует или помечен как Faulty, и предоставляет доступ к тому в режиме «только чтение» для выборочного восстановления файлов — без попыток повторного перестроения массива.

Работает с деградированными и вышедшими из строя массивами

Восстанавливает тома SHR (Synology Hybrid RAID) из оставшихся дисков без необходимости наличия полностью исправного массива — в том числе неактивные массивы, которые 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. перед заменой диска

Выполните полный расширенный тест S.M.A.R.T. на всех оставшихся дисках перед извлечением старого. Диск с перераспределёнными секторами или с ожидающими ошибками, скорее всего, приведёт к URE (неисправимой ошибке чтения) во время последующей перестройки массива.

Отключите фоновые задачи DSM во время перестройки

Перейдите в Панель управления → Планировщик заданий и приостановите запланированные тесты S.M.A.R.T., проверки целостности Btrfs (scrub) и сканирование медиатеки на время перестройки массива. Конкурирующие операции ввода‑вывода — одна из наиболее легко предотвращаемых причин отказа при перестройке.

Переподключите SATA-кабели перед началом

Ненадёжное соединение, которое работает при небольшой нагрузке, может не выдержать постоянной высокой пропускной способности в ходе многодневного восстановления. Перед началом процесса замены отключите и заново подключите все SATA-кабели данных и питания.

Не смешивайте партии накопителей

Накопители, приобретённые одновременно в рамках одной производственной серии, изнашиваются с одинаковой скоростью. Когда один выходит из строя, остальные статистически практически сразу следуют за ним. Приобретайте заменяющие накопители у другого производителя или из другой производственной партии.

Включите уведомления по электронной почте в DSM

Панель управления → Уведомления → Электронная почта. DSM может уведомить вас в тот же момент, когда диск помечается как «Faulty» или пул хранилища деградирует. Раннее обнаружение — до того, как процесс восстановления продлится 60 часов — даёт больше вариантов для восстановления.

Держите независимую резервную копию

SHR обеспечивает устойчивость к отказам, но не заменяет резервное копирование. Дефрагментированный (degraded) массив во время восстановления не защищён от повторного сбоя. Hyper Backup на внешний диск или в облачное хранилище — единственная гарантия того, что сбой при восстановлении не превратится в окончательную потерю данных.

Сбой восстановления при замене диска — один из наиболее распространённых сценариев потери данных в SHR, потому что он случается в наихудший возможный момент: максимальная нагрузка ввода-вывода на самое старое оборудование в массиве при нулевом запасе избыточности. После восстановления данных рассматривайте этот инцидент как сигнал — не только о неисправном диске, но и о состоянии всего оборудования, с которым он работал.

Содержание

1. Почему диски не читаются ни в Windows, ни в macOS, ни в «чистом» Linux
2. Путь 1: Ручная сборка через терминал Linux
3. Путь 2: RS RAID Retrieve
4. Когда ни один из путей не помогает
   • Остановитесь и выключите питание, если наблюдаете любое из следующих

Перед любыми действиями: зафиксируйте порядок установки дисков в корзинах NAS. Synology помечает каждый отсек — сфотографируйте его или запишите номер перед извлечением дисков. Изменение порядка подключения на машине для восстановления усложняет реконструкцию массива и может привести к некорректному наложению паритета.

Почему диски не читаются ни в Windows, ни в macOS, ни в «чистом» Linux

Synology Hybrid RAID не хранит данные как один файловый том на «сыром» разделе. Когда DSM создаёт storage pool и volume, он строит три отдельных слоя поверх физических дисков:

Windows не поддерживает ни один из этих уровней «из коробки»: ни Linux RAID-разделы, ни LVM, ни Btrfs или ext4. То же относится к macOS. Обычная установка Ubuntu без дополнительных пакетов увидит разделы 0xFD, но не соберёт md-массив и не активирует VG автоматически. Вот почему диски SHR выглядят как RAW, неотформатированные или просто невидимые независимо от ОС, к которой вы их подключаете.

Для более глубокого понимания процесса сборки mdadm и структуры LVM см. наши статьи про LVM и восстановление mdadm RAID-массивов.

Путь 1: Ручная сборка через терминал Linux

Ubuntu Live USB + mdadm + LVM Описано в официальной базе знаний Synology для DSM 6.2+

Сложность:

Средняя

Эта процедура применяется к DSM 6.2 и выше, для томов на Btrfs или ext4. Вам нужен ПК с достаточным количеством SATA-портов, чтобы подключить все диски SHR одновременно — за исключением горячих запасных (hot spares), bootable Ubuntu 22.04 Live USB и отдельный диск-приёмник с достаточным свободным местом.

sudo -i

apt-get update && apt-get install -y mdadm lvm2

mdadm -AsfR && vgchange -ay

cat /proc/mdstat lvs

mount /dev/vg1/volume_1 /mnt/data -o ro

Путь 2: RS RAID Retrieve

RS RAID Retrieve Windows · Linux · macOS

Сложность:

Низкая

RS RAID Retrieve выполняет ту же детекцию superblock’ов mdadm, парсинг метаданных LVM и монтирование томов, но через графический интерфейс и без необходимости загружаться в Live Linux. Программа работает в Windows, Linux и macOS, поэтому вы можете использовать любую доступную систему.

RS Raid Retrieve

Автоматическое восстановление любых RAID массивов

Попробовать бесплатно

Доступно для: Windows, macOS, Linux

Когда ни один из путей не помогает

Оба описанных метода предполагают, что диски механически исправны и обнаружимы системой. Если какой-либо диск не отображается в ОС, издаёт щелчки или скрежет, или показывает критические значения S.M.A.R.T., проблема уже не в программном слое. Восстановление данных с механически повреждённого диска требует физического вмешательства — замены головок, переноса пластин — и должно выполняться в контролируемых условиях лаборатории по восстановлению данных.

Неисправная плата Synology при целых дисках — одна из самых простых для восстановления из сценариев NAS: данные SHR присутствуют и согласованы, и время само по себе не играет решающую роль. Диски не ухудшаются просто лежа отключёнными. Риск возникает от действий, а не от бездействия: подключение к ПО, которое пишет метаданные разделов, выполнение сборки с --force без понимания состояния superblock’ов или продолжение питания диска, который до смерти платы уже показывал ошибки.

Дальнейшие действия зависят от одного свойства Unraid, которое становится его главным преимуществом при катастрофических сбоях: данные на оставшихся дисках остаются нетронутыми и полностью читаемы — каждый диск представляет собой независимую файловую систему и не требует доступа к другим дискам. В этой статье описано, как извлечь то, что осталось, и какие инструменты делают эту задачу практичной с компьютера под управлением Windows.

Почему Unraid терпит отказы иначе, чем RAID 5 и RAID 6

В массиве RAID 5 файлы разбиваются на фрагменты фиксированного размера и распределяются полосами по всем дискам-участникам. Ни на одном отдельном диске не хранится целый файл. Полоса из N+1 дисков содержит фрагменты данных от N дисков и один блок паритета. Потеря любых двух дисков делает каждую полосу, затронувшую хотя бы один из этих дисков, неполной — следовательно, весь массив становится нечитаемым, независимо от того, сколько дисков осталось.

Unraid записывает файлы целиком на отдельные диски. Файл, записанный на диск 2, полностью находится на диске 2. Диск 3 о нём ничего не знает. Диск паритета хранит побитовый XOR всех дисков данных на уровне секторов, что позволяет восстановить любой один потерянный диск — однако сами диски данных представляют собой независимые, автономные тома.

Последствия существенны. В RAID 5 из шести дисков потеря двух означает утрату всего, что было записано на всех шести. В Unraid из шести дисков потеря двух означает утрату только тех данных, которые физически находились именно на этих двух дисках — остальные четыре диска можно читать прямо сейчас, без каких-либо операций по восстановлению.

Что действительно теряется, когда паритет превышен

Понимание точных границ потери данных позволяет избежать как излишнего пессимизма, так и недостаточной подготовки. На приведённой ниже визуализации показан массив Unraid из шести дисков с одним паритетом, в котором вышли из строя два диска с данными.

Граница потери данных совпадает с физическими дисками, которые вышли из строя. Ничего на дисках 1, 3 или 5 не пострадало. Файлы, хранившиеся на дисках 2 и 4, утрачены — не потому, что паритет «сломался» в общем смысле, а потому что соответствующие сектора физически недоступны.

Восстанавливается без программного обеспечения

Файлы, полностью размещённые на уцелевшем диске, можно восстановить — просто подключите диск к системе Linux и скопируйте данные. Воссоздание массива не требуется, и паритетный диск не нужен.

Восстановление программными средствами

Доступ к файлам на оставшихся дисках возможен даже в случаях, когда сам Unraid не загружается, загрузочное устройство отсутствует или конфигурация массива утеряна. RS RAID Retrieve считывает метаданные дисков и восстанавливает структуру массива без необходимости запущенного сервера Unraid.

Невосстановимо

Любые файлы, которые хранились на физически вышедшем из строя диске и были утрачены вследствие отказов в количестве, превышающем покрытие паритетом. Никакое программное обеспечение не сможет восстановить данные из секторов, которые физически утрачены.

Перед началом: действия, от которых зависит успешность восстановления

В случае катастрофического сбоя действия, предпринятые в первые минуты после его обнаружения, влияют на итоговый результат сильнее, чем любое последующее программное обеспечение для восстановления. Некоторые типичные реакции лишь усугубляют ситуацию.

Что делать вместо этого

Восстановление данных с разрушенного массива Unraid с помощью RS RAID Retrieve

При подключении оставшихся дисков к компьютеру с Windows RS RAID Retrieve берет на себя задачи, для выполнения которых обычно требуется работающая система Linux: чтение файловых систем XFS и BTRFS, воссоздание структуры массива Unraid по метаданным дисков и предоставление просматриваемого дерева файлов, из которого можно выборочно копировать данные на исправный носитель.

RS Raid Retrieve

Автоматическое восстановление любых RAID массивов

Попробовать бесплатно

Доступно для: Windows, macOS, Linux

Работа с частично читаемыми дисками

Катастрофические отказы часто включают по крайней мере один диск, который не полностью вышел из строя — он вращается, определяется BIOS, но при чтении некоторых секторов возникают ошибки. Такие частично читаемые диски являются самым чувствительным ко времени компонентом восстановления: они всё ещё способны отдавать данные, но каждый цикл включения питания и каждая неудачная попытка чтения ускоряют механический износ.

Создание образа деградирующего диска с помощью ddrescue

ddrescue — стандартный инструмент для этой задачи, поскольку он корректно обрабатывает ошибки чтения: сначала пропускает нечитаемые сектора, считывает всё, что можно, а затем повторно пытается получить данные с проблемных секторов на последующих проходах. Это отличается от поведения dd, которое по умолчанию останавливается при первой же ошибке чтения.

	# First pass: read everything readable, skip errors, save map file
	ddrescue
	-d -r0
	/dev/sdX /mnt/recovery/disk_image.img /mnt/recovery/disk_image.map
	# Second pass: retry failed sectors up to 3 times
	ddrescue
	-d -r3
	/dev/sdX /mnt/recovery/disk_image.img /mnt/recovery/disk_image.map

Файл карты (map file) фиксирует, какие сектора были успешно прочитаны, а какие — нет. Если диск выйдет из строя в процессе копирования или вам нужно прервать операцию и продолжить позже, повторный запуск команды с той же картой возобновит работу с того места, где остановились, не перечитывая уже сохранённые сектора.

Подключение образа в RS RAID Retrieve

После завершения создания образ можно использовать вместо физического диска. В RS RAID Retrieve выберите Подключить образ, чтобы присоединить файл .img в качестве виртуального диска. Программа будет работать с ним так же, как с физическим устройством. Такой подход имеет два преимущества: деградирующее оборудование больше не испытывает нагрузку чтением во время восстановления, и если процесс восстановления потребуется повторить с другими настройками, исходный образ всегда доступен.

Что можно и чего нельзя восстановить в этой ситуации

Исход внепаритетного отказа в Unraid более предсказуем, чем в классических RAID-системах, поскольку граница повреждений определяется физическими границами дисков, а не распределением полос (stripes). В таблице ниже приведён обобщённый путь восстановления для каждого компонента массива.

Паритет здесь не поможет. Паритетный диск содержит побитное зеркальное представление данных, но не хранит информацию о целостности метаданных файловой системы. Если журнал или суперблок на диске с данными повреждены, паритет аккуратно сохранит это повреждение. Для восстановления в такой ситуации необходимо работать непосредственно с инструментами ремонта файловой системы — xfs_repair для томов XFS и btrfs check для BTRFS — из терминала Unraid.

Ситуация	Файловая система	Действие	Ожидаемый результат
Диск не монтируется, SMART в порядке	XFS	Режим обслуживания → xfs_repair /dev/sdXp1 → перезагрузка	Диск монтируется, данные целы
xfs_repair не проходит: ошибка dirty log	XFS	xfs_repair -L /dev/sdXp1 (обнуляет журнал)	Диск монтируется; файлы, открытые во время краха, могут быть частичными или пустыми
Диск не монтируется, SMART в порядке	BTRFS	btrfs scrub (смонтирован) → btrfs check /dev/sdXp1 (только для чтения) → оценка ошибок	Незначительные ошибки: после проверки диск монтируется
btrfs check сообщает об ошибках деревьев extent/chunk	BTRFS	Пропустить опцию --repair → сначала RS RAID Retrieve для посекторного/файлового восстановления	Частичное восстановление; структурный ремонт может привести к дополнительным потерям
Диск не монтируется, SMART показывает плохие сектора	XFS / BTRFS	RS RAID Retrieve → Полный анализ → восстановление на отдельный диск → плановая замена диска	Файлы подлежат восстановлению; диск физически выходит из строя — ремонт ненадёжен
Инструменты терминала не могут смонтировать диск; после ремонта файлы отсутствуют	XFS / BTRFS	Подключите диски к ПК с Windows → RS RAID Retrieve → Быстрое сканирование или Полный анализ	Восстановление файлового уровня без монтирования файловой системы
На диске, который не монтировался, нажали «Format»	Любая	Нет пути восстановления — паритет теперь отражает пустой диск	Данные утрачены навсегда

Как Unraid использует отдельные файловые системы для каждого диска

В случае логического сбоя архитектура Unraid становится ключевым фактором для понимания того, что повреждено, а что — нет.

В отличие от RAID 5 или RAID 6, где одна полоса данных распределяется по нескольким физическим дискам, Unraid записывает файлы целиком на отдельные диски. Каждый диск с данными является автономным томом — отформатированным как XFS или BTRFS — и монтируется операционной системой отдельно. Слой массива Unraid выше файловой системы отвечает за агрегирование «shares» и обновление паритета, тогда как сам файловый слой внизу — это стандартный Linux.

XFS

По умолчанию в Unraid

Ключевые особенности, влияющие на восстановление:

• Восстановление метаданных на основе журналирования
• Для ремонта диск должен быть отмонтирован
• В Unraid: требуется включение режима обслуживания (Maintenance Mode)
• Основной инструмент: xfs_repair
• Исправление повреждённого журнала требует флага -L (деструктивная операция)

BTRFS

Опционально в Unraid

Характеристики, важные при восстановлении:

• Copy-on-write (COW); встроенные контрольные суммы для данных и метаданных
• Проверку можно запускать на смонтированном томе
• Режим восстановления (--repair) агрессивен — используйте с осторожностью
• Основные утилиты: btrfs check, btrfs scrub
• Возможность восстановления субтомов даже при частичной порче данных

Практический вывод из этой архитектуры: повреждение файловой системы на Диске 3 никак не влияет на файловые системы Диска 1, Диска 2 или любого другого диска. Данные каждого диска изолированы. Вы восстанавливаете один том, а не весь массив целиком. Исключение — диск четности: у него нет файловой системы, и его никогда не следует подвергать инструментам для восстановления файловых систем.

Причины повреждения файловой системы в Unraid

Повреждение файловой системы в Unraid почти всегда можно отнести к одной из трёх основных причин. Понимание того, какая из них имеет место, определяет подход к восстановлению.

Нечистое завершение работы

Отключение питания или принудительная перезагрузка во время работы массива оставляют незавершённые операции записи. Журнал содержит неполные транзакции. При следующем монтировании файловая система обнаруживает несогласованность и отказывается монтироваться. Это самая распространённая причина.

Неисправная оперативная память

Поддержка памяти с коррекцией ошибок (ECC) в большинстве установок Unraid по умолчанию отсутствует. Изменение состояния одного бита в буфере записи может повредить метаданные файловой системы — записи каталогов, таблицы inode или суперблок — и проявиться так же, как последствия отключения питания, но такие ошибки гораздо труднее предотвратить.

Ошибки секторов диска

Перераспределённые или помеченные как ожидающие перераспределения сектора в SMART-данных диска указывают на области, которые устройство не может надёжно читать или записывать. Если метаданные файловой системы попадут на такие сектора, файловая система может быть повреждена даже без события с питанием. Если при повреждении файловой системы счётчики ошибок SMART ненулевые, вероятнее всего причина — аппаратная неисправность.

Кнопка «Format»: что она на самом деле делает и почему её нельзя нажимать

Когда диск становится Unmountable (не монтируется), веб‑интерфейс Unraid отображает опцию Format рядом с кнопками диагностики. Для пользователей, не знакомых с тем, как Unraid управляет парностью, это порождает опасное заблуждение: будто нажатие Format как‑то автоматически вернёт диск в рабочее состояние и паритет восстановит утраченные файлы.

Форматирование не восстанавливает данные. Оно уничтожает их навсегда.

Нажатие кнопки Format на немонтируемом диске полностью стирает файловую систему и создаёт новый пустой том. Затем паритет перерасчитывается с учётом этого теперь пустого диска. Исходные данные исчезают — не повреждены, не подлежат восстановлению, их нет. Паритет будет корректно отражать пустой диск, что делает любые последующие попытки восстановления бесполезными.

Это самый распространённый сценарий потери данных в Unraid после аппаратных отказов, и он полностью инициирован пользователем. Данные, которые находились на диске до нажатия кнопки Format, в большинстве случаев можно восстановить с помощью инструментов, описанных в этой статье.

Правильная последовательность действий при немонтируемом диске: сначала диагностировать, затем пытаться восстановить/починить, форматировать только в самом крайнем случае — и только после того, как все данные уже будут скопированы или восстановлены в другое место.

Восстановление немонтируемого XFS-диска в Unraid: пошаговая инструкция для xfs_repair

xfs_repair требует, чтобы целевая файловая система была полностью отмонтирована перед запуском. В работающем массиве Unraid все диски с данными смонтированы. Чтобы отмонтировать конкретный диск для ремонта, не отключая полностью общие ресурсы (shares), Unraid нужно запустить в режим обслуживания (Maintenance Mode) — режим загрузки, при котором массив поднимается без смонтированных шаров и без активного использования дисков.

Шаг 1: Запустите массив в режиме обслуживания

В веб‑интерфейсе Unraid откройте раздел Main. Перед нажатием кнопки запуска отметьте чекбокс Maintenance Mode, который появляется под элементами управления запуском массива. Нажмите Start. Массив запустится, но диски не будут монтированы в шаринги. Это требуемое состояние для xfs_repair.

Шаг 2: Определите правильный путь к устройству

Этот шаг предотвращает распространённую и серьёзную ошибку. В Unraid у каждого диска данных два пути к устройству:

• /dev/mdXp1 — MD‑устройство (массив), управляемое уровнем массива Unraid. Не используйте этот путь для xfs_repair.
• /dev/sdXp1 — сырой раздел диска, прямой путь к аппаратному устройству. Используйте этот путь.

Чтобы определить, какой /dev/sdX соответствует диску, который вы собираетесь ремонтировать, откройте терминал (в WebGUI: Tools → Terminal, или подключитесь по SSH) и выполните:

# List disks with their Unraid slot assignments
ls -la /dev/disk/by-id/

Сопоставьте серийный номер из SMART‑отчёта в WebGUI с символьной ссылкой в /dev/disk/by-id/, чтобы подтвердить правильность пути к устройству перед продолжением.

Шаг 3: Запустите xfs_repair — стандартный проход

# Replace sdX with your actual device identifier (e.g. sdb, sdc)
xfs_repair /dev/sdXp1

xfs_repair выполнит несколько фаз: проверит иноды, каталоги и карту свободного пространства. При исправном журнале он воспроизводит неподтверждённые транзакции и завершает работу с кратким отчётом. Если проверка завершилась без критических ошибок, попробуйте примонтировать диск, перезагрузившись в обычный режим (без режима обслуживания).

Шаг 4: Если xfs_repair завершается из‑за «грязного» журнала — флаг -L

Если восстановление прерывается сообщением вроде «ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed» и утилита отказывается продолжать, значит журнал транзакций нечитаем. Единственный вариант в этой ситуации — обнулить журнал, используя флаг -L.

# Force repair by zeroing the dirty log
# Use only after standard xfs_repair has failed
xfs_repair -L /dev/sdXp1

Шаг 5: Проверка восстановления

После успешного восстановления запустите xfs_repair ещё раз в режиме только-проверки (-n) чтобы убедиться, что больше нет несоответствий:

# Dry-run check — makes no changes, reports remaining issues
xfs_repair -n /dev/sdXp1

Если сухой прогон (dry-run) показывает отсутствие ошибок, перезагрузитесь в обычном режиме (без Maintenance Mode). Диск должен смонтироваться, и общий ресурс должен снова появиться. После этого выполните проверку паритета в режиме без исправлений, чтобы подтвердить корректность паритета.

Восстановление повреждённого тома BTRFS в Unraid

Повреждения BTRFS в Unraid встречаются реже, чем XFS, отчасти потому, что BTRFS использует семантику copy-on-write (COW) — он никогда не перезаписывает существующие данные, а сначала записывает новые версии блоков в свободное пространство. Это делает файловую систему более устойчивой к неполным записям. Тем не менее повреждение метаданных всё ещё возможно, и процедуры восстановления в ряде важных аспектов отличаются от тех, что применяются для XFS.

Шаг 1: начните с btrfs scrub — а не с btrfs check

Прежде чем выполнять какие-либо восстановительные операции, запустите scrub на смонтированном томе. В отличие от xfs_repair, btrfs scrub может выполняться при смонтированной файловой системе. Он проверяет контрольные суммы всех блоков данных и метаданных и сообщает о любых несоответствиях. На одно-дисковом томе Unraid без BTRFS RAID scrub не сможет автоматически исправить ошибки — резервных копий нет — но он точно покажет, какие блоки повреждены, что важно при выборе стратегии восстановления. Запустите массив в обычном режиме (не в режиме обслуживания — Maintenance Mode) и откройте терминал:

# Replace /mnt/diskX with the actual Unraid disk mount path
btrfs scrub start /mnt/diskX
 
# Monitor progress
btrfs scrub status /mnt/diskX

Если scrub завершился без ошибок, диск в порядке, и статус «Unmountable» мог быть временным. Перезагрузите систему и проверьте, монтируется ли диск нормально.

Шаг 2: Запустите btrfs check в режиме только для чтения

Если по результатам scrub обнаружены ошибки или диск остаётся несмонтируемым после попытки scrub, переходите к btrfs check. Сначала остановите массив, чтобы диск был размонтирован, затем выполните проверку в режиме только для чтения — это позволит оценить масштаб повреждений перед попытками восстановления:

# Stop array first, then check without making changes
btrfs check /dev/sdXp1

Внимательно изучите вывод. btrfs check перечислит конкретные ошибки деревьев и «осиротевшие» элементы. Небольшие несоответствия — осиротевшие иноды, неверные обратные ссылки корней — обычно можно безопасно исправить. Ошибки в extent tree или chunk tree свидетельствуют о более серьёзном структурном повреждении, и восстановление в режиме восстановления (repair) может оказаться неполным.

Шаг 3: режим восстановления — используйте с осторожностью

Для незначительных, хорошо понятных повреждений — ошибок кэша свободного пространства, осиротевших инодов, неверных обратных ссылок корня — режим восстановления обычно безопасен:

# Only for minor, well-scoped corruption
# Image the disk first if data is critical
btrfs check --repair /dev/sdXp1

Шаг 4: Восстановление отдельных субтомов

Если верхнеуровневое дерево BTRFS повреждено, но данные в субтомах целы, иногда можно смонтировать конкретный субтом напрямую и скопировать из него данные, не восстанавливая всё дерево целиком:

# Показать список субтомов на частично читаемом томе
btrfs subvolume list /mnt/diskX
 
# Смонтировать конкретный субтом по его ID, если стандартное монтирование не удалось
mount -o subvolid=256 /dev/sdXp1 /mnt/recovery_point

Если какой‑либо субтом монтируется успешно, немедленно скопируйте данные на исправный диск до попыток дальнейшего восстановления повреждённого тома.

Когда терминальные утилиты не справляются: восстановление файлов с повреждённого диска Unraid с помощью RS RAID Retrieve

Утилиты xfs_repair и btrfs check работают на уровне структуры файловой системы — они пытаются снова сделать том монтируемым. Если это невозможно из‑за серьёзного повреждения метаданных, либо после завершения ремонта файлы по-прежнему отсутствуют или пусты, следующим шагом становится восстановление на уровне файлов из «сырых» данных диска.

Именно для этого предназначен RS RAID Retrieve. Программа считывает данные с секторов напрямую, обходя повреждённые структуры файловой системы, и восстанавливает деревья каталогов и содержимое файлов по исходным таблицам размещения. Она поддерживает как XFS, так и BTRFS, которые Windows не может монтировать нативно — поэтому стандартный рабочий процесс предполагает использование ПК под Windows с внешне подключённым диском.

RS Raid Retrieve

Автоматическое восстановление любых RAID массивов

Попробовать бесплатно

Доступно для: Windows, macOS, Linux

Результаты восстановления по типу повреждения данных

Повреждение журнала / некорректное завершение работы

Наиболее благоприятный сценарий для восстановления. Структуры распределения файлов обычно целы. RS RAID Retrieve способен восстановить полное дерево каталогов и вернуть файлы с исходными именами и путями. Обычно достаточно Fast Scan.

Частичная порча метаданных

Деревья каталогов могут быть неполными. Некоторые файлы могут отображаться без имён в режиме восстановления. Содержимое файлов часто остаётся целым, даже если метаданные повреждены. Полный анализ восстанавливает больше файлов, но это происходит ценой утраты исходной структуры каталогов в затронутых областях.

Суперблок и дерево экстентов повреждены

Если диск был отформатирован после перехода в состояние «Unmountable», либо если физические повреждения секторов уничтожили первичные и резервные суперблоки, восстановление на уровне файлов невозможно. Такое развитие событий редко встречается при чисто логических сбоях, но часто бывает, когда нажали кнопку «Format» или при выраженной аппаратной деградации диска.

Повреждение файловой системы в Unraid в большинстве случаев можно восстановить — при соблюдении правильной последовательности действий и при условии, что кнопка «Format» не была нажата до сохранения данных. Путь принятия решения прост:

В этой статье описаны механизмы, обеспечивающие такую защиту, корректная процедура замены вышедшего из строя диска и действия на случай, когда стандартный путь не срабатывает и данные нужно извлекать извне.

Как Unraid хранит данные: независимые диски и XOR-паритет

Unraid не распределяет содержимое файлов по дискам полосами, как это делает RAID 5. Каждый диск данных — это полностью автономный том, отформатированный как XFS или BTRFS, который операционная система монтирует отдельно. Файл, записанный на Диск 2, полностью хранится на Диске 2. Это намеренное архитектурное решение с важными последствиями для обычной работы и при отказах.

Слой защиты обеспечивает выделенный Parity disk — диск паритета. Unraid вычисляет паритет по секторам, используя XOR-логику по всем дискам данных. Для каждого смещения сектора диск паритета хранит побитовый XOR соответствующих секторов всех дисков данных.

Ниже — упрощённый пример с тремя дисками данных. Каждая строка — один сектор. Столбец Parity — это XOR от Disk 1–3. Если Диск 2 пропадает, каждый его сектор можно пересчитать из трёх остальных столбцов:

Важное ограничение: этот XOR-механизм защищает от потери ровно одного диска. Если в массиве с одним диском паритета одновременно потеряны два диска данных, математика реконструкции не работает — уравнений недостаточно для двух неизвестных. Этот сценарий рассматривается в третьей статье серии.

Режим эмуляции данных: что это такое и чего от него ожидать

Когда Unraid обнаруживает, что диск отключился, массив не останавливается. Вместо этого он переходит в режим эмуляции данных: отсутствующий диск заменяется виртуальным конструкцией, формируемой на лету из диска паритета и всех оставшихся дисков данных.

С точки зрения клиента, читающего файл, который был на вышедшем из строя диске, ничего не меняется. Unraid перехватывает запрос чтения, определяет соответствующие сектора, восстанавливает их через XOR и возвращает данные. Записи на эмулируемый диск тоже обрабатываются — они обновляют паритет и выжившие диски, пока отсутствует исходный диск.

Режим эмуляции — не постоянное решение. Это переходное состояние — и успех зависит от того, что ни один из оставшихся дисков не выйдет из строя до завершения восстановления. Это окно максимальной уязвимости в Unraid-массиве.

Что работает в режиме эмуляции

Чтение файлов из шар, размещённых на вышедшем из строя диске. Лёгкие записи. Обычный доступ от всех сетевых клиентов. Мониторинг через WebGUI.

Чего ожидать нельзя

Длительных интенсивных записей под нагрузкой. Любой устойчивости к второму отказу диска. Корректирующих результатов проверки паритета — корректирующая проверка в режиме эмуляции может испортить данные.

Замена вышедшего из строя диска: пошаговое восстановление

Процесс восстановления записывает реконструированное содержимое вышедшего из строя диска на заменяющий диск. Unraid читает каждый сектор оставшихся дисков и паритета, вычисляет недостающие данные через XOR и записывает их на новый диск. По завершении процесса паритет снова становится действительным, и массив возвращается к полной защите.

Мониторинг SMART во время восстановления диска в Unraid: что проверять

Восстановление — самая интенсивная по чтению операция, которую когда-либо выполняет массив Unraid. Каждый сектор каждого оставшегося диска данных плюс весь диск паритета читаются последовательно. Диск, который в обычной нагрузке был погранично работоспособен, может не выдержать этой длительной последовательной нагрузки и выйти из строя.

Если второй диск выйдет из строя во время восстановления, массив потеряет возможность эмуляции полностью. В конфигурации с одним диском паритета некуда откатиться. Вы останетесь с деградированным массивом и возможной потерей данных на двух дисках.

Как восстановить файлы с упавшего массива Unraid с помощью RS RAID Retrieve

Стандартный путь восстановления предполагает, что массив можно запустить, Unraid распознаёт конфигурацию дисков и оставшиеся диски достаточно здоровы, чтобы выдержать полное последовательное чтение. Когда любое из этих условий не выполняется — загрузочное устройство повреждено, паритет недействителен или восстановление прервано — встроенные инструменты достигают своих пределов. То же самое относится, когда нужно вернуть файлы с упавшего массива Unraid без ожидания полного цикла восстановления.

В таких случаях наиболее прямой подход — подключить физические диски к Windows‑машине и работать с ними напрямую с помощью RS RAID Retrieve. Программа понимает структуру массива Unraid, может реконструировать логический том из доступных дисков и представить файловые системы XFS или BTRFS в обозреваемом виде — то, что Windows сам по себе сделать не может. Это практичный вариант для восстановления NAS, когда сам Unraid запустить нельзя.

RS Raid Retrieve

Автоматическое восстановление любых RAID массивов

Попробовать бесплатно

Доступно для: Windows, macOS, Linux

Что RS RAID Retrieve может и чего не может в этом сценарии

Доступно при наличии остальных дисков + паритета

Файлы, хранившиеся на вышедшем из строя диске, можно реконструировать, если паритет действителен и все остальные диски присутствуют. Программа выполняет ту же XOR‑математику, что и Unraid при обычном восстановлении.

Частичный доступ без паритета

Если диск паритета также недоступен, данные на оставшихся дисках данных всё ещё напрямую доступны — каждый диск представляет собой полноценную независимую файловую систему. Вы можете восстановить файлы с целых дисков даже без паритета. Файлы, которые были на вышедшем из строя диске, в этом случае утрачены.

Невосстановимо: два диска данных потеряны, один паритет

С двумя неизвестными в XOR‑уравнении реконструкция невозможна. Файлы, хранившиеся на двух вышедших из строя дисках, не могут быть восстановлены через паритетную математику. Этот сценарий подробно рассматривается в материале «Unraid Data Recovery Beyond Parity Limits».

Заключение: когда встроенных инструментов достаточно

Для простого отказа одного диска в здоровом массиве с действительным паритетом встроенный WebGUI Unraid и его нативный процесс восстановления справляются со всем. Сторонние инструменты не требуются. Ключевые переменные: действительный паритет, здоровые оставшиеся диски и целое загрузочное устройство Unraid.

RS RAID Retrieve становится актуален, когда одно из этих условий отсутствует — повреждён загрузочный флеш‑накопитель, восстановление было прервано, замещающий диск ненадёжен или массив Unraid «упал» и не стартует. В таких случаях подключение дисков к Windows‑машине и использование RS RAID Retrieve — самый быстрый путь вернуть файлы с Unraid без предварительного восстановления серверной среды.