Backup copy jobs GFS policy

[perjonsson1960]

Folks,

I am worried that there is something that I have misunderstood regarding backup copies, and that we have lost archive data...
I have created a backup copy job for our two physical Exchange servers.
The job ran for the first time on Tuesday June 19th. The properties for the job is:

Keep 7 restore points, which is the default, so I went with that.
I have checked "Keep the following restore points for archival purposes".
Weekly backups: 4
Monthly backups: 12
Yearly backups: 1
Schedule: Weekly on Sunday, monthly on first Sunday of the month, yearly on Jan. 1st.

Today it is June 30th (Saturday), and when I look at the backup copy properties on disk, I have one full backup file dated June 23rd, which is marked with "R" in the Retention column, and then I have six incremental files. Shouldn't there be a weekly full backup, marked "W", created on June 24th (Sunday) left on disk? Or is it created later somehow? I am so worried that I have lost archive data... My boss won't be happy...

Sincerely,
Per Jonsson
Sweden

[tsightler]

I would expect the weekly backup to be created tomorrow. Effectively, the weekly backup is the tail of the 7 day retention. Since right now this is still June 23rd, there's no reason to create it (June 24th is still covered by an incremental in the recent chain). However, once the tail of the recent chain is the 24th, that VBK will be sealed, tagged with a "W" (or "M" or "Y" as appropriate) and a new "R" VBK will be generated that will be used for the 7 day retention going forward.

[perjonsson1960]

Oh, I see! I am beginning to understand how it works now!
Thanks!

[csydas]

If it helps, the biggest thing that helped me understand Backup Copy was that it's basically designed with WAN in mind, so everything is done to reduce the amount of data going between the two repositories. I couldn't understand for the longest time why a Full wasn't made on my GFS day and what the hell was the logic of marking an increment for a GFS point, blah blah blah. But then it clicked with me: if we made a full with today's data, we'd have to move a lot more data over WAN, whereas if we just wait and made todays "full" later with a synthetic, we could do it with just an incremental.

Once our team came to that revelation, we basically pivoted on Backup Copy from being a stupid design to making a ton of sense. For our on-site backup copy to a drive we airgap after each run, we just do the read full from source to have more predictable points.