sorry for being annoying, in this command /mounted_other_disk/ would be /sdc/ ??? just don't want to make mistakes.

and new disk has to be the same size? obviously..

It's not an annoying question. The "/mounted_other_disk/" location is the directory name where you have mounted the clean, empty partition of the harddisk (that is: not the victim drive) you are going to write the backup file to. And that partition better be larger than the "victim" partition.

ok, I bought another 1tb external HDD, supposed to be delivered tomorrow,
and borrowed another computer with linux installed, it is Ubuntu
so tomorrow will try ddrescue

I'm not sure do I need to install ddrescue, or it should work on that computer?

and is new hdd, in where I'll be rescuing data has to be formatted FAT32, or it is does not matter???

Note that ddrescue and dd_rescue are different commands. The command line suggested by unSpawn is for dd_rescue which may be a better choice for you than ddrescue. (I've been talking about ddrescue in this thread only because that's the tool I've used. But my problems have been with removable media - old floppy disks and CDs - not hard drives.)

yes, thanks, ddrescue and dd_rescue - are not the same
I manage to install dd_rescue! that was an expirience
Installing ddrescue is easy, just one command (apt-get install ddrescue)

everithing ready now...
so, how about new HDD, does it have to be formatted FAT32 like faulty? or it does not matter?

If that's a "tar-ball" of the source code you can put it anywhere. But you'll then need to unpack the "ball" (ark <ball name> usually works, but look at man tar for the command line method) and then compile and install it, usually:(Which often creates lots of output, but you can ignore it unless you get an error (not warning) message.)

Note that you'll need to install a complete development environment (if you haven't already done so) before you can compile anything.

I was just using dd_rescue on some floppies that ddrescue had problems recovering, and I was unpleasantly surprised when dd_rescue did not do as well as ddrescue had.

For your edification, here's what I was running to recover damaged floppies (taken, almost verbatim, from the info ddrescue file:Now you want, instead, to "rescue" your whole sdb drive onto your new sdc drive. For that, I'd suggest something like this (comments indicated by "#" after the prompt - which is also a "#" when running as "root"):Note: The above code is untested. Use at your own risk!

Good luck, and keep us posted.

well, I've got new HDD, formatted it as ext2
so, my faulty disk dev/sdc2
mounted other disc /media/disk

I'm trying dd_rescue. Command looks:

dd_rescue -r -l /tmp/dd_rescue.log -o /tmp/badblocks.log -A -f -v /dev/sdc2 /media/disk/sdc2.dd

it's running... fingers crossed...

Good luck!

I was working on some tips and instructions but since you're already working on it I'll add it only for future reference:


8<------------------------------------------------------------------------------------------------------------------------------------
You're going to make a bit-by-bit backup to file so I suggest ext2 (as you won't need journalling) as VFAT has a 4GB file size limit while ext2 reaches 2TB (4TB with kernel >= 2.6.17).

* Before you start you should confirm the "victim" drive is not powered on (disconnect the molex) if you suspect failing hardware (and you should unless you can confirm otherwise) to save it from seeing too much spin up/downs until you need to work on the drive.

** When you add your new 1TB disk note the brand and type and make sure you add it to the other IDE channel, not the one the "victim" is on.

- After booting up your OS you can pinpoint the drive using 'fdisk -l' as no partitions or file systems should be shown for the new drive (and run 'hdparm -i /dev/${DEVICENAME}|grep Model' to confirm). Let's assert the new, empty 1TB drive is located at "/dev/sde": run 'fdisk /dev/sde', type p (print partitions to confirm), type o (create partition table), type n (add partition) and make it number 1, primary and allow for defaults so the partition spans the whole disk, type t, select 1, make it 83, type w to write. After a reboot your new disk is ready to be formatted.
- If the new, partitioned 1TB drive is still located at "/dev/sde" (you know how to confirm it is) run 'mkfs.ext2 /dev/sde1; tune2fs -m 1 /dev/sde1; fsck -fv /dev/sde1' to create the ext2 file system, set reserved blocks from default 5 percent to 1 percent and then check the partition just in case.
- Power down, attach the "victim" drive molex and boot up (preferably in runlevel 1 to save CPU cycles). With the old "victim" drive at "/dev/sdd" and the new 1TB drive at "/dev/sde" run 'mkdir /salvage; mount /dev/sde1 /salvage -o rw,noatime,nodiratime' to mount the partition.
- All is now in place to run the salvage operation with 'dd_rescue -r -l /tmp/dd_rescue.log -o /tmp/badblocks.log -A -f -v /dev/sdd2 /salvage/sdd2.dd 2>&1 | tee /tmp/dd_rescue.tee'.

*** If you run the operation you may want to start it by first running 'screen' before you run dd_rescue. This way you can easily switch between virtual terminals and run for instance 'pgrep -lf dd_rescue' in a second one to see if it's still alive and 'tail -f /tmp/dd_rescue.log' in a third one to check progress from dd_rescues point of view.

