SEO

Is it possible to write a mksysb image that I've saved to an nfs share
to a bootable tape from the machine with the NFS share?
Basically I'm looking to have a disaster preparedness strategy, so in
the event of a system crash, I could write the weekly mksysb from the
NFS share to tape and recover the OS from that.

michael.shulman wrote:
> Is it possible to write a mksysb image that I've saved to an nfs share
> to a bootable tape from the machine with the NFS share?
> Basically I'm looking to have a disaster preparedness strategy, so in
> the event of a system crash, I could write the weekly mksysb from the
> NFS share to tape and recover the OS from that.

1. I have done it.
2. It's way more complicated than it's worth
3. It's not supported by IBM.
4. Check out NIM --it's in all AIX installs, it's easy to set up and
it's supported. You can boot off the network and restore any mksysb
you can save to the NIM server.

Also - do you really need a BOOTABLE tape? You could always boot off
CD's then install from the mksysb backup copied onto a tape... Half
the time AIX has a bug in it requiring you to do this anyway although I
think it's cleared up this year. ( It'll be back...)

Thanks for responding.
My concern is - does the CD I'm booting off of have to be at the same
patch level on on the tape (for example an AIX 5.3.00 CD and a mksysb
at 5.3.05-01)
I've been trying for a while with very little success to build a NIM
environment. There's something going on with the networking on the NIM
master. The response to building a new machine from an existing SPOT is
spurrattic, meaning that the bootp on the NIM master will see the
requests but won't even respond half of the time. I've opened up a
trouble ticket with IBM but they don't seem to have a clue on how to
resolve it. I've gone as far as destroying the entire NIM environment
and rebuilding it, as well as the entire networking environment.
I suppose I can pull down the DVD's of the latest patch level if
necessary (it's probably smarter then what I'm currently doing
anyway.)


jthomp1515@yahoo.com wrote:
> michael.shulman wrote:
> > Is it possible to write a mksysb image that I've saved to an nfs share
> > to a bootable tape from the machine with the NFS share?
> > Basically I'm looking to have a disaster preparedness strategy, so in
> > the event of a system crash, I could write the weekly mksysb from the
> > NFS share to tape and recover the OS from that.
>
> 1. I have done it.
> 2. It's way more complicated than it's worth
> 3. It's not supported by IBM.
> 4. Check out NIM --it's in all AIX installs, it's easy to set up and
> it's supported. You can boot off the network and restore any mksysb
> you can save to the NIM server.
>
> Also - do you really need a BOOTABLE tape? You could always boot off
> CD's then install from the mksysb backup copied onto a tape... Half
> the time AIX has a bug in it requiring you to do this anyway although I
> think it's cleared up this year. ( It'll be back...)

> jthomp1515@yahoo.com wrote:
> > michael.shulman wrote:
> > > Is it possible to write a mksysb image that I've saved to an nfs share
> > > to a bootable tape from the machine with the NFS share?
> > > Basically I'm looking to have a disaster preparedness strategy, so in
> > > the event of a system crash, I could write the weekly mksysb from the
> > > NFS share to tape and recover the OS from that.
> >
> > 1. I have done it.
> > 2. It's way more complicated than it's worth
> > 3. It's not supported by IBM.
> > 4. Check out NIM --it's in all AIX installs, it's easy to set up and
> > it's supported. You can boot off the network and restore any mksysb
> > you can save to the NIM server.
> >
> > Also - do you really need a BOOTABLE tape? You could always boot off
> > CD's then install from the mksysb backup copied onto a tape... Half
> > the time AIX has a bug in it requiring you to do this anyway although I
> > think it's cleared up this year. ( It'll be back...)

Hello Michael,

You already have weekly mksysb images in a safe place. If the machines
you want to recover have a CD or DVD drive, the following would strike
me as the easiest to do:

In case you need to recover a machine create an iso-Image with mkcd or
mkdvd _from_ the mksysb image (try smit mkcd - it will ask you for the
mksysb right away). Burn it onto (possibly several) CDs (a regular PC
will handle this if your server has no optical writer) and boot your
recovering server from it - it will restore your rootvg just like the
tape did.

The nim setup, as the foreposter wrote, provides more features and
allows faster recovery/installation. But if disaster recovery is your
only demand then it might be overpowerd, much more so since a (bare
metal) recovery should be least frequently needed and I guess in that
case a procedure you have full insight and control is more important
than speed.

Regards
Joachim

michael.shulman wrote:
> Thanks for responding.
> My concern is - does the CD I'm booting off of have to be at the same
> patch level on on the tape (for example an AIX 5.3.00 CD and a mksysb
> at 5.3.05-01)

I believe the short answer to that is, "yes". BTW, once you have your
NIM environment set up, the master MUST be at the same or LATER OS level
(including fixes IIRC) than the client(s).

> I've been trying for a while with very little success to build a NIM
> environment. There's something going on with the networking on the NIM
> master. The response to building a new machine from an existing SPOT is
> spurrattic, meaning that the bootp on the NIM master will see the
> requests but won't even respond half of the time. I've opened up a
> trouble ticket with IBM but they don't seem to have a clue on how to
> resolve it. I've gone as far as destroying the entire NIM environment
> and rebuilding it, as well as the entire networking environment.
> I suppose I can pull down the DVD's of the latest patch level if
> necessary (it's probably smarter then what I'm currently doing
> anyway.)

Take a look at the network adapter speed and duplexing on both the
master AND the client; then check to see what the switch port each is
connecting through (assuming there is one) is set to. In my experience
with AIX (over the last 15 years :-} ), I've found most times, if your
systems are using 100 Mb/s adapters, this problem is related to
incompatible speed and/or (MOST times) duplexing negotiation "somewhere"
between the 2 systems (in NIM's case, the "client" and "master"). Once
you know which interface is in use, a good command to use to see what
the adapter(s) are set to is "entstat" (look up the command for syntax
and useage).

In my NIM admin days, I've never had ANY 100 Mb/s adapter issues -
assuming the adapter was good :-) - if the master's, client's AND THE
SWITCH port's settings (each was connected to) were set to 100 full
duplex; I HAVE had LOTS of similar AIX/NIM (though this is NOT specific
to NIM) issues if I left ANYTHING in the "100 Mb/s path"
autonegotiating...do a search on this forum for previous postings
related to this issue....again, NOTE this is if both ends are using 100
Mb/s adapters...things change if anything in there uses 10 Mb/s and/or
gigabit :-O

BTW, the "rules" change once the adapter-switch-adapter connection goes
to "gigabit" speeds.

HTHS and (as always with all things AIX/UNIX) I stand to be corrected :-)

P

dohhhh wrote:
> michael.shulman wrote:
> > Thanks for responding.
> > My concern is - does the CD I'm booting off of have to be at the same
> > patch level on on the tape (for example an AIX 5.3.00 CD and a mksysb
> > at 5.3.05-01)
>
> I believe the short answer to that is, "yes". BTW, once you have your
> NIM environment set up, the master MUST be at the same or LATER OS level
> (including fixes IIRC) than the client(s).
>
> > I've been trying for a while with very little success to build a NIM
> > environment. There's something going on with the networking on the NIM
> > master. The response to building a new machine from an existing SPOT is
> > spurrattic, meaning that the bootp on the NIM master will see the
> > requests but won't even respond half of the time. I've opened up a
> > trouble ticket with IBM but they don't seem to have a clue on how to
> > resolve it. I've gone as far as destroying the entire NIM environment
> > and rebuilding it, as well as the entire networking environment.
> > I suppose I can pull down the DVD's of the latest patch level if
> > necessary (it's probably smarter then what I'm currently doing
> > anyway.)
>
> Take a look at the network adapter speed and duplexing on both the
> master AND the client; then check to see what the switch port each is
> connecting through (assuming there is one) is set to. In my experience
> with AIX (over the last 15 years :-} ), I've found most times, if your
> systems are using 100 Mb/s adapters, this problem is related to
> incompatible speed and/or (MOST times) duplexing negotiation "somewhere"
> between the 2 systems (in NIM's case, the "client" and "master"). Once
> you know which interface is in use, a good command to use to see what
> the adapter(s) are set to is "entstat" (look up the command for syntax
> and useage).
>
> In my NIM admin days, I've never had ANY 100 Mb/s adapter issues -
> assuming the adapter was good :-) - if the master's, client's AND THE
> SWITCH port's settings (each was connected to) were set to 100 full
> duplex; I HAVE had LOTS of similar AIX/NIM (though this is NOT specific
> to NIM) issues if I left ANYTHING in the "100 Mb/s path"
> autonegotiating...do a search on this forum for previous postings
> related to this issue....again, NOTE this is if both ends are using 100
> Mb/s adapters...things change if anything in there uses 10 Mb/s and/or
> gigabit :-O
>
> BTW, the "rules" change once the adapter-switch-adapter connection goes
> to "gigabit" speeds.
>
> HTHS and (as always with all things AIX/UNIX) I stand to be corrected :-)
>
> P



Another aspect of NIM setups is NFS -- NIM uses it a lot and it's not
very intelligent about it. It is best to make sure /etc/exports and
xtab are cleaned out before you start and use smitty nfs to do it so
it really cleans it up properly. Once it's cleaned out NIM will take
it from theres

Assuming you network was functional before setting up NIM it really
should work if you have selected the right interface and speed
settings ( entstat -d entX check and see)

I use this for my DR plan and we test it twice a year at Stirling
Forest -- recover a Veritas netbackup server and a NIM server from
mksysb, use Veritas to restore needed mksysbs to the NIM server,
reconfigure the nim server to the new network and proceed. always
works , even with newbie sysadmins.

Tips--

Use the smitty nim menus as much as possible
On running systems , configure the nim client from the client side and
you can see if it set up properly.
remove any old /etc/niminfo files from the client before you start.
Check /.rhosts and see if it got updated with the nim server info.
Also if you are having odd issues check /etc/hosts on both sides and
see what's in there.


CD stuff -- you can create ISO images from your mksysbs and then burn
image of CD #1 using any cd burner -- and you only need the first
CD if all you need is a boot. ( And this does work I did it a couple
years ago when the mksysb's were broken in 5.2 ML 04.)

If you really really wanna do a tape I THINK I go tthis to work a
couple years ago as well but it's really not something I would rely
on:
How to make a bootable installable mksysb tape from a mksysb image on
disk:



Use the image.data file out of the desired mksysb image to create a
"dummy" mksysb:

on the target system:

extract the correct image.data file out of the host mksysb image as
follows:

cd /
/usr/sbin/restore -xvq -f'/path/to/desiredmksysb_image_file' -t
'./image.data'

this should put an image.data file in "/" with the date stamp of the
mksysb image file.

then run the mksysb without creating a new image.data file...

on the target system

create an exclude.rootvg file in /etc that excludes all:

^./ (should work - this just speeds up the process; is not essential)

run mksysb -e -p /dev/rmt0

creates a bootable tape with a very small backup segment due to the
excludes.

position the tape at the start of the actual backup:

tctl -f/dev/rmt0 rewind
tctl -f /dev/rmt0.1 fsf 3


copy the desired mksysb image over the original one:

dd if=/path/to/desiredmksysb_image_file of=/dev/rmt0.1 obs=1024
conv=sync

The dd will copy the entire mksysb image onto the tape.

At this point you have a complete bootable mksysb with the
desiredmksysb_image_file data and structure on it.

Kept working on the NIM problem and it turned out to in fact be the NFS
shares. I blew away the NFS settings and xtab and set it back up again,
and the NIM ran successfully. Making bootable tapes isn't nessesary
anymore :-).
Thanks everyone for your help!



