Rocky Linux now GA. Veeam support ??? (also AlmaLinux)

[PTide]

Thank you for sharing this piece of knowledge. Much appreciated. Glad to hear that the product makes some good to someone.

For future readers: please note, that although Veeam Agent for Linux might work well on Rocky, Alma, and other RHEL-alike distros, we cannot provide official support for those right now.

Be especially careful with using pre-built (kmod) modules on unsupported system as it can cause unrecoverable backups and lead to unpredictable side-effects on the actual system.

Please also note that VAL v6 introduced an improved pre-built binary blksnap kernel module packages (requires kernel 5.3.18 or later).

If you wish to support our work towards better compatibility with modern distros, you can suggest your code improvements here:

https://github.com/veeam/blksnap/blob/m ... blksnap.md

Anyway, all bug reports and improvement requests posted here will be taken seriously and will be review by R&D team.


Thank you

[Gostev]

+ I will share the proposed System Requirement for V13 in a couple of weeks for discussion, if we can agree to drop some less popular distros the our QA should be able to add some new ones into their test plans.

[mikeely]

Thanks Anton. Is there any way we can move this forward to a point release in V12? Going unsupported until V13 goes GA is a fairly significant business risk for a lot of us.

[Gostev]

It is unlikely as this would require us to change V12 system requirements and drop some currently supported distro, in order to obtain spare QA capacity for testing some new distros. This would be much more damaging as this directly impacts existing customers already using the product on such distros, many of whom chose those distros and/or Veeam specifically because of the official support available. We first announced V12 system requirements 2 years ago, changing them on a short notice is just unfeasible.

Having said that, remember you can still use distros which "seem to work fine" with Veeam under the experimental support terms.

[mikeely]

Alas, I get it. CentOS/RH really left a lot of people out in the cold, vendors included. Any way of shifting QA resources or expanding to the slight degree it'll take to add these extremely-similar distros to the supported list before V13? We don't even know which February V13 will be released yet </hint>

[Gostev]

We don't do "slight" testing though especially after we had the users of unsupported distros discover a number of distro-specific issues that included data losses. The most recent one even corrupts data on the source (production) disk, eww...

By the way, always wondered - why not use some of the [many] supported Linux distros instead?

[mikeely]

By the way, always wondered - why not use some of the [many] supported Linux distros instead?

Fair question. I would first point out that we were on a supported distro - Centos 7! We were just beginning steps to migrate to Centos 8 when that thing happened which I won't mention, and of course that put our migration plans on hold. From there, we sincerely considered Debian/Ubuntu (most likely Ubuntu LTS) as an alternative but this would require refactoring several of our internal tools, thus paying off some old tech debt the hard way. It was still a possibility. Of the remaining distros, I personally suggested openSUSE, having worked with it before but nobody else had touched it since they last lost data to a ReiserFS crash or two. Fedora is out of the question due to perceived if not actual stability concerns, and there's standing knowledge in the office that the minute we start using Oracle software I walk directly out the door, never to return. I've been down that road before and will never ever (EVER) have anything to do with those scumbags ever again, ever. Yeah yeah, OEL is free for anyone to use, just like Java used to be. I wasn't the only person on the team to have this specific concern with Oracle's widely-reviled business practices either. I really wish Veeam (and the rest of the tech world) would dump them like the bag of trash they are, but I understand why you'd have a lot of customers who rely heavily upon Veeam to recover from the latest stupid thing Larry's amateur-hour team of incompetents foists on their customers.

Once Rocky came around and we could see momentum and community engagement, we began upgrading to that instead. We've not got a highly-successful Centos 7 to Rocky 9 (by way of Rocky 8 ) workflow and should be totally current within the next few weeks. It works, it's stable, and the only code we're having to refactor is the stuff we were going to have to refactor anyhow (ahem, PHP) and should have done long ago.

I do hope this provides some insight into one customer's experience of having the CentOS rug yanked out from under them, and what process was gone through to arrive at a community-supported distro to run the business. And also some insight into how I feel about one particular "software" vendor.

[mcz]

By the way, always wondered - why not use some of the [many] supported Linux distros instead?

We're running a hardened repository on Alma due to one reason: The driver for the 10 Gigabit NIC was only available for RHEL...

[lasseoe]

