3 reasons I don't like Storage Lifecycle Policies (in NetBackup)

At the beginning I have to admit that Storage Lifecycle Policy (SLP) is a great idea.

During ancient times of NBU we had NBU Vault available. Nifty tool allowing us to select backup images by various filters and create new copies on tapes prepared to eject from tape library and transport to offsite location. And by reading documentation for 7.6 version it supports duplication from any Storage Unit (STU) to any STU. (Do I remember properly some limitations in older versions?) But as I remember it requires explicit license - not cheap for non-capacity based NBU customers. The configuration allows you to duplicate anything but you have to do it properly to really get all images you need. My personal opinion is that simple script creating proper list of images (the though part) and then to run bpduplicate command can do the same. NBU Vault offers you nice GUI for configuration and some few more nifty features.

Since NBU version 7 the SLP was born. Put in basic installation, no special license required. Easy to use, easy to configure. Using the same bpduplicate command as backend. But there are big differences. The main one is that SLP is considered as logical backup destination unit and all backups using it will just follow some rules to get desired amount of backup copies on the right places. Other big difference is possibility to chain duplications and select which copy will be used by which duplication. Pretty nice if you need (e.g.) disk copy of backup in company remote branch, another short retention disk copy in headquarter, long retention tape copy and and offsite tape copy due to legal demand.The biggest difference visible to user/admin is simplicity! There is almost nothing to configure (and of course screw up).

As I mention already - great idea.

And now comes the list of reasons why it's not great implementation. It seems like it's designed by different bunch of people they never seen NBU Vault. Is the rumor about buying of some other SW product by Symantec right? Great idea but with stupid implementation.

Read my 3 reasons by opening a full article.


NBU Java console authentication and authorization - integration with Active Directory

In many enterprise environments the ActiveDirectory authentication is used even on Unix/Linux servers. It's much smarter way how to manage a lot of users and groups. But - by default - NBU requires local Unix user. What is you want to used AD auth for NBU Java console too? I was inspired by discussion forum on Symantec web. Solution is easy. But how to handle authorization configured in /usr/openv/java/auth.conf ?
Here is my solution.


SAP/MaxDB backup of transaction logs - status code 6 resolution

If you are backing up transaction logs of SAP/MaxDB you probably have often failed backups with status code 6. But nothing wrong happened. Just no transactions was available for backup. It's a behavior of dbmcli - anything except successful backup returns exit code 1. But parent wrapper script provided by Symantec is not able to distinguish real errors from situation where there are just no transactions to backup. (Read TECH129715). By Symantec we have to wait until SAP will provide dbmcli with more granular exit codes. Seems that we cannot do anything.

Or can?


Netbackup Storage Lifecycle Policy by my way

I don't believe disk arrays. Even you have great RAID protection, replication, snapshots there is still something called firmware. And it can have a bug. Usually it has (read release notes of next version) but fortunately not mandatory.
And there can be a bug screwing parity and this can be really bad.

You need to protect your disk based backups. I will describe you 3 different options by using of NetBackup:

  • Multiple copies of backup job
  • Storage lifecycle policies
  • Own perl script using bpduplicate