Eu fiz uma imagem (dd) de uma unidade e estou tentando executar uma verificação de sistema de arquivos: Tipo de Sistema de Arquivos: ext3

Aqui está o erro original do fsck:

 fsck -fv -z ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.undo.$(date
+"%Y-%m-%d.%H.%M.%S").und /dev/loop2
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Overwriting existing filesystem; this can be undone using the command:
    e2undo ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.undo.2019-01-17.13.31.41.und /dev/loop2

The filesystem size (according to the superblock) is 122063840 blocks
The physical size of the device is 121604515 blocks
Either the superblock or the partition table is likely to be corrupt!

Informação do fdisk -l / dev / sda

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 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
Disklabel type: dos
Disk identifier: 0x000794ac

Device     Boot  Start       End   Sectors   Size Id Type
/dev/sda1  *        32      8191      8160     4M  4 FAT16 <32M
/dev/sda2       262144 976773119 976510976 465.7G 83 Linux

Informação de fdisk -l ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img

Disk ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img: 464 GiB, 498226311168 bytes, 973098264 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: 0x000794ac

Device                                              Boot  Start       End   Sectors   Size Id Type
./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img1 *        32      8191      8160     4M  4 FAT16 <32M
./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img2      262144 976773119 976510976 465.7G 83 Linux

Eu fiz um dispositivo de loop para o Partition Using:

losetup --offset $((512*262144)) /dev/loop2 ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img

De blockdev --getbsz / dev / loop2

4096

De blockdev --getsz / dev / loop2

972836120

De dumpe2fs / dev / loop2:

Filesystem UUID:          f68ccb5a-bcfa-4e8a-8876-45adaa6e6b85
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30523392
Block count:              122063840
Reserved block count:     6103192
Free blocks:              96939245
Free inodes:              30462657
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      994
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Sat Apr 26 21:28:22 2014
Last mount time:          Wed Jan 16 15:59:22 2019
Last write time:          Thu Jan 17 18:16:50 2019
Mount count:              17
Maximum mount count:      -1
Last checked:             Sat Apr 26 21:28:22 2014
Check interval:           0 (<none>)
Lifetime writes:          10 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      162d0daa-7968-48f9-8370-f095c9e19f58
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x000059bd
Journal start:            0

Seguido por muitos:

Group 0: (Blocks 0-32767)
  Primary superblock at 0, Group descriptors at 1-30
  Reserved GDT blocks at 31-1024
  Block bitmap at 1025 (+1025)
  Inode bitmap at 1026 (+1026)
  Inode table at 1027-1538 (+1027)
  4 free blocks, 8179 free inodes, 2 directories
...
(SKIPPING TO END)
...
Group 3725: (Blocks 122060800-122063839)
  Block bitmap at 122060800 (+0)
  Inode bitmap at 122060801 (+1)
  Inode table at 122060802-122061313 (+2)
  0 free blocks, 8192 free inodes, 0 directories

Terminou com:

dumpe2fs: /dev/loop2: error reading bitmaps: Can't read a block bitmap

Agora eu posso montar / dev / sda2 muito bem e ler os arquivos, mas não consigo montar / dev / loop2

mount -t ext3 /dev/loop2 ./DriveImage/
mount: wrong fs type, bad option, bad superblock on /dev/loop2,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Eu recebo o mesmo erro ao tentar montar diretamente da imagem usando:

mount -o loop,offset=$((512*262144)) ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img ./DriveImage

Agora, de acordo com o dumpe2fs, o superbloco está certo!
E de acordo com a matemática:

 Superblock says:
 122063840
 Filesystem says:
 121604515

 block size:
 4096

 Math: Sectors * Sector Size = Size / Block Size = Blocks
 Partition 1: 
 8160 * 512 = 4177920 / 4096 = 1020
 Partition 2:
 [From fdisk]
 976510976 * 512 = 499973619712 / 4096 = 122063872
 [From blockdev with /dev/loop2]
 972836120 * 512 = 498092093440 / 4096 = 121604515

O fdisk está reportando muito perto dos blocos corretos ... (Apenas 32 blocos a mais) Mas no meu livro, o fsck está obtendo suas informações de blocos da mesma maneira que o blockdev faz (ou usa), mas de acordo com o dumpe2fs e verificando a tabela de partições , o superbloco está correto e a tabela de partições também.

