The best way is to export directly, not via tapes.  Use the "export node 
nodename filedata=all tos=newserver" command.  If these boxes are close setup a 
backend network (using secondary NICS) and define the new server on the current 
prod box using that secondary address.   Then, when you do the export you'll 
use that network, and keep the extra traffic off the prod network.  

Of all the methods I looked at this wound up being the best way to move the 
nodes to a new server.  I'm using it now to migrate from HP-UX to a newer AIX 
Server.  (and from LTO1 to LTO3 tapes).

See Ya'
Howard

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Henrik Ahlgren
> Sent: Friday, November 21, 2008 4:01 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] export/import nodes
> 
> thanks for comments so far.
> 
> Yeah, but wouldn't that lead to an empty node in the target server? Of
> course I want to migrate the data, I just don't like the idea of
> copying ten tapes worth of data to a set of temporary tapes and then
> again to new storage pool tapes (I have not tried it yet, but I assume
> TSM doesn't just use the export tapes as stgpool tapes, right?), if I
> had the
> possibility to just move the DB entries and keep the data in the tapes
> it was in the first place. I mean, with reusedelay and all, I would
> have the same data in 30 tapes instead of 10 for some time (not
> counting
> copypools volumes). Multiply that for couple of nodes, and soon you
> run out of library space. Well, at least it would have the side effect
> of reclamation.
> 
> I guess the next best thing to do would be to use FILEs on disk.
> 
> Imoprting the whole DB to a new server is also a nice hack, but I
> would like to start from scratch, since I'm planning an upgrade from
> prettyy ancient TSM version with DB that have lived for about eight
> years.
> 
> BTW, I haven't heard or noticed before that TSM might not adhere
> collocation in case of running out of scratch volumes. Is that
> behavior version dependend? I believe everyone runs out of scratch
> volumes every now and then...
> 
> On Fri, Nov 21, 2008 at 06:51:23AM -0200, Leandro Mazur wrote:
> > I think you can use the command export node with the parameter
> > filedata=none. Example:
> >
> > export node test filed=none tos=server1
> >
> > Please, correct me if I'm wrong.
> >
> > On Thu, Nov 20, 2008 at 9:13 PM, Wanda Prather <wprather AT jasi DOT com>
> wrote:
> >
> > > You can't copy just some DB entries.
> > > Other people have reported success with restoring the TSM DB to the
> new
> > > server, then deleting the unwanted filespaces/nodes on the new
> server.
> > >
> > > But you need to review your tape inventory carefully.  The fact
> that your
> > > storage pool is collocated doesn't mean that tapes necessarily have
> data
> > > for
> > > only one client.  If there was ever a day where you ran short of
> scratch
> > > tapes, TSM would have started stacking multiple clients per tape.
> > >
> > >  I'd recommend checking each tape before moving it would be a good
> plan.
> > >  If
> > > there are multiple nodes on a tape, you can use MOVE DATA to force
> the data
> > > to other volumes in the storage pool; if scratch tapes are
> available,
> > > collocation will be honored on output.  I think that would be less
> trouble
> > > than cleaning up the mess after a move.
> 
> --
> Terveisin
> 
> Henrik Ahlgren
> Technical Manager
> Itella Information Oy
> 
> Tietäjäntie 2
> FI-02130 Espoo
> GSM +358-50-3866200