Hi Richard
thanks for your hints.
We still hope on a solution that makes us happy. The idea with BackupSet is
theoretically the closest one. But I heard from people with experince, that
(i) its not so easy to restore a client with the newest backupversions and
(ii) we have the time-problem moved to the process GENERATE BACKUPSET
(collect/consolidate all newest versions).
Regards,
werner

-----Ursprüngliche Nachricht-----
Von: Richard Sims [mailto:rbs AT BU DOT EDU]
Gesendet am: Mittwoch, 18. Dezember 2002 15:21
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Re: synthetic fullbackup

>We are looking for a solution for the following problem:
>During a restore of a whole TSM-client we found that the needed ACTIVE
>backup_versions were heavy scattered around our virtual tape-volumes. This
>was the main reason for an unacceptable long restore-time...

Werner - As Geirr said, Backupsets are the optimal solution but, as all
         solutions, will require extra processing time.
Another approach is to exploit the often-unexploited MIGDelay value, on
the primary tape storage pool.  Try to match that value to your dominant
Copy Group retention value, and migrate older files to a next, tape
storage pool, and let reclamation naturally bring bring newer files
closer together.  This should get inactive versions out of the way.
The cost is extra tape data movement.

There is no "ideal" solution.  Opportune full backups (weekend?) will
get you closest to what you want.

  Richard Sims, BU