Video Screencast Help

Stop default tape eject behaviour in BE 2012...

Created: 05 Aug 2013 | 13 comments
deejerydoo's picture
23 Agree
1 Disagree
+22 24 Votes
Login to vote

This is with regards to what I would term a fairly fundamental design fault, in Backup Exec (BEWS), which has existed for several versions. It specifically applies to single tape backup drives (not autoloaders) for backups run at small/remote sites, in an unattended manner.

Scenario:

A backup tape is inserted into the tape unit. For whatever reason, the tape is associated with the wrong media set and the overwrite protection period (OPP) or append protection period setting prevents the job from progressing. At this point the job enters a waiting state. While the job is in this state BEWS creates a media removal alert. What it also does at this point, and this is the point where the logic breaks down in BEWS, is to eject the tape, thereby making it impossible to rectify the issue and necessitating a visit to site to push the tape back into the drive!

What should happen is as follows:

The incompatible OPP should cause the job to enter its waiting state and BEWS should still create the media removal alert. However, the tape should not be ejected. The media removal alert will alert the operator to check the backup job and media properties without any harm coming to the data on the tape. The operator then has an opportunity to decide the next course of action. If it is to stop the backup job, then the operator hits the "Acknowledge" button on the media removal alert and, ONLY AT THIS POINT, BEWS ejects the tape. However, if the operator realises the issue with the media set on the current tape they can associate the job with the correct media set. Once they have done this they will be able to hit the "Cancel" button on the remove media alert and the tape will NOT be ejected. The backup job will then leave its waiting state, because the alert has been cleared and the job will find that the media is now in a backup set that will allow the job to continue.

Comments 13 CommentsJump to latest comment

Alejandro Cisternas's picture

I have the same problem, the site with a stand alone drive have diferent time zone that me, some times the tape expire few minutes after backup job begin, so the job eject the tape because is a valid tape, but only by 5 minuts more, and we have to wait to next office day on site to reload the tape.

+1
Login to vote
digre's picture

Yes please. Give us the opportunity to cancel tape eject.

+1
Login to vote
gbmtw's picture

We have to pay for engineers at the datacenter to push our tapes back in when this happens

It would be nice to have an option to leave the tape in or eject it on a per job basis, with either as the default.

+1
Login to vote
Ruben Teuling's picture

100% agreed

Just installed 2012 and thought, lets see if they already added this functionality/option, to my disappointment this wasn't the case. I know of about 80% of my clients that (I) would upgrade to 2012 NOW if this option was added. Would save me and them a couple of hours a year.

+1
Login to vote
deejerydoo's picture

Can somebody from Symantec please comment as to whether 2014 addresses this issue at all?

+1
Login to vote
deejerydoo's picture

The slience from you guys is deafening!

You could say almost as loud as the sound of feet walking away from the product.

+1
Login to vote
Andrew Wiggin's picture

In my case, I have switched to a backup over fiber from tapes. But, the tapes are faster & I still have several of them lying around. So, I used to run a tape backup every night. Now, my data has grown over the threshold of what fits on my tapes (just barely). I would keep doing what i did - i can set the job to auto-cancel before it finishes - but, the tape is still ejected - so the next night it fails.

I know this isn't a mission critical need, but, when the crypto-locker ate my files, the >1TB of files from tape restored much (35x) faster than what was on the fiber.

+1
Login to vote
boaz's picture

