Диск физически присутствует, SMART ошибок не показывает, массив Unraid стартовал без проблем — но одна общая папка (share) исчезла, а веб-интерфейс показывает диск как не монтируется. Это событие повреждения файловой системы, и по своей природе оно отличается от аппаратной неисправности.
Паритет здесь не поможет. Паритетный диск содержит побитное зеркальное представление данных, но не хранит информацию о целостности метаданных файловой системы. Если журнал или суперблок на диске с данными повреждены, паритет аккуратно сохранит это повреждение. Для восстановления в такой ситуации необходимо работать непосредственно с инструментами ремонта файловой системы — 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 или любого другого диска. Данные каждого диска изолированы. Вы восстанавливаете один том, а не весь массив целиком. Исключение — диск четности: у него нет файловой системы, и его никогда не следует подвергать инструментам для восстановления файловых систем.
Диск четности не имеет файловой системы — никогда не запускайте xfs_repair или btrfs check на нём.
Диск четности хранит данные XOR по фиксированным смещениям секторов. У него нет таблицы разделов, видимой инструментам работы с файловыми системами, и попытки лечить его как файловую систему повредят данные четности, оставив весь массив без защиты. Перед открытием терминала определите диск четности в веб-интерфейсе (WebGUI).
Причины повреждения файловой системы в Unraid
Повреждение файловой системы в Unraid почти всегда можно отнести к одной из трёх основных причин. Понимание того, какая из них имеет место, определяет подход к восстановлению.
Нечистое завершение работы
Отключение питания или принудительная перезагрузка во время работы массива оставляют незавершённые операции записи. Журнал содержит неполные транзакции. При следующем монтировании файловая система обнаруживает несогласованность и отказывается монтироваться. Это самая распространённая причина.
Неисправная оперативная память
Поддержка памяти с коррекцией ошибок (ECC) в большинстве установок Unraid по умолчанию отсутствует. Изменение состояния одного бита в буфере записи может повредить метаданные файловой системы — записи каталогов, таблицы inode или суперблок — и проявиться так же, как последствия отключения питания, но такие ошибки гораздо труднее предотвратить.
Ошибки секторов диска
Перераспределённые или помеченные как ожидающие перераспределения сектора в SMART-данных диска указывают на области, которые устройство не может надёжно читать или записывать. Если метаданные файловой системы попадут на такие сектора, файловая система может быть повреждена даже без события с питанием. Если при повреждении файловой системы счётчики ошибок SMART ненулевые, вероятнее всего причина — аппаратная неисправность.
Перед запуском любых инструментов восстановления — сначала проверьте SMART:
- Откройте Unraid WebGUI → вкладка Main → нажмите на затронутый диск → SMART report.
- Если
Reallocated_Sector_Ct,Current_Pending_SectorилиOffline_Uncorrectableимеют ненулевые значения, восстановление файловой системы может сработать временно, но аппаратное состояние диска ухудшается. Планируйте замену диска независимо от исхода ремонта. - Если 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.
Unraid 7.0 и новее: сначала используйте кнопки восстановления в веб‑интерфейсе.
Начиная с Unraid 7.0, в просмотре дисков веб‑интерфейс показывает кнопки CHECK и FIX. Они автоматически запускают xfs_repair с корректными флагами. Если ваша версия поддерживает это, попробуйте сначала путь через GUI перед открытием терминала — результат будет тот же, а интерфейс сам позаботится о переводе в режим обслуживания и выборе путей к устройствам.
Шаг 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.
Флаг -L отбрасывает журнал — поймите, что это означает
Обнуление журнала заставляет xfs_repair отказаться от любых ожидающих выполнения транзакций метаданных, которые ещё не были записаны на диск. На практике это означает, что файлы, записывавшиеся в момент сбоя, могут быть частично утеряны или отображаться с нулевым размером. Файлы, полностью записанные до возникновения повреждения, не затрагиваются.
Используйте -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). Диск должен смонтироваться, и общий ресурс должен снова появиться. После этого выполните проверку паритета в режиме без исправлений, чтобы подтвердить корректность паритета.
✓ Ожидаемый вывод после успешного восстановления
xfs_repair выведет строки о завершении фаз (Phase 1–7) и завершит работу с: «done». В фазах 3–7 не должно быть ошибок. Любые файлы, перемещённые в /lost+found в процессе восстановления, будут доступны там после монтирования диска — их можно вернуть в прежние места, если вы знаете, куда они принадлежат.
Восстановление повреждённого тома 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: режим восстановления — используйте с осторожностью
btrfs check —repair может привести к дополнительной потере данных
В отличие от xfs_repair, рассчитанного на регулярное использование, разработчики BTRFS прямо предупреждают не применять режим --repair без консультации с разработчиком или без предварительного образа диска (backup). В случаях серьёзной порчи дерева экстентов (extent tree) режим восстановления может удалить файлы, которые сочтёт осиротевшими, вместо их восстановления.
Если проверка в режиме только для чтения показывает ошибки дерева экстентов и на диске находятся невосполнимые данные, пропустите режим восстановления и сразу переходите к RS RAID Retrieve для посекторного/построчного восстановления файлов до попыток любых структурных исправлений.
Для незначительных, хорошо понятных повреждений — ошибок кэша свободного пространства, осиротевших инодов, неверных обратных ссылок корня — режим восстановления обычно безопасен:
# 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 работает с повреждённым диском Unraid
Программа определяет структуру массива Unraid по метаданным диска, восстанавливает логический том и затем сканирует файловую систему на уровне секторов. Даже если xfs_repair переместил файлы в /lost+found или метаданные слишком повреждены для монтирования, программа часто способна восстановить содержимое файлов и их исходные пути каталогов, напрямую читая данные о распределении блоков.
Автоматическое восстановление любых RAID массивов
Остановите сервер Unraid и извлеките повреждённый диск
Если система всё ещё доступна, выполните корректное завершение работы. Подключите повреждённый диск к компьютеру под управлением Windows — по возможности используйте прямое подключение SATA. Также подключите оставшиеся диски массива и диск чётности; RS RAID Retrieve использует их для восстановления полной конфигурации массива и корректной идентификации роли каждого диска в структуре Unraid.
Запуск RS RAID Retrieve — автоматическое обнаружение массива
При запуске программа сканирует все подключённые диски, считывает с каждого метаданные Unraid и автоматически восстанавливает конфигурацию массива. Повреждённый диск отображается в списке дисков рядом с исправными участниками массива. Windows не присваивает буквенные обозначения томам XFS или BTRFS; это ожидаемое поведение и не указывает на проблему с подключением.
Выберите тип сканирования в зависимости от степени повреждения
Щёлкните правой кнопкой мыши по восстановленному массиву или отдельному диску в Drive Manager и выберите Open. При повреждении файловой системы, когда таблица разделов и суперблок целы, достаточно Fast Scan — оно отобразит дерево каталогов с подсвеченными восстанавливаемыми файлами. Если же сам суперблок повреждён или Fast Scan возвращает пустое дерево файлов, выполните Full Analysis. Это посекторное сканирование по сигнатурам, которое может восстановить файлы даже при отсутствии метаданных каталогов, но имена файлов и пути при этом могут не сохраниться.
Предварительный просмотр файлов перед подтверждением восстановления
RS RAID Retrieve позволяет просмотреть содержимое файлов до того, как будет выполнена какая‑либо запись на диск. Используйте эту возможность, чтобы убедиться, что восстанавливаемые файлы целы — откройте образцы документов, изображений и архивов прямо в окне предварительного просмотра. Файлы, которые корректно отображаются в превью, с большой вероятностью будут восстановлены правильно. Файлы, которые в предварительном просмотре видны как пустые или повреждённые, скорее всего не удастся восстановить в пригодном для использования виде независимо от применяемого инструмента.
Копирование восстановленных файлов на исправный носитель
Выберите файлы и каталоги для восстановления, нажмите Восстановление и укажите путь назначения на отдельном, исправном диске. Не восстанавливайте файлы обратно на исходный диск и не копируйте их на диски, которые в настоящее время находятся в массиве Unraid. После копирования проверьте выборочную группу восстановленных файлов, прежде чем считать восстановление завершённым.
Результаты восстановления по типу повреждения данных
Повреждение журнала / некорректное завершение работы
Наиболее благоприятный сценарий для восстановления. Структуры распределения файлов обычно целы. RS RAID Retrieve способен восстановить полное дерево каталогов и вернуть файлы с исходными именами и путями. Обычно достаточно Fast Scan.
Частичная порча метаданных
Деревья каталогов могут быть неполными. Некоторые файлы могут отображаться без имён в режиме восстановления. Содержимое файлов часто остаётся целым, даже если метаданные повреждены. Полный анализ восстанавливает больше файлов, но это происходит ценой утраты исходной структуры каталогов в затронутых областях.
Суперблок и дерево экстентов повреждены
Если диск был отформатирован после перехода в состояние «Unmountable», либо если физические повреждения секторов уничтожили первичные и резервные суперблоки, восстановление на уровне файлов невозможно. Такое развитие событий редко встречается при чисто логических сбоях, но часто бывает, когда нажали кнопку «Format» или при выраженной аппаратной деградации диска.
Повреждение файловой системы в Unraid в большинстве случаев можно восстановить — при соблюдении правильной последовательности действий и при условии, что кнопка «Format» не была нажата до сохранения данных. Путь принятия решения прост:
Логический сбой не означает, что паритет недействителен — но полагаться на него слепо нельзя.
После ремонта файловой системы диск паритета по‑прежнему содержит XOR от секторов диска — включая сектора, повреждённые до ремонта. После успешного ремонта и чистой монтировки диска выполните проверку паритета без исправления (non‑correcting), чтобы выявить несоответствия. Если найдены ошибки, выполните проверку с исправлением, чтобы синхронизировать паритет с текущим состоянием диска. Сделайте это до возвращения массива в нормальную эксплуатацию.
Часто задаваемые вопросы
ddrescue -d -r3 /dev/sdXp1 /path/to/image.img /path/to/map.log. После получения образа запускайте восстановление по файлу образа, а не по живому диску — xfs_repair /path/to/image.img. Если восстановление даст хуже ожидаемый результат, у вас останется исходная посекторная копия для дальнейшей работы. Единственное ограничение: диск‑приёмник для образа должен быть достаточно большим, чтобы вместить полный необработанный (raw) размер исходного раздела, а не только занимаемое на нём пространство.
/lost+found и переименовывает их по номеру inode. Если вы помните примерный размер файлов, дату создания или тип содержимого, можно сузить круг кандидатов с помощью stat для проверки метаданных inode и file для определения типа по заголовку файла — file /mnt/diskX/lost+found/123456789 подскажет, содержит ли inode JPEG, видеоконтейнер, сжатый архив и т. п. Для медиафайлов большинство можно опознать и переименовать по содержимому. Для баз данных или данных приложений без читаемого заголовка идентификация сложнее и может потребовать сравнения размеров файлов с заведомо корректными резервными копиями или анализа логов приложения, где могли фиксироваться исходные имена файлов.
