> Remember that the source during the rebuild of the offsite tapes is the > primary tapes. So, if the primary pool is reclaimed it would be no > different than a backup to copy stg pool.
Actually, I think there is a difference. MOVE DATA's intent is to clear off a volumes as fast as possible, and is why aggregates are not rebuilt. I would agree with you if the offsite volumes were first deleted, and then a backup of the primary pool was run. Of course, since this is actually a mixture of the two, it would work either way. > My understanding was that what > you are saying is only true if the aggregates are in the same pool. The > other thing is you can do a RECONSTRUCT=YES and it will remove the deleted > portion of the aggregates within storage pool as it is reconstructed. Is reconstruct=yes an option on move data in 4.2? It is not on my 4.1 servers. > -----Original Message----- > From: Steve Roder [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 26, 2002 7:22 PM > To: [EMAIL PROTECTED] > Subject: Re: Mitigating Risk with TSM's incremental backups > > > > That tells me what is coming back soon. You can get elaborate and select > > only the volume name and pipe the stuff into the commands necessary to > issue > > the commands dynamically, but I just do them manually right now. We are > > heading down the automated path soon. > > > > The command that I use to move the data is: > > > > move data [volume_name] stg=[same_copy_pool] > > > > By doing this I am not exposed and I my operations department was able to > > continue a tape rotation they are used do. The side effect is reclamation > > is automatically done by doing this. I love 2 bird solutions. > > Note that the move data command differs from true reclaimation in that > move data does not rebuild aggregates, so the reclaimable space on a tape > that is within an aggregate will not free up. In other words, if you had > an aggregate of 10MB on one of these tapes, and all of the data within it > was expired, except for a single 1 byte file, move data will copy the > entire 10MB aggregate to the new output volumes. Depending on the nature > of your data, this could actually add up to a lot of wasted tapes, as that > 10MB aggregate will be copied around until that last 1 byte file is > expired. > > A nit? Perhaps...and perhaps not. > > > Steve Roder, University at Buffalo > HOD Service Coordinator > VM Systems Programmer > UNIX Systems Administrator (Solaris and AIX) > TSM/ADSM Administrator > ([EMAIL PROTECTED] | (716)645-3564 | > http://ubvm.cc.buffalo.edu/~tkssteve) > > Steve Roder, University at Buffalo HOD Service Coordinator VM Systems Programmer UNIX Systems Administrator (Solaris and AIX) TSM/ADSM Administrator ([EMAIL PROTECTED] | (716)645-3564 | http://ubvm.cc.buffalo.edu/~tkssteve)
