03-21-2013 03:54 PM
Hi all,
We are a small shop running a server with Windows 2012 Standard with Hyper-V. We have 4 hyper-V VMs running and we have SSR 2013 installed on the Windows 2012 host. I have searched through these forums and have found that SSR 2013 is capable of backing up the Host with the VMs. I have run backups on the Windows 2012 host several times and SSR always completes successfully and creates a recovery point.
I was looking in the event logs and find the following 2 errors for each VM that is on the host when SSR is run.
Error 1 "Requester reported unsuccessful backup for the virtual machine 'XXXXXXXX'. (Virtual machine ID 064918AE-59A8-4D4D-8D11-7A70D5CEC1AF)" XXXXXX is the name of the virtual machine.
Event ID 10170 Source Hyper-V-VMMS
Error 2 "The operation failed"
Event ID 16010 Source Hyper-V-VMMS
Given the errors above, is SSR 2013 performing proper backups with the VMs in a consistent state? Can someone explain the significance of these errors? I don't want to find out in the future that SSR was not properly backing up the host machine and its VMs.
Thanks!!,
CQ
Solved! Go to Solution.
05-24-2013 10:22 AM
I updated SSR 2013 to SP1 on our server and the Hyper-V failure errors in the logs have disappeared. I will continue to monitor the logs for a while but it looks like SP1 corrects the issue.
03-22-2013 03:21 AM
Have you looked in the Hyper-V specific event logs for a more detailed error/message? (Event Viewer - Applications and Services Logs - Microsoft - Hyper-V)
Unfortunately I don't have access to a Windows 2012 server running Hyper-V so I cannot test this myself.
You may want to consider contacting Microsoft about this issue. Or open a case with Symantec support.
03-22-2013 06:39 AM
03-22-2013 07:06 AM
You could try posting in the Microsoft forums to see if anyone other there has any ideas.
http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/threads
05-22-2013 02:35 PM
We are also in the same position (have the same errors).
My suspicion is that Symantec system recovery is not fully tested with WIndows Server 2012.
The reason I think this is that they STILL don't support backup exec on SQL 2012 or Windows Server 2012 until SP2 (which as of 5/22/2013 is still not released).
Symantec is really dragging their feet on support for new products.
See here for more details: https://www-secure.symantec.com/connect/blogs/new-beta-program-backup-exec-2012-r2
You might want to start looking for a backup software that has a better track record of keeping up to date with various Microsoft product changes.
05-23-2013 12:13 AM
You are right in the sense that BE does not currently support Windows 2012 (unless you are enrolled in the Beta Program for SP2/Capri) but SSR does support it (http://www.symantec.com/docs/TECH201318).
I would encourage you to update to SP1 for SSR 2013. If this does not help, open a case with support so this can be investigated further.
05-23-2013 01:09 AM
Please upgrade to SSR 2013 SP1. Also, do let us know if Integration Services are installed for each VM. In the properties dialog of the VM, from either Hyper-V Manager or SCVMM, look on the Integration Services tab and ensure that “Backup (volume snapshot)” is checked (see screenshot below).
05-23-2013 06:48 AM
Please check the technote at http://www.symantec.com/docs/HOWTO48572 for requirements to be met in this case.
05-23-2013 07:43 AM
We have met all those requirements. Only thing left to do now is to try SP1 which we will do over the next few days. Apparently the thing forces a reboot of the server which we were not expecting.
05-24-2013 10:22 AM
I updated SSR 2013 to SP1 on our server and the Hyper-V failure errors in the logs have disappeared. I will continue to monitor the logs for a while but it looks like SP1 corrects the issue.
05-27-2013 07:14 AM
Any updates ?
How is it working ?
05-27-2013 10:53 AM
The error has vanished. When I open Hyper-V Manager and observe the status of the Virtual Machines during backup I see Backing Up followed by succeeded as SSR completes. I used to see failed. I believe my particular issued has been resolved.