Understanding GFS usage with capacity tier

[GauravT]

Hi Guys,

Current capacity: 15 TB
Job retention: 30 restore points, incremental.
Schedule: 1 backup daily
Tape Out Job: 1st of every month, manual

Requirement:
In addition to the regular backup job:
Monthly backups - 1 per month, 12 total
Yearly backups - 1 per year, 7 total
Tape Out Job: 1st of every month

The best option is GFS here, but I am not sure I understand its workings correctly.

For monthly backup - it will synthesize a full backup at the end of the month and flag it (30 retention points will be available as per current backup job configuration). It will be stored on the local repo. So every month we'll get a monthly restore point. At the end of the month I'll have 1 .vbk file in the repository. At the end of the year I'll have 12 .vbk files in the repository. In the next cycle starting the next year the previous chain will start to get pruned? As new .vbk keeps being created the previous .vbk will be deleted. 12 .vbk remain at any given time.

For yearly backup - it will synthesize a full backup from the 12 monthly flagged GFS backups? or will it do an active full backup? at the end of the year I'll have 1 .vbk in the repository. At the end of 7 years I will have 7 .vbk files.

And I'll have 30 restore points from the local backup job in the repository.

The storage capacity is reaching exhaustion. Disk shelf is entirely utilized. Can't buy additional shelf this year. The plan is to add capacity tier and push backup older than 30 days to the cloud. How to configure the gfs to make sure the local repository (performance tier) always has enough space to accommodate the new backups.

1. Have operational window on capacity tier to 30 days. Copy and Move mode.
2. Create weekly synthetics, so the inactive chain or inactive vbk/vib can start to move to the cloud after 30 days. Incase of copy mode, the data out of operational window will be pruned from local repository (performance tier)
3. Will the monthly created gfs .vbk be moved to the cloud immediately post 30 days?
4. Will the yearly gfs be able to create the yearly full backup if the 11 prior monthly gfs backup are on the capacity tier and the 12th on the prem? or will all monthly gfs remain on the local repo till the yearly gfs is created?
5. Should the operational windows be set differently if I need the tape out jobs every 1st of month? because data blocks older than 30 days will start to be pruned on the local repository (performance tier.)

Kindly help understand. The ideal scenario is to have 30 restore points on the local repository (from normal backup job). 1 monthly gfs for each month(12 per year), 1 yearly gfs for 7 years. (can be moved to capacity tier as soon as feasible).

[HannesK]

Hello,
the easiest way is to imagine capacity usage in object storage similar like REFS / XFS bloc cloning. I mentioned that in the FAQ.

At the end of the month I'll have 1 .vbk file in the repository.

actually two. the first one is still there.

The way how synthetic full works is animated in https://www.veeam.com/kb1932

3. No. Only the inactive chain can be moved (as you already mentioned)
4. yes. the yearly backup is created with the data from the "last day of the year".
5. Tape jobs write the newest backups to tape. So you can move old backups to the cloud.

If you configure GFS on the backup job, then everything would be met. If you want to move to cloud earlier, you can add weekly synthetic fulls. "move after 7 days" sounds like a good idea for your requirement.

Best regards,
Hannes

[GauravT]

Hi HannesK

Thank you so much for the prompt response.

3. No. Only the inactive chain can be moved (as you already mentioned)

The monthly created gfs will be a .vbk, won't it be moved to the capacity tier? if it is out of operational window of 30 days? if I set the window ahead to 31 or 32 days for this scenario.

Or will the monthly gfs be on prem till the chain of 12 monthly gfs is complete?

and the same for the yearly gfs. It is eligible for immediate offload once created? if it older than 30 days? it'll be a .vbk as well.

The GFS config should be:
weekly = 0
monthly = 12
yearly = 7

For monthly gfs - Since weekly gfs is disabled. A new full backup will be created on the last day of the month.

For yearly gfs - The monthly gfs is enabled, a yearly flag will be added to the 12th monthly backup.

[HannesK]

The monthly created gfs will be a .vbk, won't it be moved to the capacity tier?

the monthly (also weekly and yearly and all other VBKs) VBK will be moved if both conditions are met
1) it's part of an inactive chain. That means, another VBK was created after the monthly VBK in your situation
2) it's older than the days configured "move after X days"

[GauravT]

the monthly (also weekly and yearly and all other VBKs) VBK will be moved if both conditions are met
1) it's part of an inactive chain. That means, another VBK was created after the monthly VBK in your situation
2) it's older than the days configured "move after X days"

Alright. A monthly GFS will be a full backup (.vbk), if the weekly GFS is not enabled, and thus will be independent. If a synthetic or full backup is created after the monthly gfs is created. The monthly GFS .vbk will be moved to the capacity tier if is out of operational restore window.

Same for yearly. If a yearly GFS is created. Then a synthetic .vbk is created, lets say a week after. The yearly GFS is eligible to be moved to the capacity tier, once it is out of operational window.

I get it. Do correct me if I'm wrong.

Best Regards,
Gaurav

[HannesK]

correct. Just a note: every full backup is independent. No matter whether GFS or just "whatever VBK".

[GauravT]

Thank you for the clarity, Hannes =)