It's ok, I just want to learn more on the matter and understand the suggestion, and use it properly, not making a mistake.
Copying files from NTFS internal to FAT32 external hdd
- Thread starter jetstream
- Start date
you have a bad disk - let's call it "source". then you get (borrow/buy/rent/do-not-steal) second
disk, call this "test".
if you run the recovery software on your one and only "source" you are betting that it will work
perfectly and it will be a one-time get-it-all 100% perfect retrieval.
but if you copy that "source" to "test" and run software recovery on "test" and it doesn't
do the job then that's it -. you just used up the only copy you have. But if you still have an
original untouched "source" you can try again: copy again to "test" - try software #2, etc.
the only key to this puzzle is a complete sector-by-sector copy program that creates
a new "test" each time you need it (if it works the first time then you're done - if
it doesn't work the first time you copy it again and use another program)
BTW, this is the approach the forensics folks use. copy the "DISK" many times,
then run various specialized programs to bypass security, reverse engineer
encryption, re-assemble lost blocks, scan un-allocated sectors looking to
form original files, etc. IOW similar to what I am describing.
finding a sector-by-sector disk copy program may require a little research.
most disk copy programs ONLY assume the disk is absolutely correct
and will ONLY copy the "correct" set of files, not the deleted chains, or missing.
there are some other factors like the how old your disk is, the size,
whether there's an MBR or the newer GPT, etc.
however, if you trust this Recuva - I haven't seen or used it, and you're willing to
accept whatever it recovers, then by all means use it as you see fit.
disk, call this "test".
if you run the recovery software on your one and only "source" you are betting that it will work
perfectly and it will be a one-time get-it-all 100% perfect retrieval.
but if you copy that "source" to "test" and run software recovery on "test" and it doesn't
do the job then that's it -. you just used up the only copy you have. But if you still have an
original untouched "source" you can try again: copy again to "test" - try software #2, etc.
the only key to this puzzle is a complete sector-by-sector copy program that creates
a new "test" each time you need it (if it works the first time then you're done - if
it doesn't work the first time you copy it again and use another program)
BTW, this is the approach the forensics folks use. copy the "DISK" many times,
then run various specialized programs to bypass security, reverse engineer
encryption, re-assemble lost blocks, scan un-allocated sectors looking to
form original files, etc. IOW similar to what I am describing.
finding a sector-by-sector disk copy program may require a little research.
most disk copy programs ONLY assume the disk is absolutely correct
and will ONLY copy the "correct" set of files, not the deleted chains, or missing.
there are some other factors like the how old your disk is, the size,
whether there's an MBR or the newer GPT, etc.
however, if you trust this Recuva - I haven't seen or used it, and you're willing to
accept whatever it recovers, then by all means use it as you see fit.
What I don't understand is:
Is the source vulnerable to running a file recovery tool? That's how the above sounds to me, like there's a risk. If you screw it once you have no second chance, so better run it on a copy first. Is that it? I get the idea, but I thought those recovery tools just read the lost data without modifying anything on the affected disk(?).
cpt_paranoia
Addicted Member
Some recovery tools operate on in situ data, manipulating the bits on the faulty HDD itself. If this manipulation is unsuccessful, you make life difficult for some other tool you might try to run, because the first tool has only further mangled the disk.
That's why it can be safer to use a tool that is known to only do a perfect, bit-for-bit copy of the fault disk to another clone disk, and make no changes to the original disk. Then you can run whatever in situ tools you like on the clone disk, and, if they are unsuccessful, run the clone tool again, and try a different recovery tool.
If your Recuva tool guarantees not to modify the original disk, then, by all means, use that to try to recover the data off the disk onto another disk.
there's a number of problems the file/disk recovery programs need to address. if it does an
integrity scan against the file tables and indexes and determines that there's corruption
there, then it may need or want to fix it before continuing.
theoretically, it would be a bad assumption to assume the disk's file tables and indexes
are perfect and only "find" the missing deleted file chains. file chains are where the
file tables, for a given filename, points to the first block of that file, then the next
and all the way to the end. break anywhere and you lose the ability to recover.
occasionally, some of these links go random or go backwards.
I'd look at any and all file/disk recovery programs. and look into what and how they work.
another approach. you can do this on any good disk on a Windows system. Run
the check disk integrity on a disk, note how it runs several passes in CHKDSK
and other apps. this ensures the disk is good regardless of whether it's a boot disk
or any other disk, and includes USB drives, and SSDs.
the key to recuva or "check disk integrity" is finding a utility that copies ALL blocks
(sectors or clusters) and makes NO assumptions as to OS (windows, dos, Linux,
Mac, UNIX), ignores all file tables and whether they are perfect or corrupt or missing,
and can read the disk contents (no matter what size the disk is).
this last requirement is because the just-previous file systems were MBR based
and is now GPT, the original disks back in IBM PCs were MFM and all the
way to just earlier were all 512-byte sectors. and you could write a simple
program (even in Visual Basic) to read all the sectors and write them somewhere
else. nowadays, advances the disk formatting to 4K clusters so the basic OS read
is no longer a 512-byte sector read but a 4K cluster I/O.
again it's your choice how you proceed.
integrity scan against the file tables and indexes and determines that there's corruption
there, then it may need or want to fix it before continuing.
theoretically, it would be a bad assumption to assume the disk's file tables and indexes
are perfect and only "find" the missing deleted file chains. file chains are where the
file tables, for a given filename, points to the first block of that file, then the next
and all the way to the end. break anywhere and you lose the ability to recover.
occasionally, some of these links go random or go backwards.
I'd look at any and all file/disk recovery programs. and look into what and how they work.
another approach. you can do this on any good disk on a Windows system. Run
the check disk integrity on a disk, note how it runs several passes in CHKDSK
and other apps. this ensures the disk is good regardless of whether it's a boot disk
or any other disk, and includes USB drives, and SSDs.
the key to recuva or "check disk integrity" is finding a utility that copies ALL blocks
(sectors or clusters) and makes NO assumptions as to OS (windows, dos, Linux,
Mac, UNIX), ignores all file tables and whether they are perfect or corrupt or missing,
and can read the disk contents (no matter what size the disk is).
this last requirement is because the just-previous file systems were MBR based
and is now GPT, the original disks back in IBM PCs were MFM and all the
way to just earlier were all 512-byte sectors. and you could write a simple
program (even in Visual Basic) to read all the sectors and write them somewhere
else. nowadays, advances the disk formatting to 4K clusters so the basic OS read
is no longer a 512-byte sector read but a 4K cluster I/O.
again it's your choice how you proceed.
