Ignite-UX & Bootable Tapes

Greg Fields

Hewlett Packard Company

2025 Larpenteur Ave.

St. Paul, MN 55113

651-603-3111

Fax 651-603-3009

greg_fields@hp.com

Ignite-UX and Bootable Tapes

Contents

Introduction

make_recovery Options

Restore Exceptions

Patches

check_recovery

Using the System Recovery Tape

findholes

Screen Examples

Making vg00 Changes Using the Unsupported Method

Making vg00 Changes Using the Supported Method

Unedited config.recover

Edited config.recover

The Results

Summary

Man Page for make_recovery

Introduction

Have you ever had a drive die in your boot volume group? This usually happens at the worst time! Month end or just before vacation there is never a good time for such a disaster. In the past after your Customer Engineer repaired the drive you had to reinstall the operating system, restore from you back up, worry about changed device files, LVM configuration, etc.. In the middle of the night after the 100^th time you were called and asked when is the system going to be up didn. t you say to yourself . There has got to be a better way!. Well there is now and it is called Ignite-UX. Start using Ignite-UX and make your life less stressful!

Ignite-UX was introduced in April of 1997. Ignite-UX really has two main parts. The first part is to do initial configuration and software installation of HP-UX systems over the network. It replaces the existing HP-UX Install program (also known as Cold Install). A 700 or 800 series system will be designated as the Ignite-UX server. This server will push operating systems images to systems over the network. This is very handy for installing new systems. That. s neat you say but all I want to do is fix my broken root volume group. I don. t want to have to designate a system as a Ignite-UX server. You don. t need to because the second part of Ignite-UX allows any 700 or 800 series 9000 to make a bootable tape to restore the root volume group. This requires the Ignite-UX software to be installed on the system but, it doesn. t require a separate system to be used as a Ignite-UX server. Ignite-UX can then be used to create a system recovery tape. Anyone can do this! For large data centers that don. t want to manage individual tapes for each system the net_recovery can be used to store images back to a system designated as the Ignite-UX server. This paper will focus on how to a make system recovery tape on a individual system using the Ignite-UX command make_recovery and how to restore from the tape.

How do I get Ignite-UX and how much does it cost? Anyone can afford Ignite-UX because it is free! It can be downloaded from the web at:

www.software.hp.com/products/IUX/index.html

It is also on the application CD. s. Ignite-UX works with HP-UX version 10.X and 11.X for series 700 and series 800 systems. Ignite-UX is fully supported by the Response Center.

It is very easy to make a system recovery tape since only one command is needed. The command is:

/opt/ignite/bin/make_recovery

The make_recovery command is fairly simple but, it has many uses! Not only can you restore your broken root volume group but, you can also do the following.

· Convert file systems from HFS to VxFS

· Modify root file system sizes

· Modify primary swap space allocation

· Extend /stand file system

· Clone nearly identical systems

With make_recovery you can create an image of your whole root volume group or you can just make a image of the core operating system. See the attached man page for make_recovery to see what files make up the core operating system. Because the store/restore utility pax is used the image can not be over 2GB so must people will be able to make a image of the whole root volume group. The system recovery tape will consist of three parts.

· Boot or LIF area

· System configuration file as produced by save_config

· Operating system archive

make_recovery options

The follow options are used with make_recovery.

-A Specifies the entire root volume group is be included in the tape

-p Allows you to preview processing that will take place without actually creating

the tape.

-r Allows you to resume creation of the tape after the . p option has been used.

-v Verbose mode that displays progress messages

-d Specifies either a DDS or DLT tape drive where the tape will be created

-b Specifies the temporary area where the LIF volume will be made before it is

stored to the tape. The default directory is /var/tmp/uxinstlf.recover. At least

32 MB is required in this directory or the build of the LIF volume will fail.

-C Creates the status file that check_recovery is run against. (More on this later.)

When the . A option isn. t used only the core operating system is used. There are a couple of files (See attached man page) that can be used with the core to make it more flexible but, we will focus on recovering the whole root volume group. It is important to remember that normally only vg00 will be backed up with make_recovery.

Restore Exceptions

Looks pretty simple doesn. t it? Well it is but, if you are one of those who have put the root volume files outside of vg00 then you will have to be aware of how make_recovery handles that. Ignite-UX requires that the file systems /, /stand, /sbin, /dev, and /etc reside on the root volume group. The file systems /opt, /var, /home, /tmp, and /usr can reside outside of the root volume group. Only /usr is considered part of the core operating system. If make_recovery . A is done and /usr is outside of vg00 the entire volume group that /usr belongs to will also be backed up. If your boot volume group fails vg00 and the volume group that /usr resides in will be restored. Be careful that your tape will not grow over 2 GB in size or make_recovery will not work! What about the other root volume file systems that reside outside of vg00, how much of those get backed up? Only the files that are considered to be part of the core will be backed up. (See attached man page for list) For example, if /opt resides in vg01 then only four files from /opt will be backed up. When the restore tape is used vg01 will not be restored, only vg00. If this tape were used to clone a system /opt will end up with only four files! So remember if root volume file systems reside outside of vg00 the only file system that will be backed up completely in another volume group is /usr and any other file systems in the /usr volume group. All other root file systems outside of the root volume group will only have their core files backed up. Always remember that make_recovery will back up only vg00 unless the previous mentioned /usr situation is in place. Unless /usr is in another volume group make_recovery will never back up other volume groups. It will only back up vg00.

Is there anything else you should be aware of? Yes, if you have used HP-UX LVM mirroring on your root volume file systems Ignite-UX will NOT redo the mirroring after you have recovered your system from the system recover tape. You can manually incorporate the mirroring procedure with make_recovery. See the paper entitled . Ignite-UX and Mirrored Disks. on the Ignite-UX home page. If you don. t incorporate the mirroring procedure into your make_recovery you can simply remirror the logical volumes once your system has reloaded from the system recover tape.

Patches

Do you need anything else on your system before running make_recovery? If you. ve been around UNIX long enough it shouldn. t surprise you that a patch is needed. The pax cumulative patch is needed to allow directory paths longer than 100 characters. It also fixes the problem of files that were hard-linked together not coming back as links after restoring from the system recovery tape. The patches are as follows for Series 700 and 800 servers:

10.01 PHCO_11975

10.10 PHCO_11976

10.20 PHCO_16877

10.30 PHCO_11978

11.X No patch needed

(Be aware that these patches could be superceded in the future.)

check_recovery

How often should you make your tape with make_recovery? This will be a judgement call on your part. If you do not have many changes being made in the root volume files then you probably won. t need to make the tape very often. Is there a way to check the aging of the tape and take some of the guess work out? Of course! The command is:

/opt/ignite/bin/check_recovery

The check_recovery command compares the current state of vg00 to the system recovery status file, /var/opt/ignite/recovery/makrec.last, that was made when make_recovery was done with the . C option. Check_recovery will look for the following discrepancies.

· Additions Files added to vg00 since the last tape was made

· Deletions Files not existing on the current system but, was on the last tape

· Modifications Files existing on the current system but, with a different

modification date then the file on the tape

There are no options to check_recovery but, you must remember to use the . C option when you create the system recovery tape with make_recovery. You could check the aging of your tape every day by running check_recovery in a cron job. If you e-mailed the results of your cron job outside of the system you would then have a record of what has changed. If you use your system recovery tape you will know what has changed since the tape was created. Note! The output of check_recovery doesn. t show you how the file was modified, it only shows you what files were modified.

Using the System Recovery Tape

O.K., you now have been faithfully creating your tape and the big moment finally arrives! You must restore your root volume group! With shaking hands you put your boot tape into your drive, point the boot path to the tape drive, and boot! What do you do now? Nothing!!! Don. t interact with ISL. Don. t do anything but, watch! It. s as simple as that! By letting the system boot from the tape uninterrupted you will eventually have the system at the log in prompt. After you log in you will see all volume groups and file systems back on the system! If you have been running check_recovery and e-mailing the results you can do a quick review to see if anything else needs to be researched.

findholes

If all looks good you have one more step if you are on 10.X. You must run

/opt/ignite/data/scripts/findholes

This is only necessary on 10.X, not 11.00. Why is findholes needed? Because make_recovery uses pax to restore the files from the system recovery tape. Pax attempts to optimize disk space by creating files with . holes. (sparse files) if a file contains a block of nulls. In most cases this doesn. t matter since the files will appear identical except for the disk space reported by the . du. command. However, if the changed file is an executable it can cause the executable to unpredictably die with errors. When findholes is run it will automatically list and fix any sparse files it finds. The time it takes will vary with the speed of the system. A H40 will usually take less than 15 minutes for findholes to complete. Newer systems are quite a bit faster. You can run with sparse files and not use findholes if you have the appropriate patches listed here.

10.01 Series 800 PHKL_17448 plus dependencies

10.10 Series 800 PHKL_11241

10.20 Series 800 PHKL_16751 plus dependencies

10.01 Series 700 PHKL_17447 plus dependencies

10.10 Series 700 PHKL_11240

10.20 Series 700 PHKL_16750 plus dependencies

(Be aware that these patches could be superceded in the future.)

Remember this rule of thumb when rebuilding your root volume group with your system recovery tape.

Do Not Interrupt the Boot in any way!

Follow this rule and you will get all of your volume groups and file systems back. What would happen if you interrupt the boot process of Ignite-UX and went into interactive mode? Only vg00 would be brought back and NO other volume groups would be created. There will also be some other files that will not be brought back. See the attached man page of make_recovery under heading Interactive Mode for the list. That is why it is so important not to interrupt the boot!

Screen Examples

What if you want to do some modifications to your root volume group? Do something like change a file system from HFS to VxFS? You will need to interrupt the Ignite-UX process and go into interactive mode. The following are screens you will see when you go into interactive mode.

Point the boot path to the tape device and begin the boot process. Do not interact with ISL. At the point shown on the next page interrupt the Ignite-UX boot process to go into interactive mode.

Figure 1

Notice that [A1] you have 10 seconds to cancel the automatic batch-mode and go into interactive mode. Note! If Ignite-UX notices significant hardware differences between the system the tape was created on and the system you are restoring to Ignite-UX will automatically bring you into interactive mode and present the user-interface.

Figure 2

This is the first screen you will be presented with. This is the same screen you will see when installing 11.00 from the Install/Core CD. Highlight Install HP-UX and hit return.

Figure 3

Notice here that you want the * to be in the Advanced Installation which gives you the maximum ability to make changes. The Guided Installation is the default which isn. t as flexible as the Advanced Installation. Tab to OK and hit return.

Figure 4

Ignite-UX will give you five tabs. The Basic tab is the first screen shown. Here you can even point the Root disk to another drive. The other sections on this screen should not be changed. Now tab to the next screen.

Figure 5

The Software screen has no fields that should be changed. This is a screen that is used

for the server version of Ignite-UX. Now tab to the System screen.

Figure 6

The System tab has many parameters that can be changed. If you want to change network parameters this would be the screen to make those changes. Now tab to the File System screen.

Figure 7

The File System screen is where HFS file systems can be changed to VxFS. This is also where changes can be made to the sizes of file systems and also to swap. Now tab to the Advanced screen.

Figure 8

The Advanced screen is also another screen where no changes are made. This screen is only used by the Ignite-UX server. If you went to Show Summary near the bottom of the screen you would be presented with the next screen.

Figure 9

The General Summary is a review of the file system types and sizes. This screen can be

reached by selecting Show Summary at the bottom of any of the five tab screens.

Figure 10

The Hardware screen is a review of the hardware configuration. After OK is hit you will be returned to the tab screen that you originally entered the Show Summary from. Once the tab screen is display tab to Go! to continue the boot.

Figure 11

If you already have a root drive installed you will receive this warning. Tab to Go! to continue.

Figure 12

The archive will be extracted from the tape and stored onto the root volume group. Depending on the speed of your system and tape drive the time will vary. K series with a DDS II will take less than a half a hour!

Figure 13

At this point Ignite-UX is done building the kernel. It will now reboot but, this is not the final reboot. Ignite-UX will put the system through two boots with the second boot being the normal boot.

Figure 14

At the point you see large a OK Ignite-UX is done installing the system. It will now do a normal reboot and the system will be up.

When the system is back up you will only have vg00 mounted. Since you interrupted the boot the other volume groups were not built. If you look under /dev you will notice there are no directories for the other volume groups such as vg01, etc. You will now need to import all the other volume groups. Hopefully you have recorded your LVM configuration! A copy of the original fstab will be at:

/var/opt/ignite/recovery/fstab

What a pain it is to import all the volume groups you say to yourself. There must be another way! The makers of Ignite-UX thought about this too. There are two ways to get around the vgimport problem. One way is supported way the other is unsupported.

First we will go over the unsupported way. Be warned! You will be on your own if you go this route. The Response center doesn. t support this method.

Making Changes to vg00 Using the Unsupported Method

The following shows the screens that you will see when go the unsupported way.

Figure 15

Instead of going the normal route of Install HP-UX go to the Advanced Options.

Figure 16

Once you are into the Advanced Options go into Edit (vi) config file.

Figure 17

This is the screen where you can fool Ignite-UX into thinking you didn. t interrupt it. Notice how the two RECOVERY_MODE are different. Since you interrupted Ignite-UX the second RECOVERY_MODE is set FALSE. This means that none of the volume groups will be created except for vg00 and a set of files will not be brought back to as defined in the man page. To fool Ignite-UX into thinking you didn. t interrupt it, set the second RECOVERY_MODE=TRUE. Now all your other volume groups will be created and all your files will also be brought back. But, be forewarned! Since all your files are brought back you have to be VERY careful on how you use this method. Usually it is going to mean coming up in single user mode to change things to match what you altered with Ignite-UX. For example, if you change file systems from HFS to VxFS you will need to alter the /etc/fstab after the system is back up in single user mode. The original /etc/fstab still has the file systems listed as a HFS mount so you will need to vi the /etc/fstab and change the mount options to VxFS, then reboot the system as you normally would.

Making changes to vg00 Using the Supported Method

The unsupported method is not the best route for those not completely confident in their UNIX skills. The supported method is more straight forward and lets Ignite-UX worry about the details. Instead of interrupting Ignite-UX to change options you actually make your changes before the system recovery tape is created. To accomplish this issue the command:

/opt/ignite/bin/make_recovery . A . p

This will create the file

/var/opt/ignite/recovery/config.recover

This is where you will make your changes before the system recovery tape is made. Let. s say we have a system with a /etc/fstab that looks like this.

# System /etc/fstab file. Static information about the file systems

# See fstab(4) and sam(1M) for further details on configuring devices.

/dev/vg00/lvol1 / hfs defaults 0 1

/dev/vg00/lvol3 /home hfs defaults 0 2

/dev/vg00/lvol4 /opt hfs defaults 0 2

/dev/vg00/lvol5 /tmp hfs defaults 0 2

/dev/vg00/lvol6 /usr hfs defaults 0 2

/dev/vg00/lvol7 /var hfs defaults 0 2

/dev/vg01/lvol1 /HPWorld vxfs delaylog 0 2

/dev/vg01/lvol2 /HPWorld1999 vxfs delaylog 0 2

This system is on 10.20 but, you will notice that /stand isn. t broken out and that all of the vg00 file systems are still HFS. This is seen quite often on systems that have been upgraded from 10.01 to 10.20 since /stand wasn. t broken out and VxFS still wasn. t available in 10.01. In this case we wish to break /stand out and make it lvol1, have / be lvol3, and change all file systems to VxFS, except /stand of course. This would be the traditional 10.20 file system layout. To accomplish this use make_recovery with the following options:

/opt/ignite/bin/make_recovery . A . v . p

Since you used the . p option this will create the file

/var/opt/ignite/recovery/config.recover

After it creates this file you will be returned to the HP-UX prompt. The tape will not be created yet since you used the . p option. Now you can edit the config.recover file. This is the unedited version of config.recover.

Unedited config.recover

cfg "HP-UX System Recovery"=TRUE

_hp_saved_detail_level="vfph"

# Variable assignments

init _hp_root_disk="8/4.8.0"

init _hp_root_grp_disks=1

init _hp_root_grp_striped="NO"

init _hp_pri_swap=524288KB

init _hp_disk_layout="HP-UX save_config layout"

# Disk and Filesystems

_hp_disk_layout+={"HP-UX save_config layout"}

(_hp_disk_layout=="HP-UX save_config layout") {

# Disk/Filesystem Layout:

volume_group "vg00" {

max_physical_extents=2200

max_logical_vols=255

max_physical_vols=16

physical_extent_size=4

minor_number=0x00

physical_volume disk[_hp_root_disk] {

} # end pv_options

logical_volume "lvol1" {

usage=HFS

size=204800KB

mount_point="/"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=6329

rotational_delay=0

largefiles=FALSE

bad_block_relocate=false

contiguous_allocation=true

stripes=0

stripe_size=0KB

minor_number=0x01

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol2" {

usage=SWAP_DUMP

size=524288KB

bad_block_relocate=false

contiguous_allocation=true

stripes=0

stripe_size=0KB

minor_number=0x02

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol6" {

usage=HFS

size=339968KB

mount_point="/usr"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=6397

rotational_delay=0

largefiles=FALSE

bad_block_relocate=true

contiguous_allocation=false

stripes=0

stripe_size=0KB

minor_number=0x06

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol4" {

usage=HFS

size=258048KB

mount_point="/opt"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=6381

rotational_delay=0

largefiles=FALSE

bad_block_relocate=true

contiguous_allocation=false

stripes=0

stripe_size=0KB

minor_number=0x04

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol7" {

usage=HFS

size=163840KB

mount_point="/var"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=2157

rotational_delay=0

largefiles=FALSE

bad_block_relocate=true

contiguous_allocation=false

stripes=0

stripe_size=0KB

minor_number=0x07

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol5" {

usage=HFS

size=32768KB

mount_point="/tmp"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=2056

rotational_delay=0

largefiles=FALSE

bad_block_relocate=true

contiguous_allocation=false

stripes=0

stripe_size=0KB

minor_number=0x05

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol3" {

usage=HFS

size=20480KB

mount_point="/home"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=5884

rotational_delay=0

largefiles=FALSE

bad_block_relocate=true

contiguous_allocation=false

stripes=0

stripe_size=0KB

minor_number=0x03

disk[_hp_root_disk]

} # end logical_volume

} # end volume_group "vg00"

} # end "HP-UX save_config layout"

hw_instance_num = 8/4 "ext_bus" 0

hw_instance_num += 8/4.5 "target" 0

hw_instance_num += 8/4.5.0 "disk" 0

hw_instance_num += 8/4.7 "target" 1

hw_instance_num += 8/4.7.0 "ctl" 0

hw_instance_num += 8/4.8 "target" 2

hw_instance_num += 8/4.8.0 "disk" 1

hw_instance_num += 8/16 "ba" 0

hw_instance_num += 8/16/0 "ext_bus" 2

hw_instance_num += 8/16/4 "tty" 0

hw_instance_num += 8/16/5 "ext_bus" 1

hw_instance_num += 8/16/5.0 "target" 3

hw_instance_num += 8/16/5.0.0 "tape" 0

hw_instance_num += 8/16/5.2 "target" 4

hw_instance_num += 8/16/5.2.0 "disk" 2

hw_instance_num += 8/16/5.7 "target" 5

hw_instance_num += 8/16/5.7.0 "ctl" 1

hw_instance_num += 8/16/6 "lan" 0

hw_instance_num += 8/16/7 "ps2" 0

hw_instance_num += 8/20 "ba" 1

hw_instance_num += 8/20/2 "tty" 1

hw_instance_num += 8/20/5 "ba" 2

hw_instance_num += 8/20/5/1 "unknown" -1

hw_instance_num += 32 "processor" 0

hw_instance_num += 34 "processor" 1

hw_instance_num += 49 "memory" 0

release="B.10.20"

# System/Networking Parameters

_hp_custom_sys+={"HP-UX save_config custom sys"}

init _hp_custom_sys="HP-UX save_config custom sys"

_hp_custom_sys visible_if false

(_hp_custom_sys=="HP-UX save_config custom sys") {

final system_name="m26061p"

final ip_addr["8/16/6"]="12.30.43.200"

final netmask["8/16/6"]="0xfffff800"

final broadcast_addr["8/16/6"]="12.30.45.255"

final route_gateway[0]="12.30.40.1"

final route_destination[0]="default"

final dns_domain="msr.hp.com"

final dns_nameserver[0]="12.40.100.102"

is_net_info_temporary=FALSE

} # end "HP-UX save_config custom sys"

RECOVERY_MODE=TRUE

_hp_locale = "SET_NULL_LOCALE"

run_ui=FALSE

env_vars +="INST_ALLOW_WARNINGS=10"

sw_source "recovery"{

source_type="MT"

source_format=archive

load_order=0

post_load_script="/opt/ignite/data/scripts/os_arch_post_l"

post_config_script="/opt/ignite/data/scripts/os_arch_post_c"

}

sw_sel "recovery_tape"{

description = "Recovery Archive"

sw_category = "HPUXEnvironments"

sw_source="recovery"

archive_path="1"

archive_type=tar

} = TRUE

sw_source "no select"{

source_format = cmd

}

sw_sel "English" {

description = "English Language Environment"

sw_source = "no select"

sw_category = "Languages"

locale = { "SET_NULL_LOCALE:English", "C:English" }

} = TRUE

post_load_cmd="

if [[ -f /tmp/install.vars ]]; then . /tmp/install.vars; fi

if [[ $RECOVERY_MODE = TRUE ]]; then

cp /stand/vmunix /var/vmunix.makrec &&

cp /var/vmunix.makrec /stand/vmunix

rm -f /var/vmunix.makrec

final_cmd="

if [[ -f /tmp/install.vars ]]; then . /tmp/install.vars; fi

