Netbackup 7.5.0.4 Exchange 2007 GRT backup failed status 20

[hani_hammad]

after upgrade to 7.5.0.4 from 0.3 Exch. GRT backup (app cluster) failed 

storage unit is on MSDP 

 11:55:01 PM - Info nbjm(pid=7448) starting backup job (jobid=30633) for client ########, policy Exch_07_GRT, schedule Full  

 11:55:01 PM - Info nbjm(pid=7448) requesting STANDARD_RESOURCE resources from RB for backup job (jobid=30633, request id:{7FB589A4-201F-4039-A383-442169CCD880})  

 11:55:01 PM - requesting resource Dedupe_SU

 11:55:01 PM - requesting resource ########.NBU_CLIENT.MAXJOBS.########

 11:55:01 PM - requesting resource ########.NBU_POLICY.MAXJOBS.Exch_07_GRT

 11:55:01 PM - granted resource ########.NBU_CLIENT.MAXJOBS.########

 11:55:01 PM - granted resource ########.NBU_POLICY.MAXJOBS.Exch_07_GRT

 11:55:01 PM - granted resource MediaID=@aaaa2;DiskVolume=PureDiskVolume;DiskPool=Dedupe;Path=PureDiskVolume;StorageServer=########;MediaServer=########

 11:55:01 PM - granted resource Dedupe_SU

 11:55:07 PM - estimated 0 Kbytes needed

 11:55:07 PM - Info nbjm(pid=7448) started backup (backupid=########_1349992507) job for client ########, policy Exch_07_GRT, schedule Full on storage unit Dedupe_SU

 11:55:09 PM - started process bpbrm (7228)

 11:55:18 PM - Error bpbrm(pid=7228) NetBackup storage unit NOT compatible for Granular enabled backup, Please refer NetBackup software compatibility list for supported configurations

 11:55:20 PM - end writing

invalid command parameter(20)

[CRZ]

This sounds like a defect.  I would recommend opening a support case and having a bpbrm log ready to send to your TSE.

What's the version of Exchange?

[rawilde · Accepted solution]

Exchange GRT poerformance to Puredisk (or OST media device) has much better performance when using VSS (snapshot backup) versus the older legacy or streaming style backup.  To save performance complains or support cases, we added a check in 7.5.0.4 to error if trying to backup using this style.  Please change yoru backup type to snapshot and try again.  If this is not the issue, let me know.

Thanks.

[CRZ]

I'm speechless.  Are you saying that we deliberately coded something that caused backups which succeeded in 7.5.0.3 to fail in 7.5.0.4?  Tell me I'm reading that incorrectly.  (Then, please email me.)

[hani_hammad]

Thanks rawilde and Chris, it worked after enabling snapshot however i lost the ability to perform a db level grt backup !,

btw, i reviewed the release notes of 0.4 and found something that may need more explanation 

"

Etrack Incident: 2820643

■ Description:

Non-Volume Shadow Copy Service Exchange granular backup jobs fail. The

error occurs if the backups are targeted to a media server deduplication pool

storage unit on NetBackup clients that are higher than version 7.5.0.4.

"

[d_bergen]

I am seeing the same issue since upgrading, if it in fact turns out that a perfectly functional configuration has been made to throw an error for no reason in the new version I will be extremely unimpressed.

When I turn on VSS for Exchange backups I no longer see the error however by backup speeds are unusable, this is why I didn't use VSS in the first place, now I have no option. Nice upgrade.

[rawilde]

We were seeing too many escalations regarding GRT performance without using VSS backup sets. The decision was made to only support VSS backup using GRT to a dedup storage.

[rawilde]

d_bergen

Please let me know more about the issue you are having with VSS versus the non VSS backups.  You should not be seeing such big speed/performance issues by using VSS.  Maybe we can take a look at the issues.

[rawilde]

Are you trying to do a DB level backup of Exchange 2007 and not storage group?  Can I ask why?

I will see if we can clear up the description in future release notes.

[rawilde]

Also wanted to make a note that VSS backups are the "preferred" backup from Microsoft for Exchange databases.  For Exchange 2007, a lot of vendors don't even support streaming based backups anymore.  Microsoft removed the capability all together for Exchange 2010, so VSS is the only option.

[hani_hammad]

nothing important, we already have an SG:DB 1:1 rate , however I agree that there is no notable performance advantage, or in other words it was fine before the VSS