Сначала определите свою ситуацию

Прежде чем продолжить, воспользуйтесь этой таблицей, чтобы найти свой конкретный сценарий и сразу перейти к нужному разделу:

Почему два сбоя математически разрушают SHR-1

SHR-1 использует один набор паритетных данных — по сути, это эквивалент RAID 5 с точки зрения отказоустойчивости. Для каждой полосы (stripe) в массиве один диск хранит XOR-паритет остальных. При отказе одного диска любой отсутствующий блок данных можно вычислить заново: нужно взять блок паритета и выполнить XOR со всеми оставшимися блоками данных — в результате отсутствующее значение восстанавливается. Это работает, потому что есть одна неизвестная величина и одно уравнение.

При отказе двух дисков в каждой полосе уже две неизвестные, а уравнение паритета по-прежнему одно. Математического решения нет. Ни одно программное средство, как бы его ни рекламировали, не способно восстановить два независимо неизвестных значения из одной XOR-связи. Это не ограничение конкретного инструмента — это свойство самой схемы паритета.

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

Примечание о SHR-2

SHR-2 хранит два независимых набора паритета в каждой полосе — аналогично RAID 6 — и выдерживает любые два одновременных отказа дисков без потери данных. Однако SHR-2 не застрахован от этого сценария: три одновременных отказа нарушают математику паритета так же, как два отказа нарушают SHR-1. Если вы используете SHR-2 и потеряли три диска, применима та же логика, что и ниже. Для сравнения отказоустойчивости SHR-1 и SHR-2 на практике см. нашу статью о восстановлении SHR/SHR-2 после аппаратного сбоя Synology.

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

Не все двойные отказы одинаковы. Последовательность и характер сбоев определяют, какое восстановление возможно:

Одновременный отказ — сбой питания или контроллера

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

Второй диск вышел из строя во время восстановления

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

Первый диск отказал давно и остался незамеченным

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

Оцените физическое состояние каждого диска

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

Для дисков, которые включаются без посторонних звуков, выполните mdadm --examine для каждого раздела устройства:

	mdadm --examine /dev/sdb3
	          Magic : a92b4efc
	        Version : 1.2
	    Feature Map : 0x0
	     Array UUID : 4b2f8e1a:7c3d9f02:1a4b8c3d:9e2f7b01
	           Name : DiskStation:2
	  Creation Time : Fri Mar 10 14:22:31 2023
	     Raid Level : raid5
	   Raid Devices : 3
	 Avail Dev Size : 7813959680
	     Array Size : 15627862016
	  Used Dev Size : 7813931008
	    Data Offset : 2048 sectors
	   Super Offset : 8 sectors
	   Unused Space : before=1968 sectors, after=0 sectors
	          State : clean, degraded
	
	    Device UUID : 9d3f1c2a:4e8b7f03:2c1d9e4b:7a3f8c01
	    Update Time : Mon Jun  2 09:14:22 2025
	  Bad Block Log : 512 entries available at offset 16 sectors
	       Checksum : 3f8a1b2c - correct
	         Events : 247

Обратите внимание на три момента: UUID массива должен совпадать на всех дисках — если это не так, значит диск относится к другому массиву либо его суперблок повреждён. Счётчик Events должен быть примерно одинаковым у всех участников массива — существенное расхождение указывает на то, что один из дисков пропустил значительное число операций записи. Поле State на диске, который был частью массива и потерял одного из участников, будет отображаться как clean, degraded.

Также на этом этапе откройте встроенный монитор S.M.A.R.T. в RS RAID Retrieve. Показатели Reallocated Sector Count и Pending Sectors на уцелевшем диске имеют значение: диск, у которого в уже деградировавшем массиве накапливаются сбойные сектора, мог выдавать тихие ошибки чтения, повлиявшие на целостность данных ещё до второй поломки. Для справки по интерпретации данных S.M.A.R.T. см. нашу статью о признаках отказа жёсткого диска.

Три уровня восстановления

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

Сложность:

Низкая

