Urbackup Hyper-V Client


#1

hi:
I just upgraded my Hyper-V VMs to Microsoft version 8 to support CBT in Windows 2016.
I installed new Urbackup Hyper-V Client.
I configured Image backups and instructed in the Docs.
All seems configured correctly.
Issue is every time I run the first Full IMage backup for my Hyper-V Windows 2016 VM I get following error as soon as backup starts:

03/17/19 11:55 INFO Starting unscheduled full image backup of volume “IDE:0:0”…
03/17/19 11:55 INFO Basing image backup on last incremental or full image backup
03/17/19 11:55 WARNING Error retrieving last image backup. Doing full image backup instead.
03/17/19 11:55 INFO Loading ZIP metadata from urbackup/mbr_data_printweb2_2312–02–IDE_0_0.zip
03/17/19 11:55 INFO pnhv02[printweb2_2312–02]: Loading MBR zip file…
03/17/19 12:00 ERROR Error loading ZIP file MBR: CANNOT_OPEN_FILE
03/17/19 12:00 INFO Time taken for backing up client pnhv02[printweb2_2312–02]: 5m 3s
03/17/19 12:00 ERROR Backup failed

What does it mean " |ERROR |Error loading ZIP file MBR: CANNOT_OPEN_FILE|"

What is the issue causing this and how can I correct this?

Thanks for your support


#2

Sorry, you are having problems. It has a 5min timeout for creating the snapshot (hard coded, unfortunately). The most simple explanation would be that creating a production checkpoint takes longer than 5min on your Hyper-V server (for other explanations a debug-level log file from the client would be helpful).

You can check this by running following in powershell:

cd C:\Program files\UrBackup
.\hyperv_snapshot.ps1 -VmName printweb2_2312–02

#3

hi uroni:

i was able to fix this issue by deleting the clients and re-adding them back and rediscovering and now the server is backing up fine.

however a second hyper-v server is having a different issue.

i installed hyper-v client and configured identically as first server but it will not connect to my backup server. I have confirmed that the backup hostname/IP and internet passwords are correct.
I also confirmed that my client can telnet to backup server on port 55415.
It shows as offline in Status tab.

Do you have any idea where I can begin troubleshooting this or check logs to see what may be issue?

please note I had to remove and re-add the client name so maybe the reference on the backup server to the client is somehow pouting to an old reference. If so how can I refresh this?


#4

A server restart might help (or waiting 5min for the client to go offline on the server).


#5

hi

I got the backup started finally on this client by removing and re-adding the client.

But now I am getting same error as before:

Basing image backup on last incremental or full image backup
Error retrieving last image backup. Doing full image backup instead.
Loading ZIP metadata from urbackup/mbr_data_printweb1_2312–01–IDE_0_0.zip
pnhv01[printweb1_2312–01]: Loading MBR zip file…
Error loading ZIP file MBR: CANNOT_OPEN_FILE
Time taken for backing up client pnhv01[printweb1_2312–01]: 5m 5s
Backup failed

To verify I manually ran the powershell script .\hyperv_snapshot.ps1 and it did create the urbackup checkpoint properly so that does not appear to be the issue.
Also when I ran the backup I was watching the Hyper-V console very closely and it never attempted to even create the snapshot as I never saw checkpoint trying to create. I did see it when I ran the powershell manually.
So something is failing even before the checkoint is attempting to create atleast from my observation.

Do you have any idea what may be causing the “Error loading ZIP file MBR: CANNOT_OPEN_FILE” error ?

thanks for your help


#6

Hey mate - had problems with the Hyper-V backups previously. Moving to the latest version seems to have resolved. However one of the issues I found was that the UrBackup client service kept crashing on the Hyper-V node. Can you mark the service as “Restart” if it fails? This will ensure that UrBackup keeps trying again.


#7

Could you try if using this server version fixes this: https://www.urbackup.org/downloads/Server/2.3.8/
I increased the timeout to 60min there (from 5min)


#8

I noticed a pattern for all my issues.
In my setup I have 2 Hyper-V servers which I replicate VMs from one server to the other.
So the client detects all the VMs from both servers. So they are duplicated during detection as they are replicated across both servers.
So if I just install on 1 Hyper-V server it works. But once second server is configured and the duplicate VMs are detected by Hyper-V client and then to Server all issues arise. All backups fail and then I start to see the issues that I presented here.
As a test I manually deleted the duplicated VMs which seems to have resolved the issues and then backups started to work. But after sometime the client rediscovers the deleted duplicated VMs that I deleted and again all issues with backups arise again.
I can only assume that even though its on different Hyper-V servers the duplicate VMs are causing issues with the logic for accounting for them.
I am not sure if the Hyper-V client was designed for such a situation but it may need some retooling.
For any Hyper-V servers that are not in a replication mode I am not seeing this issue.
I think the Hyper-V client design should give the option to either auto select all VMs or to manually select which VMs to backup which would then allow you to exclude any duplicates. Most of the other commercial products I have used to backup VMs work in this fashion so I am not sure why this was not built in same way.
Perhaps you can include this in next release.
Please update.


#9

I am not sure i understand the reason why replicating and running both the clone and the original vm at the same time.
If you don’t have too much clients, i d try renaming all the clients on one hyperv (you can rename only the urbackup client name).
So that they appear as different for the server.


#10

hi
the urbackup client name is not the issue, its the VM name that is the duplicate that is the issue.
is there any way to resolve the duplicate VM name inside the hyper-v server to avoid the duplicates ?


#11

Wrt. to adding all vms: The idea is that backup can be disabled on the server for vms that you don’t want to backup (I put them into a group named “hyper-v disabled”). But your are correct, being able to select them would perhaps be better.

Have you tried the 2.3.8 server I posted?

Having the same VM on multiple backed up servers might cause problems, but I cannot immediately see how it causes the specific problems you posted about.

For the Hyper-V client I implemented that a client automatically renames itself if its UUID is the same across servers. That was implemented so that it does not add a VM as new client merely because it migrated.

I’ll have to think about how to fix this, but it’ll have to take into account where the VM was last seen running. Does it somehow prevent one from running the same VM on multiple Hyper-V hosts? And may I ask how you mirrored the VM such that it is on multiple Hyper-V hosts?


#12

hi
i installed the 2.3.8 version which helped with the MBR timing.
but again issue is with the hyper-v vms that I am replicating via hyper-v replication.
once i backup 2 hyper-v servers that have the VMs dupliated via repliation what I am seeing is that one server will work but the second physical node - all those VMs just hand on the MBR stage and never start the backups. I have now tested this behavior on 4 different servers (2 pairs) with identical results so I can confirm this is a bug in the logic for the latest hyper-v client.
whenever I just have a standalone hyper-v with no replication the backups work great.
seems as i said the duplicate VMs that are being replicated is causing issues. The MBR stage never completes even after 60 mins as you updated in v 2.3.8. and then backup just fails.
As a test I removed the 1 client from the pair and sure enough the other server VMs that were failing started to finally backup. The MBR stage passed and backup started. So clearly the duplicate vms via replication in Hyoer-v is causing issues with the logic of hyper-v client/server.
Can you perhaps allow me to check the VMs instead of just auto detecting all possible VMs. SO then I can manually select the VMs and avoid having duplicates. Perhaps this can be used as a workaround to get this issue resolved?


#13

as a followup to my post, is there any way I can exclude specific hyper-v client VMs from being discovered? Perhaps there is a file where I can put the vm names from being excluded and avoid this duplicate issues?
please let me know what can be done as all my hyper-v replica backups are failing with this duplicate issue.

All other standalone hyper-v servers are fine

thanks