JP2000082004A - Data duplex system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To back up and restore files independently of an APP based on conditions intrinsic to each of the plural files depending on user's needs. SOLUTION: This system backs up and restores only a file that a user designates by software through plural procedures and is constituted to make the name of an object file to be operated, correspond to the backup procedure and restoring procedure and permanently station them in a management table 32, monitor the occurrence of an event becoming a turning point of the backup and restoration of the designated file and the generation of a request to back up or restore the file from an APP40 to a management table 32 through a request information part 25 by a copy control process 23 according to the corresponding procedure and execute a copy for backup or restoration by starting a copying process 24 when the event or the request is generated.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to duplication (backup and recovery) of files in a computer system.
The present invention relates to a technology, and particularly to a file duplication system suitable for backing up files of a computer.

[0002]

2. Description of the Related Art In a conventional file backup technique, a backup of an entire file is always obtained by duplicating a hard disk drive (HDD). Therefore, the user needs to invest in hardware equipment, and the cost of backup increases.

As a result, this backup technology is mainly applied to large computers and workstations, and there has been a problem that its application to personal computers, which have been reduced in price in recent years, is expensive in terms of cost.

As a technique for solving such a problem, for example, there is a technique described in Japanese Patent Application Laid-Open No. 9-6545 (“user file backup system”). This technology monitors the occurrence of an error specified in advance for any file in the hard disk, and backs up the file when the number of file access retries after error detection reaches the specified upper limit number of retries. There is a technology to do. According to this technique, since only files whose number of file access retries has reached the retry upper limit specified in advance are targeted for backup, file duplication with a small hard disk capacity can be realized.

[0005]

The following points are not considered in the above prior art.

In the prior art, the number of error retries is
Error retry upper limit specified in advance (specified value)
Backup will be taken for the first time when
If the file information needs to be recovered before the error retry upper limit number is exceeded, the backup file does not exist or is not necessarily the latest backup even if it exists.

That is, when backing up a file, the required newness of the backup information differs depending on the contents and use of the file to be backed up.
To cope with this, for example, a backup is frequently acquired such that a backup is acquired every time one data write to the backup target file occurs,
It is necessary to acquire backups at a plurality of different frequencies, such as acquiring backups at a lower frequency than the former, such as acquiring backups when data writing to a file is completed and file closing is performed.

If there are a plurality of files to be backed up, it is necessary to manage each file in association with a plurality of backup acquisition conditions.

Furthermore, when the number of files to be backed up is large, recovery takes time, and it is difficult to manually recover data for files used for applications in which data is frequently updated.

[0010] Further, when the backup acquisition and the file recovery are realized by a method that requires modification to an application program (hereinafter referred to as APP) in a computer, depending on the user's program development and maintenance ability, backup may be required. May be difficult to modify.

It is an object of the present invention to perform backup and recovery of files independently of APP based on conditions specific to each of a plurality of files according to user needs.

Another object of the present invention is to perform file duplication with a small hard disk capacity, that is, file duplication with inexpensive hardware investment in an efficient and reliable manner according to user needs. Is to provide a file duplication system that can perform the above.

[0013]

In order to achieve the above object, a file duplication system according to the present invention provides a file duplication system for an arbitrary file (specified file) specified by a user.
The data input / output from the PP to the specified file and the occurrence of an error at that time are monitored. When an event to be monitored (data input / output and an error at that time) occurs, the specified file is transferred to the backup file. Copying or copying from a backup file to a user-specified file is performed by software independent of APP, and backup and recovery of the specified file are performed.

In particular, according to the present invention, a plurality of execution procedures are provided for backup and recovery, and a backup processing procedure and a recovery processing procedure which are individually executed for each of a plurality of designated files are respectively referred to as a backup section and a recovery section. And the correspondence between each section and the designated file is stored in a table format on the memory of the computer. Thereby, file duplication can be efficiently performed according to user needs.

The backup classification includes a procedure for acquiring a backup when the specified file is updated and closed by a process of monitoring the closed after updating of the specified file, which is started for each specified file, and a procedure for acquiring data of the specified file. There are two procedures for acquiring a backup when data is written to a specified file by monitoring the trigger of the occurrence of writing.

In the file recovery section, when a data input / output failure occurs in the designated file, the system is activated for each designated file. By detecting the occurrence of a data input / output failure in the designated file, the designated file is detected. When a data input / output failure occurs, a procedure for recovering a file by a user's manual operation at an arbitrary timing, and an optional APP using a designated file
To recover files when requested from

[0017]

Embodiments of the present invention will be described below.

FIG. 1 is a block diagram showing an embodiment of a file duplication system according to the present invention.