Используйте этот путь только если mdadm --examine возвращает корректные суперблоки с совпадающими UUID на всех дисках. Работа через терминал дает вам полный контроль над каждым шагом, но имеет жесткие ограничения: все диски должны быть физически доступны и читаемы, при повреждении суперблоков нет запасного варианта, и заранее невозможно определить, какие файлы повреждены. Перед выполнением любых команд ниже создайте образ каждого диска с помощью ddrescue — работайте только с образами.

	# Установите ddrescue, если он не установлен
	apt-get install -y gddrescue
	# Создайте образ каждого диска в отдельный файл — выполните для каждого участника массива
	ddrescue -d -r3 /dev/sdb /mnt/images/sdb.img /mnt/images/sdb.log
	ddrescue -d -r3 /dev/sdc /mnt/images/sdc.img /mnt/images/sdc.log
	ddrescue -d -r3 /dev/sdd /mnt/images/sdd.img /mnt/images/sdd.log
        

		# Запустите для каждого образа — убедитесь, что UUID и Events совпадают
		mdadm --examine /mnt/images/sdb.img
		mdadm --examine /mnt/images/sdc.img
		mdadm --examine /mnt/images/sdd.img
        

	# Сообщаем ядру, что файлы-образы следует воспринимать как блочные устройства
	losetup /dev/loop0 /mnt/images/sdb.img
	losetup /dev/loop1 /mnt/images/sdc.img
	losetup /dev/loop2 /mnt/images/sdd.img
	# Принудительно собираем массив — указываем разделы с данными, а не всё устройство целиком
	mdadm --assemble --force /dev/md0 /dev/loop0p3 /dev/loop1p3 /dev/loop2p3
	# Проверяем результат сборки
	cat /proc/mdstat
	mdadm --detail /dev/md0
        

	# Активируйте группу томов LVM на собранном массиве
	pvscan
	vgchange -ay
	# Выведите список логических томов, чтобы определить правильный путь к устройству
	lvs
	# Монтируйте только для чтения — никогда не монтируйте rw на повреждённом массиве
	mount /dev/vg1/volume_1 /mnt/data -o ro
        

	# Используйте rsync с логированием ошибок — пропускает нечитаемые файлы, а не останавливается
	rsync -av --ignore-errors /mnt/data/ /mnt/destination/ 2>&1 | tee /mnt/rsync.log
	# Проверьте, что было пропущено
	grep -i "error|failed|cannot" /mnt/rsync.log
        

Уровень 2 RS RAID Retrieve — автоматическое обнаружение и ручная реконструкция

Сложность:

Низкая

RS RAID Retrieve выполняет весь процесс — анализ S.M.A.R.T., создание образов дисков, реконструкцию массива, активацию LVM и доступ к файловой системе — в одном приложении для Windows, Linux или macOS. Оно поддерживает два различных сценария реконструкции в зависимости от состояния суперблоков mdadm.

Уровень 3 Физическое восстановление в лаборатории — механически повреждённые накопители

Сложность:

Низкая

Программное восстановление — на любом уровне — зависит от того, могут ли головки чтения/записи накопителя передавать данные секторов контроллеру хоста. Если блок головок механически повреждён, привод катушки голосовой системы заклинил или вышел из строя подшипник шпинделя, накопитель не сможет выполнять запросы на чтение независимо от настроек программного обеспечения. В лаборатории блок головок заменяют в чистой комнате (ISO Class 5 или выше), выполняют юстировку головок под конкретный плавающий диск и используют инструменты на уровне прошивки, чтобы извлечь данные секторов из областей, которые собственная электроника накопителя отказалась бы читать.

Результатом работы лаборатории является набор образов на уровне секторов — по одному на каждый диск. Эти образы содержат максимально возможное чтение поверхности каждого накопителя, включая секторы, восстановленные из физически повреждённых зон, которые при обычных условиях вызывают ошибки ввода-вывода. После получения эти образы используются напрямую в RS RAID Retrieve: RAID Constructor считывает суперблоки (или применяет метод смещения LABLEONE, если суперблоки повреждены), восстанавливает топологию массива SHR и затем выполняет сканирование файловой системы и восстановление точно так же, как описано в Уровне 2.

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

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

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

Содержание

