You can implement the equivalent of a virtual mount point on NT by creating
a local share and then backing the share up as a separate filespace.
For example, on an NT machine named NTMACH1, you could create virtual mount
points on directories c:\bigdir1 and c:\bigdir2 as follows:
NET SHARE bigdir1=c:\bigdir1
NET SHARE bigdir2=c:\bigdir2
You could then backup these shares as separate filespaces as follows:
dsmc incr \\NTMACH1\bigdir1 \\NTMACH\bigdir2
The filespaces on the server (assuming you are using client PTF 5 or later)
will be \\ntmach1\bigdir1 and \\ntmach\bigdir2 .
One thing to keep in mind is that even though these shares are local, NT
still sees them as being remote, so you would need
to explicitly add them to your domain statement (they wouldn't get picked
up by ALL-LOCAL).
Also, the client scheduler service would have to run as a domain authorised
account because NT thinks the shares are domain resources
so the local system account won't have access to them.
Note that the above examples use the UNC name directly. You could just as
easily map these shares to a drive letter and get the same result.
Also note that local shares are only supported on NT, they aren't allowed
on Win9x.
Hope this helps ....
Pete Tanenhaus
ADSM Client Development
email: tanenhau AT us.ibm DOT com
tele: 408.256.8858 (San Jose), 607.755.7620 (Endicott)
---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 02/02/99
04:25 PM ---------------------------
04:25 PM ---------------------------
Jeff Connor <connorj AT NIMO DOT COM> on 02/02/99 01:00:45 PM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: Pete Tanenhaus/San Jose/IBM)
Subject: Re: NT restore performance for small files
We have the same problem with small files on NT. Servers usually have a
4GB C: drive and D: can be as large as 100GB.
Makes the DSMC RESTORE by files space not very useful unfortunately. Also,
the ADSM Installing the Clients Manual inidicates VIRTUALMOUNTPOINT can
only be used on UNIX clients. I'm toying with the idea of separate nodes
per machine with collocation at the node level using include/exclude to
carve up the large D: drive with lots of small files. Something like:
NTServer1 - normal include/exclude list. All local drives are
backed up.
NTServer1_APPS - Exclude all files Include D:\APPS\* so this node backs
up large APPS D: directory only
NTServer1_GROUPS - Exclude all files Include D:\GROUPS\* so that this node
backs up large APPS D: directory only
NTServer1_???? - Etc.
Yes we would backup some data twice but our helpdesk would always use the
machine name when trying to restore individual files. They would not have
to be aware of the NTServer1_ node names. The NTServer_ node names
would be used only in a large scale recovery.
Yes it would use up more client licenses too. Best idea I've come up with
so far though. Been trying to sell our NT admin guys on breaking D: into
smaller logical drives without much success. Unfortunate since I could
take advantage of collocate by filespace to reduce restore elapsed times.
Would like to hear other ideas if anybody has some.
Thanks,
Jeff
Dwight Cook <decook AT AMOCO DOT COM> on 02/02/99 02:05:57 PM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: Jeffrey P Connor/IT/NMPC)
Subject: Re: NT restore performance for small files
Sure it provides an easy way to split restores...!
Now backups will run faster as a single thread (multiple concurrent
incrementals lock contend with each other to much) BUT with restore
processing... you can launch multiple concurrent dsmc restore
processes and specify the level of a file system or logical volume
(what ever platform your client is on) say with NT
dsmc restore g:\* -subdir=yes -replace=yes -pass=xxx
dsmc restore h:\* -subdir=yes -replace=yes -pass=xxx
with unix
dsmc restore /d001/* -subdir=yes -replace=yes -pass=xxx
dsmc restore /d002/* -subdir=yes -replace=yes -pass=xxx
if your file systems are so big you might need multiple concurrent
tasks with a single file system break it up with the adsm option
"VIRTUALMOUNTPOINT"
Or just piss off the bean counters and make them buy more servers
prior to them getting to a bazillion GB in size ;-)
later,
Dwight
______________________________ Reply Separator
_________________________________
Subject: Re: NT restore performance for small files
Author: fr.maes (fr.maes AT CGER DOT BE) at unix,mime
Date: 2/2/99 3:11 AM
Hello Matthias,
This is a very very good question !
Sorry but I have just the same kind of problems and no solution.
We are using an ADSM V3 MVS server and ADSM V3 NT, AIX and DEC-UX clients.
Some NT servers are big lan servers with 80 to 100 GB of disk space.
We have also a restore transfer rate at 1.5 to 2GB / hour / process.
Our "big" lan servers are now connected via ATM. The restore transfer speed
is increased at +/- 4GB / hour.
Max # of backup versions = 8
Max retention only version = 800 days
DB size = 51 GB (83% full)
I mean that the actual version of ADSM is not the perfect way to restore
big
NT filespaces (more than 20GB).
ADSM offers no easy way to split backup and restore of a "big" NT filespace
thru multiple processes.
Will be better in a future release, comme d'habitude!
Courage.
Francis.
-----Message d'origine-----
De : Hensel, Matthias <Matthias.Hensel AT SCHERING DOT DE>
De : Hensel, Matthias <Matthias.Hensel AT SCHERING DOT DE>
A : ADSM-L AT VM.MARIST DOT EDU <ADSM-L AT VM.MARIST DOT EDU>
Date : lundi 1 f
|
