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.

 

2 Solutions

Accepted Solutions
Highlighted
Accepted Solution!

Not sure if this will help

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.

 

 

 

View solution in original post

Accepted Solution!

Logged a case with Symantec

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

View solution in original post

12 Replies

Hello Can you let me know if

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

Thanks Riaan, I don't think

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.

At least you got rows from

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?

The output looks like this, I

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

 

 

I'd say open a case with

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.

Highlighted
Accepted Solution!

Not sure if this will help

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.

 

 

 

View solution in original post

Thanks Jaime, that is a very

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. 

The "spiffy diffs" thing can

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.

Did you open a support case

Did you open a support case to check what's up with the column in that table?

Accepted Solution!

Logged a case with Symantec

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

View solution in original post

My experience has been that

My experience has been that Product Management does not look at IDEAS section on Connect.

Best to get hold of Product Management via your local SE to submit enhancement request.

So that field is for 2053

So that field is for 2053