Hi,
 
you can define a new management class with longer time periods and/or version 
count values
for "deleted" data. This class is meant solely for managing directories to be 
moved from X: to Y:.
Bind this class to the directories in question while they are still on X:
and do an usual incremental backup.
 
Do not forget to check TSM client settings (e.G. Domain) for Y:.
Move the data to Y: and voila - the job is done.
 
Advantage: no export node necessary
Disadvantage: during restores you must search after files on 2 locations (Y: 
and X:).
Your problem of doupbled space usage is not solved.
 
------------
In your scenario, you can shorten the period for double space requirements:
after having done export you can do 
RESTORE -LATEST -replace=newer (check for the correct syntax , please)
to the original location (only for directories to be moved to y:),
bind those directories to a management class with very small time/version count 
values,
do an INCRemental, 
delete the data on X:, 
do a new INCRemental, 
and EXPIRE the database.
 
regards
juraj
 
 
regards
juraj

 
________________________________

Von: ADSM: Dist Stor Manager im Auftrag von Kauffman, Tom
Gesendet: Do 05.01.2006 15:43
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Splitting a MS-Windows node filesystem?



It's a new year, and the new questions are crawling out of the wood-work
here.

We have an NT fileserver with four 'filesystems' (drives), co-located by
filesystem. It's about to be replaced, and in the process the 'X:' drive
will be split into the 'X:' and'Y:' drives. How do I handle this at the
server level so that I don't loose backup generations?

It looks like I need to do an export node with the filespace specified,
rename the filespace on the node, and then do an import -- this will, of
course, double the data until my expire inventory reaches the
retainextra/retainonly limits after the first backup.

Is there a better way?

TIA

Tom Kauffman
NIBCO, Inc