Rollback files to SOBR Capacity

[Artaheri]

We have a few jobs that are forward incremental, with synthetic fulls on a Friday night that transform previous backup chains into rollbacks.

The thinking behind this is that the transforms can run over the weekend, with the creation of a new incremental—and removal of an old—taking place nightly during the week to speed up the jobs.

These jobs point to SOBRs that contain Azure targets for capacity tier.

By doing this are we causing all of the new rollback files to be pushed to the capacity tier in full when they are created, effectively resending all of the backup data, or should the transfer be minimal because the chunks are already there?

I'm not sure if I've explained that clearly! Thanks for any thoughts.

[Mildur]

data, or should the transfer be minimal because the chunks are already there?

Only new blocks will be transferred. Blocks in the full backup, that doesn‘t have change since the last backup, will only be „referenced“ to already offloaded blocks (object).

For your answer:
It doesn‘t upload each day a new „full backup“ with it‘s entire size.

Update:

I would not use that feature:

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

For backup jobs created in Veeam Backup & Replication version prior to 11, you could enable the Transform previous backup chains into rollbacks option. Since Veeam Backup & Replication version 11, this option is deprecated. However, the transformation functionality is still working for backup jobs where the Transform previous backup chains into rollbacks option was already enabled. For more information on the transformation, see the Backup Chain Transformation section in Veeam Backup & Replication User Guide for version 10.

[Artaheri]

Thanks for the link, do you know why that feature was deprecated?

It looks like we will need to switch to forever forward in that case, and deal with the merge time each night of the full and the oldest incremental.

[Mildur]

I can share Anton Gostevs Newsletter, why that was done by veeam.
If you are redesigning your backup infrastructure, have a look at FastClone Feature. Creating a Synthetic full is spaceless and really fast. It doesn't use the entire space. No need todo forever Forward Incremental.

Veeam Community Forums Digest from May 25, 2020.

Specifically, I'm talking about the Transform previous backup chains into rollbacks option of the forward incremental backup. This option was added in the early days of Veeam to reduce the disk space usage via eliminating previous full backups by transforming them into rollbacks. So, very little difference comparing to our reverse incremental backup, except if there it is done "inline" during every backup, here this whole process happens once a week after the new scheduled full is created. And by the way, because there are multiple increments to process, on slow backup storage this process can run for a very long time, which results in a steady stream of performance-related support cases – which explains why I've been keeping a close look at its usage.

Now, in 10 years since this feature was first added, many things have changed – and particularly, we added the integration with the block cloning functionality of modern file systems (ReFS and XFS). Not only they made the transform performance issue go away by making it a metadata-only operation, but they also removed the very reason to perform the conversion of previous backup chains into rollbacks by enabling what we call "spaceless" synthetic full backups (i.e. not consuming additional disk space, by referencing existing blocks). So in theory, as more and more customers will move to using these modern file systems for their backup repositories, this option should no longer be needed.

Based on this, and because of significant QC overhead of performing the regression testing for this special type of the backup chain, we would like to start phasing this feature out gradually. My current plan is to deprecate this feature in the next major release (v11) by hiding it for all new product installations, and adding the deprecation note for any existing installations that will be upgraded to v11 in-place. And then in v12, remove this feature completely: as per our standard approach, we would simply block the upgrade to v12 until there's at least one job with this option enabled. This is the current plan, but the reason I'm sharing this here is it may change based on your feedback. So if you have use cases that will still require this option 2 years from now, please share them on the forum so we can discuss and see if there are perhaps any other way to address them, or if we must keep this option available for longer.

[Artaheri]

Thanks, that sounds really interesting, I'll look into FastClone some more and see if that's something we can implement.

[Mildur]

Your welcome.
You can read more about it here

https://helpcenter.veeam.com/docs/backu ... ml?ver=110