:> basic info: VAX 6620 with 1 DSSI controller, 1 SDI controller and an HSC
:> 60 hung off the CI bus. TF-867 and 12 RF35s of DSSI controller , RA92's
:> on SDI and HSC.
:> We are experiencing what I consider to be *really* slow backup, about
:> 22hrs to backup the 12 RF35's (10gb) & 6 RA92's with a verify.
:Yeah, that's pretty slow. Aside from getting a faster tape drive, you
:should also consider the state of the file structure on the disks. Are
:these big database files, or lots of small files from interactive users
:or whatever? If you have a lot of the latter, make sure BACKUP is
:running with sufficient quotas to allow its optimized file reading logic
:to work. See the section in the System Manager's Guide titled "Setting
:Process Quotas for Efficient Backups" (10.7 in the V7.1 doc set). This
:stuff matters for all backups, but is particularly important for lots of
Also consider performing an image BACKUP and restoration of the volumes,
as this will resolve any disk fragmentation issues that might be around.
(I run one of these defragmentation passes from every six months or so,
to every couple of years, depending on how full the volumes get and how
reasonably the RMS extention settings are configured on the various
As a quick test, find a big, recently-created file -- of (say) 5000+
blocks, and use DUMP/HEADER to see how many "map area words" are in
use. In general, the larger this number, the more fragmented the file.
Files extended over long intervals -- such as the system operator log
file -- tend to be more fragmented (normally), while executable images
and any files that are created relatively quickly should have relatively
And check for sufficient paged and non-paged pool -- if you cannot
remember when the last pass of AUTOGEN with FEEDBACK was run on this
system, it's probably time to run it again. :-)
-------------------------- pure personal opinion ---------------------------
note to those folks not contributing spam -- there is no ZZ in my address