WO2014147707A1 - 情報処理装置、情報処理方法、及び情報処理プログラム - Google Patents

情報処理装置、情報処理方法、及び情報処理プログラム Download PDF

Info

Publication number
WO2014147707A1
WO2014147707A1 PCT/JP2013/057670 JP2013057670W WO2014147707A1 WO 2014147707 A1 WO2014147707 A1 WO 2014147707A1 JP 2013057670 W JP2013057670 W JP 2013057670W WO 2014147707 A1 WO2014147707 A1 WO 2014147707A1
Authority
WO
WIPO (PCT)
Prior art keywords
failure
installation
file
information
progress
Prior art date
Application number
PCT/JP2013/057670
Other languages
English (en)
French (fr)
Inventor
関恭一
星大輔
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to JP2015506392A priority Critical patent/JP6160688B2/ja
Priority to PCT/JP2013/057670 priority patent/WO2014147707A1/ja
Publication of WO2014147707A1 publication Critical patent/WO2014147707A1/ja
Priority to US14/855,468 priority patent/US20160004607A1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1433Saving, restoring, recovering or retrying at system level during software upgrading
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • G06F11/1469Backup restoration techniques
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1471Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1448Management of the data involved in backup or backup restore
    • G06F11/1451Management of the data involved in backup or backup restore by selection of backup contents
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84Using snapshots, i.e. a logical point-in-time copy of the data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865Monitoring of software

