write mksysb to tape after the fact - Aix

This is a discussion on write mksysb to tape after the fact - Aix ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: write mksysb to tape after the fact

  1. write mksysb to tape after the fact

    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.


  2. Re: write mksysb to tape after the fact


    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...)


  3. Re: write mksysb to tape after the fact

    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...)



  4. Re: write mksysb to tape after the fact


    > 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


  5. Re: write mksysb to tape after the fact

    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

  6. Re: write mksysb to tape after the fact


    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.


  7. Re: write mksysb to tape after the fact

    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.



+ Reply to Thread