Immutability Duration and Retention

[mcbrown]

Checking on the following scenarios:

1. I have a backup job set to run once a day with 7 days retention and weekly synthetic fulls. This job is being sent to a Linux repository that has immutability set to 7 days. On the 8th day I should have on the repository the new full for the current week and the previous week’s full and 6 incremental. On the 8th day is there anything in Veeam that makes the previous week’s full still immutable (due to the fact that the incrementals depend on that full) even though it will be beyond the 7 day immutable set on the repository?

2. I have a backup job set to run daily with 7 days retention and weekly synthetic fulls. I have a gfs policy defined with 6 monthly and 1 yearly. This job sends to a SOBR and the SOBR is set to immediately copy all backups to the capacity tier. The immutability set on the capacity extent is 90 days. I have read that all gfs backups sent to an archive tier are immutable for the entire lifespan of the gfs backup. Is this also the case with the capacity tier or are gfs backups that sit on the capacity tier still only immutable for the immutable days set on the capacity extent? i.e. gfs month 4 backup in the scenario above will not be immutable.

3. I have a backup copy job that runs daily and has a 30 day retention with a gfs policy set for 6 monthly and 1 yearly and is sent to a Linux repository with 365 days of immutability. Due to the 365 days immutable setting, over the course of 365 days will I wind up with 365 daily incrementals, 12 monthly and 1 yearly due to the fact the 365 immutable days made it impossible for Veeam to delete the extra 335 daily incrementals and extra 6 monthlys?

Thanks for your help.

[Mildur]

Hi mcbrown

On the 8th day is there anything in Veeam that makes the previous week’s full still immutable (due to the fact that the incrementals depend on that full) even though it will be beyond the 7 day immutable set on the repository?

Yes, veeam takes care of that. Immutability for the entire chain will be the creation date of the last incremental + 7 day.

Is this also the case with the capacity tier or are gfs backups that sit on the capacity tier still only immutable for the immutable days set on the capacity extent?

When only using copy mode, gfs restore points will be immutable:
- Performance Tier —> There entire retention period
- Capacity Tier —> The specified period in the object storage properties

When you activate the move mode, gfs restore points will be immutable:
- Performance Tier —> The specified period in the object storage properties
- Capacity Tier —> The specified period in the object storage properties

Due to the 365 days immutable setting, over the course of 365 days will I wind up with 365 daily incrementals, 12 monthly and 1 yearly due to the fact the 365 immutable days made it impossible for Veeam to delete the extra 335 daily incrementals and extra 6 monthlys?

Yes, you are correct. The files cannot be deleted in that case. With your planned retention policy, please choose 30 days immutability. The gfs restore points will automatically be protected their entire retention time.
- Monthly —> protected for 12 months
- Yearly —> protected for 1 year

[mcbrown]

Thanks for the info Mildur.

Yes, veeam takes care of that. Immutability for the entire chain will be the creation date of the last incremental + 7 day.

Ok I think I got it. Does this look correct:
Retention on job set to 7
Repository set to 7 days immutability
Jan 1 - Full Backup A - Immutable from Jan 1 to Jan 14
Jan 2 - Incremental A - Immutable from Jan 2 to Jan 14
Jan 3 - Incremental A - Immutable from Jan 3 to Jan 14
Jan 4 - Incremental A - Immutable from Jan 4 to Jan 14
Jan 5 - Incremental A - Immutable from Jan 5 to Jan 14
Jan 6 - Incremental A - Immutable from Jan 6 to Jan 14
Jan 7 - Incremental A - Immutable from Jan 7 to Jan 14
Jan 8 - Full Backup B- Immutable from Jan 8 to Jan 21
Jan 9 - Incremental B - Immutable from Jan 9 to Jan 21
Jan 10 - Incremental B - Immutable from Jan 10 to Jan 21
Jan 11 - Incremental B - Immutable from Jan 11 to Jan 21
Jan 12 - Incremental B - Immutable from Jan 12 to Jan 21
Jan 13 - Incremental B - Immutable from Jan 13 to Jan 21
Jan 14 - Incremental B - Immutable from Jan 14 to Jan 21
Jan 15 - Backup chain A no longer immutable and is deleted

Does the above apply to both the performance extent and all fulls and incrementals copied to the capacity extent?

When only using copy mode, gfs restore points will be immutable:
- Performance Tier —> There entire retention period
- Capacity Tier —> The specified period in the object storage properties

