whebrew.blogg.se

That won't be intuitive to most people, which I suspect is also why that's not the default targeting mechanism for backup destinations either.

If the user ever reformatted or replaced their "D" drive, either of which would change its volume identifier, Reflect would stop using it for logs until the user pointed it at their new "D" drive so that the unique volume identifier was updated appropriately. This can be worked around by identifying the target by its unique volume identifier rather than its drive letter, as Reflect allows to be done for backup destinations, but that has challenges of its own. The volume that's assigned "D" in Rescue will not necessarily be the volume that's assigned "D" in Windows and that the user intends to use for logs. So suppose Reflect's folder in ProgramData had a tag file specifying the alternate log location of D:\MyReflectLogs. But drive letters are how most paths are defined. But more fundamentally, even though Rescue Media does employ some tricks to try to ensure drive letter assignment is consistent with Windows (which WinPE/RE itself does not guarantee at all), that doesn't always work reliably. First, the redirected location might not even be available in Rescue due to being offline, encrypted and still locked, etc.

If redirection were supported, some complications would arise. I don't know this for certain, but my guess would be that Macrium accomplishes this by checking the restored file systems for the presence of a \ProgramData folder that contains the folder hierarchy for Reflect, and if so, it adds the restore log files there.

I suspect one of the complications for redirecting logs might be the fact that as shown in the screenshot a few posts up, Reflect does "inject" a job log for a restore into the system, even if the restore is executed from Rescue.