The file duplication system of the present embodiment is built in a computer 10 such as a personal computer, and the computer 10 has a CPU (Central Processing Unit).
, A processing unit 20 for performing processing such as duplication of files in a storage program method, an input / output device 30 including a display and a keyboard, and a hard disk drive (H
DD), a table storage file 31 and a backup file 33, a user-specified file 34 to be duplicated, a management table 32 and a data writing memory 35 on the main memory, and a data read / write for the user-specified file 34. And an APP 40 having an update process 41.

The processing unit 20 includes a start / stop processing unit 21 for controlling the start and stop of the processing unit 20, a table reference processing unit 22 for referring to the contents recorded in the management table 32, and the contents of the management table 32. User specified file 34
A copy control processing unit 23 which monitors data update, error occurrence, and generation of a request notification from the APP 40 and starts a copy process when the execution condition of the duplication is satisfied. Copy processing unit 24 for executing file duplication, file 2 from APP 40
It is composed of a request notification unit 25 that receives a duplication request.

With such a configuration, the file 2 of this example
The duplication system (hereinafter referred to as “the present system”) duplicates a file as follows.

First, when the computer 10 is started or when a user request is made from the input / output device 30, the start / stop processing unit 21 of the present system performs the following as information for duplicating a file.
Accepting user input of a user-specified file name and a backup file name, a backup category and a recovery category, and other information; expanding user-input information from the table storage file 31 to the management table 32;
The table reference processing unit 22 is started.

The activated table reference processing unit 22 refers to the user input information recorded in the management table 32, activates the copy control processing unit 23, and instructs the copy control processing unit 23 to refer to the contents of the referenced table. Notify.

Based on the notified table contents, the copy control processing unit 23 determines the occurrence of an update of the user-specified file 34, the occurrence of an error, and the occurrence of a file duplication request from the APP 40 according to the backup section and the recovery section. If the conditions for backup and recovery execution are met, the copy processing unit 24 is started, and the copy processing unit 24
The contents of the table are notified as information for performing the duplication.

The activated copy processing unit 24 copies the file between the user-specified file 34 and the backup file 33 based on the information notified from the copy control processing unit 23.
Then, data is copied from the data writing memory 35 to the backup file 33.

When backup and recovery are to be performed in response to a request from the APP 40, the request notification unit 25 is called from the update process 41, and the user-specified file name, the start address of the update data for the user-specified file, and the data length are passed. The request notifying unit 25 includes the management table 32
, The occurrence of the passed request, the start address of the updated data, and the data length are recorded.

Next, details of the contents, structure, and processing of each component of such a file duplication system will be described.

First, a backup section and a recovery section performed by the present system will be described with reference to FIG.

FIG. 2 is an explanatory diagram showing the configuration of the backup section and the recovery section in the management table in FIG.

This example shows the correspondence of the operation of the present system to the backup section and the recovery section.

That is, as the backup category,
"Update completed" and "Updating"
Is specified, the backup is performed when the user-specified file 34 in FIG. 1 is closed after the update, and when “updating” is specified, the user-specified file 34 is opened with the updatable authority. Execute backup when data writing occurs.

Also, there are three types of recovery, "automatic", "manual" and "notification". If "automatic" is specified, an error occurs when data is input / output to / from the user-specified file 34. Perform recovery at that point. Also,
When "manual" is specified, the user manually recovers from the backup file 34, and when "notification" is specified, the time when the notification from the APP 40 using the user-specified file 34 occurs. Perform recovery with.

Next, the difference between the backup operation when the update is designated and when the update is designated will be described with reference to FIG.

FIG. 3 is a diagram showing a difference in a copying operation for each backup section.

In particular, it shows the difference between the backup operation when the update is designated and when the update is designated.

When the update end is specified, the user specified file 3
At the point of time when the update close of No. 4 occurs (a), backup is performed by overwriting and copying the entire user-specified file 34 to the backup file 33 (b).

On the other hand, when the update is designated, the same data is copied to the backup file 33 each time one data write occurs while the user-specified file 34 is being updated (c).
Is backed up by additional copying (d).

Next, a start / stop processing unit 21 which controls the start and stop of the processing unit 20 in FIG. 1 and receives a user input will be described with reference to FIGS. 4 and 5.

FIG. 4 is a flowchart showing an example of the main processing operation of the start / stop processing unit in FIG. 1, and FIG.
5 is a flowchart illustrating an example of an input processing operation by a start-stop processing unit in FIG.

The processing in this example is first started in the processing section 20 when the computer 10 shown in FIG. 1 is started or in response to a user request from the input / output device 30, and performs main processing and input processing for receiving user input. Consists of Figure 4 shows the main processing
The input processing will be described with reference to FIG.

The main processing is to load a management table for storing information input from the user into the memory,
This is a process for activating a table reference process for referring to the contents of the table.

In FIG. 4, after starting the main processing, the management table is first loaded into the memory (step S4).
1). Next, an option input process for receiving a user input is started (step S42). Thereafter, a table reference process is started to refer to the inside of the table (step S43), and the main process ends. Next, an input process of checking the content of input information from a user and writing the information in the management table 32 of FIG. 1 will be described with reference to FIG. The contents of the user input information are shown in FIG. Information not directly input by the user in FIG. 6 will be described later in each process.

In FIG. 5, after the start of this processing, it is determined whether or not there is a user input request for setting options such as backup (step S51). If there is no request, the process is terminated. An input screen is displayed on the output device 30 (step S52).

On this input screen, as the information directly input by the user, inputs such as a backup section 602, a recovery section 603, a user-specified file name 606, a backup file name 607, and the number of re-executions 610 shown in FIG. Accept.

The number of re-executions 610 shown in FIG. 6 indicates that the backup process and the recovery process are not completed normally.
This is for specifying the maximum number of re-executions. Also, the backup section 602, the recovery section 603, and the user-specified file name 606 are required to be input, and the backup file name 607 and the number of re-executions 610 can be omitted from the user input. And the number of times.

In FIG. 5, thereafter, it is checked whether or not the input information indicating the conditions such as backup is correct (step S53). If there is an error, step S52 is performed.
Returns to the input screen display, and prompts the user for re-input. If the input is correct, the input information is written in the management table 32 (step S54).

Next, when a user input is made,
It is assumed that either the new registration, the update or the deletion of the user-specified file name has been performed and the table contents have been changed, and the table reference processing unit 22 of FIG. 1 is started to refer to the latest table contents (step S55). ).

In the case of updating already registered contents, only the backup file name and the number of retries are permitted as update targets, and a change in the user-specified file name is treated as a new registration.

The contents of the management table 32 for managing the correspondence between the user-specified file 34 indicating such a file to be backed up and the backup section and the recovery section performed on the file will be described with reference to FIG.

FIG. 6 shows a configuration example of the management table in this embodiment.

The management table 32 is configured to hold, as one entry, information in which a duplication target is associated with a duplication option.

The function of each item will be described sequentially below.

First, the horizontal axis is “process number” 601,
“Backup type” 602, “Recovery type” 603,
"Process type" 604, "Process start time" 605, "User specified file name" 606, "Backup file name" 607, "Execution result flag" 608, "Processing flag" 609, "Re-execution count" 610, " Entry update type ”611,“ request notification presence / absence ”612, and“ update information storage queue area ”614.

Here, the “process number” 601 is used to specify the process of the copy processing unit 24 in FIG. 1 that actually performs the copy, and the “process type” 604 indicates that the copy processing unit 24 is normal. If not completed, it is used to determine whether backup or recovery has been performed. The “processing start time” 605 indicates that the copy processing unit 2
4 is used to monitor whether processing takes an unduly long time based on the time at which it was started.

The "execution result flag" 608 is used to determine whether or not the copy processing section 24 has been completed normally.
It is used to determine whether or not the system is in a state of monitoring the occurrence of an update and the occurrence of an error. The “number of re-executions” 610 is used to specify the maximum number of re-executions when the copying process 24 fails.

Further, the “entry update type” 611 is
When a registered entry is changed by user input, it is used to indicate the form of the change, and "request notification presence / absence" 612 is used to indicate whether a request from the APP has been notified.

The “update information storage queue area” 613 as the last item of the management table 32 stores one item of data to be written to the user-specified file 34 when “update in progress” is designated in the “backup category” 602. In order to store the position information on the data writing memory 35 for each data and the occurrence of the close after the update of the user-specified file 34 and the start address of the queue area for storing the result, Used.

This “update information storage queue area” 613
Holds two types of information, ie, the start address of data in the memory and the data length, in order to acquire data to be written in a file specified by the user for each case. Whether or not the user-specified file 34 has been closed after the data writing has been updated and the result thereof are determined in the order in which the two types of data, the file close flag 617 and the close success / failure flag 618, are written and the file is closed after the file update. , Stored in a first-in first-out queue format. still,
This queue area is generated in advance for each entry whose backup category is specified as being updated, and is associated by storing the head address of the queue area in the update information storage area start address which is the last item of one entry. .

Next, the management table 32 having such a configuration will be described.
The table reference processing unit 22 of FIG. 1 that refers to the contents of FIG. 1 will be described with reference to FIG.