**** After the op is done don't forget to 'cp /tmp/dd_rescue.log /tmp/badblocks.log /tmp/dd_rescue.tee /salvage' before you 'umount /salvage' for future reference.
------------------------------------------------------------------------------------------------------------------------------------>8

I'm not sure how to post screenshot here, but if you take a look at this:

http://img222.imageshack.us/img222/8185/screenz.png

it's not stopped, numbers keep rolling, but succxfer: 431582546.0k is constant

the new 1tb hard drive seems actively working, but
faulty one sdc2 seems very quite and does not make a sound

well, I wait until it stops

It's stopped, the last screen:

Summary for /dev/sdc2 -> /media/disk/sdc2.dd:
dd_rescue: (info): ipos: 0.0k, opos: 0.0k, xfered: 488250126.0k
- errs:113335160, errxfer: 56667580.0k, succxfer: 431582546.0k
+curr.rate: 235kB/s, avg.rate: 2108kB/s, avg.load: 0.2%

what should I do next?

I can see file sdc2.dd size 465.6 GB, do I need to mount it? what command line should I use?
and should I try testdisk on faulty hard drive now?

"succxfer" means "succesfully transfered amount of data", so that's OK.


Nice. Salvaged most of it. I hope you saved all logs as well per my previous reply?


If you want to mount it, in case you would want to fsck --dry-run /media/disk/sdc2.dd then run 'mkdir /mnt/mountpoint; losetup /dev/loop0 /media/disk/sdc2.dd. Now you can run 'fsck.vfat -nlvV /dev/loop0'. Now to mount the image to access file contents proceed by running 'mount /dev/loop0 -t vfat /mnt/mountpoint -o ro' and see the "/mnt/mountpoint" directory. This may not work if FAT is damaged (as suspected): see 'dmesg' output if the mount command errors out.


If you want to use Photorec to try to recover files by type then you do not have to mount the device. You do require storage to be available (in excess of 500GB, depending on your recovery options using Photorec). If the new 1TB disk has only 1 partition that spans the whole disk you could make a directory there: 'mkdir /media/disk/undelete' then just supply the image name on the commandline: 'photorec /log /debug /d /media/disk/undelete /media/disk/sdc2.dd', then select Proceed, Intel, File Opt, press "s" to disable all file family recovery options. Now only select (space bar) the extensions or file types for the files you would like to prioritize finding and press "q" to return to the menu one level up. Now select the appropriate options for your machine and selected file types and press "q" to return to the menu one level up. Now selecting Search will make Photorec go in and try to retrieve data. * Depending on what files or file types you want to recover your recovery strategy may involve different runs with different settings and siphoning off data from the output dir in between runs keep available disk space at a usable level.

If you want to use testdisk to examine the file-system or to recover files one by one then you do not have to mount the device either: 'testdisk /log /debug /media/disk/sdc2.dd'. Select Proceed, None, Advanced, Undelete. Now you can "walk" the file-system tree as far as it is readable and copy files out of the image.


HTH and again: good luck!

Please note that "fsck.vfat -nlvV" does a verification run on the partition but does not change anything but only because of the "-n" switch. Do not, I repeat DO NOT run fsck w/o the "-n" switch as this will alter your backup file and irreversibly so. If all recovery operations fail then you could choose to run testdisk (rather than fsck) on the original partition on the "victim" disk in a last ditch effort to see if it can access the second FAT table to replace the first FAT. But please do not do that until all other options have been exhausted!

do you mean *** from post NR.38

then /salvage in my situation /media/disk/sdc2.dd ???

I did not understand what that will do. And if it will "save logs" , where will they be saved? Just don't want to miss something.

and Mac OS X can not see ext2
so I still have to deal with Ubuntu - system I have no clue about
I have photorec and testdisk on Mac. Have to install it on Ubuntu as well

and again sorry for too many questions. as I understood biggest job is done. dd_rescue did work and I have to be happy. but untill I can't see results, I'm in doubt.

thank you unSpawn, great help.

I tried it, when type: 'mkdir /mnt/mountpoint losetup /dev/loop0 /media/disk/sdc2.dd'

mkdir: cannot create directory '/dev/loop0' : File exists
mkdir: cannot create directory '/media/disk/sdc2.dd' : File exists


what do I do wrong?

Yes.


No, in post #38 I explained how to mount the partition on the new 1TB drive. You have your new 1TB drive mounted at /media/disk so you could 'cp /tmp/dd_rescue.log /tmp/badblocks.log /tmp/dd_rescue.tee /media/disk' before you 'umount /media/disk'.


There is no "it": you have to copy the logs manually.


Unfortunately I forgot to separate the two commands. The right line should read 'mkdir /mnt/mountpoint; losetup /dev/loop0 /media/disk/sdc2.dd'. Note that "/mnt/mountpoint" is just a name placeholder. If you want to call it "/recovery" or "/tmp/disk" or "/mnt/media" that's up to you (OK, unless it exists).