Comprehensive data protection for all workloads

Do you consider these system requirements adequate for H2 2022 release?

Poll ended at Jun 05, 2021 8:44 pm

Yes, I'm fine with them
128
83%
No, I'll comment below
26
17%
 
Total votes: 154

Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Gostev »

WoenK wrote: Mar 15, 2021 6:18 pmExchange 2021 is coming out, so some might rather want to spent another year on their 2010 or two on their install before migrating.

If it was up to me, hell yeah, update all.
But the client spents the money and holds it tight in these times.
You can leave your clients with legacy platforms on V11, this will give them "another year or two" they need.
mkaec
Veteran
Posts: 462
Liked: 133 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: [V12] System Requirements for our 2022 release

Post by mkaec » 2 people like this post

rdmtech wrote: Mar 08, 2021 7:04 pm 2. We see our clients staying with Exchange 2010 via the same reasons. Microsoft realizes this as well and there is a very good chance they will continue to issue emergency patches as they have in the past with other EOL/out of support products.
That's a pretty big gamble to assume Microsoft will continue issuing security updates for a product they have communicated that they will not update anymore. They did it for HAFNIUM because they confirmed aggressive use of the exploit in the wild. I doubt they're going to release fixes for EOL Exchange when the exploits are only theoretical and not seen actually used. Then some script kiddie will find the exploit and have fun with your systems.
RubinCompServ
Service Provider
Posts: 259
Liked: 65 times
Joined: Mar 16, 2015 4:00 pm
Full Name: David Rubin
Contact:

Re: [V12] System Requirements for our 2022 release

Post by RubinCompServ »

Gostev wrote: Mar 08, 2021 12:41 pm Veeam Agent for Microsoft Windows

Windows 7 will have been out of support (no security updates) for over 2 years when V12 ships. I appreciate it may still be fine to use in locked down environments (no Internet access) which have to deal with a legacy software, but no one really explained why these same environments cannot also stay on V11, along with all other legacy software versions they have? I would like to see some comments on this.
Leaving aside that Windows Server 2008 R2 support ended at the same time as Windows 7, there are a number of reasons why customers with "legacy" systems wouldn't want to stay with v11:
  1. When we upgraded to v10, we encountered a number of issues that didn't exist in 9.5. After bouncing around with Veeam support, the common theme became, "We think this is fixed in v11. Upgrade to that and then see if the issue persists." While I hope it doesn't, there's no guarantee that we're not going to see the same refrain in 6 months: "This issue is fixed in v12; upgrade to that."
  2. Just because customers have "legacy" systems doesn't mean that they don't also have up-to-date systems, and we would want to ensure that those are supported as well
  3. Presumably, there will be new features in v12 (maybe SureBackup for VCD jobs? *hint hint*) and customers will want those.
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Gostev » 1 person likes this post

RubinCompServ wrote: Mar 23, 2021 6:04 pmWhen we upgraded to v10, we encountered a number of issues that didn't exist in 9.5
But if you stayed with 9.5, then you would not encounter these issues, right? ;)
RubinCompServ wrote: Mar 23, 2021 6:04 pmJust because customers have "legacy" systems doesn't mean that they don't also have up-to-date systems, and we would want to ensure that those are supported as well
Sure, I realize there are all kind of customers out there. But still, as you can still from the poll results, vast majority of IT shops do not to run software that is no longer supported, due to lack of security updates. And we as a vendor would like to focus our resources on the needs of this most common type of our customers. While those you're describing always have an option to deploy two backup servers of different versions: for "modern" and "legacy" parts of their environments.
RubinCompServ wrote: Mar 23, 2021 6:04 pmPresumably, there will be new features in v12 (maybe SureBackup for VCD jobs? *hint hint*) and customers will want those.
And here, we arrived to the very core of the issue. The main problem with adding new features is the QC resources. Our QC team gets new features and platforms to test with every release, but the old features and platforms are not going away - which is now causing a major impact on the pace of innovation. We simply cannot hire exponentially to follow the exponential test cases increase. And if we don't make hard decisions around dropping support for legacy platforms which are out of support by the platform vendor themselves, soon enough new releases will not have too many new features!
RubinCompServ
Service Provider
Posts: 259
Liked: 65 times
Joined: Mar 16, 2015 4:00 pm
Full Name: David Rubin
Contact:

