cancel
Showing results for 
Search instead for 
Did you mean: 

More info: this bug also

More info: this bug also slows down restores... :-( I have started a granular restore, and it took 10 minutes for 25MB. I 'trussed' bpdm during the restore and also saw the 1 second sleeps. With the LD_PRELOAD32 hack, the restore took 2 minutes. Please, Symantec, when the final release of GRT will be available :)

Have you opened a case with Support?

This definitely looks like the sort of thing that should get escalated to the developers for a real answer (or fix)!

I have a hunch there's a "really good reason" that delay was coded in, but obviously I have no clue what it is.  I'd hate for your modifications to come back and bite you, though, so I *strongly* recommend opening a case to get an officially supported EEB replacement... if that's what it ends up being.

Yes... still waiting :-(

Yes... still waiting :(

Yes setting

Yes setting SoftMountPingtimeout to 60 may avoid an error 1 during the indexing phase. But it does not speed up the indexing.

True, and for the record it

True, and for the record it did not help our issue.

Good news is that the last test we performed Symantec had me add a touch file (only works with the  provided EEB) and the GRT backup only took a few minutes longer than the non-grt backups.  It still ended in a status 1 but it seems to be a step in the right direction.  At least my test jobs wont last 24 hours...

Is it

Is it /usr/openv/netbackup/db/config/nbfsd_enableDirect ?

Thats the one.  Support get

Thats the one.  Support get you that EEB? If so hows it work for you?

It seems to work :-) The

It seems to work :) The indexing is very fast because the nfs server directly opens the image on disk instead of using bpdm with its 1 second delays everywhere... No error 1 so far.

Warning !!! With this EEB

Warning !!! With this EEB duplications of Exchange backups are broken ! Avoid duplications or your NBU server may be stuck running "image cleanups" during hours !

Still waiting...The latest

Still waiting... The latest EEB created problems with Duplications...

Lu - could you post the EEB

Lu - could you post the EEB file name or case number to reference to at least fixed part one of the problem.  I'll worry about the duplications later - I still rather have my GRT and I can't seam to get a hold of the EEB for this.

EEB 1712608 + touch

EEB 1712608 + touch /usr/openv/netbackup/db/config/nbfsd_enableDirect => faster indexing but BIG problems with duplications (catalog corruption).

Looks we are using the same

Looks we are using the same EEB Lu. 
Reckless, if you want the EEB for 6.5.5 try and ask for 1928803.1 (that should be a recompiled version of 1712608.9)

Matt

Reckless, I forgot to mention

Reckless,

I forgot to mention that this EEB does not solve my particular issue with GRT backups ending in a status 1 when the mailstore is larger than 60-90GB (could never narrow down at what size the problem shows up).
Though it has cut our testing time down to just a few minutes longer than a normal non-grt backup.  Previously the job would run for days!

Matt

ET1712608.8 AND nbfsd_enableDirect

This fix has been in effect and it does resolve the issue regarding the backup performance,

Engineering/Tech Support are fully aware of the side effect with SLP - however, the details from original site that reported are so generic that it would foolish to suggest anything such as corruption at this stage, I will update this thread in a few days time to connect the link with SLP as there will be some development on this SLP v ET1712608.8

RogC

We have tried the EEB

We have tried the EEB 1712608.10 and the backup is fast but the duplication to tape is still awful (catalog corruption).

My tests with the latest EEB

My tests with the latest EEB have been successfull for single large mail stores.  But when try to backup more than one at a time (Microsoft Information Store:\*) it usually ends with a status 1 again.  I even changed the policy to only allow 2 jobs to run at the same time, but i still ended up with random status 1s and backup jobs running for 20+ hours.

So, semi solved here. 

> But when try to backup more

> But when try to backup more than one at a time (Microsoft Information Store:\*) it usually ends with a status 1 again. Thanks ! Good to know ! Maybe the media server is able to provide via NFS only one image to index at the same time ?

ET1712608.10 + GRANULAR_DUP_RECURSION = 0 *if dup'ing GRT images

Apologies for the delay in updating in all but it has been confirmed
that ET1712608.10 can be safely applied to environments without causing any
side effects.

The only caveat/precuation is that when running GRT Image Duplications you should
implement "GRANULAR_DUP_RECURSION = 0" in the bp.conf. This disables the catloging of
GRT images.

Full coverage of this flag is documented in this tech note.
http://support.veritas.com/docs/317302

In summary ET1712608.10 + GRANULAR_DUP_RECURSION (if dup'ing GRT images) = effective quicker backups.

It has also been proven that the same ET1712608.10 can resolve SharePoint GRT performance
related issues.

We're currently documenting all of this and will provide an official resoultion to this problem.

Rog C

Yes, I can confirm that with

Yes, I can confirm that with ET1712608.10 + GRANULAR_DUP_RECURSION=0, we started to have GRT backups working and duplication to tape was ok. Of course the duplicated image to tape, needs to be copied back to disk to have GRT browsing. Is there a fix for "errors 1" when the Exchange stores are backed-up in parallel (multiplexing enabled) ? Is it related to the fact that only one NFS mount is allowed on the Exchange client at one time ?