Tom,
I would do this;
set the diskpool to go directly to tape2 (upd stg disk1 nextpool=tape2).
Set the reclaimstgpool on tape1; this is a feature that was added
in version 3. It directs reclaim output to another pool
(upd stg tape1 reclaimstgpool=tape2).
There is no nextpool parameter for copypools. Direct your
'ba stg' commands to the newpool. I don't know of anyway to
transfer the copies from off1 to off2. You have to re-backup all your
onsite data into off2 and then just delete off1.
It would be well worth your time to sit down with the admin ref & guide
and read about managing storagepools in the guide
and 'define stg' in the admin ref.
Hope this helps,
--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <s9c1fd0c.072 AT ehc-gate2.eushc DOT org>, on 09/15/00
In <s9c1fd0c.072 AT ehc-gate2.eushc DOT org>, on 09/15/00
at 11:06 AM, Tom Melton <Tom_Melton AT EMORY DOT ORG> said:
>I am soon to be migrating from 3490 tape technology to 3590E tape
>technology. Will the following work?
>Say I have the following storage pools:
>DISK1 (Disk storage pool - next storage pool = TAPE1)
>TAPE1 (3490 sequential access pool)
>TAPE2 (3590 sequential access pool)
>OFF1 (3490 copy pool for DISK1 and TAPE1)
>OFF2 (3590 copy pool)
>If I were to set the "Next Storage Pool" field on TAPE1 pool to be
>TAPE2 and set the TAPE1 pool access to READONLY, will the TAPE1 pool
>basically be skipped and the TAPE2 pool be used as secondary storage for
>pool DISK1?
>Also, if I set the "Reclamation Threshold" on pool TAPE1 to a very low
>percentage, or even like 1%, will the tapes recycle to pool TAPE2?
>Lastly, if I were to set the "Next Storage Pool" field on OFF1 pool to
>be OFF2 and set the OFF1 pool access to READONLY, and then if I set the
>"Reclamation Threshold" on pool OFF1 to a very low percentage, or even
>like 1%, will the tapes recycle to pool OFF2?
>Seems like this should work, and not require manual MOVE DATA commands.
> Especially since the MOVE DATA commands are not for COPY pools.
>Is the above workable?
>Thanks in advance....
>Tom Melton
>Emory HealthCare
>Emory University
|