Re: [V12] System Requirements for our 2022 release

Post by RubinCompServ »

...soon enough new releases will not have too many new features!
Part of the issue is that Veeam seems to be in such a rush to release new features that they aren't adequately supporting/patching their existing versions. We came late to the v10 release, and didn't update until July/August 2020. Not too long afterwards, we hit a number of bugs (some cosmetic and some showstoppers) and the refrain - since January - has been "We don't know what the problem is, but v11 will probably fix it", forcing us to upgrade to v11 much sooner than we would have liked. If the cost of "new features" is "new bugs in existing features", then there's a significant problem related to the QA process itself, not the regression testing.
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Gostev »

The correct statement is:
"The cost of keeping support for outdated platform versions" is "new bugs in existing features".

As I explained above, the QC team gets diluted by exponential growth of combinations and so the number of test cases, which is caused by adding support for more and more platforms and software versions without dropping support for the old ones. This results in the regression testing for each existing feature getting less and less man/hours with every release, causing bugs.

If something is supported, we have to test it equally well. For example, we have to test Windows 8.1 just as good as we test Windows 10 - while for every 50 customers using Windows 10, there's only one using Windows 8.1. And we would really love to put 2x more effort on making the product more reliable for those 50, because it only makes sense!

On the other hand, adding new features is actually nowhere near as impactful on QC, as they are always quite limited at the start in terms of platform support, general capabilities and cross-feature interactions, which in turn limits the number of test cases dramatically. For example, the newly added V11 CDP does not support half of ESXi versions we support for backup, does not support granular recovery, does not support Veeam Cloud Connect, etc.
RubinCompServ
Service Provider
Posts: 259
Liked: 65 times
Joined: Mar 16, 2015 4:00 pm
Full Name: David Rubin
Contact:

Re: [V12] System Requirements for our 2022 release

Post by RubinCompServ »

Adding new features is the crux of the issue, because Veeam decided to release v11 (for the new features) rather than patch v10. If I had systems that were supported under v10 but not under v11, I would now be suffering from bugs that will not get fixed. Why won't they get fixed? Because, rather than patch v10, Veeam decided to release v11 with those fixes instead.

By your logic, I would have been better staying at 9.5U4 where my systems worked properly, rather than upgrade to v10 (where my systems don't work properly) and not have any forthcoming patches (because my hypothetical systems aren't supported on v11). Except that 9.5U4 is going to lose support in the future, forcing me to upgrade to a "supported" version (aka v10) and accept the addition of unpatched bugs. I understand that QC is getting overloaded by having to regression-test the new versions on old systems, and that is exactly the problem - instead of rushing out new versions (because they have new features), ease up on the new features and patch the existing versions.
mkaec
Veteran
Posts: 462
Liked: 133 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: [V12] System Requirements for our 2022 release

Post by mkaec » 1 person likes this post

Gostev wrote: Mar 23, 2021 9:26 pm ...always have an option to deploy two backup servers of different versions: for "modern" and "legacy" parts of their environments.
I'd be wary of licensing issues involved with deploying two backup servers. It seems like the potential is there for things to go wrong, with one scenario resulting in accidental overuse.
mkaec
Veteran
Posts: 462
Liked: 133 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: [V12] System Requirements for our 2022 release

Post by mkaec » 1 person likes this post

RubinCompServ wrote: Mar 25, 2021 5:44 pm ..."We don't know what the problem is, but v11 will probably fix it", forcing us to upgrade to v11 much sooner than we would have liked...
This is a really good point. If you want to drop platform support in v12, then "it's fixed in v12" isn't an acceptable support response when a customer encounters a bug in the still-supported v11. The bug fix should be back-ported to the versions not EOL.
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Gostev »

RubinCompServ wrote: Mar 25, 2021 8:13 pmIf I had systems that were supported under v10 but not under v11, I would now be suffering from bugs that will not get fixed. Why won't they get fixed? Because, rather than patch v10, Veeam decided to release v11 with those fixes instead.
Bugs that were fixable, we just fixed in one of many updates v10 received... literally well over a thousand bugs were fixed. But there are also issues that cannot be fixed by changing a few lines of code, because they require a major re-write and re-architecture. Such stuff is not back-portable and requires a new major release, simple as that.

