Backup system and method and program

A remote site stores data received from a currently-used site and transfers the stored data to a proximal site. The proximal site stores the data received from the remote site and transfers the stored data to the currently-used site. The currently-used site crosschecks the data returned from the proximal site against the data transmitted to the remote site, and when the two data do not match each other, transmits the data to the remote site again.

CLAIM OF PRIORITY

The present application claims priority from Japanese application P2003-419162 filed on Dec. 17, 2003, the content of which is hereby incorporated by reference into this application.

BACKGROUND

The present invention relates to a backup technology for data in a storage system or a server, and more specifically to a technology of asynchronous data update between plural sites.

Databases and web sites avoid data redundancy by taking a backup and storing the backup data in physically different storage system. For instance, data of a site that is currently in use (hereinafter referred to as currently-used site) is transferred to a storage system on a site located in a geographically remote place (hereinafter referred to as remote site) and the data is updated so that the backup data on the remote site can be used to avoid losing data of the currently-used site over calamities such as earthquake in case the effectiveness of the currently-used site is impaired.

Such data backup systems known to this point are divided into synchronous backup systems (EP 0671686 A1) with which a data update on a remote site is synchronous with a data update on a currently-used site and asynchronous backup systems (EP 0672985 A1) with which a data update on a currently-used site is followed by a data update on a remote site.

SUMMARY

However, the prior art described above has no consideration for crosschecking whether or not data transmitted from a currently-used site to a remote site is correctly backed up on the remote site.

An object of the present invention provides a technology of crosschecking that data is backed up correctly between plural sites.

According to the aspect of the present invention, data transmitted from a site is backed up on a first backup site and a second backup site. The first backup site stores the data received from the sender site and transfers the stored data to the second backup site. The second backup site stores the data received from the first backup site and transfers the stored data to the sender site. The sender site crosschecks the data returned from the second backup site against the data transmitted to the first backup site and, when the two do not match, transmits the data to be backed up to the first backup site once again.

In this way, correct data backup between plural sites can be confirmed by a sender of backup data which transmits the backup data to a single site and which crosschecks returned data against the data transmitted.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIGS. 1 to 3are block diagrams showing the overall structure of a system to which the present invention is applied.FIG. 1is a block diagram showing the structure of a certain site.FIG. 2is a block diagram showing the relation between a server and a storage system ofFIG. 1.FIG. 3shows an example in which a currently-used site1, a proximal site2, and a remote site3are located in three geographically different places and data of the currently-used site1is backed up to the proximal site2and the remote site3.

FIG. 1is a block diagram showing an example of the currently-used site1ofFIG. 3.

As the example inFIG. 1shows, the currently-used site1ofFIG. 3has an intra network composed of a backbone LAN (Local Area Network)11A and an SAN (Storage Area Network)11B. The backbone LAN11A is connected to an external network (omitted from the drawing) such as Internet and WAN through a not-shown gateway (e.g., router).

Various servers10A to10F are connected to the backbone LAN11A to process and accumulate information upon request from application clients (client computers)5A,5B and5C, which are also connected to the backbone LAN11A.

The various servers10A to10F are connected to storage systems in a manner described below.

Application servers10A and10B are connected via the SAN11B to storage systems12A and12B, so that the serves10A and10B can read and write data in the storage systems12A and12B.

An NAS server10C is connected via the SAN11B to the storage systems12A and12B, so that the NAS server10C can read and write data in the storage systems12A and12B upon request from the application clients5A to5C.

An NAS server10D is connected to a storage system12D, so that the NAS server10D can read and write data in the storage system12D upon request from the application clients5A to5C.

File servers10E and10F are locally connected to storage systems12E and12F, respectively. The file server10E reads and writes data in the storage system12E upon request from the application clients5A to5C. The file server10F reads and writes data in the storage system12F upon request from the application clients5A to5C.

The servers10A to10F use software, which is described later, to back up data in the storage systems12A to12F to the proximal site2and the remote site3shown inFIG. 3.

Similar to the currently-used site1, the proximal site2and the remote site3ofFIG. 3can have the structure shown inFIG. 1.

