Well, the select statement returned nothing. Which is correct, because
currently there is nothing in that management class, and if those OS X
filespace didn't get moved to it (backup went by real fast, no volume
rebounds), then a return of zippo is corrent.
Do you think I need to delete the filespace first? And then back it up
again?
I'll keep trying.
Thanks for the help though.
Alex
On Fri, 14 Nov 2003, David McClelland wrote:
> Hmmm, interesting. The 'backups' table in TSM tells us which management
> class an object is bound to. For example, a 'select * from backups'
> gives us useful things which include:
>
> NODE_NAME, FILESPACE_NAME, BACKUP_DATE and most importantly for you,
> CLASS_NAME
>
> You could put together a select query and check that the CLASS_NAME is
> correct - for example, if you've just implemented this, the simplest
> test would be:
>
> select * from backups where class_name='<your OS X mgmtclass name>'
>
> Very crude - you might want to modify this to satisfy yourself that it's
> working properly.
>
> Rgds,
>
> David McClelland
> Global Management Systems, Reuters Ltd., London
>
>
> -----Original Message-----
> From: Alexander Lazarevich [mailto:alazarev AT ITG.UIUC DOT EDU]
> Sent: 14 November 2003 15:54
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: different backup policy on single node?
>
>
> Cool, thanks. made the change, backed up the filespace. But how can I
> verify that the include statement has put that filespace into a new
> management class? Nothing in the actlog about management class. A 'q
> file xxx xxx format=detail' doesn't tell me either.
>
> I could verify by deleting temp files on the filespace and see if they
> get blown away from the server according to the new management class,
> but there's got to be a better way to tell?
>
> Thanks!
>
> Alex
>
> On Fri, 14 Nov 2003, David McClelland wrote:
>
> > Alexander,
> >
> > How about using the include exclude list on the Linux client to
> > specify a different management class for the filespec in which the OSX
>
> > clients have their filespaces mounted?
> >
> > e.g. include /mnt/macclientmount/.../* MAC_MGMTCLASS
> >
> > Where MAC_MGMTCLASS as defined on the server might have the policy
> > that you wish for your Mac files.
> >
> > Rgds,
> >
> > David McClelland
> > Global Management Systems, Reuters Ltd., London
> >
> > -----Original Message-----
> > From: Alexander Lazarevich [mailto:alazarev AT ITG.UIUC DOT EDU]
> > Sent: 14 November 2003 15:04
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: different backup policy on single node?
> >
> >
> > TSM 5.1 on Windows 2K server with Overland Neo 4100 LTO2. Windows,
> > unix, mac clients.
> >
> > We nfs mount OS X workspaces onto our Linux fileserver, and back them
> > up from there. We do that because, frankly, the TSM OS X scheduler is
> > terrible. And since there is no command line for the TSM OS X client,
> > we can't run the scheduler on OS X with cron. (what is IBM thinking?)
> >
> > Anyway, we now want different policies for the OS X nfs mounts and the
>
> > other filesystems on the linux client. But I don't see any way of
> > getting this done in TSM, it just wasn't designed that way.
> >
> > But is there any backdoor way to accomplish that? I just need a way to
>
> > have different filespaces on a single client belong to different
> > policies?
> >
> > Or is there any version of the OS X TSM client that actually can run
> > via command line?
> >
> > Thanks in advance,
> >
> > Alex
> >
> >
> > -----------------------------------------------------------------
> > Visit our Internet site at http://www.reuters.com
> >
> > Get closer to the financial markets with Reuters Messaging - for more
> > information and to register, visit http://www.reuters.com/messaging
> >
> > Any views expressed in this message are those of the individual
> > sender, except where the sender specifically states them to be the
> > views of Reuters Ltd.
> >
>
>
> -----------------------------------------------------------------
> Visit our Internet site at http://www.reuters.com
>
> Get closer to the financial markets with Reuters Messaging - for more
> information and to register, visit http://www.reuters.com/messaging
>
> Any views expressed in this message are those of the individual
> sender, except where the sender specifically states them to be
> the views of Reuters Ltd.
>
|