RubinCompServ wrote: Mar 25, 2021 8:13 pmI understand that QC is getting overloaded by having to regression-test the new versions on old systems, and that is exactly the problem
Except this is not what I said in the post you're replying to, please read it carefully. New features simply don't support old systems, so they don't need to be tested against them. While as we just established, new versions are required periodically anyway, to address bugs caused by more complex design and security issues. Both V10 and V11 were driven by the need of such major architecture updates, and V12 will take it to the next level as there's a lot of technical debt we need to address.

Anyway, I think this is really not a constructive conversation at this point, at least in the scope of this topic. It is best to create a separate thread to discuss everyone's opinions on how Veeam should change its software development approaches and practices - as it is a much bigger topic, and this change will not happen overnight anyway. While for now, I have to plan system requirements for V12 in the current realities.
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Gostev » 1 person likes this post

mkaec wrote: Mar 25, 2021 9:50 pmI'd be wary of licensing issues involved with deploying two backup servers. It seems like the potential is there for things to go wrong, with one scenario resulting in accidental overuse.
Keep in mind you can always split your Veeam license. In fact, in most cases you will HAVE to do this, as for example V9 does not support V11 license, and vice versa.
WoenK
Service Provider
Posts: 19
Liked: 4 times
Joined: May 08, 2020 6:38 am
Full Name: Andreas Wolter
Contact:

Re: [V12] System Requirements for our 2022 release

Post by WoenK » 2 people like this post

Gostev wrote: Mar 15, 2021 9:21 pm You can leave your clients with legacy platforms on V11, this will give them "another year or two" they need.
frankly...seeing how fast V11 came out (might remember it incorrectly, but I think V10 was a year in beta?!) I am not even considering updating to V11 for at least another 6 months .
And seeing the hickups of V10 (because all the sudden appliaction awarenss and file indexing was active for all Linux VMs) I have become even more reluctant to simply deploy an update :D

There is still way time to go for V12 and I really do not mind if general support is dropped for really old OSes, but at least there has to be a work around.
Already a nuisance to have a windows backup running on an Exchange 2007 because guest processing is not supported.
Really would not mind if there was an Agent that could do the same job, so even if B&R drops the support have at least the options of having agent backups for unsupported OSes to the repo.
And even if some OS are EoL, there are a few that still have extended paid for support and there are quite a few areas where there simply is no alternatives (like some software where there is really no existing provider and does not run in current OS).
soncscy
Veteran
Posts: 643
Liked: 312 times
Joined: Aug 04, 2019 2:57 pm
Full Name: Harvey
Contact:

Re: [V12] System Requirements for our 2022 release

Post by soncscy »

Andreas,

Just out of curiosity, how many 2007 Exchange boxes do you have that you're dealing with? I get it is frustrating to not have built in support, but it's not just about if the backup vendor supports it, it's the application vendor too I suppose. Is it really so many that having a spare older Veeam server around is not plausible?

If you're already comfortable with application versions the app vendor itself doesn't support, why not just use scripts? I think this would even be a requirement for those legacy applications that don't support modern OSes (what sector are you in that you have such applications that are so unique/vital that a vendor can force you to use outdated and insecure OSes?)
ITP-Stan
Service Provider
Posts: 201
Liked: 55 times
Joined: Feb 18, 2013 10:45 am
Full Name: Stan (IF-IT4U)
Contact:

Re: [V12] System Requirements for our 2022 release

Post by ITP-Stan »

Sometimes the OS is running on a production machine that costs lots of money. The vendor of that machine does not offer OS updates. Only new machines come with newer OS.

Or the customer has purchased new software running on newer OS but the old software running on older OS still needs to be used every now and then.
WoenK
Service Provider
Posts: 19
Liked: 4 times
Joined: May 08, 2020 6:38 am
Full Name: Andreas Wolter
Contact:

Re: [V12] System Requirements for our 2022 release

Post by WoenK »

soncscy wrote: Mar 27, 2021 7:20 pm Andreas,

Just out of curiosity, how many 2007 Exchange boxes do you have that you're dealing with? I get it is frustrating to not have built in support, but it's not just about if the backup vendor supports it, it's the application vendor too I suppose. Is it really so many that having a spare older Veeam server around is not plausible?

