it is possible that a volume restored had its data written to by volsync via a different node than the in node the restore workload pod ended up scheduled to.

If accessMode of PVC is ReadWriteOnce then it can cause data path read access issues.

ReadWriteOnce
the volume can be mounted as read-write by a single node. ReadWriteOnce access mode still can allow multiple pods to access the volume when the pods are running on the same node.

Fix strategies (pick one?):

• Use ReadWriteMany when building replicationDestionation blocked by OADP-988
  • Need to document this so users are aware.
• Prioritize pod restore before pvc so volsync AffinityFromVolume can work
  • we may need some kind of pre-hook or to modify workload pod's container to wait for direct copy to finish before starting workload.
• Set pod affinity on restored pod if it had volumes moved by data mover so it gets restored to the same node that volsync pod used to write data to the pvc.

I have a feeling this is blocking OADP-844

Issue for making restored PVC have the same access mode as backup is broken into issue OADP-988.

This issue only cover making RWO PVCs work with intended workload.