Feature Request/ExaGrid - Allow chains on different SOBR extents

[ChuckS42]

ExaGrid is a fine deduplicating storage platform. Good integration with Veeam. One aspect of using a deduplicating storage device in Veeam is that Veeam will keep all backup chains of a particular backup on one SOBR extent (data locality). This is fine, except it makes it very painful to balance the load between SOBR extents. I end up with one extent nearly full all the time, and others with lots of free space. The only way around this is to Seal a full extent, which will force jobs to start a new chain on other extents. This, too, is fine, except that's an all-or-nothing approach, moving the problem elsewhere. What I would like to see is the ability to add an exception to the chain locality rule for ExaGrid devices, allowing the backup job to evaluate the best SOBR extent to use when a Full backup is on the schedule. I've discussed this concern with ExaGrid, and they agree, saying the solution lies with Veeam.

Make sense?

[Gostev]

It does, however one question remains: what is your reason for "balancing the load between SOBR extents" in the first place? As if these extent were... trees in your garden why do you want to have them perfectly level, even at a huge expense to the dedupe ratio caused by new fulls created on non-home extents? And if not perfectly level, then what is the threshold of making a sacrifice to the Gods of dedupe?

Random thought inspired by you describing your pain: welcome to the world of legacy storage capacity management! This is one of the reasons why object storage is the future also on-prem! But of course, this transformation will not happen overnight and your ExaGrid will likely be out of support by then anyway and until then, we need to make sure you can keep using whatever storage you have in place today productively!

[ChuckS42]

ExaGrids have global dedupe these days, so I wouldn't expect any losses there. As for object storage... well, that's a subject for a future time. (For us, at least.)

[foggy]

Hi Chuck, this is actually exactly what we did in v11 - specifically for ExaGrid, we disabled the logic that ensures that the full backup is placed to the same extent where the previous full backup for the same chain is stored. This was done per user requests similar to yours, where ExaGrid global deduplication allows for placing fulls on different extents without affecting dedupe rate.

[ChuckS42]

Perfect! Can I have v11 now? :p

[veremin]

You have to wait a bit - we're expecting an RTM build in the next few days and GA few weeks after it. Thanks!