GFS Retention Policy

[foggy]

Harvey is correct, GFS points start to be created when the regular chain reaches retention (actually, even more, when the full in the regular chain reaches the day specified in GFS schedule after the chain itself reaches retention).

Then, if you reduce the number of restore points in the regular chain, it will just shorten the chain, the oldest 50 restore points will be merged into the full backup. This will not trigger any in-between GFS points creation, they will continue to be created according to the specified schedule, so the next GFS point will be created when regular full will reach the specified day and the corresponding VMs state will be offloaded as GFS point. Points that would be created if the number was kept intact, will be skipped.

[Zach123]

Hi

Thanks for confirming that.

We really want to keep the monthly GFS restore point and do not want them to be skipped as a result of shortening the regular restore point count. What are the options I have,

I am thinking of

a) Reducing the count of regular restore points in phases (Let's say, from 100 to 90, then to 60 and so on). Would that not allow the GFS restore point to be created which would have been missed If I drop it directly from 100 to 50.

Or

b) Secondly, similar to how the state of a single VM can be exported for any given point of time( as mentioned in the below link), can we not do that for the whole instead. Allowing us to create the GFS restore point manually.
https://helpcenter.veeam.com/docs/agent ... tml?ver=30

Actually we are struggling with our backup copy job to complete on time. After working with iLand and Veeam support ( case 03636183), they suggested splitting the backup copy job but that did not help us in any way. Moreover, our cloud repository is getting full. Cloud vendor has already mentioned that there are no issues with there backup repository.

The merge operation is taking a really long time, so is the merge operation. I guess it could be because of long backup chain.

"https://i.imgur.com/MyjN9jY.png"

[foggy]

In case of a), if you do this carefully not skipping the days GFS points are scheduled at, this will help.

For b), you can do export for all the VMs in the particular restore point, a separate full backup file will be created per each VM. Keep in mind though that you would need to take care of their retention manually.

[Zach123]

Hi

Thanks for the information. As the first option looks a bit risky, I will go with the second option.

Do I really have to take care of there retention manually, even if I set "Delete exported backup file automatically".

[foggy]

Right, if you select this check box, backups will be retained according to the configured value. What I meant was the fact that each exported backup is a standalone .vbk file, which is not a part of the chain, so it is not subjected to the job retention settings. Sorry for the confusion.

[sosborne]

I have backup jobs scheduled to run a full (either synthetic or active) on Saturday and then increments on weekdays. I then have backup copy jobs with GFS retention on Weekly, Monthly and Yearly. However, the backup copy Monthly schedule is the 1st and the 1st happens to be Sunday this month, so what will happen? Will a copy be taken on the Sunday as a copy of the previous day even though no backup is actually happening, or will the Monday copy be given the archival flag which will then in theory have the Monday increment? I have the forward lookup mechanism set to give me in theory better control over timing the Restore Point for end of month purposes but there is always an exception.

I avoided doing a backup each day as it wasn't necessary and this way seemed to be more predictable in terms of restore points and timing of fulls across the month.

Thanks in advance.

[foggy]

Hi Simon, GFS restore point will be offloaded when the full backup in the regular backup copy job chain will reach the day it is scheduled at - i.e. 1st day of the month, Sunday in this case.

[sosborne]

Hi Foggy, I don't 100% understand. Normally the backup job doesn't run on Sunday so normally no copy. So are you saying that in my case the Saturday full would run on the Sunday, or that the Saturday full will be marked with an M flag?

[foggy]

Backup copy job doesn't copy files but builds restore points synthetically. The restore point created on Sunday will be put aside and marked as monthly when it becomes a full restore point in the regular backup copy chain (i.e. the day after the Sunday increment is merged into the full). I recommend reviewing this thread and the corresponding user guide section for a better understanding of how GFS retention works for backup copy jobs.

[sosborne]

There was no Backup Copy made on Sunday for the 4 jobs scheduled on 1st (there was no Backup). For the two jobs scheduled on the last day (the Saturday) they were marked W and M as expected (the full backup is taken this day). Just after midnight on Monday morning the Backup Copy came back with a 0.0B copy report as it usually does. No subsequent job has caused an M flag to be added.

I raised a job for this Case 04037106.

My concern is primarily getting an M flag on the restore point.

[sosborne]

If it wasn't clear my previous post the schedule I am referring too is the GFS archive schedule on 1st (and last day). Otherwise the backup job runs full on Saturday and increment M-F.

[foggy]

Then the chance is the regular chain retention is not reached yet. What is it set for and how many restore points do you have in the chain?

[sosborne]

Regular is 5 RP's, Weekly 3, Monthly 24 (1 day of Month), Yearly 7. And it is currently set to Active for Archival (and has been for sometime).

[sosborne]

There are currently 3 weeklys and 3 increments.

The copy jobs with the last day of the month have a WM marked on the 29th full.

[foggy]

Looks unexpected as you should have 4 increments in the chain to meet the 5 RP's setting. And since you have enabled the 'Read from source..." setting, then the weekly full should be uploaded right on Sunday, as configured. Please continue looking closer to this with our engineer.

[sosborne]

The chain I reported to you is the current state. At the time of the backup a full had been run the day before on the Saturday (for the weekly).

I have been working with him but I am now stuck. As I see it my only option for March is an export of Saturdays Full. And then a rethink of the scheduling (possibly even changing full day when it is the 1st on a Sunday). Any suggestions as the following doesn't meet our requirements which are - a monthly restore point on a given day last/first day of month, a weekly full, and preferably Active fulls on the monthly RP as it feels safer given the duration involved (on the monthly/yearly)?

This is all very frustrating as I was recommended backup copy to fix an old issue. And I had identified that the current scheduling may cause a problem ahead of time.

Case # 04037106

Unfortunately, there is no way to re-assign GFS flag without ruining the retention. If we try to do it via DB edit, we will end up with two monthly backups created within one month. The next retention pass will simply delete the full from 1 Feb out of schedule. We can create March backup by re-scheduling monthly backup creation day. Set it to 5th for instance, to create the full backup tomorrow, and then revert it back.

We have checked the behavior and it meets the logic of Active Full GFS backups. Active GFS cannot "look into the past". That is, if we detected that the last point has already been copied within weekly backup, we won't copy it again and we will skip the run. If the job is left as is, you will face the same situation in October. Synthetic GFS works differently as it doesn't create GFS points exactly on the specified day, but it waits for regular full backup to reach the GFS day and assigns GFS flag to it, copying the data from older restore points if necessary.

To avoid such situation in future, we might need to reconsider GFS policy by joining weekly, monthly and yearly GFS days. E. g. if you set monthly GFS for the first Saturday of the month, it will always match with the weekly GFS. Only one backup (with both weekly and monthly flags) will be created. It will also help to save disk space.

[foggy]

Hi Simon, I can see that you've switched to synthetic GFS and are evaluating the consequences at the moment. I believe this will meet your scheduling requirements and as for the safety, you can rely on the health check technology to ensure consistency of the backup files.