Ce message est au format MIME. Comme votre programme de lecture de courriers ne comprend pas
ce format, il se peut que tout ou une partie de ce message soit illisible.
--B_3323942706_366709
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Richard,
You have the same questions I had when I started to put in place our DR
solution. We also have 3590E drives and I never tried to remove the hard
drive default compaction. I don=B9t see a reason for that. Now choosing
software compaction is a must if you have enough cpu to do the work for
backup and ALSO for restore. For us we can spend more time to use software
compaction because we know that we have enough cpu to do the work at restor=
e
time offsite. The gain at restore justifies to take more time at backup
processing. It=B9s true too that software compaction takes less tapes than
with no compaction.
If you have many dasds to backup and a time constraint to restore i would
suggest you to both use hard and software compactions. Our idea is to say
that when we restore in a DR test the cpu is used ONLY for restore. Why not
fully using it !
Regards
Alain Benveniste =20
Le 29/04/09 20:46, =AB=A0Schuh, Richard=A0=BB <rsc...@visa.com> a =E9crit=A0:
We are working on a DR process. I notice that the defaults for a Hidro ba=
ckup
include the PACK option which tells Hidro to pack, or condense in some
fashion, its output. The output is being written to 3590E drives. It appe=
ars
that there are three choices we can make for condensing the data: softwar=
e
only, hardware only, or a combination of the two (uncompacted was purpose=
ly
omitted from the list). Which is likely to give the best results? Does
software compaction produce consistently lower output volumes than lettin=
g the
drive do it? Is there anything to be gained by using both h/w and s/w?
Obviously, software compaction costs in terms of cpu time. The question i=
s, is
it worth the time spent?
=20
Regards,=20
Richard Schuh=20
=20
=20
=20
=20
--B_3323942706_366709
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
<HTML>
<HEAD>
<TITLE>Re: Packing Methods</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'>Richa=
rd,<BR>
<BR>
You have the same questions I had when I started to put in place our =
DR solution. We also have 3590E drives and I never tried to remove the hard =
drive default compaction. I don’t see a reason for that. Now choosing =
software compaction is a must if you have enough cpu to do the work for back=
up and ALSO for restore. For us we can spend more time to use software compa=
ction because we know that we have enough cpu to do the work at restore time=
offsite. The gain at restore justifies to take more time at backup processi=
ng. It’s true too that software compaction takes less tapes than with =
no compaction.<BR>
If you have many dasds to backup and a time constraint to restore i would s=
uggest you to both use hard and software compactions. Our idea is to say tha=
t when we restore in a DR test the cpu is used ONLY for restore. Why not ful=
ly using it !<BR>
<BR>
Regards<BR>
Alain Benveniste <BR>
<BR>
Le 29/04/09 20:46, «=A0Schuh, Richard=A0» <rsc...@visa.com> a=
écrit=A0:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:12.0px'><FONT FACE=3D"Arial"=
We are working on a DR process. I notice that the defaults for a Hidro back=
up include the PACK option which tells Hidro to pack, or condense in some fa=
shion, its output. The output is being written to 3590E drives. It appears t=
hat there are three choices we can make for condensing the data: software on=
ly, hardware only, or a combination of the two (uncompacted was purposely om=
itted from the list). Which is likely to give the best results? Does softwar=
e compaction produce consistently lower output volumes than letting the driv=
e do it? Is there anything to be gained by using both h/w and s/w? Obviously=
, software compaction costs in terms of cpu time. The question is, is it wor=
th the time spent?<BR>
<BR>
Regards, <BR>
Richard Schuh <BR>
<BR>
<BR>
<BR>
</FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:12.0px'><FONT FACE=3D"Verda=
na, Helvetica, Arial"><BR>
</FONT></SPAN>
</BODY>
</HTML>
--B_3323942706_366709--
