On Fri, Oct 17, 2008 at 08:56:51AM +0200, Neil wrote: > On Fri, Oct 17, 2008 at 6:01 AM, Douglas A. Tutty <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]