Монтаж зображення ddrescue після відновлення (у мене над головою)

У мене проблеми з монтажем відновлення зображення. Я намагався змонтувати зображення декількома способами.

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

Він навіть не дає мені детальної інформації про файл, який я щойно створив, nautilus каже, що це 160 Гб.

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

Я не впевнений, що я роблю неправильно, або якщо я почав цей процес неправильно з самого початку. Нижче я окреслив те, що робив. Я незрозумілий, я би вдячний, якби хтось мав якийсь внесок для мене.

Що я робив з самого початку

Мій ноутбук має два жорстких диска.

Один має системні файли подвійного завантаження Win7 / Linux Mint. Вторинний містив мою / домашню папку.

Ноутбук був заблокований, а домашній диск був пошкоджений. Я спробував відновлення LiveCD, воно не вдалося. Навіть не завантажував би активний сеанс із встановленим диском. Тому я звернувся до 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 внутрішній, вміщує всі системні файли та всі функції комп’ютера.
• sdb - 160 г внутрішній, BROKEN , містить близько 140 г даних, які я хотів би відновити.
• sdc - 1T зовнішній, містить зображення для відновлення. Тільки місце, яке має простір для цього.

Від цього веб-сайту https://apps.education.ucsb.edu/wiki/Ddrescue

Я використовував цей скрипт для створення зображення зламаного жорсткого диска. Я змінив призначення на зовнішній накопичувач 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

Все виглядало так, ніби воно вийшло без сучка:

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

Схоже, звідки я стою, це працювало чудово. Ось журнал:

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

Я не впевнений, як діяти далі. Це означає, що всі мої дані втрачені ????????

Вдячний будь-який внесок!

Я знайшов рішення і відчуваю себе дурним за те, щоб пропустити це. Дякую вам, хлопці, за ваші відповіді!

Я перевірив зображення на наявність помилок, а потім змонтував без проблем!

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

Він виправив помилки, потім не встановив жодних проблем з:

sudo mount /dev/sda2/backup.img /mnt/recoverydata

Створене вами зображення буде містити всі несправності вашого оригінального диска. Тому ви, ймовірно, не можете його встановити чи прочитати. Спосіб продовження - це завантаження цього зображення в улюблений інструмент відновлення даних .

Ми маємо хороший досвід роботи з Testdisk / PhotoRec, але є й інші інструменти, які варто згадати, наприклад, Найперше.

Дивись також:

• Як відновити видалені файли?
• Посібник з тестових дисків
• Посібник з PhotoRec

Ось що мені довелося зробити в подібній ситуації - якщо хтось наткнеться на це питання, як я.

Моє зображення також не монтується, генеруючи ту саму помилку (поганий суперблок). Однак fsck також не вдався до наступної помилки:

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>

Прочитавши DataRecovery (посилання, надане Таккатом, спасибі!), Я спробував таке, і воно спрацювало:

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

Це дало такий результат:

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

Потім я помножив 63 на 512, щоб отримати 32256 і змонтував зображення так:

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

Я сподіваюся, що це допомагає і комусь іншому.

Окрім відповіді Такката, я хотів би запропонувати ще один можливий підхід. Зважаючи на те, що ваше зображення майже напевно пошкоджене, можуть бути деякі дані, які інструменти відновлення даних не можуть адекватно відновити.

SpinRite вирішує цю проблему по-іншому. Замість того, щоб оперувати зображенням, він вправляє диск, щоб отримати більше даних, ніж звичайні інструменти можуть відновити. Я використовував його, щоб значно збільшити об'єм даних, що підлягають відновленню. Якщо вам пощастить, ви зможете після цього нормально змонтувати диск досить довго, щоб зробити належну резервну копію.

Хоча SpinRite є головним недоліком. Це коштує неабиякої кількості грошей. Якщо інші інструменти працюють для вас, тоді заощадите свої гроші. Але якщо вам потрібно більше, SpinRite, безумовно, варто спробувати.