1. Восстановление USB‑флешки: краткое руководство с быстрыми решениями
2. Понимание причин, по которым файлы исчезают с USB-накопителей
3. Метод 1: Восстановление файлов с помощью ПО для восстановления данных с USB-накопителя
   • Как работает ПО для восстановления данных
   • Пошаговое восстановление с помощью RS Partition Recovery
   • Советы для успешного восстановления
4. Метод 2: Проверьте Корзину на Mac
   • Как корзина macOS работает с USB-накопителями
   • Пошаговое восстановление из Корзины
5. Метод 3: Восстановление скрытых файлов на USB-накопителе
   • Почему файлы становятся скрытыми
     • Отображение скрытых файлов
     • Проверка скрытых системных файлов
6. Почему некоторые файлы нельзя восстановить
7. Предотвращение потери данных на USB‑флешке

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

Восстановление USB‑флешки: краткое руководство с быстрыми решениями

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

Почему это важно: при удалении файла с USB данные сразу не стираются. macOS просто помечает пространство, которое занимал файл, как «доступное для новых данных». Содержимое файла остаётся на диске, пока его не перезапишут новые данные. Каждый раз при копировании файлов на флешку, при съёмке фото или сохранении документов вы рискуете перезаписать удалённые данные, которые пытаетесь восстановить.

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

Понимание причин, по которым файлы исчезают с USB-накопителей

Прежде чем переходить к методам восстановления, важно понять распространённые причины потери данных на USB. Знание того, что спровоцировало потерю данных, поможет выбрать наиболее эффективный способ восстановления и предотвратить похожие инциденты в будущем. Если вы сталкиваетесь с потерей данных на съёмных носителях, понимание этих причин особенно важно.

Случайное удаление или форматирование

Наиболее частая причина потери данных на USB — человеческая ошибка. Один неверный клик может удалить важные файлы, или вы можете отформатировать не тот диск, пытаясь освободить место. Возможно, вы сортировали файлы поздно вечером и по ошибке выбрали «Удалить» вместо «Копировать», либо отформатировали USB-накопитель, полагая, что данные сохранены в другом месте, а на самом деле это не так.

Вирусы и вредоносное ПО

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

Неправильное извлечение USB

Одна из часто недооцениваемых причин потери данных — неправильное извлечение. Если просто вытащить флешку, не используя функцию «Извлечь» на вашем Mac, вы рискуете прервать активные операции чтения/записи. macOS может в этот момент обновлять информацию о файловой системе или завершать фоновую операцию сохранения. Это может привести к повреждению данных на горячесменяемых устройств.

Физическое повреждение

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

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

Файловая система — это как подробная карта, которая указывает macOS, где на накопителе хранятся файлы. Различные факторы могут повредить эту карту: резкое отключение питания во время передачи файлов, неожиданное отключение устройства, ошибки в программном обеспечении или конфликты между разными операционными системами. При возникновении ошибок файловой системы RAW ваш Mac может не суметь найти файлы, хотя физически они всё ещё находятся на накопителе.

Скрытые файлы

Иногда файлы фактически не исчезают — они просто становятся скрытыми. Такое может произойти случайно из‑за команд в Terminal, в результате действия вредоносного ПО, которое меняет атрибуты файлов, или из‑за системных ошибок. macOS по умолчанию скрывает некоторые системные файлы, и иногда пользовательские файлы тоже могут оказаться скрытыми из‑за различных сбоев.

Метод 1: Восстановление файлов с помощью ПО для восстановления данных с USB-накопителя

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

Как работает ПО для восстановления данных

ПО для восстановления данных на Mac работает за счёт глубокого посекторного сканирования вашего USB-накопителя. В отличие от обычного просмотра файлов на Mac, который опирается на индекс файловой системы, такое ПО просматривает каждый сектор диска в поисках следов удалённых файлов. Оно умеет распознавать сигнатуры файлов, восстанавливать структуру файлов и извлекать данные даже при повреждённой или отформатированной файловой системе. Узнайте больше о технологии извлечения данных (data carving).

Пошаговое восстановление с помощью RS Partition Recovery

RS Partition Recovery — это универсальное решение для восстановления данных, эффективно работающее с USB‑флешками на Mac. Ниже описано, как с его помощью вернуть потерянные файлы:

