-
CharadeUR
- Influencer
- Posts: 23
- Liked: never
- Joined: Mar 05, 2012 2:29 pm
- Full Name: George Streeter
- Contact:
Feature Request: Back up metadata with Insider Protection
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
- Veeam Software
- Posts: 184
- Liked: 110 times
- Joined: Oct 14, 2016 2:18 pm
- Full Name: Ivan Kochemasov
- Contact:
Re: Feature Request: Back up metadata with Insider Protection
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.
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.
Who is online
Users browsing this forum: Amazon [Bot], Bing [Bot] and 383 guests