if [[ -a /var/tmp/remove ]]; then rm /var/tmp/remove; fi

if [[ -d /var/tmp/removedir ]]; then rm -rf /var/tmp/removedir; fi

/usr/sbin/vgimport -v -m /etc/lvmconf/vg01.mapfile /dev/vg01 \

/dev/dsk/c0t5d0

/usr/sbin/vgchange -a y /dev/vg01

/usr/sbin/vgcfgbackup /dev/vg01

/usr/sbin/vgcfgbackup /dev/vg00

Take notice the print in bold. You will see that each lvol has it. s own section. Pay close attention to the following parts.

· The usage of each lovl, except swap, is set to HFS

· The size of each lvol is in KB, not MB. To find the size in MB take 1024 x # MB to reach the size in KB. Don. t forget to make the conversion!

· The minor number of each lvol matches the lvol number. For example lvol3 has a minor number of 0x03

We want to do the following to our system.

· Make lvol1 /stand with a size of 90 MB

· Make lvol3 / with it. s original size of 200 MB

· Change all file systems to VxFS except /stand which must be HFS

Since lvol3 is already assigned to /home we must change /home to a new lvol number. Since 8 isn. t being used let. s make /home lvol8. This also means we must change the minor number of /home to 0x08.

Next we will change lvol1 to be /stand with a size of 90 MB. Then will insert a lvol3 and assign it to / with a minor number of 0x03 and a size of 200 MB. Finally we will make the appropriate file systems VxFS instead of HFS. You can use

/opt/ignite/bin/instl_adm . T . f config.recover

to check the syntax.

Here is what the edited config.recover file will look like.

Edited config.recover

cfg "HP-UX System Recovery"=TRUE

_hp_saved_detail_level="vfph"

# Variable assignments

init _hp_root_disk="8/4.8.0"

init _hp_root_grp_disks=1

init _hp_root_grp_striped="NO"

init _hp_pri_swap=524288KB

init _hp_disk_layout="HP-UX save_config layout"

# Disk and Filesystems

_hp_disk_layout+={"HP-UX save_config layout"}

(_hp_disk_layout=="HP-UX save_config layout") {

# Disk/Filesystem Layout:

volume_group "vg00" {

max_physical_extents=2200

max_logical_vols=255

max_physical_vols=16

physical_extent_size=4

minor_number=0x00

physical_volume disk[_hp_root_disk] {

} # end pv_options

logical_volume "lvol1" {

usage=HFS File system type unchanged

size=92160KB Size changed to 90 MB

mount_point="/stand" lvol 1 now set to /stand

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=6329

rotational_delay=0

largefiles=FALSE

bad_block_relocate=false

contiguous_allocation=true

stripes=0

stripe_size=0KB

minor_number=0x01

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol2" {

usage=SWAP_DUMP

size=524288KB

bad_block_relocate=false

contiguous_allocation=true

stripes=0

stripe_size=0KB

minor_number=0x02

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol3" { lvol 3 is changed to /

usage=VxFS Changed to VxFS

size=204800KB Size of 200 MB

mount_point="/"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=6329

rotational_delay=0

largefiles=FALSE

bad_block_relocate=false

contiguous_allocation=true

stripes=0

stripe_size=0KB

minor_number=0x03

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol6" {

usage=VxFS Changed to VxFS

size=339968KB

mount_point="/usr"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=6397

rotational_delay=0

largefiles=FALSE

bad_block_relocate=true

contiguous_allocation=false

stripes=0

stripe_size=0KB

minor_number=0x06

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol4" {

usage=VxFS Changed to VxFS

size=258048KB

mount_point="/opt"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=6381

rotational_delay=0

largefiles=FALSE

bad_block_relocate=true

contiguous_allocation=false

stripes=0

stripe_size=0KB

minor_number=0x04

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol7" {

usage=VxFS Changed to VxFS

size=163840KB

mount_point="/var"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=2157

rotational_delay=0

largefiles=FALSE

bad_block_relocate=true

contiguous_allocation=false

stripes=0

stripe_size=0KB

minor_number=0x07

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol5" {

usage=VxFS Changed to VxFS

size=32768KB

mount_point="/tmp"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=2056

rotational_delay=0

largefiles=FALSE

bad_block_relocate=true

contiguous_allocation=false

stripes=0

stripe_size=0KB

minor_number=0x05

disk[_hp_root_disk]

} # end logical_volume

logical_volume "lvol8" { /home is changed to lvol 8

usage=VxFS Changed to VxFS

size=20480KB

mount_point="/home"

minfree=10

file_length=LONG

blksize=8192

fragsize=1024

ncpg=16

nbpi=5884

rotational_delay=0

largefiles=FALSE

bad_block_relocate=true

contiguous_allocation=false

stripes=0

stripe_size=0KB

minor_number=0x08 minor number is 8 match lvol 8

disk[_hp_root_disk]

} # end logical_volume

} # end volume_group "vg00"

} # end "HP-UX save_config layout"

hw_instance_num = 8/4 "ext_bus" 0

hw_instance_num += 8/4.5 "target" 0

hw_instance_num += 8/4.5.0 "disk" 0

hw_instance_num += 8/4.7 "target" 1

hw_instance_num += 8/4.7.0 "ctl" 0

hw_instance_num += 8/4.8 "target" 2

hw_instance_num += 8/4.8.0 "disk" 1

hw_instance_num += 8/16 "ba" 0

hw_instance_num += 8/16/0 "ext_bus" 2

hw_instance_num += 8/16/4 "tty" 0

hw_instance_num += 8/16/5 "ext_bus" 1

hw_instance_num += 8/16/5.0 "target" 3

hw_instance_num += 8/16/5.0.0 "tape" 0

hw_instance_num += 8/16/5.2 "target" 4

hw_instance_num += 8/16/5.2.0 "disk" 2

hw_instance_num += 8/16/5.7 "target" 5

hw_instance_num += 8/16/5.7.0 "ctl" 1

hw_instance_num += 8/16/6 "lan" 0

hw_instance_num += 8/16/7 "ps2" 0

hw_instance_num += 8/20 "ba" 1

hw_instance_num += 8/20/2 "tty" 1

hw_instance_num += 8/20/5 "ba" 2

hw_instance_num += 8/20/5/1 "unknown" -1

hw_instance_num += 32 "processor" 0

hw_instance_num += 34 "processor" 1

hw_instance_num += 49 "memory" 0

release="B.10.20"

# System/Networking Parameters

_hp_custom_sys+={"HP-UX save_config custom sys"}

init _hp_custom_sys="HP-UX save_config custom sys"

_hp_custom_sys visible_if false

(_hp_custom_sys=="HP-UX save_config custom sys") {

final system_name="m2606jp"

final ip_addr["8/16/6"]="12.30.43.185"

final netmask["8/16/6"]="0xfffff800"

final broadcast_addr["8/16/6"]="12.30.45.255"

final route_gateway[0]="12.30.40.1"

final route_destination[0]="default"

final dns_domain="msr.hp.com"

final dns_nameserver[0]="12.40.100.102"

is_net_info_temporary=FALSE

} # end "HP-UX save_config custom sys"

RECOVERY_MODE=TRUE

_hp_locale = "SET_NULL_LOCALE"

run_ui=FALSE

env_vars +="INST_ALLOW_WARNINGS=10"

