And before you use a fuzzy backup make sure you can restore a fuzzy backup.
If you can't you might as well exclude the file. That's even cheaper!
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80949-1313
(719) 531-5926
Fax: (719) 260-5991
Email: [EMAIL PROTECTED]
www.storsol.com
www.storserver.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Prather, Wanda
Sent: Wednesday, October 25, 2000 1:01 PM
To: [EMAIL PROTECTED]
Subject: Re: Bytes Transferred Statistics from AIX nodes
Have you tried changing the management class for that file?
For the few cases where you KNOW the file is going to be is use, and you
want a fuzzy backup anyway, you can create a separate management class
(called FUZZY, for example), which specifies SERIALIZATION=DYNAMIC.
Bind that one file to the FUZZY management class in the inclexcl file:
INCLUDE filename FUZZY
SERIALIZATION=DYNAMIC tells TSM to back it up on the first try, whether
it's in use or not.
> -----Original Message-----
> From: Zoltan Forray/AC/VCU [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, October 25, 2000 1:40 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bytes Transferred Statistics from AIX nodes
>
> Thanks for the info.
>
> Nice thought, but there probably isn't going to be a time when these files
> are "not in use", so fuzzy is better than no backup, in this case!!
>
> IMHO, I think this is a screwball way of doing things. I guess I am too
> accustomed to the MVS way...."check to see if file is in use. No, back it
> up.....next file...if busy and was told to backup files even when
> open/inuse, back it up.........next file....if the file is locked and
> can't
> backup, give up"....not "send 30GB of data down the channel/router/etc and
> then check to see if the file is in use/changed.
>
> In this situation, after further digging, we found that of the 32G sent,
> 24G was duplicate, retries. ADSM wasted numerous hours, tying up
> resources
> and wasting backup time. Even reducing the retry to 1 is wasteful. What if
> one file is 30GB? It is going to waste time, bandwidth, etc. backing it up
> twice..
>
> Again, thanks for the clarification !!
>
>
>
>
> Hi,
>
> It does the sending on each retries. To avoid it, it would have to first
> copy the file in a reserved space, check if the file changed, and send it
> only it has asserted itself it is OK to be sent. This could be a
> worthwhile feature in *SM if it were not for the fact that you'd need to
> have a free space reserve equivalent to the size of any of the file
> bundles
> that are sent at each transmission bursts. *SM were just not designed this
> way.
>
> You may want to exclude the files changing during the backup process, and
> schedule a task to backup those files separately at a time when you know
> they are not going to change.
>
> Serge Gaudet, CMI
> Consultant.
>
>
>
>
> Zoltan
> Forray/AC/VCU To: [EMAIL PROTECTED]
>
>
> Once a week (or so), I go through the ADSM (MVS 3.1.2.50) server activity
> log file, and strip out the "AN?4961I Bytes Transferred" messages to get
> an
> idea of how much data is being transferred/backed up.
>
> Recently, we noticed that a new node (AIX) was transferring more data than
> the total of it's file systems (32GB on a 21GB system).
>
> We turned on VERBOSE logging on the node to see what the !@#$%^&* was
> going
> on.
>
> The only thing we could come up with was the issue of RETRIES on busy
> files. The log would show
> "....transfering....changed....retrying.......transfering.....changed....r
> etrying.....".
>
>
>
>
>
> When we added up the RETRIES bytes plus the total of the filesystem, it
> now
> adds up.
>
> So, why is the "total bytes transfered" including RETRIES ? Does it
> actually send the data, then go back and check to see if the file it just
> transfered changed since it sent the data (kinda doubt it <g>) and keep
> retry/sending until it runs out of retries and then gives up ?
>
> Or is this a client bug ? This is V3.7.2.0 !
