can I use this good MFTMirr I have over here?

[rsk..]

(I understand basic recovery hygiene -- I'm working with a copy of the bad partition. Hardware was fine. W2K bluescreened while writing a large file, then system wouldn't boot and partition would not mount.)

Somehow I managed to get a good MFTMirr off the partition shortly before the partition went bad. Is there a way to feed this to ZAR in case it helps? Could it help? Thanks.

[Alexey V. Gubin]

We have no use for it. The MFT mirror only holds a copy of first 16 MFT entries, which are really not needed for recovery (they are always rebuilt based on the volume data). Hence, there is no mechanism to feed the copy into ZAR.

[rsk..]

Ah, okay. Thank you.

And the same question regarding a $Bitmap? I got one of those, too. And a $LogFile and that's about it.

[Alexey V. Gubin]

$Bitmap is not needed in a similar way (it is always rebuilt based on the actual volume data).

What may be useful:

$MFT, i.e. the full master file table. Only add if the original $MFT is significantly damaged (i.e. if you missing significant number of files in output). Adding a duplicate increases processing workload and causes in duplicate files in output.
$LogFile in certain cases (provides limited improvement if any at all). On a simple volume (no RAID), duplicate $LogFile is OK with no side effects. If adding to the RAID, append to each member and make sure "RCRD bias" is disabled in Advanced Configuration.If you really want to add these,

Make sure the file sizes are an integer multiple of 512 bytes (pad with zeros if needed).
Append the files to the end of the image file.

[rsk..]

My data is indeed non-RAID.

I like how you're extremely helpful (knowledgeable and responsive). I take it you're the proprietor of this business and the author of the software. I already thanked you with a purchase, but let me say thanks again for the usefulness of the program. I appreciate it. Spasiba.

> 1. Make sure the file sizes are an integer multiple of 512 bytes (pad with zeros if needed).
> 2. Append the files to the end of the image file.

I'm using an imaged partition, so I think I should expand the partition by int(Logfile size / 512)+1 blocks and write the log there, padding with zeros. I'll try to remember to report back here how it goes.

[Alexey V. Gubin]

If you have an imaged partition, another option is to find the run of zeros somewhere close to the end of the partition and write the $LogFile over these zeros. It is unlikely that damaging a run of zeros close to the end of the volume would have a significant side effect.

[rsk..]

It looks like appending the log to the end of the partition did in fact help in this scenario. Well, that's the way it seems by the raw count so far:

First attempt, without log file:
90585 files
1100 folders
26,723,760,738 bytes

Second attempt, with partition expanded and log file appended:
99989 files
1740 folders
32,648,877,249 bytes

I'll have to see if the additionally recovered files are important and not corrupt.

Thanks again.