FIG. 7 is a flowchart showing an example of a processing operation by the table reference processing unit in FIG.

The activation of the table reference processor 22 in FIG. 1 for performing the processing of this embodiment is performed when the present system is activated and when a user input occurs.

First, after the start of this process, the first row of the management table 32 of FIG. 1 is referred to (step S71), and it is determined whether or not the file monitoring flag of the referenced entry is being monitored (step S72).

If the entry is being monitored, it is determined whether or not the entry update type is deleted (step S73). If the entry is updated, a request to delete the entry is issued from the user as an instruction to release the duplexing. Is determined, the entry is deleted from the management table 32 (step S74), and the process proceeds to the determination of the last entry in step S7D.

If it is determined in step S73 that the entry update type is not "delete", it is determined whether the entry update type is either update or suspension (step S75). It is determined that no change has been made to the monitored entry, and the flow proceeds to the determination of the last entry in step S7D. If the entry update type is either update or temporary stop, the corresponding sub-process of the copy control process is stopped based on the process number of the entry (step S76).

Thereafter, it is determined whether or not the entry update type is update (step S77). If the entry update type is update, the process proceeds to the copy control processing start of step S7B. If the entry update type is not update, it is determined that the user request is to suspend the entry, the monitoring flag of the entry is not monitored, and the process proceeds to step S7D to determine the last entry.

If it is determined in step S72 that the referenced entry is not being monitored, it is determined whether deletion of an unmonitored entry has been requested (step S72).
79) If the entry update type is "delete", the entry is deleted, and the process proceeds to step S7D to determine the last entry.

If the entry update type is not "delete", it is determined that the entry is newly registered, and the copy control processing unit 23 is started to start monitoring of the file designated by the user (step S1). S7B) Notify the copy control processing unit 23 that has activated the user-specified file name, backup file name, backup category, and recovery category designated in the management table 32 (step S7C).

Thereafter, it is determined whether or not the referred entry is the last entry on the management table 32 (step S).
7D) If it is not the last entry, the next entry is referred to and the process proceeds to step S86 to determine whether the recovery section is manual. If it is the last entry, it is determined whether or not the input processing of the start-stop processing unit 21 has not been started (step S7).
F) If not started, the input processing is started (step S7G), and if already started, this processing ends.

Next, the copy control processing unit 23 shown in FIG. 1 that receives the contents referred to by the table reference processing unit 22 and monitors the occurrence of an event that matches the backup and recovery execution conditions will be described.

FIG. 8 is a flowchart showing an example of the processing operation of the copy control processing unit in FIG.

First, after the start of this process, information of a user-specified file name, a backup file name, a backup section, and a recovery section is received from the table reference processing section 22 of FIG. 1 as a start source (step S81).

Then, based on the received information, the copy processing unit 24 for performing actual file copy is started, the first backup of the file specified by the user is obtained, and the backup file 33 is generated (step S82).

Next, it is determined whether or not the notified backup section has been updated (step S83).

If the division is being updated, the writing of the update data information from the request notifying section 25 to the management table 32 is monitored, and the writing monitoring processing for starting the copy processing section 24 is started when the writing is performed. Then, the process proceeds to step S86 to determine whether the recovery section is manual.

If the classification has been completed, the update completion of the user-specified file 34 is monitored. If the update has been completed, an update completion monitoring process for activating the copy processing unit 24 is started (step S85). Next, it is determined whether the recovery section of the notified entry is manual (step S8).
6) If the operation is manual, the process ends because there is no need to activate the copy processing unit 24 for executing recovery.

If the recovery category is not manual, it is determined whether the category is automatic (step S87). If not, it is determined that the category is notification, and the occurrence of notification from APP is monitored. If there is a notification, a notification monitoring process for starting the copy processing unit 24 is started (step S8).
8). If the classification is automatic, user specified file 3
The occurrence of a data input / output error is monitored, and if an error occurs, an error monitoring process for activating the copy processing unit 24 for recovery execution is started (step S89).

As described above, the copy control processing unit 23 shown in FIG.
Are activated from within the table reference processing unit 22 at one ratio corresponding to one entry in the management table 32, and each monitoring process is activated according to the backup section and the recovery section of the corresponding entry.

Next, the copy control processing section 23
The copy processing unit 24 of FIG. 1 which is started from the inside and performs copying for actual backup and recovery will be described.

FIG. 9 is a flowchart showing an example of the processing operation by the copy processing unit in FIG.

After the start of this processing, first, as information for determining a copying operation, the copying control processing unit 23 shown in FIG.
The copy source file name or the location of the copy source data, the copy destination file name, and the number of re-executions are received (step S9).
1).

