In our case, on this most critical server, the backupset is a part of our
DR Test because it is part of our regular DR procedures.  For this system,
we create a backupset every day.  This system, in case of emergency, can
not rely on the restore of a TSM server.  With the daily backuset, I can
start this most critical system restore first, and then work on TSM, and
the next level critical systems.  In a rare case that the backupset tape
fails, I can then attempt a restore from the restored TSM server.  The
daily backupset offers us better timing and better safety for this most
critical server.




                      "Stapleton, Mark"
                      <mark.stapleton@B        To:       ADSM-L AT VM.MARIST 
DOT EDU
                      ERBEE.COM>               cc:
                      Sent by: "ADSM:          Subject:  Re: Disaster Recovery
                      Dist Stor
                      Manager"
                      <[email protected]
                      .EDU>


                      08/31/2004 07:58
                      AM
                      Please respond to
                      "ADSM: Dist Stor
                      Manager"






From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
Behalf Of Joe Pendergast
>If the systems are small enough, and you have plenty of tapes,
>you can produce "backupset" tapes of each system.  A backupset
>is a self contained tape that allows the client to restore
>without needing the TSM server.  We use a backupset for one of
>our critical systems.

As Mr. Rodriguez mentioned earlier in this thread, using backupsets for
DR testing is not DR testing. If you're trying to replicate the
conditions that hold in a real disaster, you're not going to have
backupsets conveniently up-to-date and ready for you.

One other alternative Mr. Choate has is to run MOVE NODEDATA on the
nodes to be tested:

        MOVE NODEDATA <node_name> fromstg=<copy_pool>

Note the volume number of the tape that is written to, and check that
tape (or tapes) out in preparation for your test.

However, as Mr. Rodriguez also mentioned, this too is not a true DR
test.

--
Mark Stapleton (stapleton AT berbee DOT com)
Berbee Information Networks
 Office 262.521.5627