Definitions

  • the present invention relates to processing when a failure occurs in software installation.
  • FIG. 1 shows an operation flow of server initial setting processing.
  • a driver corresponding to the application is installed (S1001).
  • an application is installed (S1002)
  • an application specific setting corresponding to the user's environment is performed (S1003).
  • a final check is performed to confirm whether or not the application has been correctly installed (S1004). If a hardware failure, software error, power-off, etc. occur during the initial setting process, and the process fails unexpectedly (S1005), it is not recorded until the process was performed correctly. Cannot resume from. In this case, the user must perform the OS installation (recovery) again (S1006), and the recovery takes a lot of time.
  • This first technique is premised on causing a computer to continuously install a plurality of software. And this 1st technique makes a computer implement
  • This technique includes a data saving unit for saving initialization data of the OS on the main storage device to an initialization data saving area, and an input / output device control unit for controlling stop of the input / output device connected to the information processing device. And comprising. Furthermore, the second technique includes a restart control unit that designates whether or not to restart and transfers control to a specific address of the OS program, and a data recovery unit that recovers initialization data from the data saving area. .
  • JP 2004-302929 A Japanese Patent Laid-Open No. 11-24936
  • the process is resumed in a state where the installation process has already progressed partway.
  • the file being processed remains, it cannot be guaranteed that the installation will be completed correctly even if the installation cannot be resumed or reunited. Therefore, when the initial setup is continued after the problem occurs, it is necessary to confirm to what processing the manual setup has been carried out manually, which complicates the operation and takes time.
  • an object of the present invention is to reduce the time required for resuming processing when a failure occurs in software installation processing.
  • the information processing apparatus includes a storage unit, a storage processing unit, a processing unit, a detection unit, a progress management unit, a restoration unit, and a control unit.
  • the storage unit stores the location and file name of a file to be changed that is changed in a predetermined process when software installation is executed.
  • the save processing unit acquires and saves the change target file using the location and file name of the change target file stored in the storage unit.
  • the processing unit executes installation.
  • the detection unit detects a failure that occurred during installation.
  • the progress management unit acquires progress information indicating the progress status of the installation, and when a failure is detected, identifies a predetermined process when the failure occurs as a failure time process based on the progress information.
  • the restoration unit restores the file changed in the failure processing using the saved change target file corresponding to the file.
  • the control unit resumes the installation from the start time of the failure process.
  • the operation flow of the server initial setting process is shown.
  • An example of the functional block diagram of the information processing apparatus which concerns on this embodiment is shown.
  • 2 shows an example of the configuration of an information processing apparatus according to the present embodiment.
  • An example of a progress management table concerning this embodiment is shown.
  • An example of application change information concerning this embodiment is shown. It is a figure for demonstrating a mode that a file is backed up by the backup process part. It is a figure for demonstrating a mode that the file of the file name described in the additional information list
  • wrist of application change information is deleted. It is a figure for demonstrating a mode that the installation object file is rewritten from application environment backup information.
  • the entire processing flow of the initialization process in this embodiment is shown.
  • movement flow of the installation object determination process in this embodiment is shown.
  • movement flow of the application installation process in this embodiment is shown.
  • An operation flow of driver installation, application installation, and unique setting in this embodiment will be described.
  • movement flow of the retry process in this embodiment is shown.
  • movement flow of the recovery process in this embodiment is shown.
  • 2 shows an example of a hardware configuration of an information processing apparatus according to the present embodiment.
  • FIG. 1 is an example of a functional block diagram of the information processing apparatus according to the present embodiment.
  • the information processing apparatus 1 includes a storage unit 2, a storage processing unit 3, a processing unit 4, a detection unit 5, a progress management unit 6, a restoration unit 7, and a control unit 8.
  • the storage unit 2 stores the location and file name of a file to be changed that is changed in a predetermined process when software installation is executed. Further, the storage unit 2 stores the location and file name of an addition target file to be added in a predetermined process. In addition, the storage unit 2 stores normal state information when a predetermined process is normally completed.
  • the save processing unit 3 acquires and saves the change target file using the location and file name of the change target file stored in the storage unit.
  • the processing unit 4 performs installation.
  • Detecting unit 5 detects a failure that occurred during installation.
  • the detecting unit 5 detects a failure and collects failure information indicating the content of the failure.
  • the progress management unit 6 acquires progress information indicating the progress of installation, and when a failure is detected, identifies a predetermined process when the failure occurs as a failure time process based on the progress information.
  • the progress management unit 6 acquires progress information before and after the predetermined process.
  • the progress management unit 6 determines whether or not the predetermined process has been normally completed based on the normal state information, and determines that the predetermined process has not been completed normally. Specify as a process.
  • the progress management unit 6 determines whether or not the failure process can be restarted based on the failure information, the progress information, or the determination result.
  • the restoration unit 7 restores the file changed in the failure process using the saved change target file corresponding to the file. Further, the restoration unit 7 deletes the file added in the failure process based on the location and file name of the addition target file stored in the storage unit. When the progress management unit determines that the failure process cannot be resumed, the restoration unit 7 restores the file changed in the failure process using the saved change target file.
  • FIG. 3 shows an example of the configuration of the information processing apparatus according to the present embodiment.
  • the information processing apparatus 1 according to the present embodiment is, for example, a server, and includes an installation processing unit 11, a storage unit 12, a control unit 13, a backup processing unit 14, a recovery processing unit 15, and a check processing unit 16.
  • the installation processing unit 11 is an example of the processing unit 4 and the detection unit 5.
  • the storage unit 12 is an example of the storage unit 2.
  • the control unit 13 is an example of the progress management unit 6 and the control unit 8.
  • the backup processing unit 14 is an example of the storage processing unit 3.
  • the recovery processing unit 15 is an example of the restoration unit 7.
  • the check processing unit 16 is an example of the progress management unit 6.
  • the installation processing unit 11 installs an application, installs a driver necessary for installing the application, and performs application specific settings according to the user environment.
  • the installation processing unit 11 detects a failure that has occurred during the installation process, and notifies the control unit 13 that a failure has occurred. At that time, the installation processing unit 11 stores failure information, which is information indicating the content of the failure and the state of the system at the time of the failure, in the storage unit 12. Notify that the information storage is complete.
  • the installation processing unit 11 stores operation information such as a log of installation processing in the storage unit 12.
  • the storage unit 12 includes a progress management table that is information for grasping the progress of the installation process, application change information that is a list of information that each application adds / changes, and whether or not the installation has been performed normally. Setting check information for determining whether or not is stored.
  • the storage unit 12 also has an area for storing failure information when a failure occurs, an area for storing a backup target file by the backup processing unit 14, and an area for storing operation information of the installation process. .
  • the storage unit 12 also stores files related to installed drivers and applications.
  • the progress management table is information used for grasping the progress of installation processing for each application.
  • the progress management table is created for each application to be installed in association with each application.
  • FIG. 4 shows an example of the progress management table according to the present embodiment.
  • the progress management table 20 includes data items of a stage 21, a start flag 22, a completion flag 23, a success flag 24, a failure flag 25, and identification information 29.
  • Stage 21 shows the stage of processing in the installation of one application.
  • application installation is divided into three stages based on the contents of processing.
  • the three stages are driver installation, application installation, and unique settings.
  • Driver installation is a stage where driver installation is performed, which is a system requirement for installing an application.
  • Application installation is a stage where the application itself is installed.
  • the unique setting is a stage where setting items are set according to the user's environment after the application is installed.
  • the stage shown by the stage 21 is not limited to three, For example, you may provide the setting stage before driver installation, etc.
  • the start flag 22 is a flag indicating that the processing of the stage 21 has been started.
  • the start flag 22 is set by the control unit 13 immediately before the process of the stage 21 is started.
  • the completion flag 23 is a flag indicating that the processing of the stage 21 is completed.
  • the completion flag 23 is set by the control unit 13 immediately after the processing of the stage 21 is completed.
  • the success flag 24 is a flag indicating that the processing of the stage 21 has been normally completed.
  • the success flag 24 is set by the control unit 13 when it is determined that the processing of the stage 21 has been normally completed.
  • the determination process performed after the end of the stage 21 process to determine whether or not the stage 21 process has been normally completed is referred to as a setting check. Details of the setting check will be described later.
  • the failure flag 25 is a flag indicating that the processing of the stage 21 is not normally completed.
  • the failure flag 25 is set by the control unit 13 when it is determined that the processing of the stage 21 is not normally performed.
  • the identification information 29 is information indicating which installation target application the progress management table 20 is associated with.
  • the application change information is a list of information that is created for each process stage of installing each application and added / changed in each process. That is, the application change information is managed for each application to be installed, and is further managed for each stage 21.
  • FIG. 5 shows an example of application change information according to the present embodiment.
  • the application change information 30 includes correspondence processing information 31, an additional information list 32, and a change information list 33.
  • Corresponding process information 31 is information indicating which stage 21 process the application change information 30 corresponds to in which application is installed.
  • the process of the stage 21 indicated by the corresponding process information 31 is referred to as a target process.
  • the additional information list 32 is a list of information added when the target process is executed.
  • the additional information list 32 includes an additional file list 34 and an additional registry key list 35.
  • the additional file list 34 is a list of names of files (including folders or directories) added in the target process. This name is represented by a full path including the location information of the file.
  • the additional registry key list 35 is a list of names of registry keys to be added in the target process. Note that the additional registry key list 35 can be omitted in an OS such as Unix (registered trademark) that does not have a registry.
  • the change information list 33 is a list of information that is changed by executing the target process.
  • the change information list 33 includes a change file list 36 and a change registry key list 37.
  • the change file list 36 is a list of names of files (including folders or directories) to be changed in the target process. This name is represented by a full path including the location information of the file.
  • the changed registry key list 37 is a list of names of registry keys to be changed in the target process. It should be noted that the modified registry key list 37 can be omitted in an OS such as Unix (registered trademark) that does not have a registry.
  • the setting check information is information used to determine whether or not the processing has been normally performed in each stage 21 for each installation target application.
  • the setting check information includes, for example, setting items and values that should be set when the process is normally completed.
  • the control unit 13 manages the progress status of the installation process. For this purpose, the control unit 13 performs a process of saving the status of the progress status at a predetermined time point of each process in the installation process. Furthermore, when a failure occurs during the installation process, the control unit 13 performs processing for specifying up to which stage 21 the processing has been completed at the time of occurrence of the failure.
  • control unit 13 sets a start flag 22 at the start of processing of each stage 21. Further, the control unit 13 sets a completion flag 23 at the time when the processing of each stage 21 is completed. After the completion flag 23 is set, the control unit 13 instructs the check processing unit 16 to execute a setting check. Further, the control unit 13 sets the success flag 24 when it is determined that the processing of the stage 21 is normally performed as a result of the setting check of the stage 21. And the control part 13 sets the failure flag 25, when it determines with the process of the stage 21 not being normally performed as a result of a setting check.
  • control unit 13 specifies to which stage 21 the processing has been completed at the time when the failure has occurred.
  • the control unit 13 is notified from the installation processing unit 11 that a failure has occurred. Then, the control unit 13 refers to the progress management table 20 to identify the process that has been completed before the occurrence of the failure.
  • the control unit 13 can identify which application has a failure during the installation process.
  • the control unit 13 determines that the installation process of the application A has been performed when a failure occurs. Then, by confirming that the value of the success flag 24 of the record (row) in which the value of the stage 21 is “driver installation” is set to “true”, the control unit 13 completes the driver installation normally. Can be determined.
  • control unit 13 confirms that the value of the start flag 22 of the record whose stage 21 value is “application installation” is set to “true”. It can be determined that it has been started. Further, the control unit 13 can determine that the failure has occurred before the completion of the installation of the application by confirming that the value of the completion flag 23 of the record “application installation” is not set.
  • control unit 13 instructs the installation processing unit 11 to restart the installation from the start of the processing immediately after the specified time. To do.
  • the backup processing unit 14 backs up the files changed by the processing at each stage before the processing at each stage of the stage 21 is started. For the file to be backed up, the backup processing unit 14 searches for the application change information 30 that matches the value of the corresponding process information 31 to the next stage of processing, and displays the change information list 33 of the application change information 30. Identify by reference.
  • FIG. 6 is a diagram for explaining how files are backed up by the backup processing unit 14.
  • the backup processing unit 14 refers to the change file list 36 of the change information list 33 and recognizes a backup target file. Further, the backup processing unit 14 refers to the change registry key list 37 of the change information list 33 and recognizes the registry key to be backed up (S61).
  • the backup processing unit 14 copies the recognized backup target file to a predetermined save area.
  • the backup processing unit 14 stores the recognized registry key value to be backed up in a predetermined save area in association with the registry key name.
  • the file information and registry key information backed up here will be referred to as application environment backup information 42.
  • the recovery processing unit 15 restores the server to the environment before starting each stage 21 before re-installing the application to be installed. This prevents re-installation from failing due to the effects of files and registry information remaining from the previous installation.
  • the recovery processing unit 15 when a failure occurs, the recovery processing unit 15 returns the server environment to the time when the backup processing unit 14 last backed up. Since the backup processing unit 14 obtains a backup for each stage 21 process, the last backup time is the time immediately before the start of the stage 21 process when a failure occurs.
  • the recovery processing unit 15 When a failure occurs, the recovery processing unit 15 receives a recovery execution command from the check processing unit 16. Then, the recovery processing unit 15 acquires information from the control unit 13 as to whether or not a failure has occurred during execution of processing at which stage of which application. In the following description, the processing stage of an application when a failure occurs will be referred to as failure occurrence processing. If a recovery execution command is not received from the check processing unit 16 even if a failure occurs, the recovery processing unit 15 does not perform recovery processing. This will be described in detail later, but if the failure that occurred is a failure that does not require recovery, the installation process can be resumed without performing recovery. It is to do.
  • the recovery processing unit 15 specifies the application change information 30 in which the value of the response processing information 31 indicates processing at the time of failure occurrence. Then, the recovery processing unit 15 refers to the additional information list 32 of the identified application change information 30 and deletes a file that may have been added in the failure occurrence process.
  • FIG. 7 is a diagram for explaining how a file having a file name described in the additional information list 32 of the application change information 30 is deleted.
  • the recovery processing unit 15 refers to the additional file list 34 in the additional information list 32 and recognizes the deletion target file. Further, the recovery processing unit 15 refers to the additional registry key list 35 of the additional information list 32 and recognizes the registry key to be deleted (S71).
  • the recovery processing unit 15 deletes all the deletion target files recognized in S71 from the installation target disk area 41. In addition, the recovery processing unit 15 deletes all registry key values to be deleted recognized in S71 (S72).
  • the recovery processing unit 15 writes back the target file or registry key described in the change information list 33 of the identified application change information 30 from the application environment backup information 42.
  • FIG. 8 is a diagram for explaining a state where the installation target file is written back from the application environment backup information 42.
  • the recovery processing unit 15 refers to the change file list 36 of the change information list 33 and recognizes the write-back target file. Further, the recovery processing unit 15 refers to the change registry key list 37 in the change information list 33 and recognizes the registry key to be written back (S81).
  • the recovery processing unit 15 copies the write-back target file recognized in S81 from the application environment backup information 42 to the installation target disk area 41.
  • the recovery processing unit 15 registers the registry key to be written back and its value recognized in S81 in the registry with reference to the application environment backup information 42 (S82).
  • the check processing unit 16 performs a setting check, a system check, and a final check.
  • the setting check the check processing unit 16 determines whether or not the application is normally installed.
  • the setting check is started when the check processing unit 16 receives a setting check execution instruction from the control unit 13 after the processing of the stage 21 is completed. The result of the setting check is notified to the control unit 13.
  • the check processing unit 16 refers to the setting check information for each stage of each application and determines whether or not the value of the setting item described in the setting check information is a normal value. Determine whether the installation was successful. For example, the check processing unit 16 acquires server hardware information, and checks whether or not an application setting suitable for the hardware is set using the setting check information.
  • the check processing unit 16 determines whether the installation process can be performed again without performing recovery by the recovery processing unit 15. When a failure occurs, the check processing unit 16 is first notified from the installation processing unit 11 that the storage of the failure information has been completed. Then, the check processing unit 16 starts a system check.
  • the check processing unit 16 first determines whether or not recovery has already been performed after a failure occurs. When it is determined that recovery has already been performed after the occurrence of a failure, the check processing unit determines that recovery is not necessary.
  • the check processing unit 16 refers to the status information stored in the storage unit 12 by the installation processing unit 11 when the failure occurs, determines the content of the failure that has occurred, Determine if recovery is unnecessary. This is because, for example, in the case of an error in which the content of the failure is resolved with the passage of a predetermined time, the installation process may be able to be performed again without performing the recovery after that time has passed. .
  • the resumption time of the installation process may be a time when an error occurs.
  • the check processing unit 16 refers to the progress management table 20 to determine whether recovery is unnecessary. In the predetermined record of the progress management table 20, when the start flag 22 is set and the completion flag 23 is not set, the check processing unit 16 determines that a failure has occurred during the process, and recovery is necessary. It is determined that If the failure flag 25 is set in the predetermined record, the check processing unit 16 determines that the installation is not performed normally and determines that recovery is necessary. If the start flag 22, the completion flag 23, and the success flag 24 are set in a predetermined record, the check processing unit 16 determines that recovery is not necessary.
  • the check processing unit 16 determines that the recovery is necessary in the system check, the check processing unit 16 instructs the recovery processing unit 15 to execute the recovery process.
  • the final check will be described.
  • the check processing unit 16 acquires hardware information and refers to the setting check information or operation information to determine whether the driver, application, and unique setting to be installed are correctly performed. To check.
  • the check processing unit 16 checks whether the driver to be installed, the application, and the unique setting are correctly performed by confirming the result stored in the status storage unit and the application change information 30. . The final check is performed after all stages of stage 21 have been completed.
  • FIG. 9 shows an overall process flow diagram of the initial setting process in the present embodiment.
  • an installation target determination process is first performed (S101).
  • the installation target determination process is a process for determining an installation target application. Details of this processing will be described later.
  • the applications are installed in a predetermined order for the application determined in S101 (S102). Then, the control unit 13 determines whether or not installation of all applications among the applications determined in S101 has been completed (S103). If it is determined that all the installation target applications are not installed (No in S103), an application that has not been installed is installed in S102. When it is determined that all the installation target applications have been installed (Yes in S103), the initial setting process ends.
  • FIG. 10 shows an operation flow of installation target determination processing in the present embodiment.
  • the control unit 13 acquires server hardware information (S201). Specifically, the control unit 13 acquires information on the server body, that is, information on a CPU (Central Processing Unit), a memory, a device, an HDD (Hard Disk Drive), and the like.
  • server hardware information S201. Specifically, the control unit 13 acquires information on the server body, that is, information on a CPU (Central Processing Unit), a memory, a device, an HDD (Hard Disk Drive), and the like.
  • control unit 13 acquires server software information (S202). Specifically, the control unit 13 acquires information on software installed on the server, compares the information with application information corresponding to the server body, and acquires application information for installation.
  • the control unit 13 determines an application to be installed (S203). Specifically, the control unit 13 specifies an application to be installed from the hardware information acquired in S201 and the software information acquired in S202. The control unit 13 identifies an installable application from the hardware information acquired in S201 among the application information acquired in S202, and determines the application as an installation target application. When the application to be installed is determined, the control unit 13 creates a progress management table 20 for each application. At this time, the identification information 29 of the progress management table 20 is set with the identification information of the corresponding target application. Note that, when the progress management table 20 is created, the values of data items other than the stage 21 and the identification information 29 are not set. In the present embodiment, three records are created in which the values of each stage 21 are “driver installation”, “application installation”, and “unique setting”.
  • control unit 13 may determine an application to be installed and may determine the order of installation of the determined application in consideration of the dependency relationship between the applications.
  • the order of installation is determined, and the application change information 30 used in the entire installation process is also determined. .
  • FIG. 11 shows an operation flow of application installation processing in the present embodiment.
  • the driver is installed so as to satisfy the application installation requirements (S301).
  • the application is installed (S302), and the application specific setting according to the user environment is performed (S303).
  • a final check for confirming whether or not the application of the entire system has been correctly installed is performed by the check processing unit 16 (S304), and the installation of the application is completed.
  • the installation processing unit 11 detects the failure and stores the failure information in the storage unit 12 (S305). Then, an installation retry process is started (S306). The installation retry process will be described in detail later. When the retry process ends, the application installation process ends.
  • FIG. 12 is an operation flowchart of driver installation, application installation, or unique setting according to this embodiment.
  • the backup processing unit 14 performs backup processing.
  • the backup processing unit 14 identifies a backup target file and a registry key from the change information list 33 of the application change information 30 stored in the storage unit 12. Then, the backup processing unit 14 copies the backup target file and registry key information from the installation target disk area 41 to the predetermined save area as the application environment backup information 42 (S401).
  • control unit 13 performs processing for setting the start flag 22 of the progress management table 20 (S402). For example, the control unit 13 stores “true” in the start flag 22 of the record in which the value of the stage 21 matches the current processing stage.
  • the installation processing unit 11 performs driver installation when the processing stage is driver installation, performs application installation when the processing stage is application installation, and performs unique setting when the processing stage is unique setting. (S403).
  • the control unit 13 saves the status (S305), and the retry process is started (S306).
  • control unit 13 performs processing for setting the completion flag 23 of the progress management table 20 (S404). For example, the control unit 13 stores “true” in the completion flag 23 of the record in which the value of the stage 21 matches the current processing stage.
  • the check processing unit 16 performs a setting check for determining whether or not the process of S403 has been performed normally (S405).
  • the setting check when it is determined that the process of S403 is normally performed (YES in S405), the control unit 13 performs a process of setting the success flag 24 of the progress management table 20 (S406). For example, the control unit 13 stores “true” in the success flag 24 of the record in which the value of the stage 21 matches the current processing stage.
  • the control unit 13 When it is determined in the setting check in S405 that the process in S403 has not been performed normally (No in S405), the control unit 13 performs a process for setting the failure flag 25 in the progress management table 20 (S407). For example, the control unit 13 stores “true” in the failure flag 25 of the record in which the value of the stage 21 matches the current processing stage. Then, the process proceeds to the retry process of S306.
  • FIG. 13 shows an operation flow of retry processing in the present embodiment.
  • the check processing unit 16 performs a system check and determines whether or not a recovery process is necessary (S501).
  • the control unit 13 When it is determined that recovery is not necessary (YES in S501), the control unit 13 performs a driver check (S502). In the driver check, it is checked whether a driver installation process has already been performed when a failure occurs. The control unit 13 checks the success flag 24 (or completion flag 23) of the record whose stage 21 value in the progress management table 20 is “driver installation”, and determines whether or not the driver installation has been completed. If it is determined that the driver installation has been completed (Yes in S502), the process proceeds to S503. If it is determined that the driver installation has not been completed (No in S502), the process proceeds to S505.
  • the control unit 13 When it is determined in S502 that the driver installation has been completed, the control unit 13 performs an application check (S503). In the application check, it is checked whether an application installation process has already been performed when a failure occurs. The control unit 13 confirms the success flag 24 (or completion flag 23) of the record whose stage 21 value in the progress management table 20 is “application installation”, and determines whether or not the installation of the application has been completed. If it is determined that the installation of the application has been completed (Yes in S503), the process proceeds to S504. If it is determined that the application installation has not been completed (No in S503), the process proceeds to S506.
  • the control unit 13 performs a unique setting check (S504).
  • the unique setting check it is checked whether an application unique setting process has already been performed when a failure occurs.
  • the control unit 13 checks the success flag 24 (or completion flag 23) of the record whose stage 21 value in the progress management table 20 is “unique setting”, and determines whether or not the unique setting has been completed. If it is determined that the unique setting has been completed (Yes in S504), the process proceeds to S508. If it is determined that the unique setting has not been completed (No in S504), the process proceeds to S507.
  • the installation processing unit 11 performs driver installation. Then, the installation processing unit 11 installs an application (S506). Next, the installation processing unit 11 performs unique settings (S507).
  • the check processing unit 16 performs a final check (S508).
  • the check processing unit 16 confirms whether the driver, application, and unique setting to be installed are correctly performed.
  • the specific processes of S505, S506, S507, and S508 are the same as those of S301, S302, S303, and S304, respectively.
  • FIG. 14 shows an operation flow of recovery processing in the present embodiment.
  • the control unit 13 restarts the system (S601).
  • the control unit 13 specifies to which stage 21 the process has been completed when the failure occurs, and the recovery processing unit 15 performs the recovery process (S602).
  • the control unit 13 restarts the system again (S603).
  • the process transitions to a retry process (S306).
  • FIG. 15 shows an example of the hardware configuration of the information processing apparatus 1 according to the present embodiment.
  • the server includes a CPU 201, a memory 202, a storage device 203, a reading unit 204, a removable recording medium 205, a communication interface 206, and an input / output unit 207.
  • the CPU 201, the memory 202, the storage device 203, the reading unit 204, the communication interface 206, and the input / output unit 207 are connected to each other via a bus 209, for example.
  • a CPU (Central Processing Unit) 201 uses the memory 202 to execute a program describing the above-described flowchart procedure.
  • the CPU 201 provides some or all of the functions of the installation processing unit 11, the control unit 13, the backup processing unit 14, the recovery processing unit 15, and the check processing unit 16.
  • the memory 202 is, for example, a semiconductor memory, and includes a RAM (Random Access Memory) area and a ROM (Read Only Memory) area.
  • the memory 202 provides a part or all of the functions of the storage unit 12.
  • the storage device 203 is a hard disk, for example, and provides a part or all of the functions of the storage unit 12. Note that the storage device 203 may be a semiconductor memory such as a flash memory. Further, the storage device 203 may be an external recording device.
  • the reading unit 204 accesses the removable recording medium 205 in accordance with an instruction from the CPU 201.
  • the detachable recording medium 205 is, for example, a semiconductor device (USB memory or the like), a medium (such as a magnetic disk) to which information is input / output by a magnetic action, or a medium (CD-ROM, For example, a DVD).
  • the communication interface 206 transmits / receives data via a network according to instructions from the CPU 201.
  • the input / output unit 207 corresponds to, for example, a device that receives an instruction from the user.
  • An information processing program for realizing the embodiment is provided to the server in the following form, for example. (1) Installed in advance in the storage device 203. (2) Provided by the removable recording medium 205. (3) Provided via a network.
  • the server may include various devices.
  • Such devices include, for example, a Local Area Network controller and a Video Graphics Array controller.
  • this embodiment is not limited to the embodiment described above, and can take various configurations or embodiments without departing from the gist of the present embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Retry When Errors Occur (AREA)
  • Stored Programmes (AREA)

