Tom,

try to emulate virtualmountpoint through separate node names:
-       for each huge directory (acting as "virtualmountpoint") define a
node. In dsm.opt file define
--              exclude X:\...\*
--              include X:\<the_dir>\...\*
--              exclude.dir X:\<dir_1>
--              exclude.dir X:\<dir_2>
--              exclude.dir X:\<dir_3>
-       define other_dirs node with excludes for all "virtualmountpoints"
and without first exclude and the include.
Thus only the directory is included, existing known directories are
exclude.dir-ed and not traversed. If new directory is created and
forgotten to be excluded it will be traversed but only structure will be
backed up and not files. Last node will backup all but "virtualmountpoint"
directories.
You can create several schedule services and add them to MSCS resource
group for that (one-and-only) drive.
Collocation will come from itself.
Disclaimer: never solved such a puzzle nor tested it but ought to work.

Zlatko Krastev
IT Consultant




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        question on configuring large NT client for optimum restore 
proce ssing

What's the preferred method of configuring a large NT fileserver for
optimum
data recovery speed?

Can I do something with co-location at the filesystem (what IS a
filesystem
in NT/2000?) level?

We're bringing in an IBM NAS to replace four existing NT servers and our
recovery time for the existing environment stinks. The main server
currently
has something over 800,000 files using 167 GB (current box actually uses
NT
file compression, so it's showing as 80 GB on NT). We had to do a recovery
last year (raid array died) and it ran to 40+ hours; I'm getting the
feedback that over 20 hours will be un-acceptable.

The TSM server and the client code are relatively recent 4.2 versions and
will be staying at 4.2 for the rest of this year (so any neat features of
TSM 5 would be nice to know but otherwise unuseable :-)

To add to the fun and games, this will be an MS cluster environment. With
1.2 TB of disk on it. We do have a couple of weeks to play around and try
things out before getting serious. One advantage to the MSCS is that disk
compression is not allowed, so that should speed things up a bit on the
restore.

Tom Kauffman
NIBCO, Inc