Hi Steven,


The filles that could not be succesfully save are not stored on yourd
media, they are deleted. This means you do not have more versions or
wastetd space. Of course the statistics show more GB than really saved,
they show "what was sent" not what was saved, a liitle difference. But I
prefer this way, so I see why a session took so long.

Don't worry trust ADSM, he is working right.!
_________________________________________________

Kind Regards
Andreas Buser

Tel: ++41 61 285 73 21  Fax: ++41 61 285 70 98

Email: Andreas.Buser AT Basler DOT ch

Address:
Basler Versicherungen
Andreas Buser
Abt. Informatik
Aeschengraben 21
4002 Basel
Switzerland



                    Steven Chaba
                    <Steven_Chaba        An:     ADSM-L AT VM.MARIST DOT EDU
                    @RGE.COM>            Kopie:
                    Gesendet von:        Thema:  Retries, Migrations and 
Statistics - How Does It Work?
                    "ADSM: Dist
                    Stor Manager"
                    <ADSM-L AT VM DOT MA
                    RIST.EDU>


                    02.12.99
                    22:48
                    Bitte
                    antworten an
                    "ADSM: Dist
                    Stor Manager"





Server: 3.1.1.5 running over AIX 4.2.1
Clients: Various AIX, NT, DB, etc mostly version 3.1.0.x, a handful of v2
Serialization: Almost universally shared dynamic

I'm trying to understand the concept of retries as it applies to use of a
disk
storage pool, migrations from that storage pool to a tape pool as well as
to the
statistics that are reported in the activity log.

We currently have all nightly backups going to a common disk pool which is
~43
Gb. I did some analysis of last night's run, and it claimed that over 160
Gb of
data was sent to the server, dropped on this disk pool (yes, several
migrations
ran during the night, blocking backups for up to 2+ hours), and was
eventually
migrated off to tape.

Our top client in terms of data sent weighed in at over 73 Gb of data. The
only
problem is, this machine only has about 52 Gb of actual disk space, and
that's
only about 80-85% utilized. In reviewing its DSMSCHED.LOG, I see a
situation
where after about 1:00 AM virtually every file is retrying at least once,
and
most often twice before being sent successfully. This machine is our main
Lotus
Notes mail hub, serving around 2200 people. I'm working with our Notes
people to
try to find out what is causing all these files to appear to ADSM to be
changed
(multiple times?), but in the mean time I'm trying to understand what's
happening to all the extra copies of these files which are sent to the ADSM
server. When a file is marked as changed during a backup sequence, is it
kept on
the server along with the ultimate good copy (the last one sent when the
file is
no longer flagged as changed, or when the max retries are exceeded), and
migrated to tape along with the final backup copy? If so, how are these
managed,
expired, etc?

I would think if a retry is sent and is successful, that retry would be
kept but
the file it's replacing would be immediately discarded at the ADSM server,
but
the bytes transferred statistics in both my disk-to-tape migrations and the
client session reports sent don't seem to indicate this.

Our ADSM world has grown dramatically over the last year or so. My
predecessor
told me (shortly before escaping into blissful retirement) that in the good
old
days we had plenty more disk pool than a night's run required. I know disk
is
cheap, but this is in SSA drawers (which is a lot less cheap) and the
drawers
themselves are almost out of slots, so additional growth there is
constrained.

Can anyone enlighten me here? Pretty please?

Thanks in advance.
Steven
Steven J. Chaba, (confused, perplexed, unsettled and inexperienced) ADSM
Admin
Rochester Gas & Electric Corporation
<chaba AT rge DOT com>