1) Create a Macrium image file of just one partition in an image 2) mount BL image and open the BL...


1) Create a Macrium image file of just one partition in an image 2)...
Author
Message
ParrotSlave
ParrotSlave
New Member
New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)
Group: Forum Members
Posts: 12, Visits: 52
1) I usually make images of just the partitions required for Windows to boot, but occasionally I do make an entire system image. In addition to my Windows partitions, I have two other partitions, one encrypted. Being somewhat paranoid, I make images more often than I need, but, because of time and space constraints, I rarely make whole system images, I do occasionally want to save the non-Windows partitions, though. It happens that, later on, I might decide that I don't want the "Windows" part of the system image, such as, for instance, when I've installed some kind of software that requires activation (and for which multiple activations are a problem due to the idiosyncrasies of certain software makers), or if I've done a lot of laborious registry or file cleaning up, or possibly solved some kind of software problem. So, I might want to keep the non-Windows partitions I saved, say, in January, but not the Windows partitions, opting instead to save the Windows-only image I made in, say, February. That will save space (and also make it easier to keep the volume on which the images are stored defragmented.)
2) It would be nice to be able to mount a Bitlocker encrypted drive in Reflect, a drive that was imaged while encrypted, and be able to unlock the virtual drive by entering the BL password. Of course, to do that might require that some kind of huge ransom be paid to Microsoft to be able to incorporate BL like that.  [If I run Reflect, and create an image from within Windows, and the BL drive is decrypted at the time, then the Reflect image will also be decrypted. I discovered that accidentally, when I was shocked to realize that my "hidden" files were visible when I mounted the backup in Reflect. The thought had never occurred to me that it would do that, although it's obvious once one thinks about it. You might consider making a warning about that more obvious. Similarly, if the Bl drive is not decrypted when Reflect is run from within Windows, or if Reflect is run from Windows PE, the BL drive image that results will be encrypted. That image will restore to the original drive perfectly, with the same encryption and no problems, but if I forget that the drive was decrypted, then restore it, I'll have to create a new encryption key, which could mean a hassle with keeping track of the Recovery keys in future images. You can use the same password, but the recovery key would be different, I think.]




jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)
Group: Forum Members
Posts: 14K, Visits: 85K
1) So you're asking to be able to delete partitions out of a backup after it's been created?  That's sort of antithetical to the concept of a backup as a read-only archive of a point in time, and I doubt these types of deletions would even be feasible given the reality of Differential/Incremental backups.  The best solution for your needs would be to have two separate definition files, one that captures only the "system" partitions, and the other that captures your "data" partitions.  That way you would be able to capture each with different frequencies if desired, and also specify different retention polices or perform different manual deletion routines as needed.  At that point there would be no need to capture any separate "whole disk" image backups.  It might be convenient (in which case you should use a third definition file for that), but even without it, if you ever needed to restore your entire system, you could do so by simply restoring the "system" backup first and then restoring the "data" backup immediately afterward.

2) For BitLocker To Go volumes (as opposed to BitLocker system volumes), you can capture them in their locked state by locking the drive within Windows before performing the capture, but otherwise yes, if the partition is unlocked within Windows, then it's unlocked to Reflect. However, capturing a partition in its locked state would cause your images to be much larger since Reflect would have to capture the entire partition's size, not just the amount of data you're actually using, and you wouldn't even be able to benefit from compression since encrypted data isn't compressible. So for example if you had a 200GB BitLocker To Go volume and were only using 20GB of it, your image backups would still be 200GB.  I'm also not even sure if Differential/Incremental backups would work when imaging locked BitLocker volumes. This is all why the recommended practice is to capture BitLocker volumes in their unlocked state and protect the backups with Reflect's encryption instead.  It keeps Diff/Inc backups working, allows compression to work (since compression is applied before encryption this way), and image backups only include the data that actually exist, not the data plus all the pseudorandom noise on the rest of the partition.

