Who changed that backup specification?

Backups can fail spontaneously, but generally I've found that the most common reason for a Data Protector backup to fail is because somebody has changed something.

There are two solutions to this, depending on the level of tracking you need.

For the light touch, there is a global parameter "EventLogAudit" which you can set to 1.

It seems like you just need to restart the GUI for this to take effect, even though you will get a message saying that you need to restart all Data Protector services.

After you have made this change, you can then see when a change has been made. So, to demonstrate, I removed a file server from the backup job called "LegacyServers". This is what appeared in the event log:

It doesn't show any more detail than this though. You can't tell what was changed.

If you need tracking of precisely what was changed and when, then you need to implement a version control system. I'll put that in another blog post, but it's not difficult.

The screenshots below are using TortoiseGIT (which is a Windows front-end to git). Because Data Protector's job specification format is a collection of plain-text files, this kind of version control works particularly well. The benefits are:

• Each commit shows exactly the change that was performed and why.
• It's very easy to revert changes, even parts of changes.

Let's say that someone has made a change. Apart from the Event Log message, the relevant folder will look like this (note the red exclamation mark, signalling a file that has not been committed):

The administrator fixes this by running a commit:

To commit, the administrator needs to provide a log message, to explain why this was done. You can put in the change request number if this makes sense, or any other comment at all.

Once that has completed, we can now see that all changes that have been made to the Data Protector environment have been documented in the version management system. Green tick marks everywhere!

So if tonight's backup fails, or we discover later that "fileserver" is not being backed up and we don't know why, we can look back through the history of the backup job:

We can even run a "diff" command to show precisely what changed between two versions.

Never get caught out by a changed backup again!

If you found this blog post helpful, you will probably really enjoy my books on Data Protector: http://www.ifost.org.au/books.



Greg Baker is an independent consultant who happens to do a lot of work on HP DataProtector. He is the author of the only published books on HP Data Protector (http://www.ifost.org.au/press/#dp). He works with HP and HP partner companies to solve the hardest big-data problems (especially around backup). See more at IFOST's DataProtector pages at http://www.ifost.org.au/dataprotector