> 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 <[EMAIL PROTECTED]> > 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 >