Strategic approaches to backup up virtual environments

[MattZurkowsky]

Can anyone speak to the the security aspects of virtualizing servers and desktops? I am trying to push for virtualizing in our new facility and need more leverage then all the other benefits up front. Of course if it is less secure then I won't have much leverage...

I just want to get some information outside of what the marketing crap/hype, features/benefits that the virtualization vendors provide.

Any experiences with various strategic approaches to backing up virtual environments? I'm looking specifically for information on assessing the business impact of protecting and recovering data from VMs in an automated and timely manner.

[rahrenstorff]

Generally, I would suggest that virtualization, implemented properly according to the required scale/complexity, allows for better ROI with software and hardware in production, and improved RTO in the event of guest, host, or site disasters. Additionally, I believe disaster recovery is easier to implement and maintain with virtualized environments.

I have been using VMware since it's practical inception in 2000. I have also used Xen, XenServer, VirtualBox, KVM (on Red Hat), Parallels Virtuozzo, and OpenVZ in either testing or production. I have virtualized servers and desktops. As virtual platform vendors converge on open protocols and formats and the hypervisor layer becomes a commodity, it will be increasingly cheaper and easier to deploy and maintain all aspects of the virtual layer.

As to a 'strategic approach', I could only offer this advice: each environment is requires a comprehensive review of the criticality of data, RTO/RPO, business continuity impact, regulatory compliance, and cost.

[CanadaCloudGuy]

Unfortunately I cannot provide much insight into the VDI aspect of things as it's out of my realm of expertise. However as far as strategic approaches to backup up VM environments, there are a number of ways to do it. The quick and dirty way would be to back up at the VMDK level and if a restore is necessary, simply restore the whole system and data. Unfortunately this doesn't provide the necessary granularity to critical systems with fine RPO and RTO ranges. Backing up through the application level (the same as a physical server) will provide you those means (provided the software you're using supports it), but complete system restore could prove to be a bit longer, but file level granularity is there. From a best practice approach, and if the budget is there, doing a combination of both will provide you the best of both worlds in order to recover your VM environment from file to VMDK quickly and efficiently.

Any other thoughts?

[tdugan]

Matt,

We backup VMs in a few different ways depending on the way we expect to restore them. For example, a virtualized file server is backed up at the O/S level because we need the granularity of restoring individual files ... whereas a SQL server is backed up at the VMDK level because, generally speaking, if we are going to restore the database, we are essentially restoring 90% of the server anyway so we may as well restore the entire server VMDK rather than toying with the restoration of a database. Much like "rahrenstorff" above, I've been working with VMware (and other virtualization platforms) for years - not quite back to 2000 but to 2003 ... but ... what's a few years? ;-) Anyway ... he is correct that knowing what your RPO/RTO requirements are for each server are critical to knowing how to back them up ... because ... it's not about the "backup", it's about the "restore" ! ;-)

Good luck.