Seriously? VSA can't be used as a tape server?

Hey ​@Lolek Bolek . Not really much for us to comment on here. For better communication of your frustration...and even make a feature enhancement request, it’s best to post this on the Forums directly to the PMs. There are several “things” the VSA doesn’t have the ability to do, either yet or ever. Some due to security (DISA STIG config of the OS, etc), and some just maybe because this is only the 1st iteration of Veeam on this platform. But again..you can make your frustration heard better over on the Forums. Maybe they even have this already planned as a potential enhancement in a future release.

Best.

They did not drop anything the VSA is a hardened appliance and more permissions are needed for a tape server which is why that is a requirement.  If you want all in one then Windows server is the better option.

Could you please guide me directly there?

I'm not very familiar with the board and wouldn't know if I'd find the right channel for this.

PM = Product Manager or Personal Message? If the latter, who should I contact?

You would interact with the Product Managers not messages.

A hardened Tux and/or more permissions do not automatically interfere with or exclude a fundamental feature of the software system. VSA /= VIA and positions itself as a logical bare-metal or virtual OVA appliance evolution to the Wintendo equivalent. Using this as an argument for not including a fundamental feature simply for that reason would be like me removing the brakes from your new car and claiming that more safety features and sensors in the interior are a pro argument, and what do I actually want, since the car will still start and roll even without brakes.

How do I get in touch with these so-called "product managers"?

Hi ​@Lolek Bolek - just go into the VBR page:

https://forums.veeam.com/veeam-backup-replication-f2/?sid=38a7c871158344436cb483ed6fa5997d

Then create a post there with “feature request” in the subject with Tape Server or something similar. PM = Product Managers. Sorry for the confusion there.

Best.

Thank you, did so. Just waiting for a moderator green light there.

Hi,

Just to echo that tape creates concerns over the customisation and additional security risks that installing additional software and drivers brings:

https://www.veeam.com/kb4772
 

You can use the Veeam Software Appliance and then an additional server for tape purposes, but the purpose of the Veeam Software Appliance is to be a predictable collection of software and configuration, pre-hardened for minimum security risk and footprint.

You’ll also find an existing post on R&D discussing this, and a specific call out is that the role requires root, something that is not granted on the Veeam Software Applliance: https://forums.veeam.com/post561761.html?hilit=Tape%20Linux#p561761

Sorry, but that's just wishy-washy marketing fluff.... Or are you implying that all VBR releases from the pre-VSA era, contrary to the Veeam rhetoric propagated up to that point, represent an infrastructural security risk, and that clients who used them in their trust were therefore infiltrated? You should be more concerned about why Veeam is jumping on the MFA bandwagon, trying to sell it to you like all the hipsters as a security measure, but then, during installation, already directing you to third-party TTP applications. These applications often rely on mass surveillance systems like smartphones, tablets, or even better, the application platform economies of other manufacturers for authentication purposes. Before you can do this, you have to hand over your metadata, which is then sold on the derivatives market for profiling. This means you can perform your supposed MFA authentication on compromised applications from anyone, all under the guise of security within your Veeam ecosystem. To make matters worse, Veeam also offers malicious QR codes for supposed convenience, which, as mentioned before, can be scanned by cameras of mass surveillance systems. Wonderful, how naive can you be? The metadata that is automatically transferred (and of course the data you don't see) doesn't just go to the coder. Furthermore, since several major releases, so-called "AI" has been promoted. So, what this integral component has to do with "gimme all your data" and the unanimously approved security features is certainly open to question. And you do realize, I hope, that pontificating about "security" in the same breath while simultaneously using commercially closed software systems is utter nonsense? I could go on and on, but please feel free to continue writing about how the disintegration of the core "tape" feature is being sold as a pro-argument in the name of so-called "security," instead of simply taking a clear stand and stating that DevOps either dropped the ball or allowed themselves to be co-opted by marketing zealots and their mantras for a product that, as it stands, is unfinished.

This makes little sense for consolidation in small to medium-sized infrastructures, and especially in SAS interconnects. Furthermore, why should an extra system be maintained for the sake of interoperability, which isn't even a given with SAS, when a) this has always been an integral part of the backup ecosystem, and b) Veeam was already promoting this as an alternative (and I'll put it bluntly) long before the first VSA beta releases for those who want to get rid of the Microsoft stuff and don't see why they should have to maintain a separate Microsoft server in their existing infrastructure just for VBR? What exactly are you describing as "pre-configured"? If you mean the OS, then that's due to the purpose of the appliance. However, it doesn't include the production and relevant core functionality. If it did, the target audience would be vanishingly small. So, the resource requirements are already quite average to high for what it writes by default in its factory state. And why you're harping on about security again is beyond me. I can't help but notice that when I read your backlog, I'm immediately reminded more of marketing mantras than of the other person's nuanced thinking.

Yes, I read that. My feature request (it's ridiculous that customers have to remind the manufacturer about it) was exported there. The internet is full of posts where, on the one hand, the VSA approach was long overdue and is celebrated with a sigh. On the other hand, these same people usually add a big "but" afterward, emphatically warning that this is clearly an unfinished appliance for production environments. This applies not only to the first version, but also to the currently available overlay 13.0.1.1071. This isn't just limited to my specific issue; it's a problem across the board. It ranges from completely missing core features to illogical arrangements or channeling of basic appliance controls, to the fact that many people are mocking the manufacturer for releasing such a TUX-based VSA, while simultaneously publicly justifying the endless feature dysfunction by recommending the VBR console to those using the VSA. The VBR console, of course, is only available as a Wintendo build, which in turn requires at least the use and maintenance of a M$ Wintendo (v)client. It couldn't be more ridiculous. And here lies one of the immense contradictions of the otherwise sound idea, which, however, is currently poorly implemented and obscured by a lot of marketing fluff. The cast-based cheerleaders do their part. I must say that i've observed and can confirm exactly this and other issues on my current test track with the VSA. And regarding your objection, what's so bad about running the ID0 process in an isolated layer, even if it were implemented that way? There are far worse things that are sold to the obviously uninformed masses as features. That's really not a valid argument. Furthermore, there are plenty of better ways to implement this.

​@Lolek Bolek I’m going to assume you’re having a bad day, but there is no need for the plain rudeness in your response.

It’s not marketing to highlight that if something requires root access on a system designed specifically to avoid granting root to anything, that those two things are by design, not compatible. Why that seems to offend you so deeply, I cannot say.

I suggest you refresh yourself with the community rules, reframe your essay into the key points you wish to portray, and try again.

The bottom line is you’ve been given your next step that you can raise this over in the R&D forums, but segmentation of components with differing degrees of risk is a common design approach.

@MicoolPaul semantics and contrived theatricality are not very productive. And you don't need to feel offended or caught out just because it contradicts the usual mainstream mantras.

We don't need to have a fundamental debate here about things that should already be clear.

New insights would be more helpful. Unfortunately, in your backlog, you're just repeating yourself instead of authentically addressing the issues.

Therefore, it's unclear to me what new point I could possibly address in your backlog.

v13 abandoned Windows 11 as an OS.  Now we have to buy Windows Server 2019.   Community version doesn’t have a lot of features.   They won’t sell me a full copy for home because I am not a business.   I am still on v11.   Going to v12 is upgrading a SCSI tape controller and drive not supported on Windows 10 or 11.   I wished VEEAM would drop Microsoft and go to Linux.   They are less controlling.