Hi peeps,

I just managed to make an image of my failing HDD (ST3160815AS) using Ubuntu-Rescue-Remix Live CD. However, I'm not being able to recover any data from the image, at all.

This HDD has 2 partitions. On the 1st partition I had installed Win 7 Ult. (x64) and the 2nd one has my valuable data, which I desperately need to recover. The image I created with ddrescue is in raw format and contains the whole disk, ~160GB. Although, the image has plenty of errors since ddrescue couldn't recover about 12MB data from the bed sectors. Ddrescue log viewer indicates that all bad sectors are located in a particular section of the platter, which I assume may help to have more positive outcome in recovery?!!!



Speaking of recovery, I used almost any tool/software I could find on the net to try and recreate the damaged file system and lost partition table on this image, to no avail. I also tried, simultaneously, to scavenge at least some of my data with testdisk, photorec, runtime getdataback NTFS, R-Studio, etc. and the bestt success I had so far is the recovery of some corrupted .jpg files that were of no real benefit. Runtime GetDataBack NTFS, at least I thing managed to identify the 2 partitions, but when it went to analyze the chosen file system it has found in the previous step, started to shoot "Access violation at address...." error.




I ignored all the errors, and it went searching for files. A few min later I could see a bunch of directories with cryptic naming that had some files/folders inside of them with real labels which I could recognize. Unfortunately I couldn't recover NOTHING of all the files I wanted. They were all corrupted when I thought for a split sec. I would have my data back... .

I came to this forum to ask if any of you experienced folks here know if I can approach this issue with recovery in a different way with a different tool set which I'm not aware of, before giving up and taking the loss.
Any hint, any clue, any advice is very much appreciated...I'm more than willing to try!!!
Thank you
TM

Can you see all the files and folders in the first partition, and are they all intact?

_________________
A backup a day keeps DR away.

IIUC, you have cloned your 160GB HDD to a 160GB image file on a 250GB drive. You are now trying to mount the recovery tree for what you believe to be the second partition in your 160GB image.

I don't use GetDataBack, but ISTM that the two detected partitions span the following sector ranges on your 250GB HDD:

Partition #1 - sectors 19954129 to 183794121
Partition #2 - sectors 163842033 to 312575977

AFAICS, the second partition overlaps the first, which suggests that GDB may have detected a remnant of an earlier installation. Therefore, instead of sector 163842033, I would be looking for a boot sector at 183794122 or later.

_________________
A backup a day keeps DR away.

Yes, I can see the indexes/references of all the files and folders correctly in the 1st partition (primary bootable partition, 78.1GB). However, I can't access the files if I try. Likewise, I can see the folder tree in the 2nd partition (logical partition, 70.9GB), where my data are stored, but again I can't recover them at all. So I guess they are not intact...

Also, I have noticed that recovery tree in the 1st partition contains some of the same directories that reside in the 2nd logical partition. This is a little confusing to me, since I don't remember having duplicate copies of my data in the boot partition. Why GDB is listing some directories in both partitions?!!!




Yes that's how I did it. Since I didn't have a spare same size healthy disk available, I created an image file (not a clone) of the 160GB damaged disk inside a 250GB HDD using ddrescue, like this:

2nd pass:

3d pass:


When all finished I made a 2nd copy of the image file in the 250GB disk to another 3rd HDD. Since I dont have another spare HDD handy, I decided to copy this image back to the same 250GB disk, but this time not as image file but mounted as a real HDD. I know sounds a bit cumbersome and inefficient way of doing it but AFAIK testdisk can't read from an image file when I attempted recovery the 1st time. So cloning the image to HDD seemed to me as the logical step to make, at the time.

OK, I have updated the recovery approach, and now I'm attempting to recover from the raw image alone.I'm accessing the image inside my Win 7 OS with the same tool, GDB NTFS.

Based on new analysis of GDB, by comparison, I see no difference in the total size of sectors in the image file vs the cloned image on the 250GB disk I had previously.So I guess GDB is reading only the data spanning up to 160GB in size regardless if the image is cloned on a disk or accessed as raw file...if my observation is correct. And I still get the same "Access violation..." error when it tries to search for data inside the system file.





