stevenleeyan
As the title, I want to know as the users like us how to judge a program is good or not to help us to get the lost files back. Anyone get some useful ideas?
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
BuffaloChuck
I am sure there are more thoughtful programmers than others, so there must be Better Programs. But in 30 years of doing this, I've never found one single absolutely certainly guaranteed product. I think the nuances between hard-drive's hardware and the user-behavior takes 'certainty' out of the equation. "Best o' luck" is the only adage worth adopting.
It's best to remember that any or all file-blocks on a hard-drive can be written to during normal usage, then freed-up and overwritten. This is where the recovery problems begin.
That said, there are two choices a user/administrator has: (1) install the Recovery Software early on during a Software Load (or even as The Very First Software installed after the OS is loaded - I do this before the OS Updates are started). This ensures that at least the File Recovery Software isn't overwriting too many once-used file blocks... or
(2) Install this File Recovery Software on a workbench PC and pull out whichever user-hard-drive is going to be recovery, attach it to that hosting Workbench PC, and run the recovery from that host-PC. This way, almost no Recovery Behavior File-Writes affect the to-be-recovered file system.
The next consideration for the administrator is Time. When someone needs file-recovery software to function, they cannot be in a hurry. The best results happen after hours and even days. And even then, there are no guarantees that The One Most Critical File was written to a one-use-only pristine file-block.
It's best to remember that any or all file-blocks on a hard-drive can be written to during normal usage, then freed-up and overwritten. This is where the recovery problems begin.
That said, there are two choices a user/administrator has: (1) install the Recovery Software early on during a Software Load (or even as The Very First Software installed after the OS is loaded - I do this before the OS Updates are started). This ensures that at least the File Recovery Software isn't overwriting too many once-used file blocks... or
(2) Install this File Recovery Software on a workbench PC and pull out whichever user-hard-drive is going to be recovery, attach it to that hosting Workbench PC, and run the recovery from that host-PC. This way, almost no Recovery Behavior File-Writes affect the to-be-recovered file system.
The next consideration for the administrator is Time. When someone needs file-recovery software to function, they cannot be in a hurry. The best results happen after hours and even days. And even then, there are no guarantees that The One Most Critical File was written to a one-use-only pristine file-block.
BuffaloChuck
By the way, when I've tested File Recovery Software, I use the "Host PC" method (Option #2) to load software onto, then attach various HDDs and run each program against the same hard-drive. On some drives, Software ABC is the best. On other drives, though, it doesn't do as much recovery as Software XYZ.
I think some of this is that Software ABC and XYZ were targeting certain hard-drive hardware technologies. File Systems (like NTFS) are supposed to insulate File-Write Differences from the hardware itself, but software is still subordinate to hardware. That's the only excuse I can offer for ABC doing better or worse than XYZ on some drives, but not others.
This testing, by the way, obligates me to spend one overnight recovery session per package, so 'time' again becomes very important IF the user makes it so.
I think some of this is that Software ABC and XYZ were targeting certain hard-drive hardware technologies. File Systems (like NTFS) are supposed to insulate File-Write Differences from the hardware itself, but software is still subordinate to hardware. That's the only excuse I can offer for ABC doing better or worse than XYZ on some drives, but not others.
This testing, by the way, obligates me to spend one overnight recovery session per package, so 'time' again becomes very important IF the user makes it so.
