Unable to Mount Secondary Disk During FLR

[rookfive]

Hi Forum Friends,

I've opened a support case for this ( 03472205 ), but I was hoping I could reach out here to see if anyone has experienced this issue.

When I do a guest file restore on our fileshare, it processes, but my secondary disk doesn't get mounted. When I click on said disk ( D: ), I see a message that says:

Unable to mount volume from backup to the mount server

This file restore WAS working when I first began backing up the fileshare, but has since began failing and I'm not seeing a cause. I've searched through logs for the FLR, but I only see that the disk is being mounted successfully.

One more bit of information that might be helpful. FLR for other VMs with multiple disks works as expected, so I believe this issue is specific to the fileshare VM backup.

Thanks so much!

[foggy]

Hi Wayne, you'd better work with your support engineer on that, he will be able to tell the actual reason after logs investigation. A check from your side could be restoring the entire VM to see if everything is ok with disk in the backup.

[rookfive]

Hi Foggy,

I appreciate the reply, and wanted to post back to say that I was able to resolve the issue. It was so silly.

Here is what was happening:

1. Backup FileShare1 that has two disks on two separate datastores - These get mapped to C: and D:
2. Test restore guest files for FileShare1
3. C: can be accessed, but D: could not be mounted

SOMEHOW, the datastore that contained D: had been attached to another VM in our environment. So it was attached to DatabaseServer1 AND FileShare1. I removed it as a disk from DatabaseServer1, re-ran my backup, and now I can access D: when restoring guest files.

TLDR: The drive couldn't be mounted because it had mysteriously become attached to another VM

[rookfive]

I wanted to post back one more time and clarify this, just in case someone is has a similar issue in the future.

The resolution was correct, to remove the datastore from that extra VM, but what I wanted to clarify is that the 'extra VM' it was being attached to, is actually one of my Veeam proxies. So in this regard, it was SUPPOSED to be attached to that VM during the backup process. My issue occurred because the Fileshare datastore stayed attached once the backup job completed.

Thanks all! I look forward to being more active on the forums and growing my Veeam knowledge.

Humbly,

wmartin

[bhagen]

I'm posting an alternative reason / solution for this error, just in case people like me have this issue and find this thread.

I had this issue today and opened Case #03907562.

Two items to note:
1. Before opening the ticket, I tried (unsuccessfully) to find where else that vmdk was mounted, by using powercli and linux searches on the esxi hosts.
a. I could have bypassed all that and just used the search feature at the top of the Datastore / Files section in vsphere. Yeah; I make things too complicated, too often!
b. In any case, these vmdks were *only* attached to the correct vms; they were *not* attached anywhere else.
2. So I initiated a sev 1 case with Veeam. The results?

**The drives on the original VM have Bitlocker installed!!**

Again; I'd made things too complicated.

So the answer in my case was to follow https://www.veeam.com/kb1459.

In a nutshell:
1. Do an instant VM recovery to another location, with a different name, *not* connected to the network, powered on.
2. In vsphere, attach a new hdd to that instant-recovered vm, copy the needed data from the bitlocker-ed drive to the new drive, then detach the drive.
3. Attach that drive to the original VM (or to any vm), copy the data from it to the correct location, and detach the drive.
4. Kill the instant VM, and be on your merry way!

Hope that helps somebody else!