At different points in its process, Minion Backup writes a trigger file to a share. This allows Minion Enterprise to then collect the data and save it to its repository for use in alerting, trending, etc. The use of a trigger file was a deliberate decision we made to give you full control and flexibility over your process.
Here are the advantages to having a trigger file process, instead of having each client server write its data directly to ME:
- You get a distributed architecture. If for some reason all the client servers can't access the ME server, you can give them different trigger file shares and then another copy process can pick up the files and copy them to a more suitable location, or you can now have a firewall rule (for example) opened up from that single location to the ME server. And you don't have to have another ME server to make this happen, so it saves you on SQL Server licensing and complexity.
- You get simple ME disaster recovery. Should something happen - say the ME server goes down, or the network segment goes down - you can easily switch the trigger file location to somewhere else so you don't miss any collections. This way when the ME server comes back up, you can change the trigger file share back to what it was on the client servers, and copy the files over for processing. This way you avoid having to do a full import of all the logs, and you don't have to have another ME repo server around as a backup.
- You can easily place your own files in the trigger file share. All you need to do is create them the same way the MB process does, and you can use it to create your own log file imports.
- You can roll your own. If you don't like the way the ME history process works, you're free to turn it off and write your own. You can have MB continue to write the trigger files, and you can create your own process to pick them up and deal with them however you like.
There may be more advantages, but I think you get the idea. This architecture allows for a flexible, resilient process.
Executables
MBHistoryProcessBackupDB.exe
This executable processes trigger files for the Minion.BackupLogDetails table.
The Minion.BackupDB procedure for MB creates the trigger file for this collection. MB writes the trigger file as soon as the backup completes - not after the backup batch completes - so the data can be collected into ME for alerting. If the backup fails, we try to give you the error message in the alert email itself; this collection is where that comes from. So process writes the file for this collection before the entire MB process is finished.
Let's take the example of a backup process with verify and copy. What happens is:
- MB backs up the database,
- then creates the trigger file,
- then verifies the backups,
- then copies the backup files to three locations.
Again, this ordering is to ensure that any errors can be reported to ME right away for alerting. The Minion.BackupLogDetails will continue to be updated as the rest of the processes complete though, and these changes will be picked up in a later collection.
MBHistoryProcessBackupMaster.exe
This executable processes Minion.BackupLogDetails, Minion.BackupLog, and Minion.BackupFiles from the Minion Backup backup procedures. The trigger files for this collection are created as one of the final steps in the Minion.BackupMaster procedure. By the time the BackupMaster procedure finishes, all the MB log tables have been written to and are now ready to be put into ME in their final state. And at this point, since the initial reporting of the backup status has already been reported in the collection above, then this data is merely for trending and other types of analysis and is less critical to get into the ME repository right away.
MBHistoryProcessBackupFiles.exe
This data currently isn't being collected as of Minion Backup 1.2. However, when we do start managing this, it fills in a hole that the other two collections don't cover. The above collection creates trigger files for backup files that were created during the backup process, but it doesn't know anything about backup files that may have been marked as deleted as part of the process. These files won't have the same ExecutionDateTime as the current process, but they did have a change made to them. So this process is meant to pick up those changes so the ME repo knows when files are no longer on disk.
Related Articles:
Setting up Minion Backup collections in Minion Enterprise
Troubleshooting Minion Backup collections in Minion Enterprise