Montowanie obrazu ddrescue po odzyskaniu (w mojej głowie)

18

Mam problemy z zamontowaniem obrazu odzyskiwania. Próbowałem zamontować obraz na wiele sposobów.

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

Nie podaje mi nawet szczegółowych informacji na temat pliku, który właśnie utworzyłem, nautilus mówi, że to 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

Nie jestem pewien, co robię źle lub czy od samego początku rozpocząłem ten proces niepoprawnie. Poniżej opisałem, co zrobiłem do tej pory. Nie mam pojęcia, byłbym wdzięczny, gdyby ktoś miał dla mnie jakiś wkład.

Co zrobiłem od samego początku

Mój laptop ma dwa dyski twarde.

Jeden ma pliki systemowe Win7 / Linux Mint z podwójnym uruchomieniem. Drugi zawierał mój folder / home.

Laptop został zgnieciony, a dysk / home został uszkodzony. Próbowałem odzyskać LiveCD, nie powiodło się. Nie załadowałby nawet sesji Live z zainstalowanym dyskiem. Więc zwróciłem się do 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 wewnętrzny, przechowuje wszystkie pliki systemowe i wszystkie funkcje komputera.
  • sdb - 160g wewnętrzny, USZKODZONY , zawiera około 140g danych, które chciałbym odzyskać.
  • sdc - 1T zewnętrzny, zawiera obraz odzyskiwania. Tylko miejsce, w którym jest miejsce na to wszystko.

Z tej strony https://apps.education.ucsb.edu/wiki/Ddrescue

Użyłem tego skryptu, aby utworzyć obraz uszkodzonego dysku twardego. Zmieniłem miejsce docelowe na zewnętrzny dysk USB.

#!/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

Wszystko wyglądało, jakby poszło bez problemu:

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

Wygląda na to, że z miejsca, w którym stoję, działało idealnie. Oto dziennik:

# 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  +

Nie jestem pewien, jak postępować. Czy to oznacza, że ​​wszystkie moje dane zostały utracone ????????

Doceń DOWOLNE dane wejściowe!

BorgDomination
źródło
5
+1 za dostarczenie wielu szczegółowych istotnych informacji przedstawionych w jasny, łatwy do odczytania sposób.
Scott Severance
Wiki Ubuntu ma bardzo dobrą stronę dotyczącą odzyskiwania danych: help.ubuntu.com/community/DataRecovery
Wilf

Odpowiedzi:

7

Znalazłem rozwiązanie i czuję się głupio, że przegapiłem to. Dziękuję wam bardzo za odpowiedzi!

Sprawdziłem obraz pod kątem błędów, a następnie zamontowałem go bez problemu!

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

Naprawił błędy, a następnie nie zamontował żadnego problemu z:

sudo mount /dev/sda2/backup.img /mnt/recoverydata
BorgDomination
źródło
5

Utworzony obraz będzie zawierał wszystkie błędy oryginalnego dysku. Dlatego prawdopodobnie nie możesz go zamontować ani przeczytać. Aby kontynuować, należy załadować ten obraz do swojego ulubionego narzędzia do odzyskiwania danych .

Mamy dobre doświadczenie z Testdisk / PhotoRec, ale są też inne narzędzia, o których warto wspomnieć, np. Foremost.

Zobacz też:

Takkat
źródło
4

Oto, co musiałem zrobić w podobnej sytuacji - na wypadek, gdyby ktoś natknął się na to pytanie tak jak ja.

Mój obraz również nie chciał się zamontować, generując ten sam błąd (zły superblok). Jednak fsck również nie powiódł się z następującym błędem:

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>

Po przeczytaniu DataRecovery (link udostępniony przez Takkat, dziękuję!) Wypróbowałem następujące i zadziałało:

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

To dało następującą wydajność:

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

Następnie pomnożyłem 63 przez 512, aby uzyskać 32256 i zamontowałem obraz w ten sposób:

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

Mam nadzieję, że pomoże to również komuś innemu.

Jure Merhar
źródło
2

Oprócz odpowiedzi Takkata chciałbym zaproponować inne możliwe podejście. Biorąc pod uwagę, że obraz jest prawie na pewno uszkodzony, mogą istnieć pewne dane, których narzędzia do odzyskiwania danych nie są w stanie odpowiednio odzyskać.

SpinRite rozwiązuje ten problem w inny sposób. Zamiast operować na obrazie, ćwiczy dysk, aby uzyskać z niego więcej danych, niż normalne narzędzia mogą odzyskać. Użyłem go, aby znacznie zwiększyć ilość danych do odzyskania. Jeśli masz szczęście, będziesz mógł później zamontować dysk normalnie przez wystarczająco długi czas, aby wykonać właściwą kopię zapasową.

SpinRite ma jednak poważną wadę. Kosztuje sporo pieniędzy. Jeśli inne narzędzia działają dla Ciebie, niż oszczędzaj pieniądze. Ale jeśli potrzebujesz więcej, zdecydowanie warto spróbować SpinRite.

Scott Severance
źródło