Violation of PRIMARY KEY constraint 'PK_Storages'

Which Veeam version/build are you running?

Besides the Veeam version you are using check the logs here - C:\ProgramData\Veeam\FOLDER for more details on the job.

Also, I would suggest a quick search in the forums - http://forums.veeam.com

We are on Veeam version 12.0.01420 P20230718

The error is occurring with our backup copy jobs, which we utilize StoreOnce catalyst repositories.

Error Is related to Veeam DB. It seems a similar issue due After version upgrade. You can create a new DB with Veeamdb tool.

Wait support reply for correct solution but I think Is only possible.

Let us know how you solve.

Support has stated there is a known bug and will be working with us on a fix.  However, it appears we need to make sure our StoreOnce firmware is at 4.3.6.

Keep you in the know.

@Moose - When you get it resolved, let us know the details on what exactly is causing the issue and the resolution….of course, without sharing pertitinent work info. What I mean is, if it is the Veeam DB, are you using PostgreSQL or SQL? Is the issue due to the storage type you’re using? (StoreOnce) Or, is it a combination of the two? Or, something else? I just think it would be beneficial for others to know/be aware of who use similar infrastructure as you in case they run into the same issue.

Thanks!

Sure will, our SQL is on its own server, and we utilize HPe StoreOnce for the repositories.  We are still waiting for a support engineer to review and provide us with a fix.  While we are in a wait state, our storage architect is upgrading the firmware of a StoreOnce pair.

Great, thanks!

Veeam support is working out a fix in R&D and testing, hopefully it will be released soon.

Ah, ok..nice. Thanks for the update @Moose !

Great to hear be sure to report back if it fixes the issue.

Veeam support responded last Friday with the following. 

It seems as though there was some kind of event that happened during the original synthetic full run which caused the problem which may have involved something environmental. The synthetic fulls have generally been successful previously.

Because the trigger seemed to be some temporary condition, and because the firmware on the storage has now been updated to 4.3.6, I wouldn't expect to see reoccurrence even prior to getting the updated hotfix.

The affected backup chains were still in a problem state in the database that is preventing the replication from succeeding, but only the target side catalyst is affected. Because of this, it would be possible to either create a new catalyst store or just select affected backups and "delete from disk" and allow a fresh replication of the files.  This has worked as a temporary fix.

Pete

Great to hear you finally got it fixed with the help of support.