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:[EMAIL PROTECTED] > Sent: 14 November 2003 15:54 > To: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > Sent: 14 November 2003 15:04 > > To: [EMAIL PROTECTED] > > 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. >