But yes, if you capture an image of a BitLocker volume while it's unlocked and then restore it later, the data will be unencrypted on the disk, and if you re-enabled BitLocker, you would have a new Recovery Key even if you used the same password. However, that doesn't strike me as a significant key management issue since if you just overwrote your original partition with the restore, there would be no longer be a reason to keep the OLD Recovery Key.

In terms of imaging from Windows PE, the results will depend on a couple of factors. First, the Rescue Media Wizard includes an option for Rescue Media to automatically unlock BitLocker volumes, which it achieves by storing unlock keys it can find when you run the wizard on the Rescue Media that you build. If you enable that, then capturing from Windows PE will be just like capturing from within Windows, and restore scenarios benefit from being able to use Rapid Delta Restore and also avoiding ever writing unencrypted data to disk at all (assuming you're rolling back an existing partition rather than restoring onto a new/empty disk).  Alternatively, Windows PE also includes the manage-bde command, which is everything you need in order to work with BitLocker and BitLocker To Go volumes, so even if you weren't comfortable with unlock keys being stored on your Rescue Media (as I'm not), you can use that command to unlock the disks prior to performing image capture/restore operations to gain the benefits I just described.  This is precisely what I do.

Finally, as a general note, be careful distinguishing between encrypted/decrypted and locked/unlocked in your terminology.  Your BitLocker volumes aren't "decrypted" within Windows; they're just unlocked.  Decrypted would mean that BitLocker wasn't even involved anymore.

And for what it's worth, Macrium has a KB article explaining how Reflect works with encryption.

Edited 23 August 2017 10:32 PM by jphughan
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)
Group: Forum Members
Posts: 14K, Visits: 85K
@Macrium, despite my post above, I do think the idea of warning about unlocked BitLocker volumes being backed up in the clear has merit.  One possible implementation for this could be that if any BitLocker partitions are selected when setting up an imaging job, a warning could appear in the area indicated below, with the standard small yellow triangle warning icon followed by text such as, "Your selection includes BitLocker partitions. Backups of unlocked BitLocker partitions will be captured unencrypted by default. Consider enabling Reflect's image encryption to keep your data protected."  For bonus points, only show that warning if Reflect encryption hasn't already been selected under Advanced Options. I would even show this warning in Reflect Free even though users who go to Advanced Options as instructed will then see an error that encryption can't be enabled in the Free version, because for some users, I suspect this issue of protecting backups of BitLocker partitions may be enough to justify purchasing a paid version all on its own.

And then for clone operations, I think the warning should always be displayed. In my testing, it seems that if the clone source is ever unlocked when the job runs, the target will be decrypted, even if it was originally set up with BitLocker and previous clones occurred while the source was locked. Therefore for this scenario, the warning text should read something like, "Your selection includes BitLocker partitions. Be aware that if the source partition is ever cloned while unlocked, the target partition will be unencrypted."  (UPDATE: Newer Reflect releases now allow an unlocked BitLocker volume to be cloned to another unlocked BitLocker volume while maintaining the destination's encryption, including its distinct protectors, i.e. the source protectors do not replace the destination's.)

https://forum.macrium.com/uploads/images/cd7e0a7e-acf4-4c0c-b277-2c5b.png

Edited 11 January 2018 4:03 PM by jphughan
ParrotSlave
ParrotSlave
New Member
New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)
Group: Forum Members
Posts: 12, Visits: 52
I don't use differential backups. I had issues a decade or so ago with Ghost's differential backups, and have never felt inclined to use them: the differential part of it seems like it's adding another layer of software processing, which means one more thing that can go wrong. I like the simplicity of a whole image for a given drive. Right now, I have one hard drive that contains 13 Macrium images of this system, 4 of them being when I was experimenting with Win10, the others Win8.0 and Win8.1. Six of them are complete system images, of a little less than 200 gb each, the others being around 70 to 80 gb each.
Keeping that many images is obviously ridiculous. What in the world need could I possibly have for that? A few years ago, I don't even remember exactly what it was, but I solved a recurring software error by restoring several different older images successively for troubleshooting purposes before I finally found an image where the problem did not occur. Then I had to I re-update everything--more than usual, because the last "good" image then was from a couple of years prior. My attitude is that I don't want to have to reinstall Windows, regardless of how easy that is these days, but then have to re-install all the third-party software I've accumulated. That is the nightmare. Before SSDs, I had no compunctions about endless use of the HDD. Some of those images have software programs that might cause me to consider restoring an image merely in order to deactivate the program in order to re-install it without an activation hassle, although viBoot may make that pointless--but would still make keeping some images essential. I have exceptionally good security practices, and I don't go on the internet where I shouldn't, but if something happens like my mouse pointer starting to move by itself, I'll synchronize any saved files, and then do an image restoration in a New York minute.
I suppose that I could buy an empty drive and restore a whole image to that drive, then re-image just whatever partitions I want at this late date for archiving purposes. That's a lot of trouble. I don't need all those Windows partitions at this late date, but I would like to save the data partition. The odds are pretty good that there isn't any data that I don't have saved elsewhere, but I'm a belt-and-suspenders kind of person. Backup, backup, backup. I don't need my full 171.8 gb image made on 12/13/15 since I have an image made on 01/02/16, less than a month later, that's only the Windows partitions, and is only 68.3 gb. I want to weed out these images, and save just the data partition from that whole system image. At this point, whatever it was that was causing me to make those images is no longer an issue, but I still want to save one from every now and then, just in case.

