Deleting specific restore points for object-based repositories

[squebel]

Hello,

There are some edge cases where we need to manually go into the repositories and delete backup files. This is typically done if a customer wants the backup retention changed for their systems but their vm's are backed up under a larger job where we can't change the retention of the entire job. We will go in and find the VBKs and manually delete them, rescan, and then "forget" those points. There are a couple other situations where this need arises. This can be done on local repositories but is not possible to do when the backups are landing on object storage. Is there any way to do this today?

[sfirmes]

There is a PowerShell cmdlet Remove-VBRRestorePoint which allows you to remove individual restore points/backups. Using this cmdlet will remove the restore point from VBR and remove the files/objects from the repository.

Hope this helps.

Steve

[squebel]

Steve,

This actually seems to delete ALL the restore points for the server in that job, not just the individual restore point.

I pulled out the exact restore point for a vm as a test. It was the last incremental backup and used that as the Oib object to delete. It went and deleted all 8 restore points for that vm in the job.

[squebel]

Any other thoughts or suggestions on this? The behavior does not seem to be what the name of the cmdlet indicates it would do because it seems to delete the entire backup chain, not just the restore point.

[hayliz]

I am also interested in a solution. We also receive several requests regarding this requirement.

[Mildur]

Hi all

@squebel I remember we talked about this request at Veeam On. Unfortunately this is not possible today.
I have noted your and @hayliz request in our internal request tracker.

This is typically done if a customer wants the backup retention changed for their systems but their vm's are backed up under a larger job where we can't change the retention of the entire job.

Just an idea for a workaround for object storage repositories without API/egress costs.
Consider using our "move backup" feature. This allows you to transfer a single machine to a new backup job with a different retention. Backups will then be deleted based on the new jobs retention policy after the move.

Best,
Fabian

[squebel]

Thanks, Fabian. Appreciate it!

[squebel]

Fabian, is there any chance this is being considered? We continue to have customers that want to purge certain restore points of which we can't and it's starting to make us think differently about using S3 storage.

[Mildur]

"Hi Squebel,

We haven’t forgotten about your request; it’s still on our internal roadmap for potential features in upcoming versions.
However, we need to prioritize each request we get. I have asked for an update regarding this request from our internal team.

Best,
Fabian"

[DominikM]

Any update on this?

[Mildur]

Hi Dominik,

Unfortunately, there’s no update.
At the moment, we don’t have enough requests for it compared to other more requested features.

Best regards,
Fabian

[vee789]

@Mildur
I also have a customer who asks how it is possible to delete certain VM restore points from an onprem S3 repo (so API costs/transfers are not an issue).
We have a GFS policy and AFAIK those restore points are like a synthetic full and it should be possible to delete some of them without breaking the backup chain.

The planned GFS policy is: 30x daily, 26x weekly, 12x monthly, 8x yearly
As we don't know the exact space consumption going forward, the customer wants to keep the option open to delete some older restore points to gain space if needed.

How would it possible to delete the lastest "yearly" restore point of a certain VM?
Or is it only possible to delete the oldest restore points of all VMs in a certain job with lowering the retention in the GFS setting? (like going from 8x yearly to 6x yearly)

[Mildur]

Hi vee789,

You can only lower the retention policy in the job, but you can’t select and delete a single GFS restore point from the backup.

We have a GFS policy and AFAIK those restore points are like a synthetic full and it should be possible to delete some of them without breaking the backup chain.

That’s generally true with “classic” backup files, but on object storage we don’t store restore points as standalone .VBK/.VIB files. By default, each VBK/VIB is split into many small 0.5–1.0 GB data chunks that are uploaded to object storage. This design enables faster restores because the backup server can retrieve only the chunks required for the restore instead of downloading an entire chain.

To be able to delete an entire full backup safely, we’d need product functionality that can reliably detect which objects are not referenced by any other restore point, and then remove only those (i.e., a safe “delete” action).

I will add your vote to our internal feature request system where we track the demand for this feature.

Best,
Fabian

[vee789]

Hello Fabian

Ok understood. Thank you very much for your detailed response and explanation. This improves my understanding and is very helpful.
Glad to see that there already is an internal feature request for this functionality.