AppAssure has done a fantastic job thus far at backing up my Exchange 2013 infrastructure. Like all Exchange backup solutions, it is not without its quirks. One potentially harmful quirk is that it sometimes seems to forget it is backing up Exchange data. That may sound worse than it is because that Exchange data is still backed up. The problem is that it doesn’t send truncation commands to the Exchange databases when a full backup is done.
This is important because Exchange databases log all their transactions (eg every email) in a series of small log files before committing them to the database itself. This is a typical guard in many types of databases to prevent against corruption and data loss. These log files can grow pretty quickly, and unless an Exchange database receives a truncation command, it will continue to keep all these logs around. You’d be surprised how quickly hundreds of gigabytes of space can be chewed up. When Exchange runs out of space for log files, the databases hard crash.
Disk space monitoring should help protect against that in the idealistic fairy tale world where monitoring always works, alerts are always read, and nothing is causing an exponential increase in disk space. I don’t live in that world, so I wanted to guard against that. AppAssure assured me (see what I did there?) that they didn’t offer a way to alert on failed truncation events. I found that a bit strange being the main reason other than data protection for Exchange backups, but I dug into their PowerShell cmdlets to see what I could whip up.
I found a get-completedjobs cmdlet that was promising. That returned a status attribute that indicated if the job ran successfully. Then I found that the job description would contain “truncation” if it was attempting to truncate the Exchange database logs. This was promising. My first attempt to script it out was rushed and primitive. It was was tailored for my environment searching against specific servers and would only provide a generic alert if it had been two days since the last truncation. It did the trick, but it gnawed at me whenever an alert came through.
Finally I set aside a couple hours to script out a better solution. It’s finally to a point where I won’t hide it in shame. Contained within the report is each Exchange server that is being backed up, whether it passes or fails the backup check (truncation in the last couple days) which is color coded green or red respectively, and the date of the last truncation. If all servers pass the backup check, the subject states that. If any number of servers fail, the subject states that there were failures and lists the failures. There is also console output in table format showing the results and the processes.
I’ve uploaded the script to the Microsoft Technet repository here.
Below are examples of the pass and fail reports as well as the console output: