How tightly managed is the V13 beta? I've done a sales request in the portal but am not sure if that's the right path.
For my part I'm trying to get a test environment set up to answer several internal questions surrounding both the move to web-based tools as well as the Linux VBR server (that would be the part we're most excited about).
Additional questions:
When can we start looking for documentation/tooling on migrating from Windows VBR to Linux VBR?
Will VeeamONE also be a Linux application, or if it's still going to be Windows will it still require MSSQL? If the only Windows environment we have to support is VeeamONE then we probably just won't have VeeamONE any longer as the cost/feature ratio of that one Martian may not be justifiable in an otherwise all-Linux environment.
Thanks in advance!
'If you truly love Veeam, then you should not let us do this ' --Gostev, in a particularly Blazing Saddles moment
Hi Mike, at this time I would not worry about V13 beta already as it's just a few weeks before the Supported Preview of V13 Veeam Software Appliance (VSA) becomes generally available. I will write an FAQ about this release before it's becomes available, so please hold any questions about this release until then.
Windows VBR to VSA is not "upgrade" but replatforming, it will not be available immediately. Likely stages are as follows, connected to evolving the tooling and importantly to stabilization of V13 VSA itself:
1/ No replatforming (only new, clean VSA installs are possible, although of course you will be able to import existing backups there).
2/ Replatforming with mandatory Professional Services involvement (otherwise our Technical Support will be forced into becoming them).
3/ Replatforming of basic deployments (with no complications) by customers, but artificially throttled (you'll need to sign up and wait for a "slot" to prevent our support from overload). May result in some secondary data lost (anything that is not stored in the configuration database, like guest catalogs).
4/ Replatforming of basic deployments at will without throttling and with added tools to prevent some/all secondary data loss.
5/ TBD based on how the above goes.
By far, my main and only concern in all this is our Customer Support team's load. Because if anything at all breaks during replatforming, they will be forced to troubleshoot consequences. Therefore any sort of mass replatforming right after V13 release can easily turn into tsunami that will destroy the organization (people will quickly burn out and leave). Not to mention the entire support organization will need time to build VSA expertise before every engineer can pick up VSA support cases in principle, and this ramp up alone may require some months.
So you can probably see how for the time being, net new install of VSA will be the best approach whenever possible. As a big part of the issue is all the Windows-specific leftovers that may have accumulated in the product configuration across years of in-place upgrades, which the new cross-platform code is simply not ready to encounter.
Oh, and importantly, replatforming will be available within V13 exclusively, never across major versions (from V12 direct to V13 VSA). Therefore you will have to perform an in-place upgrade of your VBR V12 to V13 as usual before you will be able to proceed with replatforming in principle.
Gostev wrote: ↑Aug 21, 2025 11:59 am
...
Windows VBR to VSA is not "upgrade" but replatforming, it will not be available immediately. Likely stages are as follows, connected to evolving tooling and importantly stabilization of V13 VSA itself:
1/ No replatforming (only new, clean VSA installs are possible, although of course you will be able to import existing backups there).
2/ Replatforming with mandatory Professional Services involvement (otherwise our Technical Support will be forced into becoming them).
3/ Replatforming of basic deployments (with no complications) by customers, but artificially throttled (you'll need to sign up and wait for a "slot" to prevent our support from overload). May result in some secondary data lost (anything that is not stored in the configuration database, like guest catalogs).
4/ Replatforming of basic deployments at will without throttling and with added tools to prevent some/all secondary data loss.
5/ TBD based on how the above goes.
...
Oh, and importantly, replatforming will be available within V13 exclusively, never across major versions (from V12 direct to V13 VSA). Therefore you will have to perform an in-place upgrade of your VBR V12 to V13 as usual before you will be able to proceed with replatforming in principle.
Thank you for the informative reply. This level of communication keeps us customer folks coming back when renewal time happens.
'If you truly love Veeam, then you should not let us do this ' --Gostev, in a particularly Blazing Saddles moment
mikeely wrote: ↑Aug 21, 2025 3:45 pm
Can it be MSSQL on Linux at least?
No. Besides, as I previously shared in another discussion, we plan to stop supporting Microsoft SQL completely in future so we don't spend resources optimizing the code for two different database engines. May be there are workloads for which PostgreSQL is not a great choice, but we've been quite happy with it for our purpose of hosting the VBR configuration database.
Okay, last question for now: is there a port requirements doc for V13 out yet? I am very much hoping that we can stick to the much-narrowed list of ports the Linux infra needs (pretty sure it's just tcp dports 22,443,2500-3300) compared to the spectacular mess of ports and ranges that Windows RPC calls require.
'If you truly love Veeam, then you should not let us do this ' --Gostev, in a particularly Blazing Saddles moment
' --Gostev, in a particularly Blazing Saddles moment