> 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?), i


Well, if you do an export node server-to-server via IP, the data goes
directly to the stgpool on the target server.  You still have to move the
data, but you don't have to do it to sequential media.


>
> 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.


Well, if you want to start from scratch, that would be doing exports, so the
DB  is build as you go.

>
>
> 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...
>
No, working as designed.  By "running out of scratch", I really meant
"unable to add a tape to the pool because the pool has already reached
maxscratch volumes".  All that collocation does is change the selection of
the output volume for a backup or process (migration, reclamation, etc).  If
TSM can't honor collocation, it keeps going uncollocated rather than fail
the process/backup.  Rough flowchart:

 If collocation is NONE, TSM chooses output tape:
 A: If there is a filling tape in the pool, use it
    If there is not a filling tape in the pool, and maxscratch not reached,
mount a scratch
    If there is not a filling tape in the pool, and maxscratch already
reached, fail

B: If collocation is NODE, TSM chooses output tape:
   If there is a filling tape in the pool with data already for this node,
use it
   If there is no filling tape in the pool with data for this node and
maxscratch not reached, mount a scratch
   If there is no filling tape in the pool with data for this node and
maxscratch reached, go to A:


>
> 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
>