I do hope this provides some insight into one customer's experience of having the CentOS rug yanked out from under them, and what process was gone through to arrive at a community-supported distro to run the business. And also some insight into how I feel about one particular "software" vendor.

"arrive at a community-supported distro", eh? CentOS was a community-supported distro, in the end you get what you pay for and you didn't pay for CentOS so .. yeah. If you want guarantees, support etc then pay for RHEL, it's really not that expensive if you opt for web-based support which is still A LOT more than what you get from any free distro.

Switching between RHEL compatible distros isn't all that hard, the real differences are in how they handle repositories and in the grand scheme of things it's a minor detail that's easily dealt with.
If you manage your servers and more importantly apps using a configuration management tool, switching between distros isn't that big of a deal.

[aj_potc]

For future readers: please note, that although Veeam Agent for Linux might work well on Rocky, Alma, and other RHEL-alike distros, we cannot provide official support for those right now.

Would we be able to rely on your best-effort experimental support, as Anton mentioned in a later comment?

We certainly can't expect you to guarantee anything based on a non-supported distro, but it would be nice if your support agents would give these cases a try, rather than dropping them as soon as one of the popular RHEL clones is mentioned.

Be especially careful with using pre-built (kmod) modules on unsupported system as it can cause unrecoverable backups and lead to unpredictable side-effects on the actual system.

That sounds scary! Would you mind sharing whether this problem occurred with one of the distros we're discussing here?

Thanks!

[PTide]

Hi,

Would we be able to rely on your best-effort experimental support, as Anton mentioned in a later comment?

I did not the questions, honestly. Are you asking whether we can declare experimental support for Alma and Rocky?

Be especially careful with using pre-built (kmod) modules on unsupported system as it can cause unrecoverable backups and lead to unpredictable side-effects on the actual system.

So far I haven't heard of any serious adverse effects on the systems that are being discussed here. However, even RedHat sometimes releases patches that bring a lot of headache. I remember one or two RedHat minor (revision) kernel updates which broke certain things, and RedHat released another fixing patch shortly after. And you know what? The initial breaking patch never made it to CentOS ever! They completely skipped it!

[aj_potc]

"arrive at a community-supported distro", eh? CentOS was a community-supported distro, in the end you get what you pay for and you didn't pay for CentOS so .. yeah. If you want guarantees, support etc then pay for RHEL, it's really not that expensive if you opt for web-based support which is still A LOT more than what you get from any free distro.

But we're not discussing OS vendor support, guarantees, or whether anybody paid for CentOS. When CentOS 8 was shut down by Red Hat, we were forced to move to something else. So, we're naturally interested in expanding Veeam support to the successors of CentOS.

Unfortunately, I and many others don't consider CentOS Stream, Fedora, Oracle, or RHEL to be CentOS successors.

[aj_potc]

Hi,

I did not the questions, honestly. Are you asking whether we can declare experimental support for Alma and Rocky?

Yes, exactly. Some level of best-effort or experimental support would be better than nothing.

[mikeely]

But we're not discussing OS vendor support, guarantees, or whether anybody paid for CentOS. When CentOS 8 was shut down by Red Hat, we were forced to move to something else. So, we're naturally interested in expanding Veeam support to the successors of CentOS.

Unfortunately, I and many others don't consider CentOS Stream, Fedora, Oracle, or RHEL to be CentOS successors.

Not to mention going the MSP route (paid support from RedHat) is, while not in their mind expensive, still an unbudgeted expense and "not expensive" is relative. We do have a RedHat license to be able to view docs on access.redhat but to upgrade our whole fleet to RHEL would require a significant expenditure which would force us to postpone other projects which are higher in importance.

[villapla]

Hi,

I think it would be nice to distinguish between Veeam supporting Rocky/AlmaLinux for:
a) VAL
b) Hardened Repository

I'm only interested on b). AFAIK there are no kmod involved, so I hope supporting b) would be simpler tan a).

[brianclemens]

Oh behalf of the Rocky Linux team, let us know if there's anything we can do to help!

Easiest to reach us at https://chat.rockylinux.org

[PTide]

@brianclemens

Hello there! A surprise, for sure, but a welcome one. : )

Thanks for reaching out, we won't miss that opportunity.

Cheers

[ThHu68]

