Skip to main content
  • EN

As some of you might already know, with V11 the creation process of GFS points within backup copy jobs will be completely renewed.

As I understood it, the new method will be exactily the same then, as it is already for primary backups.

So instead of forever forward merging and meanwhile somehow dropping a GFS point, we will see a forward chain with synthetic fulls. The latter will then be flagged with the GFS flags.

This will in my opinion be remarkable for two reasons:

  1. We’ve seen problems with GFS backup copy jobs not adhering to the SOBR placement policy. During one support case I was driving we narrowed it down to the legacy way GFS points are generated in these jobs. SOBR placement policy disregarded for GFS - Veeam R&D Forums. So this might be solved then, which is great news.
  2. On the other hand this is also good news for the usage of dedupe appliances. Especially the ones with a landing zone like ExaGrid. Those currently suffer from the merging processes occuring in backup copies and therefore we always had to use the flag to transport the GFS points as active fulls over and over again: “read the entire backup from source instead of synthesizing it from increments”. This sometimes is not optimal because of the large transfers included. Especially if the secondary backup is behind a WAN for 3-2-1 reasons. So with V11 we might be able to switch to a synthetic process here. I will follow-up on this as we have quite some ExaGrids in the field.

Any thoughts on that?

I haven't heard of this before but looking forward to see how this will change the behavior of backup copy jobs.

Will exiting jobs automatically move to the new processing or will this only affect new jobs?

Thanks for sharing, was a good read and exciting to see.

Here is the official Veeam Blog Post about it:

https://www.veeam.com/blog/new-gfs-retention-v11.html

In short: 

  • Copy GFS retentions is replaced by a “classical” forward incremental with periodic synthetic full.
  • No quarterly backups any more.
  • New behavior also after upgrading to v11.

Important:

  • Check GFS retention before you upgrade.
  • Think about adding additional weekly fulls.

Worst case scenario:

  • 10 restore points
  • 1 yearly
  • v10:
    • 2 fulls and 9 increments
  • v11:
    • 2 fulls and 374 increments

@vNote42 It looks like the blog post has been taken offline, but I could read it via mail.

To sum up; as long as you have a complete GFS schema in place (weekly, monthly, yearly) you shouldn’t get any problems. If you leave out the weekly restore points you’ll end up with a high amount of incremental restore points.

Can't edit my last post; here's why the blog post has been taken offline.

https://www.reddit.com/r/Veeam/comments/lihrmj/comment/gn45c8s

Can't edit my last post; here's why the blog post has been taken offline.

https://www.reddit.com/r/Veeam/comments/lihrmj/comment/gn45c8s

Thanks for sharing this. It’s worth highlighting @Gostev’s comment regarding some of the positives regarding this change. A key one being support for immutability.

Can't edit my last post; here's why the blog post has been taken offline.

https://www.reddit.com/r/Veeam/comments/lihrmj/comment/gn45c8s

@regnor Thanks for sharing! It seems, post bypassed quality management. I posted the link about half an hour after I saw the feed.

Can't edit my last post; here's why the blog post has been taken offline.

https://www.reddit.com/r/Veeam/comments/lihrmj/comment/gn45c8s

Thanks for sharing this. It’s worth highlighting @Gostev’s comment regarding some of the positives regarding this change. A key one being support for immutability.

I didn’t think about that...but of course it makes sense as merging won’t be possible on an immutable repository.

Here is the official Veeam Blog Post about it:

https://www.veeam.com/blog/new-gfs-retention-v11.html

In short:

[...]

 

The blog post is back online.

Also and if I understand this right, now the GFS restore point will be created on the day itself, instead of it being created when the day that was targeted drops out of retention. If this is the case this will be much easier to explain to customers. I remember people asking “so my Monthly will take place on the 1st right?”… “well no it will be created when the 1st leaves your retention” 🙂 That was not always a fun conversation since you would then have to explain about vib ‘s being merged into vbks etc. It got complicated to say the least. 

Also and if I understand this right, now the GFS restore point will be created on the day itself, instead of it being created when the day that was targeted drops out of retention. If this is the case this will be much easier to explain to customers. I remember people asking “so my Monthly will take place on the 1st right?”… “well no it will be created when the 1st leaves your retention” 🙂 That was not always a fun conversation since you would then have to explain about vib ‘s being merged into vbks etc. It got complicated to say the least. 

Definitely agree with this for sure. Logic now will be much better for clients as well as being able to implement it.

Comment


Terms & Conditions