Feature Request: ReFS with SOBR avoid next extent

[eduzimrs]

Hi Guys,

We're using ReFS with SOBR in many customers and quite often we see:
"Parcial fast cloning"
at the job logs, despite the Data Locality is set to SOBR we are seeing the that this is not the exactly behavior we expect, quite often we see the next chain being written to another extent even though having plenty of free space in both extents, turn out that it mess up with fast cloning capability, because the first VBK is in another path.

Another situation i'd like to address is when we do not have free space at one extent, that's where i'd like to suggest the feature or some check box in order to generate an error to avoid veeam write the next chain to the extent which has free space.

Support case id #04181495 where we are investigating this behavior.

[HannesK]

Hello,
I just checked the case and you seem to have free space on the wrong extents.

There are some reg keys to influence placement, but they will not help without free space on the right extent. Free space must exist before backup starts on the extent where the backup chain exists.

Customers have backup software to be able to restore. Backup is a requirement to be able to restore. So we rate "inefficient backup" higher than "no backup". Creating an error and leaving a user with no backup would be more dangerous than writing to a "wrong" extent.

We generate warnings on low disk space. That should be enough to fix the issue before a backup does "unexpected" placement: https://helpcenter.veeam.com/docs/backu ... ml?ver=100

Best regards,
Hannes

[eduzimrs]

I see your point about doing the backup instead of none, but in this case i've mentioned, the vbk is about 4TB, what i'd like to avoid is to create a new 4TB vbk rather than the small synthetic vbk in the same extent.

In this case it took about 7 hours to complete the "partial fast clone" merge process, which in turn can led me to some uncomfortable situations, like:

- Put extra IO on the repository where other jobs are written to;
- In case i need a restore, it would not be available during the transformation process;
- Customers complaining about miss-sizing of repository capacity due to this "unplanned extra data".

That's why i suggest a kind of checkbox or something to avoid this potential situation when combined to the fast cloning capabilities.

I can definitely tell that this is some kind of feature many Veeam admins will enjoy, i'm part of Veeam User Group in Brazil and we discuss a lot about features, and this one in particular would do help improve the experience with Veeam.

Thanks Hannes, really appreciate your time answering us.
Best regards,
Eduardo

[benthomas]

I have to agree with @eduzimrs on this, having experienced the same issue, and in some cases, there is enough space for a ReFS 'enhanced' Synthetic full, but because there isn't enough for a "fat" full, it will offload to another SOBR extent, which in turn causes other jobs to have insufficient capacity and write to additional SOBR extents, and so forth with the domino effect actually causing more failures and excessive space usage than it tried to avoid.
When if I could 'force' it to attempt to create a synthetic full on the same extent that the rest of the chain exists on, then it would not only most likely succeed, but also avoid affecting other backups on other extents. If there turns out really not to be enough space for the synthetic, then that job fails, sure, but only that job is impacted, not all the other jobs on the other repos.

Yes I understand that the best thing to do is either expand the existing SOBR extents or add another SOBR extent to spread the load, but this isn't always possible with customers.

[stfconsulting]

I have hit this also and it ends up creating a messy situation where a repository can run out of space completely. Backing out of the space problem can be pretty complicated because we can't always just add hardware / space to make the backup viable again. I understand the concept of doing the backup vs not doing the backup however whats the difference? Eventually all backups will fail because we will have zero space to operate. In my case I have hit this more because of issues with REFS (performance) not so much available space. Hopefully the latest March hotfix will make this go away.

[poulpreben]

I always find myself tuning SOBR to reserving only 1% of the original VM size instead of the default 50%. Just like OP I would prefer a failed backup over losing block cloning any day.

The FR that makes sense IMO is to enhance the reservation logic to detecting the availability of fast clone within the target extent. When it is detected, it could make reservations as if it was an incremental backup. I guess it could actually even just disable reservation logic entirely for synthetic fulls since the changes have already been written to the extent.

[Gostev]

Yes, space reservation logic for synthetic fulls is something we're looking to enhance for ReFS/XFS extents ASAP.

[eduzimrs]

That's good news @Gostev, we look forward to have this feature.
Thanks you all guys.

[theviking84]

Is there any update on this? Did anything get improved in v11? Or if not is there a time line?

I feel like making multiple sobrs each with its own s3 bucket is the only way around this problem for now for me, so that there is no choice of where to put the next backup. I still benefit as I mainly care about the object storage extension part when talking about sobrs.

[Gostev]

Yes, this is addressed in v11.