FIG. 2is a detailed block diagram showing the relation between the application server10A and the storage system12A which constitute the currently-used site1.

The application server10A has interfaces (referred to as I/F in the drawings) connected to a CPU, a memory, an external network, and an intra network11A. The storage system12A has a control unit121which includes an interface connected to a CPU, a memory, a cache memory (data cache), and an intra network11B, and an interface connected to disk drives120. The application server10A also has a display system and an input system which are not shown in the drawing.

Receiving a request from a client, which is described later, or the like, the application server10A reads or writes data in the SAN storage system12A and, when a data update takes place, transfers data to the proximal site2and the remote site3for backup as will be described below. The application server10A may have local disk drives as the file servers10E and10F ofFIG. 1have.

Given below is an example in which the application server10A and the storage system12A ofFIGS. 1 and 2are provided in each of the sites shown inFIG. 3to exchange data among the sites for backup. It is assumed for a simpler explanation that the application server10A, the SAN11B, and the storage system12A are provided in each of the currently-used site1, the proximal site2, and the remote site3shown inFIG. 3and that a backup system is run on the application server10A of each site.

The application server10A and the storage system12A, which are connected to each other via the SAN11B inFIGS. 1 and 2, may be connected through a LAN or an original network instead of the SAN11B. The intra network11A, which is a LAN inFIG. 1, may be composed of an IP network.

FIG. 3is an explanatory diagram showing a data flow for data backup between three geographically different sites.

In the backup system of the present invention, data writing in the storage systems12A of the currently-used site1(S1in the drawing) is followed by transfer (copying) of the written data to the remote site3(S2in the drawing).

The remote site3writes the data received from the currently-used site1in a storage system (for example, the storage system12A ofFIG. 1) and then transfers (copies) the written data to the proximal site2(S3in the drawing). The proximal site2writes the data received from the remote site3in a storage system (for example, the storage system12A ofFIG. 1) and then transfers (copies) the written data to the currently-used site1(S4in the drawing).

The currently-used site1crosschecks the data received from the proximal site2against the data transmitted to the remote site3in step S2to find out whether the data written in the remote site3and the proximal site2is correct or not (S5in the drawing). When it is found as a result of the crosscheck that the written data is not correct, the currently-used site1transmits data to be backed up to the remote site3once more.

In other words, a site serving as a sender (the currently-used site1) transmits data to be backed up to sites to which the data is backed up (the proximal site2and the remote site3), data written to the backup destination sites is transferred to the sender site for data looping and, as the data looping is completed, the data transmitted from the sender and the data that is backed up last are compared to each other for crosscheck.

This makes it possible to ensure data consistency while avoiding an increase in load of the sender where data is being updated and backed up. In short, the present invention makes backup destination sites daisy-chained from one site that serves as a sender, thereby allowing the sender site to take a backup at minimum load irrespective of the number of backup destination sites.

A site is composed of a data processing devices which includes a computer such as a server, a storage system for storing data, and a network for connecting the computer and the storage system to each other, or for interconnecting computers, or for interconnecting storage systems. The currently-used site1is a site that has data to be backed up, which is stored, for example, by the application server10A in the storage system12A connected to the application server10A via the intra network (SAN or LAN)11B.

Software configurations of the currently-used site1, the proximal site2, and the remote site3are shown inFIG. 4.

Components inFIG. 4are roughly divided into two: a software group100of the currently-used site1which serves as a sender of data to be backed up and a software group200of the proximal site2and the remote site3to which the data from the currently-used site1is backed up. The software groups100and200are executed by the application server10A shown inFIG. 1.

The structure of the software group100is described first. The software group100of the currently-used site1, which transmits written data and crosschecks data returned from a backup destination site, is composed of six modules: a role definition module101for determining the role of each site, a data management module102for managing data written in the storage system12A and data to be transmitted, a data write module103for writing data in the storage system12A, data transfer module104for transmitting data written in the storage system12A to a backup destination, a data receiving module105for receiving data returned from a backup destination by looping, and a crosscheck module106for comparing the data transmitted by the data transfer module104and the data received by the data receiving module105with each other for crosscheck.

