Automatic backup and restore for configuration of a logical volume manager during software installation

[0001] 1. Field of the Invention

[0002] This invention relates to software installations on a computerized device and more particularly, to an automated system backup and restore during a software installation on a computerized device.

[0003] 2. Description of the Related Art

[0004] In current enterprise environments, businesses typically employ a large storage area network (SAN) that is made up of several large storage servers and numerous storage devices. Each storage area network (SAN) generally includes at least one logical volume manager (LVM) that provides a mapping layer between the application programs running on, for example, a workstation computer, and the physical disks on which the network data is ultimately stored. The logical volume manager (LVM) typically has a system configuration that is large and complex.

[0005] When software on a storage device needs to be migrated or upgraded, a network system administrator generally has to manually perform several tasks that are error prone and extremely time consuming. Additionally, conventional migration/upgrade methods generally require that the storage servers be rebooted after the installation of the new software, which may disrupt all of the users and user activity on the network. When the system is rebooted, all of the application programs are shut down, even if they are not related to the software devices involved in the migration/upgrade.

[0006] FIG. 1 depicts a conventional method 100 for manually backing up and restoring a system configuration during a software installation. The method 100 begins 102 by manually backing 104 up the system configuration. This is conventionally a manual procedure performed by a system or network administrator. The administrator then manually inactivates 106 the configuration of the logical volume manager (LVM) in order to install 108 the new software on the storage device or devices. After the new software has been installed, the administrator then manually reconfigures 110 the storage devices and restores 112 the configuration of the logical volume manager (LVM). The conventional method 100 then ends 114. As discussed above, conventional software installation practices require a user to manually backup a system configuration prior to installing the new software and then manually restore the system configuration after the new software is installed.

[0007] What is needed is a process, apparatus, and system that automatically backup and restore a system configuration during the installation of new software on a software device. Beneficially, such a process, apparatus, and system would be embedded within a system packaging file so as to limit the need for human involvement in the software migration/upgrade process. The process, apparatus, and system would also beneficially avoid unnecessary human errors that result from human involvement with the complicated system configuration.

[0008] The present invention has been developed in response to the present state of the art, and in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available software installation systems. Accordingly, the present invention has been developed to provide a process, apparatus, and system for automated system backup and restore during a software installation that overcome many or all of the above-discussed shortcomings in the art.

[0009] The apparatus for automated system backup and restore is in one embodiment provided with a logic unit containing a plurality of modules configured to functionally execute the necessary steps of automatically backing up and restoring a system configuration during a software installation. These modules in the described embodiments include a software installation module, a file packaging module, a pre-removal module, a backup module, a removal module, a post-installation module, a reconfiguration module, a restoration module, a recovery module, a system configuration module, a volume group identification module, a physical volume identification module, a physical volume device type module, a volume group attribute module, a volume group file systems module, a software device module, a mounting module, a status module, and a conversion module.

[0010] The apparatus, in one embodiment, is configured to automatically back up and restore a system configuration during a software installation. The software installation module may be located in a server and configured to assist with the installation of new software on a software device, such as a physical disk device driver. The file packaging module may be configured to embed the backup and restore procedures in the server packaging files so that the backup and restore procedures may be automatically executed during a migration or upgrade of storage device software.

[0011] The pre-removal module, in one embodiment, may be configured to automatically execute a pre-removal procedure prior to installing the software on the software device. One embodiment of the pre-removal module described includes the backup module and removal module. The backup module maybe configured to backup the system configuration of, for example, a logical volume manager (LVM) prior to the installation of new software on the software device. The removal module may be configured to remove the software device from its electronic environment prior to the installation of new software on the software device.

[0012] Similarly, the post-installation module is preferably configured to automatically execute a post-installation procedure after installing the software on the software device. One embodiment of the recovery module as described includes the reconfiguration module and the recovery module. The reconfiguration module may be configured to reconfigure the software device after new software has been installed. The restoration module may be configured to restore the system configuration of, for example, a logical volume manager (LVM) after the installation of new software on the software device.