Abstract

 ソフトウェアのインストール処理において障害が発生した場合に、処理の再開までに要する時間を削減する。記憶部に記憶された、ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を用いて、前記変更対象ファイルを取得して保存し、前記インストールを実行し、前記インストールの途中で発生した障害を検出し、前記インストールの進捗状況を示す進捗情報を取得し、前記障害が検出された場合、前記進捗情報に基いて、前記障害が発生した時の前記所定の処理を障害時処理として特定し、前記障害時処理において変更されたファイルを、保存された前記変更対象ファイルを用いて復元し、前記障害時処理の開始時点から前記インストールを再開する。

Description

情報処理装置、情報処理方法、及び情報処理プログラム
 本発明は、ソフトウェアのインストールにおける障害発生時の処理に関する。
 オペレーティングシステム(以下、OSと記す)がプレインストールされているサーバの初期設定処理は、初回の電源投入時に自動で行われる。図1は、サーバの初期設定処理の動作フローを示す。初期設定処理では、まずアプリケーションに対応するドライバのインストールが行われる(S1001)。そして、アプリケーションのインストールが行われ(S1002)、ユーザの環境に応じたアプリケーションの固有設定が行われる(S1003)。そして、アプリケーションが正しくインストールされたか否かを確認する最終チェックが行われる(S1004)。この初期設定処理中にハードウェア故障、ソフトウェアエラー、電源切断等が発生し、処理が予期せず途中で失敗した場合(S1005)、どの処理まで正しく行われたかを記録していないため処理を途中から再開することができない。この場合、ユーザはOSのインストール(リカバリ)から再度行わなければならず(S1006)、そのリカバリには多大な時間がかかる。
 一方、複数のソフトウェアのインストールが完了するまでの時間を削減するための第1の技術がある。この第1の技術は、複数のソフトウェアのインストールをコンピュータに連続して実行させることを前提とする。そして、この第1の技術は、OSが再起動した時に自己プログラムが自動的に起動されるように設定する機能をコンピュータに実現させる。さらに、第1の技術は、上記自己プログラムが起動した時に、上記複数のソフトウェアのインストールにおける進捗状況を把握し、上記複数のソフトウェアのインストールを未実行または異常終了の位置から再開する機能をコンピュータに実現させる。
 また、OSの再起動を高速に行う第2の技術がある。この技術は、主記憶装置上のOSの初期化データを初期化データ退避領域に退避するためのデータ退避手段と、情報処理装置に接続された入出力装置の停止制御を行う入出力装置制御手段と、を備える。さらに、第2の技術は、再起動の可否を指定し、OSプログラムの特定番地に制御を移す再起動制御手段と、データ退避領域から初期化データを回復するためのデータ回復手段と、を備える。
