Gordon, DRM will not vault primary pool or backupset media. An alternative product, AutoVault, has primary pool and backupset vaulting for precisely what you are trying to accomplish. For specific situations, it is a very efficient way to retain data long-term without the need to duplicate the data or fill your tape library. The one risk is that you will not have a second copy of the data to recover from media failure.
Using AutoVault, you would direct your archive data to a separate primary pool hierarchy. It sounds like all your TSM data is archives, so you may not have a need for an incremental backup primary pool hierarchy and a copypool. Configure AutoVault to vault your archive tape primary pool. It will eject the media from your library and generate a report of what media to take offsite. It will also generate a report of empty tapes to return from the vault. Many of our customers are effectively using this technique for archive data, backupsets, and TDP (database backup) data. More information is available at: http://www.coderelief.com/tdp.htm Regards, Steve Hnath Code Relief LLC www.coderelief.com -----Original Message----- Re: Offsite Archives & DRM Forum: ADSM.ORG - ADSM / TSM Mailing List Archive Date: Jul 25, 14:25 From: Seay, Paul <[EMAIL PROTECTED]> This is certainly an alternative solution that should be consider if not the first choice at least the second. I had closed my mind that he only wanted to send primary tapes offsite. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -----Original Message----- From: Jolliff, Dale [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 8:05 AM To: [EMAIL PROTECTED] Subject: Re: Offsite Archives & DRM Why not just assign an overflow location then do a move media? You have to keep track of the tape movement manually, but at least the checkout part is simplified. -----Original Message----- From: Seay, Paul [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 12:30 AM To: [EMAIL PROTECTED] Subject: Re: Offsite Archives & DRM The answer to your question is a qualified no because I cannot think of a way to safely do it. The concept of a copy pool is to be able to protect the data in two locations. And DRM is the vehicle to support that. What you really are trying to do is a archive using primary copy pool tapes which is not what TSM was designed to do. As I see it you only have one choice here. You will have to roll your own tape movement thing. With primary tapes you have to mark them to unavailable using an UPDATE VOLUME vvvvvv ACCESS=UNAVAILABLE. You can probably create a SELECT statement that meets your criteria to create the command as follows: Select 'UPDATE VOLUME ', volume_name, 'ACCESS=UNAVAILABLE' from volumes where stgpool_name='TAPEARCH' and volume_name in (select volume_name from libvolumes) > /mark.cmd This gives you all the tapes in your library that are in the storage pool. Run this output as a macro command after striping off the first 2 lines. Then do another select: Select 'CHECKOUT LIBVOLUME ', library_name, volume_name, 'other appropriate parameters' from libvolumes where volume_name in (select volume_name from volumes where access='UNAVAILABLE') > /eject.cmd Run this the same way as above. At this point the tapes should be checked out of your library and TSM should not try to do anything with them. Now, I have not tried this so you will have to do some significant testing. There may be something I did not consider. The real negative piece here is you have to manage what expires and is ready to be put back in the library. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -----Original Message----- From: Gordon Woodward [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 24, 2002 2:57 AM To: [EMAIL PROTECTED] Subject: Offsite Archives & DRM This is a follow up to a post I sent through the other day about problems with offsite tapes we were having and TSM (for NT) not allowing anymore tapes to be loaded into the library. I've been reading the TSM Admin Guide today about DRM and copy storage pools and I think have found the solution to ours problems, however I would like to run it by some more knowledgable people. First I'll give a quick overview how our archives are currently working, I should also mention that these are really 'snapshots' of existing data on our servers and not actually removing any data from their locations. Once a month we have a scheduled job execute on our Tivoli server which runs the command "dsmc archive....etc" on each of our servers. As the server backs up the data to the Tivoli server it is temporarily stored in a disk storage pool (ARCHIVE) on our SAN, then as this disk storage pool fills up the data starts to automatically migrate across to another storage pool of type sequential access (called TAPEARCH). The next morning a scheduled job runs which migrates the remaining data held within the disk storage pool across to the sequential access storage pool, or some LTO tapes as it were. We were then checking the tapes out that belonged to this sequential access storage pool, which as it turn out is also a primary storage pool. Reading through DRM it will only recognise media (data) associated with copy storage pools, so my line of thought now is that I need to somehow convert the sequential access storage pool (TAPEARCH) from a primary pool to a copy pool. My problem now is is that we don't want to retain any copies of this archive data in our Tivoli library, if I am understanding correctly how copy storage pools work, we only want to refer to these tapes for the data stored if ever these was the need restore from them. Is there a way to configure TSM so we can move the data to a copy storage pool to use with DRM without having to also retain copies of this same data within the library system on another bunch of LTO tapes? Gordon Woodward Senior Support Analyst Deustche Asset Management (Australia) Limited [EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