In the software group200executed on a backup destination site, servers of the proximal site2and the remote site3have the same structure as the application server10A ofFIG. 1. The only difference between the server of the proximal site2and the server of the remote site3is reception and transmission destination determined by role definition, which will be described later, and the two servers carry out identical processing.

The software group200is composed of a data receiving module201for receiving backup data and role definition transmitted, a role definition analyzing module202for analyzing the received role definition and ruling the server operation based on the role definition, a data write module203for writing the received backup data in the storage system12A, and a transfer module204for transmitting the written data to the next backup destination or to the sender (currently-used site1).

The role definition module101run on the application server10A of the currently-used site1, which is the sender, determines in what order backup data is to be transmitted from the currently-used site1as the sender, and what processing is to be performed in the respective sites. Such definition is set as a table shown inFIG. 5, for example.

In the table ofFIG. 5given as an example, the remote site3is defined as the transmission (transfer) destination of backup data of the currently-used site1serving as the sender, the proximal site2is defined as the transfer destination of data of the remote site3, and the currently-used site1is defined as the transfer destination of data of the proximal site2.

The table ofFIG. 5also instructs about processing on data received by the respective sites. For the currently-used site1, transferring (transmitting) data and crosschecking received data against transmitted data are defined as processing to be made. For data received by the remote site3, writing the received backup data in the storage system and transferring the written data are defined as processing to be made. Similarly, backup data received by the proximal site2is written in the storage system and the written data is transferred according to the definition.

With the role definition ofFIG. 5, when data is written in the storage system12A of the currently-used site1, the written data is transferred to the remote site3which is the transfer destination allotted for the currently-used site1as shown inFIG. 3. The remote site3writes the data received from the currently-used site1in the storage system and transfers the written data to the proximal site2. The proximal site2writes the data received from the remote site3in the storage system and transfers the written data to the currently-used site1. The currently-used site1compares the data received from the proximal site2with the data transmitted to crosscheck whether the two matches or not (in other words, whether data looped through the sites is correct or not). If it is found as a result of the crosscheck that the two do not match, given processing such as retransmission of backup data is executed as will be described below.

Processing defined by the role definition module101is composed as shown inFIG. 6. Upon starting the software group100, the application server10A of the currently-used site1runs the role definition module101first to read the role definition ofFIG. 5(S10) and to transmit to the proximal site2and the remote site3their respective processing after reception and data transfer destinations (S11).

In other words, based on the table ofFIG. 5, the currently-used site1transmits to the proximal site2role definition (role sharing information) which defines write and transfer of data received as processing after data reception and which defines the currently-used site1as the transfer destination. Similarly, the currently-used site1transmits to the remote site3role definition (role sharing information) which defines writing and transfer of data received as processing after data reception and which defines the proximal site2as the transfer destination.

Described next referring to a flow chart ofFIG. 7are details of the software group200executed on the servers of the proximal site2and the remote site3.

FIG. 7shows the data receiving module201, the role analyzing module202, the data write module203, and the data transfer module204which are shown inFIG. 4. First, in step S20, data from the sender is waited for and reception of the data advances the process to step S21, where the data received is identified for branch processing according to data type.

In step S21, when the received data is role definition (role sharing information), the process proceeds to step S22whereas processing of step S23is chosen when the received data is transfer data (backup data).

In step S22, a site to which the data is to be transferred next and what processing is to be made on the received data are set based on the received data which is role definition. For instance, in the remote site3, the role definition (the table ofFIG. 5) transmitted from the currently-used site1sets the proximal site2as the data transfer destination and sets write and transfer as processing after reception. Thereafter, the process is returned to step S20to wait for the next data.

On the other hand, in step S23, the received data, which has been determined as transfer data (backup) in step S21, is written in the storage system. The written data is transmitted to the transfer destination set in step S22.

