brentwg
ADSM.ORG Member
Hi:
I work for a university that achives a great deal of raw particle accel. data directly to tape. As a consequence, we are constantly almost running out of scratch tapes. The current process for archiving is as follows:
1) all part. accel. data is archived directly to tape - archivetape storage pool.
2) each night, a "housekeeping" script copies archivetape storage pool data to the copypool.
However, we recently decided that this data (since it already resides on tape at the client's location) is no longer is required to be copied to the copypool. (Yes, I agree that it's a risk. But the client doen't want to a] pay for more tapes, nor b] have this data residing in 3 locations.)
In order to prevent all future archivetape data from being copied to the copypool, I simply commented out the lines in the housekeeping script which executes these commands. That takes care of the future no problem. However, I was wondering what the best method is for dealing with the 150 tapes which already contain copies of archivetape data? Ideally, we want to check these tapes back in as scratch.
I thought that I could do the following:
1) identify each copypool tape that contains archivetape data
2) issue the following command: "del vol [vol_name] discarddata=yes"
3) check this tape back into the library as scratch
A number of consequences worry me, however. If I discard data from a copypool tape, does this somehow affect the data already residing in the primary storage pool (archivetape)? Does reclamation flow in only one direction (primary storage pool to copypool)? Or is reclamation even an issue here.
Basically, what I am trying to ask here is this: by deleting files from my copypool, am I also telling the TSM database to delete files from the archivetape pool?
Obviously I want this data to reside in the library. I just don't want it to waste twice as much space by residing offsite in the copypool as well.
I work for a university that achives a great deal of raw particle accel. data directly to tape. As a consequence, we are constantly almost running out of scratch tapes. The current process for archiving is as follows:
1) all part. accel. data is archived directly to tape - archivetape storage pool.
2) each night, a "housekeeping" script copies archivetape storage pool data to the copypool.
However, we recently decided that this data (since it already resides on tape at the client's location) is no longer is required to be copied to the copypool. (Yes, I agree that it's a risk. But the client doen't want to a] pay for more tapes, nor b] have this data residing in 3 locations.)
In order to prevent all future archivetape data from being copied to the copypool, I simply commented out the lines in the housekeeping script which executes these commands. That takes care of the future no problem. However, I was wondering what the best method is for dealing with the 150 tapes which already contain copies of archivetape data? Ideally, we want to check these tapes back in as scratch.
I thought that I could do the following:
1) identify each copypool tape that contains archivetape data
2) issue the following command: "del vol [vol_name] discarddata=yes"
3) check this tape back into the library as scratch
A number of consequences worry me, however. If I discard data from a copypool tape, does this somehow affect the data already residing in the primary storage pool (archivetape)? Does reclamation flow in only one direction (primary storage pool to copypool)? Or is reclamation even an issue here.
Basically, what I am trying to ask here is this: by deleting files from my copypool, am I also telling the TSM database to delete files from the archivetape pool?
Obviously I want this data to reside in the library. I just don't want it to waste twice as much space by residing offsite in the copypool as well.
