Hi I'm new here and I have done something really stupid. In an attempt to test the performance of a couple of drives on my Debian server I ran the following commands....
dd if=/dev/zero of=/dev/sda bs=1000000 count=512 dd if=/dev/zero of=/dev/sdb bs=1000000 count=512 dd if=/dev/zero of=/dev/sdc bs=1000000 count=512 ...not very smart since this wiped out the first 512mB on each of the drives.
I have managed to recover most of the data on the sda drive using Stellar Phoenix Linux recovery but I have problems with the other two

sdb: This is a 1,5TB Western Digital WD15EARS with GPT and EXT2
I guess I need to try and recreate the GPT tables to recover it?
Stellar finds nothing on it...
gdisk Repairing GPT Disks claims there is nothing faulty with the partitioning table. The GPT tables are there and the MBR is protected
Testdisk claims it finds "MS DATA" on the in sector 38 to the end of the partition. I'm pretty sure the file system should be EXT2 but now I'm starting to doubt myself.
I then ran TestDisk and in "advanced" I force EXT2 and ask to find backup superblocks. Yep find several. Now what?
Should I make a raw copy of the drive using dd and run fsck /f on the copy and hope if fixes the filesystem?

sdc: This is a 2TB WD20EARS with a normal MBR primary partition and EXT2 fs
Trying to scan this disk with Stellar Phoenix Linux recovery the software crashes. I have had these up with Stellar Phoenix support and after some emails back and forth they said I needed to send both drives to them for diagnostics. Since they are limited to their own software and I'm not very keen on sending my drives to India I'm now here.

I have access to r-studio 4.2 at work could this maybe to the trick? I'm not a noob with computers but file systems is really not my forte so I need all the help I can get.

Thanks in advance!

Maybe. It won't hurt to try.

_________________
http://www.northwind.gr
SandForce SSD Recovery
Ransomware Reverse Engineering - NoMoreRansom! partners

First thing you should have done, make a clone. Always work from a clone.
that’s the first thing you have to do make a clone
with the clone you can do a "fsck.ext2 /dev/sdc" On a linux machine of-course. knoppix cd will also do. because you screwed you’re partition everything is rebuild
Everything that can not be related to the / is placed in lost&found.
The super-block is overwritten. There are several copy of it exponential spread out on you’re partition.

