Help With Data Recovery For An External Drive

[TheRedMaverick]

Hello there, I've run into a little bit of trouble with my external hard drive. It's a pretty long story so I'll try to sum it up but still provide as much critical information as I can. I'm not extremely well versed with this stuff so please bear with me

First off, this is the external that I am using http://www.amazon.ca/gp/product/B002QEBMCI/ref=oh_details_o04_s00_i00

I hooked this up to my sister's Macbook to try and help her back up her data because she recently tried to install a new version of OS X Leopard which seems to have bricked her laptop. I made a LiveCD and proceeded to boot up Ubuntu on her laptop. After getting some advice from a friend, I went ahead and did this:



This is a screenshot of the Ubuntu terminal I had running. The cp /dev/sda1 /dev/sdb1 command on the last line is the root of my problems. sda1 is the Macbook's hard drive, and sdb1 is my external drive. After using this command, terminal began working for about roughly 2 seconds, and it seems to have overwritten my external drive's structure and also renamed it from "Elements" to "EFI". This is what it looks like now when I hook it up to my Windows 7 PC:



Now I'm assuming the command I used in Ubuntu may have converted my NTFS partition to a FAT32, but I'm not entirely sure. I've contemplated trying to format the drive to NTFS but from what I've read, it's a risky procedure and I may end up losing data.

I've tried multiple data recovery suites (roughly 8 different kinds) and so far, R-Studio Network Edition and DiskDigger seem to be the most promising of them all. I've recovered most of my data except for a particular file type (.M2TS) which doesn't seem to be supported by a lot of these programs. Here are the scanning results that I get when I use R-Studio:



Recognized 3 is the new FAT32 partition that has some corrupt OS X installation files.

Recognized2 is the partition where all of my files are located intact with the appropriate file names and folder structures, but I can't seem to recover anything properly. When I try to recover a file, you can see what happens in the log found in the above screenshot near the bottom; "Closing attribute: parsed allocated size (#) differ from stored one (#)" and then "Recovering file (file path) failed. Can't read file to be recovered completely (801)."

That being said, I can recover some files from the Extra Found Files part of the scan in the previous screen I posted. It seems that the size of the original file plays a part in which files I can successfully recover or not; the bigger the file is, the least likely I am able to successfully recover it. Images seem to work universally but videos are a hit or miss. I've used another program called DiskDigger which seems to have been able to piece together a lot more files that I had, including videos, except for the notorious .m2ts files I'm looking for. DiskDigger, however, has not retained the structure of my files and folders and has inconveniently labelled all the files found as "sector(#)" where I'm assuming this refers to the sector of which the file was found. I can't complain though, at least I've found some working files

I guess my question to you all is what is my best course of action? Should I continue trying different recovery programs to see if one will happen to successfully recover all my files? Should I attempt to format the drive to NTFS or possibly even delete the FAT32 partition? Am I doing something wrong or missing something completely obvious?

I feel that because R-Studio actually detects my original folder structure and file names that there's still a chance to undo what I did, but that could just be wishful thinking.

Any input would be greatly appreciated!

[labtech]

I am not a Unix/Linux expert, but it seems to me that issuing the commands listed in the terminal should not have caused the loss of the data on the external in the way it shows right now in R-Studio. If you look in the R-Studio manual, the red color of the partition found indicates that only the boot records of the partition are found. This indicates that the old data on the external drive may have gotten overwritten with other new data (from the MacBook), which is sort of consistent with the ...(801) file errors received when attempting to recovery the old files.

Did you run a full detailed scan on the external drive in R-Studio? I believe yes, but asking to make sure.

I am highly confident that more had been done onto the external to bring the drive and the old data to this point. Are you sure no other commands had been issued?

Generally speaking, I do not think much more can be done to recover the old files. What you got so far is likely the best recovery outcome.

[TheRedMaverick]

The only other actions that were performed after the copy command were basically exploring the new EFI files through Ubuntu. I was told by the friend who actually walked me through the Linux part that the copy command, indeed, should not have caused loss of data, but that seems to be the case. Terminal took about 2 seconds or maybe even a bit more to issue that command which threw me off as it usually, with my limited experience with Linux, only takes a few milliseconds. This is what led me to actually checking the status of the external and that's when I saw that it had converted the drive this new FAT32 filesystem.

