Disable GFS Immutability

[mehmetistanbullu]

Hello

Keeping GFS points as immutable is a nice feature. When we say keep for 1 year, it keeps them as immutable for 1 year. However, the vast majority of customers do not need this. If they want the last 14 days to be immutable, keeping the last 14 days is enough.

However, when we delete the relevant virtual server, this point continues to be stored for a long time.

This issue becomes a problem when cleaning the backups of unnecessary virtual servers. How can we find a solution for this issue? Frankly, I do not know of a solution other than a registry key that will disable this feature. Manual deletion is not an option.

[david.domask]

Hi Mehmet,

Just to confirm, this is immutability via a Hardened Repository or Object Storage Immutability?

Within the UI, there is not an option to configure such a setup at this time that I'm aware of, and with a hardened repository, manual deletion would be my recommendation. Which registry value did you have in mind, as off the top of my head (and quick check of registry values) just not sure which one you're referring to.

For the customers who do not need it, is it feasible right now to include their workloads in jobs that do not have GFS? I realize this means additional jobs, but it's the most immediate means I can think of at the moment to accomplish your goal.

[mehmetistanbullu]

Hello David; Hardened Repository

GFS immutability bypass the repository immutability setting so this option create a problem when backups are unnecessary. I think these backups should be able to be cleaned up if the repository setting allows it or need a options for this. (GFS backup settings screen)

Since the customer does not want such a thing, having the manual backup deleted is a solution that causes work for the customer. We heard some criticism about this.

Combining Immutability with GFS policy really provides protection in this regard, but since the customer's actual indelibility demand is around 14 days to 30 days, manually cleaning the backup files one by one in very large environment is a troublesome job.

[david.domask]

Hi mehmet,

Understood on the use case, and we can discuss this internally, however it somewhat violates the idea of immutable if the immutability can be disabled by an attacker or malicious insider.

For now, I would advise consider splitting the jobs into those with GFS and those without, and clients who require the long-term immutability can be added to a job with GFS enabled, and those who do not need it can be added to jobs without GFS.

[mdiver]

I would want to bring that topic up again, as we face issues with it over and over again in customer environments.
Just today I had one customer with 0 bytes free in his VHR made of 8 extents in a SOBR (~400TB total). Getting out of that situation and back to having backups run can be cumbersome and annoying.

Here the summary of my request in sync with David's remark about an attacker not to be able to remove any immutability:

Let the Veeam admin decide during the first (!) installation of the VHR, if you want GFS points to also be immutable or not.
The "immunerepo" service on the VHR can than by reading that protected setting within the VHR decide, if we want those immutable flags be removed from GFS points or not.

Thanks,
Mike