from time to time I'm trying to import my backups on the object storage on a fresh veeam database to make sure everything goes well ICE. I'd choose a window where no offloads are being done so that the contents of the buckets are in a consistent state. Now sometimes the import ends with a warning and shows the following errormessage:
Violation of PRIMARY KEY constraint 'PK_Backup.Model.Points_id'. Cannot insert duplicate key in object 'dbo.Backup.Model.Points'. The duplicate key value is
What I've realized is that some of the vm's in the backup are missing, obviously it was able to import some of them but stopped when the error occured.
As mentioned, the data should be fine and the issue appears from time to time. Is that a known issue, what can be done to prevent it? What you don't wannt to have is having non-restorable data ICE...
Fabian, tbh, I just wannted to know if that issue is known and if there's a workaround. Soon v12 will appear and I guess a lot will change (no local index needed, etc.), so I didn't wannt to waste my and support's time for an issue that will only exist for some months...
Understood and I appreciate it that you don't want to waste anyone's time. But analyzing a potential bug (known or unknown) is never a waste of time, if it makes the product more stable. At least not on our site.
If we don't have a KB article on that issue, it's most likely a unknown bug or a bug which needs to be confirmed by analyzing the logs.
So please open a support case and provide us with the case number. Our support has access to the bug database and can confirm any known non-public bugs with the debug logs you provide.
If no offload or synchronization activities are running on the first backup server, you should be able to import the object storage repository on the second backup server. To confirm what might have gone wrong, you need to open a support ticket, as this way, we will have access to the required data (debug logs and infrastructure).
Ok Vladimir, seems like I haven't used a clean, fresh database but was re-using the existing database on my machine where I've (most likely) already imported the same repository in the past and then just detached and deleted it, that's why there were keys already in the database... Maybe there should be a better cleanup in the future. Dropping the whole database + let it rebuild by the restarted VeeeamBackupSvc has resolved the issue and now I was able to import all chains without any issues. I guess that's it. Thanks!
The cleanup procedure should not leave stalled entities after its run. So the situation looks unexepected.
Glad to hear that you have solved the original issue, however, if the cleanup process bisbehaves again, proceed with opening a new support ticket, as we will need fresh debug logs that capture problems with the removal procedure.