jthomp1515@yahoo.com wrote:
> dohhhh wrote:
> > michael.shulman wrote:
> > > Thanks for responding.
> > > My concern is - does the CD I'm booting off of have to be at the same
> > > patch level on on the tape (for example an AIX 5.3.00 CD and a mksysb
> > > at 5.3.05-01)
> >
> > I believe the short answer to that is, "yes". BTW, once you have your
> > NIM environment set up, the master MUST be at the same or LATER OS level
> > (including fixes IIRC) than the client(s).
> >
> > > I've been trying for a while with very little success to build a NIM
> > > environment. There's something going on with the networking on the NIM
> > > master. The response to building a new machine from an existing SPOT is
> > > spurrattic, meaning that the bootp on the NIM master will see the
> > > requests but won't even respond half of the time. I've opened up a
> > > trouble ticket with IBM but they don't seem to have a clue on how to
> > > resolve it. I've gone as far as destroying the entire NIM environment
> > > and rebuilding it, as well as the entire networking environment.
> > > I suppose I can pull down the DVD's of the latest patch level if
> > > necessary (it's probably smarter then what I'm currently doing
> > > anyway.)
> >
> > Take a look at the network adapter speed and duplexing on both the
> > master AND the client; then check to see what the switch port each is
> > connecting through (assuming there is one) is set to. In my experience
> > with AIX (over the last 15 years :-} ), I've found most times, if your
> > systems are using 100 Mb/s adapters, this problem is related to
> > incompatible speed and/or (MOST times) duplexing negotiation "somewhere"
> > between the 2 systems (in NIM's case, the "client" and "master"). Once
> > you know which interface is in use, a good command to use to see what
> > the adapter(s) are set to is "entstat" (look up the command for syntax
> > and useage).
> >
> > In my NIM admin days, I've never had ANY 100 Mb/s adapter issues -
> > assuming the adapter was good :-) - if the master's, client's AND THE
> > SWITCH port's settings (each was connected to) were set to 100 full
> > duplex; I HAVE had LOTS of similar AIX/NIM (though this is NOT specific
> > to NIM) issues if I left ANYTHING in the "100 Mb/s path"
> > autonegotiating...do a search on this forum for previous postings
> > related to this issue....again, NOTE this is if both ends are using 100
> > Mb/s adapters...things change if anything in there uses 10 Mb/s and/or
> > gigabit :-O
> >
> > BTW, the "rules" change once the adapter-switch-adapter connection goes
> > to "gigabit" speeds.
> >
> > HTHS and (as always with all things AIX/UNIX) I stand to be corrected :-)
> >
> > P
>
>
>
> Another aspect of NIM setups is NFS -- NIM uses it a lot and it's not
> very intelligent about it. It is best to make sure /etc/exports and
> xtab are cleaned out before you start and use smitty nfs to do it so
> it really cleans it up properly. Once it's cleaned out NIM will take
> it from theres
>
> Assuming you network was functional before setting up NIM it really
> should work if you have selected the right interface and speed
> settings ( entstat -d entX check and see)
>
> I use this for my DR plan and we test it twice a year at Stirling
> Forest -- recover a Veritas netbackup server and a NIM server from
> mksysb, use Veritas to restore needed mksysbs to the NIM server,
> reconfigure the nim server to the new network and proceed. always
> works , even with newbie sysadmins.
>
> Tips--
>
> Use the smitty nim menus as much as possible
> On running systems , configure the nim client from the client side and
> you can see if it set up properly.
> remove any old /etc/niminfo files from the client before you start.
> Check /.rhosts and see if it got updated with the nim server info.
> Also if you are having odd issues check /etc/hosts on both sides and
> see what's in there.
>
>
> CD stuff -- you can create ISO images from your mksysbs and then burn
> image of CD #1 using any cd burner -- and you only need the first
> CD if all you need is a boot. ( And this does work I did it a couple
> years ago when the mksysb's were broken in 5.2 ML 04.)
>
> If you really really wanna do a tape I THINK I go tthis to work a
> couple years ago as well but it's really not something I would rely
> on:
> How to make a bootable installable mksysb tape from a mksysb image on
> disk:
>
>
>
> Use the image.data file out of the desired mksysb image to create a
> "dummy" mksysb:
>
> on the target system:
>
> extract the correct image.data file out of the host mksysb image as
> follows:
>
> cd /
> /usr/sbin/restore -xvq -f'/path/to/desiredmksysb_image_file' -t
> './image.data'
>
> this should put an image.data file in "/" with the date stamp of the
> mksysb image file.
>
> then run the mksysb without creating a new image.data file...
>
> on the target system
>
> create an exclude.rootvg file in /etc that excludes all:
>
> ^./ (should work - this just speeds up the process; is not essential)
>
> run mksysb -e -p /dev/rmt0
>
> creates a bootable tape with a very small backup segment due to the
> excludes.
>
> position the tape at the start of the actual backup:
>
> tctl -f/dev/rmt0 rewind
> tctl -f /dev/rmt0.1 fsf 3
>
>
> copy the desired mksysb image over the original one:
>
> dd if=/path/to/desiredmksysb_image_file of=/dev/rmt0.1 obs=1024
> conv=sync
>
> The dd will copy the entire mksysb image onto the tape.
>
> At this point you have a complete bootable mksysb with the
> desiredmksysb_image_file data and structure on it.