Please forgive this new user, but I can't get my mind straight about how reflect.exe handles grandfather scheduling when invoked from a .bat file.  I'm trying to set up a .bat file which will, on completion of a daily incremental backup, temporarily connect to a network server and robocopy the new backup file(s) across to the server.  Eventually, I'm thinking also of arranging for the less frequent differential and full backups to do likewise but only when explicitly triggered (I anticipate the larger network transfer for these to take hour(s) and I only want them to run when it suits me).

From what I've can see so far, some aspects of the scheduling of a normal .xml definition appear to be integrated into the .xml definition, although the Windows Task Scheduler lists separate tasks for each of full, diff, and inc.  So am I right in thinking that, provided the backups are otherwise "similar", reflect.exe somehow gets to "see" all of the scheduled  tasks before they are run to work out which one to actually perform?

Given that, I note that the reflect.exe has command line switches -full, -diff, and -inc, and the command help is pretty explicit in stating that if none of those switches is specified, then a full backup is performed ... "by default".   Sorry to be pedantic, but what does "by default" actually mean?  Does it actually perform the backup implied by the definition backup plan info in the .xml file?

And if I create a .bat file, right click it in Reflect and attempt to schedule it, am I scheduling the .bat file, inserting some backup plan info into the associated .xml file, or both?

Or ... and I suspect this may be the case ... is it just that the Definition Backup Plan info in a .xml file doesn't apply / is ignored when reflect.exe is run from a .bat, .vbs, or .ps1 file?

Bill R

By default means that if you do not specify which type of backup to perform (full, differential, incremental) then a full backup will be done.

The XML file provides info to Reflect on what do for a backup.  The XML file name is passed as a parameter to Reflect.exe in the batch file. 

Reflect does not "see" anything.  When a scheduled task runs, the task will invoke Reflect with the XML file you specified to use for THAT scheduled task.  If you have multiple scheduled tasks then each will pass the XML file name that is specified IN that task (whether its format is DOS Batch, VBScript or PowerShell).  Tasks are independent and have no knowledge of each other.

Normally YOU do not create a file to run as a scheduled task.  Reflect will create that file for you, then you can modify that file to add logic to, for example, copy the backup to another drive.  Since Reflect has created that backup, and it does so by YOU specifying WHICH XML file to use when running that backup, each backup is related to one and only one XML file.

Perhaps I've misunderstood that initial part of your plan, but does it indicate an intention to begin by copying only the newly created incremental backup files and not the full and differential backup files on which the incrementals are based?   If so, it should be clearly understood that incremental backups alone (i.e., without the prior backups which are their "points of departure") will not provide a valid backup set for recovery purposes.  In fact, any "missing link" (or a corrupted one) in an incremental chain invalidates everything thereafter.

Regards, Richard V. ("Arvy")

=Arvy .. sorry, I phrased that badly.  I should have said "The less frequent differential and full backups will also be robocopied likewise to the network server, but  I'm thinking of eventually arranging for those to be run and robocopied only when explicitly (i.e. manually) triggered (I anticipate the larger network transfer for these to take hour(s) and I only want them to run when it is suitable to do so, space- and time-wise)."

No problem, Bill.  I suspected that the warning might not be required, but just wanted to be sure that you weren't headed unaware for a potentially disastrous result.

I would have thought that you'd probably want "extra insurance" for your most recent full and differential backups whenever they're created, perhaps even more than for your latest incrementals, but that's strictly an individual judgement call, of course, and I can certainly understand your wanting to trigger the processes during idle time.

Regards, Richard V. ("Arvy")