I ran a full scan which took pretty much 24 or so hours to complete. This is the case for all the recovery programs I used except the ones that lacked the option to do in-depth scans.

[Vulcan]

I was told by the friend who actually walked me through the Linux part that the copy command, indeed, should not have caused loss of data

To be blunt, that's plain wrong - unfortunately that specific cp command is complete madness and is never, ever, appropriate for this situation. Either you misunderstood the instructions from your friend, or you received very bad advice. Based on your story, the current situation is likely to be completely the result of running that cp command.

Some of your interpretations of the current situation are incorrect (e.g. the external disk has not been "converted" to FAT32, despite what Windows shows), but I don't have time now to explain them all. Although there are things that could be tried, to attempt to recover more data from the external drive, there are further risks of human error in the procedures I would consider, and there would need to be long, long discussions first about procedures etc.

In a short summary, all I can say is that if you make any changes to the 2TB disk (e.g. reformatting it, as you mentioned before), you are very likely to make any recovery less successful. So don't do that, at this stage.

If you accept the risks of DIY recovery attempts (i.e. you could make things worse, or lose even more data, and you have to accept complete responsibility for any consequences), then perhaps someone else will have the time to guide you - if not, there is a professional member in Toronto whose services you could use.

Sorry if this reply is not what you had hoped to hear. If it makes you angry, then just ignore... Good luck!

[labtech]

@OP
If you have other resources, as in another external or drive that the data on it is not of importance, you can potentially replicate what had happened with those commands on a new case, so to speak. Then, you can draw some conclusions by comparing one case to another.

[TheRedMaverick]

I was told by the friend who actually walked me through the Linux part that the copy command, indeed, should not have caused loss of data

To be blunt, that's plain wrong - unfortunately that specific cp command is complete madness and is never, ever, appropriate for this situation. Either you misunderstood the instructions from your friend, or you received very bad advice. Based on your story, the current situation is likely to be completely the result of running that cp command.

Some of your interpretations of the current situation are incorrect (e.g. the external disk has not been "converted" to FAT32, despite what Windows shows), but I don't have time now to explain them all. Although there are things that could be tried, to attempt to recover more data from the external drive, there are further risks of human error in the procedures I would consider, and there would need to be long, long discussions first about procedures etc.

In a short summary, all I can say is that if you make any changes to the 2TB disk (e.g. reformatting it, as you mentioned before), you are very likely to make any recovery less successful. So don't do that, at this stage.

If you accept the risks of DIY recovery attempts (i.e. you could make things worse, or lose even more data, and you have to accept complete responsibility for any consequences), then perhaps someone else will have the time to guide you - if not, there is a professional member in Toronto whose services you could use.

Sorry if this reply is not what you had hoped to hear. If it makes you angry, then just ignore... Good luck!

Thanks for that info! I'm not mad, it's more of a learning experience for me. Now I know to always back up my data before attempting anything like this.

I've heard of certain risks involved with data recovery software but after multiple scans, it seems that so far I haven't really done any permanent damage. I'm not getting into the really technical features of these programs (R-Studio seems to be the most technical so far).

I would go to a professional but I guess I'd like to learn more about the process myself and maybe get better at it so I can avoid having to always resort to a professional (not that I plan on doing this again )

[TheRedMaverick]

@OP
If you have other resources, as in another external or drive that the data on it is not of importance, you can potentially replicate what had happened with those commands on a new case, so to speak. Then, you can draw some conclusions by comparing one case to another.

Well after this incident, I've been thinking about getting myself a second external so that could be something I could try out. I realize now that one external is just not enough.

Also, Vulcan, I replied to your post but apparently it needs to be approved by moderators for some reason lol. I'll wait a bit but if not I'll maybe just edit this post to address your post

[Vulcan]

@labtech,

True, the OP could do that test, but I'm confident about the cause likely being the cp command, so they'll just see similar results (if they repeat the original situation closely enough). I've seen people make enough similar mistakes to last a lifetime.

In short, some or all of the old (FAT32-formatted) disk has been copied to the start of the (NTFS-formatted) 2TB disk. Although dd is typically used to do a (deliberate) raw copy, in order to allow control of block size etc. (and assuming no read errors are expected), some people use cp to do this (although that has some disadvantages IMHO). In this situation, the result is the same - the first xMB of the 2TB disk has been overwritten.