Edited 23 August 2017 11:23 PM by ParrotSlave
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)
Group: Forum Members
Posts: 14K, Visits: 85K
You don't have to use Differential backups, but you can still capture two different types of images from a single disk, each containing different partitions, and then restore both images to the same disk if you ever need to "regenerate" your whole disk.  That said, things have come a VERY long way since Norton Ghost (which I used as well quite heavily in multiple jobs!), and I'm actually using Incrementals Forever, which means not only do I only ever capture Incrementals, but I have Reflect merging the contents of Incrementals into the root Full with each backup.  Unfortunately in my case, a Full backup is about 1.2TB, so it's just not reasonable to be capturing that every day.  Still, I've had this strategy running for the last 9 months and have had zero problems.  I did however have some discussions with Macrium Support to ask how Reflect would handle certain failure scenarios before even contemplating using this strategy.

But of course if using Full backups exclusively works for you, then it's certainly simpler.  Hopefully my suggestions above re BitLocker were helpful. Smile

ParrotSlave
ParrotSlave
New Member
New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)
Group: Forum Members
Posts: 12, Visits: 52
Sorry about my carelessness in reference to BitLocker. Thanks for clearing that up. And I never paid attention to BitLocker once having started using it; I had not paid any attention to BitLocker to Go. Speaking of BitLocker, do you have any ideas about this, which should probably be in a separate forum: I had upgraded Win8.1 to Win10 a second time, in the hope that it had improved, and, after a while, Win10 went a little crazy. I decided to immediately restore an older image, but first I made an image (from the PE environment) of the only partition that might have had some unsynchronized data files, a BitLocker protected partition. (In case of any emergency, my standard protocol is to first image the "bad" system for convenient retrieval of data by later mounting the image in Reflect.) After restoring the non-evil version of Windows to my system, I used EaseUS Partition Master to make a new partition on an external drive, then restored the BL drive image to that new partition. Windows recognized the restored partition as a Bitlocker partition, and it even allowed me to unlock it. Unfortunately, after unlocking it, it still shows a greyed-out lock, and trying to open it, Windows tells me that I need to format it first, then, which I click no, it tells me that the volume has no recognized file system. (See the graphic.) Just to make sure, I used a command prompt to try to unlock the volume again, using manage-bde -unlock K: -RecoveryPassword [then the recovery key], and it told me that the volume was already unlocked.

