Feature Request - Add Expiration Data column in Job Properties and Add Reporting

[thunter-npwf]

We're a new customer to Veeam and figuring out what the deletion dates for various full and incremental backups files is extremely difficult. I read through many different support articles and think I finally have a little bit of a handle on things, but it would be much easier if the software would calculate out the expiration/deletion date for incremental and full backup files based on the selected retention settings. I would love to see that as a report in Veeam one and also when you click on properties for a backup (see attached) where it lists out all the restore points.

I raised this issue with support and they suggested that this forum was the appropriate venue for this request.

[Gostev]

Hi, Travis.

Could you clarify why do you need to be figuring out the deletion dates of individual files in the first place? In other words, why can you not just let software do it's job and don't worry about it at all?

You can be sure each file will be deleted as soon as possible, after the following two things happen:
1. The restore point contained in the file is passed its retention policy, and
2. There are no restore points that are dependent on it (subsequent increments) which are still under retention policy.

Thanks

[thunter-npwf]

As someone completely new to Veeam, I'm used to my backups being clearly labeled re: retention and Veeam is not user friendly in that regard. There are a lot of competing factors with the retention time, GFS settings, synthetic full schedule and immutability that don't always make it clear when a file is eligible for deletion and thus harder to figure out disk space consumption. Since the software is calculating that deletion date somewhere on the back end, it would be a lot more straightforward if that was exposed in the UI and/or in a report.

[Gostev]

Your backup should in fact be clearly labeled. As far as I remember, you should see the GFS generation letter (one or more) next to each restore point in the backup properties.

[thunter-npwf]

True, but seeing W,M, or Y is not clear. A date is much clearer and I'm not sure why there is so much defensiveness on what seems like a basic ask.

[Gostev]

What you're seeing as "defensiveness" is me honestly trying to get to the bottom of your request and understand the actual reason behind it. Because you're the first in my memory to ask about this in the entire time the product existed, so over 16 years and among millions of users.

Further, we don't implement asks just because they are "basic". We always try to understand the real value behind each request, in order to be able to prioritize one among thousands of other pending asks.

For example, we did have a similar request after we added backup immutability feature, but that was understandable because immutability period is separate and often lower than retention, so seeing this is actually useful to many. This is why we've prioritized adding "Immutable Until" value and have been working on adding this.

[thunter-npwf]

Fair point I suppose. I can't believe I'm the only person to ever ask about wanting to know the date a file expires to help me keep an eye on the disk consumption, but if there's no value in the request then I guess it is what it is.

Thanks for considering.

[SSSSSStorage]

Hi,

when will the "Immutable Until" feature be available? as we do get requests during auditing of the exact date we have backups expire, so it would be helpful to have.

[Gostev]

It's already available depending on backup repository type and is coming to other pending some immutable architectural rework to make it actually possible.

[Matts N]

SSSSSStorage, do you need retention expiration or actual expiration of backup files for auditing? Since immutable can be shorter than actual retention, maybe what you need is what the OP is asking for?

[tina.cornelison]

We've had this ask also. I've also seen other posts regarding expiration dates. Not sure why veeam would think users wouldn't want to know when their data will expire. Especially in the event of retirement of a repo. The repo goes into orphaned state. Upon trying to remove the orphan it will clearly tell you the date once it fails. But nothing that you can look at from the GUI until you try to remove the data.

[mkaec]

+1 from me. I saw this thread and immediately thought "that would be great".