We have a Veeam issue with rebalancing a Scale-Out Backup Repository with hardened (immutable) extents.
Our setup:
Veeam Backup & Replication v12 (SOBR, Data Locality mode)
12 Linux hardened extents with immutability enabled, and backup jobs with long GFS points enabled.
Several extents are nearly full; others (newer) have plenty of free space.
Problem:
We need to rebalance backup data to relieve the full extents.
“Rebalance” does not move immutable restore points, so little or no data is moved in our case.
“Evacuate Backups” (by putting an extent in Maintenance Mode) copies immutable chains instead of moving them, and it only helps if the extent is fully evacuated. Partial evacuation is not possible, and in this case, we do not want to fully empty the extent.
I request that Veeam find a solution for this.
What options do we see, at the current moment?
Move VMs from within a job to a new job. The new job will write data to the extents with the most free space. The old data will remain on the original extent, and it will not be possible to delete it from Veeam because it is immutable due to the GFS retention (e.g., 1 year). We would then have to manually remove the immutable flag on the files, which is manual and risky work, and not an easy way to rebalance data. But if the repo is Veeam LHR, this is not an option.
- Veeam does not have a tool or script to do this.
Our setup:
Veeam Backup & Replication v12 (SOBR, Data Locality mode)
12 Linux hardened extents with immutability enabled, and backup jobs with long GFS points enabled.
Several extents are nearly full; others (newer) have plenty of free space.
Problem:
We need to rebalance backup data to relieve the full extents.
“Rebalance” does not move immutable restore points, so little or no data is moved in our case.
“Evacuate Backups” (by putting an extent in Maintenance Mode) copies immutable chains instead of moving them, and it only helps if the extent is fully evacuated. Partial evacuation is not possible, and in this case, we do not want to fully empty the extent.
I request that Veeam find a solution for this.
What options do we see, at the current moment?
Move VMs from within a job to a new job. The new job will write data to the extents with the most free space. The old data will remain on the original extent, and it will not be possible to delete it from Veeam because it is immutable due to the GFS retention (e.g., 1 year). We would then have to manually remove the immutable flag on the files, which is manual and risky work, and not an easy way to rebalance data. But if the repo is Veeam LHR, this is not an option.
- Veeam does not have a tool or script to do this.
Statistics: Posted by mv@cloudio.dk — Aug 20, 2025 11:34 am