[0013] The recovery module disclosed also includes a reconfiguration module and a restoration module, which may be substantially similar to the reconfiguration module and restoration module, respectively, of the post-installation module. The recovery reconfiguration module may be configured to reconfigure the software device after a failed attempt by the post-installation module. Likewise, the recovery restoration module may be configured to restore the system configuration of, for example, a logical volume manager (LVM) after a failed attempt by the post-installation module.

[0014] The system configuration module disclosed includes the volume group identification module, the physical volume identification module, the physical volume device type module, the volume group attribute module, and the volume group file systems module. The system configuration module may be configured to store system configuration information for the logical volume manager (LVM), for example.

[0015] The volume group identification module is preferably configured to store a volume group identifier (VGID). The physical volume identification module is preferably configured to store a physical volume identifier (PVID). The physical volume device type module is preferably configured to store a device type, such as a hard disk drive identifier, for a given physical volume. The volume group attribute module is preferably configured to store an attribute of a volume group, such as whether the volume group is active. The volume group file systems module is preferably configured to store an indicator to indicate whether a file system is mounted, for example.

[0016] The software device module in the depicted embodiments includes the mounting module, the status module, and the conversion module. The software device module may be configured to administer the operation of the software device during the installation of new software. The mounting module is preferably configured to facilitate mounting and unmounting a file system. The status module is preferably configured to vary on and vary off a volume group. The conversion module is preferably configured to convert a volume group from software device based to server based, and vice-versa.

[0017] A system of the present invention is also presented for automated system backup and restore during installation of new software on a software device. The system, in one embodiment, includes a storage server operating in connection with a logical volume manager (LVM) to manage a plurality of storage software devices, such as physical hard disk drives. The system discussed also includes a software installation module, a pre-removal module, a post-installation module, and a file packaging module similar to those discussed above. A further embodiment of the system may also include the recovery module as discussed above. In a particular embodiment of the system, neither the storage server nor the logical volume manager (LVM) requires a system reboot following installation of the new software on the storage software device.

[0018] The system may further include multiple storage servers connected together within a storage area network (SAN) and may communicate with one or more logical volume managers (LVMs) also connected to the network.

[0019] A process of the present invention is also presented for automated system backup and restore during installation of new software on a software device. The process in the disclosed embodiments substantially includes the steps necessary to carry out the functions presented above with respect to the operation of the described apparatus and system. In one embodiment, the process includes automatically executing a pre-removal procedure prior to installing the software on the software device, automatically executing a post-installation procedure after installing the software on the software device, embedding the pre-removal and post-installation procedures in a packaging file.

[0020] In a further embodiment, the process also includes backing up the system configuration of, for example, the logical volume manager (LVM) and removing the software device prior to the installation of the new software on the software device. A still further embodiment of the process discussed includes reconfiguring the software device and restoring the system configuration of, for example, the logical volume manager (LVM) after installing the software on the software device.

[0021] The process may also include reconfiguring the software device via, for example, the recovery module, after a failed attempt by the post-installation module to reconfigure the software device. Likewise, the process may include restoring the system configuration of the logical volume manager (LVM) after a failed attempt by the post-installation module to restore the system configuration.

[0022] The process may further comprise storing the system configuration information and managing the operation of the storage software device during the installation.

[0023] The present invention may also be embodied in a computer readable medium configured to carry out the process described above, and may also be embodied in the form of an apparatus having the means for implementing the process described above.

[0024] These features and advantages of the present invention will become more fully apparent from the following description and appended claims, or maybe learned by the practice of the invention as set forth hereinafter.

[0035] Many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

[0036] Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

[0037] Indeed, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.

[0038] FIG. 2 depicts a logical volume manager (LVM) environment 200. The depicted LVM environment 200 includes three layers, namely, an application layer 202, a logical layer 204, and a physical layer 206. In one embodiment, the application layer 202 is a journaled file system (JFS) 208. In an alternative embodiment, the application layer 202 may be a relational database management system (RDBMS) (not shown). Application programs execute within the application layer 202 using logical blocks. A logical block is a unit of data including a number of bytes of data. For example, one logical block may include 512 bytes of data.

