I just had a P2 ticket and got the generic 7 step fixes but none of them mentioned updating .NET and PostSQL to the latest version. Spent hours trying to figure out why my 25TB Veeam 365 repo died on me and it came down to the most basic software updates.
I recently updated to 8.1.2.3301 to fix the archiving issue, it was good for a week solid, then bam, Friday 11/7/25 came around and all my backups stalled, and repo went invalid for 72hours. Was pretty desperate after hours cause I had a client with some missing emails and couldn't restore and all backups stopped.
Just insane to me that it let me update and doesn't check if we are latest .Net or updated PostSQL version. I suggested it to the support staff to improve but HEY they sent me here to suggest updates/improvements. So ya'll get to read about this. Please Veeam improve your updates and installers install the suggest installing the latest .Net and PostSQL. THX.
We plan to enhance the experience by adding a version check for installed third-party components. You will receive a notification during the upgrade if any component is outdated. However, automated updates for NATS and PGSQL are not foreseen; users should perform these updates manually.
HI,
As i have issue for installing the 8.2.0.2202 version i will try to update first the .net and the PostSQL.
However in the requierement of this version (Cf the release note) it's not mentionned that we need to have the latest version. The version compatible with the update are listed in the release note so normally except if you are very late on the version of .net and PostSQL it should work.
Thanks
Best regards,
Nicolas
Running the latest supported versions is recommended but not required. I've heard about issues with upgrading to v8.2, but cannot confirm atm the root cause. RND is looking at those as we speak.
I have also noticed another important factor that can cause upgrade failures.
If the system doesn't meet the recommended resource requirements, for example having 4 CPU cores instead of 8, or 8 GB of RAM instead of 16 GB, the upgrade may simply fail. The worst part is that it does not roll back cleanly. In my testing, it can leave the software uninstalled altogether.
I have also seen upgrades fail if components such as .NET or PostgreSQL are below a certain version level. According to Veeam’s current System Requirements KB, the officially supported PostgreSQL versions are:
Local or remote installation of PostgreSQL 15.9, 15.12, 15.13, 15.14, 16.4, 16.9
That said, I have been running versions 17.5, 17.6, 16.9, 16.10, and 15.14.x across various environments. From experience, the 17.x branch performs the best, while the older builds tend to have more issues.
The reason I am on an “unsupported” version of PostgreSQL is that the KB originally stated “version 16 or later” was supported, and that language was changed long after my deployments. Since PostgreSQL 17.x has been stable and clearly superior, I am not risking a downgrade just to satisfy that change.
Hopefully this helps others avoid similar issues and provides some additional data points for anyone troubleshooting failed or incomplete upgrades.
Maybe not related but just got hit by an error trying to update from 8.1 to 8.2 :
Error: Could not load file or assembly 'C:\Program Files\Veeam\Backup365\Veeam.Jet.Net.v12.2.0.dll'. The specified module could not be found.
RND has found a critical issue in upgrades from 8.1.2.3301 or 8.2.0.2008 to the latest 8.2.0.2202. While we're fixing the issue, the workaround can be uninstalling the currently running version and then installing the latest 8.2 and connecting it to your existing NATS and PGSQL. All the configuration and settings in such a case will be preserved.
We're now working on updating the information on veeam.com and KBs.
At the same time, build 8.2.0.2202 can safely be used for new installations and upgrades from build 8.1.2.180 or lower.
what exactly is the critical issue? I updated a small test environment from xyz.2008 to the latest version and since then the test backups are so slow or stuck because of a throttling issue, strange behaviour.
We need this test environment these days, so really uninstalling the software via windows uninstall und doing a fresh vb365 install would fix the issue?
(I didn‘t enter separate credentials for NATS or PostgreSQL when upgrading months ago, but I won‘t lose my config during a fresh install?)
Hi,
I have the PostgreSQL 15.14 and the dotnet 8.021.
Normally this part should be ok because if i open the ISO of the patch i can see that the version of PostgreSQL in the package is the 15,14 and the dotnet the 8.017 same for PowerShell.
The two things that are not up to date are the Microsoft Visual Studio and the the NATS server.
May i have to update the manually before to try again to install the patch.
Otherwise i will wait for the new fix, is it planned to be released soon?
1) Delivering a fixed version will take us time. Uninstalling the VB365 controller (server) and doing a fresh vb365 install would really fix the issue if you connect it to the same existing NATS and PGSQL. This is an ugly workaround, but it works.
2) We recommend running PGSQL 16.9, and NATS 2.10.28. However, earlier versions listed in our documentation are also supported and work with no issues.
The PG 16.9 recommendation surprises me because:
a) the iso (still) has v15
b) I'm not aware of a Veeam documented upgrade from v15 to v16 (or later), updating with the same major version is documented in https://www.veeam.com/kb4729
Running on 2202 with most customers without any upgrade issues on PG 15.14 and NATS 2.10.28, upgraded both components myself as per your recommendation for NATS in https://www.veeam.com/kb4742
If fairly easily possible, and not unimportant, also supported I would prefer to upgrade to the latest PostgreSQL 17 or even 18 which was release two months ago.
I followed (and readapted for my specific use with a customer) the following guide to upgrade to a new version of PSQL in use by the VBO: https://www.veeam.com/kb4676
I suggest making the first attempt in a lab, possibly using an environment as similar as possible to the production one.
