ADSM-L

Re: copy serialization shared , shared static, shared dynamic

2004-12-15 14:15:13
Subject: Re: copy serialization shared , shared static, shared dynamic
From: "Killam, Perpetua" <Perpetua.Killam AT RBCCM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 15 Dec 2004 14:12:27 -0500
Hi Andy, 

My confusion is with one particular client (nas filesystem mounted on a solaris 
box, don't ask me why they want to do it this way? ;-) ) I have 
Sharedstatic mode, but it backups everything it inspects, instead of looking of 
changed data(incremental). The user claims nothing much changes on the 
snapshots of the filesystems.

I'm just trying to understand how it could be. I'm going to find out how their 
snapshots work too

Please let me know your thoughts.

Thanks,
Perpetua

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Andrew Raibeck
Sent: Wednesday, December 15, 2004 1:18 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: copy serialization shared , shared static, shared dynamic

See the reference information for DEFINE COPYGROUP regarding the 
SERIALIZATION parameter. It contains warning info about using the *DYNAMIC 
serialization methods.

As for the *STATIC serialization methods, consider:

STATIC tries to back the file up once. If it can't capture an unchanged 
version, then the file is skipped.

SHRSTATIC will try up to 4 times to back up a changing file. Though it 
will skip the file if it ultimately cannot get an unchanged version, at 
leat you get several tries. The downside is that when the file is retried, the 
current transaction (which can include other files as well) has to be resent, 
and thus represents an increase in backup run time.

In general, having a good backup version takes precedence over 
performance, and therefore SHRSTATIC is what I would recommend over 
STATIC. In general, use of STATIC or *DYNAMIC methods should be on an 
exception basis only, when the trade-offs between serialization, value of the 
data, risk of fuzzy backp or no backup, etc., are fully understood.

My two cents.

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 12/15/2004 
07:16:32:

> Hi,
> 
> I know that we could use these modes depending on the user requests,
> but i would like to find out what is the best practice? 
> i read in 5.2,that it should be shared static? do these parameters 
> also cut down on inspection time during backups? how reliable is the
> data when it is time to restore?
> 
> 
> > Please let me know
> > Thanks,
> > Perpetua
> >
> > --------------------------------
> > This e-mail may be privileged and/or confidential, and the sender 
> does not waive any related rights and obligations. Any distribution,
> use or copying of this e-mail or the information it contains by 
> other than an intended recipient is unauthorized. If you received 
> this e-mail in error, please advise me (by return e-mail or 
> otherwise) immediately.
> >
> > Ce courriel est confidentiel et protege. L'expediteur ne renonce 
> pas aux droits et obligations qui s'y rapportent. Toute diffusion, 
> utilisation ou copie de ce message ou des renseignements qu'il 
> contient par une personne autre que le (les) destinataire(s) 
> designe(s) est interdite. Si vous recevez ce courriel par erreur, 
> veuillez m'en aviser immediatement, par retour de courriel ou par un
> autre moyen.
> > ================================
> 
> 
> <font face="Times New Roman" size="3">
> 
<p>------------------------------------------------------------------------------
> </p>
> <p> This e-mail may be privileged and/or confidential, and the 
> sender does not waive any related rights and obligations. Any 
> distribution, use or copying of this e-mail or the information it 
> contains by other than an intended recipient is unauthorized. If you
> received this e-mail in error, please advise me (by return e-mail or
> otherwise) immediately.</p>
> <p> Ce courriel est confidentiel et protégé. L'expéditeur ne renonce
> pas aux droits et obligations qui s'y rapportent. Toute diffusion, 
> utilisation ou copie de ce message ou des renseignements qu'il 
> contient par une personne autre que le (les) destinataire(s) 
> désigné(s) est interdite. Si vous recevez ce courriel par erreur, 
> veuillez m'en aviser immédiatement, par retour de courriel ou par un
> autre moyen.</p>
> <p>====================================================</p>
> </font>



<font face="Times New Roman" size="3">
<p>------------------------------------------------------------------------------</p>
<p> This e-mail may be privileged and/or confidential, and the sender does not 
waive any related rights and obligations. Any distribution, use or copying of 
this e-mail or the information it contains by other than an intended recipient 
is unauthorized. If you received this e-mail in error, please advise me (by 
return e-mail or otherwise) immediately.</p>
<p> Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux 
droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie 
de ce message ou des renseignements qu'il contient par une personne autre que 
le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel 
par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par 
un autre moyen.</p>
<p>====================================================</p>
</font>

<Prev in Thread] Current Thread [Next in Thread>