If you're already comfortable with application versions the app vendor itself doesn't support, why not just use scripts? I think this would even be a requirement for those legacy applications that don't support modern OSes (what sector are you in that you have such applications that are so unique/vital that a vendor can force you to use outdated and insecure OSes?)
Industry where the vendor does not exist anymore and nobody else is making something new?
Or where the newest supported OS is Win7 ?
Or where things where written in an obsucre database format that no one uses anymore and does not run on a modern OS?
I mean the really most frustrating part is when there is simply no alternative. Really not talking about clients that simply ignore security risks because they want to save some cents, but those that can not switch, unless they start developing somthing on their own or find a developer, that could do it.
If you got a CNC machine supported by a Windows PC (which in my opinion was a bad idea in the first place), using specialized interface cards which need a special firmware running only in a PCI slot on only few chipsets, one is almost screwed.

I do understand that one can not support an OS forever, but as far as I read V12 will bring an all-new repo with does not support any prior agent versions. Sure scripting is a possbility and I could probably go back to the standard windows backup, but there are also those support hours that come with the extra work hours the clients have to pay for and I rather have not a discussion with them, why I prefer Veeam and not somthing else, that would also save the old stuff.

Excahnge 2007 was an example...took me quite some time to find out that guest processing is not supported even though SBS2008 was not end of life at that point. And I could not find an Veeam agent that would run on it.
And cutting support for anything below Windows 1909 IMHO is way way too fast. Lets say I have a Win7 VM running 24/7 and I need it running without any reboots.software might also run on win10, but besided stabilty issues Win10 also does its own reboots from time to time just to update.
There are a lot of apllications where the security updates are simply not needed and looking at the track record of unstable updates from MS, I would never update those VMs. Why should I ? Nobody logs on to them besides via console, only way to get into their network is via the console from the Vcenter.
Shiny new updates are sometimes good, sometimes they help and sometimes one curses, because the security update just screwed something that was wroking perfectly before (like some 20H2 that produce blue screens, kill the bcd and in general do not seem to be any good).
So yeah...something legacy that can run the stuff but still have it in a central reporting of athe backup server, where I am not allowed to open a support case unless I pay for each one.
soncscy
Veteran
Posts: 643
Liked: 312 times
Joined: Aug 04, 2019 2:57 pm
Full Name: Harvey
Contact:

Re: [V12] System Requirements for our 2022 release

Post by soncscy » 1 person likes this post

I think maybe my statement was too direct, but my question was in earnest. Really, I 'm curious what sectors have this because I'm very curious which industries/problems are lagging on more modern (preferably OSS) solutions to such lock in.

Of course it's frustrating; that's part of the definition of vendor lock-in that this can they have such weight they can act unmovable in such situations.

I'm just curious who they are and who is ready to be disrupted ;)
WoenK
Service Provider
Posts: 19
Liked: 4 times
Joined: May 08, 2020 6:38 am
Full Name: Andreas Wolter
Contact:

Re: [V12] System Requirements for our 2022 release

Post by WoenK »

Nope, did not find it too direct :D
Just think about all the small firms that are in really small niches.
With very specialized hard and software, often custom made.
If the ROI would be around 5 years, one might convince them to upgrade (if they can).
If it is 20-40 years, surely not .
One must never forget, that there are not just customers each with a few hundred VMs that can be kept up to date.
There might be that one architect, who has his whole specialised database on a Win2000 server and it is protected by a printer port dongle for licensing. Virtualizing the hardware server was the easy part, finding an desktop machine with a printer port (USB Adapters did not work, win 10 is also having troubles with parallel ports) that would work as a licence server the tough one.

Really can not even guesstimate how many clients are out there worlwide, that might have the budget to upgrade if it was efficient, but not the possibilty.
If you really want to do tough cuts, you must give the once that sell or rent the licences to customers a really good darn argument, why that Win7 physical computer can not be backuped anymore by the backupserver that will handle Exchange 2021 backup as well as the other VMs and why he would need another "old" backupserver just for that and pay extra licenses.