Yeah figured it would be stupid to test things on the drive I messed up. I now have a completely new 2TB WD2002FAEX drive I plugged into the Linux machine together with the WD15EARS.
WD2002FAEX = /dev/sda
WD15EARS = /dev/sdb
None of them mounted of course
I have tried cloning the WD15EARS to the WD2002FAEX with the following command
dd if=/dev/sdb of=/dev/sda
dd runs for a while and then I get:
dd: writing to `/dev/sda': Input/output error
6160449+0 records in
6160448+0 records out
3154149376 bytes (3.2 GB) copied, 294.117 s, 10.7 MB/s

I have tried 3 times. Every time it halts after exactly 3154149376 bytes. Could I be in such a bad luck that the new WD2002FAEX I clone to is faulty? If it has a bad block or something can I work around that?

Edit: Hang on to that thought. I'm going to try ddrescue first

How are these drives connected to the PC - SATA or USB or something else?

Run dmesg and look at the end of the output ie the most recent kernel messages. Those may give more info about whatever problem is happening when trying to write to /dev/sda.

I would also suggest you check whether that new drive is correctly recognised - again, one place to look for that is in the dmesg output, except that will be earlier in the messages (wherever sda was detected).

The chosen dd command line is not the most efficient IMHO, but that discussion can wait until later...

Edited to add: Just saw your edit & your plan to use ddrescue. That would be sensible if the reported problem was a read error on /dev/sdb (based on your report of the device node assignments to the disks) - but it isn't. Anyway, I'll go and do something else while you're troubleshooting

Vulcan
Both drives are connected to a SIL 3114 PCI SATA adapter. According to dmesg both drives were recognised correctly. No trace of messages about the write error.
output from running ddrescue
Frigg2:~# ddrescue -v /dev/sdb /dev/sda

About to copy 1500 GBytes from /dev/sdb to /dev/sda
Starting positions: infile = 0 B, outfile = 0 B
Copy block size: 128 hard blocks
Hard block size: 512 bytes
Max_retries: 0 Split: yes Truncate: no

Press Ctrl-C to interrupt
rescued: 1500 GB, errsize: 4096 B, current rate: 0 B/s
ipos: 914442 MB, errors: 8, average rate: 27062 kB/s
opos: 914442 MB

Looks like it might was a good choice anyway since there were read errors on the drive?

So next step would be to find a superblock copy and do a fsck.ext2 -b #### /dev/sda1 - where #### is the location of the first good superblock copy? Should I run fsck with "/f" as well or do I need to be careful about what to fix?

Thaanks for the info about the SATA connection. If there had been an I/O error accessing either sdb or sda, there would have been a message in the dmesg outout. Therefore based on my experience, I cannot just accept your statement that there was no relevant message. But it's not important now that you're using ddrescue.

Yes, ddrescue is showing there are read errors on sdb. However, whenever I mention using ddrescue (which I didn't do in this case, as you chose it first ), I always mention the challenge of using it efficiently/correctly, if you have no previous experience with it. The ddrescue defaults are usually sub-optimal, and unfortunately you're making a typical beginner's mistake of not using a ddrescue logfile, so you don't know where the unreadable sectors are, to force further retries on them later. (Assuming that /dev/sda was not zero-filled at the start.) Based on previous experience, I don't usually give detailed remote ddrescue assistance, as it is too inefficient due to the number of things to take into account in the decisions.

There are several options about how to proceed from here, depending on factors like what storage space you have available for keeping multiple clones, what time you can spend on this, what risks you want to consider about whether the drive will deteriorate before being able to clone another separate copy etc. etc. I suggest you do some reading about ddrescue including some of the available tutorials on the web.

I would suggest to make another copy from the clone before doing a "fsck.ext2"
looks like the hdd is dying.

Restore the partition with testdisk
and than do a fsck.ext2 /dev/whateverisyourepartition

I agree that making any changes to the only clone from a failing disk, is risky (the clone might become the only copy, if the original disk fails catastrophically), but personally I don't agree with just making another copy of the imperfect clone which the OP is now creating,

Assuming that the OP is continuing to take the risks of DIY, then if the OP has the storage to make another clone (hence my earlier comments), then trying to make a better clone first, by improving the use of ddrescue, would be my aim. Only when the best possible (DIY) clone has been produced, would I move on to the next stages. Of course others may have different views.

OK so what I should I do then rerun ddrescue like this
ddrescue -v -l /ddrescue_sda.log /dev/sdb /dev/sda

or should I consider making /dev/sda a part of the file system on the Linux box and make the clone an image-file instead?
or are there more options I should use?

At the moment the amount of space to store clones is limted but since I want to move away from WD15EARS I'm planning to add another 2TB 2002FAEX and then will have 2TB more disk to store clones on while I work on this.
Time is not a factor since I have no customer hanging over my shoulder to get some stuff back. This is all done to try and get my personal data back as well as learn some new things. My day job is in networking so this is a bit out of my league still I really would like to try and get this data back. It's anything from old sports broadcasts to my old 3D models on these drives.

I think the best thing you can do is to practice is on a small partition.
make a ext2 filesystem on a small hdd. Put some stuff on it
do the same thing you did when you wiped a few sectors.
See if you can restore it with testdisk. If you can do it on a small scale ...

success

@Signify,

In brief:

I haven't seen any update about the result of your previous cloning attempt. If it was not totally successful, then I would be focussing on getting another, better clone (without overwriting any imperfect clone you already have). This would need more empty disk space, but it seems you don't have room for that yet.

Your suggested ddrescue command line doesn't match anything in my experience (are you sure the order of those options is correct - check the examples in the ddrescue docs or, as mentioned on another recent thread, in the Testdisk docs), but unfortunatey I don't have time to do an interactive walkthrough of ddrescue remotely.

@Signify:

I just remembered something:


I think that is the syntax for dd_rescue (the Kurt Garloff utility), and not for (GNU) ddrescue (the Antonio Diaz utility), hence my earlier concern about this command line.

Some people still use dd_rescue - I stopped doing so many years ago, and moved to using ddrescue. IMHO you need to make it clear which one you're using, to avoid confusion / ambiguity. Yes, having such similar utility names invites confusion.

Sorry about the delay I have not had time to do more on this. I'll read up on GNU ddrescue now that I know there are two programs with almost the same name. You are correct I read the wrong manual. Just to be clear it is GNU ddrescue that I have and attempted the first time.

Finally come around to fix this

Booted my normal workstation with a Knoppix USB

Managed to clone the 1,5TB WD15EARS to another disk with
ddrescue -r-1 -n -v /dev/sdx /dev/sdx WD15EARS.log
Took me a good 6 hours but no errors

Unhooked the original
Fired up Gparted GUI,
Got an error message about the GPT table was in the wrong place. Fixed automatically
Now I got myself a broken ext2 partition. Getting somewhere
Ran fsck -f from inside Gparted on the partition. 1 hour later I had all the data nicely bundled up in Lost+Found

Now time to tackle the WD20EARS