Persistent numbering with custom backup file names (even after purges)


Persistent numbering with custom backup file names (even after purges)...
Author
Message
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
I created this based on a request from @RefDM in this thread.  Basically, when using custom backup file names, Reflect will automatically add a number to the name if a set with the specified name already exists, or a higher number if a set with that appended number already exists -- but after that original "numberless" set gets purged, Reflect reuses the original numberless name rather than continuing along with its numbering, and lower numbers are then also reused whenever the original set with those lower numbers are purged.  RefDM wanted a way to continue numbering upwards rather than ever reusing the original name or lower numbers, so I took this on as a small scripting challenge and created a way to do this.  The setup involves creating a "counter" text file anywhere you like that contains a number. Whenever a Full backup runs, the number from the counter gets added to the "base" custom file name you've specified, and if the Full backup succeeds, the number stored in that text file is incremented so that the next Full will use that new number.  If you ever wish to reset your numbering or skip ahead, simply change the number in the counter text file.

Here are the detailed implementation steps:

1. If you haven't already, create a definition file that specifies a custom backup file name. The exact name doesn't matter, but you can't use a definition file that has "Use the Image ID as the file name" enabled.

2. Create a "counter" text file by opening Notepad, typing the number you wish to start with (must be an integer), and saving it somewhere, e.g. in the same folder as your definition file.

3. In Reflect, go to the Backup Definition Files tab, right-click your definition file, and select "Generate a PowerShell script file".  Make any desired selections in the dialog (though none are required for this), then click OK.

4. Open your new PowerShell script for editing.  PowerShell ISE is easier to work with, but Notepad is fine as well.

5. Take the contents of the attached Before-iResult.txt file and paste them into your script immediately above the line that reads: $iResult = (Start-Process -FilePath $strReflectPath -ArgumentList $strArgs -PassThru -Wait).ExitCode;

6. Make the following customizations to the script block you've just pasted in:
  • Change the value of $BackupFileNameBase to whatever backup file name you want to use.  Do not include any numbering that you want to have automatically incremented.  For example, if you want to end up with sets named MyBackup2018-0, MyBackup2018-1, etc., your base would be simply "MyBackup2018-". (NOTE: This name plus the value in the counter text file will overwrite whatever is stored in your XML definition file whenever a Full backup runs, so if you ever wish to change your backup file naming in the future, do it here rather than in Reflect.)
  • Change the value of $CounterFilePath to the path of the text file you created in Step 2.
  • Read the comment block about optional leading zeroes, and if you wish to use them, change the value of $CounterValueFormatted immediately under the comment to your liking.  Leading zeroes in the counter text file are ignored, so if you want them, you have to use this method.
7. A few lines down in your script you'll see a line that reads: return $iResult; Paste the line provided below immediately above that line:
if ($XMLFileMod -and ($iResult -eq 0)) {($CounterValue + 1) | Out-File $CounterFilePath}

8. Now make sure that your schedules, desktop shortcuts, and any manual job executions are associated with this new script, not the original definition file.  To do that, go to the PowerShell Files tab, right-click your script, and select Schedule and/or Create Desktop Shortcut to create your new items.  If you've been using scheduled backups, the last step is to go to the Backup Definition Files tab and remove your original schedule entries from the definition file.  And whenever you want to run a backup manually, right-click the script rather than the definition file and select Run Now.

Enjoy! Smile

Attachments
Before-iResult.txt (5 views, 2.00 KB)
Edited 23 June 2018 12:29 AM by jphughan
RefDM
RefDM
Junior Member
Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)
Group: Forum Members
Posts: 70, Visits: 191
@jphughan
I have already tested your solution by running the script directly from PowerShell outside the context of Macrium Reflect user interface, and it is a perfect solution. Thank you so much!

To me as a relatively new MR user, the script is also an important proof of concept about a robust way to extend MR functionality and to overcome some of its "limits". Furthermore, it will be easy to modify the script to read the counter value based on the existing backup file names in the destination directory. Maybe that will be my first PowerShell excercise Smile

( If I only were able to find yet a robust way to dig out the backup method used from the backup files themselves - to differentiate diffs from incres - I think the product would be pretty much perfect! )

( ...and having also support for booting the backups up in a VirtualBox environment would make it perfect... )

Edited 19 June 2018 4:43 PM by RefDM
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
Glad it works, but having thought along your lines already, be careful about trying to read numbering from an existing file name.  I thought about doing that in order to pull the number out of the XML file in order to avoid having to specify (and maintain) the $BackupFileNameBase variable in my script extension manually as well as keep a counter text file, but it occurred to me that it could never be a robust solution.  Consider someone who wanted files named MyBackup20181, MyBackup20182, etc.  That's admittedly not clean numbering, but it's the pattern Reflect itself would use if you had entered "MyBackup2018" in its image file name field.  In that scenario, there's no way to know which portion of that string of numbers at the end is the counter and which portion should be kept static.  I couldn't just increment that by 1, because when I got to MyBackup20189, doing that would result in MyBackup20190, when the user would have wanted MyBackup201810.  And you couldn't even always say "take the final X characters as the integer", because your numbering might require more digits as time goes on, and/or you might have changed your leading zero preference, etc.  And that was just for pulling numbers out of the XML file configuration.  Pulling numbers out of files that already reside on the destination as you're suggesting creates even more potential stumbling blocks, because that carries the added risk of potentially pulling files that were generated by other jobs, etc.  It also removes a perk of having an external counter file, namely that you can reset the counter value to whatever you want without having to mess with the files in the destination in order to make some "auto-detect" mechanism do what you want.

At the end of the day, I decided that anything I tried to implement along those lines would be ugly and still inherently unreliable, which meant that it could lead to unpredictable and confusing results and the hassle that came with that -- and since the whole point of this exercise was to improve organization and make things clearer, that seemed counterproductive.  So instead I went with the "KISS" philosophy. Smile

Edited 19 June 2018 4:57 PM by jphughan
RefDM
RefDM
Junior Member
Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)Junior Member (89 reputation)
Group: Forum Members
Posts: 70, Visits: 191
What you write makes absolutely sense.

I think I will let some time to pass and think of it in peace when I'm not in such a hurry as I'm now... (you already saw in the other thread a moment ago how I make mistakes in a hurry Whistling)

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
Ha!  I know the feeling, believe me.  In fact since originally posting my script extension above, I've edited it a couple of times to clean it up slightly.  It works the same way, but I just saw ways to clean it up a bit when I looked at it after taking a bit of time away.  Let me know if you think of any other things you could use or encounter any hurdles working on your own PowerShell.  Like I said, I enjoy little "hack-a-thon" projects like this as time allows. Smile

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
Made some small improvements to the script snippet attached to the first post in this thread.  It now handles (and provides useful feedback for) conditions where the XML file is still set to "Use the Image ID as the file name" or the XML file appears to be invalid.  I also added a comment explaining why the initial If statement includes the "$strType.Length -eq 0" condition.

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