SureBackup Backup Verification scanning orphaned VMs

[mdiver]

Maybe this is by design, but to me it seems odd:

Assume a SureBackup job in "backup verification and content scan only" mode.
It's linked to a large job with many VMs. Once VMs are removed from the primary job (e.g. being decomissioned) they stay in the backup chain for some time.
SureBackup now even checks those VMs - not only the ones still actively in the job.
Is this planned behavior?

I would have expected only the actively backed up VMs to be scanned. With GFS enabled and on a VHR you will keep those decomissioned VMs for a long time in the backup chain. Scanning those decomissioned old and no longer changing VM backups wastes a lot of ressources.
Especially if you use random mode, you would not want orphaned VMs to be picked here.

Unfortunately excluding those VMs is also not possible as the exclude dialog for the SureBackup Job only allows to pick VMs actively in the job.

Thanks,
Mike

[Dima P.]

Hello Mike,

Thank you for the feedback! Mind me asking what backup format are you using: single backup file or per-VM chains? Thank you!

[Egor Yakovlev]

Hi Mike,

Main idea behind SureBackup is to validate backups. VM is not processed by the job anymore, but since VM data is still in the backup files, and it is a 100% valid restore points that you can use to restore that VM back...until set retention policy clears that data out, we do treat such data equally to other restore points for other VMs in the same backup job.

In your case there are solutions:
- Exclusion "Add" dialog has a checkbox "Show full hierarchy" on top. That allows selecting machines that are not in the job anymore\yet.
- Since VM is not processed anymore, you can use Move Backup feature to "split" stale backups of that VM and put them elsewhere(if they are even needed?), outside of SureBackup scope. That feature is available for split VM chains, hence the Dima's question above remains.

Hope that helps!

[mdiver]

Thanks Egor and Dima.

In this case it's per-VM chains inside a SOBR consisting of 6 similar sized VHR extents.

VHR also invalidates the method to move the backup away. We're using GFS and therefore GFS points are immutable.
That's mainly the problem here, as the customer has decomissioned VMs. But they will still linger in Immutable-GFS and SureBackup scans half a year old restore points over and over again.

Show full hierarchy is indeed an option, but you would have to manually add VMs that were removed from the backup. We sometimes have jobs with 300+ VMs and it gets quite cumbersome to keep track here.
An option to only scan VMs still being actively in the job would help. Escpecially when randomly cycling a few of them.

Thanks,
Mike

[mdiver]

I have to clarify a bit:
"Show full hierarchy" is only an option when the VMs haven't been decomissioned already.

With VMs the only exist inside the chain but not in the virtual environment, I can find no option to suppress scanning them.
Therefore I would be really helpful to have an option to suppress non-existing VMs.

Thanks,
Mike

[Egor Yakovlev]

Case is clear.
Noted an improvement request.

[TWuser]

And here I thought that 13 year problem was finally fixed. Multiple people in the (now 13 year old) thread noted the issue specifically with deleted VMs, especially after immutability was implemented.

Somehow exclusions in 12.1 come with a giant asterisk that the VM has to still exist? If a site had GFS running for 5 years on an immutable repo, then wanted to enable SureBackup, a single deleted VM that fails will fail every test for the entire 5 years?