I need some help regarding an NT client problem we're having and I don't have
much experience with the NT client or NT.
We have an NT client with a RAID disk setup that we run an incremental backup
on. Currently it's occupancy looks like this:
adsm> q occ rainmaker
Node Name Type Filespace Storage Number of Space
Name Pool Name Files Occupied
(MB)
------------------------ ---- ----------- ----------- --------- ----------
BIGDAWG Bkup RAID1 BKP.DLT7000 952,533 27,168.39
BIGDAWG Bkup RAID1 BKP.DLT7000 952,533 27,168.39
BIGDAWG Bkup RAID1 CPY.DLT7000 952,533 27,168.39
BIGDAWG Bkup Backup OS BKP.DLT7000 137 1.02
BIGDAWG Bkup Backup OS CPY.DLT7000 137 1.02
Recently the folks that administer this machine had to restore some inactive
files using the NT client (v3). It took forever just to get a list of files
to restore. My observation using the dsmc restore -pick for one
file was that it took 1hr 45 min to present a list to pick from. The ADSM server
was relatively quiet at the time I was doing this. They've had to wait hours
for responses from the GUI. The command line interface appears to work a bit
better.
Is our problem because of the way the filespace backup is setup for RAID1?
Does restore look at every file (952K worth in this case)? Why is it so slow?
Is there something we can do to our server or client configurations to
optimize restores? With Unix you can setup a virtualmountpoint which helps
when backing up and restoring large file systems. Is there a similar way to
setup an NT client?
Our server is an RS6000/F40 (1 cpu) running v2 with a db that looks like this:
adsm> q db
Available Assigned Maximum Maximum Page Total Used %Util Max.
Space Capacity Extension Reduction Size Usable Pages %Util
(MB) (MB) (MB) (MB) (bytes) Pages
--------- -------- --------- --------- ------- --------- --------- ----- -----
6,120 6,120 0 2,584 4,096 1,566,720 789,066 50.4 56.0
6,120 6,120 0 2,584 4,096 1,566,720 789,066 50.4 56.0
We are aware our server needs more horsepower and we're in the midst of
setting up an F50 with 4CPUs and much more memory.
Thanks for any information you can give..
========================================
Neal V. Adams
SLAC Computing Services -- Systems Group
phone: 650-926-2821
fax: 650-926-3329
email: neal AT slac.stanford DOT edu
========================================
|