ADSM-L

Re: Expiring Files on a Copy Storage pool

2002-10-02 21:17:27
Subject: Re: Expiring Files on a Copy Storage pool
From: "Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 2 Oct 2002 21:01:05 -0400
There is no direct relationship between a copy storage pool and a primary
storage pool.  When you move data from one primary pool to another the copy
storage pool is managed just as before, the expiration criteria of the
primary objects.  Remember TSM manages the objects not tapes.  I recently
had to do something like this for our exchange data.  We have a primary
pool, onsite copy pool, and an offsite copy pool.  An onsite copy pool
volumes and any offsite copy pool volumes over 30 days are no longer
required.  So, any copy storage pool tape that has not been written to in 30
days we do a delete volume xxxxxxx discarddata=yes.  But, the data will get
copied again the next time a backup storage pool command is issued.  So, we
had to come up with a different method.

We do a move data of all primary pool volumes that have not been written to
in the past 30 days to a new primary pool that does not have backup stgpool
commands performed on it.  The retention of the data remains the same, 1
year.  But the copy pool volumes will hang around for a year also.  So, we
delete the copy pool volumes that have not been written to over 35 days.
The window difference is to prevent us from copying data again.  End Game,
we now have our Exchange data kept for 1 year, and our most recent 35 days
copied with an onsite copy and an offsite copy.  We returned over 600
Magstar tapes to our scratch pool doing this (about $30K).

If you come to Share, you will find out some of these goodies.  It is in
Dallas, in March, go to www.share.org.

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


-----Original Message-----
From: Gerhard Rentschler [mailto:g.rentschler AT RUS.UNI-STUTTGART DOT DE]
Sent: Wednesday, October 02, 2002 10:36 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Expiring Files on a Copy Storage pool


Hi,
using the new move nodedata command I moved a number of files from one
sequential stgpool to another. The source stgpool is backed up to a copy
storagepool, the target stgpool is not. Using q occupancy I can see that the
moved files are still on the copy storagepool. Are they going to be expired
by the next expire inventory run or should I run backup stgpool? What
happens if I move the files to a different stgpool which is backed up to the
same copy storage pool? Will they be deleted and backed up again? Regards
Gerhard

---
Gerhard Rentschler            email:g.rentschler AT rus.uni-stuttgart DOT de
Regional Computing Center     tel.   ++49/711/685 5806
University of Stuttgart       fax:   ++49/711/682357
Allmandring 30a
D 70550
Stuttgart
Germany

<Prev in Thread] Current Thread [Next in Thread>