Hello @all,

I’m mostly just a reader, but often read about different Linux distributions and Veeam support.

How about the thought: Snap vs Veeam. This could be used to support many Linux distributions

https://snapcraft.io/about

Even if snap's are basically heavily protected, you can open them specifically. And you would only have to develop and validate in one direction.

Greetings
Tom

[Herbert Sz]

b) Hardened Repository
I'm only interested on b). AFAIK there are no kmod involved, so I hope supporting b) would be simpler than a).

I know it doesn't help for the specific support question, but I'm using Rocky in my lab since January as hardened repo, it works fine.



If one wants support immediately running an immutable Repo on Rocky, you could get it by using Minio on Rocky as S3 target, which also works nicely in my lab and is supported by us.
Unfortunately I saw, Minio support for production is not cheap, if it's true what they mention on their Website.

[brianclemens]

@brianclemens

Hello there! A surprise, for sure, but a welcome one. : )

Thanks for reaching out, we won't miss that opportunity.

Cheers

Glad to hear it! There are a few companies that are leveraging our special interest groups to build out support for their products / delivery / etc. It also appears we also already have community members working on enabling Veeam support in Rocky Linux: https://chat.rockylinux.org/rocky-linux ... dfrrky49xr

[bennyvasquez]

So happy to have been passed a link to this thread! I work for the AlmaLinux community and I chatted with some folks at the veeam booth last week at CloudFest. I’ll echo here the offer I made to them last week: I know testing load is almost always the hesitation with adding support for additional distros, and we’d love to help with that! Feel free to reach out if we can offer additional resources to help with testing, or if we can answer any questions at all. We’ve got a load of interested community members.

[PTide]

Hi Benny,

Much appreciated! Will prepare some questions for you soon.

Thanks!

[mikeely]

Hi all:

Any update on this? It's been a couple months since Brian and Benny reached out.

Thanks!

[Gostev]

Interesting development:

IBM Red Hat Puts RHEL Source Behind Paywall
This week, IBM Red Hat made a big move. This is one of those moves, that, at the same time, our readers should have been prepared for. Red Hat moved RHEL source code behind its paywall for subscribers. This has huge implications for Alma Linux, Rocky Linux, and others seeming to leave only CentOS Stream, a testing release, as an avenue for IBM Red Hat's source code. One thing is clear, IBM Red Hat does not want folks running anything in its ecosystem unless they are paying customers.

[d3nz]

First steps of killing Open Source?..

[jandrewartha]

And then there's https://openela.org/ now. So more choices but still no answers as to which ones will be supported by Veeam.

[gpochiscan]

Hello!

Still wondering when and if Veeam will ever officially support Rocky linux 9.1/9.2 when rockylinux/almalinux are alternatives of RHEL and many customers moved from CentOS to these distributions.
Veeam installation directly from veeam-release repository works just fine on rocky 9.2, I could create full backup of the server, connect it to provider.
Now, the veeam management cannot be installed in order to be able to manage the agent and backup jobs from VSPC.

As a service provider it's impossible to be able to manage rocky linux backups individually as you will need to individually manage all the agents.

Also, veeam support couldn't respond to this question at any moment and just redirected to forum.

In conclusion: Is it veeam going to support Rocky Linux 9.1/9.2 and when?

Thanks!

[aj_potc]

Unfortunately, this topic is now more than two years old, and we still have no guidance from Veeam regarding their plans to support any of the RHEL clones that have been widely adopted since the EOL of CentOS 8 in December 2021.

At the moment we're in a very unpleasant situation in which a number of our systems are not officially covered by Veeam support.

It would be great to hear something (anything!) concrete so that we can plan our future OS migrations with Veeam support in mind. That's true even if the answer is that Veeam will never support any RHEL derivative. At least then we'll know, and will be able to look at alternatives.

Thanks!

[PTide]

Hello,

No short term (as in "the next 6 months") plans for official support so far, internal negotiations are still ongoing.

Thanks!

[sebkoe]

I also find it a bit surprising that not even RHEL 9.2 is officially supported e.g. as Vmware Proxy. Not to mention the now widely used Alma / Rocky 9.2 variants.

Instead, CentOS 7 is still supported, which will already be EOL in mid-2024. I would expect something more from Veeam here.