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. »
You know this situation. In some remote site you have just some amount of empty tapes available and nobody to add new ones to library available. Or it’s Friday afternoon, tape library is down and you don’t know whether the space on staging disk storage unit will be enough to accomodate wekend backups? Here is a shell oneliner showing sum of last full backups for clients from list of policies (the policies configured for this particular storage unit):»
Simple shell script for adding new media server to all or selected NBU clients.»
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
Here is my solution.
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. (Hmm, Technote TECH129715 was deleted in meanwhile).
By Symantec we have to wait until SAP will provide dbmcli with more granular exit codes.
Seems that we cannot do anything.
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