In response to your problems:
(1) Lotus Notes files retrying - you should expect a lot of your files to
have to retry an the Lotus Domino server will constantly update these
files, even although no-one may be accessing the NSF's at the time. One
way round this is to shut down the Domino server while the backup is
running - not ideal. Another would be to upgrade to R5 and use the new
Tivoli Domino agent (I wouldn't bother with the connect agent for V3 ADSM).
I would reduce the number of retries because they are not gaining you
anything - so set this to the minimum. Something you could try which I
have never done is to try and identify the Domino server tasks that are
causing the updates (compact , indexer, etc) - although shutting these down
may affect active users.
(2) General consensus is that disk pools should be at least equal to the
size of your incremental overnight backup.
good luck,
Stuart
Steven Chaba <Steven_Chaba AT RGE DOT COM> on 02/12/99 09:48:24 PM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: Stuart Robertson/Edinburgh/Unitech)
Subject Retries, Migrations and Statistics - How Does
: It Work?
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>
|
