Preciso recuperar arquivos da minha unidade flash Lexar de 16 GB. O PCB não parece danificado de forma alguma, então espero que a recuperação possa ser feita. Quando conecto o USB em uma máquina Windows, ele o reconhece como uma unidade, mas solicita que eu insira um disco. Depois de alguns dias tentando fazer isso funcionar, decidi tentar no Ubuntu.
Executando o lsusbcomando:
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
O pen drive é reconhecido como Alcor Micro Corp. Até aí tudo bem. No entanto, quando executo 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
A unidade não é reconhecida. Finalmente, corri 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
Alguma idéia para recuperar os dados? Desde já, obrigado!
Responder1
Faça uma imagem do dispositivo agressor com ddrescue- Você precisará de espaço de armazenamento suficiente para armazenar toda a unidade, independentemente da quantidade de dados que você tem (ou tinha) armazenados nela. Nesse caso, parece que você precisará de 16 GB para armazenar um clone de /dev/sdb.
ddrescue é o programa que fará o trabalho e se não estiver instalado precisamos instalá-lo sudo apt-get install gddrescue(não é um erro de digitação, g é a abreviação de GNU)
Abra um terminal CtrlAltTe mude para o diretório onde você armazenará o arquivo de imagem e emita o comandosudo ddrescue -d /dev/sdb sdb.img sdb.logfile
o -d direciona o acesso direto à unidade (ignorando o cache) /dev/sdb é o dispositivo que estamos usando para entrada sdb.img é o arquivo que estamos usando para saída sdb.logfile está monitorando onde estamos e quais nossos resultados são.
Se por algum motivo o processo for interrompido antes de ser concluído, o arquivo de log permitirá continuar de onde paramos.
a imagem começará e você verá algo assim:
Resgatado indica a quantidade de dados lidos com sucesso, errsize indica o tamanho dos dados ilegíveis. À medida que o processo continua, esperamos ver o primeiro aumentar e o último aproximar-se de zero. O ddrescue usa um processo chamado gravação de dados, pelo que me lembro, no qual os blocos com falha são divididos pela metade e tentados novamente.
ddrescue é uma ferramenta muito poderosa e você pode aprender muito sobre ela nomanual. Preste muita atenção ao Capítulo 3!!escolher o arquivo ou dispositivo errado para saída definitivamente arruinará o seu dia.
Depois de obtermos a imagem resultante, podemos executar testes e procedimentos de recuperação nela sem qualquer estresse adicional para o dispositivo com falha ou falha.
Eventualmente, o ddrescue exibirá "Concluído" na tela do terminal. Se o tamanho do erro for alto e você quiser tentar recuperar um pouco mais, poderá executar novamente o comando e aplicar opções para tentar novamente os blocos com falha e até mesmo ler ao contrário (provavelmente não é útil em um dispositivo de estado sólido) por: sudo ddrescue -d --try-again --retrim --reverse /dev/sdb sdb.img sdb.logfileou qualquer outra combinação de opções que você considere útil no manual mencionado. Depois de terminar de tentar recuperar todos os dados, é hora de ver o que temos.
Emita o comando fdisk -l sdb.imgou o nome que você deu à sua imagem. Com alguma sorte, você obterá uma saída semelhante a esta, indicando que a tabela de partições está intacta.
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
Observe o número "Iniciar". Isso significa que o sistema de arquivos inicia no setor 2048.
Armados com essas informações e algumas habilidades matemáticas básicas ou uma calculadora, podemos chegar ao deslocamento necessário para testar nossos processos. 2.048 setores X 512 bytes por = 1.048.576
já que criamos esta imagem devido a uma falha, primeiro tentaremos reparar o sistema de arquivos
emita o comando sudo losetup --offset 1048576 /dev/loop2 sdb.imgpara configurar a imagem em um dispositivo de loop.
então emita o comandosudo fsck /dev/loop2
Depois de repararmos o sistema da melhor maneira possível, criaremos um ponto de montagem sudo mkdir /mnt/loope montaremos o dispositivo de loop configurado anteriormente comsudo mount /dev/loop2 /mnt/loop
Agora esperamos ter alguns dados que possamos copiar para outra unidade. vamos olhar:
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
Parece que tenho alguns. Espero que você também! depois de terminar de copiar meus arquivos, desmonto o dispositivo de loop comsudo umount /dev/loop2
Se essa abordagem não tiver sido bem-sucedida, também posso tentar testdisk com o comando `sudo testdisk sdb.img (ou o nome que você deu ao arquivo de imagem). Pressione Enter para selecionar a imagem e escolha o tipo de partição. Se um tipo for detectado, isso lhe dará uma dica sobre como proceder. Observe que geralmente é Intel em unidades flash.
Você pode escolher Analisar para procurar partições perdidas ou ir diretamente para Avançado para que as ferramentas do sistema de arquivos selecionem uma partição já conhecida ou recuperada. Após a seleção da partição, você verá uma lista de arquivos com instruções sobre como selecionar arquivos para copiar e etc. Esta parte é bastante autoexplicativa e provavelmente será abordada em outro lugar, então vou parar por aqui com a promessa de que se alguma coisa não estiver clara você pode me deixar um comentário e eu entrarei em contato com você.