You use R-Studio much more than I do, so I'm not disagreeing with any of your comments on that but IMHO there are opportunities for other (invasive) recovery techniques to be tried, before giving up (although I can't predict if they would be recover any more or not).

Edited to add:

@TheRedMaverick,

"Also, Vulcan, I replied to your post but apparently it needs to be approved by moderators for some reason lol."

FYI that's typical for new members, where some things can trigger the moderator checks (just like I think your original posting was slightly delayed for those checks).

[TheRedMaverick]

@Vulcan

Yeah some of my posts have been delayed (I think my response to your first post may be lost forever lol). It sounds like those invasive methods of data recovery could get pretty technical and I can see why resorting to a specialist would be a lot easier, but I know a lot of those places or people charge quite a bit to recover your data or even to evaluate your drive.

[labtech]

@labtech,

True, the OP could do that test, but I'm confident about the cause likely being the cp command, so they'll just see similar results (if they repeat the original situation closely enough). I've seen people make enough similar mistakes to last a lifetime.

In short, some or all of the old (FAT32-formatted) disk has been copied to the start of the (NTFS-formatted) 2TB disk. Although dd is typically used to do a (deliberate) raw copy, in order to allow control of block size etc. (and assuming no read errors are expected), some people use cp to do this (although that has some disadvantages IMHO). In this situation, the result is the same - the first xMB of the 2TB disk has been overwritten.

@Vulcan - not questioning what you are describing since you have vast experience with Linux commands. From my recollection and brief search online, I thought cp is intended to work with manipulation of folders and files and not so much cloning, including copying of boot structures from one drive to another. This is what is strange to me. Either way, the command is not explained quite clearly in the brief search I have conducted, which evidently can be deceitful in what will accomplish. I would like to experiment this myself, but my time is restricted now, so something to keep in mind for later on.

I agree too that there may be some things to try with more advanced tools, at least for confirmation purposes, but I guess the budget is limited.

@OP
There are some places that offer free evaluation, but the issue would be finding a good reputable company that offers it. Heads up: if the data, or partial data, will be recoverable, then that will be few hundred dollars for sure.

[drc]

Try running the scan on the "G:" partition rather than on the whole drive. Looks like for whatever reason R-Studio is not correctly picking up the start sector of the old NTFS partition. Two seconds worth of overwriting should not have been enough to damage much of your data.

Also cloning/imaging the problem drive and working with the copy is always a good idea.

[Vulcan]

@labtech,