I think it should really be no problem to have in a new version two different types of repositories, one for new and shiny and one for legacy. Would keep the status quo and still enable for new developments. Really would not even ask for any kind of support for legacy (just put it in a disclaimer, that every opened support case will cost a gazillion).
ITP-Stan
Service Provider
Posts: 201
Liked: 55 times
Joined: Feb 18, 2013 10:45 am
Full Name: Stan (IF-IT4U)
Contact:

Re: [V12] System Requirements for our 2022 release

Post by ITP-Stan » 3 people like this post

Manufacturing sector, where a machine and the PC that programs the machine is very expensive, ROI 10+ years.
Mildur
Product Manager
Posts: 8549
Liked: 2223 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Mildur »

Veeam Agent for Linux
CentOS: dropping support for CentOS 8; continuing to support CentOS 7.
Debian: no changes.
Fedora: dropping support for Fedora 32; minimum supported version is Fedora 33.
RHEL: no changes.
Oracle Linux: no changes.
SLES: dropping support for SLES 11 and some older service packs; minimum supported versions are SLES 12 SP3 and SLES 15 SP1.
Rolling distributions: Support for rolling distributions like CentOS Stream and openSUSE will be experimental given their ever-changing nature.
A small Question.
What are the changes to "Veeam Agent for Linux" and "Ubuntu"?

For installation of backup components, i understand that only 18.04 and later will be supported.
Ubuntu: dropping support for 14.04 LTS and 16.04 LTS; supported versions are 18.04 LTS and 20.04 LTS.
I am missing the information about making a backup from an Ubuntu machine.
Will 14.04 and 16.04 will be supported to use Veeam Agent V6?
Product Management Analyst @ Veeam Software
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Gostev »

Good catch! I simply forgot to copy/paste the Ubuntu line from the working document, but I added it now. Ubuntu 14.04 will be out of extended support by the time V12 ships, so we won't be testing it. Ubuntu 16.04 however remains supported. Thanks!
Mildur
Product Manager
Posts: 8549
Liked: 2223 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Mildur »

Thank you Anton :)
Product Management Analyst @ Veeam Software
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Gostev » 1 person likes this post

Based on the feedback, we also decided to keep support for Windows 7 and Windows 8.1 in the next release of Veeam Agent for Windows to give everyone a bit more time for migration to Windows 10.

As a reminder, all changes to the original plan are tracked in the first post of this thread in red font.
Regnor
Veeam Software
Posts: 934
Liked: 287 times
Joined: Jan 31, 2011 11:17 am
Full Name: Max
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Regnor » 2 people like this post

I thought about this topic and I can see pros/cons which were already mentioned here.
In total I would go with option "1".

Pro:
  • VBR stays clean and QC has more resources for important stuff
  • Removal of EOL application/platforms gives another good reason to upgrade those
Con:
As stated not every business has the money or manpower to upgrade all of their applications/platforms and there my be other reasons to postpone updates.
As you say Anton, they could stay on older VBR releases, but as soon as they experience problems or bugs, they would be forced to upgrade to the next major released because of Veeams support Policy (End of Fix).

What about that, before completely removing the support for certain applications/platforms, you mark them as non-supported/deprecated in the next major release?
Put that with bold, red letters any some ! on the top of the Release Notes and throw a warning on the first backup.
Of course this would only work if a) the new release doesn't break features which EOLs need and b) businesses don't take this transition time as an excuse for postponing the updates again.
rdmtech wrote: Mar 08, 2021 7:04 pm 2. We see our clients staying with Exchange 2010 via the same reasons. Microsoft realizes this as well and there is a very good chance they will continue to issue emergency patches as they have in the past with other EOL/out of support products.
Well I would say no.
Looking at the April and May 2021 patches which Exchange 2013+ have received, I would say Exchange 2010 is also affected but didn't receive an update. So you're running a software with serious security holes and just because there's no (known) mass-attack doesn't mean that there's no danger.
Perhaps 99% of the customers won't have problems with that, but the 1% could possibly lose everything; hey that's like not having a backup which in 99% is not needed :lol:
ITP-Stan
Service Provider
Posts: 201
Liked: 55 times
Joined: Feb 18, 2013 10:45 am
Full Name: Stan (IF-IT4U)
Contact:

Re: [V12] System Requirements for our 2022 release

Post by ITP-Stan » 1 person likes this post