sw_source "recovery"{

source_type="MT"

source_format=archive

load_order=0

post_load_script="/opt/ignite/data/scripts/os_arch_post_l"

post_config_script="/opt/ignite/data/scripts/os_arch_post_c"

}

sw_sel "recovery_tape"{

description = "Recovery Archive"

sw_category = "HPUXEnvironments"

sw_source="recovery"

archive_path="1"

archive_type=tar

} = TRUE

sw_source "no select"{

source_format = cmd

}

sw_sel "English" {

description = "English Language Environment"

sw_source = "no select"

sw_category = "Languages"

locale = { "SET_NULL_LOCALE:English", "C:English" }

} = TRUE

post_load_cmd="

if [[ -f /tmp/install.vars ]]; then . /tmp/install.vars; fi

if [[ $RECOVERY_MODE = TRUE ]]; then

cp /stand/vmunix /var/vmunix.makrec &&

cp /var/vmunix.makrec /stand/vmunix

rm -f /var/vmunix.makrec

final_cmd="

if [[ -f /tmp/install.vars ]]; then . /tmp/install.vars; fi

if [[ -a /var/tmp/remove ]]; then rm /var/tmp/remove; fi

if [[ -d /var/tmp/removedir ]]; then rm -rf /var/tmp/removedir; fi

/usr/sbin/vgimport -v -m /etc/lvmconf/vg01.mapfile /dev/vg01 \

/dev/dsk/c0t5d0

/usr/sbin/vgchange -a y /dev/vg01

/usr/sbin/vgcfgbackup /dev/vg01

/usr/sbin/vgcfgbackup /dev/vg00

After you are done editing the config.recover file start the creation of your system recovery tape with

/opt/ignite/bin/make_recovery . r . v

The Results

The tape will now be created with the configuration you just specified in the config.recover file. When the system is back up this is what your /etc/fstab file will look like.

# System /etc/fstab file. Static information about the file systems

# See fstab(4) and sam(1M) for further details on configuring devices.

/dev/vg00/lvol3 / vxfs delaylog 0 1

/dev/vg00/lvol1 /stand hfs defaults 0 1

/dev/vg00/lvol4 /opt vxfs delaylog 0 2

/dev/vg00/lvol5 /tmp vxfs delaylog 0 2

/dev/vg00/lvol6 /usr vxfs delaylog 0 2

/dev/vg00/lvol7 /var vxfs delaylog 0 2

/dev/vg00/lvol8 /home vxfs delaylog 0 2

#/dev/vg00/lvol1 / hfs defaults 0 1

#/dev/vg00/lvol3 /home hfs defaults 0 2

/dev/vg01/lvol1 /HPWorld vxfs delaylog 0 2

/dev/vg01/lvol2 /HPWorld1999 vxfs delaylog 0 2

Compare this to the original /etc/fstab before the system was recovered with the system recovery tape.

# System /etc/fstab file. Static information about the file systems

# See fstab(4) and sam(1M) for further details on configuring devices.

/dev/vg00/lvol1 / hfs defaults 0 1

/dev/vg00/lvol3 /home hfs defaults 0 2

/dev/vg00/lvol4 /opt hfs defaults 0 2

/dev/vg00/lvol5 /tmp hfs defaults 0 2

/dev/vg00/lvol6 /usr hfs defaults 0 2

/dev/vg00/lvol7 /var hfs defaults 0 2

/dev/vg01/lvol1 /HPWorld vxfs delaylog 0 2

/dev/vg01/lvol2 /HPWorld1999 vxfs delaylog 0 2

Notice we now have /stand as it. s own lvol. /home has changed to lvol8, / is now lvol3, and the appropriate file systems are now VxFS. Notice how Ignite-UX even comments out the original lvols for / and /home. And also take note that the other volume group vg01 is still configured in the system. So, as you can see all of our changes were made and we lost no files. This Ignite-UX is a clever program!

Summary

Using Ignite-UX can make the life of any system administrator less stressful! As you have seen a system can be recovered using the system recovery tape created by make_recovery. You can also modify the layout of vg00 with Ignite-UX. This paper only covered the make_recovery aspect of Ignite-UX. Imagine how many more things you could do when you are using a Ignite-UX server in your environment! Ignite-UX was engineered and is regularly being updated with new functionality by a team of Hewlett Packard engineers in Fort Collins, Colorado. Thanks to this team there will be less time spent recovering and loading systems!

Man Page for make_recovery for Ignite-UX Version 1.59

make_recovery(1M)

NAME

make_recovery - creates a System Recovery Tape

SYNOPSIS

/opt/ignite/bin/make_recovery [-AprvC] [-d destination]

[-b boot_destination_file]

DESCRIPTION

make_recovery creates a bootable system recovery tape for an LVM or

whole disk system while it is up and running. When a system has a

logical volume layout, the recovery tape will only include data from

the root volume group, plus data from any Non-root volume group

containing /usr. make_recovery is capable of creating system recovery

tapes for all DDS tape devices, with the ability to span multiple

tapes. For some systems, DLT tape devices can be used to create

system recovery tapes (See DEPENDENCIES). Root-user privileges are

required to execute make_recovery.

Data which is not in the root volume group is expected to be backed up

and recovered using normal backup utilities.

The recovery tape can be used to:

restore a non-bootable system with little or no user

intervention.

restore a system in the event of a hardware failure of the root

disk or volume group when a disk has to be replaced or gets

corrupted.

Clone software from one system to another when systems are nearly

identical. Most system having nearly identical architectural

characteristics are within the same class (example: K Class HP-UX

systems). In many cases, make_sys_image and make_medialif may be

more suitable tools for cloning systems. See WARNINGS section

for more info.

Convert from HFS to VxFS file systems.

Modify root file system size.

Modify primary swap space allocation.

make_recovery makes use of the installation technology provided by the

Ignite-UX product, and can be considered a "customized" installation

media. A system can be recovered by booting and installing from the

tape without user intervention. All information regarding disk

configuration, software, and system identity is stored on the tape at

the time that make_recovery is executed.

The System Recovery tape consists of three parts:

- A Boot Image (made by make_medialif)

- System Configuration File (produced by save_config)

- OS archive

The contents of the archive portion of the tape depends on which

command options are provided. The archive portion of the recovery

tape can be classified as:

Core-OS only:

Core-OS consists of:

/.profile, /.rhosts,

/dev, /etc, /sbin,

/usr/bin, /usr/sbin,

/usr/lib, /usr/obam,

/usr/sam, /usr/share,

/usr/ccs, /usr/conf,

/usr/lbin, /usr/contrib,

/usr/local, /usr/newconfig

/var/adm/sw/security, /var/opt/ignite/local/manifest,

/var/adm/sw/products, /var/adm/sw/save,

/var/adm/sw/sessions/swconfig.last,

/var/adm/sw/sessions/swmodify.last,

/var/adm/sw/sessions/swlist.last,

/var/adm/sw/swconfig.log,

/var/adm/sw/getdate.templ,

/var/adm/sw/defaults.patchfilters,

/var/adm/sw/ui/preferences, /var/adm/sw/targets,

/var/adm/sw/software, /var/adm/sbtab,

/var/opt/ignite/recovery,

/var/adm/cron, /var/spool/cron,

/sbin, /dev, /stand,

/opt/ignite/bin/print_manifest,

/opt/ignite/share/man/man1m.Z/print_manifest.1m,

/opt/upgrade, /opt/dce

Generated by: make_recovery

Core-OS and all Non-Core data on both the root and Non-root volume

