Forum Discussion

DPFreelance's avatar
5 years ago

Architecting Catalog protection and recovery

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

  • 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.

10 Replies

  • 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.

     

  • 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.