Não é possível montar o drive USB externo

1

Estou no Debian Jessie e tenho um drive USB externo com NTFS. Eu o conectei ao meu Raspberry Pi, que então reiniciou espontaneamente (provavelmente o consumo de energia era alto demais para o adaptador que estou usando). Desde então, não consigo mais acessar minha unidade USB. Eu tentei corrigi-lo no meu computador normal com

sudo ntfsfix /dev/sdb1

mas isso só me diria

Volume is corrupt. You should run chkdsk.

Eu tenho um computador com Windows, mas também não consigo detectar a unidade. Veja mais algumas informações:

$ ll /dev/sd*
> brw-rw---- 1 root disk 8,  0 Oct 28 12:07 /dev/sda
> brw-rw---- 1 root disk 8,  1 Oct 28 12:07 /dev/sda1
> brw-rw---- 1 root disk 8,  2 Oct 28 12:07 /dev/sda2
> brw-rw---- 1 root disk 8,  5 Oct 28 12:07 /dev/sda5
> brw-rw---- 1 root disk 8, 16 Oct 28 12:16 /dev/sdb
> brw-rw---- 1 root disk 8, 18 Oct 28 12:16 /dev/sdb2
> brw-rw---- 1 root disk 8, 19 Oct 28 12:16 /dev/sdb3

$ sudo fdisk -l
> Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 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
> Disklabel type: dos
> Disk identifier: 0x0007f3b4
> 
> Device     Boot     Start       End   Sectors   Size Id Type
> /dev/sda1  *         2048 472016895 472014848 225.1G 83 Linux
> /dev/sda2       472018942 488396799  16377858   7.8G  5 Extended
> /dev/sda5       472018944 488396799  16377856   7.8G 82 Linux swap / Solaris

> Disk /dev/sdb: 1.8 TiB, 2000365289472 bytes, 3906963456 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
> Disklabel type: dos
> Disk identifier: 0x6e697373
> 
> Device     Boot      Start        End    Sectors   Size Id Type
> /dev/sdb1  ?    1936269394 3772285809 1836016416 875.5G 4f QNX4.x 3rd part
> /dev/sdb2  ?    1917848077 2462285169  544437093 259.6G 73 unknown
> /dev/sdb3  ?    1818575915 2362751050  544175136 259.5G 2b unknown
> /dev/sdb4  ?    2844524554 2844579527      54974  26.9M 61 SpeedStor
> 
> Partition table entries are not in disk order.

$ cat /etc/fstab 
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name devices
> # that works even if disks are added and removed. See fstab(5).
> #
> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
> # / was on /dev/sda1 during installation
> UUID=4b0d4c23-d659-4d16-9396-b895c4964b12 /               ext4    errors=remount-ro 0       1
> # swap was on /dev/sda5 during installation
> UUID=2cc71c90-2d55-4f49-bdb0-b25166d77014 none            swap    sw              0       0
> /dev/sdb1       /media/usb0     auto    rw,user,noauto  0       0

A partição deve ser /dev/sdb1 , mas como você pode ver, não está em /dev . Além disso, não entendo por que fdisk está dizendo que seu tipo é QNX4.x 3rd part . Qualquer ajuda como eu posso, pelo menos, recuperar os arquivos no disco?

    
por pfnuesel 28.10.2014 / 12:25

2 respostas

0

Como pode ser visto pelo comando fdisk , a tabela de partição estava toda desarrumada. Isso provavelmente aconteceu porque a energia na unidade foi cortada enquanto tentava acessá-lo. Eu instalei testdisk , então corri

sudo testdisk /dev/sdb

Após uma análise rápida, o disco foi devidamente reconhecido como sendo um disco NTFS com apenas uma partição, ao contrário das quatro partições sugeridas por fdisk . Reescrevendo a tabela de partição com testdisk corrigiu o problema. Agora tenho acesso a todos os arquivos, como se nada tivesse acontecido.

Fonte: link

    
por 28.10.2014 / 13:47
1

Se você conseguir ler os dados brutos do disco, poderá usar dd para criar um clone do disco (ou dd_rescue , se dd falhar). Então, você pode usar um escultor de arquivo como foremost (que, para mim, produziu bons resultados em ambos partições formatadas e corrompidas).

Para usar foremost , você deve ter pelo menos 2,5 vezes o tamanho da sua partição para recuperar espaço livre (você precisa de espaço para a imagem da partição e espaço para os arquivos gravados).

Especialmente se você lida com um dispositivo corrompido, é obrigatório criar uma imagem dele para trabalhar (evita a perda de dados acidentalmente sobrescrevendo o dispositivo e minimizando a perda de dados devido ao mau funcionamento do dispositivo).

A desvantagem de um escultor de arquivo é que você pode precisar reconstruir manualmente os arquivos de partes dele ou você precisa usar dados alternativos (como, por exemplo, a visualização de uma imagem JFIF que você não pode reconstruir).

Especificamente para NTFS, você também pode tentar uma ferramenta como Recuperação de dados NTFS Stellar Phoenix (que eu não testei nem usei).

    
por 28.10.2014 / 12:38