Architecting Catalog protection and recovery

[DPFreelance]

Greetings!

I am working on re-architecting my NBU environment (currently mastered on AIX) with a new build and design.

Currently I backup and protect my catalog with physical media.  My goal for the new catalog backup/protection is to write that out to a disk unit attached to the master and then use hardware replication for offsite protection of said catalog.  This disk will be 100% dedicated to catalog backup ONLY.

My concern comes down to catalog recovery; obviously with physical media that's a fairly simple process: locate the appropriate tape and feed it to the recovery process.

I have a new test build to try out architectural options and new features for planning the new environment and I've setup an Advanced Disk target on the master to drop its catalog backups.  Backing up the catalog that way seems to be all fine and lovely.  But reviewing the Catalog DR file it generates has brought a question up:  If I'm in a catalog recovery scenario (building burned down/whatever), exactly HOW does this work?  As you can see below, the DR file specifies a specific disk storage device.  If I'm rebuilding a master and rebuilding its disk pools, I am guessing that there is no guarantee that they get the same 'path' assigned?  Can I get around that by inventorying the recovered diskpool?  Should I use Standard Disk instead of Advanced Disk (don't recall seeing that during the setup, is that still a thing in 8.2?)  Essentially:  how do I feed the recovery process these files?

Catalog Recovery Media

        Media Server       Disk Image Path     Image File Required

      * <servername>     @aaaah              Catalog_1572449441_FULL

      * <servername>     @aaaah              Catalog_1572449451_FULL

[mph999]

Advanced disk (or other type that uses @aaaab type of media id) is a pain as you suggest, as when rebuilding, unless the disk 'is' @aaaab ' (as only one disk on system) then yes, there is no guarantee that the disk is going to have the same media id.  You can get around this - for exacple if the disk is @aaaac then if you added a temp adv disk first, that would be @aaaab, you ould then add teh disk containing the catalog which should then be @aaaac.

Ultimately though, you end up having to re-sync the dr file, you could edit this, but nbcatsync command should take care of it - which is the 'official' way, although I have seen issues in the past with it working perfectly.

The problem with putting the catalog to disk is getting a copy offsite, you could duplicate it if you have offsite storage.

The other problem with disk is thtat if the disk goes, or corrupts - you can lose everything ...  Also Malware, I've seen customers lose 100% of catalog backups as the disks they were on were affected by the 'Encryption type' Malware attacks.

Sending the catalog to basic disk is the easiest way (you just recreate the disk with the same path) - ultimately, another copy going to tape is the ultimate protection, easily duplicated (should always have multiple copies) and easy to take offsite, protected from Malware ...   Always be very sure to save the DR file offsite as well.  The number of times we see catalog recovery needed with no DR file saved is unbelievable - no I can't tell you which tape it is on ...

I would not recommend putting the catalog on MSDP due to the extra complexity of having to get it all set up again.

[RiaanBadenhorst · Accepted solution]

Yes, just use basic disk. It will be simpler.

[Marianne · Accepted solution]

I agree with the 'Basic Disk' advice. This is the easiest ever catalog recovery.

PS:

I trust that you are planning your 'new build and design' on a Linux server as AIX NBU Master or Media server is no longer supported as from NBU 8.1.2.

[DPFreelance]

Yes indeed it will be Linux (CentOS).

EOL on AIX masters is the primary motivator for all this work. I looked at the upgrade/migration process and decided to stay a very long way away from it, ha!

Thanks for the input folks; I'll take another look to see where i missed Basic Disk!

[sdo]

NetBackup Master Server is not (officially) supported on CentOS - only NetBackup Media Server and NetBackup Client are (officially) supported on CentOS :

https://download.veritas.com/resources/content/live/OSVC/100046000/100046445/en_US/nbu_80_scl.html?_...

Master on CentOS should be ok for a PoC or maybe even a dev/test system... but personally I'm not sure that I myself would risk walking the line with someone else's data.

[Marianne]

Not CentOS! Not supported as NBU master server.... Please check the OS SCL carefully.

I have assisted a customer to migrate from Solaris to SuSE Linux - it is honestly as easy as described in this doc: 

Using catalog backup and recovery to transfer NetBackup catalogs between UNIX or Linux master servers as part of a hardware refresh : http://www.veritas.com/docs/000041077

We used an NFS share as Basic Disk for the Catalog backup and recovery.

[DPFreelance]

My *nix admins tell me that CentOS is basically the same thing as RHEL, but I can ask about that again for prodcution.

I'll look into this other method; I'm actually looking forward to a fresh environment though as our current build has been around for about 15 years (started on 5.0 I think).  I suspect a clean install will be a healthy thing to do.

[Systems_Team]

Hi DPSafelite,

I would raise a support case for verification regarding CentOS/RHEL.  I think you'll find that as it is not on the SCL as a supported config, that is what support will tell you - not supported.

I had a similar issue, although with clients not Master servers.  Mine was related to Postgres/MySQL on CentOS.  I thought similar - that CentOS and RHEL are pretty much the same, but support confirmed that those databases on CentOS were not supported but on RHEL they were (ie: the same as the SCL states).

As SDO said, running an unsupported config for a POC or dev/test might be fine but I definitely wouldn't risk it with a production Master.

Hope this helps,

Steve

[Marianne]

---

I'm actually looking forward to a fresh environment though as our current build has been around for about 15 years (started on 5.0 I think).  I suspect a clean install will be a healthy thing to do.

---

This decision would mean that you will need to keep the existing environment around until all images have expired.
If you have long retentions e.g. 5 years or even Infinity, this might be a costly decision. 
If you should decide down the line to merge the old master catalogs into the new environment, you will need to pay for consulting services to do this.

[DPFreelance]

Yup, 100% aware of that.

I'm on Capacity model, so no additional licensing costs are involed in keeping the old master around for a few years.  I'll be backing up the same data it used to so that should be covered.