Through the above processing, the proximal site2and the remote site3set their transfer destinations and contents of processing to be made on received data based on the role definition which has been received from the currently-used site1. After that, writing data in the storage system12A of the currently-used site1starts backup processing in each site following a procedure shown inFIG. 8. The point at which a write instruction is transmitted from the application server10A and received by the control module121of the storage system12A is deemed as completion of data writing.

There are various methods to synchronize data among plural sites. Shown here is an example of using snapshot as the synchronization method.

In the application server10A of the currently-used site1as the sender, a snapshot is created after data is written in the storage system12A to create data management information, which will be described later. Then the data is transferred to the remote site3defined as the transfer destination as shown inFIG. 8.

The snapshot created is for a file, block, or volume written in the storage system12A.

When creating a snapshot for the first time, a snapshot of all data is created and transferred. In the second and subsequent creation of snapshot, data that is updated alone is transferred. This means that, upon start of backup, a snapshot of all data is created and every data is transferred to other sites whereas a snapshot is created for a differential of data and the data differential is transferred to other sites for backup from the next time on.

FIG. 8is a diagram showing a data flow between sites.

In the currently-used site1, synchronization request processing for creating a snapshot of data is carried out in step S31when the backup system (software group100) is started or otherwise initialized and when a request is made to create a snapshot.

The synchronization processing includes, as described later, creating a snapshot that indicates the physical location (the location in the storage system12A) of data to be backed up, creating identification information (for example, information unique to data such as time stamp and address), and holding the created data as management information for crosscheck of written data after the data is backed up on other sites (processing carried out by the data management module102ofFIG. 4).

Then the application server10A transfers the written data and the management information attached thereto to the remote site3, which is the transfer destination determined by the role definition (S32, the data transfer module104ofFIG. 4).

The server of the remote site3processes the received data as the role definition dictated following the flow chart ofFIG. 7. To elaborate, after receiving the data (S33), the server of the remote site3writes the received data in the storage system to execute backup (S34). Then the server transmits the data written in the storage system to the proximal site2, which is the transfer destination determined by the role definition (S35).

The data transmitted from the remote site3is received by the server of the proximal site2(S36). The server of the proximal site2processes the received data as the role definition dictates following the flow chart ofFIG. 7. To elaborate, after receiving the data (S36), the server of the proximal site2writes the received data in the storage system to execute backup (S37). Then the server transmits the data written in the storage system to the currently-used site1, which is the transfer destination determined by the role definition (S38).

The data transmitted from the proximal site2is received by the application server10A of the currently-used site1(S39). The application server10A of the currently-used site1processes the received data as the role definition dictated with the use of the software group100ofFIG. 4. To elaborate, after receiving the data (S39, the data receiving module105), the application server10A compares the management information of the received data with the data management information kept in step S31to crosscheck whether or not the data transmitted from the currently-used site1matches the data returned after backup to two sites. (S40, the data crosscheck module106ofFIG. 4).

When it is found as a result of the crosscheck that the two match, the data management information is updated in step S42whereas, when the two do not match, the process returns to step S32to transmit anew the data that has failed the crosscheck (S41). After the data management information is updated in step S42, backup processing for next data is started.

As described, data written in the currently-used site1is backed up to the proximal site2and the remote site3separately after management information unique to the data is attached to the data, so that the management information of the transmission data kept by the sender is compared with management information contained in data which has been looped through the sites and which has been received from the proximal site2. In this way, whether the data is correctly backed up or not can readily be crosschecked.

This means that the load required for crosscheck is not influenced by the number of sites to which data is backed up since, in the case of crosschecking data on the currently-used site1, which is the sender of backup data, the currently-used site1only has to compare management information of data received from a site where the data is backed up last with management information of the data transmitted which has been kept in the currently-used site1irrespective of the number of backup sites.

The processing in steps S31and S32and the processing from steps S39to S42are carried out by the data management module102to the data crosscheck module106of the software group100ofFIG. 4which is executed on the application server10A of the data sender.

Given next is a description of data management information created by the application server10A of the currently-used site1.