All agreed and thanks for the kind words (I wouldn't say I have vast experience, just experience in some specific areas of using *nix ). FYI:

I thought cp is intended to work with manipulation of folders and files and not so much cloning, including copying of boot structures from one drive to another. This is what is strange to me.

You are absolutely correct about cp - but in *nix many "unusual" things are also treated as files, and cp can attempt to copy them. For example /dev/sda is a "file" in the /dev filesystem and so cp can (try to) copy it. However whether the result is a true copy or not depends on several factors - and things get complex here e.g. read about sparse file treatment by the cp command.

Therefore IMHO for DR purposes cp should not be used for cloning raw devices, and it can also result in confusion (especially for the inexperienced) about what will happen with the target of the copy (as seems to have been the case with the OP ).

I would like to experiment this myself, but my time is restricted now, so something to keep in mind for later on.

I know what you mean about limited time - again, just as a FYI in case you find it interesting, you can see a similar discussion here:

http://www.linuxquestions.org/questions ... sk-320508/

Hope that background info helps to explain things a little

@drc:

Two seconds worth of overwriting should not have been enough to damage much of your data.

I see where you're coming from - except that by using the cp command, the 2s does not necessarily mean that data was being overwritten for only 2s (as it would do if dd had been used). This would be an interesting experiment, to watch the blinking lights on the disks while repeating the OP's procedure, with a fairly full (i.e. not zeroed) source disk.

Also due to the effects of sparse detection by cp on the source, the consequences on the target may have been (and I expect actually were) sparse writes, leading to a horrible mixture of old & new data on the target, within the first xMB (partially) overwritten area.

Of course I agree about cloning, but considering that is exactly the procedure where the current problem happened, and it would require more hardware (personally I would be considering the use of at least 2 x 2TB new disks), so I did not dare get into that detail and the subsequent risks & follow-up questions in this situation. I admire you putting yourself up for that. I don't have the time or the guts.

[drc]

Great

I'm not familiar with the expected effects of using cp to copy a partition. What may make things better or worse is that the command was run against the GPT protection "partition" in the MBR which is essentially just the entire drive.

Based on OP's R-Studio scan it sounds like the MFT was relatively unaffected, which is at least a good sign.

[lcoughey]

PM sent to OP

[Vulcan]

@Luke,

Glad you're around - obviously you're the member I was thinking of earlier, as someone local whose professional services the OP could use.

With a recent RedHat (not the OP's Ubuntu, though I doubt this part is different), I got 5 mins on one of my lab systems to do a quick test with some scratch disks, and when trying to run the OP's command, there is a prompt from cp of:

Code:

cp: overwrite '/dev/sdb'?

... since the "file" (of course really the raw device) /dev/sdb already exists. This would need to have been answered with a 'y' in order to continue.

Anyway, now I've established that despite the "friend's" comments, the cp command given would overwrite (likely with sparse writes) the first xMB on the 2TB disk, after that confirmation prompt from cp, I'm sure the professionals can do a more efficient job than me of any subsequent recovery.

[TheRedMaverick]

@OP
There are some places that offer free evaluation, but the issue would be finding a good reputable company that offers it. Heads up: if the data, or partial data, will be recoverable, then that will be few hundred dollars for sure.

A free evaluation would be nice, I guess I have to do my homework and think about whether my data is critical enough for me to warrant spending x amount of dollars on it.

[TheRedMaverick]

Try running the scan on the "G:" partition rather than on the whole drive. Looks like for whatever reason R-Studio is not correctly picking up the start sector of the old NTFS partition. Two seconds worth of overwriting should not have been enough to damage much of your data.

Also cloning/imaging the problem drive and working with the copy is always a good idea.

I'll give it a shot and post the results, I just hope it doesn't take 24 hours like the initial scan did.

Cloning seems like a good idea and I'm considering getting a new external anyway. It'll save me from permanently destroying the data if I continue with these DIY methods.

[TheRedMaverick]

With a recent RedHat (not the OP's Ubuntu, though I doubt this part is different), I got 5 mins on one of my lab systems to do a quick test with some scratch disks, and when trying to run the OP's command, there is a prompt from cp of:

Code:

cp: overwrite '/dev/sdb'?

... since the "file" (of course really the raw device) /dev/sdb already exists. This would need to have been answered with a 'y' in order to continue.

Anyway, now I've established that despite the "friend's" comments, the cp command given would overwrite (likely with sparse writes) the first xMB on the 2TB disk, after that confirmation prompt from cp, I'm sure the professionals can do a more efficient job than me of any subsequent recovery.

Thanks for all of that information, Vulcan. I looked up some key words and phrases you used like sparse writes and even the dd command. I wish I had researched it myself because dd seems like the more suitable choice for what I was doing.

It's nice that you got a confirmation with your test, the reason I didn't back up my information in the first place was because I had faith in the person guiding me through it and I figured if for some reason I did stumble on some kind of overwrite issue, I would get a notification but I guess Linux assumes you know what you're doing for the most part haha.

[TheRedMaverick]

PM sent to OP

Thanks for the PM. I read it I just can't reply to it because apparently I need a certain number of posts before I can use the private messaging feature. Hopefully I'll only need 10 posts

[TheRedMaverick]

Well I did another scan for the G partition like drc suggested. It seems to be almost identical to the FAT32 partition from the original scan except in the metadata, it says the partition offset is 0 bytes instead of the original scan showing 1MB (2048 sectors) and the new scan shows one more parsed file entry than the original scan.

What is interesting though is that I tried recovering some of the video files from the Recognized2 NTFS partition where my original file and folder structures are. It seems that a lot of the videos do not convey the appropriate file size and do not work but there are some files that actually do play. The thing is, the files that play do not coincide with the title of the file. So for instance, I click on a video labelled "A" but video "B" plays. Both "A" and "B" were originally .m2ts files, the files that I'm actually seeking. Very strange