In your original post you have told us you have a partition with errors and that when you connect it to another PC it freezes the OS. You have not told us what events led to the partition or disk malfunctioning (and oddly enough nobody asked either) nor any 'dmesg' or Syslog or 'fsck.vfat -lnvV /dev/sdc2' output. Mounting the partition in read-write mode and accessing it in KNOPPIX to copy directories should not have been done. Copying from if=/dev/sdc2 to of=/dev/sdc1 only works if sdc1 is equal to or larger in size than /dev/sdc2. Uber-slow filesystem access could point to errors in the filesystem but also to disk hardware trouble.


Just in case it didn't get through what others told you:

NO.

DON'T EVEN THINK OF FIXING THINGS ON THE "VICTIM" DRIVE.

MAKE A BACKUP (to file) FIRST!


Before you use ddrescue notice that your dd command stopped at aprox 58GB so let's tell you there's more tools with different features than ddrescue. You just got to know them: dd_rescue, ddrescue, dcfldd or rdd-copy (find most of them on the HELIX Live CD) all allow for read retries. dd_rescue adds reverse direction copying or resuming operations, dcfldd and rdd-copy offer hashing, verification or native file splitting, plus rdd-copy also offers native client-server and compression support.

Note these tools are used to get the data off the disk as much intact as possible, not for recovery in the sense of "fsck" or "undeleting". There's lots of threads at LQ about "undeleting" based on header / footer carving with tools like Photorec, Foremost, scalpel or other forensic tools. See for instance here, here and here. Because every situation is unique (read-writes between acquisition and recovery, journalling, on-disk filesystem structure leftovers, HW probs), it's good (or sad) to know members have had good results using Photorec but in the end no tool comes with the ultimate guarantee for recovery.


That said your first priority is making a backup of the partition to a file on another physical disk. Boot HELIX or KNOPPIX. Do not mount the "victim" drive. Attach another internal disk or an external USB or firewire one. Create a ext2 partition if necessary (make sure the image of /dev/sdc2 would fit) then mount it. If you chose to use dd_rescue over ddrescue for it's reverse-reading capabilities run 'cd /tmp; dd_rescue -r -l /tmp/dd_rescue.log -o /tmp/badblocks.log -A -f -v /dev/sdc2 /mountpoint/other_physical_disk/directoryname/rescued_sdc2.dd &' but before that please check "README.dd_rescue" to see what the switches mean and if they apply to your version.

HTH

thank you unSpawn
why "Mounting the partition in read-write mode and accessing it in KNOPPIX to copy directories should not have been done"

I thought, that's the only solution!!!

About the HDD. It's 1tb Freecom, 2 partitions, different formating, one Mac Extended, other FAT32, so problems with FAT32, because the other partition working fine I hope that Hard Drive not mechanicaly damaged.

How it's happend. Unmounted both partitions as usual, and both icons dissapeared, but the screen saying that hard drive can not be unmounted because drive is in use. There was no any programs on, and icons were gone. I still used computer for some time, and switched it off later. Next day switching on Hard Drive, only Mac Extended partition appeared. From then I'm trying to find solutions.

I did scan with TechTool Pro 5 (on mac) and it showed 2000 bad blocks. But I cannot recover from FAT32 using that tool. So probably will try photorec as few people mentioned it.

and only partition the same size 500GB I have it's on the same faulty HDD.

So something was accessing the disk and you might have turned off the computer while it was still accessing the disk. If the disk is mounted as /dev/sdc and the VFAT partition is /dev/sdc2 please show me the output of running (non-destructive) 'fsck.vfat -lnvV /dev/sdc2'. Adjust device and partition names if necessary.

sorry, I'm newbee in Linux and Terminal,
how do I find how the disk mounted? and VFAT partition?

just type MOUNT in terminal???

and how do I run (non-destructive) 'fsck.vfat -lnvV /dev/sdc2'???
should I just type fsck.vfat -lnvV /dev/sdc2 in terminal?

if I understand it wright, I have:

knoppix@Microknoppix:~$ fsck.vfat -lnvV /dev/sdc2
dosfsck 3.0.8 (23 Jan 2010)
dosfsck 3.0.8, 23 Jan 2010, FAT32, LFN
open: No such file or directory
knoppix@Microknoppix:~$

when I do "mount" :

