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!
źródło
Odpowiedzi:
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!
Naprawił błędy, a następnie nie zamontował żadnego problemu z:
źródło
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ż:
źródło
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:
Po przeczytaniu DataRecovery (link udostępniony przez Takkat, dziękuję!) Wypróbowałem następujące i zadziałało:
To dało następującą wydajność:
Następnie pomnożyłem 63 przez 512, aby uzyskać 32256 i zamontowałem obraz w ten sposób:
Mam nadzieję, że pomoże to również komuś innemu.
źródło
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.
źródło