The new Minion Backup 1.2: DB groups, scheduling options, and more!

Articles, Minion Backup / By

We released Minion Backup 1.2 (our Free SQL Server Backup utility) this week! We’ve got a some outstanding new features, and of course a number of bug fixes.

New features in brief: Free SQL Server Backup

  • Minion Backup allows you to define groups of databases (to include or exclude in backups).
  • The new @TestDateTime parameter lets you see which schedule will be used at any given time.
  • The FrequencyMins column adds more flexibility to your scheduling scenarios.
  • You can now set the backup job to fail or errors and/or warnings, if you like, using either the FailJobOnError and FailJobOnWarning columns, or similarly named parameters.

Minion Backup 1.2 New Features

The one page MB Highlights PDF is a good place to start, if you haven’t laid hands on our backup solution yet.

Database Groups

Minion Backup 1.2 allows you to create named groups of databases to include or exclude from backups (or from all maintenance), using database names and/or wildcard strings.

Minion Backup allows you to define groups of databases (to include or exclude in backups) in the Minion.DBMaintDBGroups table.

Let’s take an example: We will create a group named XYZ with Action=Include, and databases ‘DB1,DB2,DB3’; and, Action=Exclude, with databases ‘DB1,DB2’.

ID Action MaintType GroupName GroupDef Escape IsActive Comment
1 Include Backup XYZ DB1 NULL 1 XYZ: DB1
2 Include Backup XYZ DB2 NULL 1 XYZ: DB2
3 Include Backup XYZ DB3 NULL 1 XYZ: DB3
4 Exclude Backup XYZ DB1 NULL 1 XYZ: DB1
5 Exclude Backup XYZ DB2 NULL 1 XYZ: DB2

Then, a run of Minion.BackupMaster with @Include=’DBGROUP:XYZ’ would include only databases DB1, DB2, and DB3:

EXEC Minion.BackupMaster @DBType = 'User', 
 @BackupType = 'Full', 
 @StmtOnly = 0,
 @Include = 'DBGROUP:XYZ', 
 @ReadOnly = 1; -- backups for just DB1, DB2, and DB3

And if you run Minion.BackupMaster with @Exclude=’DBGROUP:XYZ’, it would only exclue databases DB1, and DB2:

EXEC Minion.BackupMaster @DBType = 'User', 
 @BackupType = 'Full', 
 @StmtOnly = 0,
 @Exclude = 'DBGROUP:XYZ', 
 @ReadOnly = 1; -- backups for everything except DB1 and DB2

And you can also use wildcard expressions (e.g., ‘DB%’) as an entry in this table.

Note that this table is shared between Minion modules, and as a result, will be available to all of them.

For more information, see the DB Groups video, and product documentation on www.MinionWare.net/backup.

Test Schedule for a Date and Time

The new @TestDateTime for Minion.BackupMaster is a €œwhat if€ parameter that allows you to see what backup schedule will be used at a certain date and time. This returns the settings that would be used at that particular date and time, and a list of databases (and their order) to be included in the batch.

EXEC Minion.BackupMaster 
 @StmtOnly = 1,
 @TestDateTime = '1/1/2017'; -- Tells us what schedule and what databases affected

 

Schedule backups using Frequency in Minutes

The FrequencyMins column is a new part of the settings table (Minion.BackupSettingsServer). It allows you to run the SQL Agent backup job as often as you like, but to space backups out by a set interval. Let’s say that the backup job runs every 5 minutes, but log backups should only run every 30 minutes. Just set FrequencyMins = 30 for the Log backup row(s).

Note that actual frequency also depends on the SQL Agent job schedule. If FrequencyMins = 5, but the job runs every 15 minutes, you will only get this backup every 15 minutes.  Therefore, you should set the Agent schedule to the most frequent time you want to run any of your backups.

One scenario where this might apply is needing a job to run every 5 minutes, so that user database backups can start as soon as possible after system database backups.  Without FrequencyMins, this would cause the log backups to run every time the job runs. With log backups FrequencyMins=30, the job will see that it hasn’t yet been 30 minutes since the last log backup, and it won’t take log backups yet.

Fail on errors / warnings

You can now set the backup job to fail or errors and/or warnings, if you like, using either the FailJobOnError and FailJobOnWarning columns, or similarly named parameters.

The FailJobOnError and FailJobOnWarning columns are a new part of the settings table (Minion.BackupSettingsServer).  If you set FailJobOnError = 1 will cause the job to fail – after the backup batch completes – if Minion Backup encounters an during the run. Similarly, FailJobOnWarning = 1 will cause the job to fail (after batch completion) if any warning was encountered.  Therefore, you now have two ways to report on backup errors: using these new parameters, or querying the LogDetails table.

For more information, see the official product documentation on www.MinionWare.net/Backup/

Minion Backup 1.2 Issues resolved

  • Installer issue: it wasn’t including new table columns needed because Microsoft changed the Restore Headeronly output.
  • Backups failed if SSAS is installed on the server and the service is turned off.
  • Incorrect error logic when reporting an error back to the Agent, and as a result, some errors weren’t reported correctly.
  • Since the StatusMonitor job should not have a schedule, it was removed.
  • Not logging the error properly when you haven’t enabled Powershell scripts.  It will now show up in the Minion.BackupLogDetails table.
  • Because sometimes @@ServerName and the machine name aren’t the same.  It’s the machine name you want to go by, so it now uses SERVERPROPERTY(‘MachineName’).
  • Minion Backup was needlessly removing Log shipping primaries from the backup list.
  • Scheduler table wasn’t honoring high-level schedules (FirstOfMonth, etc.) under certain circumstances.

Free SQL Server Backup just got a lot easier.

More resources