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@VM.MARIST.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