Forum Discussion

thesanman's avatar
thesanman
Level 6
13 years ago

Does incremental catalog recovery work?

Today I was planning to migrate my old Master Server to a nice new one.  I had pre-prepared the new server; same name, ip etc and pre-installed same version of NetBackup on it.

I then performed a cumulative hot catalog backup on the old Master Server and shut it down, moved the cables and restarted the new one.

Confirming all was ok and I could see the required tapes I then initiated a catalog recovery from tape using the latest recovery file (from the incremental).  All looked ok; it started, recovered 3 lots of information and then finished very quickly.  I soon realised it had not recovered the "full" files; just the incremental files.  I was missing a majority of my image catalog.

Symantec are looking at this but wondering if others have seen or heard of this?

NetBackup version 7.1.0.4, RHEL 6.

7.1.x and Earlier
Backup and Recovery
NetBackup
Recovering
  • mph999's avatar
    mph999
    13 years ago

    This is what I believe should happen ... with Incremental Catalogs Recovery.

    If an online catalog backup policy includes both full backups and incremental backups, the disaster recovery email may indicate either a full backup or an incremental backup for recovery. An incremental backup recovery completely recovers the entire catalog because it references information from the last full backup. You don't need to first recover the last full catalog backup, then follow with subsequent incremental backups.

    I'll try it on my server when I get a few mins.

     

    Martin

18 Replies