Шаг 1: Скачайте и установите RS Partition Recovery

RS Partition Recovery

Универсальное решение для восстановления данных

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

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

Шаг 2: Подключите USB‑флешку

Подключите USB‑флешку к Mac через свободный USB‑порт. Убедитесь, что соединение надёжно. Подождите, пока Mac распознает устройство. Если флешка выглядит повреждённой или не монтируется автоматически — не переживайте: RS Partition Recovery зачастую всё равно может обнаружить и просканировать её.

Шаг 3: Выберите ваш USB‑накопитель

При запуске RS Partition Recovery вы увидите список всех подключённых к Mac накопителей. Найдите в списке вашу флешку — обычно устройства отображаются по имени, объёму и типу файловой системы (например, FAT32, exFAT, APFS, HFS+). Кликните по вашей флешке, чтобы её выбрать.

Шаг 4: Выберите тип сканирования

RS Partition Recovery предлагает несколько вариантов сканирования:

Quick Scan: Быстрое сканирование, которое ищет недавно удалённые файлы, легко поддающиеся восстановлению. Оно анализирует индекс файловой системы и может вернуть файлы, удалённые стандартным способом. Как правило занимает всего несколько минут.

Full Analysis: Глубокий посекторный анализ всего диска. Находит файлы, которые мог пропустить Quick Scan, включая данные с форматированных дисков, повреждённых разделов или серьёзно повреждённых файловых систем. Такое сканирование занимает больше времени (от 10 минут до нескольких часов в зависимости от объёма накопителя), но обнаруживает значительно больше восстанавливаемых файлов.

В большинстве случаев начните с Quick Scan. Если нужные файлы не найдены — запустите Full Analysis.

Шаг 5: Подождите завершения сканирования

Во время сканирования RS Partition Recovery показывает ход выполнения, указывая, какая часть диска уже проанализирована. В реальном времени отображается количество найденных файлов.

Шаг 6: Просмотрите найденные файлы

После завершения (или даже в процессе сканирования) вы можете просматривать найденные файлы. RS Partition Recovery организует результаты несколькими способами:

• По типу файла: фото, документы, видео, архивы и т.д.
• По исходной структуре папок: если информация файловой системы сохранена
• По статусу файла: существующие файлы vs удалённые/потерянные

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

Шаг 7: Выберите файлы для восстановления

Отметьте галочками файлы и папки, которые хотите восстановить. Вы можете:

• Выбирать отдельные файлы, отмечая их галочками
• Выбирать целые папки, чтобы восстановить всё их содержимое
• Использовать «Select All», чтобы восстановить все найденные файлы
• Использовать Command+Click (Cmd+клик), чтобы выбрать несколько несмежных файлов

Шаг 8: Выберите место для сохранения восстановленных файлов

После того как выбрали файлы, нажмите кнопку «Recover». Появится диалог, в котором нужно указать папку для сохранения восстановленных данных.

Критическое предупреждение: Никогда не восстанавливайте файлы обратно на ту же самую USB‑флешку, с которой выполняется восстановление. Всегда выбирайте другое место для сохранения — например, внутренний диск Mac или другой внешний накопитель. Восстановление на ту же флешку может перезаписать другие ещё не восстановленные данные и привести к их безвозвратной потере.

Шаг 9: Завершите восстановление

Нажмите «Далее», чтобы начать процесс восстановления. RS Partition Recovery скопирует выбранные файлы в указанное место. Время восстановления зависит от количества и объёма файлов. После завершения откройте папку с восстановленными файлами, чтобы убедиться, что всё в порядке.

Советы для успешного восстановления

Повысьте вероятность успешного восстановления с помощью этих рекомендаций:

• Не устанавливайте программу восстановления на сам USB-накопитель. Установите её на внутренний диск Mac или на другой внешний диск.
• Восстанавливайте файлы как можно скорее. Чем дольше откладывать, тем выше риск перезаписи данных.
• Если первый скан не нашёл ваши файлы, попробуйте режим полного/глубокого сканирования. Быстрое сканирование работает быстрее, но менее тщательно.
• Тщательно проверяйте предварительный просмотр файлов. Найденный файл не обязательно цел — предварительный просмотр помогает оценить, можно ли его восстановить.
• Сразу же организуйте восстановленные файлы. Восстановленные файлы часто теряют оригинальные имена и получают общие названия (например, «File001.jpg»), поэтому разберите их сразу, пока помните, что к чему относится.

