Yes, we see this error all the time. I always thought it was a block-size mismatch between NDMP and non-NDMP backups sharing the same volume pool and retention, i.e., non-NDMP backups use a block-size of 256kb, while NDMP (waiting on NAS reboots before I move to 256k) uses 63kb.
If its a bug fixed in MP6, I don't think there will be too much longer of a wait, as a I saw some MP6 files on the ftp site, although not the main releases. Any info from Symantec as to when that bug will be fixed? -- nick > > I upgraded to 6.0MP5 a few weeks ago to fix the notorious pempersist > problem where NetBackup refused to run any of my scheduled policies or > let me manually start backups. I had been running 6.0MP4 because MP5 had > a bug that caused all of my NDMP backups to fail and to get things > running I had to install MP5 and then install some super duper secret > binaries for bptm and bpdbm. This fixed the problem with jobs not > scheduling although I am still seeing the occasional type 41 error on my > hot catalog backups, which is a symptom of the pempersist problem. > > This weekend I started getting type 84 errors on some of my NDMP backups > with the error message: > > Error bptm(pid=13699) FREEZING media id XXXXXX, too many data blocks > written, check tape/driver block size configuration > > error. Searching for this on Google produced the following web page: > > http://seer.entsupport.symantec.com/docs/295172.htm > > ETrack: 117380 > Description: NDMP backup using TIR - positioning error - bptm does not > advance expected_block_pos[TWIN_INDEX] if bytes_this_buf == 0 > > Has anyone else had any experience with this? I'm becoming increasingly > frustrated with NetBackup 6.0. There are nice new features that I love, > such as hot catalog backups and the ability to queue vault jobs, but for > every feature I like there's a bug that I really hate, such as the NDMP > problems in 6.0MP5, the pempersist problem in every 6.0 release and now > this. It's especially annoying since I'm not using TIR in any of my NDMP > policies. Indeed as far as I can tell it's not even an option for an > NDMP policy type backup. > > Looking at the webpage listed above is depressing since the page was > apparently last updated on the 23rd of January, 2008, yet contains this > sentence > > "This issue is currently being considered by Symantec Corporation to be > addressed in a forthcoming Maintenance Pack or version of the product. > The fix for this issue is expected to be released in the fourth quarter > of 2007." > > I have this nightmare that I'm going to have to restore some crucial bit > of corporate data and I'm not going to be able to. Then Symantec will > post an eTrack notice saying "Oh yeah, we found this bug in the version > of NetBackup that you're running that causes it to expire all of your > backup images, run 'rm -rf' on all of your disk based storage units, > relabel all of the tapes in your library and then overwrite your catalog > with zeros. Don't worry though, we're working on a fix that should be > out at some date that's well in the past." > > Jamie Jamison > _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu