Steve, Our Tivoli setup was actually done by an outside group. Here is how it is currently run:
backup clients to disk where possible tape where not backup diskpools to copypool backup tapepools to copypool migrate disk to tape. backup 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 >>> [EMAIL PROTECTED] 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. >>> [EMAIL PROTECTED] 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 >>> [EMAIL PROTECTED] 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 >>> [EMAIL PROTECTED] 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. ***********************************************************************************
