OADP/Velero backups and also restores the following OVN-K and multus Pod annotations by default:

  "k8s.ovn.org/pod-networks": "{\"default\":{\"ip_addresses\":[\"10.129.2.14/23\"],\"mac_address\":\"0a:58:0a:81:02:0e\",\"gateway_ips\":[\"10.129.2.1\"],\"routes\":[{\"dest\":\"10.128.0.0/14\",\"nextHop\":\"10.129.2.1\"},{\"dest\":\"172.30.0.0/16\",\"nextHop\":\"10.129.2.1\"},{\"dest\":\"169.254.0.5/32\",\"nextHop\":\"10.129.2.1\"},{\"dest\":\"100.64.0.0/16\",\"nextHop\":\"10.129.2.1\"}],\"ip_address\":\"10.129.2.14/23\",\"gateway_ip\":\"10.129.2.1\",\"role\":\"primary\"}}",
  "k8s.v1.cni.cncf.io/network-status": "[{\n    \"name\": \"ovn-kubernetes\",\n    \"interface\": \"eth0\",\n    \"ips\": [\n        \"10.129.2.14\"\n    ],\n    \"mac\": \"0a:58:0a:81:02:0e\",\n    \"default\": true,\n    \"dns\": {}\n}]",
 

These annotations can't be removed from a running pod and can't be restored with their previous values during the restore, as they need to be injected by the OCP network CNI.

In most scenarios, if pods belong to deployments, replicasets... this could be workarounded by scaling down and up those pods on the restored site, and new pods will be created with the right annotations. Another workaround can be excluding pods (and keep deployment, rs...) from the restore. 

Unfortunately, with the above workaround, there are still some remaining scenarios (for example, when postHooks are required during the restore phase) that require the new restored pod to be created with the expected (and not the restored) annotations. 

So it would be beneficial for the OADP integration with OVN-K, Multus, and OCP that those annotations could be excluded from backups.