No LAN here, this is direct connect.  All the disks (6xA5200 FC) are very
quick, and data is on striped volumes that are very very fast.
Your right, my 401G is a database, and the database is DOWN so the files
aren't changing and there is little activity to its disks outside the
backup.  We're getting ready to whack a database for good, but want a solid
backup before we do.
One of the concerns I have is, when I see that I'm getting "1500k/s" to the
drive, that makes me think this is a throttle somewhere.  If that number was
based on disk-to-tape performance I'd get an akward number that would keep
changing, eg 2433k/s.  The perfectly rounded number makes me think that
something is limiting.  And there is no "Limit" type statement in my bp.conf
or vm.conf.
There are no real bottlenecks (I designed the system with that in mind), and
certainly none that would slwo the tapes to 1500k/s, but I'm a disk guy, not
tape.
And yes, this is a 3day backup.  At 1500 today, we'll be moving into day 3
of the backup.  It should be done in roughly 30hours.  Now that is lame.

benr.


> Hi Benr,
>
> DLT 7000 speeds should be about 15 gigs/hour.  4-5 megs/sec.  I would
> like to ask you if you are using a drive that is attached to this 400
> gig server or if you are actually going trough a network.
>
> If network, then I would check the network utilization.  (E.g. is the
> bandwith shared etc? )
>
> With the speeds you are seing (it would take 3-4 days to backup the
> data), if this is a production database and backed up trough the same
> network as production data uses, this could explain your problem.
> If this is on a different lan segment, then I would check the switch
> speed and duplex settings (Auto negotiate on-off etc) and match them
> with my server.
>
> Also there is a way to slow down your backups with a bo.conf parameter
> limit badwith or something like that.
>
> If this is over SSO e.g. direct connect tape drive, I would check my
> subsystem utilization v.s. backup speed, if there is no bottle neck
> there, try scsi connections, and drive it self (we have had drives that
> were slow until they were replaced).  (perhaps do a direct tar to the
> drive and see what speed you get, compare it with the netbackup speed
> etc).
>
> I hope this helps,
>
> Yucel
>
> ---------------------------------------------------------
> Yucel M. Erbilgic
> erbilgic.ym AT pg DOT com
> (513) 945-1859