Good information Keith, we were really shooting to eliminate any in guest backups if possible with the exception of any hosts that have physical RDM's. Licensing wise are you guys capacity based or PVU based? We're utilizing PVU right now so that was another big reason we wanted to pull the agents out of the guests to save some costs there as well. We've found however that the file level recovery with TSM for VE is really too slow and unusable with any other back-end storage other than VTL or disk in our opinion.
Are you utilizing one overall policy for all your TSM for VE backups? Sounds like with the way you're capturing mainly the OS that would work really well in your environment. ----- Original Message ----- Hi Ken, We have been using TSMVE 6.4 for a couple months, I wouldn't call the following a set of best practices, but they work well for the restore service we provide. File restore services are still provided with TSM Extended Edition. Nothing different there. Recovery of the first disk on virtual machines is provided with TSMVE 6.4. Should disaster strike, the frst disk is restored by TSMVE, then files and directories are restored with TSM Extended Edition. We only snapshot the first disk. Our standard virtual machine is created here with a first disk of 60 GB and additional disks for data storage. VM admins are encouraged to install their OS on the first disk. We snapshot the first disk only by adding this statement to dsm.opt for each data mover; INCLUDE.VMDISK "*" "Hard Disk 1" If the first disk of a virtual machine is greater than 60 GB, that guest is excluded from snapshots by appending '-NB' to its display name in the vSphere client. Then, '*-NB' [ star dash NB ] is added to the exclusion filter in the TSMVE plug-in when a scheduled or run-now backup is created. We use one data mover per cluster, and put the data mover on the cluster it backs up for performance reasons. We exclude the data mover from the backup using the filter, and back it up with TSM/EE. Each cluster is scheduled for backups once a week, and two versions are kept. Our largest cluster has 12 hosts and about 420 guests. Our 'vmlimit' options are fairly conservative, and could change with more experience. Here they are: VMMAXPARALLEL 8 VMLIMITPERHOST 0 VMLIMITPERDATASTORE 1 So far, so good. Best wishes, Keith Arbogast Indiana University
