VM Tape job failed after ejecting magazine

[sasilik]

We have tape library with 4 magazines and 3 drives. 2 drives are used to write backups and 3rd is available when there is need to restore something from tape. That case came yesterday and when magazines from right side were ejected and tapes put in and magazines back the library was offline for a while for a VEEAM and VEEAM cancelled the backups to tape processes which were waiting inside the Backups to tape job. Error message was:

Code: Select all

17.09.2019 15:26:31 :: Tape library assigned to media pool Week files does not contain any enabled tape drive  
17.09.2019 15:26:34 :: Job has been terminated Error: Tape library assigned to media pool Week files does not contain any enabled tape drive  

Two backups to tape processes which where in the middle of writing data to tape were not affected and finished their jobs successfully. I found some older threads and KB article which I am not sure address the issue really.
tape-f29/bug-insert-tape-fails-job-when ... 36034.html
tape-f29/collected-feature-requests-for ... 29239.html
tape-f29/tape-job-fails-if-tapes-in-cha ... 50622.html
https://www.veeam.com/kb1816

After job ended I removed the successfully completed vm backups from job and started job again. But is this expected behavior and you should not eject magazines from library when there is backup job running? It kind of makes having the third drive for restore purposes meaningless.

[Dima P.]

Hello Markko,

Its not recommended to eject the magazine while the backup job is running. Can you please clarify if you have I/E slots configured on your library? Thank you in advance!

[sasilik]

Mailslots are disabled on library right now. I guess I should enable them and make use of them if removing entire magazine disturbs VEEAM tape jobs.

[Dima P.]

That should work. If I remember correctly, removing entire magazine puts the tape library in the offline state which leads to the mentioned issues. Cheers!

[sasilik]

It works but it makes procedure longer and more complicated. Instead of ejecting magazine, inserting tapes and putting magazine back person must eject mailsots, put tapes in it, import tapes in VEEAM and then go back and put rest of needed tapes and again import tapes. And I must write instructions for it to others. It is also little confusing for me why jobs which are waiting for tape resource to come available are aborted right away when library goes offline for a while. The ones which are processed don't even notice that and write their data without problem.

[Dima P.]

Thanks for the feedback, it makes sense. I've noted an improvement request based on your post and we will discuss it with the tape team. Cheers!

[btg]

case #05567708

Hi everyone,

I would like to request the following feature:
If a tapeloader goes offline (e.g. if a magazine is ejected), rather than aborting the queued tasks, they be put on hold (same as if there are no free tapes available).

We use tape as an integral part of our backup strategy.
We frequently need to do large tape swaps, while backups are writing to tape.

Whenever we eject one of the magazines, queued jobs/tasks fail, with the error message "No tape libraries are online"

I understand that Veeam's opinion is that "It is not recommended to eject the magazine while the backup job is running."

Using the IO slots is not feasible for us - we need to unload/load about 100 tapes, which takes 2 people about 2 hours. Ejecting the magazines takes 1 person 20 minutes.

Apparently, this used to be possible, but changed between Veeam 8 and 9 - see tape-f29/ejecting-magazine-puts-library ... 34044.html

Backups that are actually writing to the tape at the time, continue to write without any problems.

Thanks in advance.

[Mildur]

Hi Jort

I moved your request to this topic to keep similar requests together.
We will count your request as +1.

Tracked as PRT-226

Thank you very much
Fabian

[btg]

case #05567708

Hi Fabian,

I'm new to this forum - what progress can I expect on this issue?

[Dima P.]

We will add your vote to this feature request and will discuss it with RnD folks during the next major version planning, meanwhile, please do not eject tape magazine while tape jobs are running. Thank you for your feedback Jort!

[btg]

Does "next major version planning" refer to planning for Veeam 12.1, Veeam 13, or Veeam 14?

[Gostev]

Next major version is V13.

[btg]

Can you tell me when this meeting is scheduled?

[Gostev]

Not unless you're coming to one?

[btg]

When should I ask you if this issue was discussed, and what the outcome was?

[btg]

Gostev,

When should I ask you if this issue was discussed, and what the outcome was?

[Gostev]

I don't know it if was discussed by Dima with the corresponding dev team and what was the outcome, however such information would be for internal use only anyway. As always, we cannot share any details on possible future enhancements or their timelines. The earliest we can usually talk about any new feature publicly is after it is implemented in the immediate release branch and passes basic tests. This is both not to set false expectations and to ensure we have the flexibility to drop/postpone/accelerate features due to higher priorities.

From what I can see though, with only two requests in almost 4 years this does not seem like the most wanted tape backup enhancement. So it's somewhat unlikely that it is at the top of the priorities list for the tape team. This is not to say the feature does make sense or is unimportant, of course - and rather about its relative priority to other missing features.