In answer to the question above, I know I certainly do. I use VMware Data Recovery (vDR) to backup my main lab, and I have another lab coming online (depending if I go hiking this weekend or not!) and I will use vDR in that lab as well. This means, if I wish to check on the status of my backups, I will need to proactively each morning connect to those labs, and see if the backups went well. Now, quite frankly, they normally do, but on occasion they don't and I must know that so I can take action. Sometimes a backup that doesn't execute is actually a clue for something else – such as lately for me an Active Directory issue and thus blocking vDR from accessing an AD protected CIFS share. The backup not going was a clue I had an issue with my AD and the first indication of the issue. But I do not want to access the appliances to check things if there is no issue! Thus, I need to be alerted to the status of the backup jobs and not look at the appliance each morning and instead only look when I need too.
But, in case you would like to have an email that says how your backup went – successful or not than read on.
Background
It is important to understand that in a future major release, we will have email reports available without any of the work we are going to do below. In addition, what we will do below will NOT work in the next major release. I will update this article for those changes so this article will work, but the fact is you will have real email reports available so you likely do not need this information in the future.
We will be using something called syslog to create our messages. We will configure vDR to deliver syslog messages to a syslog server that will be able to filter for them, and than forward them as email messages that arrive in your mailbox. Not hard, or time-consuming for us to do but it is a little different.
The little secret that makes this work is that vDR generates syslogs messages with the facility of uucp. This is of course not what we want it to be done with, and that will be fixed in a future major version that has email reports. But once you know that, if you know syslog already, you are good to go. But we will provide additional information below in case you are not familiar with syslog.
I am using a syslog server called Kiwi as I have used it in the past and am familiar with it. It is important to note that most syslog servers should be able to do what we are doing with Kiwi.
vDR changes
We will start by accessing the vDR console to configure syslog to send vDR messages to our syslog server.
Using a tool like Putty, access the console with the root account and the root password. The password starts out as vmw@re and hopefully you have changed it!
Change to the /etc folder.
Use your favorite linux editor (insert smile here), VI to add the following to the last line of syslog.conf: uccp.*@your_syslog_server_ip_here
Important to understand that only tabs should be used between the uucp.* parameter and the @your_syslog_server_ip_here value.
See the screen-shot below for what your syslog.conf should look like when you are finished.
Note: one of the things that will change in a future release is we will not use uccp but rather something more appropriate.
To make this change live, you will need to restart syslog in the vDR appliance.
The command to do that is:
service syslog stop
service syslog start
Once the syslog service starts it will use the new configuration that includes your changes.
See below what you should see when you restart the service.
Syslog
You should now trigger a backup job. If you do, and a moment after it finishes, you will see something in your syslog server like the following.
Now for a little background on what you see.
I have a backup job in my vDR appliance called Local Apps, and it backs up a number of VM's. So I have a line above for each VM that is backed up as part of that job. That explains why I see Script "Local Apps (sql1)" completed successfully. It means that the VM SQL1 was backed up as part of the job Local Apps successfully. So script means the job you created in vDR. Plus, the name in brackets is the name of the VM.
As well, you can see a line that has Script "Verify" and Verify is actually an internal name (one of the things that will be changed in a future release) and it means Integrity Check. Another script is called "Grooming" and it means Reclaim. It too is an internal name that will be replaced in a future release.
Once you have this information in your syslog server, you can now start to filter it, and report on it.
I created a filter to capture syslog messages from my two appliances. See below for an example of that.
Once the traffic from those two appliances is captured, we need to turn it into an email. I created an action to do that which you can see below.
I did not change much in this screen, but added my email address, and the vDR traffic part to the subject line. This will send to me every syslog message from either of my appliances. At some point that will be too many, and I will change the filter. For example, once I am over the excitement of receiving emails on the job status, I will likely change the filter so that I will only get emails on failed jobs.
Summary so far
I have modified the syslog.conf on the appliance so that any vDR messages are sent to my syslog server. Plus I have created a filter on my syslog server that will capture any messages from either of two different hosts – which are my vDR appliances. Then I created an action that will email the syslog message to me.
The interface of Kiwi may be different than what you are familiar with, but I hope the information here it still provides you with what you need!
So does it work?
The email
See below for an example of an email that originated with vDR and is seen in Zimbra. This is, after all, what this blog is about!
Conclusion
With the information above – primarily the facility uucp, you can have your vDR appliance forward vDR syslog messages to a syslog server. Once that is done you can filter for them and turn them into email messages. I showed using the Kiwi syslog server how to do this.
Please remember that several things in this blog will change in the future with a new release, but with that release you will have native email reporting and this blog will not be necessary for most people.
Any questions, comments or clarifications please do not hesitate to leave them in the comments.
