Eu tenho um arquivo de imagem de um disco rígido com defeito criado com ddrescue no Linux. O disco rígido tem 750 GB, se bem me lembro, apenas cerca de 30 MB não puderam ser salvos. Tenho alguns outros HDs com defeito e não me lembro se este pertencia ao meu computador Windows ou Linux.
Estou tentando gravar a imagem de volta em um HD de 2 TB. Não importa se eu formato esse HD como NTFS ou EXT e gravo a imagem nesse novo HD, uma vez feito isso, ele aparece como não formatado e em branco novamente. Eu li que devemos usar ferramentas de correção de erros para as imagens antes de escrevê-las. Então tentei usar fsck e ntfsfix, mas nenhum consegue identificar a imagem e corrigi-la.
Se o ddrescue conseguiu salvar tanto daquele HD defeituoso, por que as ferramentas não conseguem corrigir os erros e por que não podem ser gravados de volta? Consegui escrever de volta outro HD de 160 GB com defeito, então não sei por que esse de 750 GB não funciona.
Edite, para escrever de volta a imagem que uso:
sudo ddrescue -f seagate750gb.img /dev/sdb restore.log
cabeça -n 16 seagate750gb.log
# Rescue Logfile. Created by GNU ddrescue version 1.17
# Command line: ddrescue -d -r5 -R /dev/sdb seagate750gb.img seagate750gb.log
# current_pos current_status
0x89B7F4A00 +
# pos size status
0x00000000 0x89B7F4800 +
0x89B7F4800 0x00000200 -
0x89B7F4A00 0x010AA200 +
0x89C89EC00 0x00000200 -
0x89C89EE00 0x21775200 +
0x8BE014000 0x00000200 -
0x8BE014200 0x000DA400 +
0x8BE0EE600 0x00000200 -
0x8BE0EE800 0x00369600 +
0x8BE457E00 0x00000200 -
0x8BE458000 0x002B6000 +
arquivo seagate750gb.img
seagate750gb.img: x86 boot sector
gdisk -l seagate750gb.img
GPT fdisk (gdisk) version 0.8.8
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Disk seagate750gb.img: 1465149168 sectors, 698.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2891CCD9-92FB-4380-AB03-801E0E4F90CC
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1465149134
Partitions will be aligned on 2048-sector boundaries
Total free space is 1465149101 sectors (698.6 GiB)
Number Start (sector) End (sector) Size Code Name
sudo gdisk -l /dev/sdb
(este é meu HD de 2 TB, depois que a imagem foi gravada nele)
GPT fdisk (gdisk) version 0.8.8
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 59784077-576E-4CC1-918D-773D10916B46
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3907029101 sectors (1.8 TiB)
Number Start (sector) End (sector) Size Code Name
Responder1
Antes de especular, verifique algumas coisas:
Certifique-se de que a imagem do disco realmente contenha dados. Tente algo como:
lzop < disk.img | wc -c - disk.img
Isso levará alguns minutos para contar os caracteres na imagem e em um
lzop
fluxo um tanto compactado da imagem. Se a imagem contiver zeros, olzop
número será relativamente pequeno.Se o
lzop
número for pelo menos10%do tamanho da imagem bruta, há alguns dados emdisco.img.Se parecer haver dados, verifique o que alguns utilitários padrão dizem sobre isso:
file disk.img
...deveria contar um pouco sobre o que há lá. Se for uma tabela de partições, tente:
gpart -v disk.img