[0039] The application programs executing within the application layer 202 often need to store and access data within the physical layer 206. The logical layer 204 represents a mapping layer that operates on logical volumes 210 that include one or more logical blocks. A logical volume 210 is defined in terms of the information that it contains rather than the physical attributes. A logical volume 210 represents the data as used by an application program rather than the physical placement of the data in a storage device.

[0040] The logical layer 204 includes a logical volume device driver (LVDD) 212 that is a pseudo-device driver that operates on the logical volumes 210 and manages and processes all input/output (I/O). The logical volume device driver (LVDD) 212 maps the logical volume 210 to a physical volume 214 that represents the physical placement of the data in a storage device. Each physical volume 214 may be assigned a name and a physical volume identifier (PVID) that is a type of serial number that identifies the physical volume 214. The physical volume identifier (PVID) is often a combination of a server's serial number and the date that the physical volume 214 is created.

[0041] One or more physical volumes 214 maybe grouped together to form a volume group 216. A physical volume 214 may be added or removed from the volume group 216 after the volume group 216 has been created. Each volume group 216 may be assigned a name and a volume group identifier (VGID) that is similar to the physical volume identifier (PVID) for a physical volume 214. The volume group identifier (VGID) often is used as a base for the logical volume identifier (LVID) of a logical volume 210 within the volume group 216. A physical volume 214 is transferred via a device driver 218 to or from a physical disk 220. The device driver 218, in one embodiment, is a small computer system interface (SCSI) disk device driver. In an alternative embodiment, the device driver 218 may be a serial storage architecture (SSA) disk device driver. The physical disk 220 may be a magnetic hard disk drive (HDD), an optical drive, or any other type of electronic storage device.

[0042] FIG. 3 depicts a schematic block diagram of a server 300 that may be employed in conjunction with the logical volume manager (LVM) environment shown in FIG. 2. The depicted server 300 includes a central processing unit (CPU) 302, a local electronic memory device 304, an application layer interface 306, a physical layer interface 308, and a software installation module 310. In one embodiment, the server 300 may comprise a freestanding computer or workstation connected to a network. In another embodiment, the server 300 may comprise a storage server.

[0043] The application layer interface 306 is configured, in one embodiment, to process communications between the application layer 202 and the logical layer 204 of the logical volume manager (LVM) environment 200. For example, the application layer interface 306 may be configured to receive logical blocks operated on by an application program to be stored on a physical disk 220 within the physical layer 206. The application layer interface 306 also may be configured to communicate logical blocks, such as a saved file, to the application layer 202 to be process by an application program.

[0044] The physical layer interface 308 is configured, in one embodiment, to process communications between the physical layer 206 and the logical layer 204 of the logical volume manager (LVM) environment 200. For example, the physical layer interface 308 may communicate physical volumes 214 to physical layer 206 to be stored on the physical disks 220. The physical layer interface 308 also may be configured to receive physical volumes 214 from the physical layer 206 in response to a file access request from an application program within the application layer 202.

[0045] The depicted software installation module 310 includes a file packaging module 312 that includes a pre-removal module 314, a post-installation module 316, a recovery module 318, a system configuration module 320, and a software device module 322. The software installation module 310, in one embodiment, is configured to assist in the installation of new software on a software device, such as a physical disk device driver 218. The file packaging module 312 is included in the software installation module 318 and is configured, in one embodiment, to embed in the packaging files backup and restore procedures that may be automatically executed during a migration or upgrade of storage device software.

[0046] The depicted file packaging module 312 includes a pre-removal module 314, a post-installation module 316, a recover module 318, a system configuration module 320, and a software device module 322. The pre-removal module 314 is configured to backup and deactivate a logical volume manager (LVM) system configuration, such as through a backup module 324, and to remove the system configuration, such as through a removal module 326. If a failure occurs during execution of a pre-removal procedure, an administrator may identify the cause of the failure, fix the cause of the failure, and execute the pre-removal procedure again.