特開2004-302929号公報 特開平11-24936号公報
 しかしながら、第1の技術では、停電による予期せぬ電源断が起こった際に、正しいエラー処理が行われないため処理状況が記録できない。そのため再度処理を行う際にはインストール未実施の処理として最初からインストールが再開される。
 さらには、第1及び第2の技術では、既に途中までインストール処理が進行した状態で処理が再開されることになる。この場合、処理途中のファイルが残存しているため、インストールを再開できない場合や再会できたとしてもインストールを正しく完了することを保証できない。そのため、問題発生後に初期セットアップを継続する場合、手作業でどの処理まで実施されたかを確認しなければならず、作業が煩雑になり、時間がかかる。
 また、第2の技術では、1度目の実行で障害が発生するまでの時間分の処理時間がかかる。
 そこで、1つの側面では、本発明は、ソフトウェアのインストール処理において障害が発生した場合に、処理の再開までに要する時間を削減することを目的とする。
 一態様の情報処理装置は、記憶部、保存処理部、処理部、検出部、進捗管理部、復元部、及び制御部を含む。記憶部は、ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を記憶する。保存処理部は、記憶部に記憶された変更対象ファイルの所在及びファイル名を用いて、変更対象ファイルを取得して保存する。処理部は、インストールを実行する。検出部は、インストールの途中で発生した障害を検出する。進捗管理部は、インストールの進捗状況を示す進捗情報を取得し、障害が検出された場合、進捗情報に基いて、障害が発生した時の所定の処理を障害時処理として特定する。復元部は、障害時処理において変更されたファイルを、該ファイルに対応する保存された変更対象ファイルを用いて復元する。制御部は、障害時処理の開始時点からインストールを再開する。
 本実施形態に係る情報処理システムによれば、ソフトウェアのインストール処理において障害が発生した場合に、処理の再開までに要する時間を削減することができる。