An example of data management information is shown inFIG. 9. The data management information uses a time point Ti at which a snapshot is created and which serves as time stamp. The time stamp makes the index of the management information. A management list40ofFIG. 9contains the length and value of data, additional information44(transmission time point42and retransmission counter43), and data address41. Data management information is added to the management list40for each time stamp Ti, in other words, whenever data is written in the currently-used site1and a snapshot is created. To elaborate, columns in the drawing each of which is composed of the address41, the additional information44, and data50are sequentially created with one column as one entry (record). Plural entries are managed by their time stamp Ti.

Data transfer processing is as shown inFIG. 10. The management information (the time stamp Ti, the address41, and the additional information44) is added in a preset data format to the data50and the data is then transmitted to the remote site3.

FIG. 10shows a data format example in which the time stamp Ti constitutes a section from the header (0 byte) of data to be transferred to 8 bits, the address41constitutes a section up to 12 bits, the additional information44constitutes a section up to 16 bits, and the data50including the data length is stored in a section from 17 bits and on.

An example of management information is given now. The time stamp Ti is composed of, for example, year, month, date, time, minute, second + 1/100 second. If a snapshot is created on Oct. 29, 2003 at 9:53:2:78, the time stamp is expressed as “2003102909530278”.

The address41of the data50is expressed by the logical location in a file system or the physical location in the storage system12A. For instance, when the address41is expressed by logical location, “file_a10” is expressed as “/nas/data/dir_a/file_a10”. For the data value, in the case of text data, “NAS backup method examples” and the like are stored.

The retransmission counter43indicates the number of times data is re-transferred due to non-match crosscheck results. The additional information44may include a counter indicating the number of timeout (in which transferred data fails to return in a given period of time), a counter indicating the number of non-match crosscheck results, or the like. Although the additional information44includes the transmission time point42in the example shown here, the transmission time point42may be omitted if data to be transferred is managed by the time stamp Ti.

In the management list40here, a group associated with the time stamp Ti may include data written in the currently-used site1at different timing. For instance, a first data block (e.g., block1) is written in the storage system12A and then is registered to the management list40in preparation of transfer. In registering the block1to the list, a time stamp T1at which a snapshot is created is stamped on the block1. Then a second data block (block2) is written in the storage system12A and, upon transfer, is registered to the management list40. If at this point the snapshot created at the time stamp T1includes the block1and the block2, the block1and the block2constitute a group of the management list40which has the same time stamp Ti as the index.

The snapshot and the management list40which are created by the above snapshot creating processing and data management information creating processing are stored in given area of the memory of the application server10A or the storage system12A shown inFIG. 1. The snapshots and the entries in the management list40are deleted when crosscheck results match as described later.

FIG. 11is a time chart showing an event where this backup system is put into operation.

As the backup system is started at a time stamp T0, initialization is performed first.

In this initialization processing, steps subsequent to step S10ofFIG. 6are executed to distribute role sharing information throughout sites to which data is to be backed up. Thereafter, a snapshot of all data is created by processing described later and by the data synchronization request ofFIG. 8to synchronize data of the currently-used site1with data of the proximal site2and the remote site3to which data is to be backed up.

After that, receiving a write request, the application server10A stores data in the storage system12A before creating a snapshot of data updated at the time stamp T1.

Since data has been synchronized among the sites at the time of initialization processing, differential data alone is transferred for data synchronization among the sites in creating a snapshot from the time stamp T1on. When a write request is received to the currently-used site1, it only has to manage differential data and the load of processing the write request can be reduced.

Referring to flow charts ofFIGS. 12 and 13, a description is given on details of the above snapshot creating processing, data management information creating processing, and data transfer processing.

The first step inFIG. 12is step S55in which whether the snapshot processing type is initialization or not is determined. In the case of initialization, the process proceeds to step S56. After completion of initialization, the snapshot processing type is determined as normal snapshot creating processing and the process proceeds to step S60.

Upon initial start of this backup system, target data is initialized so that “no snapshot of the target data has been created yet”. This state is determined at the time of creating a snapshot. The target data can be file-unit data, volume-unit data, or the like as described above.

