Macrium Support Forum

Automatically mount and dismount drives

By russd1985 - 16 February 2017 12:14 PM

I know you can use Powershell scripts and the command line option to do some clever things with Macrium Reflect. However, it's quite complex, so it would be really helpful if there was a simple way in the GUI to automatically mount and dismount drives before and after scheduled backups.

I'm keen to avoid ransomware encrypting my backups, so by dismounting the drive at all times other than when it's backing up I could prevent this happening. 
By jphughan - 28 February 2017 4:55 PM

I suppose if the concern is ransomware, having a disk unmounted (I assume you mean just un-assigning the drive letter?) is better than not, but that also has you banking on ransomware not being smart enough to catch on to your ruse, which historically has not proven a safe bet. For example, early on users were able to recover from ransomware restoring from Previous Versions courtesy of local VSS snapshots (a feature I'm still annoyed was removed from client versions of Windows after 7 and now only available when paired with a File History target....) -- but ransomware developers caught on and responded by blowing away VSS snapshots.  I personally think the feature you suggest would lead to too much confusion even if it weren't on by default, e.g. people ticking this box in a the Reflect GUI in the name of security and later on wondering where their hard drive went after a backup completed.  I also think writing the necessary code to figure out which unmounted disk to mount and which drive letter to assign to it would be more effort than it's worth for the developers, especially since after all that effort your protection against ransomware still isn't nearly as good as setting up a disk rotation of external disks that involves physically disconnecting them, which is what I've implemented partially for that concern and also to facilitate off-site storage to protect against natural disasters.

All that said, Reflect does have an option to detect backup target by disk ID rather than drive letter, and since that's visible even when no drive letter is assigned and there's nothing preventing an application from writing to a disk that doesn't have a drive letter assigned, theoretically Reflect could write a backup job to that disk without ever mounting it -- but I don't know if it does.  Might be worth trying if you haven't already though, but note that the downside of specifying a backup target by disk ID is that it precludes setting up a disk rotation, which again is the superior solution anyway.  I use a little utility called USB Drive Letter Manager to ensure that all of the backup disks in my rotation are always assigned the same drive letter and it works wonderfully.

By jphughan - 11 August 2017 6:13 PM

I finally looked into this more, and while it does require PowerShell, it's not complex because Reflect builds most of the script that's required, and then you just need to add the lines to assign and unassign the drive letter.  I've posted about it in this thread:
By Nick - 11 August 2017 6:26 PM


Thanks for posting.

I'm keen to avoid ransomware encrypting my backups, so by dismounting the drive at all times other than when it's backing up I could prevent this happening.

Removing a drive letter will not thwart ransomware so I'm afraid you will be wasting your time.

The Windows API to enumerate local volumes does not require drive letters to be assigned:

Please note that we are releasing Macrium Image Guardian, to protect your backups from unauthorised access in the next Macrium Reflect update. 
By dyhs - 12 August 2017 12:09 PM

If you want to avoid ransomware, you had better physically disconnect your external USB hard drive after backup, that is to say unplug the USB cable, not just safely remove it in Windows or via any software that does the same.
The problem is, there are ways to re-enable a drive that was safely removed, as long as it is still physically connected to the computer.

Having said that, I also believe that some sort of "automatic eject drive after backup" feature in MR might be useful for some users.
First off, it would be handy because it automates an operation you should do manually anyway, the Safely remove before unplug. An (optional) pop-up window would remind users that "Macrium Reflect prepared your external drive [Drive id] for removal. Please unplug it". 
Secondly, I don't know if any current ransomware does actually take the effort to re-enable safely removed devices.
Therefore, an "unmount after backup" feature may not be futureproof but it at least adds a layer of protection from many current viruses when you can't physically unplug the drive for some reasons.

As an alternative, I would like a "Disconnect Reminder" feature for those who backup to an external USB drive.
That is to say, no automatic eject, but a pop-up window reminding that the drive be unplugged after backup.

By jphughan - 12 August 2017 3:18 PM

Yes, the only surefire protection is to disconnect the drives.  Anything short of that, including the drive letter assignment and removal PowerShell I provided in the Backup Scripting section -- before Nick burst my bubble with that MSDN article Tongue -- is basically better than nothing, but not absolute protection.  But then again, people employ "better than nothing, but not absolute protection" measures in all sorts of aspects of their lives.  Just because ransomware COULD access a drive with no letter assigned or one that had been safely removed but not disconnected doesn't mean that they all WILL, and for some people it simply isn't practical to physically disconnect a disk after each backup and reconnect it (or a different one) before the next one; I completely get that.

In terms of the proposed "automatic eject" feature, I think that's the crux of the issue.  It isn't a fully effective ransomware safeguard, just like the drive letter removal idea that Nick opted against implementing for that very reason.  And it also puts the burden on the user to remember that "Hey, even though my drive is still connected, it's been ejected, so it's not actually usable", unless of course Reflect started probing for such "ejected but still connected" disks before executing the next job.  It sounds to me like Macrium has already found a ransomware protection design they're more confident in with the upcoming Image Guardian feature, so I doubt these lesser measures will really be considered.
By dyhs - 12 August 2017 3:57 PM

Image Guardian is a new feature. I completely trust Nick but I'd wait and see how it works out.
Anyhow, it's for V7. I only have 6 for now. Smile
Besides, I happen to store other stuff on same disk other than MR backups.

By Froggie - 12 August 2017 4:24 PM

With another application I use for my Files & Folder backup, I use a different approach for connected drives and it works well, for me at least.

There is a utility available in the Windows Development kits (it's different for different versions of Widows) called DEVCON.  DEVCON is basically a command-line version of Device Mgr.  As such it allows me to REMOVE a device from the System... the same operation as would be exercised by the physical removal of the device.  It also removes the driver reference to that device... meaning that the next time you plug it in, Windows will re-discover the device and assign the needed driver.  When these functions are used, that device cannot be accessed by Windows at all.  To get access to it once again, you must un-plug/re-plug the device or execute a device re-scan operation within Widows (done in DEVCON as well) that can re-discover the device and assign it to a driver (same as if you plugged it in from scratch).

Using that tool and appropriate MOUNTVOL commands on the way in and way out.  That device is very safe from any nefarious activities. Sure, if MalWare is really targeting that System specifically, it can run those appropriate Windows device re-scans and re-discover the device (if plugged in and powered up), then mount it for appropriate access (it doesn't really need drive letters to do that),.. but it really has to be targeting a System at its lowest possible level to discover all that stuff.  But this at least allows me to protect the end of my file operations by making this device blind to Windows.  Both DEVCON (if System resident) and MOUNTVOL are available for use with scripting under REFLECT.

In addition, I use a System NT level file modify/write protection driver (what MIG will wind up using through standard Windows protection mechanisms) that protects those sensitive file areas when and if that device is even mounted.  Unless MalWare/RansomeWare is targeting my particular System configuration, I feel quite safe at the moment.
By jphughan - 12 August 2017 6:38 PM

dyhs - 12 August 2017 3:57 PM
Image Guardian is a new feature. I completely trust Nick but I'd wait and see how it works out.
Anyhow, it's for V7. I only have 6 for now. Smile
Besides, I happen to store other stuff on same disk other than MR backups.

Totally agreed that it's new and will therefore need to be tested.  I was just pointing out that it's clear Macrium has focused their anti-ransomware efforts on this feature and therefore I don't see them putting effort into the building native support for the types of obfuscation techniques we're talking about here, especially if they're also less convenient and less effective than Image Guardian.  I too store other things on the disk that holds MR backups, but depending on how Image Guardian is implemented, that may not pose a problem.  It could lock down only specific folders (or even files) rather than entire drives, which appears to be what Microsoft is doing with the Fall Creators Update, although I haven't experimented with the Insider builds to know for sure.