ADSM-L

Retries, Migrations and Statistics - How Does It Work?

1999-12-02 16:48:24
Subject: Retries, Migrations and Statistics - How Does It Work?
From: Steven Chaba <Steven_Chaba AT RGE DOT COM>
Date: Thu, 2 Dec 1999 16:48:24 -0500
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>
<Prev in Thread] Current Thread [Next in Thread>