In the initialization processing of step S56, ‘i’ in the first time stamp Ti is set to 0 and a snapshot is created as the time stamp T0. In step S57, data management information is created for all data. Then, in step S58, area for the management list40and for a snapshot which are to be used at the next time stamp T1are created and initialized.

In step S59, the data created for the time stamp T0in step S57is transferred to the remote site3. Upon transferring the data, current time is written as the transmission time point42in the management list40and the value of the retransmission counter is initialized.

In step S60for the second and subsequent snapshot createing processing, a time stamp T(i) is created and the latest snapshot time is created as well in order to take a backup after a write request is received to the application server10A as shown inFIG. 1.

In step S61, area for the management list40and for a snapshot which are to be used at the next time stamp T(i+1) are created and initialized. In the second and subsequent snapshot creating processing, a snapshot of updated data is created by write request processing, which will be described later.

In step S62, the data created for the time stamp T(i) in step S60is transferred to the remote site3. Upon transferring the data, current time is written as the transmission time point42in the management list40.

Referring to the flow chart ofFIG. 13, processing performed upon the write request ofFIG. 11is described next.

When the application server10A receives the write request, address of this data and management information containing the data are created in step S65. In other words, an entry of management information having the next time stamp T(i) as the index is added to the management list40.

In step S66, an instruction is issued to write this data to the storage system12A.

Through the processing ofFIGS. 12 and 13, a write request after completion of initialization starts creation of management information of data to be written which is followed by creating of the time stamp T(i) and a snapshot as well, and the data written in the currently-used site1is transmitted to the remote site3based on role definition (role sharing information).

When management information of T(i+1) is created by the write processing (FIG. 13), it is required, each time data is written, to determine whether or not management information is already created in order to create area for the next data in steps S58and S61. This could prolong data writing processing. The write processing can be made lighter by using the snapshot creating processing to create area since creating data management information is approximately equivalent with creating a snapshot.

Through the processing of step S65, original data (transfer data) to be compared is stored in data management information and relevant data is taken out of the data management information for comparison in the crosscheck processing.

Data contents at the time stamp Ti are therefore kept in data management information so that data contents of the currently-used site1at the time stamp Ti can be synchronized with other sites and so that no problem is raised from writing data of the same address at a time stamp subsequent to the time stamp Ti over the data at the time stamp Ti.

In short, in the case where data is updated several times at the same address in the storage system of the currently-used site1, data (value) of the data management information list that has the same address is written over by the processing of step S65.

A detailed description is given next with reference to a flow chart ofFIG. 14on the data crosscheck processing carried out in step S40ofFIG. 8.

In step S70, the time stamp Ti and the address41are extracted from management information of data transmitted from the proximal site2and received by the application server10A as shown inFIG. 10. Then the management list40is searched with the time stamp Ti as the index to extract data that has matching address41from the relevant entry stamped with the time stamp Ti.

In step S71, the received data is compared with the data50of the management list40to determine whether the two match or not.

To compare the received data with the data50kept in the management list40, the two may be crosschecked for bit by bit, or checksum may be created upon transmission and compared for crosscheck of the data. Alternatively, a part of the received data may be compared with a part of the data50for crosscheck. For instance, a section from the header of the data to a given bit number, a section from the tail of the data to a given bit number, a section stretching over a data border for a given number of bits, or the like may be used for crosscheck. The data border refers to the border between data blocks, the border between packet data, and the like.

When the received data and the data50of the management list40coincide with each other, the process proceeds to step S76whereas the process proceeds to step S72when the two do not match.

In step S72where received data which returns after being looped through the sites does not match the data50of the management list40, the retransmission counter43of the management list40is read to whether or not the read count of the retransmission counter43exceeds a given retransmission count.

When the read count of the retransmission counter43exceeds the given retransmission count, the process proceeds to step S74to notify a not-shown display device or the like of the application server10A of a retransmission error (notification of the fact that the given retransmission count is exceeded). In this way, an administrator of the application server10A or the like can be notified of several malfunctions that have taken place in the process of looping backup data from the currently-used site1through the remote site3and the proximal site2.

When the given retransmission count is not exceeded but there is a retransmission error, the process proceeds to step S73to warn a not-shown console or the like of the application server10A of a data crosscheck error.

