Backup Copy Job GFS Retention/Restore Point Behavior

[coolsport00]

Good day!
I am confused how BCJobs behave with regards to GFS retention. Since I upgraded to v11 a few wks ago, I ran into storage space issues. I think I know why...not only because Qtrly GFS was removed, but also because FFwd Increm was changed (if using Synth Fulls in prev Veeam versions) to now be Fwd Increm, regardless of Full method used. As such, I have way more .vib's on disk.

Short-Term (i.e. 'Simple') Retention is pretty easy, if only using that method - a Full is created on day 1, then increm's until the config'd retention is met. On the next day, an Increm is created then the earliest Increm is merged into that first day Full, and the Full is 'moved forward' 1 day. All good there.

The confusion is when incorporating GFS. Instead of going on and on about how I think restore points are created, can someone tell me how Veeam behaves when using GFS in BCJobs? I will say this to help explain the source of my confusion... I thought the Short-Term process still happened, but instead of FFwd merges, a Full (Synth or Act) would be created, then Increm's following it, until the ST Retention is reached, at which point the previous chain would be removed. Depending on GFS > Wkly, Mthly, Yrly configs, the previous chain I think would get merged into a GFS Full, then deleted; or, an Active Full would get created, then after subsequent Increm's to meet the ST Retention, the previous chain would be deleted once that's met. That doesn't seem to be the case though. I think increments get created until a GFS option is reached. For ex, if I have ST Ret = 3; GFS Ret - Wkly = 0; Mthly = 2; Yrly = 0; I would have 1 Full (first job run), then 29-30 Increm's until I reached my first Mthly GFS sched. That causes a lotta space issues there. You're basically forcing customers to configure a Wkly. Or, if only wanting Yrly, forcing customers to configure Mthly's. Anyway, can someone clear up my confusion?...Maybe a PM, or long-time support gurus?

Thanks in advance!

[foggy]

Hi Shane, there's no merge when GFS is enabled in v11. Have you reviewed the corresponding user guide section? The algorithm is essentially the same as in primary backup jobs.

[coolsport00]

Yessir...it's incomplete.

[coolsport00]

Can you provide an example 'foggy'? For example, suppose I have Short-Terms = 3; Wkly = 0; and Mthly = 1. Was I correct at the end of my initial post? I would have just 1 Full and a full month of Increments until the day the Mthly Full gets created? After the Mthly Full, what happens to the previous '30' Increments? Do they stay until there's at least 3 the following month to meet the Short-Term Ret?

Thanks.

[Natalia Lupacheva]

Hi Shane,

Just to add, there's an explanation why the backup chain was switched from forever forward incremental policy to forward incremental:

GFS retention policy functions in combination with short-term retention policy. After you enable the GFS retention, the backup chain switches from the forever-forward incremental policy to forward incremental policy. Thus, the increments are no longer merged to the full backup file.

If you enable only yearly full backups without monthly and weekly backups, this can result in a large number of increments in a backup chain. To avoid this, it is recommended to enable an additional weekly GFS cycle. Weekly GFS cycle will update the backup chain every week which will allow to remove excessive increment files.

Thanks!

[coolsport00]

Hi Natalia -
Yep...read that. Read the whole Guide. Nothing in it explains, not in great detail so I can understand, how GFS retention works *explicitly*. Appreciate the response.

Cheers!

[foggy]

Can you provide an example 'foggy'? For example, suppose I have Short-Terms = 3; Wkly = 0; and Mthly = 1. Was I correct at the end of my initial post? I would have just 1 Full and a full month of Increments until the day the Mthly Full gets created? After the Mthly Full, what happens to the previous '30' Increments? Do they stay until there's at least 3 the following month to meet the Short-Term Ret?

Yes, your understanding is correct here.

[coolsport00]

Thanks foggy -
So, after 3 increments in the subsequent month, all the previous Increments get deleted, as well as the Full if the Full isn't part of the GFS somehow...correct?

So, I think I'm now not confused But, I still don't understand the logic of doing it this way when in combination with Short-Term. The Short-Term should take "precedence" and do its cycle...continuing to "move forward" after the retention is reached for FWD Increm (not FFwd). So yes...there would be at most 2 chains on the Repo, but would then be deleted when the config'd Retention is reached. It just seems 'cleaner' that way, no? And, the logic for Fwd Increm is retained that way IMO, as it's described in how it works in the Guide. Further thoughts? And again...I really appreciate all the responses. Hope I didn't give you all a headache

[foggy]

So, after 3 increments in the subsequent month, all the previous Increments get deleted, as well as the Full if the Full isn't part of the GFS somehow...correct?

That's correct.

[coolsport00]

Ok, thanks Alexander.