On Thu, 16 Oct 2003, Richard Sims wrote: > >Now the problem. Some of these 'move data' processes treat the volume > >that is being emptied as 'offsite', even though the volume has been loaded > >into the library and its access updated to readwrite. I'm pretty sure the > >reason for this is that the volumes in question have files at the > >beginning and/or end that span to other copy pool volumes which are > >themselves still offsite. > ... > > You can greatly simplify the task and eliminate the problems you are > experiencing with the inevitable spanning issue by just doing > DELete Volume ... DISCARDdata=Yes > The next Backup Stgpool will automatically regenerate an offsite volume > with that data, and pack it much fuller than Move Data can. It's a win > all around.
But isn't that just going to mean that all those primary pool tape mounts will have to occur during the next stgpool backup? Or would there possibly be fewer extra tape mounts during stgpool backup due to different processing logic in the server (e.g., mount a primary pool volume once, read all the needed data off of it)? Our daily process to backup the primary tape pools usually has little to do, and few input volumes to mount, since we back up the disk pools just before migrating. My goal here is to minimize the number of tape mounts and the time that the tape drives are tied up, whether it's in 'move data' processing or 'backup stgpool' processing. Thanks, Bill Bill Kelly Auburn University 334-844-9917