Do you mean I should try rebuilding the partition table as a 1st step to recovery?!!! And what method should I use and what tool may be a good option to repair the partitions?

DiskExplorer for NTFS reports invalid Partition Table for the image in question, but I guess it has identified a few valid boot sector(s). How can I use these findings to my advantage, any suggestions?
Thanks...

Hi, again...

I gave it another try to find the partition table on the sector range, 183794121 --> 312575977, as per your suggestion. I used DMDE this time since it comes with a nifty option to search in a particular area of the image...However, after search completed it found 7 volumes but, to my understanding, it didn't find any partition sector or a valid system file.

I went ahead and opened one of the volumes with the largest size. On the next screen, the directory tree listed some folders and files which I could recognize based on their naming, but again were non recoverable.




Thanks, and Happy New Year...

I confess I'm still confused. IIUC, you ddrescue-d a 160GB patient HDD to a 160GB image file on a 250GB HDD. You then copied this first image file to a third HDD as an image file, and you finally ddrescue-d the copied image file to the second HDD as a sector-by-sector clone. This means that the first 160GB of the 250GB HDD should be a sector-by-sector clone of the patient HDD. However, it doesn't look that way.

For a start, the two partitions should not overlap. Secondly, the first partition should normally begin at sector 2048.

To make matters more confusing, the command line that you say you used does not do what you think it does.


