Video Screencast Help

NDMP job failing when is reaches tape fragmentation size

Created: 01 Feb 2011 • Updated: 15 Feb 2013 | 8 comments
The Director's picture
This issue has been solved. See solution.

All our Hitachi NAS (BlueArc) NDMP jobs are failing when they reach the fragment size set in the storage unit. No matter what fragment size we use the job will write until that size and then get an "Error bptm (pid=19100) FREEZING media id XXXXXX, External event caused rewind during write, all data on media is lost" and the job will die with an 84 error.

Master Server - 7.0.1 SLES 10

Media Server - 7.0.1 RHEL 5.5

Hitachi NAS (HNAS/BlueArc) - Titan 2100 

Using NDMP with SSO. The drives are attached directly to the NAS head as well as the media server.

Quantum Scalar i6000 with LTO5 drives

Comments 8 CommentsJump to latest comment

Marianne's picture

I found the following in the Device config guide:

"SCSI reservation is not enabled by default. Please refer to BlueArc's documentation for details on enabling this setting in an SSO configuration."

Also see this doc for additional config info:

See the "BlueArc titan" chapter.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

The Backup Guy from Seattle's picture

The way to configure an HNAS or BlueArc servers to use SCSI Reserve and Release is to run the command "ndmp-option reserve_devices all" on the NAS server. That's an important setting when sharing tape drives with these appliances, but I don't think this problem is caused by a device sharing problem; I think the "external event caused rewind" is a red herring.

I've got another system with the same problem with NetBackup 7.0.1 and the bptm logs consistently show the block position on tape is just one block less than NetBackup expected. I think that something in the NDMP communication between NetBackup and these appliances is causing a misinterpretation of the mover window offset.

The mover window is defined in the NDMP spec (

A mover window is the means by which the DMA constrains the mover to use a certain, contiguous set of tape blocks.

Is your HNAS running firmware version 7.0? Have you ever enabled hardware encryption on your tape drives? Was this solution working for you before? I know sites that use BlueArc and HNAS with NetBackup and LTO successfully so I know it's not completely incompatible, but something is not working here.

The Backup Guy from Seattle's picture

There's a patch that will fix this for Windows media servers, but I'm not sure about Linux servers. Ask for the patch for Etrack 2196740. I've heard, but not confirmed, this problem is not present in NetBakcup 7.1.

Symontec's picture


   I confirm that the issue for windows is gone in 7.1.



If this post was helpful, please take a second to vote or mark as solution.

CRZ's picture

Assuming The Backup Guy from Seattle (I love that username) is correct, for Linux you will want to reference Etrack 2291889.

This issue IS resolved in 7.1 (again, assuming it's the same issue) and is referenced in the 7.1 EEB Guide by yet another two Etrack numbers - 2132186 and 2131806 - see page 19:

Symantec NetBackup 7.1 Emergency Engineering Binary Guide

EDIT: As the original post was made back on 2/1 and we never heard back from them, I hope that either they find it now....or that somebody else finds this useful in the future! :) | APPLBN | 761LBN

The Director's picture

I have contacted support and am waiting on the EEB. (as a side note, I had a previous case open and was told there was a fix only for solaris and there wouldn't be one made for Linux)

Thanks so much to The Backup Guy from Seattle, as he contacted me and helped me with this issue upon finding my original posting.

Marianne's picture

Please let us know if your problem has been resolved.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

The Backup Guy from Seattle's picture

I heard from "The Director" offline that Etrack 2291889 did fix the problem for him. Including "Symontec", that's three sites this has worked for. I'm sure the related Etracks "CRZ" mentioned above must be the right fix for this issue in 7.1.

That's a good win for this forum. I don't think any of the three sites would have found the fix yet without it. Nice work moderating Marianne and CRZ!