Feature Request - Retention policies for File Indexes/Logs for old jobs

[skrause]

I have been somewhat annoyed by this over the years and today, as I am patching my Veeam infrastructure, I decided it was time to post this.

Right now, the guest file indexes for servers that are backed up are never deleted. So if you have a backup server that has been running for a year+, even if your longest retention doesn't meet that, you still end up having the indexes going back to the first time the job ran. For file servers with a lot of files, that can take up a lot of space when it all adds up.

Job logs are similar in that they are pretty much never deleted.

Obviously, the retention policy logic for file indexes would need more thought due to potential GFS restore points etc. But I would think that a "garbage collection" task on job logs that was adjustable and ran regularly to prune logs older than a certain age (6m/1y/etc) would be somewhat easier to implement.

I know I could write scripts and schedule a task in Windows on all the servers, but it would be nice to have it included with the application.

[PetrM]

Hi Steve,

Maybe I'm missing something but the default period for storing historical indexing data is 3 months. Did you check what is the retention period for indexes in your environment?

Speaking about logs, I'd suggest to refer to this KB in which you can find more fine-tuning options for logs rotation.

Thanks!

[foggy]

A couple of topics for further reading: cleaning up vbrcatalog folder and VBRCatalog folder growing in size.

[skrause]

Maybe I'm missing something but the default period for storing historical indexing data is 3 months. Did you check what is the retention period for indexes in your environment?

Speaking about logs, I'd suggest to refer to this KB in which you can find more fine-tuning options for logs rotation.

I am speaking of on the B&R server not on the Enterprise manager. I have indexes going back to the beginning of time (for the B&R server) in the VBRcatalog folder.

[PetrM]

I understood but it should work on the related Veeam B&R server as well. Do you have a support case for this issue?

Thanks!

[skrause]

No, because this has been a behavior I have experienced with every B&R component for years so I made the assumption it was working "as intended" thus the feature request.

[PetrM]

Hi Steve,

I've got your point and asked my colleagues from QA to check the behavior. I'll update the topic as soon as I hear back from them.

Thanks!

[PetrM]

@skrause Could you you please reach out our support team and share a case ID? Our QA confirmed that Veeam B&R must store indexes for existing restore points only and Enterprise Manager stores indexes according to its retention settings. The behavior described in your previous post looks like a technical issue.

Thanks!