Feature Request: Back up metadata with Insider Protection

[dataprotection-uss]

We learned recently on a Veeam Support case (08116625) that metadata, .vbm, files are not moved to the Recycle Bin under Insider Protection. This came up after recovering from a ransomware event that gained access to Veeam B&R and deleted the backups. We restored the .vbk files which were in the Recycle Bin, but we lost the .vbm files. We required these files to cover the data. Why are these not protected by Insider Protection, but required for restores?

Our support engineer confirmed this and wasn't able to explain why. He only recommended we make a Feature Request here.

If .vbm files are required for restores, they must be protected by Insider Protection.

[CharadeUR]

We recently had a client with a ransomware issue. They of course deleted the backups but we had a Veeam Cloud Provider with Insider Protection. We were sold this on the belief that if the backups got deleted we could easily recover. What we found was just the opposite. Because the metadata file was deleted even when our cloud provider restored we could not import them from the cloud repository. So we had to drive 1.5 hours to drop off a hard drive then back here then come back the next day to pick up a physical drive with the files on them to import them and restore. We lost 6 hours just in driving time. This seems absurd to me that a restore doesn't restore something we can easily import. And yes we had veeam tech support involved and they were unable to import it either Then on top of that one of the backups was corrupt so we had to get Ontrack involved to fully restore. It was a hard lesson that we thought we had covered because we bought into the sales pitch that cloud resources would be recoverable and I guess assumed from the cloud. Please fix this as what would we have done if it was a 10 hour drive or we had to fly to the west coast or something.

[IvanK]

Hi George,

Appreciate you writing this up in detail. Here's what's going on: Insider Protection intentionally doesn't keep the .vbm metadata, because a chain produces many .vbm versions over its life and IP retention would likely make any single one we kept invalid anyway. The supported recovery is to import the retained files onto a standby VBR (basically attaching the VCC repo as a local repo to a secondary VBR) on your side and regenerate the .vbm via PowerShell - no physical seed needed.

One thing worth flagging: Insider Protection is one line of defense, not the primary one. Against an attacker deleting backups, immutability (object-lock / hardened repo) is the stronger safeguard, since it stops the deletion outright rather than helping you recover after. If you're not already running it underneath IP, I'd add it.

I'd still record a feature request on this, let's hear more feedback from the community.

[Mildur]

Hi @dataprotection-uss,

I apologize for the late reply.
I merged your question with an existing topic. Please see Ivan’s comment regarding the request.

Best,
Fabian