Denys wrote:

>Your tests are very interesting.  They only show one side of the equation
>however.  You should try to do the same test but send the backup to $NULL.
>There are three/four components to a backup.  If the backup is to a local
>device, the three components are: the disk subsystem, the software and the
>backup device.  If the backup is to a remote device, the fourth component is
>the network itself.

To which Neil responded:

>A quick test to $NULL reveals that the system is capable of pushing out the
>data at 3589 K/S, so we have the potential to half our backup time, if only
>DDS4 or DLT/x was infinitely faster than DDS3...


While sometimes stores to $NULL are interesting, and answer part of the
equation, let's not forget that putting that infinitely faster DDS4 or
DLT on a loaded channel will have the opposite effect of what's intended.

In Neil's example, his system has the ability to PULL data from the disks
at 3589 K/S, but now writing that data back out to the target device must
be figured into the equation. Is that target device on its own channel
or does it share a channel? Is there CPU bandwidth available for software
compression (if that's to be used)? What queue is the backup process
running in as compared to other activity on the machine? Etc.

I've seen cases recently where adding a faster drive did not speed up the
backup because of I/O or CPU limitations. The becomes significant when
one considers that the 18 and 36 GB disk drives, while bigger, aren't
really faster, all things being equal.