Backup Exec is ejecting a tape when it shouldn't...

Hi,

BENT?

Backup Exec will eject a tape if it is either write protected or not appendable. This is by design, and this has been done over virtually all the versions. With a tape autoloader/library it would simply check the next slot...with a stand-alone drive, it will eject the tape if it is unusable.

So there is no design flaw...I know of other backup vendor products that do this.

Have you tried to add that tape into the specific media set that will run for that day?

Thanks!

BE does not move tapes from the scratch media set to any other media set, unless it has written to it as part of a job.

When a tape cannot be overwritten, it is always ejected and a media insert alert issued to request for an overwritable tape.  This is by design and is this way since forever.

BENT?

"Backup Exec for NT", the old product name before Microsoft changed the OS name, which triggered a product name change to BEWS, "Backup Exec for Windows Servers".  I think this happened back around BE 8 or 9.  Old habits die hard :)

...hehe! Thought as much but wanted to make sure it wasn't some other vendor's product.!

Hi guys,

Thanks for your reponses.

BENT, Sorry... I've been using Backup Exec since the days of Arcada (pre Seagate/Veritas and Symantec) and ironically, the acronym seems to fit better with 2012 (sorry, couldnt resist that one)!

I am aware of the way in which, BEWS and BENT before it, works with tape media that is overwrite or append protected. My issue is as follows:

1. BEWS detects the media as not being suitable for the current backup type of the job currently running. This can be because of operator error, allocating a tape to the wrong media pool. Or, in my specific case, this appears to have been the job engine, somehow, allocating the blank (scratch media pool) tape to a media set that is overwrite protected, before it started to write the data for the backup job, thereby locking iteslf out from using the blank tape).

1.2. As BEWS has detected the media issue it issues a media removal alert and ejects the tape. A little point aboput this alert is that it can be acknowledged or cancelled.

Hmm... If there is only one outcome then "Cancel" is pointless and this alert should only be acknowledgeable... Unless the cancel option gives us a chance to remediate the issue with the media and save the backup job (see below)!

3. My issue is that because it has ejected the tape, in an unattended backup scenario, the remote operator is not able to remediate the incorrect tape media set association, until somebody attends the site to push the tape back in. Thereby making proper unattended operations not possible.

4. This situation would be better handled as follows:

4.1. BEWS detects the media as not being suitable for the current backup type of the job currently running.

4.2. BEWS issues a media removal alert, but does not eject the tape yet.

4.3. The remote operator now has a chance to take a look at the media properties and ensure the media is either associated with the correct media set or ejected. If the tape is to be ejected the operator acknowlegdes the media removal request and the tape is ejected.

4.4. However, if the tape can simply be allocated to the correct media set, the operator can cancel the media removal request and the backup job can continue.

Hooray!

The key think here is that, all that needs to happen is the tape eject should not be made the default behaviour, as there is no benefit to this. Media set protection has done it's job and paused the job awaiting input from an operator. If the tape is not ejected the job can be recovered remotely. All that Symantec developers need to do is simply move the event of the tape being ejected, from a default state, regardless of what's going on, to something that only happens when the operator acknowledges the tape to be removed. Simple really...

PS: Just because something has always been or behaved the same, does not mean it is right or cannot be improved upon. If this was the case we would all still be running around in furs clubbing eachother on the head.

...that might be worth an idea. although ejecting a tape would be by design...have you checked the settings to see if it's a simple case of deselecting a setting to prevent the tape ejecting?

Thanks!

Hi Craig,

My issue is not the fact that BEWS media protection pauses the job and alerts the operator. That part of the design is great. The problem is that, regardless of what's going on, the tape is immediately ejected and the opportunity for rescuing the job has been lost.

The design flaw is only in the default behaviour of the tape being ejected. Simply tweak the design so that the tweak makes the job more recoverable and then make the tape eject an operator controlled event, from acknowledging the media removal event.

I know of other backup vendors that do this too...

The media was a brand new blank tape that had been labelled in BEWS that afternoon. The default behaviour, as you undoubtedly already know, is for newly labelled media to be allocated to the scratch pool. The scratch pool is exactly where this tape sat until the BEWS job engine decided to stuff it up.

If all I did was label the new tape in BEWS, the BE2012 interface makes allocating the tape to any pool other than the default scratch pool, impossible. To do this I would have had to select the "Online Tape" media group and then gone to the properties of the media before I could allocate it to another media pool. Something that I would have only done if I was delirious or having a psychotic episode. Neither of which was the case, at the time. :-)

Yep, gathered that much, hence suggesting you add it in as an Idea. The first thing you're going to be told is to make sure the tape inserted is available for a write...but, if there was a delay between ejecting the tape that you could set, it would make more sense...add that in and see what happens.

Thanks!

Hi Craig,

Yea... tried that in the extensive testing with L1 and L2 engineers.

The current behaviour of BEWS is to have a hissy fit and spit the tape (not the dummy). Whereas changing this from a default behaviour would, as far as I can see, only improve the recoverability of otherwise lost jobs.

Come to think of it, I can't actually think of a scenario where ejecting the tape, by default, is a good idea at all... Can you think of any?

Surely the only time the tape shoul dbe ejected as the immediate default behaviour would be if the tape is full or the job, has finished, and if the job definition specifies it. If the remote operator wants to eject a tape there are many ways this can be done. If somebody is on site and only has physical access to the tape drive, they can also eject the tape. Why make it the default action and only increase the chances of jobs failing? As long as your media protection is set correctly you should never need to have the tape ejected as a default action, unless the media fills up or the job has finished. The latter of which I do not have set for this job.

Note to all of you who are saying this is the way it has always been done. Stating this does not help us. I am not disputing how long this has been the behaviour. I am challenging what I think is, at best, a great improvement for the product and, at worst, a fix for a design flaw.

For sure...and I've actually experienced this before. I looked after sites in some real backwaters places in Africa. Using stand-alone tape drives, when a tape ejected, it took a site engineer hours to drive to the site to put a tape in, or they had to rely on someone to put the tape in. Most times this never happened, and therefore queue up 5% backup success rates for example. Hence I got the go-ahead to put in HP StorageWorks MSL2024 G3 libraries...

I'd definitely vote this up if it was an Idea...post back with the link when you have done so.