Tape linked to hardened repository

[Maga84]

Good morning, I wanted to know if it's possible to link a tape directly to a hardened repository. I've already checked the feasibility of the connection and its visibility by Veeam Backup & Replication, and it appears correctly. I wanted to confirm whether, in accordance with security best practices, it's possible to link it to the additional modules that Veeam needs to add to the machine.

Thank you!

[david.domask]

Hi Fabio,

I've moved your topic to our Tape Forum as it's more about supported tape servers than general question.

Please see our User Guide page on Tape Servers:

The tape server role requires root access rights. For this reason, Veeam Software Appliance, Veeam Infrastructure Appliance and hardened repository cannot be used as the tape server.

So you will not be able to apply the tape server role to a Hardened Repository server, you will need to configure a self-managed tape server.

[Maga84]

Thanks, David, for both moving the topic and replying. I hadn't seen the link to the guide you provided; I'd completely missed the need for root access for the tape server.

Thanks again!

[MLang]

Hi folks.

Is the Veeam Infrastructure Appliance supported as a Tape Server in v13? I know there is no explicit role for it, but can I basically use the VIA as a basis and install the appropriate drivers needed for the tape library etc.?

Regards, Marc

[david.domask]

Hi Marc,

I've moved your post to an existing topic on the same subject.

The Veeam Infrastructure Appliance current cannot host the Tape server role; self-managed tape servers (Linux or Windows) will be required.

See our Support Statement on the Veeam Appliances, installation of additional software / drivers is not supported.

[MLang]

Thanks for the clarification.

[eldxmgw]

I was advised to post this as a feature request, although frankly, I find it rather ridiculous to have to request a basic function of a tape server, which has always been there, in this way.

The original topic was: https://community.veeam.com/discussion- ... #post88135

My original request was:
I wanted to abandon my bare-metal Windows Server/VBR12 instance because of Microsoft and finally switch to VSA.
So I set up and configured a bare-metal test installation of VSA on the server.
This server has a direct connection to the HPE MSL 4048 tape library via a SAS controller.
Full of anticipation, I then read: "Note that Veeam Software Appliance cannot be used as a tape server." at: https://helpcenter.veeam.com/docs/vbr/u ... tml?ver=13
Seriously? That's incredibly counterproductive!
Now I'm supposed to set up and maintain another server because VSA doesn't have the usual integrated tape server role? I also haven't found any option in the web UI to integrate and use the currently running tape library via a tape server, as is usually the case.
Seriously? Did the DevOps team drop the ball here?

[david.domask]

Hi eldxmgw, welcome to the forums.

I've merged your topic with an existing topic on the subject.

Your point is understood, however please see the posts above regarding the the Veeam Appliances and tape devices -- we're aware of the request to remove this restriction, but at this time a self-managed tape server will still be required.

[eldxmgw]

Hi David, and thanks for getting back to my topic.
Yes, strangely enough, I already saw this thread a few days ago, after I first encountered this feature dysfunction and searched for a solution, but couldn't find one.
I was made aware of some aspects of this yesterday in my post in the community forum. I addressed these points today with my findings. I'd like to refer you to it: https://community.veeam.com/discussion- ... #post88175
If, as you wrote, you're already aware of this, is there an implementation roadmap for it, or is it TBD? Because as it stands, many people are just left hanging in limbo. This applies especially to this topic, but also to others.

[david.domask]

You're welcome Lolek.

Right now nothing to share, the restriction on tape server roles with the Veeam Appliances will remain for now.

However, we are always receptive to feedback, and will certainly consider yours in our discussions.

I will add one small bit of explanation on how we're positioning the appliances, as while I understand your position, the appliances are meant as a "zero-configuration secured appliance" -- the secured part is a cornerstone of how the Veeam Software Appliance / Infrastructure Appliance were designed and their intended purpose, hence why something potentially needing root and / or installing additional software to the appliance is so heavily regulated.

But your use case of an all-in-one setup that includes tape-out is understood, and as noted will consider this feedback moving forward.

[eldxmgw]

Thanks for the feedback, David.

Unfortunately, I can't let the line of reasoning regarding "security" and the implementation of just this one topic stand, even though it's a frequently used and popular mainstream evergreen.
Regarding so-called "security," you've already shot yourselves in the foot with the VSA project by jumping on the MFA bandwagon.
Even during the rollout, you're pushing the generation of a TOTP token.
Regardless of the architecture used to generate it, the metadata doesn't just reach the developer via the platform economy from which the embedded tool was obtained.
Most hipsters out there voluntarily use mass surveillance devices, aka "smartphones," for this purpose.
The fact that these transfer metadata and more 24/7/365 via commercially closed systems and so-called app developers has been widely known for decades.
This forms their financial basis through the sale of metadata on the derivatives market.

Finally, you really outdid yourselves by offering the "evil QR code" as an alternative to the cipher.
Well, how do you think that will be handled? Exactly, mass surveillance device -> camera -> self-contained and commercial tool – bang, end of story.

I only need to mention these two trivial facts to illustrate how the buzzword "security" undermines the system from the very beginning due to these intrusion factors.
However, this isn't a discussion limited solely to the Veeam ecosystem. Microsoft devotees turn pale when this topic comes up in the context of Entra.ID & Co.

And regarding the ID0 requirement for the tape implementation... it would be pretty stupid to just implement it like that.
If it's going to be encapsulated, then it should be.
And furthermore, there are certainly other implementation options, provided the person is willing to engage with them and doesn't just brush them aside.

Finally, the appliance doesn't need a feature that allows end users to add additional software solutions.
This can easily be left closed by the manufacturer.

However, this requires that you deliver an appliance that is in no way inferior to a fully-fledged backup system.
Realistically speaking, as things stand, this is far from the case. Even if the core issue of "tape" is completely ignored.
This not only results in the aforementioned features being missing, but also in poorly implemented server control options and their accessibility.
I just want to mention that the basic idea behind VSA is absolutely correct! It's just that the implementation and its real-world application lag far behind the potential requirements, and especially those of the users out there.
There are quite a few sources that are having a good laugh about this.
Whether this is ultimately good for the product is a marketing question.
This doesn't just mean the aforementioned features are missing, but rather poorly implemented server control options and accessibility.
In my opinion, I would not have launched VSA on the market in its current state.