VeeamFLR, 5.5hrs later "Access to the Path is Denied"

[Hariseldon1]

I have been trying to conduct a VeamFLR of a my personal biggest VBK (1.6 TB) to a new larger hard drive.

I am trying to FLR restore two smaller drives ( 500 GB and 1 TB) to a single larger 1.5 TB vmdk

Until now all my Veeam restores have been volume based restores. This time I am trying to "combine" such that the old 500 GB drive (X:\) and old 1 TB drive (Y:\) are restored to a new larger 1.5 TB drive (A:\)

My restore plan:
Old 500 GB drive "X:\" --> restored to new 1.5 TB drive but in the sub-directory of "A:\X\"
Old 1 TB drive "Y:\" --> restored to new 1.5 TB drive but in the sub-directory of "A:\Y\"
^^naturally... A:\X\ and A:\Y\ would not inherit from parent A:\ seeing as how each subdirectory represents separate old drives

I wanted to use Veeam VBK as source because I know you're really good about retaining NTFS permissions etc.
(I hoped VeeamFLR would just work and properly handle restoring permissions etc)

Good news: the 500 GB drive FLR'd perfectly!

Bad news: 5.5 hours into the 1 TB drive FLR, I get this odd popup window that saiys "Failed to Transfer C:\VeamFLR\ComputerName\Volume0\path\to\the\file.ext. Access to the path is denied. Continue? Yes or No"

So. If I read that right. FLR is restoring using C:\VeeamFLR\ mountpoint to transfer files to the destination I picked out?

(I feared that was the purpose of the C:\VeeamFLR\ directory)

Anywho, how can I complete this FLR of the 1 TB drive in the vbk file?

If you PM me your email address, I can send screenshots of the FLR error popup window.

Thanks!

[Dima P.]

Hello Hari.

Old 1 TB drive "Y:\" --> restored to new 1.5 TB drive but in the sub-directory of "A:\Y\"

For such amount of data I'd recommend volume level restore instead of file level restore. Volume level recovery works on a block level which simply has better performance.

Bad news: 5.5 hours into the 1 TB drive FLR, I get this odd popup window that saiys "Failed to Transfer C:\VeamFLR\ComputerName\Volume0\path\to\the\file.ext. Access to the path is denied. Continue? Yes or No"

Looks like an issue that should be investigated by our support team.

If I read that right. FLR is restoring using C:\VeeamFLR\ mountpoint to transfer files to the destination I picked out?

On the first place we make this directory visible for the ease of use - you can restore files by drag and drop from the backup to your live operating system (btw copy/paste from the mounted folder works faster than restore via backup browser).

If you PM me your email address, I can send screenshots of the FLR error popup window.

You can submit a support case directly from product UI. Open Control Panel > Support > Technical Support to raise a ticket.

[Hariseldon1]

Thank you Dima!

I submitted my support ticket (#03149318 ) and referenced this forum thread.

I completely agree! for that amount of data I too have always done a volume level restore

I Suppose I could to VLR then afterwards move everything into the sub-directory "A:\Y\" and manually make sure I correctly replicate all the attributes/permissions to that sub-directory

I hoped to let Veeam do that heavy lifting and [[correctly as usual]] restore all the important stuff including the data

Alternatively, I will also try dusting off my knowledge-base of xcopy and consider a scripted copy from the legacy drive. Although this is the most painful of all my options

I have screenshots for your support team, can you look up ticket #03149318 and email me whom I should send anything additional to?

[Hariseldon1]

another VLR option, I could mount VHDX volumes and VLR to them. That would let Server 2012 R2 dedup the two large 500GB and 1TB vhdx files.

I would like to keep the layers to a minimum. Mounting vhdx files in a vmdk is rather a kludge just to benefit from Windows Dedup. I think Dedup benefit would not be as drastic as directly on the files themselves.

You have no idea how many times I have kicked myself in the behind for setting this up as vRDMs back in ESXi 4.0

I am very sorry for doing that. But I did enjoy my epic 8 year esx host uptime
(prof dev lab everyone, never run a production host without regular updates)