We just went thru *TWO* very painful NT server disk-array failure outages;
ultimately, we got info from Tivoli/IBM corroborating our observations
(REGARDLESS OF PLAFORM):  large numbers of small files will restore very
SLOWLY!!!!

Consider 2 to 7 GB per hour as "normal"... whereas we get upwards of 20 GB
per hour for data base restores (per thread, per channel & tape head - and
we've done some measurements that demo over 90 GB per hour backup speed
using 3 tape heads, using 1 Gbps switched network, bottleneck became the
read-speed from the Unix client disk drives... improved via RAID-0+1 over
multiple channels).

The short answer to a "best practices" query is that we plan to implement
one of the first two solutions:
smaller and more disk arrays (like limited to 50 or 100 GB max for
file-served data).
This solution reduces the number of NT user shares subject to any given
full-restore outage. When the Win2K logical volume (image) backup becomes
available, early next year (?), we will use it (weekly or monthly?) for
initial file system restore.
Unix/AIX with Samba/Fast-Connect service for the NT shares.
This, then, allows us to use Logical Volume (IMAGE) backups to speed the
restore process
A third alternative we didn't discuss would be to use the Services for
Unix V2 on NT servers or Gateways (with NFS services accessed same as old NT
shares), which mitigates some of the migration-to-Samba issues (and would
allow us to use IMAGE backup/restore to move lots of data faster!)

Both NT4 servers were on RAID-5, old Pent-Pro dual processors, much data had
NT file-compression ON;  when it was time to do the restore, we used (a)
fast, new processor (dual P3-700 MHz), (b) no NT compression (can't control
this until the data is restored!), and (c) no more RAID-5 (until restore is
complete).  Restore performance varied from 2 to 7 GB per hour; we're
convinced the poor-performance factors were not related to AIX-ADSM server
or the network (we monitored throughout the outages)... we think the main
factors were large number of database inserts (ie, over 1 million NTFS file
system object-create transactions), plus the NT file compression overhead.

BTW, we started using the DIRMC "trick" to help speed up directory restores;
be careful to send the disk-pool to sequential Dir-File on disk (using
migration) then copy pool the sequential dir-file storage pool (so
reclamation as well as restore speed is fast).  Another afterthought I had
was to restore the directory structures first, then go after the data
files... don't know how much that would help, but it's worth considering.

Regards,

Don France

Unix Engineering (P.A.C.E.)
San Jose, CA


 -----Original Message-----
From:   Richard Sims [mailto:rbs AT BU DOT EDU]
Sent:   Monday, March 26, 2001 9:26 AM
To:     ADSM-L AT VM.MARIST DOT EDU
Subject:        Re: Win2K/NT restores taking too long...

>Our restores to AIX servers run great, the problem only seems to affect the
>NT servers.  Can anyone help...?

Jeff - You may get more insight by doing Q Sess from the server when such
       a restore is running.  The difference may relate to the Windows
directories having to be restored from storage pools, rather than the TSM
database as is the case with the AIX directories - and thus tape mounts.

  Richard Sims, BU