Need help with data recovery on HDD
#1
Posted 16 August 2012 - 03:54 PM
System drive (Seagate 7200.11) with XPx64 stopped being recognized in BIOS. Found this place, went through steps to get it back. Now I'm not seeing any partitions on the drive from the current OS (win7x64).
Drive is 500GB 7200.11. It contains both the OS and documents of value. Most urgent (priority) is getting a few docs back. Would be wonderful if I could make it bootable again of course, but that's a bonus.
- I have another external 500GB drive that is clean.
- I have another 7200.11 internal that I believe is clean.
- I don't remember which file system was used on the problem drive. Did run testdisk but had to go to work. Believe it said FAT16 (why?). Would have thought I'd have chosen NTFS or FAT32...
Questions:
1) What steps should I take first?
2) Which softwares would be recommended for these steps?
Thanks in advance for any and all help you can give me,
Mattias
#2
Posted 16 August 2012 - 04:28 PM
mattiasnyc, on 16 August 2012 - 03:54 PM, said:
To be on the safe side you should first thing image the disk.
Normally one would image the disk, i.e. save it's entire contents to a file on another (larger) disk.
Since you only have other disks of the same size this is not possible, so, as a poorman's solution you could clone (i.e. directly copy sector by sector) the contents of the unbricked disk to the other disk.
This is intended as a preventive measure, by having an image or a clone, in case of any possible "mistake" during the recovery procedure you have a "way back".
mattiasnyc, on 16 August 2012 - 03:54 PM, said:
Under windows NT (and possibly a 2K or XP would be "better" than a Vista
For imaging DatarescueDD:
http://www.datarescu...cue/v3/drdd.htm
For cloning :
http://alter.org.ua/...win/bb_recover/
The app of reference is TESTDISK (for partition oriented recovery) or the "companion" PHOTOREC (for file based recovery):
http://www.cgsecurit...g/wiki/TestDisk
It is very possible that some manual intervention by means of a hex editor will be needed anyway, in any case, if you have ANY doubt in the usage of any of the tools, ask BEFORE doing something that you may later regret
Here is an example of a similar recovery, performed succesfully
http://www.msfn.org/...-after-bsy-fix/
jaclaz
#3
Posted 16 August 2012 - 04:35 PM
I will clone the drive and then read through the link you mentioned. I'm assuming that the suggested clone software will work in Win8x64 (?). Unfortunately that's all I have available at the moment. I also hope you don't mind if I pose further questions after having read that thread. I'm fairly decent with technology but I'm sure I'll have questions....
/m
This post has been edited by mattiasnyc: 16 August 2012 - 04:38 PM
#4
Posted 16 August 2012 - 04:58 PM
mattiasnyc, on 16 August 2012 - 04:35 PM, said:
I will clone the drive and then read through the link you mentioned. I'm assuming that the suggested clone software will work in Win8x64 (?). Unfortunately that's all I have available at the moment. I also hope you don't mind if I pose further questions after having read that thread. I'm fairly decent with technology but I'm sure I'll have questions....
/m
You are very welcome to ask questions
I have NO idea IF any of the mentioned software will work:
- under 64 bit
- under windows 8
- under the two above combined
or if they will work "correctly".
If I should bet on the worst possible combination one could find for data recovery, I would bet on Windows 8 64 bit
Now, get real
You are going to risk supposedly very valuable data by using "legacy" tools, designed for 32 bit on a 64 bit OS (and this in itself is not "smart" as you rely on the 32 bit subsystem that could have some incompatibilities with "real 32 bit OS) and to this you add the use of newly released OS (and traditionally NO MS OS was EVER found to be stable before "SP1").
While the first would be IMHO a limited risk (but that I would anyway choose NOT on valuable data), the second seems to me like "pure folly"
If you had several YEARS of experience with the tools, then it would be logical for you to test the new OS and environment (on EXPENDABLE data ONLY of course) but without any experience with the tools introducing a brand new OS?
Come on....
If you have not available a "good" WIndows NT based system, i.e. a 2K or XP (and possibly NOT Vista or 7 AND definitely NOT 8) then you'd better get a free Linux based live disk, that is known to work.
You want either ddrescue or dd_rescue (most distro's will have one of them) and TESTDISK/PHOTOREC are also available in the Linux version on many distro's, Parted Magic is the first one that comes to mind:
http://partedmagic.c...ku.php?id=start
jaclaz
This post has been edited by jaclaz: 16 August 2012 - 04:59 PM
#5
Posted 16 August 2012 - 08:47 PM
As I mentioned in my first post my current OS is Windows 7 x64, not 8.
I'm not sure I'll get access to other OS'. How about I just find a different cloner, like EaseUS Todo Backup Free Edition, clone the drive, and then I'll just give it a whirl and continue working on the clone instead of the original. I guess we'd see soon enough if the other software will operate properly under Win 7 x64 or not, with the target in question. Perhaps it'll be enlightening to others in the same situation.
Or do you think it's a waste of time?
#6
Posted 17 August 2012 - 02:20 AM
mattiasnyc, on 16 August 2012 - 08:47 PM, said:
As I mentioned in my first post my current OS is Windows 7 x64, not 8.
I'm not sure I'll get access to other OS'. How about I just find a different cloner, like EaseUS Todo Backup Free Edition, clone the drive, and then I'll just give it a whirl and continue working on the clone instead of the original. I guess we'd see soon enough if the other software will operate properly under Win 7 x64 or not, with the target in question. Perhaps it'll be enlightening to others in the same situation.
Or do you think it's a waste of time?
No, it's OK, as said it is very likely (though not "granted") that the 32 bit programs will work in the 64 OS without a glitch, but I have a few doubts on the cloning app that you mentioned
According to this:
http://www.todo-back...-hard-drive.htm
Quote
It sounds like even in the "sector by sector" mode the actual partition table OR "indexed in the filesystem sectors" (used space in the above snippet) is involved in the "clone" process.
This (forensic version of dd):
http://gmgsystemsinc.com/fau/
or rawcopy:
http://www.ltr-data.se/opencode.html/
might do (as they have a 64 bit version).
If I were you I would try the latter.
Something "plain" like:
Quote
should do, the above uses NOT any "fine-tuning", it will probably take some time (a few hours) to perform the copy.
Be VERY, VERY careful in choosing m and n ....they are the disk numbers (as you can see them in Disk Management and/or diskpart, first disk (boot disk) is 0, if you have three disks they will be 0, 1 and 2 be sure to identify correctly which one is the source and which is the target.
When cloning a disk drive it is a good idea to make sure that BOTH the "source" and the "target" drives are kept "cool", depending on your setup/hardware, it could be advisable to add a fan to have some additional airflow aroud the disks.
The "general" issue with 7 might be that the disk (actually some sectors on it) are "locked", from what I understand this should not apply to a disk that is seen as "RAW", most possibly later in the recovery it might be needed to put the disk "offline", see references here:
http://www.msfn.org/...os-with-imagex/
http://www.msfn.org/...ost__p__1006402
jaclaz
#7
Posted 17 August 2012 - 08:43 AM
jaclaz, on 17 August 2012 - 02:20 AM, said:
http://gmgsystemsinc.com/fau/
or rawcopy:
http://www.ltr-data.se/opencode.html/
might do (as they have a 64 bit version).
If I were you I would try the latter.
Something "plain" like:
Quote
should do, the above uses NOT any "fine-tuning", it will probably take some time (a few hours) to perform the copy.
Be VERY, VERY careful in choosing m and n ....they are the disk numbers (as you can see them in Disk Management and/or diskpart, first disk (boot disk) is 0, if you have three disks they will be 0, 1 and 2 be sure to identify correctly which one is the source and which is the target.
When cloning a disk drive it is a good idea to make sure that BOTH the "source" and the "target" drives are kept "cool", depending on your setup/hardware, it could be advisable to add a fan to have some additional airflow aroud the disks.
I will use rawcopy as you suggested. I have a question about the highlighted section above:
In my device manager I see the following:
Drive 0 Unallocated (this is the problem drive) 465.76 GB
Drive 1 Sys Reserve / C: / D: (this is the system drive)
Drive 2 Crucial F: (mem stick)
Drive 3 L: (mem stick)
In other words on my system the "boot drive" isn't "Drive 0", but it appears to be "Drive 1". Does this seem correct?
#8
Posted 17 August 2012 - 11:30 AM
mattiasnyc, on 17 August 2012 - 08:43 AM, said:
Drive 0 Unallocated (this is the problem drive) 465.76 GB
Drive 1 Sys Reserve / C: / D: (this is the system drive)
Drive 2 Crucial F: (mem stick)
Drive 3 L: (mem stick)
In other words on my system the "boot drive" isn't "Drive 0", but it appears to be "Drive 1". Does this seem correct?
It is "unusual" in the sense that what you report should be related to BIOS drive order (and the way disks are connected to the actual physical interfaces on the motherboard) and normally first disk in BIOS is the "boot disk" and BOTH the "source" (drive to recover/copy from) and "target" (drive used for cloning/copy to) are attached to it "later".
The above is the "normal" setup, when you have a fully working machine and you add to it the source and the target disks.
On the other hand, if the "bricked" disk "was" a boot disk on that machine and you added a second disk installing to it a "temporary OS" and after the unbricking you placed the "unbricked" disk where it was before, what you report may be "normal".
jaclaz
#9
Posted 17 August 2012 - 11:38 AM
jaclaz, on 17 August 2012 - 11:30 AM, said:
The above is the "normal" setup, when you have a fully working machine and you add to it the source and the target disks.
On the other hand, if the "bricked" disk "was" a boot disk on that machine and you added a second disk installing to it a "temporary OS" and after the unbricking you placed the "unbricked" disk where it was before, what you report may be "normal".
jaclaz
Actually my functional (win7) OS drive lives on SATA 3 or 4, and my damaged drive on 5 or 6.
But as long as I can trust what's reported it shouldn't make a difference, so the question is: can I trust it?
#10
Posted 17 August 2012 - 11:56 AM
mattiasnyc, on 17 August 2012 - 11:38 AM, said:
Well NEVER trust anything or anyone!
Do a simple experiment.
Check the first sector of both the \\.\PhysicalDrive0 and 1
rawcopy 512 \\.\PhysicalDrive0 C:\drive0.bin rawcopy 512 \\.\PhysicalDrive1 C:\drive1.bin
Then physically disconnect the "unbricked disk" and redo:
rawcopy 512 \\.\PhysicalDrive0 C:\drive0_2.bin rawcopy 512 \\.\PhysicalDrive1 C:\drive1_2.bin
If the setup is what you see in disk management you should get two identical files C:\drive1.bin and C:\drive1_2.bin, a file C:\drive0.bin and an error as at the second attempt there should be no drive0 avaialble.
As well, to make sure of the n check in disk management before connecting the "target" drive and after connecting it
jaclaz
Edit: ERRATA CORRIGE
the rawcopy thingy uses bytes and not sectors as "copylength" corrected in the above from "1" to "512"
This post has been edited by jaclaz: 17 August 2012 - 12:05 PM
#11
Posted 17 August 2012 - 03:14 PM
I'm just a bit uncomfortable on a command line without having any frame of reference if you know what I mean... Do you know of any other cloning software that will do the same job but with an intuitive UI? (other people are welcome to jump in here)
Also, I'm guessing here that the problem with some of the cloning softwares that exist is that they actually "analyze" the sectors and decide whether or not to clone them based on whether or not they appear to be used as opposed to "empty" or "corrupted", is this correct? Or in other words they're not really cloning drives as much as they are cloning some/most data on them, which in turn means that some of the data I wish to recover might not make it to the "clone" in the first place...
Again: I greatly appreciate your help and patience with this. I'm pretty well versed in computer technology compared to the average person but this is all completely new to me as you can probably tell.
So, again, thanks!
This post has been edited by mattiasnyc: 17 August 2012 - 03:15 PM
#13
Posted 18 August 2012 - 06:00 AM
mattiasnyc, on 17 August 2012 - 03:14 PM, said:
I'm just a bit uncomfortable on a command line without having any frame of reference if you know what I mean... Do you know of any other cloning software that will do the same job but with an intuitive UI? (other people are welcome to jump in here)
Opening a command prompt and typing in it:
Quote
will give you all the information available (which you should anyway test yourself).
The syntax is similar (though not identical) to many other programs that do the same thing, the "archeotype" of them is "dd" see (only to learn some history and possibly to get a quick laugh
http://reboot.pro/15207/
Basically dd takes a source and copies it to a target based on offset/position/address without caring about the contents.
The other programs I suggested you before are either "more suited to data recovery" (they use some specific "strategy" to attempt reading the data in case of difficulty and/or "give up" after a number of failed tries and write to the target a 00ed sector instead of throwing an error) or "
mattiasnyc, on 17 August 2012 - 03:14 PM, said:
Exactly.
For "normal" use, i.e. NOT for "forensics" or "data recovery", ignoring some data (which are unneeded for these other than foresics or data recovery scopes) will allow a number of advantages, like faster operation, smaller images, etc. a quick sum up is here:
http://www.msfn.org/...inside-windows/
mattiasnyc, on 17 August 2012 - 03:14 PM, said:
So, again, thanks!
You are welcome, actually the fact that you are "new to the field" is a good thing: it means that you never faced a serious case of data loss in these years
The app Kelsenellenelvian
jaclaz
#14
Posted 18 August 2012 - 11:03 AM
Quote
I would think this is a potential problem then, is it?
Too bad because I like the fact that the UI gives information about the disk which means that one can easier recognize which disk is which...
#15
Posted 18 August 2012 - 11:20 AM
mattiasnyc, on 18 August 2012 - 11:03 AM, said:
Quote
I would think this is a potential problem then, is it?
Too bad because I like the fact that the UI gives information about the disk which means that one can easier recognize which disk is which...
Not really, really that's the way *all* tools should behave (when dealing with data recovery).
Basically when you hit a bad sector, a "normal" tool will throw an error and abort or "insist" trying over and over on that same (bad) sector (and thus "stall").
A recovery oriented tool will try a few times to read the bad sector (let's say 5 times) then will understand that the sector is actually bad and write to the target a sector full of 00's INSTEAD and continue to the next sector.
If there is a bunch of bad sectors in some cases it is advised to avoid also the (say) 5 times try on each of them (which will slow considerably the imaging) and simply "jump" a little bit further (and possibly later trying again that zone "backwards"), that is the idea of the DatarescueDD.
jaclaz
#16
Posted 21 August 2012 - 08:49 AM
I started the process at 9:43, it's now 10:43 and the software is telling me it's currently on sector 3,374,xxx. "0%" complete. That's after a whole hour. Transfer rate is reading at 0.5MB/s!!!
Source drive is internal SATA. In the software it came up as "ATA", not "SATA". Target drive is external FW400. Still, ATA should at worst transfer 16MB/s I think, and FW400 50MB/s, all theoretical of course.
Any clues as to what I should check?
#17
Posted 21 August 2012 - 09:50 AM
mattiasnyc, on 21 August 2012 - 08:49 AM, said:
I started the process at 9:43, it's now 10:43 and the software is telling me it's currently on sector 3,374,xxx. "0%" complete. That's after a whole hour. Transfer rate is reading at 0.5MB/s!!!
Source drive is internal SATA. In the software it came up as "ATA", not "SATA". Target drive is external FW400. Still, ATA should at worst transfer 16MB/s I think, and FW400 50MB/s, all theoretical of course.
Any clues as to what I should check?
Well, ATA means both "PATA" and "SATA", I wouldn't see that as a problem, and anyway a "normal" (P)ATA 133 is comparable with a SATA I (150) when it comes to speed.
You never know the speed you can have on a program (unless you are already familiar with it and have some experience).
Much more than that, you are doing the first step of data recovery and the source drive is NOT (evidently) fully functional as it was a bricked drive, later unbricked.
It is also possible that you are hitting a particular zone with "bad" (or - actually worse for speed - "half bad" sectors) and the tool is slowing down to try (desperately) to read them sectors.
There are too many variables in your setup, there is nothing "wrong" at first sight but the interaction of a number of "not known" or "not tested together" items may lead to "whatever".
And mind you it is very possible that by using the recommended OS and tools you would have exactly the same speed
The "advantage" of using a command line tool (over an "easy" GUI one) is that you can try to image a small part of the disk, see what happens, try with another area, stop and resume, etc..
Really cannot give you any meaningful advice
jaclaz
#18
Posted 21 August 2012 - 01:04 PM
Thanks for the input and I'll harass you more once it's done...
/m
#19
Posted 22 August 2012 - 04:58 AM
mattiasnyc, on 21 August 2012 - 01:04 PM, said:
Yep, one of the "key" requirements for disk data recovery is "patience" (the other one being "perseverance"
BUT do check, by just feeling it with a hand, if the disk is warming up "too much" (a highly specialized technical unit of measure
mattiasnyc, on 21 August 2012 - 01:04 PM, said:
Oww, come on
Link to image
(for some strange reason the board doesn't like this image's name)
jaclaz
#20
Posted 22 August 2012 - 09:34 AM
To reiterate: Trying to recover the data on the source drive (that failed and was unbricked) is playing with fire, right? So that's why I should prefer to use a clone...?
and
What type of risk are we talking if I start working on the source instead? Is it dependent on the operation I perform on it or is it something else at play?
- ← Internal or external hard drive
- Hard Drive and Removable Media issues
- detect problem after upgrading firmware →



Help

Back to top









