21 Haziran 2012 Perşembe 05:54
I'm designing the backup and restore solution for VM in Hyper-V. I have couple questions:
- I see in
http://technet.microsoft.com/en-us/library/dd252619%28v=ws.10%29 that virtual network configuration is not part of a full Hyper-V server restore. Are there APIs(or Powershell) available to allow us to query the virtual network configuration and redefine
it as part of the restore process? (Is there any reason why Hyper-V writer cannot restore the virtual network by itself? In my opinion, without the network restored it's not a completed restore...)
- Is it possible to restore an individual virtual disk for a VM without restoring the entire VM? For example, VM A has c.vhd and d.vhd, can I only restore d.vhd using Hyper-V VSS writer? It's said in this
that "During the processing of the PreRestore event, the Hyper-V VSS writer turns off and deletes any VMs that are about to be restored. " In many situation we only want to restore the data disk instead of the system disk. I guess we can replace a single
vhd file manually, but it could be good if Hyper-V VSS writer supports this so that it can be done in a formal way automatically.
- If my original folder for "c.vhd" and its snapshot file "c.avhd" is in "d:\Virtual Machines", but after I copied both files to another folder e:\MyBackup, will c.avhd's parent disk still be the one in original folder "d:\Virtual Machines"? Or it will use the one in the same new folder as its new parent disk? This is critical from a backup point of view.
Thanks a lot!
- I see in http://technet.microsoft.com/en-us/library/dd252619%28v=ws.10%29 that virtual network configuration is not part of a full Hyper-V server restore. Are there APIs(or Powershell) available to allow us to query the virtual network configuration and redefine it as part of the restore process? (Is there any reason why Hyper-V writer cannot restore the virtual network by itself? In my opinion, without the network restored it's not a completed restore...)
21 Haziran 2012 Perşembe 07:55
I know this is not directly answering your question, however I hope that it will serve as an even better answer than what your asking.
If you already have a backup solution in place for physical machines, use the same procedure for your virtual machines. Even tho you might deploy some sort of full Virtual machine backup, the amount of data stored, the handling of it and the restore itself will proberly be longer in time. Then on top of that comes the administrative overhead of maintaning a seperate backup procedure for your virtual machines, maybe even a seperate backup system. Including regular checks, logs etc.
The company I was previously employed at spent quite time trying to figure out the best possible solution for backup for the virtual machines, and ending up following the simple path of just using the exact same methods as for physical servers. - No image backup. Do note that this was for production servers only. Development servers was handled differently due to different requirements :)
Standard file backup will handle everything within the server, like any other backup will.
System state will be used in case of complete system crash. (rarely happends with VM's)
In that case, recreating the virtual machine, installing basic O/S, installing backup agent - restoring VM full. Would take a less time than trying to apply the latest image from backup, getting it to run again etc.
Even if your talking a bunch of servers, I would still prefer it the simple way. Less systems and procedures to maintain. If you have a bunch of servers, you optimize on the new server deployment, but if your running alot of virtual servers, then you proberly got this part nailed allready, meaning that its not a new system to introduce. Your using well known functions, which are tested/used on a regular basis. Your not deploying systems which are only used in case of disaster basically.
Remember only to use snapshots for development and/or short periods of time due to performance penalty.
If you cant use this answer for anything, I do appologize for wasting your time.
25 Haziran 2012 Pazartesi 02:09
Thanks for your reply and it does open my view of the issues for backup VM.
But it's not the exact answer for my questions. I believe we should utilize the unique capability provided by Hypervisor to backup and restore VMs instead of using a traditional "in-server" backup agent inside each individual VM.