Case #07046684 multiple jobs unexpectedly unable to meet data placement policy

[HiHoItsOffToWorkWeGo]

The SOBO is configured for Data Locality, it is the target of all backup jobs.
If one extent (the one containing all files for a specific backup job) of this SOBO should unexpectedly be offline when the backup job runs, the new .VIB file will be placed on another extent. (because strict mode was not enabled at the time)
To restore data locality (and ensure subsequent backups continue using the original extent), is it sufficient to move the .VIB file back to the correct extent, then perform a repository re-scan?
If not, what other steps need to be taken?
If nothing is done, will the next synthetic full use the original extent, or the extent where the newest .VIB file is located?
What effect would enabling "Strict Mode" for Data Locality in this scenario?
I imagine had it been enabled beforehand, this problem would not have started.
Will enabling it now make any difference to the extent selection of the "do nothing" outcome?

[tyler.jurgens]

If you have configured your SOBR to "Perform full backup when the required extent is offline" you will get a new VBK file on another extent if extent A is offline. If you do not have that set, the job will fail.

Stict placement policy doesn't matter when an extent is offline. It will come into play when an extent is full. Eg: If extent A contains the current backup chain and extent A is full, the next incremental backup will be created on extent B. With strict placement policy enabled, the job would fail instead. If you want to restore data locality when strict placement is not enabled and extent A is not offline, you must first clear enough space on extent A, then migrate any vib files to extent A and rescan the SOBR.