With the additions (red font) I'm totally fine with it and have changed my vote.
vmtech123
Veeam Legend
Posts: 235
Liked: 133 times
Joined: Mar 28, 2019 2:01 pm
Full Name: SP
Contact:

Re: [V12] System Requirements for our 2022 release

Post by vmtech123 » 5 people like this post

I am fine with it.
If the companies that make the product stop supporting it, why should you have to keep supporting it?

I should change that. I'm actually for it.
I am all for smaller, faster, streamlined versions of software without a ton of legacy stuff that I don't need.

Whoever is using vSphere 5.5, Server 2008 prior to R2, Exchange 2010 or SQL2005 have bigger concerns than yelling at you guys. If anything they should be THANKING you. I would use this as an opportunity to go to Management or Exec and say we need to fast track the upgrades as the backups won't be supported any longer. What an excellent way to get traction on something that should have been done years ago.

You can't get mad about Veeam dropping support for an OS, when you are not concerned about the security of your infrastructure running it. Also, A VMware snapshot is a VMware snapshot. You can still backup the VM's, the app aware stuff may not work, but I'm sure many of the people here can still get by. My one legacy isolated VM gets snapshots still and it is NOT supported. If it ever needs a restore and is broken, I can say I did my best with your unsupported OS that I have warned you about 40 times and I am covered.

Pro tip, stay a few versions ahead so you aren't still trying to get off Server2008 when they drop support for 2012. Your 2012 plans should already be underway, and if you are still using Windows 7 with no plan, yikes.

Also. Stay on V11 until you upgrade? No one is forcing you to go to V12 next year. Everyone wants the latest and greatest features, but to support their 15 year old OS. If you can upgrade Veaam, you can upgrade your VMware and Windows servers.

I haven't seen any posts about CDP and Server 2003 or 2000 yet, but you never know.
Regnor
Veeam Software
Posts: 934
Liked: 287 times
Joined: Jan 31, 2011 11:17 am
Full Name: Max
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Regnor »

If I may quote Anton from the latest digest:
Nevertheless, here I must also share that soon and for the first time ever we will be releasing a new cumulative patch for the previous major release (V10). As you know, according to our existing support policy non-current releases are not supposed to get updates in principle. So, why are we doing this? The primary reason for this exercise is to do a real-life test our R&D processes and workflows for compatibility with the possible introduction of a long-term support channel (LTSC) in the future. While we're still defining what we can realistically do to have periodic LTSC releases without impacting the pace of our innovation too much, it is clear that such releases will require on-going patching – which is what we're "training" on doing here. For the cumulative patch to be actually useful for V10 users, we will include fixes to a few common support issues and bugs that directly impact TCO, as well as backport some security improvements from V11. This way, customers who need to stick with V10 for whatever reason will be in a much better place. Nevertheless, V11 remains the recommended release without a doubt.
A LTSC could possibly solve some of the problems/concerns in this topic.
johnwatson
Influencer
Posts: 10
Liked: 9 times
Joined: Feb 16, 2021 7:42 pm
Full Name: John Watson
Contact:

Re: [V12] System Requirements for our 2022 release

Post by johnwatson »

On a restorability perspective, after we have migrated to Veeam 12. Will historic backups that dont meet minimum system requirements e.g. pre-server 2008 will file level restore, VM restore, etc. be supported. i.e. They work in Veeam 11 and dont in Veeam 12. Will I need to keep a Veeam 11 server around for those edge cases.
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Gostev »

They should continue to work fine for the most part because for example VM restore does not even care what OS is inside of the restored VM, FLR only needs the file system inside VMDK to be readable by the mount server, etc. However none of these cases will be tested and so officially supported with V12, if that is what you're asking.
Uwe.Groening
Veeam Software
Posts: 134
Liked: 5 times
Joined: Feb 23, 2015 10:18 am
Full Name: Uwe Groening
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Uwe.Groening »

Hello,
How high are the chances that we will support RHEL V9 in the new Linux agent. An enterprise customer had explicitly asked about this.
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: [V12] System Requirements for our 2022 release

Post by Gostev » 1 person likes this post

It is already supported by V11 with a patch from support.
Post Reply

Who is online

Users browsing this forum: Alex Hung and 213 guests