|
[Veritas-bu] compression to disk staging unit
2006-05-19 11:19:18
This is a multi-part message in MIME format.
------_=_NextPart_001_01C67B57.98254CD8
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
I've done this.
=20
Benefits:=20
1. less space taken up on disk storage unit.
2. If network is slow, then less data across the network. This can
actually increase backup speeds if the network is the bottleneck but, in
my experience, you'd have to be running a pretty slow link to see this
benefit.
=20
Penalties:
1. Increased load on Client
2. Depending on spare cycles, increased backup time (compression takes
time - especially if the system is already loaded)
=20
I frankly don't remember the migration to tape issues. IIRC, the client
compression was poor enough at the time (v4.5?) that it didn't expand on
hardware compression. There was still lots of "squishiness" left in
the compressed images.
=20
It's easy enough to simply turn on & test, tho. I'd suggest just
turning it on for a day.
=20
$.02
-M
________________________________
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Bob Stump
Sent: Friday, May 19, 2006 8:42 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] compression to disk staging unit
Is it wrong to use software compression in a policy that uses a disk
staging unit for the storage unit?=20
Will this result in slower migration or negative compression during the
migration phase to a tape drive that uses hardware compression?
------_=_NextPart_001_01C67B57.98254CD8
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV dir=3Dltr align=3Dleft><SPAN class=3D287351415-19052006>I've done=20
this.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D287351415-19052006></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D287351415-19052006>Benefits: =
</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D287351415-19052006>1. less =
space taken up on=20
disk storage unit.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D287351415-19052006>2. If =
network is slow,=20
then less data across the network. This can actually increase =
backup=20
speeds if the network is the bottleneck but, in my experience, you'd =
have to be=20
running a pretty slow link to see this benefit.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D287351415-19052006></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D287351415-19052006>Penalties:</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D287351415-19052006>1. =
Increased load on=20
Client</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D287351415-19052006>2. =
Depending on spare=20
cycles, increased backup time (compression takes time - especially if =
the system=20
is already loaded)</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D287351415-19052006></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D287351415-19052006>I frankly =
don't remember=20
the migration to tape issues. IIRC, the client compression was =
poor enough=20
at the time (v4.5?) that it didn't expand on hardware =
compression. =20
There was still lots of "squishiness" left in the compressed=20
images.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D287351415-19052006></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D287351415-19052006>It's easy =
enough to=20
simply turn on & test, tho. I'd suggest just turning it on for =
a=20
day.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D287351415-19052006></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D287351415-19052006>$.02</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D287351415-19052006>-M</SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<B>From:</B> veritas-bu-admin AT mailman.eng.auburn DOT edu=20
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] <B>On Behalf Of </B>Bob
=
Stump<BR><B>Sent:</B> Friday, May 19, 2006 8:42 AM<BR><B>To:</B>=20
veritas-bu AT mailman.eng.auburn DOT edu<BR><B>Subject:</B> [Veritas-bu] =
compression to=20
disk staging unit<BR><BR></DIV>
<DIV></DIV>
<DIV>Is it wrong to use software compression in a policy that uses =
a disk=20
staging unit for the storage unit? </DIV>
<DIV>Will this result in slower migration or negative compression during =
the=20
migration phase to a tape drive that uses hardware=20
compression?</DIV></BODY></HTML>
------_=_NextPart_001_01C67B57.98254CD8--
|
|
|