groups:

When there is a root volume group and a non-root volume group,

the recovery archive will include all data from both volume

groups if /usr is contained within the Non-root volume group.

Generated by: make_recovery -A

Core-OS and all Non-Core data on the root volume group:

Non-core data are any files or Non-Core file systems containing

files outside the minimum Core-OS. It is highly likely that the

root volume group will contain Non-Core files and/or filesets.

When this is the case all data under the root volume group can be

archived.

Generated by: make_recovery -A

Core-OS and some Non-core data on the root volume group:

There are some cases where it may be feasible to archive the

minimum Core-OS, then add some files to the archive without

capturing the entire root volume group. This may be feasible

when only some Non-core data is desired to be included on the

recovery tape, but not all of it.

Generated by:

Editing the /var/opt/ignite/recovery/makrec.append file before

invoking make_recovery.

Core-OS and some Non-core data on a Non-core volume group:

It is possible to include data from a Non-Root volume group This

is useful when there is a need to archive filesystem data such as

OmniBack which typically reside in /opt. This fits the model

where there is a need to restore the minimum Core-OS, then pull

in an application that will restore backups in their entirety on

the root and/or Non-Root volume groups. This is only possible

for /var and /opt filesystems when they exist on a Non-Root

volume group. When /usr is on the Non-Root volume group, any

file, dir, or product on that volume group can be included in the

archive.

Generated by:

Editing the /var/opt/ignite/recovery/makrec.append file before

invoking make_recovery.

Handling filesystem data on Non-root volume groups:

Ignite-UX requires that: /, /stand, /sbin, /dev, and /etc reside

on the root disk/volume group.

Ignite-UX allows the following to be outside the root volume

group:

/opt, /var, /home, /tmp and /usr.

Considering the filesystems that can be moved outside the root

volume group, only /usr is cosidered part of the Core-OS.

Therefore, if an attempt is made to archive the entire system,

and /usr is contained on a Non-root volume group, that entire

volume group will be included in the recovery archive.

/var and /opt are considered Non-Core OS, because many Non-Core

applications reside in these locations.

Example Scenario #1:

Filesystem kbytes used avail %used Mounted on

/dev/vg01/osdepot 2621440 2530838 84872 97% /osdepot

/dev/vg01/lvol1 480341 58696 373610 14% /var

/dev/vg01/lvol7 378965 297521 43547 87% /usr

/dev/vg01/lvol6 588643 245540 284238 46% /opt

/dev/vg00/lvol3 107669 38577 58325 40% /

/dev/vg00/lvol1 67733 12409 48550 20% /stand

/dev/vg00/lvol4 30597 19 27518 0% /tmp

/dev/vg00/lvol5 19861 1416 16458 8% /home

Consider the example scenario #1

The volume group vg01 contains:

/var, /opt and /usr

The volume group vg00 contains:

/, /stand, /tmp and /home

If make_recovery (with no options) is invoked, the archive will

include:

from vg00: /stand, /sbin, /dev, /etc, /tmp, /home

from vg01: parts of /opt and /var (see Core-OS list)

/usr/bin, /usr/lib

/usr/obam, /usr/sam,

/usr/share, /usr/ccs,

/usr/conf, /usr/lbin,

/usr/contrib, /usr/local,

/usr/newconfig

If make_recovery -A is invoked, the archive will include:

from vg00: Everything under the root volume group.

from vg01: Everything on the non-root voume group.

Everything contained within /osdepot will be

included in the recovery archive.

Since /usr is part of the core, and resides on vg01, the

entire vg01 will be included in the archive.

Example Scenario #2:

Filesystem kbytes used avail %used Mounted on

/dev/vg01/osdepot 2621440 2530838 84872 97% /osdepot

/dev/vg01/lvol1 480341 58696 373610 14% /var

/dev/vg01/lvol6 588643 245540 284238 46% /opt

/dev/vg00/lvol7 378965 297521 43547 87% /usr

/dev/vg00/lvol3 107669 38577 58325 40% /

/dev/vg00/lvol1 67733 12409 48550 20% /stand

/dev/vg00/lvol4 30597 19 27518 0% /tmp

/dev/vg00/lvol5 19861 1416 16458 8% /home

Consider example scenario #2

The volume group vg01 contains:

/var and /opt

The volume group vg00 contains:

/, /stand, /tmp, /home, /usr

If make_recovery is invoked, the archive will include:

from vg00: /stand, /sbin, /dev, /etc, /tmp, /home

from vg01: parts of /var and /opt (See Core-OS list)

If make_recovery -A is invoked, the archive will include:

from vg00: /stand, /sbin, /dev, /usr

from vg01: Core portions of /var and /opt. Contents of /osdepot

will not be contained in the archive.

Customizing the recovery tape:

make_recovery also provides a mechanism for the user to exclude

selected files from the archive via the -p and -r options. When

excluding files, extreme caution should be taken considering that

exclusion of important files could produce a system that is

unbootable. make_recovery does not perform any checks to determine

whether or not files being excluded are crucial in the boot process.

The /var/opt/ignite/recovery/makrec.append file is provided for the

user to append selected data files to the archive. This has the

format:

** User Core OS **

file: filename

dir: dirname

product: productname

** User Data **

file: filename

file: filename

product: productname

dir: dirname

The headers ** User Core OS ** and ** User Data ** are fixed form.

The file, product, dir keywords indicate that portions of the OS can

be appended on a per file, directory, or productname bases. Files,

products names and/or directories included under ** User CORE OS **

are included in /var/opt/ignite/recovery/makrec.last, while file,

product, dir contained under the ** User Data ** portion are not

appended to /var/opt/ignite/recovery/makrec.last. The

/var/opt/ignite/recovery/makrec.last file is used by check_recovery.

Adding files/directories to the ** User Core OS ** section will

increase the amount of time required for both tape generation and

check_recovery execution.

The product tag is provided to allow a user to append a backup utility

to the System Recovery tape. This is limited to utilities that have

been installed using SD (Software Distributor), and follow the SD

guidelines.

Lines starting with "#" are treated as comments and ignored. Blank

lines are also ignored.

Re-Creating Recovery Tapes:

The System Recovery tape is only as good as the last time it was

created. The tape should be recreated if the software, hardware,

patches, etc. on the system are changed. The check_recovery command

can be used to determine if the system has changed enough that the

tape needs to be recreated.

Using The Recovery Tape to Boot

To recover a failed system disk or volume group, the user would

- Insert the System Recovery tape into the tape drive

- boot the system

- interrupt the boot sequence to redirect it to the tape drive

- elect no intervention with ISL

- allow the install process to complete automatically.

Using The Recovery Tape to Clone

To clone a system disk or volume group, the user would

- Insert the System Recovery tape into the tape drive

- boot the system

- interrupt the boot sequence to redirect it to the tape drive

- Cancel the non-interactive installation by hitting the return

key when the following messages are displayed:

WARNING: The configuration information calls for a non-

interactive installation.

Press <Return> within 10 seconds to cancel batch-mode

installation:

- The "Ignite-UX Welcome" screen will be presented.

As a "customized" installation is being performed, select the

option

[ Install HP-UX ]

and then the option

[ ] Advanced Installation

Then configure/change disks, file systems, hostname, IP address,

timezone, root password, DNS server, and gateway information.

These can also be configured by using /sbin/set_parms after the

system has been finally re-booted.

- allow the install process to complete.

