Dave, we use much the same approach as your current one, with similar
problems on the mksysb. We try to run a mksysb at least monthly, or after
maintenance is applied to AIX.

The difference is that our mksysb tapes go off-site after we cut them.

Is there any reason you can't do this?

If you really can't off-site the mksysb tapes, I'd seriously look at setting
up one system as a network install master with just AIX and TSM on it. Back
when we had the SP frames this was our Control Workstation. It had one
current mksysb image file, for the TSM server.

Get this box up, network install the TSM server, use TSM to restore the
filesystem of current (weekly, in our case) mksysb images for the other
systems, and network install them.

You still have the problem of getting an off-site non-tsm backup of this
system though -- unless your D/R window is long enough to allow building the
TSM server with a 'vanilla' AIX image, followed by restoring the filesystem
of images, followed by re-booting the TSM server again from the archived
image.

Tom Kauffman
NIBCO, Inc

> -----Original Message-----
> From: Dave Z [mailto:Dave.Zarnoch AT SUNGARD DOT COM]
> Sent: Wednesday, August 22, 2001 9:42 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: TSM Bare Restore AIX Different Arch
>
>
> Folks,
>
> I apologize if this is a FAQ....
>
> (I cannot find a "complete" documented procedure)
>
> :0(
>
>
> Currently, we use the following procedure to restore systems:
>
> 1) Restore the OS using the "cloaner" method as published by IBM:
>    a) Boot off of the AIX installation media
>    b) Restore system from tape (mksysb)
>   (This allows you to recover the OS to dissimilar hardware)
> 2) Reconstruct the network (including the TSM backup network).
> 3) Restore all application data (and system data if needed) via TSM.
>
> This methodology does not support a true DR test as our
> mksysb tapes are
> not cut regularly or vaulted.
>
> Unfortunately we do not have a solution that allows us to cut
> bootable AIX
> tapes on a regular basis.  (Not all of the systems have local
> tape drives.
> The procedure can not be automated. etc.)
>
> In the future we must restore all RS/6000s with only our vaulted
> installation media (OS and TSM) as well as our vaulted TSM
> tapes.  Due to
> this we must develop procedures for a total bare metal restore of an
> RS/6000 using only the OS installation media, TSM backup
> tapes, and any
> relevant TSM disaster recovery reports.
>
> We would like to develop a procedure that details the
> recovery of a generic
> RS/6000 using only installation media, TSM backup, and
> disaster recovery
> reports.
>
> Ideas/Things to consider:
>
> We can not assume that we will recover systems to identical
> hardware.  As
> such we can not simply install a base OS and restore.
>  What system files (/etc/passwd, /etc/hosts, etc...) are
> relevant to the
> recovery of the system.
>  What system files should not be recovered?  (I.e. kernel,
> driver specific,
> etc.)
>
>
> Can anyone help with any existing procedures or point me in the proper
> direction?
>
> Thanks!
>
>
> DaveZ
>