Comprehensive data protection for all workloads
Post Reply
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: GFS Retention Policy

Post by foggy » 1 person likes this post

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
Enthusiast
Posts: 40
Liked: 3 times
Joined: Jun 04, 2019 12:36 am
Full Name: zaki khan
Contact:

Re: GFS Retention Policy

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: GFS Retention Policy

Post by 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
Enthusiast
Posts: 40
Liked: 3 times
Joined: Jun 04, 2019 12:36 am
Full Name: zaki khan
Contact:

Re: GFS Retention Policy

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: GFS Retention Policy

Post by 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
Enthusiast
Posts: 66
Liked: 5 times
Joined: Jan 30, 2018 12:06 pm
Full Name: Simon Osborne
Contact:

[MERGED] Veeam 9.5 Backup Copy Retention Policy

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Veeam 9.5 Backup Copy Retention Policy

Post by foggy » 1 person likes this post

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
Enthusiast
Posts: 66
Liked: 5 times
Joined: Jan 30, 2018 12:06 pm
Full Name: Simon Osborne
Contact:

Re: GFS Retention Policy

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: GFS Retention Policy

Post by foggy » 1 person likes this post

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
Enthusiast
Posts: 66
Liked: 5 times
Joined: Jan 30, 2018 12:06 pm
Full Name: Simon Osborne
Contact:

Re: GFS Retention Policy

Post by 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
Enthusiast
Posts: 66
Liked: 5 times
Joined: Jan 30, 2018 12:06 pm
Full Name: Simon Osborne
Contact:

Re: GFS Retention Policy

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: GFS Retention Policy

Post by 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
Enthusiast
Posts: 66
Liked: 5 times
Joined: Jan 30, 2018 12:06 pm
Full Name: Simon Osborne
Contact:

Re: GFS Retention Policy

Post by 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
Enthusiast
Posts: 66
Liked: 5 times
Joined: Jan 30, 2018 12:06 pm
Full Name: Simon Osborne
Contact:

Re: GFS Retention Policy

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: GFS Retention Policy

Post by 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
Enthusiast
Posts: 66
Liked: 5 times
Joined: Jan 30, 2018 12:06 pm
Full Name: Simon Osborne
Contact:

Re: GFS Retention Policy

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: GFS Retention Policy

Post by 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.
Post Reply

Who is online

Users browsing this forum: justin.hendren and 172 guests