Thanks but that willl not work here. I have mount retention set at 1 minute.
When I inherited the system, mount retention was set at 1 HOUR and with
collocation and lots of nodes *SM had almost all 24 tape drives tied up
preventing other batch processes and HSM from getting any drives! It's
behaving a little more sanely now. (:

 Al
+
+ I'd change it to:
+
+ backup stg disk copy
+ backup stg tape copy (for anything that might have been migrated
+ during the
+ night.  Do it this way since the copy pool tapes are already mounted and
+ ready to go)
+ migrate disk tape
+
+
+
+ Thank you, and all the others who have responded. I inherited *SM
+ and those
+ who set it up before me were under the impression that it WOULD back the
+ data up twice. I believed otherwise but I gave them the benefit
+ of the doubt
+ and asked. Again, thank you very much for responding to my question. Looks
+ like I've be able to shave 2 hours off of my morning processing.
+ (That tape
+ to tape copy AFTER migration was a killer. Especially with 3490 tapes!)
+
+ +
+ + We do what you describe every night - saves a lot of tape mounts,
+ + especially
+ + since our onsitetape is collocated:
+ +
+ + backup stgpool diskpool offsitecopypool
+ + migrate to onsitetape
+ + backup stgpool onsitetape offsitecopypool
+ +
+ +
+ + BACKUP STGPOOL is always INCREMENTAL - TSM checks the DB and only copies
+ + files that aren't in the destination copy pool already.
+ +
+ +
+ +
+ + Hello fellow *SMers! I'm thinking of redoing how our backup pool
+ + migration/tape copies process is done to increase efficiency. We are
+ + currently processing this way:
+ +
+ + Backuppool (disk) migration to primary onsite tape pool (3490).
+ + Tapepool (onsite) copy backed up to vault (offsite) tape copy pool.
+ +
+ + What I would like to do is this:
+ +
+ + Backup disk pool to vault tape (offsite) copy.
+ + Migrate disk to tape (primary onsite) copy.
+ + Backup primary tape pool to offsite pool to catch any migration
+ etc. that
+ + may have occurred during the last 24 hours.
+ +
+ + My concern is this. I do not want to back up the data TWICE
+ from the disk
+ + pool to the offsite pool. (Once from disk to offsite pool and again from
+ + onsite tape pool to offsite tape pool.) That is, is *SM smart
+ + enough to know
+ + that the data that was backed up to the vault (offsite) pool prior to
+ + migration has already been backed up and will not back it up
+ + again from the
+ + onsite tape pool to the offsite pool when the "BACKUP STG
+ + TAPEPOOL COPYPOOL"
+ + command is executed?
+ +
+ + My environment is TSM 4.1.0.0 on OS390 with 24 3490 tape drives.
+ +
+ + Thanks for listening!
+ +
+ + Alan Davenport
+ + Selective Insurance
+ + alan.davenport AT selective DOT com
+ +
+