Manual tap ejection cause Error alert

[Michael_G2]

Hello,

I am using BE 14.1 (rev 1786) with a Tandberg LTO-5 HH tape drive.

Each time I do a manual (or scheduled) tape ejection, the tape is ejected immediately and during about 6 minutes BE displays the job ejection. Then it stops with an error alert :

"Eject drive 00014 -- The job failed with the following error: A device attached to the system is not functioning"

Then the only solution I have is to reboot my OS.

Where the problem come from ? software or hardware ?

Thanks

Mike

[pkh]

You should run the Tandberg diagnostics utility against the tape drive so that you can check for possible hardware error. Make sure you select the write test and that you stored ah the BE services beforehand

[VJware]

Are there any errors / warnings logged in the event viewer ?

Try running vendor diagnostics against the tape drive as well.

Is this a physical or virtual media server ? And are you using Symantec drivers for the tape drive ?

[Michael_G2]

Thanks for your answer,

Tandberg diagnostic tools did not find my tape driver. I asked them and I am waiting for their answer.

I tried Tandberg and symantec drivers and I have the eject error alarm in all situations.

The OS is hosted on a virtual machine (vmware esx) where the tape drive is dedicated for this VM.

[CraigV]

...that's your issue...running BE on a VM accessing a physical device like tape is not supported at all.

Thanks!​

[Michael_G2]

I succeeded in testing the tape drive with Tandberg  diagnostic tool. It can eject and reload the tape without any problem. So the problem does not come from the drive.

How to prevent BE to send an error alarm when I asked for a manual or schedule tape ejection ? Moreover why it sends an error alarm ?

My backup strategy is the following : Every first month monday at night, I schedule a Full backup and all other days at night I schedule an incremental backup. Every first month monday at 14h00 I schedule a tape ejection, so workers can hear the ejection and then put another new tape. This is a way not to forget to put another new tape.

[VJware]

Not recommended as per https://support.symantec.com/en_US/article.TECH130609.html

[CraigV]

...read below and this can explain why you're getting erratic behaviour on BE:

https://support.symantec.com/en_US/article.TECH130609.html

[Larry_Fine]

And Colin's post in

https://www-secure.symantec.com/connect/forums/migrate-physical-be2014-media-server-virtual-be2014-media-server

[Michael_G2]

Hello,

I don't understand all. Do you tell me that because I am using a VM - that is not supported in all case - BE is not able to eject and understand that after ejection it is a normal situation that the drive has no tape inside ? or do I understand that because I am using a VM, there is no support, so I can't have a clear answer ?

I will try to clarify the situation.

1. my backups work fine

2. I can restore, I don't have any problems

3. When I use the tape manufacturer tool, the diagnostic is good, the tool is able to eject AND reload the tape.

4. my problem concerns only the ejction by BE that is not able to understand that it has previously eject the tape.

If there is no solution for this problem, that does not matter, I will find to try an alternative myself.

regards,

Michael

[Colin_Weaver]

With the exception of certain iSCSI attached tape libraries that are listed on our HCL, Backup Exec has never officially supported using physical tape drives or libraries with a virtualized Backup Exec Server.

As we have never officially supported it we have do no official testing that might document problems that you may have.

However we do know from customers that log cases with us (not realizing that it is not supported) that this type of configuration can appear to work initially but then intermittent or unpredictable problems occur.  Most of these issues end up requiring a full reboot of the virtualized Backup Exec Server to temporarily resolve them, however they wil happen again at some seemingly random point in the future.

As such there is no way we can support such a configuration (even as reasonable efforts). You might get it to work however the customer experiences show us that you will regularly have to take manual action to fix problems, it will never be a stable solution.

[Michael_G2 · Accepted solution]

Ok that's clear.

[CraigV]

...this was done against my wishes at a client, and it was the host that needed rebooting causing unnecessary waste of admin hours.

Also please mark the post that helped as this assists people in future...

Thanks!