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.
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:
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.
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!
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 .
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.
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:
I've got a sinking feeling in my gut that tapes are still going to be spat out aplenty in 2014!
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.
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
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!
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.
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).
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!
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?
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.
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.
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...
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!
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:
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!