The own process number and the current time as the copy start time are written in the corresponding entry items on the management table 32 as information for coping with an error during the execution of the copy (step S92).

Thereafter, copying is executed based on the information received in step S91 (step S93), and it is determined whether or not the copying has been completed normally (step S94). If the copying has not been completed normally, the number of re-executions reaches the upper limit. Is determined (step S95).

If the number of times of re-execution has not reached the upper limit, one is subtracted from the number of times of re-execution (step S96), and copying is executed again in step S93 to execute copying again. Also,
If the number of re-executions has reached the upper limit, the management table 3
An error is set in the execution result flag of the corresponding entry of No. 2 (step S97), and backup or recovery is set in the processing type to record whether the error occurred during backup or recovery (step S98). Move to process information setting in step S99.

The process number of the copy execution process and the process start time as the copy start time are used as information for judging an error when it takes an abnormally long time to complete the copy execution as the process start time.
Write to the corresponding entry above (step S9
2).

As described above, the copy processing unit 24 performs backup and recovery according to the contents of the information notified from the copy control processing unit 23 of the starting source.

Next, when the backup section is being updated, a write monitoring process which is started from within the copy control processing unit 23 and monitors the writing of the update data location to the queue area pointed to from the management table 32, That is, details of step S84 in FIG. 8 will be described.

FIG. 10 shows the copy control processing unit 2 in FIG.
13 is a flowchart illustrating an example of a write monitoring process operation 3;

After the start of this processing, first, the queue area of the corresponding entry is referenced on the management table 32 of FIG. 6 (step S101).

Then, the presence or absence of writing to the queue area is determined (step S102). If there is no writing, the process proceeds to step S101 to refer to the queue area in order to continue referring to the queue area and monitor the occurrence of writing. If writing has occurred, the contents of the first queue are referred to (step S103).

Further, it is determined whether or not the referred queue content is a file close after updating the user-specified file 34 (step S104). If not, the copy processing unit 24 is started to activate the referred queue content. Is notified (step S10B), and a time monitoring process for monitoring the processing time of the copy processing unit 24 is started (step S10).
C).

Thereafter, it is determined from the execution result flag on the table 32 whether the copying process has been completed normally (step S10D).

If the processing has been completed normally, the time monitoring process is stopped (step S10E), the referenced first queue is deleted from the queue area (step S10F), and it is determined whether or not the next queue exists. finish.

If the next queue exists in step S10I, the process proceeds to step S10I to refer to this next queue.
Move to the first queue reference of No. 3.

Further, in step S10D, the copy processing unit 2
If Step 4 did not end normally, it is determined whether the upper limit of the number of re-executions has been reached (Step S10G). If not, a new copy processing unit 24 is started to continue the processing, The process shifts to the start of the copy process in step S10B to notify the queue content of the current reference. If the number of retries has reached the upper limit, an error message is output from the input / output device 30 assuming that a fatal failure that makes data copying impossible has occurred in the file system (step S).
10H), this process ends.

If the content of the queue is a file close after updating the file in step S104, it is determined whether or not the file close is successful by referring to the close success / failure flag (618) of the queue (step S104). In step S105), if successful, the process proceeds to step S10I where there is no next queue. If unsuccessful, it is determined whether or not the recovery section 603 specified in the entry is an automatic recovery (step S106). If not, step S
The process proceeds to the determination that there is no next queue of 10I. In the case of automatic recovery, it is determined whether or not the error monitoring process started in step S89 in the copy control processing unit 23 has been started (step S107).

If it has been started, the process proceeds to step S10I where there is no next queue. If it has not been started, the file close after updating the user specified file 34 has failed, and the last write open of the user specified file 34 has been completed. It is determined that it is necessary to recover the data written during the period from to the file close, and the copy processing unit 24 is started,
The copy is executed by designating the backup file 33 as the copy source file and the user designation file 34 as the copy destination file (step S108).

Thereafter, it is determined whether or not the copy processing section 24 has been completed normally (step S109). If the copy processing section 24 has been completed normally, the write monitoring process has been completed.
An error message is output from the input / output processing 30 assuming that a fatal failure has occurred in the file system (step S10A), and this processing ends.

Next, a description will be given of the details of the time monitoring process for monitoring the required time of the copy processing unit 24 to prevent an unduly long processing time, that is, the process of step S10C in FIG.

FIG. 11 is a flowchart showing an example of the time monitoring processing operation executed in combination with the execution of the copy processing unit in FIG.

This process is started in combination with the process of the copy processing unit 24 in FIG. 1, and is started during the write monitoring process, the update completion monitoring process, the notification monitoring process, and the error monitoring process of the copy control processing unit 23. This is the process to be performed.

