Because you are dealing with virtual machines you have more options available to you than you did when backing up traditional tin servers. What approach you take depends on whether you need to recover files, databases or just an entire server, what your budget is and how you configure the storage of your VM’s. Oh yes, and your budget.
In-VM or On-Host Backup?
What does that mean? There are two places you can do your backup from.
On-Host Backup
This allows you to capture selected VM’s on the host as they are running. There’s some catches to that which I’ll come back to later. The benefit of this approach is that it’s a simple hammer that can hit everything. If you need to recover all of your VM’s then you can do it. But you have no knowledge of the VM’s contents nor the ability to recover single files from within the VM. To do that with this approach you have to recover the entire VM to an isolated network, log into the VM, and then grab the files you need.
This on-host backup really needs to be Hyper-V aware, i.e. use the Hyper-V VSS (volume shadow copy service) writer. When your backup software tries to backup the VM then the VM will be quickly brought to a “quiescent” state. This is accomplished at two levels. The parent partition uses VSS to access the VHD files. The integration components feature a backup integration. This allows the VSS writers in the VM to bring file services, Exchange, SQL (and any other VSS aware services) into a brief restful state too. A snapshot of the VM can then be taken using VSS and the backup software get’s the VM’s running state. Note that this quiescent state is not noticeable. Odds are you are already using this VSS technology to backup Windows file servers, Exchange and SQL and haven’t noticed a thing.
You probably noticed a catch here. The backup causes no noticeable downtime to the VM if (a) VSS is available in the VM operating system and (b) the backup integration component service is running in the VM. That means you must be running Windows Server 2003 SP3 or later in the VM and you have installed the IC’s and left the backup integration service enabled. All of the volumes in the VM must also have VSS enabled.
If you have VM’s that don’t meet both of those requirements then they must be stopped (saved state) before a backup can commence. This will include, for example, VM’s that meet these conditions:
- VM’s that do not have the VSS service, e.g. Linux or Windows 2000
- VM’s that do not have the IC’s installed and the backup integration service enabled
- VM’s that do not have VSS enabled on all of their volumes.
Some types of storage cannot be backed up in this way. Passthrough storage is not a file like a VHD so that is excluded from this approach. And you need to be aware of remote storage that is directly connected to the VM. It is not connected to the parent partition so it cannot be backed up with this approach.
You should also be aware that virtual network configurations are reportedly not backed up with this approach.
However the two big benefits are:
- You can do an “iron”-level backup of a VM. If you lose the VM then you can instantly restore it to a known state with no need to build new VM’s, install software, patches, etc.
- As I’ve mentioned you should not use snapshots in production. Using a VSS backup on the host you effectively get snapshot functionality.
In-VM Backup
The second approach is to do an in-VM backup. This is pretty much doing what you’ve always done with your physical servers. You log into the VM and do the backup from there. Here are the benefits:
- You can use whatever backup tool you want that is installed in the VM. It does not need to be Hyper-V VSS aware. Although it doesn’t need to be Hyper-V VSS aware you should take steps to ensure you can still backup open files and backup databases (mail, Oracle, MySQL, etc) consistently.
- You can backup remote storage that is not connected to the host, e.g. where a VM directly connects to iSCSI storage.
- You can use this approach for Linux/Windows 2000/etc and where you do not (or cannot) install Integration Components, do/cannot not have VSS enabled on all volumes or do not/cannot enable the backup integration service.
- Best of all, this approach allows you to selectively backup files and allows you to selectively recover files or databases. This is because the backup is in the VM and thus is aware of the data in the VM.
Recovering a lost VM with just this approach will be time consuming. You would have to:
- Build a new VM and set up the operating system to be identical to the previous version including service pack.
- Do a complete restoration of the backup data.
- Test like crazy to ensure everything is OK.
Best of Both Worlds
The best solution is to do both types of backup. You can do an on-host backup maybe once a day, once a week or once a month for all VM’s, depending on major changes on those VM’s. Identify those VM’s that you need to backup/recover on a granular level, e.g. shared SQL servers, Exchange, file servers, etc. For those machines you should configure in VM backup. Of course, there are those VM’s that don’t meet the requirements for on-host backup. Exclude them from the backup set and set up in-VM backups for them. It might make sense to do an on-host backup once in a while for these VM’s. This will require a scheduled maintenance window where you put the VM’s into a saved state to run the backup. This will allow quicker recoveries in a major disaster for these VM’s.
Here’s how you can handle various recoveries now:
- VM destroyed: Recover the last backup of the VM from the host level. Restore data from in-VM backup that has changes since that on-host backup. This will bring the VM back up to date, e.g. SQL databases.
- Data lost from a VM, e.g. SQL database, files, etc: Recover the data from the in-VM backup.
- Host destroyed/Office Destroyed: Recover the complete on-host backups to another host or another host in another office. Remember to configure the virtual networks.
Backup Tools
If you are operating on a shoestring then the solution for you is Windows Server Backup. You can use this to backup your host and VM’s. It’s not the prettiest solution but it works. VM’s that are backed up at the host level that are not compliant with all the requirements will need to be put into a saved state either manually or via a (PowerShell) script. In VM backup is complicated because you need to provide storage for the backups. That means using either iSCSI or VHD’s and that adds complexity to your storage solution.
The ideal solution in a Microsoft centric network is Data Protection Manager. DPM 2007 SP1 can backup Windows Server 2008 hosts and clusters. It can also backup Windows Server 2008 R2 hosts and clusters. However the caveat for Windows Server 2008 R2 clusters is that it cannot backup VM’s that are stored on Cluster Shared Volumes (CSV) and it is not Live Migration aware. DPM 2010 (expected to RTM in Q2 2010 and in beta now) will resolve that.
DPM installs agents on the host and in the VM’s. Licensing costs are reduced with System Center Enterprise (host and 4 VM’s on the host) and Datacenter (host and all VM’s on the host) CAL’s/SAL’s. You can configure protection sets with schedules of your choice and your hosts/VM’s/data will be backed up to the disk storage set(s) on the DPM server. For those VM’s that are not compliant with the Hyper-V VSS/IC requirements, DPM will automatically put them into a saved state and do the backup. A nice touch with DPM is that it will allow replication of the backed up data to another DPM server. This could be in a remote location, e.g. a hosting company, and have a tape drive attached to stream data from disk to tape for archival purposes. DPM is quite clever with backups. It backs up at a block level. It only backs up differences rather than entire files. It can also compress data on the wire.
What if you’ve made an investment in other backup technologies and want to keep it simple or you have lots of non-Microsoft technology? You have a few options:
- If your backup vendor has Hyper-V VSS compliance then do what I’ve talked about above, picking and choosing between in-VM and on-host backups. Windows Server 2008 R2 CSV is still pretty new so verify that the vendor also has compliance for that if you are deploying an R2 Hyper-V cluster.
- If your backup vendor does not have Hyper-V VSS compliance then you can only do in-VM backups. It’s not ideal but it’s what you’ve been doing up to now with your physical servers so nothing has changed. You’re just not able to take advantage of snapshot style functionality at the host level for your VM’s.
- Maybe add DPM into the mix for host-level backups only and do daily/weekly/monthly backups. That way you get an “iron” level backup of the VM for those dreaded scenarios when you have to do a complete recovery.
Things To Watch Out For
- Patches. No matter what your backup solution is, get all of the latest patches. DPM 2007 SP1 requires a hot fix for W2008 Hyper-V support. Install the June 2009 rollup. DPM 2010 requires a hotfix on W2008 R2 Hyper-V RTM clusters too.
- DPM 2007 SP1 isn’t the completed solution for W2008 R2 clusters due to the lack of support for CSV and lack of Live Migration awareness. If you are deploying DPM 2007 SP1 on W2008 R2 clusters then have your licensing set up to upgrade to DPM 2010 next year.
- The Windows Server Backup approach requires a registry change on the host. Complete instructions are on the MS site.
- Even if you only do in-VM backups, ensure your vendor will support it. Just because it’s in VM and should be pretty much identical to backing up a physical box, it doesn’t mean the vendor will actually support a VM backup.
- Test the crap out of this stuff once you have a lab or a pilot set up.