Com medo de perder os dados originais no disco (10 anos de fotos e vídeos da família e arquivos importantes), não estou disposto a executar essas coisas no disco original. Então eu fiz uma cópia do disco para esta imagem, então também, caso eu estrague algo, eu também fiz uma cópia da imagem. (Não se preocupe, eu tenho espaço em disco para isso).

O que eu estou fazendo errado aqui? e como posso consertar isso?

NOTA: Devido ao antigo disco começar a falhar (supostamente, tive alguns problemas), é por isso que estou fazendo isso.
TAMBÉM, por algum motivo, a unidade perdeu sua tabela de partições e eu tive que usar o testdisk para recuperá-la. Depois que foi recuperado, consegui montar a partição grande e ler todos os meus dados.
Então eu assumi que o disco de teste acertou ou foi muito próximo, já que está tudo lá.

(UPDATE # 1) Devo notar também que quando eu executo o fsck na unidade original eu não recebo este erro ...

fsck -nfv /dev/sda2
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

       60735 inodes used (0.20%, out of 30523392)
        1510 non-contiguous files (2.5%)
          49 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 23779/2425/0
    25124595 blocks used (20.58%, out of 122063840)
           0 bad blocks
           1 large file

       56022 regular files
        4704 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
       60726 files

(UPDATE # 2) Descobri que o arquivo de imagem não é o mesmo que o drive, o arquivo de imagem é menor.
Drive Tamanho: 500107862016 (Teve um erro aqui, eu só tenho o tamanho da segunda partição, atualizado para corrigir informações)
Tamanho da imagem: 498226311168
O arquivo de imagem está faltando 1881550848 bytes, mais 1.88GB de dados. (Isso também corrigiu)
Parece que o dd não conseguiu tudo, e que eu posso estar certo de que a unidade tem problemas, existe uma maneira de fazer o dd preencher erros de leitura com espaço em branco para que eu possa ter um tamanho correspondente?

Eu estou correndo através do fsck no dispositivo de loop para ver o que ele faz, eu acho que se eu estragar tudo, vou apenas restaurar a imagem de volta.

Outra nota importante: Este é um sistema de servidor sem cabeçalho, sem GUI, apenas CLI.

Erros de uma imagem de disco defeituosa

Parece que você está vendo erros na imagem causados ​​por uma unidade com falha. Eu usaria gddrescue em vez disso, ele tenta lidar com erros de leitura.

O manual do Gddrescue é informativo, é a seção 10 Um pequeno tutorial com exemplos começa com

Exemplo 1: Resgate totalmente automático de um disco inteiro com duas partições ext2 em / dev / sda para / dev / sdb.
Nota: você não precisa particionar / dev / sdb antecipadamente, mas se a tabela de partição em / dev / sda estiver danificada, você precisará recriá-la de alguma forma em / dev / sdb.

ddrescue -f -r3 /dev/sda /dev/sdb mapfile
fdisk /dev/sdb
e2fsck -v -f /dev/sdb1
e2fsck -v -f /dev/sdb2

Em vez de resgatar diretamente para um dispositivo (/ dev / sdb), o uso de um arquivo funciona. E, em vez de começar com -r 3a repetição de setores defeituosos 3 vezes, use o padrão (0) e -n/ --no-scrapepara "Skip the scraping phase" para obter o máximo possível rapidamente.

Há também um pacote ddrescueview que dá uma visão gráfica de um arquivo de mapa gddrescue, que pode ser interessante:

E monitorar o syslog ou o dmesg deve ter mostrado erros de leitura anteriormente, eu os monitoraria enquanto usava essa unidade.

Existem muitos arquivos importantes para backup?

Se os arquivos ainda estiverem legíveis e, especialmente, se os arquivos importantes que você deseja fazer backup forem muito menores do que a unidade inteira, basta copiar apenas esses arquivos e esquecer toda a imagem da unidade. OS são fáceis de reinstalar.

Montando imagens de disco cheias

Parece que losetup -P cria dispositivos de loop de partição apropriados, ou talvez , partprobeou gnome-disk-image-mounteralém de kpartx.