cancel
Showing results for 
Search instead for 
Did you mean: 

Information Store missing from backup

LT2013
Level 4

Wondering if anyone can explain this scenario...

We are running NB 7.5, on RH Linux media servers, backing up Exchange 2007, using the NB agent.

We needed to recover a mailbox in Exchange, so in going through the restore GUI in NB, we saw there is no catalog entry for this particular IS. It is in a policy with 2 other Information Stores, which I can recover for that date.

I restored the policy include file for the timeframe in question, as well as a dump of bpdbjobs, and it looks like the policy did have the IS in the include list. And from bpdbjobs, the backup ran fine (status=0). While the job details are hard to view, I do see the missing IS listed in the parent job. But in the child backup job, I do not see any references to that IS.

So it looks like from a backup perspective there was no issue, but why would that IS not be backed up? If it was not available, should I not have gotten some type of error on the backup job?

Thanks

 

1 ACCEPTED SOLUTION

Accepted Solutions

sdo
Moderator
Moderator
Partner    VIP    Certified

It sounds to me as if you do have an all_columns file, because none of the text would be there for a most_columns file.  The all_columns file should be complete - as I've not known this output to ever be short or truncated or lost/incomplete in anyway - and I can say that with some confidence because I've had scripts running for years (since v5.1 all the way up) which do do a proper consistency check of every field and the complete structure of every bpdbjobs all_columns type record - so I'd know if I was ever missing any meta-data.

So, I can't help but think that maybe, and I know it's onerous, but if you were to search the text file to create a filtered file containing any possibly relevant record - and then spend a bit of time breaking down the long line records into new lines - then you might see what went wrong somewhere in the text - because, like you say, it is very difficult to visually inspect these super long text records - without breaking them down to a state as they normally appear in the activity monitor.

I think the fact that you kept these bpdbjobs output files is good.     +1 for good working/admin practices :)

Good luck.

View solution in original post

6 REPLIES 6

RonCaplinger
Level 6

Have you verified the retention period used during the backup would keep the data around until at least today?

Did you check the Problems report in the NBU Java GUI (NetBackup Management --> Reports --> Problems)?

Do you have the OpsCenter Audit Trail enabled so you can see who may have made a change during that timeframe?

LT2013
Level 4

The retention is 7 years. The restore of the other IS in the include list are recoverable so it can't be a retention issue.

 

Unfortunately, I do not have the logs from 2013, nor do I have the licensed OpsCenter that provides more than 30 days worth of data.

I do have a snapshot of bpdbjobs which does confirm the IS was in the include list of the backup. Just trying to ascertain whether there was something on the Exchange side which may have caused the IS not to backup, yet the NB job ran fine.

sdo
Moderator
Moderator
Partner    VIP    Certified

Do you have the detailed '-all_columns' report from bpdbjobs?

Just because an entry is in the selection list doesn't mean that the 'specification' was correct.  Maybe the selection entry was mis-spelt, or mis-constructed?  Maybe try searching the bpdbjobs output for 'bpresolver' text - as it is bpresolver which identifies which IS are actually available.

sdo
Moderator
Moderator
Partner    VIP    Certified

Granted, you'd expect the job to error even if one of the selections on an MS Exchange policy does not exist.

But, I've just run a test plain Windows file system type backup of:

T:\Test01

T:\Test02

T:\Test03

...where only the Test01 and Test03 folders actually exist - and I got a status 0 for the backup - no errors - but the activity monitor detail (i.e. the same detail as in 'bpdbjobs -all_columns') does say:

TRV - object not found for file system backup: T:\Test02

...i.e. a trivial (TRV) level message.  Got any of these in your bpdbjobs output?

 

LT2013
Level 4

I do...hard to view the text file since all the info is on a single line. But I grepped for the policy and got the 2 jobids associated with the backup (parent and child). The selection was not mispelled since it hasn't changes in a long time. Excerpt from the parent jobid (SG13 is the once thats missing from the catalog):

NEW_STREAM,Microsoft Information Store:\\SG13,Microsoft Information Store:\\SG29,Microsoft Information Store:\\SG30

There was no instance of bpresolver (this is not a DAG backup). On the child jobid there are many references to SG29, like:

EXCHGDATA 34 Microsoft Information Store:\\SG29\\

Interestingly, there are no occurences of SG13, nor SG30 in the child. But SG30 is available for recovery. In reviewing other jobs for this policy, I do see occurences of SG13 in the child PID, but not SG30. I presume that may be because not all of the job detail description is retained on bpdbjobs.

 

 

 

sdo
Moderator
Moderator
Partner    VIP    Certified

It sounds to me as if you do have an all_columns file, because none of the text would be there for a most_columns file.  The all_columns file should be complete - as I've not known this output to ever be short or truncated or lost/incomplete in anyway - and I can say that with some confidence because I've had scripts running for years (since v5.1 all the way up) which do do a proper consistency check of every field and the complete structure of every bpdbjobs all_columns type record - so I'd know if I was ever missing any meta-data.

So, I can't help but think that maybe, and I know it's onerous, but if you were to search the text file to create a filtered file containing any possibly relevant record - and then spend a bit of time breaking down the long line records into new lines - then you might see what went wrong somewhere in the text - because, like you say, it is very difficult to visually inspect these super long text records - without breaking them down to a state as they normally appear in the activity monitor.

I think the fact that you kept these bpdbjobs output files is good.     +1 for good working/admin practices :)

Good luck.