Ignite server - building replacement target hardware question

[I J Clifford]

Hi all

I have 7 machines I need to backup with Ignite server then push out images to 7 "new" servers replacement hardware. FYI The old and new hardware is not identical, L class , N class and RP mix.

Previously I have used Ignite on each node to backup to local tape device, and swap the tapes over.

What I would like to do is update the Ignite server with the latest O/S patches and hardware enablement bundles, then take the images of the 7 "old" servers and store to locally connected SAN on the Ignite server.

My question is this .... When I push out those images to "new" servers, will Ignite be able to build the "new" servers referencing the newly updated O/S patch bundles and hardware enablement bundles stored locally on the Ignite server. How is this achieved please?

My logic for doing this would be therefore to avoid patching and updating 7 "old" nodes with later versions of Ignite, O/S patches and hardware bundles and having to reboot them (as they are live production systems) before taking images to local tapes.

Sorry if this is blindingly obvious to those familiar with Ignite server - I don't have a test machine I can make into Ignite server (unfortunately)

All help appreciated

Cheers - Ian

[Bill Hassell · Accepted solution]

Each Ignite backup image contains the contents of that machine, so when you restore the image on another box, it will be identical, patches, apps, etc. NOTE: Ignite should be run on VG00 only so you have a bootable machine. You should then use fbackup for all the non-VG00 data and after activating and mounting the non-VG00 volumes, restore the rest of the data.

[I J Clifford]

Hi Bill

OK so what I was trying to acheive isn't viable then I guess, I'll have to update the individual "old" nodes with all patches/bundles, then store image on central server, then push out to "new" kit form central ignnote server.

Thanks for the clarity Bill :)

Ian

[Marvin Strong]

As Bill, stated you should only use ignite for vg00, not the entire machine. Somewhat unclear if that is your intention or not.

If your non-OS disks are all on the SAN, it should be fairly easy to get back up an running without a restore of the data. Just vgexport -s -p -m those volume groups before you make your image( also might be a good idea to put them in a second place ). Then you can just vgimport when you get the OS on your new hardware. The reason you will probably have to vgexport vgimport will be that the ctd numbers may changes. Mostly likely the c number will.

Also your images of those 7 servers will be identical restores. You would then need to install the latest patch bundle manually. No way that I know of to automate that with make_net_recovery. Of course this is still fairly trivial. its easy to run swinstall after you get the OS back on the machine.

Now if you did a new install from your ignite server, then you could automate the patch installation aswell. Also keep in mind that if you are moving from cell based to bus based your ignite images will probably not work. But if your moving from bus based to cell based they should work.

[I J Clifford]

Hiya

I would have only been attemping the VG00 restore, I'm familiar with vgexport/vgimport, it was just the automation of the patch bundles on the source machines that interested me - I got burned once as I ignited from a L-2000 and tried to build a RP-3400, my source ignite image was missing kernel compatability for the PA8700 proc. range, so that's why I wanted to rebuild the target machines with a centrally referenced h/w enablement bundle. I previously found that without adding the h/w enablement bundle to the source server in advance of taking the image, the resulting image was unbootable on the target machine.

I guess Im forced into getting slots for reboots on each node before updating h/w, patches,ignite-ux s/w, and then taking the backup image to later restore on new kit.

Thanks - Ian

[Bill Hassell]

Ignite does an amazing job handling non-similar processors. But when you cross major processor boundaries, the rule is that the source image must have everything needed by the destination, so upward restores from earlier machines is almost always going to have issues. Always download the latest Ignite version, at least every 3-6 months and look at the new option for different hardware backup/restores.