After this process is started, first, the process number of the copy processing unit 24 started from the process of the start source is received (step S111).

Then, when the copy processing unit 24 starts, the processing start time written in the management table 32 is subtracted from the current time from the received process number (step S1).
12) It is determined whether the maximum processing time specified in advance has been exceeded (step S113).

As a result of the determination, if the time has not exceeded, the flow returns to step S112 to continue the calculation of the elapsed time. If the time has exceeded, the copy processing unit 24 is stopped (step S114), and an error message is output from the input / output device. (Step S1
15) This process ends.

This processing is performed by the copy processing unit 24 to be monitored.
Terminates normally or abnormally, and is forcibly stopped from the processing of the activation source.

Next, in the management table 32 of FIG.
The processing of the request notifying unit 25 when updating is specified in the backup category will be described.

FIG. 12 is a flowchart showing an example of the processing operation of the request notifying unit in FIG. 1. FIG. 13 is an explanatory diagram showing an example of information transferred between the APP and the request notifying unit in FIG. .

The process of the request notifying unit 25 is called from the update process 41 of the user-specified file 34 of the APP 40 when the update is designated in the backup section of the management table 32 of FIG. , The data written to the user-specified file 34 is notified to the processing unit 20 side.

The trigger of the actual call may be that after the user-specified file 34 is opened during the update processing 41.

First, at the same time as the processing of the request notifying unit 25 is called, the user-specified file name and the head address and data length of the data written to the data writing memory 35 from the update processing 41 or the user-specified file 34 The closing result is received as an argument in the format shown in FIG. 13 (step 121).

The received information is stored in the management table 3
2 is written to the queue area corresponding to the corresponding entry on step 2 (step S122), and it is determined whether the writing was successful (step S123). If the writing was successful, the normal value is returned to the update process 41 of the caller. (Step S12
4), end.

If the writing has failed, it is determined whether the upper limit of the number of re-executions has been reached (step S12).
5) If not reached, the process returns to the writing of the queue area in step S122 to continue the writing.

If the upper limit of the number of re-executions has been reached, an error value is returned to the updating process 41 of the caller (step S126), and it is determined that a fatal failure has occurred in writing to the queue area. Then, an error message is output from the input / output device 30 (step S127), and this processing ends.

The handling of the error value returned to the update processing 41 in step S126 is optional depending on the processing of the APP 40 and the update processing 41. Also, the number of re-executions may be specified as an argument from the caller,
When omitted, the request notification unit assumes an initial value.

Next, a description will be given of the update end monitoring processing started by the copy control processing section 23 in step S65 in FIG.

FIG. 14 is a flowchart showing an example of the update end monitoring processing operation started by the copy control processing unit in FIG.

In this process, when the update of the backup section is completed, the update close of the user-specified file 34 is monitored, and when the update close occurs, the copy processing unit 24 is started to execute the backup.

After starting this processing, first, the copy control processing unit 2
3 receives the information of the corresponding entry on the management table 32 (step S141),
The monitoring of the input / output event for No. 4 is started.

When the success of closing the file after updating is detected in the monitored event (step S142), the copy processing unit 24 is started (step S143), and the user-specified file name and the backup file name are obtained from the received entry information. Notify.

Then, the time monitoring process of the copy processing unit 24 is started (step S144), and thereafter, it is determined whether or not the copy processing unit 24 ends normally (step S145). Is stopped (step S
147), this process ends.

If an abnormal end of the update close is detected in step S142, and if the copy processing unit 24 does not end normally in step S145, an error message is output from the input / output device 30 in step S146. The process shifts to time monitoring stop in step S147.

Next, a notification monitoring process for monitoring the occurrence of a recovery request from an existing program when the recovery category is notification will be described with reference to FIG. This process is started from step S88 of the copy control processing unit in FIG. 8, and determines whether or not there is a notification from the request notification unit 25 by referring to the management table 32, and starts the copy processing unit 24 when a notification occurs. This is the processing to be performed. After the start of this process, first, the information of the corresponding entry on the management table 32 is received from the copy control processing unit 23 (step S151), and it is determined whether or not the notification is generated by referring to the presence or absence of the recovery notification of the entry. (Step S152).

If a notice has been given, the copy processing unit 24 is started (step S153), a time monitoring process is started (step S154), and if there is no notice, the monitoring is continued.

Thereafter, it is determined whether or not the copy processing section 24 has been completed normally (step S155). If it has been completed normally, the time monitoring processing is stopped (step S157), and this processing is terminated.