[0047] The post-installation module 314 is configured to reconfigure a software device, such as through a reconfiguration module 328, and restore the logical volume manager (LVM) system configuration, such as through a restoration module 330, after new software has been installed on the software device. In one embodiment, the restoration module 330 uses the system configuration stored by the backup module 324. If a failure occurs during execution of a post-installation procedure, the software installation will complete successfully, but an administrator may need to execute a recovery procedure in order to fully restore the logical volume manager (LVM) system configuration.

[0048] In one embodiment, the administrator may execute the recovery procedure using the recovery module 318. The depicted recovery module 318 includes a reconfiguration module 332 and a restoration module 334, which are preferably substantially similar to the reconfiguration module 328 and restoration module 330, respectively, within the post-installation module 316. The reconfiguration module 332 and restoration module 334 within the recovery module 318, however, may perform additional tests to determine how much, if any, of the logical volume manager (LVM) system configuration is already restored.

[0049] The system configuration module 320 is configured, in one embodiment, to store information about the system configuration of the logical volume manager (LVM) and is described in greater detail in conjunction with FIG. 4. The software device module 322 is configured, in one embodiment, to manage the operation of the software device and is described in more detail in conjunction with FIG. 5. The system configuration module 320 may be employed by the backup module 324 within the pre-removal module 314 or by one of the reconfiguration modules 328, 332 within the post-installation module 316 or recovery module 318. The software device module 322 may be employed by the removal module 326 within the pre-removal module or by one of the restoration modules 330, 334 within the post-installation module 316 or recovery module 318.

[0050] FIG. 4 depicts one embodiment of a system configuration module 320 of FIG. 3 that includes a volume group identification module 402, a physical volume identification module 404, a physical volume device type module 406, a volume group attribute module 408, and a volume group file systems module 410.

[0051] The volume group identification module 402 is preferably configured to store the volume group identifier (VGID) of a volume group. Similarly, the physical volume identification module 404 is preferably configured to store the physical volume identifier (PVID) of a physical volume. In one embodiment, the volume group identifier (VGID) and physical volume identifier (PVID) may be stored on the electronic memory device 304 within the server 300. In an alternative embodiment, the identifiers may be stored on a separate electronic storage device.

[0052] The physical volume device type module 406 is preferably configured to store a device type of a physical volume, for example if the software device is a hard disk drive. The volume group attribute module 408 is preferably configured to store one or more attributes associated with a volume group, such as whether the volume group is a concurrent volume group that may be accessed concurrently by multiple servers, for example. The volume group file systems module 410 is preferably configured to store information regarding the file systems, such as whether a software device is presently mounted or not mounted.

[0053] FIG. 5 depicts one embodiment of a software device module 322 of FIG. 3 that includes a mounting module 502, a status module 504, and a conversion module 506. The mounting module 502 is, in the depicted embodiment, configured to mount and unmount a software device, such as a physical disk 220 in the physical layer 206. The status module 504 is preferably configured to vary on and vary off a volume group 216. For example, the pre-removal module 314 may invoke the status module 504 to vary off an active volume group 216 prior to installation of new software on a software device. Similarly, the post-installation module 316 may invoke the status module 504 to vary on a volume group 216 after installation of the new software if the volume group 216 was active prior to the installation.

[0054] The conversion module 506 is preferably configured to convert a software device based volume group 216 to a server based volume group 216, such as prior to installation of new software. The conversion module 506 is further configured to convert a server based volume group 216 to a software device based volume group 216, such as after installation of new software. In another embodiment, the conversion module 506 may convert a software device based volume group 216 to a backup device based volume group 216 by copying a volume group 216 from a software device to a backup storage device (not shown).

[0055] FIG. 6 depicts one embodiment of a high level software installation process 600 that may be employed independently or within the logical volume manager (LVM) environment that is depicted in FIG. 2 and explained above. Preferably, each of the steps of FIG. 6 is performed automatically by a software installation module such as the software installation module 310 of FIG. 3.

