Montaje de la imagen ddrescue después de la recuperación (sobre mi cabeza)

18

Tengo problemas para montar la imagen de recuperación. He intentado montar la imagen de varias maneras.

quark@DS9 ~ $ sudo mount -t ext4 /media/jump1/1recover/sdb1.img /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so


quark@DS9 ~ $ sudo mount -r -o loop /media/jump1/1recover/sdb1.img recover
mount: you must specify the filesystem type

quark@DS9 ~ $ sudo mount /media/jump1/1recover/sdb1.img mnt
mount: you must specify the filesystem type

Ni siquiera me da información detallada sobre el archivo que acabo de crear, nautilus dice que son 160 gb.

quark@DS9 ~ $ file /media/jump1/1recover/sdb1.img
/media/jump1/1recover/sdb1.img: data


quark@DS9 ~ $ mmls /media/jump1/1recover/sdb1.img
        Cannot determine partition type

No estoy seguro de lo que estoy haciendo mal o si comencé este proceso incorrectamente desde el principio. He resumido lo que he hecho hasta ahora a continuación. No tengo ni idea, agradecería si alguien tuviera alguna aportación para mí.

Lo que he hecho desde el principio

Mi laptop tiene dos discos duros.

Uno tiene los archivos de sistema de arranque dual Win7 / Linux Mint. La secundaria contenía mi carpeta / home.

Se sacudió la computadora portátil y se rompió el disco / home. Intenté una recuperación de LiveCD, falló. Ni siquiera cargaría una sesión en vivo con el disco instalado. Entonces recurrí a ddrescue.

quark@DS9 ~ $ sudo fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 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: 0x0009fc18

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   112642047    56320000    7  HPFS/NTFS/exFAT
/dev/sda2       138033152   312580095    87273472   83  Linux
/dev/sda3       112644094   138033151    12694529    5  Extended
/dev/sda5       112644096   132173823     9764864   83  Linux
/dev/sda6       132175872   138033151     2928640   82  Linux swap / Solaris

Partition table entries are not in disk order

Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 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: 0x0002a8ea

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *          63   312576704   156288321   83  Linux

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 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: 0xed6d054b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1              63  1953520064   976760001    7  HPFS/NTFS/exFAT
  • sda - 160g interno, contiene todos los archivos del sistema y todas las funciones de la computadora.
  • sdb - 160g interna, ROTO , contiene aproximadamente 140 g de los datos que me gustaría recuperar.
  • sdc - 1T externo, contiene imagen de recuperación. Único lugar que tiene espacio para hacer todo esto.

Desde este sitio, https://apps.education.ucsb.edu/wiki/Ddrescue

Usé este script para crear una imagen del disco duro roto. Cambié el destino a la unidad USB externa.

#!/bin/sh 

prt=sdb1
src=/dev/$prt
dst=/media/jump1/1recover/$prt.img
log=$dst.log

sudo time ddrescue --no-split $src $dst $log
sudo time ddrescue --direct --max-retries=3 $src $dst $log
sudo time ddrescue --direct --retrim --max-retries=3 $src $dst $log

Todo parecía salir sin problemas:

quark@DS9 ~ $ sudo bash recover1 


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:   160039 MB,  errsize:    4096 B,  current rate:    35588 B/s
   ipos:      3584 B,   errors:       1,    average rate:   22859 kB/s
   opos:      3584 B,     time from last successful read:       0 s
Finished                   
12.78user 1060.42system 1:56:41elapsed 15%CPU (0avgtext+0avgdata 4944maxresident)k
312580958inputs+0outputs (1major+601minor)pagefaults 0swaps


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:   160039 MB,  errsize:    4096 B,  errors:       1
Current status
rescued:   160039 MB,  errsize:    1024 B,  current rate:        0 B/s
   ipos:      1536 B,   errors:       1,    average rate:       13 B/s
   opos:      1536 B,     time from last successful read:     1.3 m
Finished                       
0.00user 0.00system 3:43.95elapsed 0%CPU (0avgtext+0avgdata 4944maxresident)k
238inputs+0outputs (3major+374minor)pagefaults 0swaps


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:   160039 MB,  errsize:    1024 B,  errors:       1
Current status
rescued:   160039 MB,  errsize:    1024 B,  current rate:        0 B/s
   ipos:      1536 B,   errors:       1,    average rate:        0 B/s
   opos:      1536 B,     time from last successful read:     3.7 m
Finished                       
0.00user 0.00system 3:43.56elapsed 0%CPU (0avgtext+0avgdata 4944maxresident)k
8inputs+0outputs (0major+376minor)pagefaults 0swaps

Parece que desde donde estoy parado funcionó perfectamente. Aquí está el registro:

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue --direct --retrim --max-retries=3 /dev/sdb1 /media/jump1/1recover/sdb1.img /media/jump1/1recover/sdb1.img.log
# current_pos  current_status
0x00000600     +
#      pos        size  status
0x00000000  0x00000400  +
0x00000400  0x00000400  -
0x00000800  0x254314FC00  +

No estoy seguro de cómo proceder. ¿Esto significa que todos mis datos se pierden ????????

Agradezco cualquier entrada!

BorgDomination
fuente
55
+1 por proporcionar mucha información detallada detallada presentada de manera clara y fácil de leer.
Scott Severance
El wiki de Ubuntu tiene una muy buena página sobre recuperación de datos: help.ubuntu.com/community/DataRecovery
Wilf

Respuestas:

7

Encontré la solución y me siento un poco tonto por perder esto. Muchas gracias a todos por sus respuestas!

¡Verifiqué la imagen en busca de errores y luego se montó sin problemas!

sudo fsck -y /dev/sda2/backup.img

Solucionó los errores y luego no montó ningún problema con:

sudo mount /dev/sda2/backup.img /mnt/recoverydata
BorgDomination
fuente
4

Esto es lo que tuve que hacer en una situación similar, en caso de que alguien se tope con esta pregunta como lo hice yo.

Mi imagen tampoco se montaría, generando el mismo error (superbloque incorrecto). Sin embargo, fsck también falló con el siguiente error:

fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /mnt/download/rescue.img

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Después de leer DataRecovery (enlace proporcionado por Takkat, ¡gracias!), Probé lo siguiente y funcionó:

apt-get install sleuthkit
mmls /path/to/image

Esto produjo el siguiente resultado:

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000000062   0000000063   Unallocated
02:  00:00   0000000063   2930272064   2930272002   Linux (0x83)
03:  -----   2930272065   2930277167   0000005103   Unallocated

Luego multipliqué 63 por 512 para obtener 32256 y monté la imagen así:

mount -o loop,offset=32256 /path/to/image /mnt/temp

Espero que esto ayude a alguien más también.

Jure Merhar
fuente
2

Además de la respuesta de Takkat, me gustaría sugerir otro posible enfoque. Teniendo en cuenta que es muy probable que su imagen esté dañada, puede haber algunos datos que las herramientas de recuperación de datos no pueden recuperar adecuadamente.

SpinRite aborda este problema de una manera diferente. En lugar de operar una imagen, ejercita el disco para obtener más datos de los que las herramientas normales pueden recuperar. Lo he usado para aumentar significativamente la cantidad de datos recuperables. Si tiene suerte, podrá montar su disco normalmente después durante el tiempo suficiente para hacer una copia de seguridad adecuada.

Sin embargo, SpinRite tiene una gran desventaja. Cuesta una buena cantidad de dinero. Si las otras herramientas funcionan para usted, entonces ahorre su dinero. Pero si necesita más, definitivamente vale la pena probar SpinRite.

Scott Cesantía
fuente