Can't delete Backup while another VM is configured for SureBackup

[ASG]

Hi,

I've noticed something and I'm not sure if it was the same way before V10 (because we don't delete Backups that often):

I have a Job with a SOBR Target (so per-VM Files are stored) that backs up multiple VMs (MACHINE1, MACHINE2, MACHINE3, etc...). I wanted to delete one of the VMs (MACHINE1) from disk (since it is no longer used and we don't want to keep the backup) - however I'm unable to do this because B&R says it's in use with a specific SureBackup that is NOT running but just configured.

The problem is: MACHINE1 is not part of the SureBackup, MACHINE2 is - however the Surebackup is not running and it's not the machine I wanted to delete. Is this a bug or "a feature"?

Thanks!

[HannesK]

Hello,
you were asked in red letters to open a support case for technical issues

Just by chance, I ran into that bug some time ago... it is bug number 254358 and planned to be fixed in V11

Best regards,
Hannes

[TitaniumCoder477]

BACKGROUND

One VM backup job: LocalBackupSolution

• Source: VMs on two production Hyper-V hosts

• Destination: Internal disk space on a third DR Hyper-V host

Two agent backup jobs:

• LBS-Laptops

• LBS-Desktops

One SureBackup job: AllServers

• Mapping to one application group targeting the LocalBackupSolution backup set

SCENARIO

• Client initiated an Instant VM recovery for a laptop endpoint from the LBS-Laptops job to a production host for testing

• Since he left it up over night, Veeam automatically scooped it up in LocalBackupSolution

• After decommissioning the Instant VM recovery, client wanted to remove the unneeded point from LocalBackupSolution

• Veeam refused to allow, claiming that it was included in the AllServers application group

• Client escalated to me

INVESTIGATION & ATTEMPTS

• I confirmed the laptop asset was NOT in the selection list for the AllServers application group

• I added it and removed it, just to be sure; symptom remained

• I removed everything from the selection list and re-added; symptom remained

• I created a new application group, making sure that the laptop asset in the LocalBackupSolution job set was NOT included, only the servers; I then remapped the SureBackup job to the new application group and deleted the AllServers one; symptom remained, only now with the new application group

• I opened ticket 04753901 with support

Support told me that the protection group is targeting the job set, even if only specific assets in the job set are selected.

In summary, you are only testing specific machines, but the application group references the whole job.

This blew my mind because the result is that as long as any protection group is targeting the backup set, no cleanup can be done! And the steps that support provided below actually cause me to lose the granular settings configured for each application group VM:

Please try the following:
1. Remove all VMs from the application group
2. Add a VM from another job and finish out the wizard.
3. Go delete the backup data from LAPTOP1224DD now.
4. Edit the application group again and remove the single VM added in step 2.
5. Re-add the original job and just pick the VMs you want from that job to actually get processed.

This design logic makes no sense from a user perspective. I should not have to "gut" my application group just so that I can break the tie it has with the VM backup job set so I can remove one asset.

[HannesK]

Hello,
sounds like it's about a known SureBackup issue (I remember that I discovered).

It's fixed in V11.

Best regards,
Hannes

[TitaniumCoder477]

Hannes, if that's true then it's good news for me. But it also begs the question, why didn't support notify me of this instead of implying a destructive workaround was the only way forward?

[HannesK]

Hello,
I cannot speak for support, but it sounds like the issue from above.

Best regards,
Hannes

[TitaniumCoder477]

Well, no product is perfect and software in particular is always changing, so I have no problem with bugs when they are being "squashed" which Veeam has always been good about! I just didn't like being provided a "solution" which was really a bad, destructive workaround! At least this is fixed in v11 which all our clients will soon be using. Thanks!