As far as I am aware and know you can only have one tape Library per tape server with no multi access based on the help page you posted too. Veeam tends to want to control the entire tape Library.
Correct - I have asked for Feature Enhancement, so just wanted to get comments if this would be beneficial - Single VM controlling a large library with numerous drives would never be able to efficiency transfer enough data consistently to keep the drives spinning.
I gotcha. Yeah that would be a good suggestion for sure.
Ok, you are asking for a construct like a library manager and library clients in Spectrum Protect.
Yes, I would be glad if this would work with Veeam, too. Then you could maximize the usage of your libs and drives
I think you have to write such a feature suggestions into the Veeam forums. There is product management reading.
I support this request.
Sounds good. To understand you right: do you talk about multiple physical tape server?
Just stumbled upon this.
We regulary do connect the individual drives of a single library to different tape servers. Reason is - as stated - to circumvent a bandwidth bottleneck at the tape server. LTO8 wants to have up to 360MB/s. So four drives would be too much for 10G already.
The only thing to keep in mind is: you have to partition the library. So to VBR they look as if they are individual single drive libraries. Most libraries with multiple drives offer that option.
We don’t use virtual tape servers though - as it would only work with iSCSI anyways. I like to combine the tape server role with a Windows repository. So e.g. each extent of a SOBR can become a tape server as well. This ensures maximum speed during tape out. We use SAS or FC for the drives.
Sounds good. To understand you right: do you talk about multiple physical tape server?
i will add a +1 to this feature specially with the increase of bandwith rate of LTO9, didn’t see a bottleneck for the moment but our FC infra is brand new with 32gb ports.
I will deploy a library on ethernet with 10gb/s in short term, now i’m little bit affraid. The controller doesn’t support for the moment 25gb port.
Just stumbled upon this.
We regulary do connect the individual drives of a single library to different tape servers. Reason is - as stated - to circumvent a bandwidth bottleneck at the tape server. LTO8 wants to have up to 360MB/s. So four drives would be too much for 10G already.
The only thing to keep in mind is: you have to partition the library. So to VBR they look as if they are individual single drive libraries. Most libraries with multiple drives offer that option.
We don’t use virtual tape servers though - as it would only work with iSCSI anyways. I like to combine the tape server role with a Windows repository. So e.g. each extent of a SOBR can become a tape server as well. This ensures maximum speed during tape out. We use SAS or FC for the drives.
I like your approach with a tapeserver per repository server. I think this brings good performance.
The disadvantage is that you have to partition your tape library and have to assign the number of drives and tape slots hard to the logical libraries. So, it is not possible to give more or less ressources to one tape server automatically when it needs them.
A management instance which assigns tape drives dynamically to a tape server would solve this. Call it library manager/client or something else.
I like your approach with a tapeserver per repository server. I think this brings good performance.
The disadvantage is that you have to partition your tape library and have to assign the number of drives and tape slots hard to the logical libraries. So, it is not possible to give more or less ressources to one tape server automatically when it needs them.
A management instance which assigns tape drives dynamically to a tape server would solve this. Call it library manager/client or something else.
Correct. That’s a weak point. But with per-VM-chains VBR more or less equalizes the amount of data being driven to a single library. Good point is, you still have the drive parallelity available for your jobs. Once you reach 3 drives there is no other option anyways. Despite you have >10G at the tape server.
I like your approach with a tapeserver per repository server. I think this brings good performance.
The disadvantage is that you have to partition your tape library and have to assign the number of drives and tape slots hard to the logical libraries. So, it is not possible to give more or less ressources to one tape server automatically when it needs them.
A management instance which assigns tape drives dynamically to a tape server would solve this. Call it library manager/client or something else.
Correct. That’s a weak point. But with per-VM-chains VBR more or less equalizes the amount of data being driven to a single library. Good point is, you still have the drive parallelity available for your jobs. Once you reach 3 drives there is no other option anyways. Despite you have >10G at the tape server.
I have direct fibre channel connections to the library at my tape servers and the repository direct on them. So I can send the data via FC to the drives and these connections are at least 16Gb, the newer ones 32Gb. And I can utilize several FC connection in parallel.
With a suitable disk solution more than three drives can be utilized.
Hello Veeam Community
I've also encountered this limitation at a customer's site. Unfortunately, Veeam cannot operate a physical library or its partitions with multiple tape servers. Will this be possible in the near future?
Best regards,
Markus
Hello Veeam Community
I've also encountered this limitation at a customer's site. Unfortunately, Veeam cannot operate a physical library or its partitions with multiple tape servers. Will this be possible in the near future?
Best regards,
Markus
As far as I know they are not. Unless confirmed otherwise by someone at Veeam. There are libraries that support multiple applications but not sure the same one twice. Veeam tends to need exclusive access to the tape library.
Hi all,
https://helpcenter.veeam.com/docs/backup/vsphere/tape_servers.html?ver=120
>You can add multiple tape servers to the same installation of Veeam Backup & Replication. But note that you cannot add one tape library to two different tape servers and write data to it from both tape servers.
Is this the line that is throwing everyone off?
I disagree with the consensus in this topic, as I think this line is being misunderstood.
A tape library in Veeam is a logical object that includes:
- Tape Server
- Connected Tape Drives
- (optional) Robotic Changer (the exchange mechanism)
Don’t confuse this with the actual physical hardware, this line is simply talking about a collection of hardware connected to a tape server, regardless of the means.
With library partitioning which many tape devices support, your tape hardware will present a for all intents and purposes unique virtual partition which includes the changers and the drives that should be presented to the backup application, i.e., it will be a unique library in Veeam terms.
This is supported, as the tape hardware will manage the resource usage here. Each partition will receive the requests from the backup application and the tape hardware will manage the physical side of things.
What is _NOT_ supported is connecting the _SAME_ partition to multiple VBRs. That will cause non-stop issues as both VBRs will fight to try to lock the tape drives, and we have safe guards in place to prevent such double-adding (though this can be violated)
So same (veeam) library added to multiple VBRs? => Not supported, likely won’t even be possible to do
Two partitions from the same tape hardware being connected to two different tape servers? => Supported, but note this usually means iscsi (but not always), so plan accordingly.
Thanks for the clarification @ddomask