We are actually doing this now.  The copy pool is made from the disk
pool.  After this is done, it goes out to the primary tape pool.  Thanks
for the comments.

Dave

>>> Wanda.Prather AT JHUAPL DOT EDU 4/28/2004 2:31:34 PM >>>
Another thing that will help with the window:

Try to run BACKUP STGPOOL before the data migrates to your primary
pool.

If you can throw in a BACKUP STGPOOL diskpool OFFSITEPOOL a couple of
times
over the night, you can get the copy made BEFORE it gets to the primary
tape
pool, with half as many tape mounts!




-----Original Message-----
From: Steve Harris [mailto:Steve_Harris AT HEALTH.QLD.GOV DOT AU]
Sent: Tuesday, April 27, 2004 7:18 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: DRM Procedures


Dave,

The maxprocess idea is a good one and will help, but yes, you will send
more
tapes offsite.

As an alternative, could you run the backup stg process more often, say
two
or three times over the night?
Then the last part of the copy will only take a small amount of time
and
your window is reduced.

HTH

Steve

Steve Harris
AIX and TSM Admin
Queensland  HEalth, Brisbane, Australia


>>> dbenigni AT LUTRON DOT COM 27/04/2004 23:35:36 >>>
For our DRM procedures we have a script that runs nightly that does a
backup of all the primary storage pool to our copy pool.  Currently on
a
daily basis we are taking 1 tape of data and 1 database tape off site.
I would like to reduce the windows which it takes the copy pool to be
created.  I believe by doing the backup with the maxprocess directive
that would allow me to mount more tapes during this process, but this
would increase the number of tapes going off site.  Does this sound
correct to everyone?  TIA for the input.

Dave



****************************************************************************
*******
This email, including any attachments sent with it, is confidential and
for
the sole use of the intended recipient(s).  This confidentiality is
not
waived or lost, if you receive it and you are not the intended
recipient(s),
or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of
this
email is prohibited.  It may be subject to a statutory duty of
confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this
email
in error, you are asked to immediately notify the sender by telephone
or by
return email.  You should also delete this email and destroy any hard
copies
produced.
****************************************************************************
*******