=> On Fri, 8 Oct 1999 11:31:19 +0200, "Landreville, Frederic" <Fred_Landreville 
AT RJRI DOT COM> said:

> Then why are they thinking of a MOVE NODE command at the Server Level? I
> just want a MOVE PART OF NODE command...

> I do not want to change my policies just because of one or two moves... I do
> not want to track manually where the user files are... before this date on
> the server... after this date on that file server... makes for point in time
> restore impossible...


At the risk of sounding heartless, keeping track of where users have been is
precisely what you'll need to do under this model: Think about it: Even if
ADSM limited you to moving some of a filespace to another node of the same
"type", what happens if you move a tree from a (for instance)
large-file-enabled FS to one that's not?  That's just a first-glance example
of the amount of consistency checking that would be necessary, but is not
really in the domain of ADSM.



Try this:

Develop a virtual node (let's call it USERS) and do all your userspace backup
by the following:

Mount the users homedir _directly_, under some path like

/foo/backupusers/joeblo

back up the new "filespace"

dsmc incr /foo/backupusers/joeblo

and then unmount it.  Repeat for all users on this fileserver, repeat
(possibly simultaneously) on all fileservers.

Then when you have a PIT problem, you just have to mount the appropriate
directory under

/foo/backupusers/targetuser

and restore to that imaginary path.

I would definitely argue against mixing OS types in this mix, but it could let
you get a consistent path to your userbase.  Of course, your filespace count
will go through the roof...


Allen S. Rout