Some of the images are as large as 100 GB, but more are in the 10-20 GB range.
In most situations I know where VM is used NAS is also used (except for desktop fun and games). We use NetApp devices. We backup with backup servers with their own NAS and then go to tape (for off-site).
There are several benefits (some drawbacks) to backing up the image (outside ESX, not within).
One benefit is simplicy.
We use TSM at the moment. This requires creating a master backup followed by differentials backup. Restoring requires first building the base image then the master, then all the differentials.
The problems with this follow:
Our experience is that the base images aren't always done properly.
If you don't re-master regularly you end up having to apply lots of differentials. Any failures along the way and you're toast. That includes missing tapes, bad tapes, bad procedures (applying them).
Differentials still take time in proportion to the # of files in the server image (to check if they need to be backed up) - so servers with lots of files still take time to scan. Luckily it doesn't require all the time to copy the files across the network. There's also the time to checksum the files copied.
TSM saves time for sure, lots of it, but we currently make new full copies once / month and once / week with some systems.
Also, the TSM libraries aren't well segregated so far as tapes for which applications, especially for the differentials.
All of this is better than what we used to do.
If we copy the VMs via the VMS backup software it's a lot simpler. Each image is complete and for smaller servers not too large. Still it will take more time storage than TSM.
One benefit is RTO. Recovering a server is the total length of time it takes to recover the limited set of files for that images (maybe a dozen files). We clone images all the time and it's about a half hour operation (at the high end). It takes far longer than that to install a base OS on a server and then apply the master followed by all the differentials. That's nearly a 12 hour operation if all goes well - and it frequently doesn't for the reasons above.
Another benefit is access controls. We can have people who do not have access backup VM images without their having to have access to the content of the images. This would help us with issues for both SOX and Export controls. The people doing the backups do not need administrative access at the OS level (or above).
Another benefit is scheduling. As much as we'd like to know and control exactly when a backups is made, the fact that most people (including us) have backup servers backing up numerous other servers results in schedule "drift" over time. We have found that systems we wanted backed up at 10:00 for some reason (perhaps server-to-server depencendies) end up getting backed-up at "who knows when" within a several hour window. If we can snapshot the image, the backup will be of that at exactly the time that is done. We don't want the multi-hour drift (to limit log file growth), but if we have it, we can survive.
Another benefit is DR. We use a external host for off-site DR. Their servers are not the same model as our and their base kits are necessarily different. Both we and they have actually a number of kits due to owning many models of servers from several suppliers. We have run into issues with all systems having compatible versions of TSM and backups in addition to the OSes.
There are also additional issues with TSM regarding what it can/can't backup so far as active files, registry, and other key items. Snapshots of VMs don't have these.
There are a number of other issues, but I have to stop somewhere.
It seems that the real major downside to backup up at the host level is really the size of the backups themselves and the impact of sending those across our backup network to tape (which is how we do this). That's nothing to sneeze at, but this is worth a good look on our part.
