I've just installed and configured Backup Exec 2014 on a Windows 2012 R2 Hyper-V server and I'm receiving the following exception when I attempt to run a differential backup of my VMs with GRT enabled:
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.
No data is available for restore for these differential backups. Full backups succeed without issue. This exact error happens on both environments that I've installed BE 2014. Guest VMs are all Gen 2 VMs and both have 2012 and 2012 R2 guest VMs.
Thanks! I reviewed the KB and I don't see that it applies. VMs are supported OSs (2012 and 2012 R2) with no reported disk issues - VMs are online and running at the time of backup.
I'd normally call in for support, but we're in a trial mode with these before having our clients buy the product, so I have no support options.
We've got the same issue with the following setup:
- 2x IBM System x3650 M4 servers;
- 1x Running VMware ESXi 5.5 Update 1 with the latest patches
- 1x Running Microsoft Windows Server 2012 R2 with the latest updates, VMware vCenter 5.5 with Symantec Backup Exec 2014 Service Pack 1 and the latest updates.
There are 4 guests running on the VMware ESXi server are:
- 1x Microsoft Windows Server 2012 R2 with the latest updates in EFI mode as Domain Controller - This server produces the exact same error as above;
- 1x Microsoft Windows Server 2012 in EFI mode as Exchange Server with Microsoft Exchange 2010 Service Pack 3 Update Rollup 7 - This server produces the exact same error as above;
- 1x Microsoft Windows Server 2012 R2 with the latest updates in EFI mode as File- & Print Server - This server produces the exact same error as above;
- 1x Microsoft Windows Server 2008 R2 with the latest updates in BIOS mode as Application & Database Server - This server does NOT produces the exact same error as above, but reports it's backed up successfully.
Please provide some information on howto resolve this issue.The password for the ZIP logfile is in your PM.
i am unable to download the Zip file, I request you to contact support, if you have an active support you can still open a new case. I see this is a job log, we would need both jo log and debug logs.
I've already opened a case: 07391871
But I'm receiving standard solutionson phone and PC (like checking permisions and such), which I've mostly already doublechecked to be sure. We know what we are doing and if this wouldn't be some odd bug or issue we wouldn't be contacting you.Like stated: Any Server 2008 R2 server backs up just fine and completes successfully. Only Server 2012 and 2012 R2 have the issue, no matter whether it's a DC or member server.
I've already been stroubling with this issue at a customer's site for 2 weeks now (pre-SP1) it gave me errors and wasn't able to backup at all, now I'm still having issues. Ever since Symantec Backup Exec 2012 it's a mess and the software is full of bugs. Please, fix the software, or we will be finding another software supplier, who can provide us with working backup software.
I have been having the same problem and I believe I have the Answer.
When you use EFI instead of BIOS windows creates GPT disks. This is not support by the backupexec Vmware agent (see the link below). To check that you have open an administrative cmd windows. Type diskpart. Then type list disk. You should see a star under the GPT section.
I had a case open with symantec and the support representative told me there will be a hotfix "within one or two months".
I can confirm that I have the same problem with a server having an efi partition. The efi and the system partition are gpt. I just retried to use the GRT- option for this server again, hoping Symantec solved the problem in sp1 but getting error V-79-40960-38531.
It is so bad, that there are so much limitations in using the gpt option. Extra backup jobs for nearly every server neccesary due to that.
If someday GRT is working like suggested in the high color advertisements, it would be great step for BE.
I also know the really long process of the symantec support, when trying detect a problem reported to the forum. They try a lot of steps, already done by the user again. Than they collect tons of megabytes debugging and logging information. When the problem is detected it needs a lot of time to fix them and release a bugfix. Sometimes a had alredy forgot that I reported this problem, when they told me it was fixed, I just was livinig with the workarround.