サーバの初期設定処理の動作フローを示す。 本実施形態に係る情報処理装置の機能ブロック図の一例を示す。 本実施形態に係る情報処理装置の構成の一例を示す。 本実施形態に係る進捗管理テーブルの一例を示す。 本実施形態に係るアプリ変更情報の一例を示す。 バックアップ処理部によりファイルがバックアップされる様子を説明するための図である。 アプリ変更情報の追加情報一覧に記載されているファイル名のファイルを削除する様子を説明するための図である。 アプリ環境バックアップ情報からインストール対象ファイルを書き戻す様子を説明するための図である。 本実施形態における初期化処理の全体の処理フローを示す。 本実施形態におけるインストール対象決定処理の動作フローを示す。 本実施形態におけるアプリケーションインストール処理の動作フローを示す。 本実施形態におけるドライバのインストール、アプリケーションのインストール、固有設定の動作フローを示す。 本実施形態におけるリトライ処理の動作フローを示す。 本実施形態におけるリカバリ処理の動作フローを示す。 本実施形態に係る情報処理装置のハードウェア構成の一例を示す。
 図1は、本実施形態に係る情報処理装置の機能ブロック図の一例である。情報処理装置1は、記憶部2、保存処理部3、処理部4、検出部5、進捗管理部6、復元部7、及び制御部8を含む。
 記憶部2は、ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を記憶する。また、記憶部2は、所定の処理において追加される追加対象ファイルの所在及びファイル名を記憶する。また、記憶部2は、所定の処理が正常に終了した場合の正常状態情報を記憶する。
 保存処理部3は、記憶部に記憶された変更対象ファイルの所在及びファイル名を用いて、変更対象ファイルを取得して保存する。
 処理部4は、インストールを実行する。
 検出部5は、インストールの途中で発生した障害を検出する。また、検出部5は、障害を検出するとともに障害の内容を示す障害情報を収集する。
 進捗管理部6は、インストールの進捗状況を示す進捗情報を取得し、障害が検出された場合、進捗情報に基いて、障害が発生した時の所定の処理を障害時処理として特定する。また、進捗管理部6は、所定の処理の前後に、進捗情報を取得する。また、進捗管理部6は、正常状態情報に基いて所定の処理が正常に終了したか否かを判定し、所定の処理が正常に終了していないと判定した場合、所定の処理を障害時処理として特定する。また、進捗管理部6は、障害情報、進捗情報、または上記判定の結果に基いて、障害時処理が再開可能か否かを判定する。
 復元部7は、障害時処理において変更されたファイルを、該ファイルに対応する保存された変更対象ファイルを用いて復元する。また、復元部7は、障害時処理において追加されたファイルを、記憶部に記憶された追加対象ファイルの所在及びファイル名に基いて削除する。また、復元部7は、進捗管理部により障害時処理が再開可能でないと判定された場合、障害時処理において変更されたファイルを、保存された変更対象ファイルを用いて復元する。
 制御部8は、障害時処理の開始時点からインストールを再開する。
 図3は、本実施形態に係る情報処理装置の構成の一例を示す。本実施形態に係る情報処理装置1は、例えばサーバであり、インストール処理部11、記憶部12、制御部13、バックアップ処理部14、リカバリ処理部15、及びチェック処理部16を含む。
 インストール処理部11は、処理部4、検出部5の一例である。記憶部12は、記憶部2の一例である。制御部13は、進捗管理部6、制御部8の一例である。バックアップ処理部14は、保存処理部3の一例である。リカバリ処理部15は、復元部7の一例である。チェック処理部16は、進捗管理部6の一例である。
 インストール処理部11は、アプリケーションのインストール、そのアプリケーションのインストールに必要なドライバのインストール、及びユーザ環境に応じたアプリケーションの固有設定を行う。
 また、インストール処理部11は、インストール処理中に発生した障害を検出し、障害が発生したことを制御部13に通知する。またその際、インストール処理部11は、障害の内容及び障害発生時のシステムの状態を示す情報である障害情報を記憶部12に格納し、障害情報の格納が終了したら、チェック処理部16に障害情報の格納が終了したことを通知する。
 さらに、インストール処理部11は、インストール処理のログ等の動作情報を記憶部12に格納する。
 記憶部12は、インストール処理の進捗状況を把握するための情報である進捗管理テーブル、各アプリケーションが追加・変更する情報の一覧の情報であるアプリ変更情報、及び、インストールが正常に行われたか否かを判定するための設定チェック情報を記憶する。また、記憶部12には、障害発生時に障害情報が保存される領域、バックアップ処理部14によりバックアップ対象のファイルが保存される領域、及び、インストール処理の動作情報が格納される領域が確保される。尚、記憶部12には、インストールされるドライバ及びアプリケーションに関するファイルも格納される。
 先ず、進捗管理テーブルについて説明する。進捗管理テーブルは、アプリケーション毎のインストール処理の進行状況を把握するために用いられる情報である。進捗管理テーブルは、インストール対象のアプリケーション毎に、各々のアプリケーションに対応付けて作成される。図4は、本実施形態に係る進捗管理テーブルの一例を示す。進捗管理テーブル20は、ステージ21、開始フラグ22、完了フラグ23、成功フラグ24、失敗フラグ25、及び識別情報29のデータ項目を有する。
 ステージ21は、1つのアプリケーションのインストールにおける処理の段階を示している。本実施形態においては、アプリケーションのインストールは、処理の内容に基づいて3つの段階に分けられる。3つの段階とはすなわち、ドライバインストール、アプリケーションインストール、固有設定である。ドライバインストールは、アプリケーションをインストールするためのシステム要件であるようなドライバのインストールが行われる段階である。アプリケーションインストールは、アプリケーションそのもののインストールが行われる段階である。固有設定は、アプリケーションのインストール後にユーザの環境に応じて設定項目が設定される段階である。尚、ステージ21で示す段階は3つに限定されず、例えば、ドライバインストール前の設定段階等を設けてもよい。
 開始フラグ22は、ステージ21の処理が開始されたことを示すフラグである。開始フラグ22は、ステージ21の処理の開始直前に制御部13により設定される。
 完了フラグ23は、ステージ21の処理が完了したことを示すフラグである。完了フラグ23は、ステージ21の処理の完了直後に制御部13により設定される。
 成功フラグ24は、ステージ21の処理が正常に完了したことを示すフラグである。成功フラグ24は、ステージ21の処理が正常に完了したと判定された場合に制御部13により設定される。ここで、ステージ21の処理の終了後に行われる、ステージ21の処理が正常に完了したか否かの判定処理を設定チェックと記す。設定チェックの詳細は後ほど説明する。
 失敗フラグ25は、ステージ21の処理が正常に完了していないことを示すフラグである。失敗フラグ25は、ステージ21の処理が正常に行われていないと判定された場合に制御部13により設定される。
 識別情報29は、進捗管理テーブル20がどのインストール対象アプリケーションと対応付けられているかを示す情報である。
 次に、アプリ変更情報について説明する。アプリ変更情報は、各アプリケーションのインストールの処理段階ごとに作成され、各々の処理において追加・変更される情報の一覧である。すなわち、アプリ変更情報は、インストール対象のアプリケーション毎に管理され、さらに、ステージ21の段階毎に管理される。
 図5は、本実施形態に係るアプリ変更情報の一例を示す。アプリ変更情報30は、対応処理情報31、追加情報一覧32、及び変更情報一覧33を含む。
 対応処理情報31は、アプリ変更情報30がどのアプリケーションのインストールにおけるどのステージ21の処理に対応するかを示す情報である。以下の説明では、対応処理情報31が指し示すステージ21の処理を対象処理と記す。
 追加情報一覧32は、対象処理が実行されることによって追加される情報の一覧である。追加情報一覧32は、追加ファイル一覧34と追加レジストリキー一覧35を含む。追加ファイル一覧34は、対象処理において追加されるファイル(フォルダまたはディレクトリを含む)の名称の一覧である。この名称は、ファイルの所在情報を含むフルパスで表される。追加レジストリキー一覧35は、対象処理において追加されるレジストリキーの名称の一覧である。尚、レジストリの存在しないUnix(登録商標)等のOSにおいては、追加レジストリキー一覧35は省略できる。
 変更情報一覧33は、対象処理が実行されることによって変更される情報の一覧である。変更情報一覧33は、変更ファイル一覧36と変更レジストリキー一覧37を含む。変更ファイル一覧36は、対象処理において変更されるファイル(フォルダまたはディレクトリを含む)の名称の一覧である。この名称は、ファイルの所在情報を含むフルパスで表される。変更レジストリキー一覧37は、対象処理において変更されるレジストリキーの名称の一覧である。尚、レジストリの存在しないUnix(登録商標)等のOSにおいては、変更レジストリキー一覧37は省略できる。
 次に、設定チェック情報について説明する。設定チェック情報は、インストール対象アプリケーション毎のステージ21のそれぞれにおいて、処理が正常に行われたか否かを判定するために用いられる情報である。設定チェック情報には、例えば、処理が正常に終了した場合に設定されているべき設定項目とその値が記載されている。
 尚、アプリ変更情報30、設定チェック情報は、予めサーバに格納されているものとする。
 制御部13は、インストール処理の進捗状況を管理する。そのために、制御部13は、インストール処理における各処理の定められた時点において進捗状況のステータスを保存する処理を行う。さらに、制御部13は、インストール処理の途中で障害が発生した場合に、障害が発生した時点においてどのステージ21まで処理が完了していたかを特定する処理を行う。
 先ず、インストール処理における各処理の定められた時点において、制御部13が進捗状況のステータスを保存する処理の例を説明する。制御部13は、各ステージ21の処理の開始時点において開始フラグ22を設定する。また、制御部13は、各ステージ21の処理の完了時点において完了フラグ23を設定する。完了フラグ23の設定後、制御部13は、チェック処理部16に対して設定チェックの実行指示を行う。さらに、制御部13は、ステージ21の設定チェックの結果、ステージ21の処理が正常に行われたと判定された場合に成功フラグ24を設定する。そして、制御部13は、設定チェックの結果、ステージ21の処理が正常に行われていないと判定された場合に失敗フラグ25を設定する。
 次に、インストール処理の途中で障害が発生した場合に、障害が発生した時点においてどのステージ21まで処理が完了していたかを制御部13が特定する例を説明する。障害が発生すると制御部13は、インストール処理部11から障害が発生したことを通知される。すると、制御部13は、進捗管理テーブル20を参照することにより障害発生時までに完了していた処理を特定する。
 例えば、障害発生時の進捗管理テーブル20の状態が図4に示すものであった場合を考える。制御部13は、進捗管理テーブル20の識別情報29の値を参照することにより、どのアプリケーションのインストール処理中に障害が発生したかを特定することができる。図4の例の場合、識別情報29には「アプリケーションA」が設定されているので、制御部13は、障害が発生したときにはアプリケーションAのインストール処理が行われていたと判定する。そして、ステージ21の値が「ドライバインストール」であるレコード(行)の成功フラグ24の値が「true」に設定されていることを確認することにより、制御部13はドライバのインストールは正常に完了した状態であることを判別できる。そして、制御部13はステージ21の値が「アプリケーションインストール」であるレコードの開始フラグ22の値が「true」に設定されていることを確認することにより、障害が発生したのはアプリケーションインストールの処理開始後であると判別できる。さらに、制御部13は「アプリケーションインストール」であるレコードの完了フラグ23の値が設定されていないことを確認することにより、障害が発生したのはアプリケーションのインストールの完了前であることを判別できる。
 制御部13は、障害が発生した時点においてどのステージ21まで処理が完了していたかを特定したら、その特定した時点の直後の処理の開始時点からインストールを再開するように、インストール処理部11に指示する。
 バックアップ処理部14は、ステージ21の各段階の処理の開始前に、その段階の処理により変更されるファイルをバックアップする。バックアップ対象となるファイルは、バックアップ処理部14が、次に実行される段階の処理に対応処理情報31の値が一致するアプリ変更情報30を検索し、そのアプリ変更情報30の変更情報一覧33を参照することによって特定する。
 図6は、バックアップ処理部14によりファイルがバックアップされる様子を説明するための図である。先ず、バックアップ処理部14は、変更情報一覧33の変更ファイル一覧36を参照して、バックアップ対象ファイルを認識する。また、バックアップ処理部14は、変更情報一覧33の変更レジストリキー一覧37を参照して、バックアップ対象のレジストリキーを認識する(S61)。次に、バックアップ処理部14は、認識したバックアップ対象ファイルを所定の退避領域にコピーする。また、バックアップ処理部14は、認識したバックアップ対象のレジストリキーの値を、レジストリキーの名称と対応付けて、所定の退避領域に格納する。ここでバックアップしたファイル情報とレジストリキー情報をアプリ環境バックアップ情報42と記す。
 リカバリ処理部15は、インストールの途中で障害が発生した場合、インストール対象のアプリケーションの再インストールを行う前に、サーバを各ステージ21の開始前の環境に復旧させる。これにより、前回インストールした際に残っているファイルやレジストリ情報などの影響により、再インストールが失敗することを防ぐ。
 具体的には、リカバリ処理部15は、障害が発生した際に、最後にバックアップ処理部14がバックアップを行った時点にサーバの環境を戻す。バックアップ処理部14はステージ21の処理ごとにバックアップを取得することから、最後にバックアップを行った時点とはすなわち、障害が発生した際のステージ21の処理開始直前の時点である。
 障害が発生すると、リカバリ処理部15は、チェック処理部16からリカバリの実行命令を受け取る。すると、リカバリ処理部15は、障害がどのアプリケーションのどの段階の処理の実行中に発生したかの情報を制御部13から取得する。以下の説明では、障害が発生したときのアプリケーションの処理段階を障害発生時処理と記す。尚、障害が発生してもチェック処理部16からリカバリの実行命令を受けない場合は、リカバリ処理部15は、リカバリ処理は行わない。これは、詳しくは後ほど説明するが、発生した障害が、リカバリを行わなくてもいいと判断されるような内容の障害である場合には、リカバリを実行せずにインストール処理を再開できるようにするためである。
 リカバリ処理部15は、対応処理情報31の値が障害発生時処理を示すアプリ変更情報30を特定する。そして、リカバリ処理部15は、特定したアプリ変更情報30の追加情報一覧32を参照し、障害発生時処理において追加された可能性のあるファイルを削除する。
 図7は、アプリ変更情報30の追加情報一覧32に記載されているファイル名のファイルを削除する様子を説明するための図である。リカバリ処理部15は、追加情報一覧32の追加ファイル一覧34を参照し、削除対象ファイルを認識する。また、リカバリ処理部15は、追加情報一覧32の追加レジストリキー一覧35を参照し、削除対象のレジストリキーを認識する(S71)。リカバリ処理部15は、S71で認識した削除対象ファイルを、インストール対象ディスク領域41から全て削除する。また、リカバリ処理部15は、S71で認識した削除対象のレジストリキーの値をすべて削除する(S72)。
 次にリカバリ処理部15は、特定したアプリ変更情報30の変更情報一覧33に記載されている対象ファイルまたはレジストリキーをアプリ環境バックアップ情報42から書き戻す。
 図8は、アプリ環境バックアップ情報42からインストール対象ファイルを書き戻す様子を説明するための図である。リカバリ処理部15は、変更情報一覧33の変更ファイル一覧36を参照し、書き戻し対象ファイルを認識する。また、リカバリ処理部15は、変更情報一覧33の変更レジストリキー一覧37を参照し、書き戻し対象のレジストリキーを認識する(S81)。リカバリ処理部15は、S81で認識した書き戻し対象ファイルをアプリ環境バックアップ情報42からインストール対象ディスク領域41にコピーする。また、リカバリ処理部15は、S81で認識した書き戻し対象のレジストリキーとその値を、アプリ環境バックアップ情報42を参照して、レジストリに登録する(S82)。
 チェック処理部16は、設定チェック、システムチェック、最終チェックを行う。
 設定チェックでは、チェック処理部16は、アプリケーションが正常にインストールされたか否かを判定する。設定チェックは、チェック処理部16がステージ21の処理終了後に制御部13から設定チェックの実行指示を受信した場合に開始される。設定チェックの結果は制御部13に通知される。
 具体的には、チェック処理部16は、各アプリケーションのステージ毎の設定チェック情報を参照し、設定チェック情報に記載された設定項目の値が正常な値か否かを判定することにより、アプリケーションが正常にインストールされたか否かを判定する。例えば、チェック処理部16は、サーバのハードウェアの情報を取得し、そのハードウェアに合ったアプリケーションの設定になっているか否かを、設定チェック情報を用いてチェックする。
 次に、システムチェックについて説明する。システムチェックでは、チェック処理部16は、インストール処理中に障害が発生した場合に、リカバリ処理部15によるリカバリを行わずに再度インストール処理を行うことができるか否かを判定する。障害が発生すると、チェック処理部16は、先ず、インストール処理部11から障害情報の格納が終了したことを通知される。すると、チェック処理部16は、システムチェックを開始する。
 具体的には、チェック処理部16は、先ず、障害発生後既にリカバリ済みか否かを判定する。障害発生後既にリカバリ済みと判定した場合は、チェック処理部は、リカバリ不要であると判定する。
 障害発生後リカバリ未実施であると判定した場合、チェック処理部16は、障害発生時にインストール処理部11により記憶部12に保存されたステータス情報を参照し、発生した障害の内容を判定して、リカバリが不要か否かを判定する。これは、例えば、障害の内容が所定の時間の経過により解消するようなエラーの場合は、その時間が経過すれば、リカバリを行わずに再度インストール処理を行うことができる場合があるからである。ここで、障害の内容によっては、インストール処理の再開時点は、エラーが発生した時点としてもよい。
 障害の内容からリカバリ不要ではないと判定した場合、チェック処理部16は、進捗管理テーブル20を参照してリカバリ不要か否かを判定する。進捗管理テーブル20の所定のレコードにおいて、開始フラグ22が設定されていて、完了フラグ23が設定されていない場合は、チェック処理部16は、処理途中で障害が発生したと判定し、リカバリが必要であると判定する。また、所定のレコードに失敗フラグ25が設定されている場合は、チェック処理部16はインストールが正常に行われていないと判定し、リカバリが必要であると判定する。また、所定のレコードにおいて、開始フラグ22、完了フラグ23、及び成功フラグ24が設定されている場合は、チェック処理部16はリカバリ不要であると判定する。
 チェック処理部16は、システムチェックにおいてリカバリが必要であると判定した場合、リカバリ処理部15にリカバリ処理の実行を指示する。
 次に、最終チェックについて説明する。最終チェックでは、チェック処理部16は、例えば、ハードウェア情報を取得し、設定チェック情報または動作情報を参照することにより、インストールされるべきドライバ、アプリケーション、固有設定が正しく行われているか否かをチェックする。また、チェック処理部16は、ステータス保存部に保存している結果の確認とアプリ変更情報30を確認することによって、インストールされるべきドライバ、アプリケーション、固有設定が正しく行われているかのチェックを行う。最終チェックは、ステージ21のすべての段階が終了した後に実行される。
 次に、本実施形態の動作フローを説明する。OSインストール完了後の初期設定処理では、複数のアプリケーションがインストールされる。図9に本実施形態における初期設定処理の全体の処理フロー図を示す。
 初期設定処理では、先ずインストール対象決定処理が行われる(S101)。インストール対象決定処理は、インストール対象のアプリケーションを決定するための処理である。この処理の詳細は後ほど説明する。
 次に、S101で決定されたアプリケーションを対象として所定の順番でアプリケーションのインストールが行われる(S102)。そして、制御部13は、S101で決定されたアプリケーションのうちすべてのアプリケーションのインストールが終了したか否かを判定する(S103)。すべてのインストール対象アプリケーションがインストールされていないと判定された場合は(S103でNo)、S102においてインストール未実施のアプリケーションのインストールが行われる。すべてのインストール対象アプリケーションがインストールされたと判定された場合は(S103でYes)、初期設定処理は終了する。
 次にインストール対象決定処理の詳細を説明する。図10は、本実施形態におけるインストール対象決定処理の動作フローを示す。
 先ず、制御部13は、サーバのハードウェアの情報取得を行う(S201)。具体的には、制御部13は、サーバ本体の情報、すなわち、CPU(Central Processing Unit)、メモリ、デバイス、HDD(Hard Disk Drive)等の情報を取得する。
 次に、制御部13は、サーバのソフトウェアの情報取得を行う(S202)。具体的には、制御部13は、サーバにインストールされているソフトウェアの情報を取得し、その情報とサーバ本体に対応するアプリケーション情報とを比較してインストールを行うアプリケーション情報を取得する。
 次に、制御部13は、インストール対象のアプリケーションを決定する(S203)。具体的には、制御部13は、S201で取得したハードウェア情報とS202で取得したソフトウェア情報とからインストール対象のアプリケーションを特定する。制御部13は、S202で取得したアプリケーション情報のうち、S201で取得したハードウェア情報からインストール可能なアプリケーションを特定し、そのアプリケーションをインストール対象のアプリケーションと決定する。インストール対象のアプリケーションが決定された段階で、制御部13は、アプリケーション毎の進捗管理テーブル20を作成する。そのとき、進捗管理テーブル20の識別情報29には、対応する対象アプリケーションの識別情報を設定する。尚、進捗管理テーブル20は、作成時には、ステージ21及び識別情報29以外のデータ項目の値は未設定の状態とする。本実施形態では、各々のステージ21の値が「ドライバインストール」、「アプリケーションインストール」、「固有設定」である3つのレコードが作成される。
 尚、制御部13は、インストール対象のアプリケーションを決定するとともに、決定したアプリケーションのインストールの順序を、各アプリケーション間の依存関係などを考慮して決定してもよい。また、各アプリケーションのそれぞれの処理のステージ21は、アプリ変更情報30と対応付けられているので、インストールの順序が決定されるとともに、インストール処理全体で使用されるアプリ変更情報30も決まることとなる。
 次に、S203で決定された個々のアプリケーションのインストール処理(S102)の詳細について説明する。図11は、本実施形態におけるアプリケーションインストール処理の動作フローを示す。
 先ず、アプリケーションのインストール要件となるようなドライバのインストールが行われる(S301)。そして、アプリケーションのインストールが行われ(S302)、ユーザの環境に応じたアプリケーションの固有設定が行われる(S303)。そして、最後にシステム全体のアプリケーションが正しくインストールされたか否かを確認する最終チェックがチェック処理部16により行われ(S304)、アプリケーションのインストールが終了する。
 S301~S303において、障害が発生した場合、インストール処理部11は障害を検出し、障害情報を記憶部12に保存する(S305)。そして、インストールのリトライ処理が開始される(S306)。インストールのリトライ処理については、後ほど詳細に説明する。リトライ処理が終了するとアプリケーションのインストール処理が終了する。
 次に、ドライバのインストール(S301)、アプリケーションのインストール(S302)、アプリケーション固有の設定(S303)の処理の詳細を説明する。図12は、本実施形態におけるドライバのインストール、アプリケーションのインストール、または固有設定の動作フロー図である。
 先ず、バックアップ処理部14は、バックアップ処理を行う。バックアップ処理部14は、記憶部12に格納されているアプリ変更情報30の変更情報一覧33からバックアップ対象のファイル及びレジストリキーを特定する。そして、バックアップ処理部14はバックアップ対象のファイル及びレジストリキーの情報をインストール対象ディスク領域41から所定の退避領域にアプリ環境バックアップ情報42としてコピーする(S401)。
 次に、制御部13は、進捗管理テーブル20の開始フラグ22を設定する処理を行う(S402)。例えば、制御部13は、ステージ21の値が現在の処理段階に一致するレコードの開始フラグ22に、「true」を格納する。
 次に、インストール処理部11は、処理段階がドライバのインストールの場合は、ドライバのインストールを、処理段階がアプリケーションのインストールの場合はアプリケーションのインストールを、処理段階が固有設定の場合は固有設定を行う(S403)。尚、図11において説明したように、S403の処理中に障害が発生した場合、制御部13は、ステータス保存を行い(S305)、リトライ処理が開始される(S306)。
 次に、制御部13は、進捗管理テーブル20の完了フラグ23を設定する処理を行う(S404)。例えば、制御部13は、ステージ21の値が現在の処理段階に一致するレコードの完了フラグ23に「true」を格納する。
 次に、チェック処理部16は、S403の処理が正常に行われたか否かを判定する設定チェックを行う(S405)。設定チェックにおいて、S403の処理が正常に行われたと判定された場合(S405でYES)、制御部13は、進捗管理テーブル20の成功フラグ24を設定する処理を行う(S406)。例えば、制御部13は、ステージ21の値が現在の処理段階に一致するレコードの成功フラグ24に「true」を格納する。
 S405の設定チェックにおいてS403の処理が正常に行われなかったと判定された場合(S405でNo)、制御部13は、進捗管理テーブル20の失敗フラグ25を設定する処理を行う(S407)。例えば、制御部13は、ステージ21の値が現在の処理段階に一致するレコードの失敗フラグ25に「true」を格納する。そして、処理はS306のリトライ処理に移る。
 次に、リトライ処理(S306)について詳細に説明する。図13は、本実施形態におけるリトライ処理の動作フローを示す。
 先ず、チェック処理部16はシステムチェックを行い、リカバリ処理が不要か否かを判定する(S501)。
 リカバリ不要と判定された場合(S501でYES)、制御部13はドライバチェックを行う(S502)。ドライバチェックにおいては、障害発生時にドライバのインストール処理が既に行われていたか否かがチェックされる。制御部13は、進捗管理テーブル20のステージ21の値が「ドライバインストール」であるレコードの成功フラグ24(または完了フラグ23)を確認し、ドライバのインストールが完了していたか否かを判定する。ドライバのインストールが完了していたと判定されると(S502でYes)、処理はS503に遷移する。ドライバのインストールが終了していなかったと判定されると(S502でNo)、処理はS505に遷移する。
 S502においてドライバのインストールが完了していたと判定された場合、制御部13はアプリチェックを行う(S503)。アプリチェックにおいては、障害発生時にアプリケーションのインストール処理が既に行われていたか否かがチェックされる。制御部13は、進捗管理テーブル20のステージ21の値が「アプリケーションインストール」であるレコードの成功フラグ24(または完了フラグ23)を確認し、アプリケーションのインストールが完了していたか否かを判定する。アプリケーションのインストールが完了していたと判定されると(S503でYes)、処理はS504に遷移する。アプリケーションのインストールが終了していなかったと判定されると(S503でNo)、処理はS506に遷移する。
 S503においてアプリケーションのインストールが正常に終了していたと判定された場合、制御部13は、固有設定チェックを行う(S504)。固有設定チェックにおいては、障害発生時にアプリケーションの固有設定処理が既に行われていたか否かがチェックされる。制御部13は、進捗管理テーブル20のステージ21の値が「固有設定」であるレコードの成功フラグ24(または完了フラグ23)を確認し、固有設定が完了していたか否かを判定する。固有設定が完了していたと判定すると(S504でYes)、処理はS508に遷移する。固有設定が終了していなかったと判定すると(S504でNo)、処理はS507に遷移する。
 S505において、インストール処理部11はドライバインストールを行う。そして、インストール処理部11は、アプリケーションのインストールを行う(S506)。次に、インストール処理部11は固有設定を行う(S507)。
 そして、チェック処理部16は最終チェックを行う(S508)。チェック処理部16は、インストールされるべきドライバ、アプリケーション、固有設定が正しく行われているか否かを確認する。尚、S505、S506、S507、S508のそれぞれの具体的な処理は、S301、S302、S303、S304のそれぞれと同様である。
 S501において、リカバリが必要であると判定された場合(S501でNo)、リカバリ処理が開始される(S509)。
 次に、リカバリ処理(S509)について詳細に説明する。図14は、本実施形態におけるリカバリ処理の動作フローを示す。
 先ず、制御部13は、システムの再起動を行う(S601)。再起動が終了したら、制御部13は、障害が発生した時点においてどのステージ21まで処理が完了していたかを特定し、リカバリ処理部15は、リカバリ処理を行う(S602)。そして、制御部13は、再度システムの再起動を行う(S603)。そして、処理は、リトライ処理(S306)に遷移する。
 図15は、本実施形態に係る情報処理装置1のハードウェア構成の一例を示す。サーバは、図15に示すように、CPU201、メモリ202、記憶装置203、読取部204、着脱可能記録媒体205、通信インターフェース206、入出力部207を含む。なお、CPU201、メモリ202、記憶装置203、読取部204、通信インターフェース206、及び入出力部207は、例えば、バス209を介して互いに接続されている。
 CPU(Central Processing Unit)201は、メモリ202を利用して上述のフローチャートの手順を記述したプログラムを実行する。CPU201は、インストール処理部11、制御部13、バックアップ処理部14、リカバリ処理部15、チェック処理部16の一部または全部の機能を提供する。
 メモリ202は、例えば半導体メモリであり、RAM(Random Access Memory)領域およびROM(Read Only Memory)領域を含んで構成される。メモリ202は、記憶部12の一部または全部の機能を提供する。
 記憶装置203は、例えばハードディスクであり、記憶部12の機能の一部または全部の機能を提供する。なお、記憶装置203は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置203は、外部記録装置であってもよい。
 読取部204は、CPU201の指示に従って着脱可能記録媒体205にアクセスする。着脱可能記録媒体205は、たとえば、半導体デバイス(USBメモリ等)、磁気的作用により情報が入出力される媒体(磁気ディスク等)、光学的作用により情報が入出力される媒体(CD-ROM、DVD等)などにより実現される。
 通信インターフェース206は、CPU201の指示に従ってネットワークを介してデータを送受信する。
 入出力部207は、例えば、ユーザからの指示を受け付けるデバイスに相当する。
 実施形態を実現するための情報処理プログラムは、例えば、下記の形態でサーバに提供される。
