Re: Wish list - new item!
1999-10-08 11:02:48
=> 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
|
|
|