Clarification on Ignite "make_sys_image"

[Jeffrey Davis_1]

Hi again guys. Always good questions here.
So I'll add another one.
We have thought through our disaster recovery plan and have decided that Ignite sounds like the best way to go for us. Here is what I am stuck on however, in understanding the limitations/inclusiveness of Ignite.

I read in the Ignite papers that Ignite will allow you to include any/all application software in your ignite sys-image archive file.

Specifically, is Ignite just creating an archive image of 'only' system configuration information, i.e. lvm, parms, etc., or will it actually allow me to include the actual binaries for my applications, like Oracle, computron, OmniBack, etc.?

This is not a clear point. On the one hand they say that they 'do' allow you to include 'any' application 'anywhere' on your system. But if that is the case my archive images will be relatively large. Not really a problem, since it prevents me from having to do multiple restores to recover my complete system.

My goal is to create a sys-image which includes all OS specific files and config info. and all my third party application software binaries and run files.
The large data areas, like the databases, I can recover by doing restores through OmniBack once OmniBack is laid back out through running my sys-image again.
Your thoughts.

[Frederic Soriano]

Hello Jeffrey,

Let me describe in a few words how we are using one of our Ignite servers here:

My business division is separated into two complementary activities: development and test/validation. On development platforms, we need a set of development softwares such as aCC and debuggers, while on test platforms we need above all bug tracking software. All platforms are running HP-UX 10.20 or 11.X, and can be servers or workstations.

Because we own a lot of them, installing them by hand would be a really painful job, so Ignite was the only way for us to clone quickly specific configurations: starting from a clean system (only OSCore & Extension patches (HWCR, GR, Support and QPK for workstations)), we built a first golden image to get a "basic platform" which is used to create more specific ones.

On development platforms (based on the basic platform), we swinstall'd compilers, debuggers and other third-party products, and saved this config into a final generic golden image (still thanks to make_sys_image). Same for test platforms (with appropriate software). In both cases, a set of post_load scripts are taking care of final configuration (eg. grabbing app rc from a common location, etc.).

In both cases (dev and test), when installing these golden images to target machines, we have exactly the same config, as if we had installed all softwares by hand, with all CDs and tapes. And it's been more than one year now that we are working this way.

You can have a look at the following PDF for a brief explanation of advantages to use make_sys_image (compared to make_recovery):
http://www.software.hp.com/products/IUX/docs/system_recovery_Paper.pdf

I hope this helps.

Best regards.

Fred.

[Mike Rightmire · Accepted solution]

Hey!

OK, as I understand the question, you would like to use Ignite for disaster recovery. THAT makes the question a little different.

As I understand the 'make_sys_image' command it does NOT, by default include everything in the system. It BY DEFAULT creates just an image of the root drive and (with some exceptions) copies of vital directories, regardless of where they are located (I.E. the var directory.) The HP manuals found at ...

http://docs.hp.com/hpux/os/10.x/

... explain some of this better.

HOWEVER, if you are using Ignite for DISASTER RECOVERY (and not to install new machines with an image) the command you want to use uis 'make_net_recovery."

This command allows you to 'image' the system, including or excluding volume groups and directories as you see fit. From the Ignite GUI on the server, you can click Actions, Find New Client for Recovery to find existing machines on the network...and then once they are found, lick Actions, Make Network Recovery to back the system up. It will, during the process ask what volume groups you do/do not want to inclkude...as well as akllowing you to enter explicit directories to inlude/exclude.

From the command line (or script, or crontab) you can run ...

/opt/ignite/bin/make_net_recovery -s Igniteserver.domain.com -a Igniteserver.domain.com/archive/Machinename -x inc_entire=vg00 -x exclude=/dontback

The above is (of course) all one line and the following explains it ...

/opt/ignite/bin/make_net_recovery = is, of course, is the command for make_net_recovery itself.

-s Igniteserver.domain.com = the '-s' option stands for source and references the location of the Ignite server which is managing the backup. Even though the command is running on the machine which is being backed up, an Ignite server must be contacted by the command. Igniteserver.domain.com is the FQDN of the Ignite server. You can use IP addresses as well.

-a Igniteserver.domain.com/archive/Machinename = the directory location to store the Ignite recovery file which is made. The file will be stored on the machine Igniteserver.domain.com, in the directory /archive/Machinename. Although the server and the storage machine location are the same here, they do not have to be. You could use a third file server as the location as long as both machines can NFS to the directory. The final directory /Machinename must belong to bin:bin (using the command 'chown bin:bin Machinename') and be writable by the Ignite server and the machine being backed up.

-x inc_entire=vg00 = an option telling the make_net_recovery command to back up ALL of volume group 'vg00'

-x exclude=/dontback = an option telling the make_net_recovey command NOT to back up the directory '/dontback".

This is how we use Ignite to back up our existing machines (as opposed to using an image to load new machines) and it has saved us a couple of times. The files CAN get pretty large so you need to determine what you REALLY need to include.

When doing a recovery the volumne groups must match the available hard drives on the system. We have machines which run off two local drives and then are attached to a raid 5 array.

The array (knock on wood) is unlikely to have a complete failure, so I just use Ignite to back up the two local drives in case of a failure there, and manage the array separately.

Hope this help!
Mike