AIUI, the above command line clones physical drive sda to physical drive sdb and writes the log to a file named "image" in the current directory (assuming that ddrescue doesn't complain about the superfluous "log" parameter at the end).

That said, ddrescue's log viewer screenshot would suggest that a file named "log" was in fact created, so perhaps you mis-remembered the command line in your post.

If we take the range of sectors for your first partition (19954129 - 183794121) and shift them so that the partition begins at 2048, then the range becomes 2048 - 163842040. The second partition begins at 163842033 rather than 163842041, so this still isn't quite right, but it does suggest that there was a problem with your cloning procedure.

Edit: Is there an MBR and partition table in sector 19952081 (= 19954129 - 2048)? If so, could we see it?

_________________
A backup a day keeps DR away.

Yes, that's correct!!! The command line written in my previous post doesn't show the cloning procedure from the get go. I thought it wont be necessary to give all the details of the rescue process since I have surpassed that step successfully, I believe.I'm more interested in recovering data in post-cloning steps, and thus my first post is all concerned in recovering data from the image file spat out by ddrescue. But here it is from the start for better understanding of my situation (though,it may not be fully accurate as I kept no record of all the commands I used while inside the command-line world of Ubuntu).

From the above command I have "/dev/sda" as destination for writing the image files.Then I reformatted the healthy disk, like this:

When finished formatting, I created a folder "recovery" and inside of it mounted the drive executing these commands, one by one:

Then I started using the recovery commands written in my last post with only one correction though, "/dev/sdb" being the source drive.Indeed, what you see there is what I used in a nutshell (so to speak) and doesn't represent the entire route it took me to come all the way to here...
Now, concerning the 1st command I wrote in the previous post, I'm 110% sure I have used it as the 1st attempt to recover as much data as possible, skipping bad sectors, hence "-n" switch (--no-split). However, I cant remember if that command was understood by ddrescue or not!!! I have interrupted the rescue process many times and tried a little less than a dozen different command lines all the way through and can't tell exactly which of them produced the desired results and which just simply didn't do anything. I mostly tried common commands that are used by other people on the net with the same issue as mine. I'm just an end-user in the HHD world and can't pretend I have technical knowledge on how to recover broken HDD's even less understand weather a line of code is good or bad for certain tasks. It's over my head, really...
Nonetheless, I managed to find a screenshot of the rescue process (somewhere close to the end of recovery period of about a month) taken with my cellphone. It'll help you see a glimpse of what I have done and I hope to receive better feedback...



Partially correct!!! What I did (after I copied the image file to a 3rd HHD) is mounting/cloning this image back to 250GB disk. Of course, overwriting everything what's left in there from ddrescue job (raw image + log file). But I used a different software and not ddrescue as you guessed. I used "Active Disk Image" from within Windows platform to clone the raw file which I believe was a "sector-by-sector" clone.
Well, the reason I went with this sorta "awkward" method, is because as far as I know testdisk can't recover from raw image file contained inside a folder on a Linux (ext3) formatted disk. So instead, I used testdisk to "recover" just the folder named "recovery" which has the image + log file residing on 250GB HDD straight to my NTFS formatted HDD or the 3rd disk as we call it.
It seemed logical to me to clone the image file back to the 2nd HDD and then use testdisk on it to recover data. However, testdisk wasn't of any help which forced me to resort to other tools/software for a different/better possibility of recovery.



By the way for your info,the 3rd HDD has actually 2 partitions as well. One is the active boot partition which contains my Win 7 x64 OS and the 2nd one (logical NTFS partition) where my image and log files are resting at ATM, needing recovery.

All right, but I'm not focusing much on recovering the 1st partition (boot partition) as I'm sure I have nothing valuable inside that one...well, unless I see that some of my data have slipped onto the 1st partition due to overlapping.

No. I did not misremember what I gave ddrescue to execute, but as I mentioned It might not have been a proper command which I can't remember if that's the case.I'm unable to recreate the outcome of this particular code, ATM.So, I'll assume based on your comment that this is not a valid one...? Also, did you mean "superfluous" as being more ambiguous or rather unnecessary. If I left "log" argument out of the line I could not have interrupted the rescue without starting it all over again,could I? It, also helped me understand where all the bad sectors are located in the platter that it couldn't clone.
Hopefully, it makes your job helping me a lot easier and more focused. BTW, thank you v. much for helping me, so far...

Hmmm....what could it be, I wonder?!!! Cloning procedure...If smth. wrong with cloning there couldn't be any data showing at all on the recovery tree. I can see the references of almost all the files and folders I have stored on that partition. It makes me believe I don't have the right combination of tools and the know-how to brake it...

Sure!!!Is this what you looking for?

Thanks for the detailed feedback.

AIUI, you are saying that your initial partition layout was as follows:


Sector 0 is the location of the partition table, and sector X is the location of the first boot sector, eg sector 63 or 2048.

However, GetDataBack appears to be telling us that the clone looks like this:


Obviously this configuration is invalid, so if your cloning procedure produced an exact copy of the patient drive, apart from the bad sectors, then the patient drive must have had a logical problem in addition to the physical one. Did you use a partition editor to move, merge, or extend your existing partitions? Or did you delete the first partition, and has GDB now found a phantom partition that is a remnant of an earlier installation?

If the file systems had been intact, then sector 0 would have had a valid partition table, yet TestDisk is telling us that this sector doesn't have an 0xAA55 signature. Your opening post did not suggest that your "failing" drive had any hint of a logical problem, and that all the bad sectors were in the second partition, so why is sector 0 corrupt?

_________________
A backup a day keeps DR away.

Perhaps we should examine the image file on the third drive. You could use a hex editor such as HxD (I expect that GDB would be able to do this, but I don't have any experience with it).

Could you show us the first 0x200 bytes of the image file?

_________________
A backup a day keeps DR away.

I'll admit, I haven't read the entire post (I'm not that patient unless I'm getting paid ) but might I suggest that possibly you first cloned to an image file using ddrescue, then the second time you used ddrescue you cloned not the image file, but the entire drive containing the image file to the other drive (thus grabbing it's partition table instead)??? It's just a though. Seems to me that you've really overcomplicated this one.

Do you still have the original drive or the image file? Perhaps it'd be easier to just start over from the beginning to cut down the chances that you're dealing with issues you created in the process.

_________________
Data Medics - Hard Drive, SSD, and RAID Data Recovery Service Company

TestDisk is reporting that sector 0 of the clone does not have the required 0xAA55 signature.

If I could see sector 0 of the image file, then I would know where to find the boot sectors of each of the two partitions. I'm wondering whether Active Disk Image was able to correctly interpret ddrescue's image file. Perhaps ADI stripped off a few sectors after misinterpreting them as a header??? This would have resulted in a shift in both partitions.

_________________
A backup a day keeps DR away.