Метод 2: Проверьте Корзину на Mac

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

Как корзина macOS работает с USB-накопителями

Ваш Mac по-разному обрабатывает удалённые файлы на внешних носителях и во встроенном хранилище. Когда вы удаляете файлы с USB‑флешки, они помещаются в скрытую папку .Trashes на самом носителе. Значок Корзины в Dock собирает и отображает элементы со всех подключённых дисков, из-за чего создаётся впечатление единой централизованной корзины, хотя на самом деле её нет.

Важное замечание: Чтобы увидеть файлы, удалённые с USB‑накопителя, он должен быть подключён к Mac. Если вы удалили файлы со флешки вчера и отключили её, эти файлы не появятся в вашей Корзине, пока вы не подключите накопитель снова.

Пошаговое восстановление из Корзины

1. Подключите USB-накопитель к вашему Mac, если он ещё не подключён.
2. Откройте Корзину, щёлкнув по её значку в Dock (справа или внизу экрана, в зависимости от положения Dock).
3. Найдите нужные файлы. Просмотрите содержимое Корзины, чтобы отыскать файлы для восстановления. Если в Корзине много элементов, используйте поле поиска в правом верхнем углу или сортировку по дате удаления для ускорения поиска.
4. Восстановите файлы. Щёлкните правой кнопкой мыши (или Control+клик) по файлу, который хотите вернуть, и выберите «Put Back». Файл автоматически вернётся в исходную папку на вашем USB-накопителе. Для выбора нескольких файлов удерживайте Command при клике по каждому элементу.

Прямой доступ к скрытой папке .Trashes

Опытные пользователи могут напрямую открыть папку .Trashes на USB-накопителе. Это полезно, если стандартное восстановление из Корзины не срабатывает или если вы хотите проверить, что именно хранится на диске.

Чтобы показать скрытые файлы и папки:

Нажмите Command + Shift + . (точка) в Finder при открытом окне вашего USB-накопителя. Скрытые файлы и папки отобразятся полупрозрачными. Найдите папку .Trashes и откройте её, чтобы просмотреть удалённые файлы.

Чтобы снова скрыть скрытые файлы:

Нажмите Command + Shift + . (точка) ещё раз, чтобы отключить отображение скрытых файлов. Рекомендуется снова скрыть системные файлы после завершения работы — случайное изменение или удаление скрытых системных файлов может привести к проблемам.

Использование Terminal для расширенного доступа

Если вы уверенно работаете с командами в Terminal, вы получите более точный контроль при работе с папкой .Trashes:

1. Откройте Terminal (нажмите Command + Space, введите «Terminal» и нажмите Enter).
2. Перейдите в каталог USB-накопителя, введя:

    cd /Volumes/YOUR_DRIVE_NAME

   Замените YOUR_DRIVE_NAME на реальное имя вашего USB-накопителя.
3. Выведите содержимое папки .Trashes:

   ls -la .Trashes

Этот метод требует предоставления Terminal полного доступа к диску в Системные настройки → Безопасность и конфиденциальность → Конфиденциальность → Полный доступ к диску.

Метод 3: Восстановление скрытых файлов на USB-накопителе

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

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

Файлы на вашем USB‑накопителе могут стать скрытыми по нескольким причинам:

• Команды в терминале: Случайный запуск команд, например chflags hidden, может скрыть файлы
• Вредоносное ПО: Некоторые злоумышленнические программы скрывают файлы в рамках своей работы
• Системные ошибки: Сбои при операциях с файлами могут непреднамеренно установить атрибут «скрытый»
• Кроссплатформенные проблемы: Перемещение диска между macOS и Windows иногда вызывает проблемы с отображением файлов

Отображение скрытых файлов

Метод 1: Быстрое переключение сочетанием клавиш

Это самый быстрый способ посмотреть скрытые файлы на USB‑накопителе:

1. Подключите свой USB‑накопитель к Mac
2. Откройте Finder и перейдите на ваш USB‑накопитель
3. Одновременно нажмите Command + Shift + . (точка)
4. Скрытые файлы и папки станут полупрозрачными в Finder
5. Повторно нажмите то же сочетание клавиш, чтобы снова скрыть их

Постоянное снятие скрытости через Terminal

Если вы хотите навсегда убрать атрибут скрытости с отдельных файлов:

1. Откройте Terminal (Приложения → Служебные программы → Terminal, либо нажмите Command + Space и введите «Terminal»)
2. Введите команду для снятия скрытости, но пока не нажимайте Enter:

   chflags nohidden

   Обратите внимание: после «nohidden» должен быть пробел
3. Перетащите скрытый файл из Finder прямо в окно Terminal — путь к файлу вставится автоматически.
4. Нажмите Enter, чтобы выполнить команду. Файл теперь навсегда станет видимым.
5. Повторите для каждого файла, который нужно сделать видимым, или снимайте скрытость с целых папок тем же способом.

Пример команды:

chflags nohidden /Volumes/MyUSB/HiddenFolder

Проверка скрытых системных файлов

На вашем USB-накопителе могут находиться скрытые системные файлы, такие как .DS_Store, .Spotlight-V100 или .Trashes. Это обычные файлы и папки macOS. Не удаляйте их, если вы не уверены, что они не нужны — они помогают macOS корректно управлять диском.

Почему некоторые файлы нельзя восстановить

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

Перезапись данных

Основная причина безвозвратной потери файлов — перезапись. Помните: удалённые файлы не стираются мгновенно — им просто помечается место как «доступное». Как только в эти сектора записываются новые данные, исходный файл окончательно теряется. Это похоже на запись поверх кассеты или видеокассеты VHS — после замены старого материала новым возврата нет.

Чем больше вы используете USB‑накопитель после потери данных, тем выше вероятность перезаписи. Даже действия, кажущиеся безобидными — например, просмотр содержимого диска или запись скрытых системных файлов macOS — могут перезаписать удалённые данные.

Серьёзные физические повреждения

Если микросхемы памяти внутри USB‑накопителя физически разрушены, никакое программное обеспечение не сможет восстановить данные. К физическим повреждениям относятся электрические пробои от перепадов напряжения, повреждение водой и коррозия цепей, механическое разрушение при сдавливании, термическое повреждение при пожаре или износ вследствие большого количества циклов чтения/записи. При повреждённом накопителе стоит ознакомиться с материалами по восстановлению данных с неисправных дисков.

Шифрование и средства защиты

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

Полное разрушение файловой системы

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

Время со дня удаления

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

Предотвращение потери данных на USB‑флешке

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

Основные стратегии профилактики

1. Всегда корректно извлекайте USB‑накопители

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

2. Регулярно делайте резервные копии

Не полагайтесь на USB‑накопитель как на единственную копию важных данных. Для пользователей Mac Time Machine может делать резервные копии внешних дисков вместе с внутренним хранилищем. Включите эту функцию в System Preferences → Time Machine.

3. Регулярно проверяйте накопитель на наличие вредоносного ПО

USB‑накопители часто служат каналами распространения вредоносного ПО.

4. Обращайтесь с USB‑накопителями аккуратно

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

5. Чётко маркируйте накопители: предотвращайте случайное форматирование или удаление

6. Включайте защиту от записи, когда это возможно

Некоторые USB‑накопители имеют физический переключатель защиты от записи. Когда на накопителе находятся важные данные и вы только читаете их (не добавляете и не изменяете файлы), включите защиту от записи. Это предотвращает случайное удаление или изменение файлов на накопителе.

7. Следите за состоянием накопителя

Периодически проверяйте состояние носителя (SMART‑данные, ошибки файловой системы) с помощью специальных утилит и обращайте внимание на признаки деградации.

8. Не переполняйте USB‑накопитель

Полное заполнение накопителя увеличивает риск ошибок и повреждения данных. Старайтесь оставлять свободными как минимум 10–15% объёма для оптимальной производительности и надёжности.

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

Когда процесс 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 без предварительного восстановления серверной среды.