Re: TSM Bare Restore AIX Different Arch

[Frank Tsao, email is [EMAIL PROTECTED]]

We had used SYSBACK to perform three functions in addition to TSM:

Copy rootvg to a SYSBACK server on a monthly basis. Total of 200+ systems.
Cut a tape remotely for all systems on a semiannual basis.
Create a network boot option and refreshed all the bootp servers and boot
client roles on a quarterly basis.

You can see SYSBACK features in the following URL:

http://sysback.services.ibm.com/sysback.nsf/en/features

Frank Tsao
[EMAIL PROTECTED]
PAX 25803, 626-302-5803
FAX 626-302-7131



                    "Kauffman,
                    Tom"                 To:     [EMAIL PROTECTED]
                    <KauffmanT@NI        cc:
                    BCO.COM>             Subject:     Re: TSM Bare Restore AIX 
Different Arch
                    Sent by:
                    "ADSM: Dist
                    Stor Manager"
                    <[EMAIL PROTECTED]
                    RIST.EDU>


                    08/22/2001
                    08:50 AM
                    Please
                    respond to
                    "ADSM: Dist
                    Stor Manager"






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:[EMAIL PROTECTED]]
> Sent: Wednesday, August 22, 2001 9:42 AM
> To: [EMAIL PROTECTED]
> 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
>