Forum Discussion

Chris_W's avatar
Chris_W
Level 4
9 years ago

Backup and BMR status from client side

I need to to find a way to report on BMR backup status per client. 

Is there a command that can be run from the client side (Windows or Linux) that will show BMR status alongside the backup status (either success or failure)? I can't even find a way to do this in OCA for that matter.

Something like a BMR column added to bpclimagelist would be amazing.

 # bpclimagelist -client client 1
Backed Up         Expires       Files      KB     C Sched Type      Policy
----------------  ---------- -------- ----------- - --------------- ------------
09/10/2015 20:22  09/25/2015    39596    15118496 N Incr Backup     Linux1
09/09/2015 20:25  09/24/2015    39633    14077344 N Incr Backup     Linux1
09/08/2015 20:07  09/23/2015    39544    14998208 N Incr Backup     Linux1
09/07/2015 20:22  09/22/2015  1745972   183614688 N Full Backup     Linux1

The messiest way I can find is to script bpdbjobs -all_columns into a file and grep for BMRERR and then by elimination you can find your daily BMR successes - I'm not proud of this.

 

7.6
Backup and Recovery
Linux
NetBackup
Reporting
  • Jaime_Vazquez's avatar
    Jaime_Vazquez
    9 years ago

    Not sure if this will help you directly but this is some thing that might be useful.

     

    Every time a BMR enabled backup completes successfully, the BMR database is updated with a new copy of the "current" configuration.  That configuration entry has information about the backup that created it.

    So, on the Master Server, you can run this shell script:

    #----

    for i in `bmrs -o list -res Config | grep "current" | awk ' { print $9 } ' `
    do
    echo "---------------------"
    bmrs -o querytree -res database -table Config -id $i | grep -e "ClientName" -e "CreateTime" -e " Policy = " -e "BscheduleType"
    echo "    "
    done

    # ----

    The "for in" command will parse out the ConfigID of the configurations in the clients in the BMRDB.  Each time a configuration is added it gets a new number, and the value keeps incrementing. The longer the process goes without a reset of the BMRDB files, the larger that number can get. That in turn causes the BMRDB files to grow.

     

    The output will be four lines of output per client which will look like (sample dummy data):

    ---------------------
        ClientName = BMR_client
        CreateTime = 1424313933
        Policy = Windows_Clients
        BScheduleType = Daily_Inc

    The CreateTime is a ctime value. 
    It gives when the configuration was created on the client and will match up with the backup image ctime.

    BMR only remembers the latest version of the client configurations, hence the name "current".

    This runs on the Master.  You can run it daily after the backup window closes and save to a file. You can do some spiffy 'diffs' to see what client info changed and what did not.  If the client CreateTime changed, it worked. If not, it did not.

     

    Again, I hope this helps.

     

     

     

  • Chris_W's avatar
    Chris_W
    9 years ago

    Logged a case with Symantec but the reponse was what I was fearing. 

    At present there is no way of doing this, the command below seems to be the only way.

    bmrs -o list -res config -client

    The egineer's comment is below regarding OCA:

    Unfortunately, OpsCenter cannot directly report on a BMR enabled backup.

    So... an enchancement has been logged so if you support my cause, please vote :-)

    https://www-secure.symantec.com/connect/ideas/backup-and-bmr-status-client

12 Replies

