Backup Copy interval confusion (yet again)

[DanielJ]

I know this has been discussed to death, but please bear with me. I have used VBR for years and am still unsure of this.

I am trying to set up a copy job that saves GFS points only (if possible), since we want them on a dedup appliance. The daily job goes to an ordinary disk repository. I have previously used an interval that copies every day and saves as few incrementals as possible (since they are not needed), and that works, but puts unnecessary strain on the repository when merging the daily backup. I understand the "copy every" setting like this: the copy job will copy the first "uncopied" restore point it finds that is not older than the interval value, and then it will check again when the interval has passed. Correct? But I don't understand how this maps to the GFS schedule. If I want to save a monthly at the first sunday of each month, and a yearly at the first sunday of each year, how can I make the copy job run only on these days when all I can set is an interval of minutes, hours or days? Does this make it significant which day I choose to run the backup job the first time? For example: if I set the copy job interval to 30 days, then run the backup on the first sunday of the month, the copy job will find that restore point and create the monthly GFS copy. Then the backup will run each day while the copy job will wait for the interval to expire. When 30 days has passed, we are into next month and it might be tuesday. Will the copy job then create an incremental based on the last GFS point? Will it then start waiting for another 30 days, or what will happen on the first sunday of that month (when 35 days has passed since the last GFS point)? What if the first sunday falls late in the month, like on the 6th? It will then be only 28 days until the next "first sunday". Will it then create that month's GFS point on a tuesday? It would be very nice to get this sorted out.

I guess what I really wish for is a checkbox that said this:

[x] Only copy enough restore points to fulfill the GFS schedule (this will disable both the interval setting and the "points to keep" setting)

[HannesK]

Hello,

I have used VBR for years and am still unsure of this.

then I recommend not trying to learn how it works up to V10. We will simplify GFS with backup copy jobs in V11. With V11, the GFS restore points will be created on the configured day.

but puts unnecessary strain on the repository when merging the daily backup

what kind of dedup appliance do you use? DDboost / Catalyst should have no problem with the merges on be BCJ target side. If you have no integration then "read the entire restore point..." can fix that issue: https://helpcenter.veeam.com/docs/backu ... ml?ver=100

Correct?

sounds correct. I also wrote about it if you need more information https://www.veeam.com/blog/backup-copy- ... -copy.html

I skip most of the other questions now, as the blogpost I linked should clarify the idea of the backup copy job

[x] Only copy enough restore points to fulfill the GFS schedule (this will disable both the interval setting and the "points to keep" setting)

even with V11 we will engage customers to copy their backups regularly (daily). We have seen too many failed backup storages where monthly GFS restore points would be useless from a business perspective.

As for today and V11 I recommend the following setting:
- 7 restore points
- months and years GFS

trying to "optimize" with 30 days period just overcomplicates everything.

I hope that helps,
Hannes

[DanielJ]

We will simplify GFS with backup copy jobs in V11. With V11, the GFS restore points will be created on the configured day.

Sounds great!

what kind of dedup appliance do you use? DDboost / Catalyst should have no problem with the merges on be BCJ target side. If you have no integration then "read the entire restore point..." can fix that issue:

This job will go to a StoreOnce. We do use Catalyst, but it seems to be recommended to use "read entire restore point" anyway, which we have done so far on an older DataDomain. I have always tried to avoid synthetic operations where possible.

As for today and V11 I recommend the following setting:
- 7 restore points
- months and years GFS

Then we will go for that for now, since we then can be sure of getting the GFS points on the requested days.

[foggy]

I understand the "copy every" setting like this: the copy job will copy the first "uncopied" restore point it finds that is not older than the interval value, and then it will check again when the interval has passed. Correct?

Not exactly. It always copies the latest VM state available on source, not the first "uncopied" restore point. Say, if there were several restore points created on source within the copy interval back, the restore point on target will contain the VM state similar to the one stored in the latest of them.

[DanielJ]

I thought I should follow up on this now that I have used v11 for some time.

I cannot see that the changes to GFS brought by v11 was much of a simplification, rather the other way around. There is no longer a way to specify the day of each month to create a monthly GFS point. Instead it depends on promoting a weekly point, which can be created on a specified weekday. I found out that if weekly is not configured, and the "first week" is selected as monthly, it will be created on the first day of the month, which is lucky (for me) because that is what I happen to want most of the times. This could be clarified in the GUI. But it would be better to be able to specify the date.

Are any more changes to GFS planned for v12? Like the possibility of doing away with incrementals (in a copy job or even in an ordinary job) and only create GFS fulls on specified days (which would allow monthly GFS without weekly on a StoreOnce, with its severely restricted number of incrementals - obviously "read restore point from source" would be needed for a copy job, which would be fine). And be able to actually specify those days. Maybe show a calendar where I could mark on which days to create archive fulls, and how long to keep them, and if it should be recurring or not.

[HannesK]

yes, we plan improvements, but I cannot share any timeline.

[skrause]

Why did Veeam remove the "read the entire restore point from source" option in v11?

This was basically the only way to have large backup copy jobs be able to work properly when targeting deduplicated volumes on the target side as it gets rid of the transform operations.

[Gostev]

It should still be there in the periodic copy mode:
https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[DustinW81]

Question, can you use GFS to move Monthly & Yearly Jobs to a separate repository?
I'm trying find the best way to save my Monthly and Yearly jobs to a separate repository, while keeping my weekly's on a small sized repository.

[Gostev]

Yes, this is what Capacity Tier of a scale-out backup repository is designed to do with its Move policy.

[skrause]

It should still be there in the periodic copy mode:
https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Ahh thanks. I guess I assumed it would be greyed out in the UI if unavailable in one mode vs the other.

Oh I see it is only for the GFS copies and not for the individual restore points anymore.

So there is no way to avoid the synthetic operations when your target is deduplicated storage any more. Good to know.

[HannesK]

uhm no... it's still possible by enabling GFS (weekly recommended) in the periodic mode. And the setting always only existed for GFS

[veremin]

Oh I see it is only for the GFS copies and not for the individual restore points anymore.

Not sure whether I follow you on that - "Read the entire restore point from source" has always referred to GFS points only. Thanks!

[skrause]

I guess my retention settings on my jobs must have been setup in such a way that it behaved like it was copying every point and never making synthetics then. Probably because it was keeping the weekly fulls?

That infrastructure that used deduplicated Windows volumes as a target has been retired for over a year so I can't go back and check.

[HannesK]

yes, "read the entire restore point" has always been the workaround to avoid synthetic fulls. It's just not available for immediate / mirror copy mode. "read the entire restore point" behaves today same like in any other version before.