If the copy processing section 24 has not been normally terminated in step S155, an error message is output from the input / output device 30 (step S156), and the operation shifts to time monitoring stop in step S157.

Next, the request notifying section 25 when the recovery section is notified.
Will be described.

FIG. 16 is a flowchart showing an example of the processing operation by the request notifying unit in FIG.

This processing is called from the APP 40 when the notification is specified in the recovery section of the management table 32 in FIG.
First, together with the call of the present means, the file is received from the caller in the format shown in FIG. 13 with the user-specified file name and the backup file name as arguments (step S161).

Then, a corresponding entry on the management table 32 is obtained from the content of the received argument, and the occurrence of the notification is written in the item of the presence or absence of the request notification (step S162).
Thereafter, it is determined whether or not the writing in step S162 has been performed normally (step S163). If the writing is normal, a normal value is returned to the calling source (step S164), and the process ends.

If the writing has not been completed normally in step S163, it is determined whether or not the number of re-executions has reached the upper limit (step S165). Returning to the notification area writing in S162, if it has reached, the error value is returned to the calling source (step S166), and an error message is output from the input / output device 30 (step S16).
7) End the processing.

Note that step S164 and step S1
The handling of the normal value and the error value returned in this processing at 65 is optional.

Also, There are three types of triggers for calling this means when the recovery section is notified, and it differs depending on whether the APP 40 reads data from or writes data to the user-specified file 34.

For example, when reading data, the APP 40
The call may be made when the process of referring to the user-specified file 34 detects an error.

When writing data, the trigger differs for each content specified in the backup category. When the backup category is being updated, a backup is acquired every time one data is written. It only needs to be called each time it detects that an error has occurred in writing data to the specified file, and if the backup category has been updated, it should be called every time the caller detects an update close error of the user-specified file. good.

Next, the error monitoring process started by the copy control processing unit 23 in step S89 in FIG. 8 will be described.

FIG. 17 is a flowchart showing an example of an error monitoring processing operation started by the copy control processing unit in FIG.

This processing is for monitoring the occurrence of an error in data input / output to / from the user-specified file 34 and, when an error occurs, activating the copy processing unit 24 to execute recovery. The errors monitored here are a data read error, a data write error, and a file close error after data write.

After the start of this processing, first, the copy control processing unit 2
3 (step S).
171). Next, monitoring of the corresponding user-specified file 34 is started from the received information, and it is determined whether or not an error has occurred (step S172). If an error has occurred, the copy processing unit 24 is activated by notifying the entry information (step S173).

Then, it is determined whether the copy processing section 24 has been completed normally (step S174). If not completed, it is determined whether or not the upper limit of the number of re-executions has been reached (step S175). , If the limit has not been reached,
The process returns to the main routine to activate the copy processing unit 24 again. If the upper limit has been reached, an error message is output from the input / output device 30 (step S176), and this processing ends.

As described above with reference to FIGS. 1 to 17, in the file duplication system of the present embodiment, only the files specified by the user are backed up by software. This makes it possible to realize a duplex file system at low cost.

The backup processing procedure includes a procedure for acquiring a backup when the user-specified file is closed after the update, and a procedure for acquiring a backup when data is written during the update of the user-specified file. When the required newness of the backup information differs depending on the content and use of the file to be backed up, for example, a backup is acquired every time one data write to the file to be backed up occurs Backup at multiple different frequencies, such as backup acquisition at a higher frequency than the previous one, or backup at a lower frequency than the former, such as obtaining a backup every time a file close is performed after data has been written to a file Also if you need to get Further, when there are a plurality of files to be backed up, the correspondence between each file and a plurality of backup acquisition triggers can be managed by the above-mentioned table, so that the backup operation can be customized according to the user's business. Become.

Further, as a procedure of the recovery processing, a procedure for recovering a file when a failure occurs in a user-specified file, a procedure for executing recovery by a user's manual operation at an arbitrary time, and using a user-specified file There are three procedures for recovering a file when triggered by an arbitrary program. Thus, A for file recovery
Without converting to PP or creating a new program,
File recovery can be performed, and the burden on the user can be reduced.

The present invention is not limited to the embodiment described with reference to FIGS. 1 to 17 and can be variously modified without departing from the gist thereof. For example, in this example, as shown in FIG. 1, there is one user-specified file 34 and one backup file 33. A configuration may be used.

[0143]

According to the present invention, since a backup is obtained only for a file (designated file) for which a user desires to obtain a backup, file duplication can be performed with a small hard disk capacity, and inexpensive hardware can be used. File duplication can be realized by capital investment.