(1)記憶装置203に予めインストールされている。
(2)着脱可能記録媒体205により提供される。
(3)ネットワークを介して提供される。
 尚、サーバは、種々のデバイスを含む構成としてもよい。そのようなデバイスには、例えば、Local Area NetworkコントローラやVideo Graphics Arrayコントローラがある。
 尚、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
 1   情報処理装置
 2   記憶部
 3   保存処理部
 4   処理部
 5   検出部
 6   進捗管理部
 7   復元部
 8   制御部
 11  インストール処理部
 12  記憶部
 13  制御部
 14  バックアップ処理部
 15  リカバリ処理部
 16  チェック処理部
 20  進捗管理テーブル
 21  ステージ
 22  開始フラグ
 23  完了フラグ
 24  成功フラグ
 25  失敗フラグ
 29  識別情報
 30  アプリ変更情報
 31  対応処理情報
 32  追加情報一覧
 33  変更情報一覧
 34  追加ファイル一覧
 35  追加レジストリキー一覧
 36  変更ファイル一覧
 37  変更レジストリキー一覧
 41  インストール対象ディスク領域
 42  アプリ環境バックアップ情報
 201 CPU
 202 メモリ
 203 記憶装置
 204 読取部
 205 着脱可能記録媒体
 206 通信インターフェース
 207 入出力部
 209 バス

