I looked at the velero restore code ignoring existing resources. What I noticed

• here it does check if the resource already exists https://github.com/vmware-tanzu/velero/blob/main/pkg/restore/restore.go#L1224
• then checks if the existing resource is identical with the one in the backup https://github.com/vmware-tanzu/velero/blob/main/pkg/restore/restore.go#L1244
• but then only processes and updates ServiceAccounts https://github.com/vmware-tanzu/velero/blob/main/pkg/restore/restore.go#L1246
• and ignores any other type of resource; interestingly enough, the default clause doesn't log the error so you can't see anything if you look at the restore log; we need this error message in the log so we know the resource did not get updated https://github.com/vmware-tanzu/velero/blob/main/pkg/restore/restore.go#L1274

I also noticed that although ServiceAccount objects are being updated, velero labels did not change for velero.io/backup-name= and velero.io/restore-name= ; so this is an issue that needs to be fixed too

This is a restore log where a ServiceAccount resource was updated based on the new restored version; I checked, velero.io/restore-name was not updated on this resource to match the latest restore and backup names

time="2022-01-13T23:33:35Z" level=info msg="Attempting to restore ServiceAccount: test-vb" logSource="pkg/restore/restore.go:1264" restore=openshift-adp/restore-backup-account-6
time="2022-01-13T23:33:35Z" level=info msg="ServiceAccount abc-broker/test-vb successfully updated" logSource="pkg/restore/restore.go:1313" restore=openshift-adp/restore-backup-account-6