Внешний жесткий диск (3 ТБ) поврежден - возможно, повреждена таблица разделов

Question

У меня есть жесткий диск LaCie (3 ТБ), который я не могу смонтировать, потому что, по мнению дисковой утилиты, возникают проблемы с таблицей разделов. Я на маке (Сьерра, в курсе). Дисковая утилита не может восстановить его, но в нем перечислены жесткие диски. При попытке восстановления дисковая утилита говорит: «Восстановление поврежденной таблицы разделов. Операция не может быть завершена (com.apple.Ошибка управления диском -69874.) Операция не удалась..."

В Дисковой утилите это указано как:
ST3000DM 001-1CH166 Носитель, 3 ТБ, не инициализирован
Расположение: внешний
Подключение: USB
Таблица разделов: не поддерживается
SMART-статус: не поддерживается
Емкость: 3 ТБ
Количество подразделов: 0
Тип: Диск. Устройство: диск2

Сам диск отформатирован как Mac Journaled (GUID). Мои другие жесткие диски имеют 2 раздела (в соответствии с тестовым диском на поврежденном диске есть раздел Linux [L] & LBA [E]). Пробовал быстрый поиск и глубокий поиск на тестовом диске (там говорилось что-то вроде файловой системы в порядке, таблица разделов повреждена. Хотя точно не знаю).
Использовал testdisk для записи таблицы разделов, но это ничего не изменило. Я не решаюсь просто нажимать некоторые параметры на тестовом диске, так как я не хочу больше повреждать свои файлы и не знаю, что делают все эти параметры.

На диске есть данные, которые мне действительно нужны (когда я обнаружил, что он поврежден, я просто хотел скопировать данные на другой жесткий диск… ирония, не правда ли?), Так что было бы здорово, если бы я мог получить его , Файлы на нем в основном.PNG,.JPEG,.PSD а.CR2, некоторые форматы видео и старые / мобильные форматы изображений тоже. Думаю, на нем есть резервная копия машины времени.

Что я должен делать? Есть ли другой вариант с teskdisk или photorec?

PS: Да, я знаю, резервное копирование.
PPS: Я пытался связаться со специализированными компаниями, но эти услуги слишком дороги для такого студента, как я. В настоящее время выполняется демонстрация Data Rescue 4, чтобы проверить, что можно восстановить, но слышал, что подобное программное обеспечение не может вернуть вам файлы, такие как .psd, и, поскольку это слишком дорого, я не решаюсь заплатить так много за что-то, если он не может восстановить большинство моих файлов.

Testdisk записал новую таблицу разделов после анализа, а также GParted, но оба они не сработали. Слышал о photorec, но вернет ли он мне все файлы, которые у меня есть, или только файлы с определенными расширениями?

Answer 1

Это, очевидно, USB-накопитель, и USB-подключения иногда бывают ненадежными и изношенными, в качестве начала вы пробовали новые USB-кабели и другой порт, даже на другом компьютере с известными хорошими USB-подключениями?

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

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

Я думаю, что osx достаточно похож на linux, чтобы иметь программу dd , поэтому такая команда "копировать весь диск" должна работать так:

dd if=[original disk drive] of=/path/to/new/backup/file bs=10M

Где, if= - это файл для чтения ("в файле"), а of= - это место для записи ("в файл") - НЕ СМЕШАТЬ ИХ! bs= означает чтение и запись 10 Мбайт за раз, иногда по умолчанию используется 512 байт, что может привести к очень медленному прогрессу, 10 Мбайт (мегабайт) должны идти с хорошей скоростью.

Если на диске возникают аппаратные ошибки, может произойти сбой dd , поэтому лучше использовать gddrescue / "GNU ddrescue" , например, пропустить "плохие" или медленные сектора, попробовать прочитать "назад", начать заново с того места, где он оставил выкл, у него есть хороший пакет хитростей для проблемных поездок. Я просто не уверен, доступен ли он изначально для OS X, но запуск его с живого Linux будет работать.

После этого вы можете безопасно отключить и сохранить исходный диск на тот случай, если вы не сможете восстановить свои файлы, одновременно пробуя testdisk/photorec и все виды демонстрационных / пробных программ "профессионального восстановления" на копии диска. Testdisk должен работать, и если нет, PhotoRec очень хорош в восстановлении файлов, но не имеет имен файлов или структуры каталогов, они тоже бесплатны, так что это отличное место для старта, с хорошей документацией и практическими рекомендациями на их сайте http:// www .cgsecurity.org / вики / TestDisk

Answer 2

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

Все предлагали проанализировать диск с помощью testdisk.

Что делает анализ:

Анализирует текущую структуру разделов диска и находит разделы, что позволяет восстановить потерянные разделы.

В нашем случае проблема заключалась не в том, что мы пропустили разделы, а в том, что к разделам, которые были там, не было доступа.

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

Мы проанализировали диск с помощью testdisk несколько раз, с различными вариантами для типа таблицы разделов (первоначально мы не знали тип, но в конце концов это был EFI GPT), надеясь, что testdisk сможет найти какой-то проблемы с таблицей разделов, которые она может восстановить, чтобы мы могли снова получить доступ к данным. Мы позволили ему переписать таблицу разделов после анализа несколько раз, но это никогда не помогало.

---

До того, как попробовать различные потенциальные решения, о которых мы еще не знали, мы решили не рисковать, купили новый жесткий диск объемом 3 ТБ и клонировали старый на него.

Странная вещь, которую мы заметили, заключалась в том, что, когда мы анализировали клон, тестдиску потребовалось всего около секунды, чтобы отобразить результаты, тогда как для старого он занимал много-много часов. Также было бы сказано, что он определил тип таблицы разделов как EFI GPT. Старый был обнаружен как Linux и как минимум еще один тип, но не EFI GPT.

Это заставило нас подумать, что вполне возможно, что что-то не так с оригинальным диском, связанным с оборудованием. Мы подумали, как клон может вести себя иначе, чем оригинал, если его нет?

---

Так что все казалось правильным, но этот новый диск тоже не мог быть смонтирован. Было бы сказать

wrong fs type, bad option, bad superblock on /dev/sdb,  
missing codepage or helper program, or other error  
In some cases useful info is found in syslog - try  
dmesg | tail  or so

и Dmesg сказал бы

hfs: unable to find HFS+ superblock

Об этой ошибке сообщалось слева и справа, даже здесь, на SU, но ни одно из предложенных решений (например, "указать размер и смещение при монтаже") не помогло нам.

В поисках подсказок мы нашли опцию в расширенном меню testdisk под названием "Суперблок" или что-то подобное.

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

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

После перезагрузки ubuntu показала диск в панели запуска (первый раз, когда он это сделал), и при щелчке по нему он успешно смонтировался, что позволило нам прочитать данные. ☺