There are too many automatic backups like this, and it is difficult to find a specific time point to restore.
If the date interface is changed like this, you only need to look in the backup for that day.
There are too many automatic backups like this, and it is difficult to find a specific time point to restore.
If the date interface is changed like this, you only need to look in the backup for that day.
Welcome to the forum @manager5021
Do you really need to retain all older backups? Keeping so many will also slow things down.
Creating a new backup job covers your options. Maybe you can thin some out after awhile?
The risk of thinning is files and file versions that exist only briefly might fall between backups.
That’s why the usual plan is to thin little-to-none for awhile, increasing more as backups age.
EDIT:
Although details of the design are unclear, I’d note that the left bar concept is already there:
and you can sort of see that sections grow with age, thus thinning with age will help visuals.
If keeping closely spaced versions from years ago is necessary, then yearly list will be long.
Thank you for your answer
I set the backup to be done every 10 minutes for 30 days, but I don’t know when I might need to restore, so I’m not considering this solution for now.
I mean, if there is a filtering function (not necessarily the same as in the picture), it will make it much more convenient for users.
That might be two parts. Schedule is 10 minutes, then also:
and if so then at least it’s capped (not infinite), so gives you 30 days or the restore window is gone forever.
therefore has a hard deadline, whereas you could make a soft one by progressive thinning. Your choice.
Adding features (especially non-trivial ones) is still low on the priorities, as they easily outstrip resources.
More could be done if more people volunteered, but rather limited help requires a focus on the essentials.
EDIT:
Asking for and discussing features is fine, and a good way to gauge wide interest (or not), to set priorities.