The system recovery tape can be used to clone the software on a system

on to another system, with manual configuration to be performed by the

user during the interactive installation. Cloning should only be

considered when the hardware of the systems are nearly identical.

Extracting files from tape

After the system recovery tape has been created, a single file or

files can be extracted from tape by seeking to the tape position where

the archive is located. The mt command can be used to seek to the

appropriate location, and pax or tar can be used to extract files from

the archive.

To extract a single file from the recovery archive:

mt -t /dev/rmt/0mn fsf 1

tar -xvf /dev/rmt/0m filename

Extracting files from tape can take a long time, especially when

archives are large.

Options

make_recovery recognizes the following options:

Each option requires superuser privilege. Progress and errors are

logged to /var/opt/ignite/logs/makrec.log1.

-A Specifies that the entire root disk/volume group

is to be included in the System Recovery tape.

This creates a complete bootable backup of the

disk or volume group.

In the case of large root disks or volume groups,

or when other utilities are used for normal

backups, this option should not be used. Instead,

the default minimum core OS should be backed up,

to recover a minimum system, and then the full

recovery should be done from the backups.

-p Previews what processing would take place, without

actually creating the tape. This is a way of

verifying /var/opt/ignite/recovery/makrec.append,

and getting /var/opt/ignite/recovery/arch.include

created. The latter file determines what goes into

the archive. This file can be edited to exclude

some files/directories from the archive if desired

by deleting them from the file. Only files or

directories that are known to be user created

should be deleted. The -p option can also be used

to modify the

/var/opt/ignite/recovery/config.recover file, to

add final commands or change basic configurations

like converting from HFS to JFS. No further

checks are done by make_recovery. The creation of

the System Recovery tape can then be resumed using

the -r option.

-r Resumes creation of the System Recovery tape after

the -p option has been used to create

/var/opt/ignite/recovery/arch.include, and it has

been possibly edited. The -r option also resumes

creation of the recovery tape after the

/var/opt/ignite/recovery/config.recover file has

been edited. If the -A and -r options are both

used, the -A option will override the -r option,

and the entire root disk/volume group will be

backed up.

-v Specifies verbose mode that displays progress

messages.

-d destination Specifies the device file of a DDS or DLT tape

drive where the System Recovery Tape is to be

created. A no-rewind device file is required. The

default is /dev/rmt/0mn.

-b boot_destination_file

Specifies the temporary location where the LIF

volume will be assembled before it is written to

tape. The default directory is

/var/tmp/uxinstlf.recovery. At least 32 Mb is

required in the directory where the LIF volume

will be assembled. The LIF volume and other

temporary files required by make_medialif(1M) will

be assembled in the directory specified and then

removed after the recovery process completes.

-C Create the System status file

/var/opt/ignite/recovery/makrec.last. This file

reflects the current state of the system. It

contains the names, dates of last modification,

and checksums of all the files on the tape that

are considered "Core OS" files. It may also

contain the file information for the user files

specified in the

/var/opt/ignite/recovery/makrec.append file if the

file exists. This option would be used if the user

plans to use check_recovery to determine if the

system has been changed such that the System

Recovery tape needs to be recreated.

EXAMPLES

To create a Core-OS System Recovery tape at /dev/rmt/0mn. This tape

includes only the minimum OS required to boot the system. A system

recovery from this tape would mean booting from the tape to recover

the minimum Core OS, and then following up with a user data recovery

from normal backup media.

make_recovery

To create a Minimum OS System Recovery tape at /dev/rmt/c0t1d1BESTn

(assuming a writable DDS tape is in the drive pointed to by

/dev/rmt/c0t1d1BESTn.) User data recovery is done as described above.

make_recovery -d /dev/rmt/c0t1d1BESTn

To preview the creation of a System Recovery tape at

/dev/rmt/c0t1d1BESTn (assuming a writable DDS tape is in the drive

pointed to by /dev/rmt/c0t1d1BESTn), review the list of files that

will be included in the archive, possibly modify the list, and then

subsequently continue the creation.

make_recovery -p -d /dev/rmt/c0t1d1BESTn

vi /var/opt/ignite/arch.include

make_recovery -r -d /dev/rmt/c0t1d1BESTn

To create a System Recovery tape, at the default device /dev/rmt/0mn,

and include the entire root disk in the archive.

make_recovery -A

To create a System Recovery tape that

- includes the entire root file system in the disk,

- adds the file /mnt/fileA as a users system file,

- adds the data directory /mnt/dirB to the archive as non-system

data. (assuming that /mnt is mounted on the same volume group as

the core File Systems),

- creates the system status file.

Edit the /var/opt/ignite/recovery/makrec.append file to include:

** User Core OS **

file: /mnt/fileA

** User Data **

dir: /mnt/dirB

Then issue the command:

make_recovery -v -C

To clone a system, create the System Recovery tape.

make_recovery -v -A

Install it on the new system. Invoke the user interface by hitting any

key during the 10 second interval given for this purpose during the

installation. Configure the hostname, IP address, root password etc.

using the "system" screen of the user interface.

The installation can be non-interactive if the systems have identical

hardware configurations. When this is the case, the hostname and IP

addresses should be changed.

If the system is installed non-interactively, immediately run

/sbin/set_parms to configure the new hostname, IP address etc for the

system. This method is not recommended. (See WARNINGS).

If the disk drive and/or hardware paths to be configured are not the

same as that of the original system, the normal user interface for

installation will be presented, and the user has the opportunity to

provide the configuration information via the "system" and

"filesystem" installation configuration screen.

WARNINGS

Importing Volume Groups

Logical volumes which are unmounted will not be imported using

vgimport by make_recovery. Unmounted volume groups must be imported by

the user after recovery completes.

Interactive Mode

When a user interrupts the automatic installation, or is forced into

interactive mode because of differences in hardware or networking

configurations, recovery mode is set to false. When this happens the

following files are modified by the installation process, and the

original files become altered. See

/opt/ignite/data/scripts/os_arch_post_l and

/opt/ignite/data/scripts/os_arch_post_c.

Following is the list of files that are changed when a user performs

interactive installations using the make_recovery tape:

/etc/fstab, /etc/hosts, /etc/resolv.conf, /etc/rc.config.d/netconf,

/etc/rc.config.d/namesvrs,

/etc/ioconfig, /stand/ioconfig, /etc/eisa/system.sci,

/var/adm/sw/security/_ACL, /var/adm/sw/security/_OWNER,

/var/adm/sw/security/_PROD_DFLT_ACL,

/var/adm/sw/security/_SOC_DFLT_ACL,

/var/adm/sw/security/secrets, /var/adm/sw/defaults,

/var/opt/ignite/local/manifest/manifest,

/var/opt/ignite/local/manifest/manifest.info,

/var/opt/ignite/local/manifest/manifest.oinfo,

/var/opt/ignite/local/manifest/manifest.orig,

/var/opt/ignite/local/manifest/manifest.seed,

/opt/ignite/bin/print_manifest,

/opt/ignite/share/man/man1m.Z/print_manifest.1m

These files/directories are removed:

/var/adm/crash, /etc/dhcpclient.data

Installed Products Database

make_recovery relies on the Installed Products Database (IPD) to

extract files relevant to a product added to the System Recovery tape

via the "product" tag in the append file. It is only as reliable as

the IPD. Only products installed via SD (Software Distributor) are

logged into the IPD. It is also necessary that the SD commands be

