6.8GB file restore job is going to take 16 hours??

[bhagen]

I think I'm doing something wrong.

Background:
*I have VBR 9.5.0.1536 running on a physical box at "site a" on the west coast.
*I have the VBR console running on my PC at site a.
*I have a site b on the east coast.
*From site a's VBR install, I've got backup jobs for site b that are working properly. I have proxies at site b, backup storage at site b, a vmware stack at site b. Jobs are fast and working fine.

I just got a request to restore a folder in site b. So I spun up a restore job on my pc (in site a). It took about 5 minutes for the list to populate.
Found the folder I wanted - it's about 6.8GB - and chose "copy to...", and pointed it to a folder on a VM at site b. (They wanted it restored to a different location so they could compare files with the current folder.)
Clicked GO, and the "time remaining" fluctuates between about 4 hrs and 16 hrs.
So far, after 1Hr17m I've copied 590MB of 6.8GB.

What am I doing wrong? This should take about 10 minutes.

Thanks!

[csydas]

Hey,

Check out step 1 here: https://helpcenter.veeam.com/docs/backu ... tml?ver=95

The disks get mounted from the console used to initiate the restore:

"Veeam Backup & Replication mounts disks of the VM from the backup or replica to the backup server or machine on which the Veeam Backup & Replication console is installed, under the C:\veeamflr\<vmname> folder."

Could you install just a console at site B, remote in, and do the restore from there? It's a little cumbersome, but you should see a world of difference.

If you've been using guest indexing, Enterprise Manager ought make this simpler for your situation: https://helpcenter.veeam.com/backup/em/ ... store.html

[bhagen]

This is "solved". I finally opened a case with Veeam and they told me just what csydas mentioned. It's a bit strange that it works this way, but that's how it is, so the answer is - indeed - to spin up a console on a machine in site B and run the restore from there. Very clunky, but again, it is what it is, I guess.

However, even from site B, restoring a copy of that folder to a server in the same site was still going to take about 6 hours. But a restore to the server that the veeam console is on took roughly 15 minutes, and then a copy across the lan to the server it needed to go to took another 5 or 6 minutes.

I sure hope the behavior is different if I do a "real" restore...simply restoring a folder to it's original location and overwriting what's there. If not, then this is going to be pretty useless in an emergency situation. And I can't imagine that restoring an entire VM would even work!

Time to do some experimenting.

[ITP-Stan]

I think entire VM restores use the Proxy server mechanism, in contrast to the File Level Restore options that just mount the backup on the console server to copy/restore files.
I suggest you test this out to confirm.
Perhaps you can redesign your backup infrastructure (2 consoles perhaps) to make the best restore performance possible.

[Gostev]

Just wanted to add one comment on the original issue. Starting from 9.5, before restoring the selected files back to the original VM, we mount a backup to the mount server associated with the corresponding backup repository, and copy required files to the target VM directly - specifically to ensure that restore traffic is isolated to the remote site. The issue in this case is that instead of doing in-place Restore, you are using Copy To operation (which uses regular Windows file copy API running on the backup console, as opposed to our direct restore engine).

[bhagen]

Thanks everybody; I'm finally admitting to myself that I need to refresh my Veeam skills! I did all my veeam training back in the v7 to v8 days, and have just kept upgrading versions thinking "I know this stuff". It's been going "ok", but U3 turns out to be the tipping point for me; a *lot* has changed since u2 -and- I'm using different features at this point, so it's time for me to look into taking a class or something.