[0056] The depicted software installation process 600 begins 602 by performing 604 a pre-removal sub-process, one embodiment of which will be discussed in more detail in conjunction with FIGS. 7a and 7b below. The software installation process 600 then determines 606 if the pre-removal sub-process failed to execute properly. If the pre-removal process did not fail, the software installation process 600 removes 608 the previous files from the software device and performs 610 a pre-install sub-process. The pre-install sub-process is not altered or affected by the present invention and is not discussed in detail.

[0057] The software installation process 600 then determines 612 if the pre-installation sub-process failed to execute properly. If the pre-install sub-process did not fail, the new software is then installed 614 on the software device. The software installation process 600 then performs 616 a post-install sub-process, one embodiment of which will be discussed in more detail in conjunction with FIGS. 8a and 8b below. The software installation process 600 then determines 618 if the post-installation sub-process failed to execute properly. If the post-installation sub-process did not fail, the software installation process 600 performs 620 some conventional cleanup procedures, such as working with an object database manager (ODM). The depicted software installation process 600 then ends 622. If at some point the software installation process 600 determines 606, 612, 618 that a sub-process failed to execute properly, the software installation process 600 may also end 622.

[0058] FIGS. 7a and 7b depict one embodiment of a more detailed pre-removal process 700 given by way of example of the pre-removal sub-process 604 of FIG. 6. For convenience, the pre-removal process 700 is shown in a first part 700a and a second part 700b, but will be referred to collectively as the pre-removal process 700. Execution of the pre-removal process 700 is preferably administered by the pre-removal module 314 of the software installation module 310 in the server 300.

[0059] The depicted pre-removal process 700 begins 702 by collecting 704 the volume group identifier (VGID) for each volume group 216 stored on the software device to be migrated or upgraded. As described above, the volume group identifier (VGID), in one embodiment, may be collected by the volume group identification module 402 and stored in the electronic memory device 304 of the server 300. The pre-removal process 700 then collects 706 the physical volume identifier (PVID) for each physical volume 214 stored on the software device. The physical volume identifier (PVID) may be collected by the physical volume identification module 404 and stored in the electronic memory device 304 of the server 300.

[0060] The pre-removal process 700 then determines 708 if there is a failure in collecting the physical volume identifier (PVID). If there was not a failure, the pre-removal process 700 collects 710 the device type of each physical volume 214 stored in the software device. The physical volume device type may be collected, in one embodiment, by the physical volume device type module 406 and stored in the electronic memory device 304 of the server 300.

[0061] The pre-removal process 700 subsequently determines 712 if a volume group 216 is active on the software device. If a volume group 216 is active, the pre-removal process 700 collects the attributes of the volume group 216, such as by the volume group attribute module 408, and stores the attributes, for example, in the electronic storage memory 304 of the server 300.

[0062] After collecting 714 the attributes of an active volume 216, or if the volume group is determined 712 to not be active, the pre-removal process 700 collects 716 file systems information of the volume group 216. In one embodiment, the pre-removal module 314 employs the volume group file systems module 410 to collect the file systems information.

[0063] The pre-removal process 700 then determines 718 if the file systems are mounted. if the file systems are mounted, the pre-removal process 700 unmounts 720 the file systems and determines 722 if an unmounting failure occuffed. In one embodiment, the pre-removal module 314 employs the mounting module 502 to unmount the file systems. If no file systems were mounted or if the mounted file systems were successfully unmounted, the pre-removal process 700 continues by determining 724 if a volume group 216 is varied on. If a volume group 216 is determined 724 to be varied on, the pre-removal process 700 varies off 726 the volume group 216, such as through the status module 504 of the software device module 322. The pre-removal process 700 then determines 728 if a vary off failure occurred. If no volume groups 216 were varied on or if the volume groups 216 were successfully varied off, the pre-removal process 700 determines 730 if a volume group 216 is software device based.

