Failed to Unload Tape..

[saxie]

Hi All,

My Client's Tape job fails with:
'Failed to unload tape: tape AZP341L5 requires return to original slot 47, but it is already filled. Move tape manually.'

any idea how to solve this? I get it from time to time and I'm pretty sure its something I'm doing wrong somewhere. I'm using a HP Library wit hthree drives and a number of media pools. Eject Tape once the job finished is enabled and 'create a new media set per backup session' is also set on the media pools

i'm thinking that they are possibly inserting tapes into the library slots while there are still jobs running or while there is still a tape in the drive(s). If thats the case, how does one make sure to only put tapes into the slots that are actually empty (as opposed to empty but that slot's tape is in a drive)?

Thanks

W

[veremin]

Hi, Werner,

The "Eject tape” option doesn’t pull out a cassette from a library, but rather places it into a certain slot. So, it seems that, once finished, a given tape job is trying to automatically place a tape into a slot that is already occupied by a tape placed there by different tape job. As the result, you see the corresponding message.

Thanks.

[saxie]

Hi, thanks for the reply.

Yes, I know this is why I'm getting the error. I understand the eject function also .

The way I see it this happens in one of two ways:
1. The user is inserting tapes into the library slots manually while a tape is still in a drive. When this tape is eventually ejected (job finishes) its slot is already occupied and it complains. Quesiton: How does the user know which slots he may use?
2. A tape job finishes and ejects the tape to a slot that is 'owned' by another tape that is still in another drive. Question: why would veeam allow a tape to be ejected to a slot that belongs to another tape that is still online in th elibrary/drives somewhere.

So, to rephrase. I would like to know if there is a way to see if an empty slot is owned by a tape that is currently in one of the drives of the library so that I do not accidentally put a tape in that slot when filling the library.

Thanks!

[veremin]

Currently, there is no way you can prevent yourself from having this error in cases when someone decides to interact with library via library actual interface (inject/eject cassettes manually, etc.).

However, it will be appreciated if you open a ticket with our support team and provide them with required logs, as QA team is interested in this case. More specifically, they want to see whether this issue was caused only by manual intervention (i.e. user inserting cassette) or overlapping tape jobs were also involved.

Once the corresponding ticket is open, kindly, post its number here.

Thanks.

[saxie]

Veeam Support - Case # 00480572

[veremin]

Thank you for providing your ticket number. I've already passed this information to QA team.

[Hevros]

Hi,

I also have this issue where tapes are manually changed in a library and the slot in use by the job is filled then it fails to return the tape.
Other software (Arcserve) solves this by just putting the tape in another empty slot. can this be implemented by Veeam?

[veremin]

Hi, Stephen, for now the manual operations with the cassettes conducted via Library interface are "transparent" for backup server. In other words, VB&R management server isn't aware of these activities. As the result, you're experiencing the said issue.

Anyway, thanks for the feedback; much appreciated.

[nterreault]

I have similar problem, but it is happening when i insert tape. If i dont put the tape in the correct slot i get the error
Job started at 2013-12-12 10:59:17
2013-12-12 10:59:20 Error Failed to eject tape XXX Error: Tape XXX requires return to original slot 6, but it is already filled. Move tape manually, and retry operation.
I need to reshuffle the tape in the correct slot. Its really a pain and annoying

Nicholas

[Dima P.]

Nicholas,
Any chance you are using blind library without barcode reader or standalone drive? Thank you.

[nterreault]

Im using a library but not using the barcode ? Thanks for asking ?

Any idea ?

[Dima P.]

Nicholas,

Could you, please, run a test with barcode reader enabled in your library? Thank you.

[nterreault]

It was enable, i disable it to test, doesnt change anything.

Thanks,

Nicholas

[Dima P.]

Nicholas,
Thank you for the heads up! I will let our QA know about the results, meanwhile could you, please, open a support case? Also do not forget to post case ID to this thread so we could track it. Thank you once again.

[dave-g]

I am getting the same issue with a Quantum superloader if a job starts and a tape has been put into the slot Veeam was expecting to use.
24/01/2014 05:32:09 :: Failed to unload tape: tape Tape 15 requires return to original slot 2, but it is already filled. Move tape manually.
The job states that the actual steps of the job have completed successfully and then tags this warning line on the end of the job.
I would expect Veeam to recognise that there were empty slots available and use them accordingly.

[Dima P.]

Hello David,
This issue would be fixed in the upcoming patch 3, so stay tuned.

[Dima P.]

Hello,
The slot issue was resolved in newly released patch 3, so if anyone still has this issue – please, make sure you install last available update. You can download it here.
The feedback is highly appreciated. Thank you.

[Kirkus_AU]

Hi guys

I've installe Patch 3 and still getting this problem. Logging a support ticket now. Stay tuned!

Cheers
Kirk

[janjaaps]

We also have this issue, we are running patch #4, i think veeam should find another empty slot on its own and the job should continue, without error or warning (or make this a selectable option for customers).
Manual intervention of the library shouldn't break running or new backups. We've never had this with other solutions (like netvault).

Also.... the job shows "Warning" as last result, while nothing is put to tape, i think the job should report "Failed" in this occasion.


PS. Veeam support on proxies would be nice, but i guess that's coming in v8?

[Vitaliy S.]

Hello Jan,

Also.... the job shows "Warning" as last result, while nothing is put to tape, i think the job should report "Failed" in this occasion.

Makes sense to me as well.

PS. Veeam support on proxies would be nice, but i guess that's coming in v8?

Yes, the goal is to address it in the upcoming major version. Thank you!

[foggy]

Looks like patch 4 has introduced the issue back. With patch 3, Veeam B&R should select the free slot instead of failing the job. I would appreciate if you get to support with this so they could verify this is the similar issue and probably come up with a private hotfix.

[stooby]

This is also affecting us, p4 / v7.0.0.871 - I would hope we should not have to wait until the next major version for such a simple problem.

[foggy]

Please contact technical support directly. As it is stated above, they might have a private fix for this issue.

[janjaaps]

Seems like there is no (private) patch for this. I contacted support and they are letting me wait till v8
But we sort of worked around this. The problem still persists but we are able to get everything to tape without manual intervention. Far from ideal but better than nothing i suppose.

when tape jobs are still running during the manual daily tape change, there are tapes loaded in the drives.
If so, running and new tape jobs, in need for a tape, most likely will fail because they can't unload the tape to its original slot because it's probably filled (due to the manual tape change).

Manual intervention is needed in this scenario for veeam to continue. The tape needs to be moved to a free slot using the tape robots management interface (cli/gui/whatever) before veeam can continu on a new tape job.
If not, all new and already running jobs fail...
(sometimes even showing warning when nothing has been put to tape, this seems to happen when full pass succeeds because no vbk's and incr pass fails due to "failed to unload tape" or vice versa).

We sort of worked around this issue by unloading all driveloaded tapes in the night before the tape jobs start.
We wrote a little batch file using a cli command from the tape vendor to do this.
This ensures that when the tape jobs start there are no tapes loaded in drives and veeam has full control over de robot and can always unload.
And hope that all tape jobs are done before morning/daile tape change
We just started doing this earlier this week, so we are still cathing up on older backups needing to be put to tape, but almost there.
We do get some errors now and then:
1. "error Terminted" probably due to tape unload outside of veeam (happens when tape job still running when we do the scripted tapedrive unload)
2. "storage {0} is locked by another session" when tape jobs is still running or wanting to start and the main veeam backup jobs start (i think only happens on transformation)
But at least everything is put to tape in the end, only sometimes a nigth to late...

[AaronD]

We are experiencing this issue as well. When tapes are manually inventoried or cataloged, the last tape to be processed is not ejected from the tape drive.

Support says this is by design: "The reason why the Tape is left in the drive is in most cases after an inventory People will either restore or write to the tape so the software leaves it in place to reduce wear on the Arm."

However, this causes our backup to tape jobs to fail in the following scenario:

1. SS0001 is in Slot 1
2. SS0001 gets loaded into Drive 0 for cataloging and is not ejected from Drive 0 once cataloging is finished.
3. Technician loads new tapes into library which get autoloaded into the following slots
- SS0002 into Slot 1
- SS0003 into Slot 2
4. Backup to Tape Job #1 runs and tries to load SS0003 into Drive 0
5. Veeam realizes there is already SS0001 in Drive 0 and so tries to return it to its original Slot 1, however SS0002 is already in Slot 1
6. Veeam Backup to Tape Job #1 fails

This is causing issues in our production environment. Either Veeam should have the versatility to be able to move tape SS0001 to another slot (since its original slot is now filled), or Veeam should start ejecting the last processed tape when a technician manually performs a tape catalog/inventory (or at least provide us a GUI option to enable this functionality). Something to lessen the chance of our tape backups failing.

My Case ID for this issue is #00645503

[Dima P.]

Hello,

We confirmed these issues with the QA team. The problem is that some medium changers in some tape libraries can’t return tape media to the ‘random’ slot if the original slot was taken on the hardware level and they do not recognize standard windows tape API, which could resolve such situation. We already found the solution, but it requires additional testing. I will update this thread as soon as it will be available. Thank you.

[NewBackup]

Hello,

we have the same problem with a Fujitsu LT40 library and V8.
Is there a solution at this time?

[Dima P.]

Hello Daniel,

Please, check the solution provided in this KB article and let us know the results. Thank you.