used to add, modify, remove these products, so that the IPD is

correctly updated to reflect these changes. If there is any

possibility that the product has been manipulated without using SD, or

that the products' installation/configuration scripts are not

modifying the IPD reliably, then it is better to set up

/var/opt/ignite/recovery/makrec.append with all the filenames for the

product as a one time effort.

Cloning

The primary purpose of make_recovery is to create a system recovery

tape, which is used to later restore that same system back to its

previous state. make_recovery is not a generic cloning tool. It can

be used to clone only systems with similar characteristics, such as

kernel, drivers and i/o devices. When cloning is the objective,

make_recovery isn't always the ideal tool, since the OS archives are

specific to the machine the tape was created on. The cloning

capabilities of make_recovery have only been tested only for systems

within the same class. To create generic archives to be used across a

wider range of systems, make_sys_image and make_medialif should be

used.

If the System Recovery tape is used to clone the software on another

system, the newly installed system will have the same hostname and IP

address as the original system. These should be immediately changed

using /etc/set_parms. Introducing a second system into the network

with the same hostname or IP address will cause networking problems.

Excluding Files From Archive

The -p and -r options can be used to exclude some NON-OS

files/directories from the System Recovery archive. These should only

be used by knowledgeable System Administrators as excluding required

files/directories from the boot tape could render it useless.

make_recovery does survey the files attempting to be excluding to

determine whether these files are crucial to the boot process.

Exclusion of important files could cause the system to be un-bootable,

which renders the recovery tape useless.

Large UID/GIDs and Large Files:

On systems that support Large UID/GIDs or Large Files (>2GB), the

System Recovery tape should be created for only the Minimum OS, and

remaining user data recovered from Normal Backup Media that support

these features. make_recovery does not directly support these

features since pax (used to generate the archive) does not support

DDS Tape Devices

make_recovery creates recovery tapes for all DDS tape devices. This

includes DDS1, DDS2, and DDS3. If the recovery tape will be used on a

system other then the one it was created on, that system should have

the same kind of DDS drive. It is safe to use a DDS3 tape device if

the tape will only be used to recover that system or others with DDS3

tape devices. To maximize performance, DDS3 devices must be used

along with DDS3 tapes. When portable tapes are needed, it is best to

use mksf to create DDS1 device files, so that the tape can be used on

any DDS device.

NOT SUPPORTED

The make_recovery tool will create a recovery tape for a system with

mirrored disks but it will not preserve the mirrored disk

configurations. Using make_recovery -p allows appending commands to

restore mirrored disk to be executed automatically after the system

has been restored.

NOTES

If a Non-Root disk is corrupted, it should be recovered from normal

backups.

/usr is always recreated during the installion process. Therefore,

any volume group which containes /usr will be included in the recovery

archive.

If /opt and /var are mounted on the root volume group, these can

either be included in the System Recovery archive, or recovered from

normal backups after the system is brought up.

/opt and /var tend to grow large, and are occasionally mounted on a

separate disk or in a Non-Root volume group. In such cases, it is

essential that the user data on these disks should not be "wiped out"

during the process of reinstalling the root disk/volume group. Some

files from these file systems are required for Ignite-UX processing

and make_recovery would automatically include them in the archive.

Other files from these file systems can be included in the archive for

cloning purposes, but if the same system is being recovered, the files

will not be restored onto these file systems. These file systems will

be left unaltered.

If the disks on the system have been changed, the install process can

detect that the hardware is different, and starts up the install user

interface to allow changes to the configuration. If the hardware

configuration is the same, the installation can complete non-

interactively.

The user can also elect to invoke the user interface by hitting any

key during the 10 second interval given for this purpose during the

installation. The user can then make configuration choices, but the

archives will be recovered in a manner similar to a cold install. The

software, data files and so forth will be recovered, but the user will

manually complete the configuration of hostname, IP address, DNS

server, date and time, root password. The /etc/fstab and /etc/hosts

files will have to be re-created. A copy of the original /etc/fstab

file is saved in /var/opt/ignite/recovery/fstab for reference.

All of the above files/directories are included in the archive as

default.

DEPENDENCIES

make_recovery requires that the following filesets of the Ignite-UX

product be installed on the system.

Ignite-UX.BOOT-KERNEL

Ignite-UX.BOOT-SERVICES

Ignite-UX.FILE-SRV-release

Ignite-UX.MGMT-TOOLS

Ignite-UX.IGNT-ENG-A-MAN

For 10.x systems, the current patch for pax that fixes problems with

hardlinks is required.

V-Class systems require the appropriate firware upgrade. Contact your

local HP representative about firmware upgrades.

DLT boot support works for systems that use the HSC SCSI cards. K and

D class systems that utilize the HSC bus will boot from DLT. V-Class

systems that use the PCI bus will boot from DLT. T,E,G, and H class

systems do not boot from DLT devices.

FILES

/var/opt/ignite/recovery/makrec.append

User created file for appending

files/directories/products to the System Recovery

archive.

/var/opt/ignite/local/install.log

Installation Log reporting results of installation

from tape media. When a recovering from tape, the

results from the actual installation are captured

in this log file.

/var/opt/ignite/logs/makrec.log1

Progress and error log.

/var/opt/ignite/logs/makrec.log2

Archive content log.

/var/opt/ignite/recovery/makrec.last

System status file created with the -C option.

This file will be used by check_recovery for

system validation.

/var/opt/ignite/recovery/arch.include

List of files to be included in the System

Recovery archive.

/var/opt/ignite/recovery/chkrec.include

List of files that will be validated by

check_recovery.

/var/opt/ignite/recovery/config.recover

File that describes the System configuration.

/var/opt/ignite/recovery/fstab

A copy of the current /etc/fstab file for

reference in case the Interactive mode was used,

causing the /etc/fstab file to be re-created.

/var/tmp/uxinstlf.recovery

Default temporary location for Boot LIF volume

creation.

/opt/ignite/data/scripts/os_arch_post_l

post_load scripts which runs when booting from the

recovery tape. Saves away important files that

get altered by recovery process.

/opt/ignite/data/scripts/os_arch_post_c

post_load script which runs when booting from the

recovery tape. Restores important files that get

altered by recovery process.

SEE ALSO

pax(1), instl_adm(5), ignite(5), check_recovery(1M),

copy_boot_tape(1M), instl_adm(1M), make_medialif(1M),

make_sys_image(1M), save_config(1M).

Ignite-UX & Bootable Tapes

Greg Fields

Introduction

make_recovery Options

Introduction

Restore Exceptions

Patches

Using the System Recovery Tape

Screen Examples

Making Changes to vg00 Using the Unsupported Method

Making changes to vg00 Using the Supported Method

This will create the file

Since you used the . p option this will create the file

Unedited config.recover

Edited config.recover

The Results

Summary

Man Page for make_recovery for Ignite-UX Version 1.59

SYNOPSIS

DESCRIPTION

Considering the filesystems that can be moved outside the root

Filesystem kbytes used avail %used Mounted on

Using The Recovery Tape to Boot

Each option requires superuser privilege. Progress and errors are

If the disk drive and/or hardware paths to be configured are not the

Interactive Mode

Installed Products Database

Excluding Files From Archive

DDS Tape Devices

NOT SUPPORTED

Send email to Interex or to the Webmaster©Copyright 1999 Interex. All rights reserved.

Send email to Interex or to the Webmaster
©Copyright 1999 Interex. All rights reserved.