ADSM-L

Re: Undelivered mail

1998-07-01 16:01:40
Subject: Re: Undelivered mail
From: "Prather, Wanda" <PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU>
Date: Wed, 1 Jul 1998 16:01:40 -0400
Ditto Brent's comments on compression.
We also use client compression by default, greatly reduces the network load.

Most of our desktops back up during prime shift, when we care most about the
network load.
ADSM's incremental-only paradigm and compression allow us to backup all the
desktops during prime shift, and nobody even notices it's going on.  Most
clients send less data for their backups than if they are doing a network
software install!

For the servers backing up at night, we don't really care whether it takes 1
hour or two, as long as they get done.

So we use non-compression only for special cases that warrant it.
> ----------
> From:         Brent  Link[SMTP:jlink2 AT csc DOT com]
> Sent:         Tuesday, June 30, 1998 3:48 PM
> To:   ADSM-L AT vm.marist DOT edu
> Subject:      Re: Undelivered mail
>
> Yes.
>
>
>
>
> "Donald_W._Daniels/FFIC"@ffic.com
> 06/30/98 01:43 PM
>
>
> Please respond to ADSM-L AT vm.marist DOT edu
>
> To:   ADSM-L AT vm.marist DOT edu
> cc:    (bcc: J Brent Link/COGG/CSC)
> Subject:  Re: Undelivered mail
>
>
>
>
> Brent,  in addition to client compression do you also use tape hardware
> compression?   We're a new ADSM installation insofar as LAN attached WinNT
> servers and NT, OS/2 clients.
> Don
> ddaniels AT ffic DOT com
>
>
>
>
>
> jlink2 AT CSC DOT COM (Brent Link) on 06/30/98 08:40:48 AM
> To: ADSM-L AT VM.MARIST DOT EDU @ INTERNET
> cc:  (bcc: Donald W. Daniels/FFIC)
> Subject: Re: Undelivered mail
> MAILER AT vm.marist DOT edu
> 06/30/98 11:12 AM
>
> Please respond to Postmaster AT vm.marist DOT edu
> To:   J Brent Link/COGG/CSC
> cc:
> Subject:  Re: To compress or not to compress?
>
> #1 - nix the newsgroup idea.
> #2 - Kelly, here is our 2 cents worth on the             'compression'
> issue.
> You
> make  excellent points on this issue.
> We have tested this six ways to Sunday.  It is true that by turning
> compression
> off, you will get a faster backup.  This is exponentially true when the
> client
> machine is CPU bound.  However, the only CPU bound machines we found were
> the
> Novell 3.11 servers.  For all others, compression significantly reduces
> the
> overall elapsed time of a backup.  In these (most) cases, the compression
> on the
> client end reduces the amount of data going over the wire.  When we backup
> at
> night, the wire is very much saturated with network load.
> What was written about tape compression is true, but not really a factor
> since
> it
> isn't the storage media on the host we have been most concerned about.
> Our
> biggest concern has always been staying in our backup window, and restore
> speeds.
> For such a large number of machines backing up simultaniously, network
> saturation
> is the problem to solve.  Compression at the client reduces network
> saturation.
> For restores, consider that for non-compressed backups the amount of band
> width
> required to complete a full restore during prime time and the competition
> for
> bandwidth.  A compressed backup is decompressed on the client end.  During
> a
> full
> restore, CPU is never a problem since ADSM is ussually the only thing
> running.
> My recommendation, use client compression as the default.  Only use
> non-compressed
> for machines that can't tollerate the CPU consumption needs of
> compression.
> Brent
> jlink2 AT csc DOT com
>
>
>
>
<Prev in Thread] Current Thread [Next in Thread>
  • Re: Undelivered mail, Prather, Wanda <=