HP3000-L Archives

January 2000, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Neil Harvey <[log in to unmask]>
Reply To:
Neil Harvey <[log in to unmask]>
Date:
Sat, 15 Jan 2000 07:43:59 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
As usual, Denys' take on this backup thing drives me to do my own obsessive
backup benchmarking....

On our 967, we usually get around 1720K/S (according to the statistics
option on store).

Every day, we send about 43GB to a single DDS3 drive (with DDS3 Media in
it), and "hardware" compression is turned on just before the store begins.

The DDS3 spec is 12GB native, and "24GB" compressed - clearly we are getting
better compression than this estimate with standard MPE Databases and raw
data.

The job runs for just under 7 hours, and this is when we eat, sleep, chat,
watch cricket, and occasionally visit our families.

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...

Just for interest.....

Regards

Neil



-----Original Message-----
From: Denys Beauchemin [mailto:[log in to unmask]]
Sent: Friday, January 14, 2000 9:49 PM
To: [log in to unmask]
Subject: Re: testing of backup performance


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.

snip....

ATOM RSS1 RSS2