Sort By
  • mph999's avatar
    mph999
    Level 6
    13 years ago

    Yes, they should work.

    Apart from the staging process of the EMM DB, there is nothing special about a catalog backup.  The tapes can be browsed like any other tape if you wish (set policy type to nbu-catalog in BAR gui).

    The DR file should contain the details of the tapes used, and in fact the DR file is just a copy of the image header file, which is all that is required to run a restore.

    What is the case number ?

    Martin

  • thesanman's avatar
    thesanman
    Level 6
    13 years ago

    Case number is 418-439-612

    What I find interesting is that there's no reference to the Full tape number in the DR file; yes it references the full .f file (PREV_BACKUP_IMAGE Catalog-Backup_1339967083_FULL.f) but no indication on what tape that is.

    There's no errors during the restore procedure; it simply doesn't go and restore the "files" from the full image.

    It performs 3 restore jobs; I woudl expect 4 if the full was referenced.

  • mph999's avatar
    mph999
    Level 6
    13 years ago

    This is what I believe should happen ... with Incremental Catalogs Recovery.

    If an online catalog backup policy includes both full backups and incremental backups, the disaster recovery email may indicate either a full backup or an incremental backup for recovery. An incremental backup recovery completely recovers the entire catalog because it references information from the last full backup. You don't need to first recover the last full catalog backup, then follow with subsequent incremental backups.

    I'll try it on my server when I get a few mins.

     

    Martin

  • revarooo's avatar
    revarooo
    Level 6
    13 years ago

    You are correct in this assumption, it does reference back to the full.

  • mph999's avatar
    mph999
    Level 6
    13 years ago

    Here is the business bit of the header file.

    This was one Full backup followed by one diff inc.  We see in the DR_MEDIA lines that the media id's are mentioned. (R0TP01 and R0TP02 )

     

     
    # FRAG: c# f# K rem mt den fn id/path host bs off md dwo f_flags desc exp mpx rl chkpt rsm_nbr seq_no media_subtype keep_date copy_date fragment_state data_format slp_index_num
    FRAGMENT 1 -1 120 0 2 12 3 R0TP02 womble 65536 4530 1340102160 0 0 *NULL* 0 0 0 0 0 0 1 0 0 1 0 0
    FRAGMENT 1 1 448 0 2 12 2 R0TP02 womble 65536 4521 1340102160 0 0 *NULL* 1341311890 0 65537 0 0 0 1 0 1340102312 1 1 0
    #DR_MEDIA_REC: ver rtype mtype host c# p# classes classes kbytes nimg vimg hsize off subtype client_type sched_type run_time id/path frag_id media_desc bcode den
    DR_MEDIA_REC 2 0 2 womble 1 1 0 287904 1 1 1024 4503 1 7 0 1340099915 R0TP01 *NULL* -------- 12
    DR_MEDIA_REC 2 0 2 womble 1 1 0 287904 1 1 1024 4503 1 35 0 1340100042 R0TP01 *NULL* -------- 12
    DR_MEDIA_REC 2 0 2 womble 1 1 0 288640 1 1 1024 4514 1 7 1 1340100317 R0TP00 *NULL* -------- 12
    DR_MEDIA_REC 2 0 2 womble 1 1 0 577056 2 2 1024 9023 1 7 1 1340100633 R0TP00 *NULL* -------- 12
    DR_MEDIA_REC 2 0 2 womble 1 1 0 289056 1 1 1024 4521 1 7 1 1340102160 R0TP02 *NULL* -------- 12
    DR_MEDIA_REC 2 0 2 womble 1 1 0 289624 3 3 1024 4534 1 35 1 1340102290 R0TP02 *NULL* -------- 12
     
    Do you see similar ?
  • thesanman's avatar
    thesanman
    Level 6
    13 years ago

    Yes, I see DR_MEDIA_REC entries for the various catalog backups that I have.  In particular, for the process today, entries for the full and cumulative backups.

    I'll have to work though a similar restore process in my QA environment tomorrow.

  • thesanman's avatar
    thesanman
    Level 6
    13 years ago

    Went through a similar process using my QA environment and yes, I can see during the 'file' component of the restore process it applies the cuml, then the full backup files from the catalog backups.  This I did not see for my new Master Server yesterday.

    All very strange

  • mph999's avatar
    mph999
    Level 6
    13 years ago

    Just tested this, restored fine using both separate tapes on my server.

    I suspect that there was something wrong with the DR file though exactly what I can't image at the moment.

    Can you try and recover the same catalog on your test server, using the same DR file.

    We know this separate environment of yours can restore, as you have just done it, so this would narrow down the problem quite nicely.

    Martin

  • thesanman's avatar
    thesanman
    Level 6
    13 years ago

    Was thinking exactly the same; problem is my primary recovery tapes are at another site.  The 2nd copies are local which could be easily retrieved whereas the primaries cannot.  All are on SAN attached libraries.

    Am trying to think of a way to retrieve the tapes from my DR site.

    Another way to do the switch might be to simply synchronise a copy of local /usr/openv to the new Master Server as (say) /usr/openv.new  Then simply shutdown current Master Server; rename new Master server /usr/openv away and rename the /usr/openv.new to usr/openv and restart NetBackup.  Might have to rebuild the local tape config but other than that the rest should be the same.

    This was the way we renamed NBU Master before with help from symantec to merge the EMM databases which I don't need to do this time as the name is the same.

    Doesn't fix this restore issue I have BUT it get's me on the new Master Server.

    Thoughts?

     

  • mph999's avatar
    mph999
    Level 6
    13 years ago

    If you happy just to get things working then I guess you 'might' not be too concerned about this cause.

    Persoanlly, I would want to check this new server can do a cat recov. off and inct backup, as you may have to do this for real in the future.

    If, the issue really is with the DR file off the old system, then providing the catalog backups on the new server work, it doesn't matter, you're getting rid of the system after all - however, your thoughts may differ.

    You can recover from the 2nd copy of the tapes ...

    We can't merge the EMM DBs / or the image DB for that matter  ...

    Persoanlly I get nervous when people talk about syncing /usr/openv/etc ...

    Why you ask, after all, you have done this in the past etc ...  other people do this etc ...

    As you've worked out, I work for Sym - I do this all day/ every day and I have lost count of situations where people have called up one week after a 'migration'  bacuase something is broken ...

    So then I ask, when you ran the Catalog recovery ...

    Oh no, we copied across ....

    Really I say ... as tears begin to fill my eyes, and I consider a new career ...

    You get the idea  - sure, coping across /usr/openv is probably ok ... IF you install the correct (equal) version of NBU first, to set up things like /etc/services etc ..

    Persoanlly, and you did ask, if possible my preference would be to run a proper cat recov. , as documented in the manuals.  That way, if it goes wrong, you can turn round to Symantec and say ..." I did as described in the manuals, using a supported method".

    I apologise in advance for my views, I see from your very reasonable comments that you are not looking to take short cuts, and are slightly backed into a corner.  But speaking, 'on average' from the systems I see that are often very onwell, it is no surprise when we find a short cut has been taken at some point.

    Martin