[0064] If it is determined that a volume group 216 is software device based, the pre-removal process 700 then converts 732 the volume group from software device based to server based, such as through the conversion module 506, for example. The pre-removal process 700 then determines 734 if a conversion failure occurred. If the volume group 216 is not software device based or if the volume group was successfully converted, the pre-removal process then determines 736 if additional volume groups 216 need to be processed and, if so, iteratively returns to step 704 to collect the volume group identifier (VGID) and to repeat the described steps of the pre-removal process 700. After processing all of the necessary volume groups 216, the pre-removal process 700 then removes 738 the software devices in preparation to install the new software.

[0065] If the pre-removal process 700 determines 708 that there is a correction failure, determines 722 that an unmounting failure has occurred, determines 728 that there is a vary off failure, or determines 734 that a conversion failure has occurred with one or more of the volume groups 216 being processed, the installation fails 740. After either failing 740 the installation or successfully removing 738 the software devices, the depicted pre-removal process 700 ends 742.

[0066] FIGS. 8a and 8b depict one installation of a more detailed post-installation process 800 given by way of example of the post-installation sub-process 616 of FIG. 6. For convenience, the post-installation process 800 is shown in a first part 800a and a second part 800b, but will be referred to collectively as the post-installation process 800. Execution of the post-installation process 800 is preferably administered by the post-installation module 316 of the software installation module 310 in the server 300.

[0067] As described above, the post-installation process 800 occurs after the new software has been installed on a software device. The post-installation process 800 is designed to reconfigure the software devices having the newly installed software and restore the system configuration of the logical volume manager (LVM). The depicted post-installation process 800 begins 802 by configuring 804 the software devices.

[0068] The post-installation process 800 then determines 806 if a configuration failure occurred. If a configuration failure did not occur, the post-installation process 800 determines 808 if a volume group 216 was active prior to the installation of the new software. In one embodiment, the system configuration module 320 is configured to determine if a volume group was active. In another embodiment, the post-installation module 316 may access stored volume group attributes to determine if the volume group was active. If the volume group 216 was active, the post-installation process 800 varies on the volume group 216 and, in one embodiment, restores the original attributes of the volume group 216. The post-installation process 800 then determines 812 if a vary on failure occurred.

[0069] If the volume group 216 was not active or if the volume group 216 was successfully varied on, the post-installation process 800 then determines 814 if the volume group 216 was software device based prior to the installation of the new software. In one embodiment, the post-installation module 316 may employ the conversion module 506 to determine if the volume group 216 was software device based. If the volume group 216 was software device based, the post-installation process 800 converts 816 the volume group 216 back to software device based and then determines 818 if a conversion failure occurred.

[0070] If the volume group 216 was not software device based or if the volume group 216 was successfully converted to software device based, the post-installation process 800 then determines 820 if the file systems were mounted prior to the installation of the new software. If the file systems were mounted, the post-installation process 800 then mounts 822 the file systems and determines 822 if a mounting failure occurred. If the file systems were not mounted or if the file systems were successfully mounted, the post-installation process 800 determines 826 if additional volume groups 216 need to be processed and, if so, iteratively returns to step 808 to determine if the additional volume group 216 was active and to repeat the described steps of the post-installation process 800.

[0071] If the post-installation process 800 determines 806 that there is a configuration failure, determines 812 that there is a vary on failure, determines 818 that there is a conversion failure, or determines 824 that there is a mounting failure with one or more of the volume groups 216 being processed, the post-installation process 800 proceeds to exit 828 the installation and display 830 an error to a system administrator. In one embodiment, the post-installation process 800 may advise the administrator to run 832 a recovery sub-process. After either processing all of the necessary volume groups 216 or exiting the installation due to a failure, the depicted post-installation process 800 ends 834.

[0072] FIGS. 9a and 9b depict one embodiment of a more detailed recovery process 900 given by way of example of the recovery sub-process 832 of FIG. 8b. For convenience, the recovery process 900 is shown in a first part 900a and a second part 900b, but will be referred to collectively as the recovery process 900. Execution of the recovery process 900 is preferably administered by the recovery module 318 of the software installation module 310 in the server 300.

