Wanda,

Please expand on your statement where you suggest "making sure we don't run
backups at the same time that other software is running that also uses
snapshots". One of the new features in TSM for VE v6.4 is the ability to
run VM backups in parallel, many of them.

Ken


On Mon, Jan 21, 2013 at 6:43 PM, Prather, Wanda <Wanda.Prather AT icfi DOT 
com>wrote:

> I agree that using the "in guest" client in a VM is easier for back up;
> the big deal is when it comes time to do a DR.
> Then having the VM image from TSM/VE is easier to do your full machine
> restores with.  (I'm willing to do most anything to avoid having to deal
> with a MS System State restore!)
>
> As far as scheduling, my customer uses the plugin to create the schedule
> for the VM's.
>
> But, once you do that, go over to the TSM server/TIP and look at the
> schedule it created; it's just a normal TSM client schedule, but with a
> bunch of options that are specific to VE.  So you can doctor it on the
> server side.
> That seems to be the easiest route - create with the plug in, tweak with
> the TIP.
>
> Creating separate schedules for specific VM's is tricky because of VMotion.
> The beauty of being able to wild-card the schedule with the ESX hostname,
> is that if/when VMotion moves a VM to another ESX host, the backup for that
> ESX host will detect the "new" VM and it will still get backed up.
>
> To set up schedules that are specific to a single VM, you are going to
> have to be a little sneaky about using multiple schedules and wildcards so
> that you still can back up that VM when it moves, and not back it up
> multiple times.  Although that shouldn't be a big deal in terms of data
> with these VE block-level backups (which are so delightfully small!), I can
> foresee unpleasantness if you have multiple backup runs creating
> overlapping VMWare snapshots.
>
> The only thing we've really had to work around, though, is making sure we
> don't run backups at the same time that other software is running that also
> uses snapshots.  We havent' tried to isolate a schedule for a single VM.
>
> YMMV
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Mike De Gasperis
> Sent: Friday, January 18, 2013 2:16 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] TSM for VE 6.4 Questions/Recommendations
>
> I posted this up on the adsm.org forum but I'm hoping I get more hits
> here.
>
> We're getting ready to implement the agent at one of our facilities and
> I'm curious to see how everyone else is accomplishing some things we did
> relatively easy the "old" way.
>
> How are you scheduling certain VM's at different time frames? Wondering if
> folks are using the TSM scheduler to do it and how that looks or if the
> vCenter plugin has been an easier option for you.
>
> Policy and retention wise how are you handling VM's that may require a
> longer retention than others? Wondering if folks are just using separate
> management classes within the same policy or using multiple data move
> nodes. I'm also wondering if you're using multiple management classes are
> you just using includes within the dsm.opt or specifying in the TSM
> schedule somehow?
>
> Collocation wise we're using physical tape to store these VM backups,
> control data will be in a disk area. Are you collocating by file space for
> these VM backups given the way they're stored or are you using multiple
> data mover nodes to work what needs collocation what doesn't? My main
> concern is the file level recovery is painfully slow on physical tape,
> going and buying a bunch of disk or VTL isn't a very cost effective option
> for us unfortunately.
>
> I'm struggling to come up with the best practices on how to accomplish
> these items which to me we did so simply before with the in guest backup
> method. I know a lot of questions but recommendations and real world
> experience on these items would be invaluable.
>
>


--
Ken Bury