Claims (15)

  1.  ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を記憶する記憶部と、
     前記記憶部に記憶された前記変更対象ファイルの所在及びファイル名を用いて、前記変更対象ファイルを取得して保存する保存処理部と、
     前記インストールを実行する処理部と、
     前記インストールの途中で発生した障害を検出する検出部と、
     前記インストールの進捗状況を示す進捗情報を取得し、前記障害が検出された場合、前記進捗情報に基いて、前記障害が発生した時の前記所定の処理を障害時処理として特定する進捗管理部と、
     前記障害時処理において変更されたファイルを、該ファイルに対応する保存された前記変更対象ファイルを用いて復元する復元部と、
     前記障害時処理の開始時点から前記インストールを再開する制御部と、
    を備える情報処理装置。
  2.  前記記憶部は、前記所定の処理において追加される追加対象ファイルの所在及びファイル名を記憶し、
     前記復元部は、前記障害時処理において追加されたファイルを、前記記憶部に記憶された追加対象ファイルの所在及びファイル名に基いて削除する
    請求項1に記載の情報処理装置。
  3.  前記進捗管理部は、前記所定の処理の前後に、前記進捗情報を取得する
    請求項1または2に記載の情報処理装置。
  4.  前記記憶部は、前記所定の処理が正常に終了した場合の正常状態情報を記憶し、
     前記進捗管理部は、前記正常状態情報に基いて前記所定の処理が正常に終了したか否かを判定し、前記所定の処理が正常に終了していないと判定した場合、前記所定の処理を障害時処理として特定する
    請求項1~3のうちいずれか1項に記載の情報処理装置。
  5.  前記検出部は、前記障害を検出するとともに該障害の内容を示す障害情報を収集し、
     前記進捗管理部は、前記障害情報、前記進捗情報、または前記判定の結果に基いて、前記障害時処理が再開可能か否かを判定し、
     前記復元部は、前記進捗管理部により前記障害時処理が再開可能でないと判定された場合、前記障害時処理において変更されたファイルを、保存された前記変更対象ファイルを用いて復元する
    請求項4に記載の情報処理装置。
  6.  記憶部に記憶された、ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を用いて、前記変更対象ファイルを取得して保存し、
     前記インストールを実行し、
     前記インストールの途中で発生した障害を検出し、
     前記インストールの進捗状況を示す進捗情報を取得し、前記障害が検出された場合、前記進捗情報に基いて、前記障害が発生した時の前記所定の処理を障害時処理として特定し、
     前記障害時処理において変更されたファイルを、該ファイルに対応する保存された前記変更対象ファイルを用いて復元し、
     前記障害時処理の開始時点から前記インストールを再開する
    情報処理方法。
  7.  記憶部に記憶された、前記所定の処理において追加される追加対象ファイルの所在及びファイル名に基いて、前記障害時処理において追加されたファイルを削除する
    請求項6に記載の情報処理方法。
  8.  前記所定の処理の前後に、前記進捗情報を取得する
    請求項6または7に記載の情報処理方法。
  9.  前記所定の処理が正常に終了した場合の正常状態情報に基いて前記所定の処理が正常に終了したか否かを判定し、前記所定の処理が正常に終了していないと判定した場合、前記所定の処理を障害時処理として特定する
    請求項6~8のうちいずれか1項に記載の情報処理方法。
  10.  前記障害を検出するとともに該障害の内容を示す障害情報を収集し、
     前記障害情報、前記進捗情報、または前記判定の結果に基いて、前記障害時処理が再開可能か否かを判定し、
     前記障害時処理が再開可能でないと判定された場合、前記障害時処理において変更されたファイルを、保存された前記変更対象ファイルを用いて復元する
    請求項9に記載の情報処理方法。
  11.  プロセッサに、
     記憶部に記憶された、ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を用いて、前記変更対象ファイルを取得して保存し、
     前記インストールを実行し、
     前記インストールの途中で発生した障害を検出し、
     前記インストールの進捗状況を示す進捗情報を取得し、前記障害が検出された場合、前記進捗情報に基いて、前記障害が発生した時の前記所定の処理を障害時処理として特定し、
     前記障害時処理において変更されたファイルを、該ファイルに対応する保存された前記変更対象ファイルを用いて復元し、
     前記障害時処理の開始時点から前記インストールを再開する
    処理を実行させる情報処理プログラム。
  12.  プロセッサに、
     記憶部に記憶された、前記所定の処理において追加される追加対象ファイルの所在及びファイル名に基いて、前記障害時処理において追加されたファイルを削除する
    処理を実行させる請求項11に記載の情報処理プログラム。
  13.  プロセッサに、
     前記所定の処理の前後に、前記進捗情報を取得する
    処理を実行させる請求項11または12に記載の情報処理プログラム。
  14.  プロセッサに、
     前記所定の処理が正常に終了した場合の正常状態情報に基いて前記所定の処理が正常に終了したか否かを判定し、前記所定の処理が正常に終了していないと判定した場合、前記所定の処理を障害時処理として特定する
    処理を実行させる請求項11~13のうちいずれか1項に記載の情報処理プログラム。
  15.  プロセッサに、
     前記障害を検出するとともに該障害の内容を示す障害情報を収集し、
     前記障害情報、前記進捗情報、または前記判定の結果に基いて、前記障害時処理が再開可能か否かを判定し、
     前記障害時処理が再開可能でないと判定された場合、前記障害時処理において変更されたファイルを、保存された前記変更対象ファイルを用いて復元する
    処理を実行させる請求項14に記載の情報処理プログラム。
     
