Karel, I think you are right.
I should copy the old primary pool firstly to the new copy pool (and accept the high number of scratch used) BEFORE I migrate the data from old primary stg to new primary stg. It seems that there is no other solution. Thanks for the feedback. Best regards / Mit freundlichen Grüßen / Sincères salutations Ronald Le Large "Bos, Karel" <karel....@atosorigin.com> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 14-07-2010 16:31 Please respond to "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Copy Pool question * Backup old prim stg to new copy stg => short time extra tape storage needed * delete old copy stg volumes => free up old copy volumes * migrate old prim stg to new prim stg => take all the time you need Regards, K -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Grigori Solonovitch Sent: woensdag 14 juli 2010 16:16 To: ADSM-L@VM.MARIST.EDU Subject: Re: Copy Pool question Ther is no other solution. You can only speed up process: 1) expiry will remove the oldest data from old primary and copy pools; 2) you can migrate the newest data slowly from old primary pool th new primary pool; 3) after completion of moving/expirying of old primary pool just remove all remaing volume in old copy pool (copy will be in the new copy pols as well)m ________________________________________ From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Ronald Le Large [rlela...@epo.org] Sent: Wednesday, July 14, 2010 4:26 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Copy Pool question I have a related issue... I have a new primary stg pool and a new copy pool. I have also an 'old' primary pool and an 'old' copy pool. There is no new data arriving in the 'old' primary pool because backup data is send to the 'new' primary pool. This data is of course copied to the new copy pool. So far so good. But....I am gradually migrating the data in the old primary stg pool to the new primary stg pool. And as a result the data which has already a copy in the old copy pool. is copied again during the "backup stg" process from the new primary pool to new copy pool. This is not only time and resource consuming but this also consumes a lot of scratch tapes. How can I avoid this? As far as I know, I can not migrate data from a copy pool. to another (copy)storage pool. So expiration seems to be the only solution but then I am 'wasting' tapes for a long time. Any suggestions ? Ronald Grigori Solonovitch <Grigori.Solonovi To t...@ahliunited.co ADSM-L@VM.MARIST.EDU M> cc Sent by: "ADSM: Dist Stor Subject Manager" Re: [ADSM-L] Copy Pool question <ads...@vm.marist .EDU> 10-07-2010 00:37 Please respond to "ADSM: Dist Stor Manager" <ads...@vm.marist .EDU> Hello Andy, If you want to use new copy pools without changing existing copy pools (allow them to expiry slowly) you need: 1) keep existing primary and copy pools as they are; 2) create new primary pools (on the same disk or VTL); 3) change destination in all management classes to new primary pools; 4) create new copy pools (on new VTL); 5) backup new primary pools to new copy pools; 6) after some time old primary and copy pols will expiry. I think only this way of changing copy pools is available. It is working fine and I am able to restore data from new and old pools. I have migrated all my data recently and I am waiting for comlete expiration of data in old pools now. In addition, you can migrate data from old primary pools to new primary pools by "move data" slowly, if you couldn't wait for complete expiry time. Regards, Grigori ________________________________________ From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Huebner,Andy,FORT WORTH,IT [andy.hueb...@alconlabs.com] Sent: Friday, July 09, 2010 7:16 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Copy Pool question We will be swapping out our old VTLs for new VTLs. Our copy pools will remain unchanged. Are these statements accurate? On the day of the switch we start running the BackupSTG process against the new VTLs with all of the existing data residing on the old VTLs, the new data will be copied to the copy pools, the existing data will remain. As we migrate the data from old to new, the BackupSTG process will not duplicate the data. Meaning I will not have 2 copies of the same object in the copy pool. As we migrate the date from old to new, the BackupSTG process will not recopy the data to the copy pool. Andy Huebner This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you. Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software. [attachment "disclaimer.txt" deleted by Ronald Le Large/EPO]