[0073] As described above, the recovery process 900 occurs after the new software has been installed on a software device and a failure has occurred during the post-installation process 800. The recovery process 900 is substantially similar to the post-installation process and is designed to reconfigure the software devices having the newly installed software and restore the system configuration of the logical volume manager (LVM). The depicted recovery process 900 begins 902 by determining 904 if the software devices were successfully configured during the post-installation process 800 and, if not, configures 906 the software devices. The configuration step 906 of the recovery process 900 is substantially similar to the configuration step 804 of the post-installation process 800.

[0074] The recovery process 900 then determines 908 if a configuration failure occurred. The determination step 908 of the recovery process 900 is substantially similar to the determination step 806 of the post-installation process 800. If a configuration failure did not occur, the recovery process 900 determines 910 if a volume group 216 was active prior to the installation of the new software. The determination step 910 of the recovery process 900 is substantially similar to the determination step 808 of the post-installation process 800. If the volume group 216 was active, the recovery process 900 determines if the volume group 216 was successfully varied on during the post-installation process 800 and, if not, varies on the volume group 216 and determines 812 if a vary on failure occurred. The vary on step 914 and determination step 916 of the recovery process 900 are substantially similar to the vary on step 810 and determination step 812, respectively, of the post-installation process 800.

[0075] If the volume group 216 was not active or if the volume group 216 was successfully varied on, the recovery process 900 then determines 918 if the volume group 216 was software device based prior to the installation of the new software. The determination step 918 of the recovery process 900 is substantially similar to the determination step 814 of the post-installation process 800. If the volume group 216 was software device based, the recovery process 900 determines 920 if the volume group 216 was successfully and fully converted during the post-installation process 800 and, if not, the recovery process 900 determines 922 if the volume group 216 was at least partially converted during the post-installation process 800.

[0076] If the volume group was partially converted during the post-installation process 800, the recovery process 900 fixes 928 the volume group 216 by finalizing the conversion. Otherwise, the recovery process 900 converts 924 the volume group 216 back to software device based and then determines 926 if a conversion failure occurred. The conversion step 924 and determination step 926 of the recovery process 900 are substantially similar to the conversion step 816 and determination step 818, respectively, of the post-installation process 800.

[0077] If the volume group 216 was not software device based or if the volume group 216 was successfully converted to software device based, the recovery process 900 then determines 930 if the file systems were mounted prior to the installation of the new software. The determination step 930 of the recovery process 900 is substantially similar to the determination step 820 of the post-installation process 800. If the file systems were mounted, the recovery process 900 then determines 932 if the file systems were successfully mounted during the post-installation process 800 and, if not, then mounts 934 the file systems and determines 936 if a mounting failure occurred. The mounting step 934 and determination step 936 of the recovery process 900 are substantially similar to the mounting step 822 and determination step 824, respectively, of the post-installation process 800.

[0078] If the file systems were not mounted or if the file systems were successfully mounted, the recovery process 900 determines 938 if additional volume groups 216 need to be processed and, if so, iteratively returns to step 910 to determine if the additional volume group 216 was active and to repeat the described steps of the recovery process 900. The determination step 938 of the recovery process 900 is substantially similar to the determination step 826 of the post-installation process 800.

[0079] If the recovery process 900 determines 908 that there is a configuration failure, determines 916 that there is a vary on failure, determines 926 that there is a conversion failure, or determines 936 that there is a mounting failure with one or more of the volume groups 216 being processed, the recovery process 900 proceeds to exit 940 the installation and display 942 an error to a system administrator. In one embodiment, system administrator may run 944 a subsequent recovery sub-process, such as the recovery process 900. The exiting step 940, displaying step 942, and recovery step 944 of the recovery process 900 are substantially similar to the exiting step 828, displaying step 830, and recovery step 832, respectively, of the post-installation process 800. After either processing all of the necessary volume groups 216 or exiting the installation due to a failure, the depicted recovery process 900 ends 946.

[0080] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.