> 1a.  I first looked at define machine and it appears as if I have to define
> the TSM server and all nodes that I wish to restore at a DR site?

You may define any or all of these if you want the information stored in
the TSM database or incorporated into the recovery plan (TSM server only).
You are not required to define any of them. We have never used 'define
machine' and the related commands. Storing the corresponding information
outside of TSM allows client system administrators to reinstall their
operating systems and TSM client software while I am recreating the TSM
server.

> 1b.  Then you define the machine node association which seems as if you
> just associate all of the nodes to the tsm server that you wish to restore
> from.  Why is this needed?  You would think that this is naturally assumed
> since this is where it has been backed up/defined...

This allows for situations in which two or more client nodes are registered
for the same physical system. For example, most of our Oracle servers have
two nodes registered: one for file oriented backups and one for TDP.

> 1c.  Define Recovery Media - not quite sure what this is... There is a type
> of boot or other?  I'm not quite sure what this section is for?  It's not
> very clear!

This can be used for media required to install an operating system and
TSM client software before running TSM restores, such as Windows
distribution CD's or mksysb tapes for AIX systems. It is not required.

> 1d.  Define Media Machine Association - Still confused about this portion
> as well.  When it is stated that the recovery media is to: Select the name
> of the recovery media to be associated with one or more machines. Do they
> mean TSM server machines or node machines?

This allows for situations in which two or more systems share the same
recovery media, such as mulitple Windows systems that use the same
distribution CD's. It can be used for either client or server systems.

> 2. DRM Offsite Recovery Media - Currently we just take all of our tapes
> that have been vaulted to the DR site that were created before the DBB that
> we use for our DR.  I'm not quite sure what the commands portion of this
> querying does?  Why/what would you specify here?

I am not sure what command or commands you are referring to here.

> 3a.  Create Recovery Plan File - Where do companies usually store this
> file?  When you go down to DR, where do you begin?  I mean, what is the
> starting point?  Where do you begin?

As far as I can tell from past postings on this topics, most DRM sites
transfer two or more copies of this file to servers away from their
data centers. The transfers are done by a variety of means. I have heard
of e-mail, FTP, and NFS in this connection. Our approach is rather
unusual. We copy the recovery plan to a second file on the database
backup tape. This is relatively easy for a server running under z/OS. I
suspect that it would be much harder on other platforms.

The process at the DR site (for a Unix server platform) is as follows:
1.Recreate the operating system and TSM software on the replacement server.
2.Fetch the latest recovery plan from wherever it is stored.
3.Break the recovery plan into subfiles.
4.Execute shell scripts extracted in the previous step to recreate
  current versions of the server's configuration files and database
  and to update the status of storage pool tapes.

> 3b.  Do you use a dbbackup or a dbsnapshot?  Why would you ever want to use
> a snapshot?  You first have to restore the entire db before moving on...

We use dbsnapshots as protection from disasters that would require moving to
a replacement data center. We keep a weekly full backups and daily
incremental backups onsite as protection from smaller problems such as
disk failures. The advantage of the dbsnapshot is that it does not
interfere with the server's tracking of relationships between full and
incremental backups. I don't understand your objection to dbsnapshots;
if you end up using any form of backup of the TSM database you will have
to restore the entire DB before moving on.

> 4.  How often do you create the plan and how long do you retain the plans?

We create a plan every day and keep plans for three days. Each plan contains
instructions for restoring the latest database backup of the appropriate
type. You should create a new plan whenever you create a database backup
that will go offsite and keep the plan as long as you keep the backup.
Note that the 'source' operand on the 'prepare' and 'move drmedia' commands
must match the 'type' operand used on the relevant 'backup db' command.