Прежде всего, не делайте больше ничего на диске (по крайней мере, никогда не пишите на него). Диск, который не был распознан (в отличие от "быть распознанным и найденным пустым или с нечитаемыми данными"), похоже, указывает либо на полностью очищенный диск, что не нужно делать chkdsk , либо что-то не так с таблицей разделов или геометрией диск, или как USB-корпус обрабатывает его. Аппаратный сбой также возможен.
Это может произойти и произойдет, когда USB-корпуса попытаются договориться между диском и компьютером, к которому они подключены. Поэтому первое, что нужно сделать, это взять образ диска на (очевидно больший) диск как можно ближе к физическому уровню, используя dd под Linux. Тогда вы можете возиться с копией изображения в свое удовольствие, без риска дальнейшего повреждения реального диска.
Обновление: распознавание устройства в 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 и смонтировать его с помощью петлевого устройства. Здесь вы найдете грязные детали.
Первая попытка восстановления
Второе, что нужно сделать, - это поместить физический диск в другой корпус, тем самым обеспечив его исправность и получив шанс, что новый корпус правильно интерпретирует диск. Если диск появится снова, возможно, сломался предыдущий корпус. На всякий случай сделайте резервную копию всего содержимого вновь найденного диска, проверьте резервную копию, обнулите диск с помощью утилиты перезаписи диска, чтобы он стал полностью тупым (вы не можете иметь два устройства с разными мнениями в цепочке устройств), переформатируйте его изначально из Windows и восстановить данные. Это удачный выстрел, но я видел, как это произошло; и попытка не слишком дорогая, хорошие корпуса стоят около 19,99 долларов США новые.
В случае, если исходный корпус был плохим, вы не сможете переформатировать диск, или диск не будет доступен. Вы можете повторить новый корпус, и если она работает, либо заменить старый корпус, или продолжать использовать новый (но это имеет смысл , если новый корпус вполне лучше , чем US $ 19,99 El Cheapo).
Профессиональное восстановление
Профессиональные услуги восстановления, те, которые вы можете найти с помощью 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 я бы :-)). В качестве последнего варианта я нашел этих ребят - я их не знаю, не связан с ними и не приму никакой вины. Однако, как эти вещи идут, цена очень разумная.
