> >As big a fan of backupsets as I am, I feel the need to point out the > >disadvantage of backupsets: you can't browse through them if you don't > >the name of a desired file or its directory location. You can run Q > >BACKUPSETCONTENTS, but then you'll have to grep through a *very* long > >output. > > In our environment, a backupset would be ideal to keep our TSM DB from > growing constantly due to archives, except for the fact we are limited in > the number of tape drives available to process the backupset data migration > tape-tape. Any ideas to circumvent this physical limitation would be much > appreciated-
That's easy - buy more tape drives. :) (A) Actually, I'm almost serious about that; if you need more resources, then you need more resources. It's a simple problem of money. :) But, back to reality... (B) The BackupSet needs to copy only the ACTIVE version of the files in the filespaces you are planning to retain for an extended period. By using disk storage pools (perhaps specific ones dedicated to the data to be "archived"), with CACHE and/or MIGDELAY, you could try to retain more of your ACTIVE backup versions on disk? Or... (C) Another idea might be to create a "loopback" TSM server definition. This would allow you to generate the backupsets from local storage pools, to the "loopback" TSM server definition, where they would initially be saved to a disk storage pool. They could then later be migrated onto a separate tape storage pool. This way, with enough disk, you would only need a single tape drive during the backupset generation. Using a loopback TSM server to store backupsets has some pro's and con's. The benifits are potentially using fewer tape drives, and also consolidating multiple backupsets onto a single tape. Normally each backupset requires a unique tape, but when using a loopback TSM server each backupset uses a unique "virtual volume", multiples of which can be stored on each physical tape. The downside of storing backupsets on virual volumes are that you lose the ability to restore the backupset in isolation from the TSM server. The index of the physical tape used to store the backupset virtual volumes is kept in the TSM database, so you will need access to the TSM server to retrieve the backupset virtual volumes. Another important downside might be whether Tivoli would support this "innovative" configuration. :) Or, finally... (D) Try to plan your normal policy to cater for >95% of your data restoration requirements. Restoring files from monthly "archives" should be the exception. Try to limit the data to be "archived" (ie. included in a BackupSet) to only the "critical" data. Perhaps separate important business data onto it's own filespace and only include that filespace in the backupset? To assist in the recovery of files from a backupset you might consider saving a text file listing the contents of each backupset at creation time. You could use either "q backupsetcontents" or an SQL query to produce this list. Another issue with backupsets is that the GUI cannot restore an individual file, only the entire backupset. You need to use the DSMC command line, and specify the filename, to restore an individual file from a backupset. Though, my favorite option is still (A) Buy more tape drives. However, (D) sounds good too. :) Steven P. -- Steven Pemberton Mobile: +61 4 1833 5136 Innovative Business Knowledge Office: +61 3 9820 5811 Senior Enterprise Management Consultant Fax: +61 3 9820 9907
