Immutable repository with GFS - retention periods

[TWuser]

After finding an Orphaned backup on my Immutable repository I am not able to delete until I wait months, I have been trying to thoroughly understand all the quirks around Immutable storage and GFS backups so I don't shoot myself in the foot.
I want to be very clear about the topic so started a new post.

Under the "Hardened Repository Limitations" found here: https://helpcenter.veeam.com/docs/backu ... ml?ver=110 it says

• "If a hardened repository with immutability is a part of a scale-out backup repository with the capacity tier added, the immutability time period for full backup files with GFS retention policy is set according to the following:
  For capacity tier with disabled move policy] Veeam Backup & Replication compares the immutability period of the backup repository and the GFS backup file lifetime, and sets an immutability period for full backup files with GFS retention policy as equal to the longest of these periods.
  For example: the backup repository immutability period is 10 days; the GFS backup file lifetime is 3 years; the backup file will be immutable for 3 years; the increments from this full backup file will be immutable for 10 days from the moment of the last increment creation.

• [For capacity tier with enabled move policy] Veeam Backup & Replication ignores the GFS retention policy. The immutability time period for full backup files equals the period specified in the setting of a hardened repository."

First - to be 100% clear, if I enabled checkbox "Move backups to object storage as they age out of the operational restore window" on the SOBR itself right away, I will not have to worry about the Immutable expiration date being affected by the GFS retention period? If true, I will likely start checking the "Move" box for all SOBRs, as the risk of a job having a yearly (or longer) GFS job stuck on the Capacity tier is just too high.

Second - do GFS backups have no effect on immutable backup expiration dates on a SOBR without a Capacity tier configured? I have not found documentation that talks about GFS on a hardened repository in regards to the immutability time period.
If Veeam changes the Immutable expiration time on GFS jobs where a Capacity tier exists, it seems weird not to do the same (or have an option to do the same) for a SOBR without a capacity tier configured. Perhaps a checkbox or tooltip when enabling the Capacity tier would help make this more clear, as it can have a giant impact if misunderstood.


This was first an issue for me after configuring a new Backup job and Repository for a 12TB file server. I deleted the original job, which made the Backup an Orphan. Since it was in an SOBR with Capacity tier (with Copy enabled), it already had a copy in Azure.
- I wanted to simply right-click on the backup and select "Move to Capacity tier" - but the option was not available. There were (months old) GFS backups that would not let me move them.
- I need to turn off the repository they are stored on, but if I seal the extent and "Evacuate Backups", all the XFS fast-cloned 12TB GFS jobs will get rehydrated and absolutely crush the new repository.
- If I try to delete the Backup from Disk, it warns that it will "Remove its dependent copy from the Capacity and Archive Tiers" so I would lose the restore points completely.
I'm guessing those jobs ran before I had turned on "Move backups to object storage" option, thus there is an immutable expiration date set months out, even though my Repository has only a 7 day immutability period. Luckily I did not set a longer GFS period like 2 years.
Since I'm turning off the "old" repository anyways, the easiest solution is to just delete the repository, but the Orphaned restore points on Object Storage (Azure) should remain through the original GFS retention period?

I had to dig into quite a few forum posts until I finally found one where Gostev mentioned the "Except when Move policy is enabled" exception that should prevent the Capacity tier getting full when using long-term GFS. For a while I was worried I would have to greatly shorten planned GFS retention periods.

I would at minimum suggest/request that a Immutable Until column be added to the Backups - Disk (Orphaned) properties, with the proper date listed when GFS backups have impacted that date.
I do hope the Immutable Until does display accurate dates on normal backups when GFS affects that retention period, though testing would take me a while to verify. If anyone knows that fact for sure or can verify that would be helpful.

If anyone else was was also struggling to find specific info hopefully there are enough keywords in this post!

Thanks - TW

[Mildur]

Hi TW

First - to be 100% clear, if I enabled checkbox "Move backups to object storage as they age out of the operational restore window" on the SOBR itself right away, I will not have to worry about the Immutable expiration date being affected by the GFS retention period? If true, I will likely start checking the "Move" box for all SOBRs, as the risk of a job having a yearly (or longer) GFS job stuck on the Capacity tier is just too high.

Correct, with enabled Move Option, GFS Restore Points are immutable as configured in the settings of the hardened repository.
But consider that only gfs restore points after you checked the Move Option will work with the new configuration. Already existing gfs restore points will keep their immutability date.

do GFS backups have no effect on immutable backup expiration dates on a SOBR without a Capacity tier configured?

On a Linux Hardened Repository, GFS Backups are always immutable their entire retention period. Only exception, you use a SOBR with a capacity tier with the Move Option enabled.

If Veeam changes the Immutable expiration time on GFS jobs where a Capacity tier exists

We need to do that, or we couldn't remove the restore points on the performance tier, if the customer wants to do that.

Perhaps a checkbox or tooltip when enabling the Capacity tier would help make this more clear, as it can have a giant impact if misunderstood

We will consider it. I have also issue to find it in the guide. I'll check it out.

Since I'm turning off the "old" repository anyways, the easiest solution is to just delete the repository, but the Orphaned restore points on Object Storage (Azure) should remain through the original GFS retention period?

The Restore Points in Azure will not be removed when you delete the old repository. If you remove the SOBR, you probably have to reimport the backups from the Blob before you can use them again to do the restores.

I would at minimum suggest/request that a Immutable Until column be added to the Backups - Disk (Orphaned) properties, with the proper date listed when GFS backups have impacted that date.

Thanks for the request. We have that already for restore points on a Linux hardened repo.


Thanks
Fabian