I just updated our scripts to reorder the functions. I'll see in the
morning how it goes. Thanks for help!
Dave
>>> milton.johnson AT CITIGROUP DOT COM 4/29/2004 10:33:17 AM >>>
Dave,
If you make a slight change in order you should solve your problem:
1) backup clients to disk where possible, tape where not
2) backup diskpools to copypool
3) backup tapepools to copypool
4) backup DB to tape
*NOTE: At this point ALL of your data has been copied to your copypool
and you have a DB backup that reflects that. You can now eject your
DRM
volumes (copypool and DB backup) and send them to your vault.
5) migrate disk to tape
6) expire inventory
We actually migrate and expire at the same time, having the I/O and
CPU
bandwidth to support doing that.
H. Milton Johnson
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
Of
David Benigni
Sent: Thursday, April 29, 2004 8:29 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: DRM Procedures
Steve,
Our Tivoli setup was actually done by an outside group. Here is how
it
is currently run:
bbackup clients to disk where possible tape where not backup diskpools
to copypool backup tapepools to copypool migrate disk to tape.ackup DB
expire inventory
The problem with this is that what there is a massive amount of data
the
migration is not done before the db backup. SO, I can't be sure that
everything is offsite on the copy pool. Flipping the schedules around
would fix this. I was attacking it by lets get the migration as fast
as
possible.
Shouldn't be any draw backs this way.
Thanks!
Dave
>>> Steve_Harris AT HEALTH.QLD.GOV DOT AU 4/28/2004 7:34:33 PM >>>
Dave
You can set maxproc on your diskpool and run as many processes as you
have drives. That works fine.
But, why is the disk to tape dump speed important to you?
Most shops run a cycle of
backup clients to disk where possible tape where not backup diskpools
to
copypool backup tapepools to copypool backup DB expire inventory
migrate
disk to tape.
In my shop we leave the data on disk until about 5PM so that most
restores are done from disk rather than tape. But, we could start
migrating as early as about 11AM with our current volumes. TSM is
very
efficient with its tape drives as compared with other competing
products. As long as the migrate is complete before the next backup
cycle that's enough.
Or do you have some sort of special requirement that I don't
understand?
Regards
Steve.
>>> dbenigni AT LUTRON DOT COM 29/04/2004 6:15:27 >>>
Steve,
I could run the backup stg more times, that a different idea that I
have
not thought about.
After looking at the timing the making the copy pool is very fast.
The
time hog is migrating the disk pool to the primary tape pool. Now,
besides throwing more drives at this, is there any way to make this
process quicker?
Thanks for the insight.
Dave
>>> Steve_Harris AT HEALTH.QLD.GOV DOT AU 4/27/2004 7:18:12 PM >>>
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.
************************************************************************
***********
************************************************************************
***********
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.
************************************************************************
***********
|
