Backupsets can be useful in some situations, but saving time is not one of
their benefits.  In the experiments I've done, generating a backupset took
as long as or longer than restoring the client.  The generate backupset
process will mount the same tapes as the restore.  If you generate
backupsets regularly, and already have one on hand, then yes it would save
time.   But regularly generating backupsets would take a lot of time and
duplicate the normal backups.

Another issue with restores, is that you can only do one filespace per
command.  This may not be a big problem for NT clients, but unix clients
typically have ten or more filesystems.  And unless the client is
collocated-by-filespace, chances are that many tapes will have multiple
filespaces on them and therefore will have to be mounted several times.
Also, if you run those restore sessions in parallel, some of them will
probably compete for the same tapes at some time.  I have observed this
every time we do disaster recovery tests.

This leads me on to something I have been thinking about over the last few
weeks...  in the spirit of the season, here is the top item on my TSM
wishlist:

Since TSM has in its database the complete information about what each
client has backed up, it is conceivable that TSM could construct an
"optimized restore plan" for an entire client node.  There should be an
option on the restore command to indicate that all filespaces of a node be
restored (or maybe a "restore node" command), and TSM should be able to
multithread that operation to insure that each tape is accessed only once
and no two sessions require the same tape.  The restore command should also
have a "preview=yes" option so we can pre-fetch any needed tapes from the
rack or the vault.  And it should also be able to give an estimate of how
long the restore should take, even it has to be qualified by "assuming 10
GB/hour throughput", or something like that.

Now, some of you may be thinking this is a good opportunity for a third
party product or a server script.... I thought so too.... but as far as I
can tell, that valuable information, which TSM must have in its database,
cannot be retrieved by any known query or select.  What you need to know is
"what tape contains the active version of file xxx?"  TSM can certainly
determine this... it must, to be able to restore anything, but I challenge
anyone to find it without actually doing a restore!

Robin Sharpe
Berlex Labs



                    Karel Bos
                    <Karel.Bos@NU
                    ON.COM>       To:    ADSM-L AT VM.MARIST DOT EDU
                                  cc:    (bcc: Robin Sharpe/WA/USR/SHG)
                    12/19/01      Subject:
                    05:41 AM             Re: Incremental forever -- any 
problems? (Scary thoughts)
                    Please
                    respond to
                    "ADSM: Dist
                    Stor Manager"







Are back-up sets a option?