So if I have 90 days immutability set on the performance extent and 90 days immutability set on the capacity extent of the SOBR and only the copy set and not the move on the SOBR, each gfs monthly backup will be immutable for 6 months on the performance extent even though the performance extent is set to 90 days immutability. On the capacity extent each gfs monthly will be immutable for 90 days?

Yes, you are correct. The files cannot be deleted in that case. With your planned retention policy, please choose 30 days immutability. The gfs restore points will automatically be protected their entire retention time.
- Monthly —> protected for 12 months
- Yearly —> protected for 1 year

If I set 30 days immutability on the linux repository, the 6 gfs monthly and 1 gfs yearly will only be protected because it is on a linux repository and not the capacity tier of a SOBR right? Is there any way to make all gfs backups on a capacity tier of a SOBR immutable for their entire retention time?

Thanks again for your help.

[Mildur]

Your welcome.

Ok I think I got it. Does this look correct:

Looks good to me.

Does the above apply to both the performance extent and all fulls and incrementals copied to the capacity extent?

For short term retention, it behaves the same for both tiers. For the capacity tier, there is an additional feature called Block Generation. It adds up to 10 days to the retention of the offloaded blocks of the backup files.

So if I have 90 days immutability set on the performance extent and 90 days immutability set on the capacity extent of the SOBR and only the copy set and not the move on the SOBR, each gfs monthly backup will be immutable for 6 months on the performance extent even though the performance extent is set to 90 days immutability. On the capacity extent each gfs monthly will be immutable for 90 days?

Correct.
- 90 days immutability for daily backups
- 6 months immutability for monthly gfs
- 1 year immutability for yearly gfs

You should consider to set the immutability period accordingly to your short term retention. 7 days retention and 90 days immutability will need more storage than you have expected.

If I set 30 days immutability on the linux repository, the 6 gfs monthly and 1 gfs yearly will only be protected because it is on a linux repository and not the capacity tier of a SOBR right?

Yes. Capacity tier doesn‘t know gfs protection based on retention period. It will be only 90 days. (Specified immutability period in the object storage properties.
)

Is there any way to make all gfs backups on a capacity tier of a SOBR immutable for their entire retention time?

Not on capacity tier. If you are using AWS S3, then you can leverage veeam archive tier to offload your gfs restore points to AWS Glacier. There it will be protected for the entire retention period.

[mcbrown]

Thanks Mildur.

Clears up most of it for me.

Do GFS weeklys take the place of synthetic or active fulls defined in Job > Advanced > Backup tab > Backup Mode/Active Full Backup?
i.e If the job has a GFS policy to keep 4 weeklys and 4 montlys is there a reason to setup the synthetic or active fulls in Job > Advanced > Backup tab > Backup Mode/Active Full Backup?

Are all GFS updates active fulls?

Is it recommended to define an immutability shorter than the retention period and have both the performance and capacity extent set to the same immutability duration?

[Mildur]

Your welcome, mcbrown

Do GFS weeklys take the place of synthetic or active fulls defined in Job > Advanced > Backup tab > Backup Mode/Active Full Backup?

Imagine, that you have configured your weekly gfs to Wednesday, and Synthetic/Active Full to Sunday.
On Wednesday, veeam wants to tag the backup as a gfs weekly backup. That will not work, because there is no full todo that. Only an incremental file. Veeam waits now until on Sunday a new Full Backup is created. This full will be flagged als weekly.

In this example, if you want to have a gfs weekly each wednesday, you need to configure your synthetic or active full backups for wednesday. Or there will be only Sunday gfs weeklies.

This is documented here.

i.e If the job has a GFS policy to keep 4 weeklys and 4 montlys is there a reason to setup the synthetic or active fulls in Job > Advanced > Backup tab > Backup Mode/Active Full Backup?

Yes, you must configure synthetic or active fulls. Or you can‘t create gfs backups.

Are all GFS updates active fulls?

No, the default setting is weekly synthetic full. You can enable active full if you want, but with a decent storage and surebackup jobs, it‘s not needed. I don‘t use it in such environments.

Is it recommended to define an immutability shorter than the retention period and have both the performance and capacity extent set to the same immutability duration?

It depends on how long you want to have your backups protected. If you have a short term retention of 90 days, you should configure 90 days or less. But not more. It could lead to warnings in the Backup jobs.
How long the immutability period will be, depends on what your business requires.
Long immutability: you won‘t be able to free up space, but you have more protected restore points.
Shorter immutability: it‘s easier to free up space, but restore points are only protected for a shorter time

Use the Archive Tier , if you want to have immutable monthly or yearly cloud backups for their entire retention time. Storage on archive tier will be definitely cheaper than Storage on capacity tier.