Showing results for 
Search instead for 
Did you mean: 

Server 2012r2 - Hyper-V GRT Errors


I thought i'd join these forums and ask a question in case anyone can help me, Symantec support have had my call for over a week now with little responce other than taking more and more logs. 

Basically, we have Server 2012r2 running Hyper-V. There are 2 VM's, one a DC, and the other Exchange. 

When we purchased the product we were advised that Small Business Edition would do what we needed. Upon installing it we found that although it could talk to Hyper V, it did not come with the Hyper V agent, so we had to do our backups with the physical agent. All backups worked perfectly at this point, both at AD level and Exchange level. I was annoyed that although I was sold it as a Hyper V backup solution, we did not get the correct agent to do the recommmended backup type. 

3 months later suddenly my licensing panel goes from 'servers licensed 3, to servers licensed 1'. I ring Symantec and get told my many people (although there was a lot of confusion) that small business edition only is for 1 server :S...  (I rang the Symantec Rep at the distrubution and he told me that him and all his team have been selling it for 3 servers for years, and clearly at one point it was for 3 servers as the license did say 3 servers'  Symantec support were very keen to migrate me to 'Capacity Lite' edition, since I had no other option i took them up on it...  A symantec rep for the UK rang me back after a few days explaining loads of people had been onto him about this licensing change and were not happy about it. Its something to do with Veritas but anyways...

Being on Capacity Lite edition, this entitled me to the Agent for Hyper V. Great.. So I re-created my backup job  and set it running onto my RDX solution. The full backup worked perfectly and i thought great.

The next night, i do an incremental and i get 

'V-79-40960-38531 - During Granular Recovery Technology (GRT) operations, the necessary boot configuration files could not be loaded. Backups that were enabled for GRT may not be available for restore.'

The job completes with sucess with expections. And as the error message says, my files were not avaiable for restore, so this was a bit useless for me. 

Since i've not been getting too far with Symantec, i've been looking into it myself and i've found I get a lot of disk and ntfs errors in the last few mins of the backup job. 

I thought oh no and checked all the Raid Drives, everything is perfect. Not a single disk or ntfs error in the life of the server, by the way, everything in this setup is brand new although Live. 

I looked over the times where backups had ran for my 'physical agent' backups, no errors atall. 

The error logs refer to a volume that is certainly not a physical volume on the server, nor my RDX drive,  see one of the screenshots where it refers to volume //?/ Is it trying to mount the VM's VHD's to catalouge the files? Full Hyper V backups run perfectly with no disk errors. I think this is related to why i get the GRT errors.

I've currently made a seprate job for my DC which makes testing easier, as its incrementals take around 12 mins so i can troubleshoot issues. 

Could it be something to do with a system partition on the VM's? But then why does a full work.. ahh. So many questions :) 

Hopefully someone can help out. If i cannot get this going i'm going to have to do Agent based backups but I understand full recovery is a lot more difficult.  I've had to raise this call to an advanced tech guy as the basic ones were asking me to turn it off and back on again.. 



10 Replies

When you do an incremental

When you do an incremental backup of a VM, the full backup also needs to be mounted.  Make sure you have sufficient space in your staging area for this mount.

Hi, thanks for the responce,

Hi, thanks for the responce, when you say staging area, do you mean the backup location?



Staging area is different

Staging area is different from the backup location. It is a temporary location, where the VM is "staged" so that GRT information is extracted from the VM. This is usually C:\Temp on the BE media server. This location can be reconfigured under global settings.

Also, have a look @ these KB articles as well -

Re: Server 2012r2 - Hyper-V GRT Errors

Hi, thanks again for the help. I've had someone from Symantec help and we found that the job was mostly failing at the catalouge stage at the end, the rep thought it was because at the end of the job its 'unmounting something', or 'loosing access' to what it needs to, so the catalouge GRT job was failing with the error i posted above. He tried to run a backup with delayed catalouge turned off so the catalouging ran at the same time as the backup. For the first 2 days it worked perfectly and we thought the issue was resolved. Now its started doing the same again. 


I'll try changing the staging area location move, but i'll have to put in a large USB disk or something, my VM'S are around 250GB each, I certainly do not have that free on the C drive. (The VM's are stored on the 'E' drive (That has about 300GB free) Whats the general best pratice for the staging area?




The staging location should

The staging location should be a local, NTFS volume preferably without any file size limitations.

Re: Server 2012r2 - Hyper-V GRT Errors

Hi, so would that mean a USB external drive would be suitable?


Re: Server 2012r2 - Hyper-V GRT Errors

NTFS formatted USB drive should be fine.

Re: Server 2012r2 - Hyper-V GRT Errors

Great, i'll give it a go and let you know.





Re: Server 2012r2 - Hyper-V GRT Errors

Hi VJWare, i've made the changed you mentioned, and i'm afraid still no luck. However, i re-created the job, and it worked for 2 days, doing a full backup first, then it did 2 sucessfull days of incrementals. The the third day it had the same error as before, each incremental is on a different days RDX disk. Does it need to refer to the previous days incremental files to complete sucessfully?



The entire backup chain, full

The entire backup chain, full + all previous incrementals, must be present during the incremental backup.