v13 retention/immutability interaction; wasted space and unusable restore points

[barks]

Veeam allows job retention values to be set lower than minimum immutability. It seems to create a lot of waste and is perplexing to me, with no known benefits, especially in v13. Consider the configuration below.

Job Retention: 14 days
Minimum Immutability: 30 days
Block Generation: 10 days
Actual: 40 days (immutability works article calculation)

VBR console shows only 14 days of usable restore points, but keeps 40 days on the object repo, and reports show that the immutable 30-day requirement is met. If the restore points beyond 14 days cannot actually be used, then are you really satisfying the functional and practical needs of a 30-day immutable policy?

v12 hid immutable restore points beyond job retention from the view in the console, but had a repo rollback method to access hidden points in an emergency. Very inconvenient PowerShell-only method, but at least it was there. IMHO, I have always thought the console should just show all restore points to me. In the GUI, they could easily be greyed and marked as staged for deletion, or have somewhat of an override button to use them. It has crossed my mind that the feature designer may have thought you could fool an amateur attacker by obscurity if the restore points were not shown? Possibly, but I do not subscribe to security by obscurity logic. Hoping someone doesn't notice or isn't smart is not real security. Seems more likely this was a convenient way to avoid modifying restore point tracking logic.

So now v13 seems to have eliminated the repo rollback method(as told by support), which effectively renders 26 days of restore points completely unusable. What in the world is the point of keeping restore points that I have no way to access?

TL;DR
I just want clear visibility to all my restore points that are available on the given repository. That does not seem to be an option with a VBR config that includes object immutability.

[sfirmes]

@barks,

Veeam Support is correct that v13 eliminated the rollback method that was in v12. With regards to your question "What in the world is the point of keeping restore points that I have no way to access?", your immutability (object lock) is configured for 30 days. Based on this setting, VBR locks the objects for 30 days.

If your goal is to be able to restore jobs up to 30 days after the backup, you should set the job retention to 30 days. Assuming you wish those restore points to be immutable, the immutability setting should be 30 days as well.

Block Generation shouldn't be part of the equation for job retention nor immutability. It's intended purpose is to reduce the number of object storage requests, which can lower the S3 API traffic and storage costs.

Hope this helps.

[barks]

In v12 with a 30 retention + 30 immutability setting, Veeam keeps 70 days so 40 days worth of restore points that I cannot see in the console or easily use. Wowzer!
(Actual retention = job retention policy + immutability period + Block Generation as shown in https://helpcenter.veeam.com/archive/ba ... -retention)

In v13, the formula has been made better using the greater of the two, but 10 days is 33% of a 30 day retention. 30 days is pretty common from people I've talked to. I understand the API cost. I have paid many thousands worth even with block gen strategy towards cost avoidance. I know you see it as the cost of doing business, but it's a high throw away percentage to a lot.

It would not be seen as waste if I could simply refer to what is stored. What's the reason we can't just use what is on the repo until it's purged?