Feature Request: Restore point consolidation when disk is full

[tenjaminbanner]

I am submitting this feature request per this support request: 07771344

All details should be in the case, but to summarize:

Current state is that a veeam job only merges restore points after taking a new incremental. This presents a problem when the disk is full and a new restore point cannot be taken. If restore points could be merged prior to saving of the new incremental, a disk full condition could be solved by reducing the retention (# of restore points) and performing a merge, before a new incremental is saved.

Support advised of a manual method of cleaning up old restore points by working at the file level, but I don't see why this can't be implemented in the GUI. This could take the form of a simple delete button in the backup properties window.

[Mildur]

Hi Benjamin

If restore points could be merged prior to saving of the new incremental, a disk full condition could be solved by reducing the retention (# of restore points) and performing a merge, before a new incremental is saved.

This approach would essentially violate an organization’s retention policy. Imagine if restore points or backup chains were deleted first and then something happened during the backup; at that point, you would have deleted restore points but have no new backup.
It’s important to ensure that a backup repository has enough space for all its required operations (Veeam Calculator). This also means having enough space to store at least 1–2 active full backups of your largest machines, just in case it becomes necessary.

However, for "repositories with rotated drives," we do have an option to delete backups before writing new ones. External USB Disks normally contain only one full backup, thats why its generally ok to remove everything before copy a new backup to the disk.

Support advised of a manual method of cleaning up old restore points by working at the file level, but I don't see why this can't be implemented in the GUI. This could take the form of a simple delete button in the backup properties window.

We are aware of this request. However, adding such a button is not "simple." There would be many challenges in the product code; such as handling immutable backups, ensuring incremental restore points within a chain aren't deleted out of order, and preventing deletion of full backups that are still required for restores of incremental backups. Nothing is ever truly "simple" in coding.

Best regards,
Fabian

[tenjaminbanner]

This approach would essentially violate an organization’s retention policy. Imagine if restore points or backup chains were deleted first and then something happened during the backup; at that point, you would have deleted restore points but have no new backup.

You should have read the sentence after the one you quoted, too. "If restore points could be merged prior to saving of the new incremental, a disk full condition could be solved by reducing the retention (# of restore points) and performing a merge, before a new incremental is saved."

We would be reducing restore points anyways, so there would be "room" in the retention poliy for holding an additional restore point for this "pre backup merge operation". Needing to keep "plus one" restore point when doing a pre backup merge operation is a good point to maintain the retention policy, but it's a side issue and easily dealt with. It doesn't mean the approach I described would violate the retention policy.

We are aware of this request. However, adding such a button is not "simple." There would be many challenges in the product code; such as handling immutable backups, ensuring incremental restore points within a chain aren't deleted out of order, and preventing deletion of full backups that are still required for restores of incremental backups. Nothing is ever truly "simple" in coding.

Nothing is simple to implement, but the logic is pretty straightforward. If I'm able to identify the right file to be deleted, the software should be able to. Yes, this is a critical operation and thorough logic needs to be developed and tested, but it's certainly doable. Once done, this would be a much more robust solution compared to advising customers to delete the right file. It sounds like Veeam just doesn't want the liability.