How about using the Policy Domain to schedule a backup every so often. We are thinking of doing this and changing the Copy Mode (in the Backup Copy Group) to Absolute causing the backup to be a full and this will bring the node date closer for faster restores.
Thank You,
Bill Rosette
Data Center/IS/Papa Johns International
WWJD
Schwarz Werner
<Werner.Schwarz@B To: [EMAIL PROTECTED]
EDAG.CH> cc:
Sent by: "ADSM: Subject: AW: synthetic fullbackup
Dist Stor
Manager"
<[EMAIL PROTECTED]
.EDU>
12/18/2002 10:09
AM
Please respond to
"ADSM: Dist Stor
Manager"
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:[EMAIL PROTECTED]]
Gesendet am: Mittwoch, 18. Dezember 2002 15:21
An: [EMAIL PROTECTED]
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