PCT/JP2013/057670 2013-03-18 2013-03-18 情報処理装置、情報処理方法、及び情報処理プログラム WO2014147707A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2015506392A JP6160688B2 (ja) 2013-03-18 2013-03-18 情報処理装置、情報処理方法、及び情報処理プログラム
PCT/JP2013/057670 WO2014147707A1 (ja) 2013-03-18 2013-03-18 情報処理装置、情報処理方法、及び情報処理プログラム
US14/855,468 US20160004607A1 (en) 2013-03-18 2015-09-16 Information processing apparatus and information processing method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/057670 WO2014147707A1 (ja) 2013-03-18 2013-03-18 情報処理装置、情報処理方法、及び情報処理プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/855,468 Continuation US20160004607A1 (en) 2013-03-18 2015-09-16 Information processing apparatus and information processing method

Publications (1)

Publication Number Publication Date
WO2014147707A1 true WO2014147707A1 (ja) 2014-09-25

Family

ID=51579444

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/057670 WO2014147707A1 (ja) 2013-03-18 2013-03-18 情報処理装置、情報処理方法、及び情報処理プログラム

Country Status (3)

Country Link
US (1) US20160004607A1 (ja)
JP (1) JP6160688B2 (ja)
WO (1) WO2014147707A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6335527B2 (ja) * 2014-01-28 2018-05-30 キヤノン株式会社 システム、システムの制御方法およびコンピュータプログラム
JP7296426B2 (ja) * 2021-06-22 2023-06-22 株式会社日立製作所 情報システムを管理する管理システム及び管理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004302929A (ja) * 2003-03-31 2004-10-28 Fujitsu Ltd 自動インストーラプログラム
JP2008152762A (ja) * 2006-11-21 2008-07-03 Brother Ind Ltd プログラムのインストール装置
JP2012048540A (ja) * 2010-08-27 2012-03-08 Canon Inc 画像処理装置及びその制御方法、情報処理システム、並びにプログラム
JP2013033498A (ja) * 2006-09-01 2013-02-14 Ricoh Co Ltd 機器、プログラム更新方法、プログラム、及びプログラム更新システム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6363499B1 (en) * 1998-09-21 2002-03-26 Microsoft Corporation Method and system for restoring a computer to its original state after an unsuccessful installation attempt
US6438749B1 (en) * 1999-03-03 2002-08-20 Microsoft Corporation Method and system for restoring a computer to its original state after an unsuccessful patch installation attempt
US6836657B2 (en) * 2002-11-12 2004-12-28 Innopath Software, Inc. Upgrading of electronic files including automatic recovery from failures and errors occurring during the upgrade
AU2003270322A1 (en) * 2003-09-05 2005-04-21 Itron, Inc. Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing
KR100584338B1 (ko) * 2003-09-17 2006-05-26 삼성전자주식회사 소프트웨어 업데이트 방법 및 시스템
JP2006331256A (ja) * 2005-05-30 2006-12-07 Canon Inc 情報処理装置、インストール処理方法、記憶媒体およびプログラム
US7661018B2 (en) * 2006-12-21 2010-02-09 International Business Machines Corporation Method, apparatus and program storage device for providing automatic recovery from premature reboot of a system during a concurrent upgrade
JP5159356B2 (ja) * 2008-02-13 2013-03-06 株式会社日立製作所 リモートコピーシステム及び計算機システム
US8132047B2 (en) * 2008-11-14 2012-03-06 International Business Machines Corporation Restoring application upgrades using an application restore point
US9141487B2 (en) * 2013-01-15 2015-09-22 Microsoft Technology Licensing, Llc Healing cloud services during upgrades

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004302929A (ja) * 2003-03-31 2004-10-28 Fujitsu Ltd 自動インストーラプログラム
JP2013033498A (ja) * 2006-09-01 2013-02-14 Ricoh Co Ltd 機器、プログラム更新方法、プログラム、及びプログラム更新システム
JP2008152762A (ja) * 2006-11-21 2008-07-03 Brother Ind Ltd プログラムのインストール装置
JP2012048540A (ja) * 2010-08-27 2012-03-08 Canon Inc 画像処理装置及びその制御方法、情報処理システム、並びにプログラム

Also Published As

Publication number Publication date
US20160004607A1 (en) 2016-01-07
JP6160688B2 (ja) 2017-07-12
JPWO2014147707A1 (ja) 2017-02-16

Similar Documents

Publication Publication Date Title
JP4839841B2 (ja) スナップショット再起動方法
JP5724477B2 (ja) 移行プログラム、情報処理装置、移行方法、及び情報処理システム
US8713296B2 (en) Apparatus for restoring setting information of a board management controller from a backup memory before loading an OS when a system board is replaced
JP5077726B1 (ja) コンピュータ、その制御方法及びプログラム
US20100005258A1 (en) Backup system and method
EP2652599B1 (en) System reset
JP4940599B2 (ja) 情報処理装置、情報処理装置制御プログラム、情報処理装置制御方法
JPWO2006104197A1 (ja) 処理装置、プログラムおよび記憶媒体
JP6011272B2 (ja) ストレージ装置、復旧方法、および復旧プログラム
WO2015043155A1 (zh) 一种基于命令集的网元备份与恢复方法及装置
TW202137002A (zh) 資料儲存裝置及維持資料儲存裝置正常開機運作的方法
JP6160688B2 (ja) 情報処理装置、情報処理方法、及び情報処理プログラム
JP2017078998A (ja) 情報処理装置およびログ管理方法、並びにコンピュータ・プログラム
JP5471365B2 (ja) 情報処理装置及びコンピュータプログラム
WO2014024279A1 (ja) メモリ障害リカバリ装置、方法、及びプログラム
CN107797885B (zh) 电子设备及其控制方法
JP7503406B2 (ja) 情報処理装置
JP2011165042A (ja) 動的バックアップ機能を有する電子計算機、動的バックアップ方法及びそのプログラム
JP6981098B2 (ja) 復旧制御装置、復旧制御システム、復旧制御方法、及び、復旧制御プログラム
JP2009266117A (ja) Usbメモリ装置、及び、それを用いたプラグインアプリケーションシステム
JP7074291B2 (ja) 情報処理装置、情報処理方法及びプログラム
JP2011018187A (ja) 試験方法、試験プログラム、試験装置、及び試験システム
JP2008071188A (ja) 情報処理装置、プログラム及びシステム復旧方法
JP2008198152A (ja) 冗長構成を有するコンピュータシステム及びコンピュータシステムの系切り換え方法
KR20070024062A (ko) 백업 이미지 파일을 이용한 컴퓨터의 최적화 운영체제 복구방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13879046

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015506392

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13879046

Country of ref document: EP

Kind code of ref document: A1