Disable GFS Immutability

[crackocain]

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.

[crackocain]

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.