Re: Hard Drive Spin Down
On Fri, Oct 17, 2008 at 08:56:51AM +0200, Neil wrote:
> On Fri, Oct 17, 2008 at 6:01 AM, Douglas A. Tutty <dtutty@vianet.ca> wrote:
> > On Thu, Oct 16, 2008 at 04:26:17PM -0400, Celejar wrote:
> >> On Thu, 16 Oct 2008 13:46:30 -0400
> >> "Douglas A. Tutty" <dtutty@vianet.ca> wrote:
> >> > On Thu, Oct 16, 2008 at 12:35:17PM -0400, Celejar wrote:
> >
> > As for performance, consider if you'll be encrypting the data over the
> > network or transfering by NFS and compressing on the backup box. My
> > 486 couldn't keep a 10 MB/s ethernet NFS share saturated if I expected
> > it to create the tarball.
> Can't you compress it on the client machine?
You can, however in some backup scenarios, it may make more
sense to copy over uncompressed. For example, if you use Amanda, I
think (I may well be wrong) that it copies the data uncompressed. Part
of it depends on if this is a "push" mode, where each node to be
backed-up pushes its data to the backup box, or a "pull" mode where the
backup box pulls the data according to a central schedule.
Or, avoid the software compression all-together and go with a tape unit
with hardware compression. Then you just need a backup box that can
keep the tape unit fed. Since the speed of tapes goes up over time, I'm
not sure that, e.g. a P-II could suck data fast enough over NFS or ssh
to keep the tape streaming: it could be a processor thing or it could be
bus contention. Whatever, once you go to tape, you need to look at
throughput.
Doug.
Reply to: