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:
- 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.
- 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?