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\u2019s. Oh yes, and your budget.<\/p>\n
What does that mean? There are two places you can do your backup from. <\/p>\n
This allows you to capture selected VM\u2019s on the host as they are running. There\u2019s some catches to that which I\u2019ll come back to later. The benefit of this approach is that it\u2019s a simple hammer that can hit everything. If you need to recover all of your VM\u2019s then you can do it. But you have no knowledge of the VM\u2019s 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.<\/p>\n
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 \u201cquiescent<\/a><\/em>\u201d 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\u2019s the VM\u2019s 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\u2019t noticed a thing.<\/p>\n 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\u2019s and left the backup integration service enabled. All of the volumes in the VM must also have VSS enabled.<\/p>\n If you have VM\u2019s that don\u2019t meet both of those requirements then they must be stopped (saved state) before a backup can commence. This will include, for example, VM\u2019s that meet these conditions:<\/p>\n 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.<\/p>\n You should also be aware that virtual network configurations are reportedly not backed up with this approach.<\/p>\n However the two big benefits are:<\/p>\n The second approach is to do an in-VM backup. This is pretty much doing what you\u2019ve always done with your physical servers. You log into the VM and do the backup from there. Here are the benefits:<\/p>\n Recovering a lost VM with just this approach will be time consuming. You would have to:<\/p>\n 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\u2019s, depending on major changes on those VM\u2019s. Identify those VM\u2019s 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\u2019s that don\u2019t 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\u2019s. This will require a scheduled maintenance window where you put the VM\u2019s into a saved state to run the backup. This will allow quicker recoveries in a major disaster for these VM\u2019s.<\/p>\n Here\u2019s how you can handle various recoveries now:<\/p>\n 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\u2019s. It\u2019s not the prettiest solution but it works. VM\u2019s 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\u2019s and that adds complexity to your storage solution.<\/p>\n 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\u2019s 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.<\/p>\n DPM installs agents on the host and in the VM\u2019s. Licensing costs are reduced with System Center Enterprise (host and 4 VM\u2019s on the host) and Datacenter (host and all VM\u2019s on the host) CAL\u2019s\/SAL\u2019s. You can configure protection sets with schedules of your choice and your hosts\/VM\u2019s\/data will be backed up to the disk storage set(s) on the DPM server. For those VM\u2019s 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.<\/p>\n What if you\u2019ve 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:<\/p>\n 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\u2019s. Oh … Continue reading “Hyper-V Backup Strategies”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"_wpcom_ai_launchpad_first_post":false,"footnotes":""},"categories":[20],"tags":[55,175,181,116,117],"class_list":["post-10249","post","type-post","status-publish","format-standard","hentry","category-hyper-v","tag-backup","tag-dpm","tag-hyper-v","tag-windows-server-2008","tag-windows-server-2008-r2"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n
\n
In-VM Backup<\/h4>\n
\n
\n
Best of Both Worlds<\/h4>\n
\n
Backup Tools<\/h4>\n
\n
Things To Watch Out For<\/h4>\n
\n