I understand that creating ONE grandfather-father-son Backup Definition prompts me to enter THREE separate schedules, one for each type, and results in THREE separate corresponding entries in my Windows Task Scheduler list, EACH referring to the same XML file but with an appropriate -full, -diff, or -inc parameter specified.  I understand from other posts (e.g. http://forum.macrium.com/FindPost473.aspx ) that "if they are all set up for the same time ... Macrium figures out the right thing to do and does it (Full over Diff and Inc, Diff over Inc, etc)".

If, as you say, "Tasks are independent and have no knowledge of each other" what is it that enables Macrium to figure out "the right thing to do" .. i.e. to initiate only the dominant type of backup?  Or have I got the wrong end of the stick?

I'm realising that if I want to go on to creating an equivalent MS-DOS Batch file (using the Reflect UI) which I can modify, I will actually need to create three MS-DOS batch files, one for each type, and will need to schedule each one separately.  If I do so, will the mechanism which ensures that only the dominant type of backup is created still to continue to work? - I can't think why it shouldn't, except for the fact that I don't actually know how Macrium does this.

I appreciate that an alternative solution would be to imbed some conditional logic into just one batch file, but unless I also put more logic into the scheduling I could still finish up with three instances of the batch file being initiated simultaneously.  If Macrium can sort that out for me, so much the better (or rather, easier).

Bill R

Arvy, tx for that info. I don't have any actual problems at the moment, but am just trying to ensure I don't create problems.

Scenario -
1) Three scheduled .bat files start simultaneously, -full, -diff, -inc, all referencing the same .xml file
2) They all invoke macrium.exe, which, using its own scheduling service, ensures that only one creates a backup.
3) In each .bat file, macrium.exe returns to the .bat file which then invokes robocopy.
4) According to how it works, that potentially could result in two or more of my robocopy steps overlapping not only with themselves but with the creation of the "dominant" backup file.
5) .. with undesirable results.

Possible solutions
1) Find some way of testing the macrium.exe outcome, to suppress the robocopy phase if the particular type of backup was skipped
2) Introduce some form of interlocking, either before or after the macrium invocation, to prevent overlapping
3) Only run the -full and -diff manually when they won't clash with the .inc or with each other (which would be a shame given the effort macrium has put into trying to deal with that situation).

It all depends on how it actually works at present, but I don't fancy the "interlock" solution, especially in a .bat context. I'm an "old-school" systems application designer, and my experience with interlocks is that they're best left to someone else ...

Bill R

Given that Reflect will handle simultaneous triggers sequentially, I'm still not completely certain that I fully understand your dilemma, but if you're not locked into using .BAT file logic for some reason, you might want to consider some other option such as a VBScript.  Reflect will generate one for you if you right-click on the .XML task definition and select the "Generate a VBScript File" option.  It includes a GetBackupTypeParameter function that allows main process differentiation based on the type of backup (full, differential, or incremental) that is specified on the command line as follows:

Function GetBackupTypeParameter
 Dim i

 for i = 0 to Wscript.Arguments.Count - 1
     If Wscript.Arguments(i) = "-full" OR _
        Wscript.Arguments(i) = "-inc" OR _
        Wscript.Arguments(i) = "-diff" Then
         GetBackupTypeParameter = Wscript.Arguments(i)
         Exit Function
     End If
 Next

 GetBackupTypeParameter  = ""

End Function

Regards, Richard V. ("Arvy")

Ahhh .. I think I've discovered the source of one of my quandries  ...

When generating a .BAT file, the Macrium UI asks for and fixes the backup type when it creates the .BAT file.  If I then use the Macrium UI to schedule that .BAT file, it only permits me to add schedule(s) of that backup type. Hence I have to create three differently-named .BAT files - one for each backup type.

When generating a .VBS or .PS1 file, the Macrium does NOT ask for the backup type when it creates the file.   If I then use the Macrium UI to schedule that file, when I add a schedule it THEN asks me for the backup type, and THAT permits me to add a schedule for each type using just one .VBS or .PS1 file.

I suspect the .BAT file is treated differently, because otherwise conditional parameter logic would need to be included in the .BAT file, and although it could be made to work, it would be rather messy.

So, let's assume I'm working with a single .VBS file (or .PS1 file - I don't think it makes any difference).  In which case, my other quandry remains.  There will still be three schedules in place for that .VBS file, one for each backup type.  If those schedules are actioned simultaneously (not unlikely), then, according to how reflectservice.exe works, that could result in up to three simultaneous instantations of the .VBS file.    Three instances of robocopy could then find themselves being executed simultaneously.  And THAT could result in undesirable duplication, or even triplication, of the network transfers, or I suppose there could even be a data corruption scenario possible in there somewhere.

I think my ideal solution would be a return code from reflect.exe to indicate when one of the backup types is suppressed for the above reason. The .VBS /.BAT /.PS1 file could then suppress any following robocopy.  Any idea what code is returned in that event?   It would be nice if it was not an "error" code as such, since it wouldn't merit the backup being flagged as having failed.

But, as I said, it all depends on how reflectservice.exe actually makes this feature work ...

Bill R