knoppix@Microknoppix:~$ mount
rootfs on / type rootfs (rw,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/sr0 on /mnt-system type iso9660 (ro,relatime)
tmpfs on /ramdisk type tmpfs (rw,relatime,size=1048576k)
/dev/cloop on /KNOPPIX type iso9660 (ro,relatime)
unionfs on /UNIONFS type aufs (rw,relatime,si=7c90e372,noplink)
unionfs on /home type aufs (rw,relatime,si=7c90e372,noplink)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
tmpfs on /UNIONFS/var/run type tmpfs (rw,relatime,size=10240k)
tmpfs on /UNIONFS/var/lock type tmpfs (rw,relatime,size=10240k)
tmpfs on /UNIONFS/var/log type tmpfs (rw,relatime,size=102400k)
tmpfs on /tmp type tmpfs (rw,relatime,size=1048576k)
udev on /dev type tmpfs (rw,relatime,size=20480k)
tmpfs on /dev/shm type tmpfs (rw,relatime,size=1048576k)
devpts on /dev/pts type devpts (rw,relatime,mode=1777)
/dev/sdb2 on /media/sdb2 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp850,io charset=iso8859-1,shortname=winnt,errors=remount-ro)
/dev/sdb1 on /media/sdb1 type hfsplus (ro,nosuid,nodev,relatime,umask=22,uid=1000,gid=1000,nls=utf8)
knoppix@Microknoppix:~$

I think you wanted to see this:

knoppix@Microknoppix:~$ fsck.vfat -lnvV /dev/sdb2
dosfsck 3.0.8 (23 Jan 2010)
dosfsck 3.0.8, 23 Jan 2010, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "BSD 4.4"
Media byte 0xf0 (5.25" or 3.5" HD floppy)
512 bytes per logical sector
32768 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
2 FATs, 32 bit entries
61016576 bytes per FAT (= 119173 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 122049536 (sector 238378)
15254091 data clusters (499846053888 bytes)
32 sectors/track, 255 heads
0 hidden sectors
976500252 sectors total
Starting check/repair pass.
Got 6111232 bytes instead of 61016372 at 16384
knoppix@Microknoppix:~$

ANY CLEARNESS?

For a novice you learn fast. Thumbs up!


Luckily there's two FATs so after you're done making backups you could have a go at using testdisk. With the disk remaining at /dev/sdb run 'testdisk /debug /log /dev/sdb'. Select the right disk then select Proceed, Intel PT, Advanced, Boot, List. Now press "q" repeatedly until you exit the application window, review and attach the "testdisk.log". * While in the Boot menu you might have noticed the text "Backup boot sector OK" and the Backup BS button. If you feel lucky feel free to try it but without having made a backup would be poor judgment.

thank you, but not that fast :)







this bit I think I understand, but
especially about "review and attach the "testdisk.log"."

and I still did not managed to make back up from faulty partition, just reading photorec manuals now!

why ???

I assume that unSpawn was referring to the partition you are trying to recover....

If you are trying to do any kind of file recovery, the single most important thing is to avoid doing anything that could cause a write to the disk. Even if you did not intend to write something, having the partition mounted at all is a risk.

This is why people recommend first making a clone before attempting any kind of recovery.

so, if I mount it in read/write mode, there is a chance of faulty disc being damaged even more? or more damage to data?

If a partition (more precisely a filesystem) is mounted, then the system can write to it. Mounting it "read only" presumably gives some protection---unless, for example, there is a system malfunction or crash.

The concern is that any write to the disk will "overwrite" the existing data. Using dd bypasses the normal system and does not require mounting the partition. This reduces the chances of a system problem doing something to further damage your data.

If the disk has physical damage, then simply turning it on creates a risk.

All of this is addressed my making a clone copy, and working with the copy

it's getting a bit clearer :)
ok, dd didn't work for me, so I'm thinking about trying ddrescue
If I know exactly the names of folders on faulty hard drive
can I just use ddrescue to get folder by folder?
how the command line would look like?
if sdb2 - faulty, sdb1 -ok, folder is sdb2/personal files/picture library(sorted) goes to sdb1

??? will that work???

No, 'dd' and alike tools don't work that way.


No. Making a backup to the same physical disk would be ill-adviced.
Please re-read the second part of post #16:
- Attach another internal disk or an external USB or firewire one. If you do not have one go buy one.
- On that disk create a ext2 partition, then mount that partition.
- Run 'dd_rescue -r -l /tmp/dd_rescue.log -o /tmp/badblocks.log -A -f -v /dev/sdb2 /mounted_other_disk/sdb2.dd' to start backing up /dev/sdb2 back to front.