I have been running back and forth to insert different tapes today, even though the tapes have been wiped and even BE shows them as blank, but for some reason not writeable (set to be writeable after 8 hours, those tapes have'nt been used over 2 weeks). It works only at the beginning of new jobs, but not when a second tape is needed. Even Symantec support was not able to fix it, although they closed the case as solved.

What a horrible product, and waste of time dealing with support. I was happy with the Veritas product, but the Symantec versions just got worse and worse.

Tip for Symantec engineers - keeps the automation out. Automation is too complicated for your level.

0
Login to vote
RickkeeC's picture

Over a year later since this vote, 18-1 to put the feature in to disable eject, or at least prompt to eject.

Shame on you Symantec, NO EJECT until SIMON SAYS EJECT!   Blatant disregard for the clients needs.  Just keep changing the interface, adding more "features" no one will use, put a new and improved label on it and just keep selling it to companies that don't know there are better products out there.  No discounts to "Upgrade", you just buy it over again and again at full retail, for support that tells you, oh yeah, this is "By Design"  

+3
Login to vote
deejerydoo's picture

Gotta love the "By Design" mantra!

Why would anybody design something to fail or make absolutely no sense?

If the design is wrong, fix it!

If the implementation of the design is broken, fix it!

0
Login to vote
deejerydoo's picture

Here's the latest response I have had from a Symantec APAC senior sales representative, on this matter:

"This behaviour is a fundamental part of the design, has been through multiple versions of Backup Exec and is unlikely to change. If the available tape (or RDX cartridge) is not suitable for the current backup job (or fills up mid job) it will always be ejected and a prompt will be seen for suitable overwriteable media to be provided. This is because there is no way the job will revert to using that media and it then makes sense to eject it so that new media can be provided. This type of problem is usually only seen by customers using stand alone drives, as libraries would return the media to a slot instead of ejecting (Although a library, or partition within a library, that contains absolutely no suitable media will still pop up the alert asking for overwrite able media) If customers experience this type of issue they need to look at their backup strategy including  their media protection settings and media handing processes OR invest in a library (as well as adjusting some processes and settings)."

This response is totally indicative of the cultural intransigence that exists within Symantec, with regards to identifying improvements (most would say fixes to fundamental design flaws) for the product.

How simple can we make it for you guys to understand?

There is absolutely NO benefit from making the tape eject automatically. I have discussed this with countless Symantec reps and they all come back with the same dysfunctional response "This is by design" or "This is how the product has behaved for ages." However, after talking to them about the design flaw and walking through it all, without exception, those that are able to get over the two aforementioned mantras, see sense in what I (and plenty of others) are saying about the product. Almost every single backup admin I have discussed this behaviour with (and the voting on this article will back this up, including positive votes from some of your most active and respected participants!)... This behaviour makes no sense and needs to be changed!

But Symantec still believe that "This is by design" and "The product has behaved this way for years" is a valid response.

But Symantec still believe that this is because us backup admins don't understand media protection and overwrite policies and management.

But Symantec still believes that we can simply install tape libraries or backup to disk systems at small, remote offices or sites.

No... It is so simple... Your product ejects tapes, when it shouldn't... Give us the opportunity to investigate the failure and then decide whether to eject the tape or not. Ejecting it benefits nobody.

+3
Login to vote
RickkeeC's picture

Absolutely the best comment regarding this "by design" flaw cover up.  A simple check box could be added, "Prompt only, do not eject media" .  Instead, Symantec dictates that you compensate for the design flaw by working around it by chaning your backup strategy.  Here is a simple solution for the SOHO customer you can mark as an answer Tandenburg 8 disk robotic RDX library, $3,731.00 .  Of course, you will probably want the exra 2 year warranty for an extra $823.99 .

http://www.cdw.com/shop/products/Tandberg-RDX-Quik...

We worked around it by purchasing a $1,000 NAS, and using the duplicate to disk feature.

2015-02-21 13_43_59-Clipboard_0.png

0
Login to vote
Alex Strupler's picture

@Symantec: Is there really no Solution for this yet? I can't understand, how you as a professional company can accept that Customers have to invest so much time and money to input the tape again at remote Sites, when they don't want to change the tape!!!!

Please understand this matter and implement such a function to deactivate tape eject as soon as possible!! If you are software engineers, please consult some Buiness Analysts, in case you can't understand the financial influence in not building in such a function on your customers!

0
Login to vote