I know for a fact that I could restore that partition to the "real" data drive, i.e., the one that I'm still using, and have full access to the data, but I don't want to "use up" the SSD. It's a good one, a Samsung EVO that's only a little more than two years old. Yet HardDiskSentinel tells me that it's now down to 97% health. I'm tempted to give up speed for longevity the next time I have to get a drive. What I'm wondering, and I was considering asking Macrium support this, is whether there is some characteristic of the partition that I restored the Macrium image to, and/or whether there's some tricky setting in Reflect in restoring the image that I didn't see. EaseUS says that the original partitions on my system are GPT. Is it possible that a BL drive that originated on a GPT drive would have to be restored to a GPT drive?
https://forum.macrium.com/uploads/images/a3397f5e-4f63-4fc6-bed5-4e0b.png
Edited 24 August 2017 2:01 AM by ParrotSlave
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)
Group: Forum Members
Posts: 14K, Visits: 85K
Haven't seen that myself, but my guess is that you used Windows 10 Version 1511 (November Update) or newer and selected the default "New encryption mode" rather than the "Compatible encryption mode", in which case you won't be able to read that partition from anything older than Windows 10 1511.  In terms of a fix, if you were to build Reflect Rescue Media using WinPE 10, you'd be able to use manage-bde in THAT environment to unlock the disk, and from there you could perform a File & Folder Backup of the contents or simply copy the contents manually using the File Explorer application included there.

ParrotSlave
ParrotSlave
New Member
New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)New Member (25 reputation)
Group: Forum Members
Posts: 12, Visits: 52
That particular partition was never touched by Windows 10. I've gone to Win10 three times, the first in December, 2015, which lasted a week or so, then in July, 2016, which lasted a couple of weeks before I got too angry to put up with it, and the last time, the one this image is from, in Feb., 2017. The image was made on the 17th after only a couple of days of 10. I have absolutely no memory of ever selecting anything to do with encryption, either "New encryption mode" or "Compatible encryption mode." However I installed it, I was able to unlock that particular drive immediately in each case, since that's where I keep Dropbox, as well as a list of clues to passwords (not the passwords themselves): I unlock that partition after the desktop has appeared, but before everything, such as SuperAntiSpyware, has loaded. (If I do it too soon, it'll kill the desktop. If I wait too long, then Dropbox wouldn't synchronize unless I opened the program. These days, Dropbox will eventually synchronize by itself, even if its partition was not unlocked soon enough, but, at first, it wouldn't do so.)

I was able to lock and unlock the "real" BitLocker drive before, during, and after each installation of Win10. The image of that particular partition was made while the O.S. was Win10 1607, 10.0.14393.729. However since the image was made in WindowsPE, I don't see how the Windows encryption could relate to it: it is supposed to be an image of the partition independent of whether or not its encrypted. On the other hand, the partition itself is 97.6 gb, and the Reflect image is only 77.96 gb, which doesn't seem reasonable if it's a byte-by-byte copy. But, looking at the other Reflect images of that partition, I see that it does manage to compress it somehow.  

Edited 24 August 2017 4:41 AM by ParrotSlave
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)
Group: Forum Members
Posts: 14K, Visits: 85K
Then I'm not sure how to account for what you're seeing.  Unrelated to that specific issue, have you considered enabling auto-unlock for your BitLocker To Go volumes?  For security reasons it requires that your Windows partition have BitLocker enabled since that's where the auto-unlock files for your BitLocker To Go volumes are stored, but it would obviate the need to precisely time your manual BitLocker To Go unlocks.  As for the backups, again I would really recommend capturing Reflect backups of BitLocker volumes in their unlocked state and using Reflect's own encryption to protect those files (or keep the backups unencrypted but store the files on ANOTHER BitLocker To Go volume....), either of which would reduce your storage requirements and simplify what you've been dealing with thus far.

Edited 24 August 2017 5:19 AM by jphughan
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)
Group: Forum Members
Posts: 14K, Visits: 85K
I have a theory for why your image file is smaller than the locked BitLocker partition.  If you chose to encrypt only the space that was in use when you originally created the partition (rather than the "Encrypt the whole drive" option), then it's likely that at least some of the sectors in the partition are still zeroed out, never having been written to.  In that case, I believe Reflect would be able to compress that even when performing a byte-for-byte copy.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search