Specifying backup target drive letter using a script


Author
Message
valkyriebiker
valkyriebiker
New Member
New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)
Group: Forum Members
Posts: 2, Visits: 18
Hi all...

1st, some background: I have a number of clients that I've installed MR for that backs up to multiple external USB hard drives for the purpose of offsite rotation. I've developed a simple batch script (Windows) that allows me to identify the drive letter of the backup target then modify the MR XML config file (using FNR.EXE) then launch MR via command line. This way, regardless of which backup drive gets plugged in and whatever random drive letter it gets assigned to it, I can still find it and pass that along to MR. This also help if the user has one or more USB flash drives plugged in and/or network drives mapped that may hog preconfigured drive letters. It just lets MR work, period, regardless of drive letter. Also, MR automatically figures out what type of backup (Full, Incr, Diff) based on the files on the target drive (guid-xx-yy) that happens to be mounted. This has worked flawlessly for several years now, since v5.

Now a comment leading to my question: Reflect v7's new MIG feature is exactly what I've been waiting for. But in reading about MIG, it appears that MIG identifies the target drive\directory by examining the XML file then protecting the MRIMG files in said directory. Well, that won't work for me. In the XML, I specify a known sentinel (a dummy path that would never happen) that I search for using FNR.EXE and then replace that dummy path with the discovered drive and path for *this particular run* of MR. Again, works great.

Now my question: Q1: Am I understanding MIG correctly in that, does it indeed examine the XML to figure out where the MRIMG files are? I mean, that makes sense, but it'll break my code. Q2: Can MIG be somehow be configured via command line where to look for MRIMG files to protect? Q3: And can that protected location be changed on the fly? Q4: Finally, anyone else facing the problem wandering drive letters and how did you resolve them?

thanks.....




jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)
Group: Forum Members
Posts: 4.4K, Visits: 32K
Your understanding isn't quite accurate.  When you have "Automatically protect local disks" enabled in the MIG settings, then yes MIG will automatically be enabled for any local NTFS volumes that are specified as destinations in definition files -- and even if you manually disable MIG on one of those volumes, it will be re-enabled the next time a job is sent to that destination.  However, whenever MIG is enabled on a volume, whether automatically or manually, a marker file is stored in that volume's System Volume Information folder, and the result is that whenever that disk is attached to any system that has MIG running -- not just the original system where it was enabled -- MIG will see that marker and enable protection for that volume, regardless of drive letter and without waiting for a backup to be written to it.  So basically, enable MIG once on each disk in your rotation (or just wait for it to happen organically as a backup is written to each disk, if it hasn't already), and then you'll be set going forward.

As for your drive letter predicament, I have a client that uses a 9-disk rotation and for a variety of reasons I preferred to keep Reflect using drive letter targeting rather than Volume GUID targeting, the latter of which is a common solution for drive rotation strategies that avoids having to worry about drive letters at all.  I managed consistent drive letter assignment for the disks in the rotation using a much simpler method that does not require calling Reflect via a script.  I wrote about it in this post recently if you're curious; check out the second paragraph: https://forum.macrium.com/FindPost22713.aspx

Edited 27 April 2018 10:46 PM by jphughan
valkyriebiker
valkyriebiker
New Member
New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)
Group: Forum Members
Posts: 2, Visits: 18
jphughan - 27 April 2018 10:30 PM
Your understanding isn't quite accurate.  When you have "Automatically protect local disks" enabled in the MIG settings, then yes MIG will automatically be enabled for any local NTFS volumes that are specified as destinations in definition files -- and even if you manually disable MIG on one of those volumes, it will be re-enabled the next time a job is sent to that destination.  However, whenever MIG is enabled on a volume, whether automatically or manually, a marker file is stored in that volume's System Volume Information folder, and the result is that whenever that disk is attached to any system that has MIG running -- not just the original system where it was enabled -- MIG will see that marker and enable protection for that volume, regardless of drive letter and without waiting for a backup to be written to it.  So basically, enable MIG once on each disk in your rotation (or just wait for it to happen organically as a backup is written to each disk, if it hasn't already), and then you'll be set going forward.

As for your drive letter predicament, I have a client that uses a 9-disk rotation and for a variety of reasons I preferred to keep Reflect using drive letter targeting rather than Volume GUID targeting, the latter of which is a common solution for drive rotation strategies that avoids having to worry about drive letters at all.  I managed consistent drive letter assignment for the disks in the rotation using a much simpler method that does not require calling Reflect via a script.  I wrote about it in this post recently if you're curious; check out the second paragraph: https://forum.macrium.com/FindPost22713.aspx

Wow, that sounds perfect!

Follow-up question/confirmation: Then MIG protects the entire volume? e.g. Are all other directories and files having nothing to do with MR that happen to be on the same volume protected as well? I use only dedicated disks for backup targets so that would not matter, but it would be useful to know that. Thanks for your answer earlier. I'll check the link you posted.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)Macrium Evangelist (6.5K reputation)
Group: Forum Members
Posts: 4.4K, Visits: 32K
MIG only protects backup files generated by Macrium applications, which are identified by their file extension. It will do so wherever they exist on the protected volume rather than just in the destination folder for example, but it does nothing to protect other files. That limited focus is why it’s able to take a much more secure approach than more general purpose solutions like typical anti-malware solutions or even Microsoft’s Controlled Folder Access anti-ransomware feature. Those solutions take a “blacklist” approach, which means they rely on definition files and heuristics to identify known bad applications/activity, but in order to avoid being so intrusive that the user throws up their hands and disables them, they fundamentally err on the side of allowing activity unless they have a clear reason not to — and that “default trust” creates an opportunity for malware activity to occur undetected. (The use of heuristics can also cause those applications to block legitimate activity, but that’s a whole other problem.) By comparison, MIG takes the opposite and much more secure “whitelist” approach, operating on the basis that Macrium applications are trusted (and by default so is Robocopy under certain conditions) and everything else is categorically NOT trusted, including the user working in Windows Explorer. That design isn’t nearly as practical for a “general purpose” file protection solution, but Macrium can “afford” to design MIG this way precisely because they’re only focused on protecting Macrium file types, which normally only ever need to be modified by Macrium applications anyway. The only cases I can think where users might need to modify Macrium files outside of Macrium applications would be moving or renaming them, but those needs would typically be rare rather than routine. Deleting files can be achieved within Reflect itself.

If you want to learn more about MIG, take a look at the KB article about it. The marker file isn’t mentioned — I learned about that from Macrium and confirmed by looking for it — but it does explain a lot: https://knowledgebase.macrium.com/plugins/servlet/mobile?contentId=8726408#content/view/8726408
Edited 29 April 2018 1:15 PM by jphughan
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