Мне нужно восстановить файлы с моего 16-гигабайтного флеш-накопителя Lexar. Печатная плата не выглядит поврежденной, поэтому я надеюсь, что восстановление можно будет выполнить. Когда я подключаю USB-накопитель к машине с Windows, он распознает его как диск, но предлагает мне вставить диск. После пары дней попыток заставить эту штуку работать я решил попробовать ее на Ubuntu.
Выполнение lsusbкоманды:
Bus 002 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 8086:0186 Intel Corp. WiMAX Connection 2400m
Bus 001 Device 003: ID 0bda:5801 Realtek Semiconductor Corp.
Bus 001 Device 007: ID 058f:1234 Alcor Micro Corp. Flash Drive
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Флешка распознается как Alcor Micro Corp. Пока все хорошо. Однако, когда я запускаю sudo fdisk -l:
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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: 0xb43778ae
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 3074047 1536000 27 Hidden NTFS WinRE
/dev/sda2 3074048 921657343 459291648 7 HPFS/NTFS/exFAT
/dev/sda3 954587136 976773119 11092992 17 Hidden HPFS/NTFS
/dev/sda4 921659390 954587135 16463873 5 Extended
/dev/sda5 921659392 954587135 16463872 83 Linux
Partition table entries are not in disk order
Диск не распознан. Наконец, я запустил tail -f:
==> /var/log/syslog <==
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.398762] usb 1-1.2: new high-speed USB device number 9 using ehci-pci
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644599] usb 1-1.2: New USB device found, idVendor=058f, idProduct=1234
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644610] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644616] usb 1-1.2: Product: Mass Storage Device
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644621] usb 1-1.2: Manufacturer: Alcor Micro
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.645100] usb-storage 1-1.2:1.0: USB Mass Storage device detected
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.645183] scsi13 : usb-storage 1-1.2:1.0
Mar 24 08:55:11 danny-Satellite-E305 kernel: [ 6792.642812] scsi 13:0:0:0: Direct-Access Generic USB Flash Disk 7.76 PQ: 0 ANSI: 4
Mar 24 08:55:11 danny-Satellite-E305 kernel: [ 6792.643071] sd 13:0:0:0: Attached scsi generic sg2 type 0
Mar 24 08:55:11 danny-Satellite-E305 kernel: [ 6792.647022] sd 13:0:0:0: [sdb] Attached SCSI removable disk
Есть идеи по восстановлению данных? Спасибо заранее!
решение1
Создайте образ проблемного устройства с помощью ddrescue- Вам потребуется достаточно места для хранения всего диска независимо от объема данных, которые у вас есть (или были) сохранены на нем. В этом случае, похоже, вам понадобится 16 ГБ для хранения клона /dev/sdb.
ddrescue — это программа, которая будет выполнять работу, и если она не установлена, нам нужно установить ее с помощью sudo apt-get install gddrescue(это не опечатка, g — сокращение от GNU)
Откройте терминал CtrlAltTи перейдите в каталог, в котором вы будете хранить файл изображения, и введите командуsudo ddrescue -d /dev/sdb sdb.img sdb.logfile
-d направляет прямой доступ к диску (игнорируя кэширование) /dev/sdb — это устройство, которое мы используем для ввода sdb.img — это файл, который мы используем для вывода sdb.logfile отслеживает, где мы находимся и каковы наши результаты.
Если по какой-либо причине процесс был остановлен до завершения, файл журнала позволяет продолжить его с того места, где мы остановились.
Начнется визуализация, и вы увидите что-то вроде этого:
Rescued указывает на количество успешно прочитанных данных, errsize указывает на размер нечитаемых данных. По мере продолжения процесса мы надеемся увидеть, что первое увеличится, а второе приблизится к нулю. ddrescue использует процесс, называемый data cutting, насколько я помню, в котором неудачные блоки делятся пополам и повторяются.
ddrescue — очень мощный инструмент, и вы можете узнать о нем много полезной информации вруководство. Обратите особое внимание на главу 3!!Выбор неправильного файла или устройства для вывода определенно испортит вам день.
Получив результирующее изображение, мы можем проводить на нем тесты и процедуры восстановления без какой-либо дополнительной нагрузки на вышедшее из строя или вышедшее из строя устройство.
В конце концов ddrescue выведет на экран терминала сообщение "Finished". Если errsize высокий и вы чувствуете, что хотите попытаться восстановить немного больше, вы можете повторно запустить команду и применить переключатели для повторной попытки неудачных блоков и даже чтения в обратном направлении (вероятно, бесполезно на твердотельном устройстве) с помощью: sudo ddrescue -d --try-again --retrim --reverse /dev/sdb sdb.img sdb.logfileили любой другой комбинации переключателей, которая, по вашему мнению, может быть полезной в вышеупомянутом руководстве. После того, как вы закончите попытки восстановить все данные, пришло время посмотреть, что у нас есть.
Введите команду fdisk -l sdb.imgили как вы назвали свой образ. Если повезет, вы получите вывод, похожий на этот, указывающий на то, что таблица разделов не повреждена.
Disk sdb.img: 4013 MB, 4013948928 bytes
1 heads, 24 sectors/track, 326656 cylinders, total 7839744 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: 0x000174fe
Device Boot Start End Blocks Id System
sdb.img1 * 2048 7839743 3918848 b W95 FAT32
Обратите внимание на номер «Начала». Это означает, что файловая система начинается с сектора 2048.
Вооружившись этой информацией и некоторыми базовыми математическими навыками или калькулятором, мы можем получить смещение, которое нам нужно для проверки наших процессов. 2048 секторов X 512 байт на = 1048576
поскольку мы создали этот образ из-за сбоя, мы сначала попытаемся восстановить файловую систему
введите команду sudo losetup --offset 1048576 /dev/loop2 sdb.imgдля настройки образа на петлевом устройстве.
затем отдайте командуsudo fsck /dev/loop2
После того, как мы исправим систему в меру своих возможностей, мы создадим точку монтирования sudo mkdir /mnt/loopи смонтируем ранее настроенное петлевое устройство с помощьюsudo mount /dev/loop2 /mnt/loop
Теперь, надеюсь, у нас есть данные, которые мы можем скопировать на другой диск. Давайте посмотрим:
ls /mnt/loop
autorun.inf casper-rw ldlinux.sys pool smart-fail.txt
boot dists md5sum.txt preseed syslinux
casper install pics README.diskdefines wubi.exe
Похоже, у меня есть некоторые. Надеюсь, у вас тоже! После завершения копирования файлов я отмонтирую устройство loop с помощьюsudo umount /dev/loop2
Если этот подход оказался не слишком успешным, я также могу попробовать testdisk с командой `sudo testdisk sdb.img (или как вы назвали свой файл образа). Нажмите Enter, чтобы выбрать образ, затем выберите тип раздела, если тип будет обнаружен, вам будет дана подсказка о том, как действовать дальше. Обратите внимание, что на флэш-накопителях это обычно Intel.
Вы можете выбрать Анализ для поиска потерянных разделов или перейти непосредственно к Дополнительно для инструментов файловой системы, чтобы выбрать уже известный или восстановленный раздел. После выбора раздела вам будет показан список файлов с инструкциями о том, как выбрать файлы для копирования и т. д. Эта часть довольно понятна и, вероятно, рассматривается в другом месте, поэтому я остановлюсь здесь, пообещав, что если что-то будет непонятно, вы можете написать мне комментарий, и я отвечу вам.