The user can select a procedure for executing recovery without modifying the existing program. For example, another program intervenes in execution of recovery by notifying a request for recovery execution from another program. And a plurality of recovery procedures can be selected according to user needs.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an embodiment of a file duplication system.

FIG. 2 is a diagram illustrating a configuration of a backup section and a recovery section in a management table according to the present embodiment.

FIG. 3 is an explanatory diagram showing a difference in a copying operation for each backup section.

FIG. 4 is a flowchart illustrating an example of a main processing operation of a start-stop processing unit according to the embodiment.

FIG. 5 is a flowchart illustrating an example of an input processing operation performed by a start / stop processing unit according to the embodiment;

FIG. 6 is an explanatory diagram illustrating a configuration example of a management table in the present embodiment.

FIG. 7 is a flowchart illustrating an example of a processing operation performed by a table reference processing unit according to the embodiment;

FIG. 8 is a flowchart illustrating a processing operation example of a copy control processing unit according to the embodiment.

FIG. 9 is a flowchart illustrating an example of a processing operation performed by a copy processing unit according to the embodiment.

FIG. 10 is a flowchart illustrating an example of a write monitoring processing operation of a copy control processing unit according to the present embodiment.

FIG. 11 is a flowchart illustrating an example of a time monitoring process operation executed in combination with execution of the copy processing unit according to the embodiment.

FIG. 12 is a flowchart illustrating an example of a processing operation of a request notifying unit according to the embodiment;

FIG. 13 is a diagram illustrating an example of information transferred between an APP and a request notification unit according to the embodiment;

FIG. 14 is a flowchart illustrating an example of an update end monitoring process operation started by the copy control processing unit according to the embodiment;

FIG. 15 is a flowchart illustrating an example of a notification monitoring process operation started by the copy control processing unit according to the embodiment.

FIG. 16 is a flowchart illustrating an example of a processing operation performed by a request notifying unit according to the embodiment;

FIG. 17 is a flowchart illustrating an example of an error monitoring process operation started by the copy control processing unit according to the embodiment;

[Explanation of symbols]

10 Computer, 20 Processing Unit, 21 Start-Stop Processing Unit,
22: table reference processing unit, 23: copy control processing unit, 2
4. Copy processing unit, 25 Request notifying unit, 30 Input / output device, 31 Table storage file, 32 Management table, 33 Backup file, 34 User-specified file, 35 Data writing memory, 40 APP, 4
1. Update processing.

 ──────────────────────────────────────────────────の Continued on the front page (72) Inventor Takahiro Morimoto 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Inside Software Division of Hitachi, Ltd. (72) Daisuke Kawakatsu 5030 Totsuka-cho, Totsuka-cho, Yokohama, Kanagawa Prefecture Hitachi, Ltd. Software Division

Claims (12)

[Claims] 1. A data duplication system for backing up data used by a computer, wherein the data update monitoring means monitors data updates of an application program running on the computer, and an object monitored by the data update monitoring means. A data duplication system, comprising: monitoring condition defining means for defining the data, a storage means to be accessed by the application program, and copying means for copying the updated data into the storage means. 2. The data duplication system according to claim 1, wherein when an input / output error occurs in the monitored object, the data updated by the copying means is reflected on the monitored object to recover the data. A data duplication system comprising a recovery unit that performs recovery. 3. The data duplication system according to claim 1, wherein said monitoring condition definition means can define a timing at which said data update content is copied.
Weighting system. 4. The data duplication system according to claim 3, wherein the timing of copying includes at least one of timing when the data is updated and timing when a file including the data is closed after updating. The data duplication system characterized by the above. 5. The data duplication system according to claim 2, wherein said recovery means includes recovery condition definition means for defining conditions for recovering data. 6. The data duplication system according to claim 5, wherein said recovery condition defining means is provided when a data input / output failure occurs, and when a data recovery instruction is issued from an application program accessing said data. A data duplication system, wherein at least one condition can be defined when a data recovery instruction is issued from the system. 7. A data duplication method for backing up data used by a computer, wherein the data update monitoring means monitors a data update of an application program running on the computer,
Copying the updated content of the data into storage means accessed by the application program when the data is updated. 8. The data duplication method according to claim 7, further comprising the step of receiving a designation of a target to be monitored by said data update monitoring means. 9. The data duplication method according to claim 8, wherein when an input / output error occurs in the object to be monitored by the recovery means, the data update content copied by the copying means is reflected on the object to be monitored. A method for duplicating data, comprising a step of recovering data. 10. A computer-readable storage medium for storing a program for realizing the method according to claim 7. 11. A computer-readable storage medium for storing a program for realizing the method according to claim 8. 12. A computer-readable storage medium for storing a program for realizing the method according to claim 9.