Need advanced restore point management

[DocDT]

Retention policies is not good enough.

I want to be able to delete specific restore points in the backup chain because they take up too much space. I understand the chain and that they are all linked but this is something that Veeam already does when it deletes the oldest restore point...it merges the data into the next restore point. Adding this feature should not be out of the question and would help mitigate the problems people have with storage.

Use case: You created a forever incremental backup and filled your repository, but you want to maintain the oldest restore point. Synthetic full backups are also not the answer because these would be huge.

Use case2: You did some work which temporarily left a very large file on the filesystem which got backed-up, now your repository is full. The only way to relieve space in the repository is to clear potentially months or years of incremental backups.

[Mildur]

Synthetic full backups are also not the answer because these would be huge.

Not with FASTClone.
Today, every Backup Repo which was build as best practice should use Veeams FastClone technology (with Windows ReFS or Linux xfs). Direct Attached storage is the best in performance and stability. And it can use FastClone to reduce needed storage with synthetic fulls.
Cheap NAS Storages of course can not use the FASTClone feature. But this are not really recommended to use with veeam.

Adding this feature should not be out of the question

Normally a feature is build, if there are enough feature request. Not only because it‘s „out of question“.
There are multiple other feature requests which are higher on the todo list, i think.

[Gostev]

Honestly, I don't know how this has anything to deal with retention policies not being "good enough". Retention policy do exactly what they are supposed to do: they deleted oldest backups. I don't see how deletions can be "not good enough"

Rather, I think your issues have everything to deal with the choices you've made when setting up Veeam. Specifically the backup mode you chose (forever forward incremental) and the backup repository you used (based on your comments, presumably a file share or a legacy file system).

1. Synthetic fulls don't take any physical disk space on modern file systems which Veeam recommends using for backup repositories (ReFS or XFS).

2. Actually, Veeam does provide a simple way out of such situations. You should just create a scale-out backup repository, add your existing repository as one extent and a new repository as another. Then, you can continue normally without having to delete anything.

[DocDT]

Honestly, my quote about retention policies has nothing to do with the way retention policies work. Instead, it's about staving off the cliché answer people give when anyone asks about storage space.

1 - ReFS and XFS are not an option for me but I will push for that in the future.
2 - I'll have to research scale-out backup repositories but it looks like the ability to just delete a single restore point would be much easier.

Thanks for the response.

[Gostev]

1. Are you absolutely sure about that? May I ask what backup storage are you using? Because there's almost always a way to use ReFS or XFS.

2. Unfortunately that would not be impossible to do on a volume that ran out of free disk space even in theory. To avoid data loss and maintain the ability to perform a restore, merging restore points is a transaction process where "source" backups are not deleted until the merge has been completed successfully, which means we do need disk space for the new backup file and have it created completely before we can delete "donor" backup files. So the SOBR approach I suggested is really the only way out from the outlined scenario in any case.

[Andreas Neufert]

I would as well recommend the usage of Veeam ONE that can monitor the growth and warn you when the trend would lead into a sitaution were you run our ot storage space on the hypervisor or the backup target.

[DocDT]

1- my personal system is just using a USB external drive (no REFS as I understand). At the office, it may take some political willpower to switch to refs.

2 - good point, but how do regular retention policies handle this situation? Unless there was some temporary space there wouldn't even be a way to merge the full in order to delete the oldest backup. Your point would seem to suggest you're SOL for doing any kind of maintenance once the backup repository becomes full.

[Gostev]

That is correct: in this situation you would have to makes some free space by deleting something else from the volume, or move the entire chain to a bigger storage. By the way, this is also why this backup mode is not the default one: it requires more care about the repository free disk space. Nevertheless we do start to log warnings when free space is less than 10%, so in real life our customers rarely end up with completely full repositories.

For "set and forget" types of installations that are poorly monitored, using reversed incremental backup mode might me a better option, as there you can always just delete oldest backups if the volume gets full (no merge is required). The drawback is slower backups, but performance is usually enough for small environments with large backup windows.