Прежде всего, не делайте больше ничего на диске (по крайней мере, никогда не пишите на него). Диск, который не был распознан (в отличие от «быть распознанным и найденным пустым или с нечитаемыми данными»), похоже, указывает либо на полностью очищенный диск, что chkdskобычно не происходит, либо что-то не так с таблицей разделов или геометрией диска или как USB-корпус справляется с этим. Аппаратный сбой также возможен.
Это может произойти и произойдет, когда USB-корпуса попытаются договориться между диском и компьютером, к которому они подключены. Поэтому первое, что нужно сделать, - это взять образ диска на (очевидно больший) диск как можно ближе к физическому уровню, используя ddLinux. После этого вы можете возиться с копией изображения в свое удовольствие, без риска дальнейшего повреждения реального диска.
Обновление: распознавание устройства в Linux
На нашем «внешнем диске» есть не менее трех объектов. Аппаратное обеспечение корпуса USB, представленное как блочное устройство. Физический диск внутри корпуса. Физическое устройство, т. Е. Последовательность секторов LBA от первого до последнего. И, наконец, ноль или более разделов данных, содержащих файловые системы. Чтобы быть «распознанными» и отображаться на рабочем столе, все звенья цепочек должны работать. Но чтобы сделать снимок физического устройства, вам нужны только первые два. Если вы подключите устройство и запустите командную строку dmesg(от имени пользователя root), вы должны увидеть что-то вроде этого:
[4984939.028491] usb 8-6: new high speed USB device using ehci_hcd and address 3
[4984939.166658] usb 8-6: configuration #1 chosen from 1 choice
[4984939.170660] scsi7 : SCSI emulation for USB Mass Storage devices
[4984939.172003] usb-storage: device found at 3
[4984939.172005] usb-storage: waiting for device to settle before scanning
... который является приложением, распознаваемым, и затем идентифицирующим себя и его содержание:
[4984939.170660] usb 8-6: New USB device found, idVendor=1058, idProduct=1021
[4984939.170660] usb 8-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4984939.170660] usb 8-6: Product: Ext HDD 1021
[4984939.170660] usb 8-6: Manufacturer: Western Digital
[4984939.170660] usb 8-6: SerialNumber: 574D43305431303831303734
[4984944.400970] usb-storage: device scan complete
Далее вы увидите драйвер, информирующий о его геометрии, природе и неявно его узле устройства, здесь sdd(для SCSI Disk Four, так как sda, sdbи sdcуже были заняты):
[4984944.404739] scsi 7:0:0:0: Direct-Access WD Ext HDD 1021 2021 PQ: 0 ANSI: 4
[4984944.404739] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)
[4984944.407367] sd 7:0:0:0: [sdd] Write Protect is off
[4984944.407369] sd 7:0:0:0: [sdd] Mode Sense: 17 00 10 08
[4984944.407371] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[4984944.408741] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)
Затем ядро распознает, что есть раздел (если вы этого не видите, раздела нет или он недействителен):
[4984944.411497] sdd: sdd1
Теперь в Linux есть все, что нужно, и сообщает об успешном вложении
[4984944.416739] sd 7:0:0:0: [sdd] Attached SCSI disk
[4984944.416739] sd 7:0:0:0: Attached scsi generic sg4 type 0
И так начинается поиск раздела данных, т.е. хорошо, у нас есть sdd1, но что там? и ответ:
[4984997.498613] NTFS driver 2.1.29 [Flags: R/W MODULE].
[4984997.554613] NTFS volume version 3.1.
[4984997.568859] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean. Mounting read-only. Mount in Windows.
[4985390.027808] NTFS-fs error (device sdd1): ntfs_remount(): Volume has errors and is read-only. Cannot remount read-write.
[4985442.423299] NTFS volume version 3.1.
[4985442.425032] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean. Mounting read-only. Mount in Windows.
Это выше было "хорошее" крепление. Но просто зная, что устройство sddили, sdcили sdb, позволяет мне сделать двоичную копию (при условии, что у меня достаточно свободного места /mnt/backupdisk): входной файл /dev/sdd, выходной файл DiskImage.raw, размер блока 1 МБ :
# dd if=/dev/sdd of=/mnt/backupdisk/DiskImage.raw bs=1M
Обратите внимание, что входным файлом является /dev/sdd и нет /dev/sdd1
(или любой другой номер). Теперь, если бы я захотел, я мог бы узнать смещение внутри раздела данных DiskImage.rawи смонтировать его с помощью петлевого устройства. Здесь вы найдете грязные детали.
Первая попытка восстановления
Второе, что нужно сделать, - это поместить физический диск в другой корпус, тем самым обеспечив его исправность и получив шанс, что новый корпус правильно интерпретирует диск. Если диск появится снова, возможно, сломался предыдущий корпус. На всякий случай сделайте резервную копию всего содержимого вновь найденного диска, проверьте резервную копию, обнулите диск с помощью утилиты перезаписи диска, чтобы он стал полностью тупым (у вас не может быть двух устройств с разными мнениями в цепочке устройств), переформатируйте его изначально из винды и восстановления данных. Это удачный выстрел, но я видел, как это произошло; и попытка не слишком дорогая, хорошие корпуса стоят около 19,99 долларов США новые.
В случае, если исходный корпус был плохим, вы не сможете переформатировать диск, или диск не будет доступен. Вы можете повторить новый корпус, и если она работает, либо заменить старый корпус, или продолжать использовать новый (но это имеет смысл , если новый корпус является довольно лучше , чем US $ 19.99 Эль дешевка).
Профессиональное восстановление
Профессиональные услуги восстановления, те, которые вы можете найти с помощью Google. Не слишком честный способ сделать это - переслать через физический диск, и - если вы получили «Да, аппаратного повреждения нет, мы можем восстановить все ваши данные всего за US $ $$$, $ $$!» ответ - ну, тогда вы бы знали, что данные все еще можно восстановить. Таким образом, вы можете попытаться сделать это самостоятельно бесплатно на резервной копии образа, которую вы взяли, и заплатить только за диагностику и диск S & H. Если вы потерпели неудачу, вариант выкашливания запрошенного теста все равно останется. Если есть повреждения оборудования, профессиональное обслуживание в основном ваш единственный вариант. Существует несколько уловок вуду, которые (временно) восстанавливают «мертвый» диск, часто достаточно длинный, чтобы хотя бы восстановить наиболее важные данные,ни один, который гарантированно не будет работать каждый раз (нагревание диска, его охлаждение, «закручивание» его - я даже видел, как предлагалось ловко стучать по нему о твердую поверхность). Все они нанесут больший урон, т. Е. Вы должны обязательно использовать один трюк, который сработает в первый раз, иначе вы убьете диск навсегда. Я просто добавил это , чтобы объяснить , почему вы увидите истории успеха о возрожденных дисках: есть есть такие истории. Но если вы хотите быть (в основном) уверены, что это случится с вами , хорошо - наймите профессионала.
Если вы уверены, что с оборудованием все в порядке - вращение диска, отсутствие дребезжания, никаких странных звуков или гудений, никаких перекалибровок с щелчками - все, что произошло, это chkdskиспортило некоторые данные.
DIY восстановление
«Домашнее» восстановление обычно происходит следующим образом (в основном то же самое, что делают профессиональные парни после устранения повреждения оборудования), работая с копией образа диска:
проверьте, является ли первый сектор образа диска допустимой таблицей разделов. Если нет, отсканируйте образ диска в поисках действительной таблицы разделов или распознаваемого загрузочного сектора NTFS или FAT32, в зависимости от того, какая FS была на устройстве (для устройства объемом 1 ТБ NTFS кажется единственной логической возможностью). В любом случае вы должны найти что-то в пределах первых нескольких мегабайт.
если таблица разделов найдена, убедитесь, что раздел данных находится там, где таблица разделов говорит, что он должен быть. Если это не так, это очень хорошая новость: вероятно, таблица разделов - это все, что не так. Исправить это легко (это сделают несколько редакторов разделов Linux), и можно ожидать, что диск восстановится на 100%. Просто чтобы быть в безопасности, попробуйте смонтировать раздел данных в Linux с помощью петлевого устройства в режиме только для чтения, чтобы увидеть, доступен ли он для чтения. Если это так, обработка разделов подтверждается, и диск может быть объявлен на пути к полному и надежному восстановлению. Если это не так, возможно, раздел является правильным, и (часть) раздела данных была переписана. Это плохо; см. ниже под заголовком «все идет плохо».
если он найден и действителен, проверьте его по геометрии диска и, если они не совпадают, это также на самом деле хорошо , так как вы, возможно, нашли основную причину проблемы. Вы можете принудительно настроить физическую геометрию ядра (и получить ее при загрузке Linux ). Посмотрите, приводит ли новая геометрия к распознаванию диска в Linux. Если это так, сделайте резервную копию данных, убедитесь, что резервная копия правильная, и обнулите диск dd(достаточно пары мегабайт нулей на соответствующее sdустройство). Выключите компьютер (не просто перезагрузите компьютер; хорошо, это параноик, но он стоит недорого и может чего-то добиться), затем загрузите Windows и отформатируйте диск, который теперь не имеет смысла, в тот, который он считает лучшим форматом. Это гарантирует отсутствие конфликтов с Windows. Восстановите данные на диске. Наслаждаться.
если уловка геометрии не работает, или раздел не может быть найден, или когда он найден, он кажется пустым, вещи портятся. Вам нужен инструмент для восстановления, способный сканировать образ диска в поисках областей данных (MFT и т. Д.) Утерянных данных. И как только найден, интерпретировать их, чтобы получить данные. Это сложная работа, которая не всегда может быть полностью автоматизирована. На более низком и более отчаянном уровне это включает сканирование сигнатур отдельных файлов в надежде, что они будут лежать в непрерывных блоках на диске. Такого рода операцию я бы с удовольствием оставил профессионалам. Я делал это несколько раз, всегда успешно, со старыми FAT-дисками. Я сделал это снова, примерно на 50% успешно, с новыми и большими и более фрагментированными дисками FAT32. Я пытался пару раз, с плохими результатами (но у меня были полные резервные копии, и я на самом деле не делал все это), на гораздо более сложных файловых системах NTFS и ext4.
Восстановление вручную из Linux
ОК, так что вы пытаетесь смонтировать раздел в Linux и получить ошибки ( обратите внимание , что /dev/sdc и разные вещи - изображение относится к )./dev/sdcN /dev/sdc
# mount -t ntfs /dev/sdc1 /mnt/recovery
ntfs_mst_post_read_fixup_warn: magic: 0x00000000 size: 1024 usa_ofs: 0 usa_count: 65535: Invalid argument
Record 1 has no FILE magic (0x0)
Failed to open inode $MFTMirr: Input/output error
... это указывает на то, что раздел, как полагает система , неверен или сильно поврежден. Давайте сначала проверим первый вариант:
# fdisk /dev/sdc
Вы получаете что-то вроде этого:
Disk /dev/sdc: 1000.2 GB, 1000204885504 bytes
1 heads, 63 sectors/track, 31008335 cylinders, total 1953525167 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9d2b7596
Device Boot Start End Blocks Id System
/dev/sdc1 63 1953520127 976760032+ 7 HPFS/NTFS/exFAT
Следующим шагом будет проверка фактического начала раздела. При поиске в файле образа (или /dev/sdc) мы будем искать подпись NTFS:
00000000:EB 52 90 4E 54 46 53 20 -20 20 20 00 02 08 00 00 .R.NTFS ........
00000010:00 00 00 00 00 F8 00 00 -3F 00 FF 00 3F 00 00 00 ........?...?...
00000020:00 00 00 00 80 00 80 00 -4A F5 7F 00 00 00 00 00 ........J.......
# dd if=/dev/sdc bs=512 count=1 skip=63 2>/dev/null | hexdump -C | head -n 1
... с данными выше мы ожидаем, что загрузка NTFS будет в секторе 63, поэтому мы установили skip. Кроме того, мы попробуем с каждым сектором в первом (скажем) мегабайте ...
# dd if=/dev/sdc bs=512 count=2000000 2>/dev/null | hexdump -C | grep "00:EB 52 90 4E 54 46 53"
... просто чтобы быть уверенным, что есть только один загрузочный сектор (у меня это случилось со мной. На диске FAT32, но все же ) и что нигде нет ошибок чтения.
Ваш результат
00007e00 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|
это именно то, что и следовало ожидать: сектор 63 дает смещение 63 × 512 = 32256 = 7e00 шестнадцатеричное. Загрузочный сектор NTFS находится там, и таблица разделов выглядит правильно .
Итак, теперь мы можем скопировать большой кусок /dev/sdc1, скажем, /tmp/mydisk.imgи попытаться исправить это из Linux. Это не повредит физический диск, который все еще будет доступен без изменений для других попыток. И поскольку теперь мы знаем, что PT верен, мы можем использовать его /dev/sdc1для копирования и развлекать надежды, которых раньше не могли:
# dd if=/dev/sdc1 of=/tmp/mydisk.img bs=1G count=10
...after copying 10 gigabytes...
# ntfsfix /tmp/mydisk.img
Если NTFSfix не работает, у нас проблемы. Однако есть и более точные утилиты, которые можно попробовать. И если вам нужно восстановить файлы изображений JPEG, а файловая система не была фрагментирована, это можно сделать автоматически с помощью поиска заголовков JPEG. То же самое касается почти документов PDF, TIFF и Office, за исключением того, что я не знаю, как их распознать (для JPEG я бы :-)). В качестве последнего варианта я нашел этих ребят - я их не знаю, не связан с ними и не приму никакой вины. Однако, как эти вещи идут, цена очень разумная.