The process then proceeds to step S75where the count of the retransmission counter43of the management list40is incremented and the transmission time stamp is updated to transmit the original data50again.

The processing of steps S72to S75corresponds to the processing of steps S39to S41and S32shown inFIG. 8.

In step S76where the data received from the proximal site2is determined in step S71as matching the data50of the management list40, the transmission time point42is extracted from the management information of the data50and is compared with the time stamp at which the data is received in step S70to determine whether or not the arrival time (reception time point—transmission time point42) exceeds a preset standard time.

When the arrival time exceeds the standard time, the process proceeds to step S77to warn a not-shown display device or the like of the application server10A of lowered performance of a backup site or an external network. The warning enables an administrator of the application server10A or the like to surmise that there is an increase in traffic of the external network or the performance of the server is, for example.

In step S78, an entry for which the received data and the data50of the management list40coincide with each other is deleted.

In step S79, it is determined whether every entry with the time stamp Ti serving as the index of the data50has been deleted or not. When every entry that is managed by the time stamp Ti is completely deleted, the process proceeds to step S80to delete the snapshot that corresponds to the time stamp Ti and to delete index of the time stamp Ti from the management list40, thereby completing the processing. The processing of steps S78to S80corresponds to the data management information update processing of step S42shown inFIG. 8.

With the data crosscheck processing, data which returns from being looped from the currently-used site1through the remote site3and the proximal site2is compared to the data50of the management list40which is created prior to transmission to crosscheck, upon the return of the data, whether or not a backup is correctly taken on each backup site. Since the application server10A only has to crosscheck data from the site where a backup takes place last irrespective of the number of backup sites, an increase in number of backup sites does not lead to an increase in load of the application server10A. Therefore, the crosscheck processing merely requires very small load even in a backup system that has a large number of backup sites.

FIG. 15is a flow chart showing an example of timeout monitoring processing which is executed at regular time intervals (for instance, an interval of several hundreds msec.) on the application server10A of the currently-used site1.

In the currently-used site1which serves as a sender and where data transmitted and returned from looping is crosschecked at the time of the return, processing described below is carried out when the data is prevented from returning by failures in the backup sites2and3or in an external network.

First, in step S91, an entry with the transmission time point42is taken out of the management list40to compute a time difference between current time and the transmission time point42.

In step S92, it is determined whether the created time difference exceeds a preset timeout determining value (a fixed time period) or not.

When the time difference is equal to or lower than the timeout determining value, the processing is ended. On the other hand, when the time difference exceeds the timeout determining value, the process proceeds to step S93and the count of the retransmission counter43is read to determine whether or not the count of the retransmission counter43is equal to or lower than the preset retransmission count.

When the count of the retransmission counter43is equal to or lower than the given retransmission count, the process proceeds to step S95to warn a not-shown display device or the like of the application server10A that transmission timeout has taken place. Then the process proceeds to step S96to transmit the data50again. Upon retransmission of the data50, the count of the retransmission counter43is incremented and the transmission time stamp is updated in the relevant entry.

On the other hand, when the count of the retransmission counter43exceeds the given retransmission count, the process proceeds to step S94to notify a not-shown display device or the like of the application server10A that a transmission timeout error has taken place and that the retransmission count has exceeded the regulated count.

The processing of steps S91to S96is performed on the first through last entries of the management list40in order.

The above processing makes it possible to detect with precision that return of the data transmitted is inhibited by failures in the proximal site2and the remote site3to which data is to be backed up and in an external network, and to notify an administrator of the application server10A or the like that the crosscheck processing cannot be carried out.

As has been described, according to the present invention, the currently-used site1serving as a sender of backup data transmits the backup data to a single site and receives data returned from being backed up to one or more sites. In this way, backup and crosscheck of backup data are achieved at very small processing load and data can correctly be backed up between plural sites while simplifying the management procedure of data update.

In addition, timeout monitoring processing is performed at regular time intervals and a warning is given when data cannot be received from the last backup site in the loop, thereby prompting an administrator of the application server10A or the like to take an appropriate action.

