GFS tags and local storage

[ghgard]

The more I read about GFS and Performance vs Capacity tier, the more I confuse myself. Here is what I want to do.

I only want 7+/- restore points stored locally, I understand this can vary based on backup chain and timing. I'm concerned that the GFS tagged files will stay on the Perf. Tier.

Are GFS tagged files stored forever in the Perf. Tier or do they roll off based on the retention period (7 restore points) that I have set? I don't have the space to keep multiple full backups stored in the Perf. tier. Do I need to set the "Move backups as they age out of the operational restore window" for this configuration to work, or does it do this by default?

Currently I have the job configured to keep 7 restore points, synthetic fulls every Saturday and I am doing 4 weekly's, 12 monthly's and 2 yearly's. The data is copied to the cap. tier as soon as the backup occurs, but I do not have the "Move" option chosen.

Thanks,

Grant

[Mildur]

The retention policy is valid for all backup files. It doesn‘t depend on the Tier where the restore points are stored. The rentention policy from the backup job doesn‘t configure when a restore point is moved or not.

If you want to have only the last 7 days on the performance tier, you need to activate move policy, as you have already mentioned. You will always have at least 2 fulls and their incrementals on the performance tier. Only sealed backup chains can be moved.
If you configure 0, the ole chain will be moved as soon a new one is created. If you configure 7 days, then you will have 7-14 restore points on the performance tier (with weekly synthetic full).

If you use xfs or refs with FastClone as a performance tier, then the fulls would not need the entire space on the performance tier.

If you use a Linux hardened Repo, the move Policy cannot move the restorepoints away to the capacity tier, because they are immutable. Gfs restore points on linux hardened repos are immutable their entire retention period and will not be offloaded (only copy policy inside the retention period)

[ghgard]

Thanks. If I set the move to zero, how many would be stored locally?

[Mildur]

Your welcome.

- Always the active chain (1x FullBackup and all increments since the fullbackup)
- Another FullBackup (on the day, where the fullbackup is scheduled. The fullbackup from the new chain)

As soon the new fullbackup is created, the old chain can be moved.

[ghgard]

Thanks. I think I’ll try zero as I want to minimize local storage.

[Mildur]

Your welcome.

[ghgard]

I set my move days to zero and it cleaned out the local "performance" tier, but there are still a bunch of non-GFS tagged files in the Capacity tier. Do these clean out after the SOBR process runs every 4 hours? My retention is set to 7 days, with 4 weekly, 12 monthly and 2 yearly. A new weekly synthetic was created this morning and tagged as a GFS "w" file. All of the incrementals from last week are still in the capacity tier, but were removed from the performance tier. I assume those will remove from the Cap tier at some point?

After next weeks synthetic, the current "W" file on the perf tier will delete, correct?

Sorry for all the questions.

Thanks,

Grant

[ghgard]

Something I just thought of, the cap tier is an immutable bucket at Wasabi, set to 7 days immutable in veeam. This may be why some of the old incrementals are staying on the Cap. Tier? I assume they will eventually remove when the immutability expires?

Thanks again.

[Mildur]

No issues with asking questions we are here to help

Non GFS tagged GFS Restore Point could be from earlier Veeam Versions. The tagging exists since Veeam V10 for backup jobs and V11 for Backup Copy Jobs.

I assume those will remove from the Cap tier at some point?

The retention settings in the job defines, when a GFS Point in the capacity tier is deleted. If you have configured 100 monthly, then veeam will have 100 monthly gfs restore points in the capacity tier.

After next weeks synthetic, the current "W" file on the perf tier will delete, correct?

Yes, that should be the case. It will exist only in the capacity tier with move setting „0“ after the next weekly full.

[Mildur]

Something I just thought of, the cap tier is an immutable bucket at Wasabi, set to 7 days immutable in veeam. This may be why some of the old incrementals are staying on the Cap. Tier? I assume they will eventually remove when the immutability expires?

Thanks again.

How old are this restore points?
Are they outside of your configured retention?

Currently I have the job configured to keep 7 restore points, synthetic fulls every Saturday and I am doing 4 weekly's, 12 monthly's and 2 yearly's

With that, you will have 7-14 restore points in the capacity tier and the 4 weekly, 12 monthlys and 2 yearly RPs.

[ghgard]

The Perf tier has the synthetic full from today, thats it. The Cap. Tier has todays full and a full from one week ago along with about 11 incrementals between those full backups and two incrementals after the full today. Ive been running backups as tests to see what happens.

So, there are 16 restore points, 2 fulls and 14 incrementals. The retention is set to 7 restore points, not days. What process cleans old data from the cap. tier?

Thanks,

Grant

[Mildur]

todays full and a full from one week ago along with about 11 incrementals between those full backups and two incrementals after the full today.

Then it is expected that you have 13 increments on the capacity tier.

F I I I I I I I I I I I F I I

You have configured 7 Restore Points to keep for the Short Term Retention. That would mean to delete the first full and the first 7 increments.
But that‘s not possible. If veeam will delete them, you can not restore the other 4 increments from the first full. Veeam needs the entire chain, until no full or increment is required from the old chain. In your case, that will be 5 more increment backups, then the old chain will be deleted. As soon it is outside of the immutability period.

[veremin]

These visuals might shed some light on what Fabian is talking about; might be worth watching. Thanks!