Don't want to beat this to death, but IMO, less-experienced NetBackup admins and the archives will benefit from finding that
a) this long-running, apparently complicated problem is really NetBackup config 101 and b) there is no behind-the-scenes, undocumented magic that should send a user off on a fit of bpexpdating. > On Tue, 26 Dec 2006, bob944 wrote: > > > > [...] > > > [summary: the normal misconfiguration: drive paths and > robot drive > > numbers were not matched correctly] > > > > > ** IMPORTANT NOTE: Something I figured out myself and > > > then VERITAS confirmed it. If you have INCORRECT > > > addressing and you do backups to tapes, when the tapes > > > are used again, they will try to go the drive that > > > originally wrote them-- > > > > I don't remember ever observing that, ACSLS or not; > > NetBackup uses any drive available in a STU of the right > > density and media server. Surely you're not confusing > > media-server ownership of assigned media, are you? > Again, the problem only happened when all drives were in use (in the > robot). I don't believe that's correct. The problem--your configuration mapped NetBackup drive indices via device names to incorrect acs/lsm/panel/drive settings--was always there. The _symptom_ you saw--hangs and waiting mounts--typically shows up when you throw enough work at it (your 45 jobs and _multiple media servers_) that MediaServerB can't use the drive it thinks it has because MediaServerA, through misconfiguration, has stuck a tape in it. This or a variation is what you kept seeing as "32 active jobs. However 1/2 or 3 (random) jobs will hang saying 'Mounting MediaID' - I can check ACSLS and run query drive *, the tape it is requesting sometimes is and is not in the drive that it is supposed to be in, confusing..." and the reason why experienced ACSLS users' advice has been to verify the end-to-end configuration and prove it one drive at a time. Classic misconfiguration; we've all done it. > > > EVEN after you fix the addressing > > > issue! They MUST be EXPIRED first with > > > bpexpdate -d 0 -m MEDIA_ID so they lose that information. > > > If at any point you have an addressing problem and write to > > > tapes, BE SURE that you EXPIRE ALL TAPES written to during > > > that testing phase before you do more testing-- after you > > > ensure the address/scsi/acsls mapping is correct of course. > > > > Can you cite documentation for this? > > > Unfortunately not; the Veritas engineer confirmed my finding verbally. That _is_ unfortunate. I believe you have misinterpreted the situation: there is no tie between a tape and a physical drive, only the normal pre-6.0 ownership of media by its media server as long as the media server has images on it. Please advise if you do come up with docs--perhaps a clarifying statement from your Veritas contact--so I and the rest of the list can learn from it. _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu