cancel
Showing results for 
Search instead for 
Did you mean: 

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

deejerydoo
Level 5
Partner

Hi guys,

 

Backup Exec 2012 (patched to date).

Windows 2003 SBS SP2

Single HP Ultrium 3 internal SAS tape drive.

 

Last Friday I inserted a brand new tape into the backup rotation. For this I simply put the new tape in the drive and ran a label job on it. This puts the tape, as you probably already know, into the scratch media pool. Saturday morning I discovered I had received repeated emails, from BENT, asking me to remove the media. I connected to the server and noticed that the Friday night backup job was still running, with 0KB written to the tape, and a remove media alert was visible in BENT. When I checked the properties of the brand new tape in the drive I noticed it had been allocated to one of my backup media pools that are set to overwrite protect the backup data for a set period of time. However, it appears BENT had done this to the tape before it had run the backup; thereby preventing itself from overwriting the blank tape (this mishandling of the media pool allocation is a separate issue I am still dealing with on a Symantec support case)!? So, to get the backup job running again I thought, all I have to do is cancel the backup job, reallocate the tape back to the scratch pool and rerun the job. So, I ignored the media remove request and cancelled the job. Only to find that BENT had ejected the tape anyway!?

Surely, this is a fault in the logic of BENT. The tape should not be ejected until after the operator acknowledges the media removal alert. The backup job hasn't been set up to eject the tape on completion and I didn't acknowledge the media removal request, so BENT has a bug (faulty logic) whereby the tape is still ejected, in this scenario. In this instance, I had to ask my client to go into their office, on a weekend, so they can push the tape back into the drive. Whereby I moved the tape back into the scratch pool and kicked the job off again, which completed without further errors.

What should happen, when a tape that is overwrite protected and a backup job is trying to overwrite the tape is as follows:

1. A media removal alert is generated.

2. The operator is given the opportunity to check the backup job's settings and the state of the media in the drive and take actions to remediate the problem. In my case, this was to cancel the backup job, reallocate the blank tape to the scratch pool and then kick the backup job off again. However, I was precluded from doing this because BENT had already shosen to eject the tape.

3. If my chosen course of action was to swap the media then, and only then, Backup Exec should eject the tape if I acknowledge the media removal alert.

As far as I can see this is a fundamental flaw in the logic of the product that precludes it from being suitable for use at sites that have a single tape backup unit where backups need to be managed unattended.

Any help or suggestions would be appreciated.

Cheers,

 

David

 

 

38 REPLIES 38

Larry_Fine
Moderator
Moderator
   VIP   

I think there are a couple scenarios where a remote admin will be frustrated by an ejected tape.  so far, I don't see a downside to reducing BE's sometimes overly agressive ejhect behavior, so I upvoted the idea so that it gets investigated.

Moe_Howard
Level 4

There may be a workaround to pull the tape back in to the drive without user intervention.

I believe Windows allows a SCSI command to be sent to a SCSI Port driver:
http://msdn.microsoft.com/en-us/library/ff565387%28VS.85%29.aspx

Sending the LOAD UNLOAD SCSI command (1B) to the tape drive would pul the tape back in to the drive after the media has been unloaded. The HP LTO drives support this feature.

 

 

 

deejerydoo
Level 5
Partner

Hi Moe, Thanks for your input.

If that is the case then you may have just given the Symantec developers and alternate way of fixing the problem. All they would need to do is to get the "Media Removal Alert" to behave differently by making it so, that:

BEWS issues that SCSI command if the operator hits the "Cancel" button in the media removal alert.

However, my solution would also work for drives that don't support pulling the media back in. This is because they wouldn't need to pull the tape back in, in the first place, if BEWS didn't spit the tape out when the media removal alert was created. i.e. Only spit the tape out if the remote operator acknowledges the media removal alert.

PS: If you have encountered annoying tape ejection issues in BEWS or just think my idea is a good one, please vote it up!

https://www-secure.symantec.com/connect/ideas/stop-default-tape-eject-behaviour-be-2012

shreekumar
Level 3

Hi friends,

I am having backup tool as Backup Exec 2010 R3 with windows as OS and a stand alone tape drive , every morning the local I.T person rotates the media and insert an over writable media, but in my end the backup job is in Queued state and to reflect the media in the drive i cancel the job and run the inventory , by the time the inventory is complete i am able to see the over writable media , but as soon as i run the backup job again the job gets into queue state and now i am unable to see the media in the drive its get ejected automatically.

what is the issue ? would be helpfull if you get a solution for this .  

RickkeeC
Level 4

I manage a hundred remote serves, and luckily only one is still using BE.  I have ya'll beat as I have been using the product since the Maynard / Connor days.  They should go back to the old Connor interface and start from scratch with this software as it has been added on and patched for over 20 years now.

Some drives supported an 'inject' command which I believe was in the Connor days and quickly removed from Backup Exec as other features were removed and made more complicated.  By Design.  Yes.  Poor Design.

Even if they put back the 'inject' command, RD1000 drives don't support it, so please give me a simple option to "DISABLE TAPE/DISK EJECTION" across the board.  Easy.  Just a tick-box that disables it.

Now the problem is that running remotly, we all know how much maintenance this product needs, it jumps the track at least monthly, and when it does, it requires someones intervention to go get the key to the server room, and push the tape back in. 

This is 2014, and it's simply assinine that someone has to walk up to the machine to push a stubborn disk back in the drive.  

Guess what?  In order for it to not immediately spit the disk back out, you have to:
1. Place all the jobs on hold.  (Not the server on hold as you can't do anything with the 'server' on hold
2.) Go into each job and retarget the date to 'start' on a date  today, or later than today.
3.) Take all the jobs off hold.
4.) Watch for a job to start, because even though you told all the jobs to start on a different day, there is usually one that didn't get the command and it will start/stop and eject the disk again.
5.) Quickly cancel that subborn job.
6.) Delete the media on the disk in the drive
7.) Manually log in at the job execution time to make sure it worked.

Countless hours and embarasement sending a client to the server room each month to poke a tape or disk back in the drive.  Maybe they can come up with a USB controlled servo-finger to mount on the top of the server that woud push the tape back in.  Now there is an idea they might look at, an add on feature to "automate" this task because it would mean more revenue.  "Symantec Magic Finger USB Tape Injector"  :)

Can't wait to get this one client off of Symantec an on to BackupAssist that will let me have my way with my data without any fuss.  Does Symantec even look at what the up and comming competitors are doing when they write a backup program from scratch?  Or are they content in raising the price every year, making you purchase the program again and again with no discount, as they continually introduce more bugs into every new and improved edition.... Content to sit by idle as the client base slowly erodes and moves to different competitors?  Only time will tell.  I have voted with my purchase of over 100 copies of BackupAssist.  This seems the only way to send a message that will get some attention.  Unfortunately, I will never look back.  Ditto with the Endpoint Security malware produced by this company.

deejerydoo
Level 5
Partner

Hi Guys,

 

If you've posted your woes on this thread, please make sure you have also posted your support for the suggestion for a fix on the following article:

https://www-secure.symantec.com/connect/ideas/stop-default-tape-eject-behaviour-be-2012

I've got a sinking feeling in my gut that tapes are still going to be spat out aplenty in 2014!

Cheers,

David

deejerydoo
Level 5
Partner

And Backup Exec has done it to me again!

Spat the tape out when it shouldn't have. It should always give me a chance to rectify or override andy media restrictions on the tape, if I need to, without spitting it out!

How Backup Exec got it wrong this time:

1. Backup job failed after writing a small amount of data to the tape. The media set prevents overwrite for 6 days but allows append for 5.

2. I restarted to server in the process of resolving the issue that caused the backup failure.

3. Kicked off the backup job again, to the same tape in the drive.

4. Backup Exec reads the tape and decides, for some unknown reason that it doesn't like it, spits it out and asks me to insert overwritable media!?

5. What about the perfectly good appendable media that was available on the tape already in there? There was heaps of space for all backup jobs to finish, with plenty to spare, even accounting for the small amount of data from the earlier failed job!

Symantec, You have got to redesign the way your software interacts with stand alone tape drives. This is ridiculous and unforgivable that this has been the abhorrent behaviour in Backup Exec for years and for no good reason! Not a single person has been able to come up with a sensible reason as to why your product is so eject happy, other than poor product design.

RickkeeC
Level 4

Over a year since the original post, and BE still spits out the disk with no option but to send someone to the locked server room to fish around and push the disk back in the drive.  Blatent disregard for customer requests.  Just a check box to DISABLE AUTO EJECT.    Fail all you want, send me endless cryptic error messages with broken, abstract tech notes, but hear me sceaming - NO EJECT until SIMON SAYS EJECT! Shame on you for not listening.  

How can you have the pudding (my money) if you don't eat the meat (our feature requests).  Shine on you lazy diamonds.  -Pink Floyd

deejerydoo
Level 5
Partner

And again!

Backup was running. We hit an emergency on the server and had to reboot it. Canceling the current job in the process.

Once the server was back up and running the next scheduled job started, before we were able to get to the Backup Exec console to pause or cancel it.

Overwrite protection for the media is set to 6 days and the append period is set to 5 days.

However, for some reason, Backup Exec ejects the tape, asking for overwriteable media to be inserted!?

There is nothing that can now be done, until we can get somebody to the server to push the tape back in!

shreekumar
Level 3

Hi There, 

Make sure that all the alerts are cleared before the technician insert the Tape and also there should be no backup job active at that time .

 

 

 

deejerydoo
Level 5
Partner

Sorry Shreekumar, but your response suggests you have missed the point and some critical facts about this thread and my previous post.

RickkeeC
Level 4

Hi thanks for posting.  It is a good tip as a work around.  Its not just clearing the alerts, if subsquent jobs are scheduled, put all jobs on hold, then you have to go into the job scheduler and retarget the start date for the jobs.  Otherwise, as soon as someone pushes in a new disk, the current job may have expired its wait time, and the next job will try to start, and eject the disk again if it is not the right disk for the job.

deejerydoo
Level 5
Partner

Alternatively Symantec could just fix the product and stop the tape from ejecting!

It looks like they had the idea but failed to join the dots. Currently, when the media insert request happens, the tape is still in the drive. You are presented with a dialogue that gives you the option to OK the request or to cancel it. Regardless of which option you choose, the tape is ejected. And this is where the dots are... If you hit OK, the tape is ejected, which is fine. However, if you hit cancel, the tape should not be ejected, otherwise what is the point of the dialogue asking you to OK or cancel? This is so frustrating it is really quite laughable. Symantec almost got this working correctly, but it appears that, before they finished tape media handling, in the product, it got locked into a product release and now falls into the Symantec black hole of "The product is working as designed".

No it's not! Guys, wake up and smell the coffee!

Not one single Symantec engineer I have spoken to about this, and there have been many over the years, has been able to rationalise the current behaviour of the product. The same goes for every person that has responded to the multitude of threads about this. Not one of them has had an argument, that bears scrutiny, as to why the product should behave as it does currently!

And yet the product team hunkers down in it's ivory tower and continues to hurl abuse at us poor "kniguts" outside! (Monty Python reference, in case you're wondering).

deejerydoo
Level 5
Partner

Outstanding Backup Exec product team!

Your fix for this is to remove the option to cancel the media eject alert!

Well, I guess at least the logic of the dialog box is addressed, but you still don't get the very simple and basic root of the problem do you...

Stop the media eject!

Let us look at the media set protection alert and the media that's in the drive and make a decision on which is more important; that the data already on the media is more important than the current backup job or that the current backup job completing is more important.

One can only hope that the move to Veritas is enough of a shake-up that the product team get are forced to wake up, shape up or ship out!

Richard_Graber
Level 3
Partner

I have been so frustrated with this "feature" and the general design of BE 15 that I may ask Symantec for a refund on my clients' upgrade and go to another product.  Any recommendations?

deejerydoo
Level 5
Partner

Symantec didn't listen and it looks like Veritas are set to continue the head in the sand approach to fixing their fundamental product flaws. If Veritas continue on this path I predict the total demise of this product within the next five to ten years. I am no longer renewing the support for any of my clients, using BEWS and moving them off it as soon as possible.

CraigV
Moderator
Moderator
Partner    VIP    Accredited

That's absolutely your choice! However, while you're still on it, and while you still have an open support call (?) I'd seriously recommend escalating this. If you have not done so, then do it...it's rubbish if you have no feedback.

Thanks!

deejerydoo
Level 5
Partner

Hi Craig, Over the past few years, since I decided to try and push this particular product change, you have replied to or posted on just about every article or thread about this product design flaw. Heck, you've even voted up my product feedback post, which we have discussed in this very thread.

Let's say it's a New Year's resolution of mine to learn to let go and chose my battles. Backup Exec, under Symantec and now Veritas is one batle that is simply not winnable. The product team, built in Symantec and inhereted by Veritas do not listen and continue to flog a product that they destroyed.

Do you hear that?

That's the sound of me letting go...

deejerydoo
Level 5
Partner

Do you hear that?

That's the sound of clients, yanking my chain and reminding me that, unfortunately, I cannot let go, when they want to stick with the product, whether I like it or not!

So...

What are the chances that Veritas can prove to all of us that this is a fundamental design flaw, in the product, that they inherited from Symantec, and that they are happy to fix it for us?

The original "Ideas" post, for fixing this was carried over from the Symantec Connect site, to the Veritas site:

https://www.veritas.com/community/ideas/stop-default-tape-eject-behaviour-be-2012

So, let's see if VOX and other attempts by Veritas, to reengage with it's client base, finally start to deliver and don't just end up being spin... because it looks like we're in this together, whether we like it or not...

PS: Veritas, let's see if you are able to add Veritas to your new forum spellchecker, as Symantec never seemed capable of such a gargantuan task, for Connect!