Windows Server TechCenter >
Windows Server Forums
>
Windows Server 2008 R2 Hyper-V
>
VHD files on CSV
VHD files on CSV
- I've just started playing around with W2K8 R2 and Hyper-V + CSV. In my quest to find a backup solution before deploying this into production, I tried various methods to get a volume shadow copy (of the CSV) created, but was unsuccessful each time. As a last resort, I simply tried to XCOPY a VHD file (which was currently being used by a running VM), and it worked!
A couple of questions:
1) Aren't these files supposed to be locked when in use? I've never been able to copy an in-use VHD file off any other kind of storage before.
2) Would the resulting backup be the equivalent of the state of a physical server's disk should one suddenly cut the power to the server?
I reattached the copied VHD file to another server, and it it appeared to work fine. Would doing backups like this be too risky?
Answers
- Okay - a bit about CSV that might help your thinking.
Cluster Shared Volumes is a feature of the Failover Clustering engine that is only available with Hyper-V (that is the 'duh' statement).
Why does CSV exist? It exists as a first attempt solution to overcome the NTFS volume lock issue - thus allowing multiple servers to share a single LUN without them bumpting heads and causing volume and file corruption.
Without this - if you share a single volume among two servers you get immediate corruption as when a file is locked by a single server the entire volume is locked as well. Thus the 'other' server sees this as a bad thing and immediately tries to gets its control back and corruption happens as the two struggle over your files.
CSV uses one host in the cluster to handle and keep track of all the file locking - it is essentially the owner of the volume and its job is to make sure that everyone else plays nice.
I am guessing that if you target your VSS backup against this master server, you might have luck (I have not tried myself).
Now, your XCOPY method. I have been using XCOPY and the XCOPY diff feature for years to migrate file servers during the work day (without DFS). And no, a copy does not lock a file - it only reads. XCOPY opens the files read only - thus no locking contention.
This is a prefectly viable solution for backing up a machine - however it will fall short with certain types of machines - such as domain controllers, SQL servers, and any application server that holds a good deal of its work in memory and does not constantly write to disk.
The only thing you capture is what has been written.
You will also discover that if you begin taking snapshots, that you must alter your scripts to capture the differencing disks of the snapshot chain as well, or have good practice of deletign and powering off your VMs to merge the snapshot changes.
Either way, you will at least have a machine with installed applications that you can use - the question is in the state and quality of the contents. In some cases it is important, in other cases it is not important.
Brian Ehlert (hopefully you have found this useful)- Marked As Answer byAscendo Friday, November 06, 2009 6:34 AM
All Replies
- I think that you are talking Hyper-V Live Migration, you should have Cluster Shared Volumes in the Windows Server 2008 R2 and the VHD is stored in CSV.
More detail can be view
http://technet.microsoft.com/en-us/library/dd446679(WS.10).aspx - No I am not talking about Live Migration. I am talking about backing up VHD files which are hosted on CSV while the VMs are running, by simply copying the files.
you can use Windows Server Backup Tool to perform a living backup. However, you can't backup or restore an individual VM through Windows Server Backup.
you can refer to:Backing Up Hyper-V Virtual Machines Using Windows Server Backup
How to back up Hyper-V virtual machines from the parent partition on a Windows Server 2008-based computer by using Windows Server Backup
http://support.microsoft.com/kb/958662
How to enable Windows Server Backup support for the Hyper-V VSS Writer
http://blogs.technet.com/askcore/archive/2008/08/20/how-to-enable-windows-server-backup-support-for-the-hyper-v-vss-writer.aspx
You also can use System Center Data Protection Manager to backup all the VMs or an individual VM.Thanks for the links, but none of them are applicable to Hyper-V R2 + CSV.
- Okay - a bit about CSV that might help your thinking.
Cluster Shared Volumes is a feature of the Failover Clustering engine that is only available with Hyper-V (that is the 'duh' statement).
Why does CSV exist? It exists as a first attempt solution to overcome the NTFS volume lock issue - thus allowing multiple servers to share a single LUN without them bumpting heads and causing volume and file corruption.
Without this - if you share a single volume among two servers you get immediate corruption as when a file is locked by a single server the entire volume is locked as well. Thus the 'other' server sees this as a bad thing and immediately tries to gets its control back and corruption happens as the two struggle over your files.
CSV uses one host in the cluster to handle and keep track of all the file locking - it is essentially the owner of the volume and its job is to make sure that everyone else plays nice.
I am guessing that if you target your VSS backup against this master server, you might have luck (I have not tried myself).
Now, your XCOPY method. I have been using XCOPY and the XCOPY diff feature for years to migrate file servers during the work day (without DFS). And no, a copy does not lock a file - it only reads. XCOPY opens the files read only - thus no locking contention.
This is a prefectly viable solution for backing up a machine - however it will fall short with certain types of machines - such as domain controllers, SQL servers, and any application server that holds a good deal of its work in memory and does not constantly write to disk.
The only thing you capture is what has been written.
You will also discover that if you begin taking snapshots, that you must alter your scripts to capture the differencing disks of the snapshot chain as well, or have good practice of deletign and powering off your VMs to merge the snapshot changes.
Either way, you will at least have a machine with installed applications that you can use - the question is in the state and quality of the contents. In some cases it is important, in other cases it is not important.
Brian Ehlert (hopefully you have found this useful)- Marked As Answer byAscendo Friday, November 06, 2009 6:34 AM