The error alarm (notification) issued in step S94ofFIG. 15may be replaced by processing that stops the backup system since in step S94the retransmission count has exceeded the regulated count and a transmission timeout error has taken place which means that a backup site or an external network may have stopped operating.

Although the embodiment described above shows an example in which the application server10A is connected to the storage system12A via the intra network11B, the backup processing can be carried out by the NAS servers10C and10D and file servers10E and10F shown inFIG. 1instead of the application server10A. Furthermore, the NAS servers10C and10D may be replaced by NAS heads.

MODIFICATION EXAMPLE 1

Shown in the embodiment described above is an example of creating a snapshot. Instead of creating a snapshot, a time point at which data is written in the storage system12A may be used as the time stamp Ti. Alternatively, a time point at which management information is created may be used as the time stamp Ti to manage the management list40.

The present invention is not limited to the use of the time stamp Ti and synchronization may be achieved in a manner that makes a backup site catch up with data contents of the currently-used site1.

In this case, synchronization processing started upon a synchronization request (FIG. 8) lasts until data inconsistency between the sites is solved and the backup site only has to make its data contents match the latest data contents of the currently-used site1instead of synchronization based on a snapshot which is data contents at a specific time point. Of the data management information shown inFIGS. 9 and 10, the time stamp and the data50are thus made unnecessary and the information may be managed by the address41. This means that the substance of data is not contained in data management information and that data stored in the address41that is specified by the data management information is created upon crosscheck. In this case, the path of creating a snapshot which is shown inFIG. 12is unnecessary and, in step S65ofFIG. 13, the transmission time point42of the data management information is reset as data of the same address is written.

MODIFICATION EXAMPLE 2

Backup data is looped to the sender for crosscheck in the embodiment described above. Alternatively, a sender of backup data and a site which performs crosscheck may be separate sites as shown inFIG. 16. InFIG. 16, the currently-used site1transfers backup data to the remote site3and at the same time transfers management information (the management list40) to the proximal site2, which is the last backup site in the loop.

Receiving data from the remote site3, the proximal site2writes the data in the storage system and then executes processing similar to the one in the above embodiment to crosscheck the written data against the management list40received from the currently-used site1.

This makes it possible to further reduce the load of the application server10A of the currently-used site1serving as a sender of backup data, and the response of the application server10A of the currently-used site1can be improved in write processing or the like.

In the case where there are plural backup sites as this, data crosscheck can be performed by a sender site or any one of the backup sites. Preferably, the last backup site in the loop performs the crosscheck since this way the data consistency can be ensured.

The role of the respective sites can be changed at any time according to the role definition shown inFIG. 5. It is therefore possible to change the flow of backup loop and the site that performs crosscheck arbitrarily by merely changing the processing after reception of data and the data transfer destination in the role definition as long as the software group100is set in each site.

MODIFICATION EXAMPLE 3

InFIG. 1, the currently-used site1and the proximal site2are connected through an external network. Instead, the same SAN11B may be used to connect the storage system of the currently-used site1and the storage system of the proximal site2.

In this case, the backup system (the software groups100and200) may be run on the application server10A as in the above embodiment or may be run by the control module121of the storage system12A. The latter makes it possible to reduce the load of the application server10A even more and, in addition, the storage system12A can improve the overall performance of the backup system by communicating with another storage system12A via the same SAN11B at high speed.

MODIFICATION EXAMPLE 4

The servers of the respective sites in the above embodiment are connected to one another through an external network. Alternatively, the control module121of the storage system12A on one site may be connected to the control module121of another site through an external network, so that the software group100or200of the above embodiment is executed by each control module121.

The storage system12A in the above example has disk drives, which may be replaced by tape devices or optical disk drives.

The address41as management information may be the physical storage position in the storage system12A instead of the file position employed in the above embodiment.

When the address is the physical storage position, the currently-used site1and other sites usually have to have an identical physical configuration and therefore the same data is stored at the same address in the respective sites. On the other hand, when the address is logical information, the sites do not need to have an identical physical configuration.