We have six backup copy jobs that are failing with the following error;
Error: Violation of PRIMARY KEY constraint 'PK_Storages'. Cannot insert duplicate key in object 'dbo.Backup.Model.Storages'.
We have rescanned the repositories and reran the backup copy jobs, but still experiencing this error.
A case has been opened with Veeam support and we are anxiously awaiting their response.
Thanks
+14
Which Veeam version/build are you running?
+20
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.
+10
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.
+17
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.
+17
Great, thanks!
Veeam support is working out a fix in R&D and testing, hopefully it will be released soon.
+17
Ah, ok..nice. Thanks for the update
+20
Veeam support is working out a fix in R&D and testing, hopefully it will be released soon.
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
+20
Great to hear you finally got it fixed with the help of support.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
