Skip to main content
  • EN

I have a Hyper-V VM in TN. Our VBR is in TX. I set the backup job for said Hyper-V VM to use on-host proxy and store data to a repo local to the Hyper-V VM in TN.  Started the job ~1940 CST and let it run, it was stuck on 50% completion, and stuck on hard disk 1 processing (like below) for almost two hours. I ended up stopping the job, not gracefully, but immediately.

 

7:41:16 PM    Hard disk 1 (931 GB) 1024 KB read at 1 MB/s    01:49:24

 

I’m using an NFR to test this because we have a Hyper-V VM in TN that we want to bring to TX but to VMware using Instant Recovery (Instant Recovery to VMware vSphere - User Guide for VMware vSphere (veeam.com))

 

I was directed here for possible help. I have logs here https://we.tl/t-CHOg5OnEjz  (make sure to click Agree if prompted, I tested it out using WeTransfer).

 

If anyone could point me to the direction “why” the job froze and didn’t process the disk, I’d be grateful.

 

EDIT: P.S. - The second hard disk processed fine..

 

7:41:16 PM    Hard disk 2 (931 GB) 5.9 GB read at 143 MB/s    00:59

"The Hyper-V host was the proxy (on-host) which the VM is on. Had I used the VBR as the proxy then it would have been “off-host” and traffic would more than likely traverse the WAN. The repo is local to the Hyper-V host. After I got my initial backup, I was going to do backup copy to TX and then do instant recovery." <- I understand that, thus why (probably) your Agent job was traversing the WAN. My point was using a VM-based job with your on-host setup wouldn't 😊 My guess is you should then be good to go. Keep us posted. 

We ended up not doing this, I had this idea instead, we brought up a small VM, migrated the SQL express DBs over to it, now it’s on VMware, and not on Hyper-V. Case closed.

Great idea @jaceg23 . Glad you got it sorted.

 

Very interesting solution and glad you solved it.

Comment


Terms & Conditions