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?
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?
Statistics: Posted by HiHoItsOffToWorkWeGo — Dec 20, 2023 11:25 pm
