BitLocker Live Clone using definition file issue


Author
Message
jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)
Group: Forum Members
Posts: 2.2K, Visits: 14K
Until now, I've been keeping a pair of identical 4TB USB 3.0 drives synchronized using a file-level replication tool because I want BitLocker enabled on both and until recently, performing Reflect clones would have complicated that.  Now that Reflect can perform "BitLocker Live Cloning", i.e. preserve BitLocker on the clone target as long as an initial clone has been run (so that RDC can be used going forward), I'm experimenting with that.  However, it seems that using that capability with a definition file may be problematic.

This may be a cosmetic issue rather than a functional one, but having just run a large clone job and waited for BitLocker to re-enable, I really don't want to find out by re-running the clone and potentially sending myself back to square one.  Here's what I did and what I'm seeing:

I set up an initial clone job from Disk 1, Partition 2 (BitLocker Unlocked) to Disk 2, Partition 2.  As expected, Reflect warned that BitLocker would be removed from the target since this was the initial clone.  I chose to save the job to a new definition file and to run it immediately.  After the clone completed, leaving my target unencrypted, I re-enabled BitLocker on Disk 2, Partition 2.  After refreshing my Reflect view, the partitions on both disks were recognized as BitLocker Unlocked.

Now, if I manually stage a new clone job from scratch, I do not get the warning that BitLocker will be removed from the target, and the summary page says "Live Restore", as expected (although this should arguably say "Live Clone").  However, if I choose to edit the definition file I originally created, my source partition still shows the BitLocker icon, but the target does not, and when I click Next, I get the warning that BitLocker will be removed -- but if I proceed all the way to the summary page, Reflect shows "Live Restore".  Further, even if I create an entirely new definition file after having re-enabled BitLocker on my target, the initial pass through the wizard proceeds as expected (no warning dialog, Live Restore shown at the end), but if I edit that newly created definition file, I still get the behavior I've just described.

Again, since I don't want to risk having to re-clone and re-encrypt my entire 4TB drive, I haven't found out whether Reflect would run a BitLocker Removal clone as it warned, or a BitLocker Live clone as it states in the summary -- but it seems clear that there's at least a cosmetic bug here.

Edited 22 December 2017 4:44 AM by jphughan
Nick
Nick
Macrium Representative
Macrium Representative (2.3K reputation)Macrium Representative (2.3K reputation)Macrium Representative (2.3K reputation)Macrium Representative (2.3K reputation)Macrium Representative (2.3K reputation)Macrium Representative (2.3K reputation)Macrium Representative (2.3K reputation)Macrium Representative (2.3K reputation)Macrium Representative (2.3K reputation)
Group: Administrators
Posts: 1.3K, Visits: 6.9K
jphughan - 21 December 2017 11:48 PM
Until now, I've been keeping a pair of identical 4TB USB 3.0 drives synchronized using a file-level replication tool because I want BitLocker enabled on both and until recently, performing Reflect clones would have complicated that.  Now that Reflect can perform "BitLocker Live Cloning", i.e. preserve BitLocker on the clone target as long as an initial clone has been run (so that RDC can be used going forward), I'm experimenting with that.  However, it seems that using that capability with a definition file may be problematic.

This may be a cosmetic issue rather than a functional one, but having just run a large clone job and waited for BitLocker to re-enable, I really don't want to find out by re-running the clone and potentially sending myself back to square one.  Here's what I did and what I'm seeing:

I set up an initial clone job from Disk 1, Partition 2 (BitLocker Unlocked) to Disk 2, Partition 2.  As expected, Reflect warned that BitLocker would be removed from the target since this was the initial clone.  I chose to save the job to a new definition file and to run it immediately.  After the clone completed, leaving my target unencrypted, I re-enabled BitLocker on Disk 2, Partition 2.  After refreshing my Reflect view, the partitions on both disks were recognized as BitLocker Unlocked.

Now, if I manually stage a new clone job from scratch, I do not get the warning that BitLocker will be removed from the target, and the summary page says "Live Restore", as expected (although this should arguably say "Live Clone").  However, if I choose to edit the definition file I originally created, my source partition still shows the BitLocker icon, but the target does not, and when I click Next, I get the warning that BitLocker will be removed -- but if I proceed all the way to the summary page, Reflect shows "Live Restore".  Further, even if I create an entirely new definition file after having re-enabled BitLocker on my target, the initial pass through the wizard proceeds as expected (no warning dialog, Live Restore shown at the end), but if I edit that newly created definition file, I still get the behavior I've just described.

Again, since I don't want to risk having to re-clone and re-encrypt my entire 4TB drive, I haven't found out whether Reflect would run a BitLocker Removal clone as it warned, or a BitLocker Live clone as it states in the summary -- but it seems clear that there's at least a cosmetic bug here.

Thanks for bringing this to our attention. It is indeed a 'cosmetic' issue, in that the outcome of the restore is unaffected however it'll be fixed in the next update. 

Please note that if the source file system contains large files with only small modifications, such a a synthetic full, then RDC isn't very efficient for this and may be no quicker than a simple file copy. RDC has huge advantages over a Full clone when small files have changed, not so much if the changed files are large. 

Kind Regards

Nick - Macrium Support

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)Most Valuable Professional (3.1K reputation)
Group: Forum Members
Posts: 2.2K, Visits: 14K
Good to know about RDC, an thanks as always Nick! Smile

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search