Sort By
  • RiaanBadenhorst's avatar
    RiaanBadenhorst
    Level 6
    9 years ago

    Hello

     

    Can you let me know if you get any output if you run this query. I only have a test vm on which I ran 1 BMR job but I don't have anything in this table. It should contain the status of BMR jobs.

     

    select * from nb_BMRJobsStatusArchive

     

    If that gives an actual output, you could try this.

     

    select
    UTCBigIntToNomTime(domain_image.writeEndTime) as "Backup Time",
    UTCBigIntToNomTime(domain_image.expirationTime) as "Expiration Time",
    domain_image.filecount as "Files",
    domain_image.sizeOfImageInKBytes as "Kbytes",
    lookup_scheduletype.name as "Schedule Type",
    domain_image.policyname as "Policy Name",
    nb_BMRJobsStatusArchive.status as "BMR Status"
    from domain_image, lookup_scheduletype, nb_BMRJobsStatusArchive
    where
    domain_image.scheduleType=lookup_scheduletype.id
    and
    nb_BMRJobsStatusArchive.jobid=domain_image.jobid

  • Chris_W's avatar
    Chris_W
    Level 4
    9 years ago

    Thanks Riaan, I don't think it's working for me either. For each of the 150 rows I get for your first query, the "status" column contains "-999", not sure if that means anything to you :-)

    The second query you provided, returns no data.

  • RiaanBadenhorst's avatar
    RiaanBadenhorst
    Level 6
    9 years ago

    At least you got rows from the first qyery, i got nothing. Sorry.

     

    That table is the only place its supposed be kept. Can post some f the output?

  • Chris_W's avatar
    Chris_W
    Level 4
    9 years ago

    The output looks like this, I get 150 lines returned. I removed our customer's client names, hence client1...

    masterServerId clientName jobId status
    62 client1 14539501 -999
    62 client2 14539500 -999
    62 client3 14539503 -999
    62 client4 14539502 -999
    62 client5 14539497 -999
    62 client6 14539496 -999
    62 client7 14539499 -999
    62 client8 14539498 -999
    62 client9 14535194 -999
    62 client10 14535195 -999

     

     

  • RiaanBadenhorst's avatar
    RiaanBadenhorst
    Level 6
    9 years ago

    I'd say open a case with support and ask them if that is normal (-999). That field should tell us whether the BMR job worked or not, and once we know what is Yes, and what is No we can join it with the other query.

  • Jaime_Vazquez's avatar
    Jaime_Vazquez
    Level 6
    9 years ago

    Not sure if this will help you directly but this is some thing that might be useful.

     

    Every time a BMR enabled backup completes successfully, the BMR database is updated with a new copy of the "current" configuration.  That configuration entry has information about the backup that created it.

    So, on the Master Server, you can run this shell script:

    #----

    for i in `bmrs -o list -res Config | grep "current" | awk ' { print $9 } ' `
    do
    echo "---------------------"
    bmrs -o querytree -res database -table Config -id $i | grep -e "ClientName" -e "CreateTime" -e " Policy = " -e "BscheduleType"
    echo "    "
    done

    # ----

    The "for in" command will parse out the ConfigID of the configurations in the clients in the BMRDB.  Each time a configuration is added it gets a new number, and the value keeps incrementing. The longer the process goes without a reset of the BMRDB files, the larger that number can get. That in turn causes the BMRDB files to grow.

     

    The output will be four lines of output per client which will look like (sample dummy data):

    ---------------------
        ClientName = BMR_client
        CreateTime = 1424313933
        Policy = Windows_Clients
        BScheduleType = Daily_Inc

    The CreateTime is a ctime value. 
    It gives when the configuration was created on the client and will match up with the backup image ctime.

    BMR only remembers the latest version of the client configurations, hence the name "current".

    This runs on the Master.  You can run it daily after the backup window closes and save to a file. You can do some spiffy 'diffs' to see what client info changed and what did not.  If the client CreateTime changed, it worked. If not, it did not.

     

    Again, I hope this helps.

     

     

     

  • Chris_W's avatar
    Chris_W
    Level 4
    9 years ago

    Thanks Jaime, that is a very interesting way to get a status, I'll attempt your spiffy diffs and see how it goes. 

    Riaan, I'll also log a call with support to see what they say. 

  • Jaime_Vazquez's avatar
    Jaime_Vazquez
    Level 6
    9 years ago

    The "spiffy diffs" thing can be interesting.  You can easily use 'diff' to capture/show what changed. So that would show clients where the imports worked. What did not make that list would be clients that failed to import.

    Off the top of my head, I think the way to go is change the output from four lines per client to  single line per client, sorted by client name. The 'diff' operation would work much cleaner then.

    Lots of luck with that and please let us know how it all worked out.

    One more thing to pass along about the BMR configuration part of the deal.  The client configuration creation and import into the BMRDB occurs as the first step of the NBU backup job. It will complete and set a status code based on its own actions ahead of any NBU backup stream job. As such, the client configuration information displayed will reflect just the BMR part of the backup. That can complete normally and a new "current" configuration inserted into the BMRDB.  BMR has no idea or no concern about the actions and status information of the actual backup itself. That is NBU's responsibility. If the NBU backup job fails for some reason, the configuration CreateTime will not match up with a backup image ctime, which will not exist.

    The backup job itself will get the status code of the BMR portion or the NBU portion, whichever is the highest.

  • Chris_W's avatar
    Chris_W
    Level 4
    9 years ago

    Logged a case with Symantec but the reponse was what I was fearing. 

    At present there is no way of doing this, the command below seems to be the only way.

    bmrs -o list -res config -client

    The egineer's comment is below regarding OCA:

    Unfortunately, OpsCenter cannot directly report on a BMR enabled backup.

    So... an enchancement has been logged so if you support my cause, please vote :-)

    https://www-secure.symantec.com/connect/ideas/backup-and-bmr-status-client