Antes de tudo, não faça mais nada no disco (pelo menos nunca grave nele). O disco que não está sendo reconhecido (ao contrário de "ser reconhecido e encontrado vazio ou com dados ilegíveis") parece indicar um disco completamente danificado, o que chkdsknão costuma acontecer, ou algo errado com a tabela de partição ou a geometria do disco ou a maneira como o gabinete USB lida com isso. Uma falha de hardware também é possível.
Isso pode e acontecerá quando os gabinetes USB tentarem negociar entre o disco e o computador ao qual estão conectados. Portanto, a primeira coisa a fazer seria capturar uma imagem do disco em um disco (obviamente maior) no nível mais próximo possível do físico, usando ddno Linux. Depois, você pode mexer com uma cópia da imagem no conteúdo do seu coração, sem risco de danos adicionais ao disco real.
Atualização: reconhecimento de dispositivo no Linux
Temos pelo menos três entidades em nosso "disco externo". O hardware do gabinete USB, expondo como um dispositivo de bloco. O disco físico dentro do gabinete. O dispositivo físico, ou seja, a sequência dos setores do LBA do primeiro ao último. E, finalmente, zero ou mais partições de dados, hospedando os sistemas de arquivos. Para ser "reconhecido" e exibido em uma área de trabalho, todos os links das cadeias precisam estar funcionando. Mas, para tirar uma foto do dispositivo físico, você precisa apenas dos dois primeiros. Se você conectar o dispositivo e executar a linha de comando dmesg(como root), deverá ver algo assim:
[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
... que é o gabinete sendo reconhecido e, em seguida, identificando-se e seu conteúdo:
[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
A seguir, você verá o driver informando sua geometria, natureza e implicitamente seu nó do dispositivo, aqui sdd(para o Disco Quatro SCSI, desde então sda, sdbe sdcjá foram utilizados):
[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)
Então o kernel reconhece que existe uma partição (se você não vê isso, a partição não está lá ou é inválida):
[4984944.411497] sdd: sdd1
Agora o Linux tem tudo o que precisa e relata um anexo bem-sucedido:
[4984944.416739] sd 7:0:0:0: [sdd] Attached SCSI disk
[4984944.416739] sd 7:0:0:0: Attached scsi generic sg4 type 0
E assim começa a busca pela partição de dados, ou seja, tudo bem sdd1, mas o que há lá? e a resposta é:
[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.
Isso acima era uma montagem "boa". Mas apenas saber que o dispositivo é sdd, ou sdcou sdb, permite-me fazer uma cópia binária (assumindo que tenho espaço livre suficiente /mnt/backupdisk): arquivo de entrada /dev/sdd, arquivo de saída DiskImage.raw, tamanho do bloco 1 MB :
# dd if=/dev/sdd of=/mnt/backupdisk/DiskImage.raw bs=1M
Observe que o arquivo de entrada é /dev/sdd e não /dev/sdd1
(ou qualquer outro número). Agora, se eu quisesse, poderia descobrir o deslocamento da partição de dados DiskImage.rawe montá-lo com a ajuda de um dispositivo de loop. Aqui você encontrará os detalhes sujos.
Primeira tentativa de recuperação
A segunda coisa a fazer seria colocar o disco físico em outro gabinete, garantindo assim que o gabinete fosse bom e obtendo a chance do novo gabinete interpretar corretamente o disco. Se o disco reaparecer, pode ter sido o gabinete anterior que está quebrado. Apenas no caso de, fazer backup de todo o conteúdo da unidade, verificar o backup, zerar o disco com um utilitário de substituição de disco para que fique completamente estúpido (você não pode ter dois dispositivos com opiniões diferentes em uma cadeia de dispositivos), reformate-o nativamente do Windows e restaure os dados. É um tiro de sorte, mas eu vi isso acontecer; e a tentativa não é muito cara, bons gabinetes custam cerca de US $ 19,99 novos.
Caso o gabinete original esteja com defeito, você não poderá reformatar o disco ou o disco não estará acessível. Você pode tentar novamente o novo gabinete e, se funcionar, substituir o antigo gabinete ou continuar usando o novo (mas vale a pena se o novo gabinete for muito melhor que um El Cheapo de US $ 19,99).
Recuperação profissional
Serviços de recuperação profissional, aqueles que você pode encontrar com o Google. Uma maneira não muito honesta de fazer isso seria enviar o disco físico e - no caso de você receber uma mensagem "Sim, não há danos ao hardware e podemos recuperar todos os seus dados por apenas US $ $$$, $ $$! " resposta - bem, você saberia que os dados ainda eram recuperáveis. Assim, você pode tentar fazer isso de graça no backup de imagem que você tirou e pagar apenas pelo diagnóstico e S&H do disco. Se você falhasse, a opção de tossir a massa solicitada ainda estaria lá. Se não é danos no hardware, o serviço profissional é basicamente a sua única opção. Existem vários truques de vodu que reviverão (temporariamente) um disco "morto", muitas vezes tempo suficiente para recuperar os dados mais importantes, pelo menos,nada que tenha a garantia de funcionar sempre (aquecer o disco, resfriá-lo, "girá-lo" - eu até vi sugerido para batê-lo de forma inteligente contra uma superfície dura). Todos eles causarão mais danos, ou seja, você deve usar o único truque que funcionará na primeira vez, ou você matará o disco para sempre. Acabei de adicionar este para explicar por que você vai ver histórias de sucesso sobre discos reviveu: não são essas histórias. Mas se você deseja ter (principalmente) certeza de que isso acontecerá com você , contrate um profissional.
Se você tem certeza de que o hardware está bom - giros no disco, sem barulho, sem sons ou vibrações estranhas, sem recalibrações com cliques e clackety -, então "tudo" que aconteceu foi que chkdskatrapalhou alguns dados.
Recuperação DIY
A recuperação "em casa" geralmente seria assim (basicamente a mesma coisa que os profissionais fariam quando os danos ao hardware fossem descontados), trabalhando na cópia da imagem do disco:
verifique se o primeiro setor da imagem do disco é uma tabela de partição válida. Caso contrário, verifique a imagem do disco procurando uma tabela de partição válida ou um setor de inicialização NTFS ou FAT32 reconhecível, dependendo do FS que estava na unidade (para uma unidade de 1 TB, o NTFS parece a única possibilidade lógica). De qualquer maneira, você deve encontrar algo dentro dos primeiros megabytes.
se a tabela de partição for encontrada, verifique se a partição de dados está onde a tabela de partição diz que deveria estar. Caso contrário, isso é uma notícia muito boa: provavelmente a tabela de partição está errada. A correção é fácil (vários editores de partição Linux fazem isso) e o disco pode ter uma recuperação de 100%. Para garantir a segurança, tente montar a partição de dados no Linux com um dispositivo de loop no modo somente leitura para verificar se é legível. Nesse caso, a partição de borking é confirmada e o disco pode ser pronunciado no caminho para uma recuperação segura e completa. Caso contrário, possivelmente a partição está correta e uma (parte de) uma partição de dados foi reescrita. Isto é mau; veja abaixo em 'as coisas azedam'.
se for encontrado e válido, verifique a geometria da unidade e, se não corresponderem, também é uma coisa boa , pois você pode ter encontrado a causa raiz do problema. Você pode forçar a geometria física ao kernel (e obtê-la na inicialização do Linux ). Veja se a nova geometria leva ao reconhecimento do disco no Linux. Nesse caso, faça backup dos dados, verifique se o backup está correto e zere o disco dd(alguns megabytes de zeros no sddispositivo apropriado são suficientes). Desligue o computador (não apenas reinicie; OK, é paranóico, mas custa pouco e pode fazer alguma coisa); em seguida, inicialize o Windows e faça com que ele formate o disco agora sem noção para o que ele acha que é o melhor formato. Isso garante que não haja conflitos com o Windows. Restaure os dados no disco. Apreciar.
se o truque de geometria não funcionar, ou a partição não puder ser encontrada ou, uma vez encontrada, parecer vazia, as coisas azedarão. Você precisa de alguma ferramenta de recuperação capaz de digitalizar a imagem do disco em busca das áreas de dados (MFT, etc.) dos dados perdidos. E uma vez encontrado, interprete-os para obter os dados. Este é um trabalho difícil e nem sempre pode ser totalmente automatizado. Em um nível mais baixo e mais desesperado, isso envolve a verificação das assinaturas dos arquivos individuais , esperando que eles fiquem em blocos contíguos no disco. Esse tipo de operação eu ficaria feliz em deixar para os profissionais. Fiz isso várias vezes, sempre com sucesso, com discos antigos do FAT. Fiz novamente, cerca de 50% com êxito, com discos FAT32 mais novos, maiores e mais fragmentados. Eu tentei algumas vezes, com resultados ruins (mas eu tinha backups completos e não estava realmente dando tudo de mim), nos sistemas de arquivos NTFS e ext4 muito mais complicados.
Recuperação manual do Linux
OK, então você tenta montar a partição em Linux e obter erros ( aviso de que /dev/sdc e são coisas diferentes - a imagem refere-se )./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
... isso parece indicar que a partição, como o sistema acredita que está , está errada ou seriamente danificada. Vamos verificar a primeira opção primeiro:
# fdisk /dev/sdc
Você obtém algo assim:
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
O próximo passo será verificar o início real da partição. Ao procurar no arquivo de imagem (ou /dev/sdc), procuraremos a assinatura 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
... com os dados acima, esperamos que a inicialização NTFS esteja no setor 63, é por isso que definimos skip. Além disso, tentaremos com todos os setores do primeiro (digamos) megabyte ...
# dd if=/dev/sdc bs=512 count=2000000 2>/dev/null | hexdump -C | grep "00:EB 52 90 4E 54 46 53"
... só para ter certeza de que existe apenas um setor de inicialização (aconteceu comigo. Em um disco FAT32, mas ainda assim ) e que não há erros de leitura em nenhum lugar.
Seu resultado
00007e00 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|
é exatamente o que esperaríamos: o setor 63 fornece um deslocamento de 63 × 512 = 32256 = 7e00 hexadecimal. O setor de inicialização NTFS está lá e a tabela de partição parece estar correta .
Portanto, agora podemos copiar uma grande parte do /dev/sdc1, digamos, /tmp/mydisk.imge tentar corrigi-lo no Linux. Isso não danificará o disco físico, que continuará disponível inalterado para outras tentativas. E como agora sabemos que o PT está correto, podemos usar /dev/sdc1a cópia e alimentar esperanças que não podíamos antes:
# dd if=/dev/sdc1 of=/tmp/mydisk.img bs=1G count=10
...after copying 10 gigabytes...
# ntfsfix /tmp/mydisk.img
Se o NTFSfix não funcionar, estamos com problemas. Existem utilitários mais precisos que podem ser tentados. E se você precisar recuperar arquivos de imagem JPEG e o sistema de arquivos não estiver fragmentado, isso poderá ser feito automaticamente buscando os cabeçalhos JPEG. O mesmo, quase, vale para documentos PDF, TIFF e Office, exceto que eu não sei como reconhecê-los (para JPEGs, eu :-)). Como opção final, eu encontrei esses caras - eu não os conheço, não sou parente deles e não aceito nenhuma culpa. No entanto, como essas coisas acontecem, o preço é muito razoável.
