A copy group parm would be ok with me, too, although not quite as granular.

By the way, we turned off compression on the client in question, and last
night's run was 7 hours shorter - 4 hours as opposed to 11.  We are somewhat
skeptical of the stats from a run with a lot of retries in it - it appears
that the file counts include all the files that were resent; and possibly the
data transfer as well.

Jerry


______________________________ Forward Header __________________________________
Subject: Re: Proposed compression change?
Author:  INTERNET.OWNERAD at SNADGATE
Date:    11/21/97 9:42 AM


Jerry,

  This is an excellent idea.  I was thinking about compression being a copy
group parm, but any method to select file types to compresss would be
great.

Dan T.

----------
> From: Jerry Lawson <jlawson AT THEHARTFORD DOT COM>
> From: Jerry Lawson <jlawson AT THEHARTFORD DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Proposed compression change?
> Date: Wednesday, November 19, 1997 10:44 AM
>
> Date:     November 19, 1997             Time: 10:31 AM
> From:     Jerry Lawson
>           The Hartford Insurance Group
> (860)  547-2960          jlawson AT thehartford DOT com
>
----------------------------------------------------------------------------
-
-
> I haven't seen any good requirements discussed on the list lately - is
> I haven't seen any good requirements discussed on the list lately - is
the
> ADSM-R list still working?
>
> At any rate we have a client that is giving us some fits, which as we
> discussed options, this item came to mind....
>
> The problem is that the server supports an Electronic Document Management
> (EDM) system.  The server (which is NT, but I don't think that matters)
has
> about 50 GB of DASD.  A good portion of this data are .TIF files.   These
> files do not compress well; we see lots of messages about "compressed
data
> grew", and retries on the backups as a result.  The net effect is that
for
> large parts of the nightly backup, we wind up retrying most of these
files.
> There are, however, many files on the machine, such as the data base
itself
 > (an SQL DB) that compresses very nicely, thank you.
>
> In the current design, compression is a binary decision - it is either on
for
> the whole client, or it is off.  It can be made to be "Client
Determined",
> but this doesn't really change my problem.
>
> What I would like to see is the ability to set compression on by the file
> type.  There are certain types of files (such as TIF, other graphics, and
> sometimes things like DLLs) that just don't compress, and we just wind up
> tripping over them.  These in turn slow down the whole backup process for
the
> retry.  By being able to set an "exclude from compression"  indicator,
the
> client would skip the files matching the pattern.
>
> Any other opinions?
>
>
>
----------------------------------------------------------------------------
-
-
>                                                      Jerry
>                                                      Jerry
>
> Insanity is doing the same thing over and over..and expecting the results
to
> be different - Anon.