JPH11102262A - Disk subsystem and remote backup system by magnetic tape library device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To preserve data on a disk subsystem to be the object of direct access from a host into a magnetic tape library device installed away from the disk subsystem while multiplexing these data against the fault of the disk subsystem caused by a disaster or the like. SOLUTION: This backup system is a computer system provided with a disk subsystem 3 for recording data from a host computer 1 and a magnetic tape library device 5 installed away from the disk subsystem 3. In this case, the disk subsystem 3 and the magnetic tape library device 5 are connected through a remote server 6 provided separately from the host computer 1, and data transfer is executed for multiplexing the data from the disk subsystem 3 to the magnetic tape library device 5 without through the host computer 1 under the control of the remote server 6.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a computer system, which prepares data on one or a plurality of disk subsystems directly accessed by a host in preparation for a failure of the disk subsystem caused by a disaster or the like.
Installed away from the disk subsystem,
The present invention relates to a system for multiplexing and storing data in one or more magnetic tape library devices which are not directly accessed by a host.

[0002]

2. Description of the Related Art As a measure for protecting data on a disk subsystem in a computer center (hereinafter referred to as a "primary center") which performs normal business processing from a failure caused by a disaster or the like, there are roughly two types of measures as described below. The scheme has been adopted.

In the first method, the same system configuration as that of the primary center is provided in a secondary center located at a remote location from the primary center, and the hosts of both centers are connected by a line, and transactions generated in the primary center are transferred to the secondary center. This is a method in which the entire system is completely duplicated by transmitting the same transaction to both centers and executing the same transaction processing in both centers. In the method of sending a transaction to the secondary center according to the above method, a journal which is transaction history information is temporarily recorded on a magnetic tape device or the like in the primary center, and this is recorded on the secondary center based on the history information by file transfer or transport. There is also a means to re-execute (re-run) transaction processing.

A second method is a method in which two or more disk subsystems are directly connected to each other without using a host, and only important data on the disk subsystems is duplicated by a function of the disk subsystem. Yes, recently announced by various companies and already commercialized. IBM is 3
PPRC realized by 990-6 disk controller
(Pier to Pier Remote Cop
y) Function, SRDF (Symmetric
A Remote Data Facility function or the like corresponds to this. Both functions directly connect the disk subsystem on the primary center side and the disk subsystem on the secondary center side, duplicate the data on the disk volume on the primary center side on the disk volume on the backup side, and duplicate the data. It is a function to perform conversion.

Japanese Patent Application Laid-Open No. 06-214853 describes in detail a system configuration and a realization method for a remote copy function similar to the above-mentioned PPRC and SRDF. According to this, two disk subsystems connect the respective disk subsystems, and one of the subsystems is connected to the host as a primary subsystem.

[0006]

In the first method, since the secondary center needs to adopt the same system configuration as that of the primary center, the cost of implementing the system is large. Also, since the transaction transfer processing is borne by the host in the primary center,
There is a concern that the host load on the primary center will increase, which will affect the performance of normal business processing.

On the other hand, in the second system, since only the disk subsystem is duplicated, the system configuration can be constructed at a lower cost than in the first system. However, the disk subsystem is the most expensive external storage device of the computer system, and the cost burden to the user is not small. Further, in the second method, data is exchanged between disk subsystems without passing through the host, so that the host load is reduced as compared with the first method. However, since it is realized by the function of the disk subsystem,
The disk subsystems of the primary center and the secondary center must be provided with a function of exchanging data with each other, and a dedicated device must be purchased in the backup system, which eventually increases costs.

An object of the present invention is to provide means for implementing a low-cost backup system for disaster countermeasures. A second object of the present invention is to realize a backup system without imposing a load on a host computer.

[0009]

In order to solve the above problems, the present invention mainly employs the following configuration.

A computer system comprising: a disk subsystem for recording data from a host computer; and a magnetic tape library installed at a position remote or close to the disk subsystem. A remote backup system that directly connects the magnetic tape library device without passing through the host computer and executes data transfer for data multiplexing from the disk subsystem to the magnetic tape library device.

In the remote backup system, the transfer data for multiplexing comprises information on a disk volume in the disk subsystem and update history information on the information, and Copy all information of any disk volume to one or a plurality of tape volumes of the magnetic tape library device, and the update history information is a record unit of a record stored in a disk volume in the disk subsystem. When data update processing has occurred, the updated data is added to the disk volume identification number, the positioning information where the record is stored, and the time information at which the update processing occurred, Any tape cartridge in the magnetic tape library device The over arm, the remote backup system, which is recorded in the order in which the update occurred.

In the remote backup system described immediately above, when a failure occurs in the entire disk subsystem or a part of the disk volume, the copied information of the entire disk volume and the update history information of the tape volume are provided. A remote that restores all data of the failed disk volume to the state immediately before the failure to another failed volume in the disk subsystem or to a disk volume in a separately installed subsystem in the disk subsystem Backup system.

[0013]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an example in which the present invention is applied to a general-purpose computer system will be described with reference to the drawings. FIG. 1 shows an example of a configuration in which the present invention is applied to a disaster backup system of a general-purpose computer system, in which a disk subsystem on a primary center side and a magnetic tape library device (Ma) on a secondary center side are shown.
By connecting a magnetic tape library (MTL) via a remote server having a control mechanism different from that of the CPU without using a CPU, data is duplicated between the two devices.

In FIG. 1, 1 is a central processing unit C
The PU 3 is connected to the CPU 1 via the interface cable 2 and stores a disk subsystem (hereinafter referred to as D) that stores data to be directly referenced and updated from the CPU 1.
ISK) and 5 are magnetic tape library devices MTL that are connected to 3 via an interface cable 4 and a remote server (hereinafter referred to as RS) 6 to be described later and store a copy of data stored in 3. Reference numeral 7 denotes a disk controller (hereinafter referred to as a DKC) which is a control unit for reading and writing data in the DISK 3.
Is a disk volume (hereinafter referred to as LD) to which data is actually stored and is directly read and written from the CPU 1.
This is a disk drive (hereinafter referred to as DKU) in which a plurality of EVs 9-1 to 9-1-n are stored.

Next, DKC 7 and MT in DISK 3
The internal configuration of each L5 will be described. In the DKC 7, reference numeral 10 denotes a channel interface control unit (hereinafter referred to as CH) for controlling the exchange of control information such as data and data read / write instructions between the CPU 1 and the RS 6.
D) and 11 are cache memories (hereinafter referred to as caches) used to temporarily buffer data when data is read / written between the CPU 1 and the RS 6 and the LDEV 9, and 12 is a cache memory used for data transfer from the LDEV 9 to the cache 11. A disk interface control unit (DID) controls read processing and data write processing from the cache 11 to the logical volume (logical device) LDEV 9.

In the MTL 5, 13 is a higher-level device (RS
6) Reading of data recorded on the tape and RS
6, a magnetic tape device for writing the data transferred from the device 6, ie, a recorder (hereinafter referred to as MT), and a tape volume 15/16/17 and a storage shelf 1 for storing the same.
8. A library device including an accessor robot for mounting / demounting the tape volume 15/16/17 on the MT13. Tape volume 1
Reference numerals 5, 16, and 17 denote tape volumes 15-1 to 15-n for storing the dump data, tape volumes 16-1 to n for storing the log data, and tape volumes 17-1 to 17-n used in the operations of the secondary center. They are logically classified and managed by species (hereinafter referred to as logical groups). In the present embodiment, a magnetic tape library device including a recorder, an accessor robot, a tape volume, and the like will be described below. However, the present invention can be applied to other magnetic tape storage devices.

The RS 6 is a control mechanism other than the CPU 1 interposed between the DISK 3 and the MTL 5, and has a function of transferring data of the DISK 3 to the MTL 5 via the interface cable 4 without receiving an instruction from the CPU 1. is there. The RS 6 20 is a memory for storing control information such as a management table for managing the association between the LDEV for which an update instruction has been issued from the CPU 1 and the tape volumes 15 and 16 corresponding thereto. Also R
Although S6 has an independent configuration as a control mechanism in FIG. 1, it may be incorporated in the MTL 5.

The system configuration for realizing the functions of the present invention has been described above. The spare DISK 21 and the LDEV 9 'and CPU 22 in the DISK shown in FIG. It is used when recovering data.

Next, an outline of functions and operations of the disaster backup system according to the present embodiment will be described with reference to FIGS. FIG. 2 shows an outline of functions used during normal operation (when no disaster has occurred). In a normal operation, a process of periodically dumping all data of the LDEV 9 in the disk 3 to the tape volume 15 of the MTL 5 as shown in FIG.
LDEV in DISK3 from CPU1 as shown by b-1 in the figure.
Every time the record recorded in No. 9 is updated, b
-2 Update history information (log information)
To perform recording on the tape volume 16 in the MTL 5.

Since the update process to the LDEV 9 can occur during the dump acquisition, the dump process and the log acquisition process are performed simultaneously. Hereinafter, a logical group of tape volumes 15-1 to 15-n for storing dump data is referred to as a dump pool, similarly, tape volumes 16-1 to n are referred to as a log pool, and tape volumes 17-1 to 17-n are referred to as a secondary center business pool. It shall be.

FIG. 3 shows an outline of functions / operations in the event of a disaster in the primary center. In this embodiment, as described above, an example in which the data of the LDEV 9 of the primary center is recovered to the LDEV 9 ′ of the spare disk 21 of the secondary center (the disk subsystem 3 is provided instead of using the spare disk 21 of the secondary center) (It is also possible to perform a recovery process using a spare disk not shown).) First, as shown in a in the figure, the M in which the dump data of the LDEV 9 to be recovered is stored.
The data of the tape volume 15 in the dump pool of the TL 5 is copied to the LDEV 9 ′ of the spare DISK 21.

Next, among the update logs recorded in the tape volume 16 in the log pool as shown in FIG.
Using the log data obtained immediately before the latest dump data of the DEV 9 and the log data immediately before the occurrence of the disaster, the DISK volume on the spare DISK is updated to the latest state immediately before the failure. As a result, the data immediately before the failure on the LDEV 9 'is recovered on the spare DISK.

The details of the above-described dump and log processing during normal operation and recovery processing when a disaster occurs will be described below. First, the flow of the dump process will be described with reference to FIG. Prior to the execution of the dump process, the user initially sets the dump start time, the number of the LDEV to be dumped, and the address of the tape deck of the MT 13 used for the dump process for each target LDEV from the RS 6 in advance.

In this embodiment, as described above, the MTL5
Tape pools in the dump pool, log pool,
It is managed by dividing into three pools called secondary center business pools. The management of the correspondence between the tape volume and the pool utilizes the function of the tape attribute management of a general tape library device for large general-purpose computers.

In this function, the user sets in advance the attribute No. for each volume identification number (hereinafter, VSN: volume serial number) of the tape volume. Is specified, the subsequent tape volume can be loaded into the tape deck (mount).
Is the attribute number. , The tape library automatically selects an arbitrary tape volume having the specified attribute.

The attributes of each tape volume can be freely changed by the user and software. In this example, the tape volumes in the dump pool and the log pool are further classified into used and unused, and the dumped tape volume has the attribute D1, the empty tape attribute has the attribute D0, the log acquired tape volume has the attribute L1, and the same. The attribute of the empty tape is managed as L0. In this way, when the RS 6 issues a tape volume mount instruction at the time of dump acquisition or log acquisition, specifying the D0 or L0 attribute can prevent unauthorized overwriting on the dump acquisition tape.

Therefore, in addition to the initial setting, the user can select RS
6 must be instructed to set all the attributes of the tape volume used for dumping to D0. R
S6 receives this and instructs the MTL 5 to set the D0 attribute of the tape volume, and the MTL receives this and sets the attribute. LDEV N initialized by user
o. The tape deck address is registered in the dump management table stored in the memory 20 shown in FIG.

After completion of the initial setting, the RS 6 refers to the dump management table at the designated dump start time and refers to the subsystem No. to be dumped. And LDEV No. In the ascending order, the tape volume of the D0 attribute is designated for the tape deck of the address designated to each LDEV 9.
Issue a command to input (hereafter, mount).

Note that a plurality of LDEV Nos. If a tape deck having the same address is designated for the For other than the LDEV, the mount command is not issued until the dump processing of the LDEV is completed. On the MTL5 side receiving the mount command, the accessor robot 1
9 mounts an arbitrary tape volume from among the tape volumes 15 designated with the D0 attribute, and reports a mount completion to the RS 6 together with the tape volume VSN. The RS 6 temporarily stores the VSN in the memory 20.

Next, the RS 6 temporarily stores the dump start time (current time) in the memory 20, and stores the CH
A READ command (hereinafter referred to as RD) for reading the data of the dump acquisition target LDEV is issued to D10. R
D is a command for requesting data reading from the LDEV 9. DI of DISK3 that received the RD command
D12 reads the data of the specified LDEV 9 to the cache 11, and CHD10 reads the data from the cache to the RS.
Transfer to 6.

If the requested data already exists in the cache, the CHD 10 directly transfers the data from the cache 11 to the RS 6. CHD after reading is completed
10 reports the completion of the READ process to RS6. Next, upon receipt of the completion report, RS6 sends WR to MT13 of MTL5.
Issue an ITE command (hereinafter WR). Here, WR is an instruction for writing data to the tape volume and a command for transferring the write data itself.

The MT 13 that has received the WR command writes the data transferred to the tape volume 15 already mounted. Read the data from DISK3,
The unit for writing data to the tape volume 15 is arbitrary, such as a record unit and a track unit on the LDEV 9 side, and is repeated until the last LDEV data to be dumped. DIS report last data detection report of LDEV to be dumped
After K3 reports to RS6, RS6 temporarily stores the dump end time (current time) in memory 20 and issues a demount command for the tape volume to MTL5.

After the MTL 5 receives the tape volume demount instruction, the accessor robot 19 demounts the tape volume from the tape deck of the MT 13, and
The shelves are transported to the position before the mounting of the storage shelf (hereafter, home cell) and the completion of demounting is reported. RS that received the report
6 indicates the attribute of the tape volume as D0 for MTL5.
To D1 and the MTL 5 changes the attribute.

Upon receipt of the attribute change completion report from the MTL 5, the RS 6 refers to the dump management table and
When the VSN of the V storage tape volume is recorded, the MTL 5 is instructed to change the attribute of the VSN (old dump data storage VSN) from D1 to D0. VS
N No. Is not stored or MTL5 indicates
When the report of the attribute change from 1 to D0 is received, RS
Reference numeral 6 updates the VSN (new dump data storage VSN) and the dump end time stored in the memory 20 in the respective items of the LDEV in the dump management table to update the table information.

Next, referring to FIG.
A description will be given of the flow of an update log acquisition process when an update instruction is issued from the CPU 1 to data in the DEV 9. In this embodiment, one disk subsystem is used as an update log acquisition unit, and the update information generated in the subsystem is recorded on the same tape volume 16 in the order in which the updates occurred.

In the initial setting before the log is acquired, RS6
Specify the address of the deck to be used for each subsystem to be logged. Similarly to the dump processing, the log volume of the log volume of the tape volume 16 is managed by the log acquired attribute (L1) and the empty attribute (L0).
6 specifies that all the attributes of the VSN of the tape volume 16 used for log acquisition are changed to L0, and the RS 6 instructs the MTL 5 to change the attribute of the tape volume. The MTL 5 changes the attribute of the designated volume and reports the completion to the RS 6.

When the initialization is completed, the RS 6 sends the tape volume 1 having the L0 attribute to the MTL 5 before starting the log acquisition.
6 is issued. MTL5 is any volume from tape volume with L0 attribute to MT1
3 and reports the VSN of the tape volume together with the mount completion report, the RS 6 writes the VSN in the log management table of the memory 20.

As shown in FIG. 7, the log management table is used for time consistency with the dump data at the time of recovery from a failure. Thus, the log can be obtained. CPU
When the data update processing to the LDEV 9 in the DISK 3 occurs at 1, the CPU 1 issues a WR command for writing data to the CHD 10. DISK3 is W
The update data sent by the R command is temporarily stored in the cache 11, and a write completion report is made.

Next, the CHD 10 adds control information to the WR data and writes the control information as log data in a log area on the cache 11. As shown in FIG. 8, the log data includes, in the update data itself, an update occurrence time serving as information necessary for recovery when an LDEV9 failure occurs, and an LD storing the data.
This is data to which positioning information including the EV number and the cylinder, track, and record number (CCHHR) of the data (record) is added, and is stored in an area different from the update data.

When the update data is reflected from the cache 11 to the LDEV 9, the DID 12 collectively reflects (destages) the plurality of data in the LDEV 9 when a certain amount of data is accumulated in the cache 11 by the plurality of update data from the CPU 1 to the DISK 3.

This function is a function aimed at increasing the efficiency of I / O processing of a general cache disk subsystem.
In this example, the CHD 10 issues a log data read request to the RS 6 in synchronization with the destaging process. As a result, the log data also accumulates to some extent in the cache 11 and is collectively read out to the RS 6, so that the log data readout can be made more efficient.

RS6 which received the log data read request
Issues an RD command for reading log data to CHD10 of DISK3. The CHD 10 transfers log data from the log area in the cache 11 in the order updated by the CPU 1. When receiving the log data, the RS 6 checks the update occurrence time of the tape volume in the log management table, and if the time is not recorded, records the update occurrence time in the first log data in the log acquisition start time of the log management table. I do.

Next, in this embodiment, the RS 6 is the MT 1 on which the tape volume for log acquisition is mounted before the MTL 5.
3 is instructed to write log data in the order in which the data was received from DISK3. MT of the log data
FIG. 8 shows a format when writing to the L5 tape volume 16. First, the subsystem number for which a log is to be acquired and the time at which the first data is updated are recorded in order from the beginning of the tape volume. This time is the same as that recorded in the log management table. When the information in the log management table is lost for some reason, the information is effective information for identifying log information updated in record units from the CPU 1 recorded subsequently to the information on the tape volume. Becomes

Next, the MT 13 records a plurality of log data received from the RS 6 on the tape volume 16 in the order received from the RS 6. When the MT 13 detects the end information of the tape volume while writing the log data, the MTL 5 reports the end of the tape volume to the RS 6 to end the process of reflecting the log data on the tape volume.

After receiving this, the RS 6 writes log data for one batch write to the tape volume 16 and then instructs the MT 13 of the MTL 5 to demount the tape volume. The MTL 5 executes the demount processing in the same manner as the demount processing in the dump. When the demount is completed, the MTL 5 returns a demount completion report to the RS 6.

Next, the RS 6 writes the update occurrence time of the log record last written to the tape volume in the log management table, changes the attribute to L1, and simultaneously sets
An instruction to change the attribute of the tape volume to L1 is issued to TL5. After changing the attribute, the MTL 5 returns a completion report to the RS 6. Upon receiving the attribute change completion report from the MTL 5, the RS 6 refers to the dump management table storing the dump data of the same subsystem as the log management table storing the log data, and checks the LDEV of each LDEV of the dump management table. By comparing the youngest dump start time among them with the last log data update occurrence time recorded in the log management table, if there is a VSN having log data older than the dump start time, the RS6 sends the corresponding tape volume to the MTL5. Is changed to the attribute of L0. After changing the attribute, the MTL 5 returns a completion report to the RS 6.

Next, the RS 6 issues a mount request to the MTL 5 to mount the L0 attribute tape volume on the designated deck. When the mounting is completed, the MTL 5 notifies the RS 6 of the completion of mounting. For the WR command of the log data until the completion of the mounting, MT13
Returns a response indicating that the mount has not been completed, so that the RS 6 waits for the WR command to be issued until the mount is completed.

Next, when a failure occurs in the entire disk subsystem or a part of the LDEV, the dump data and the log data are combined, and the LDEV in another subsystem is combined.
An example of recovering all data of a failed volume will be described with reference to FIG.

Prior to data recovery, the user specifies to the RS 6 the address of the tape deck of the MT 13 used for each LDEV to be recovered and the address of the recovery destination LDEV 9 ′ for the LDEV data. In response to the designation from the user, the RS 6 refers to the dump management table in the memory 20 and obtains the VSN of the tape volume 15 in which the dump data of the LDEV to be restored is stored.

Next, the RS 6 sends the restore target L obtained previously to the deck of the address designated for each recovery target LDEV.
A mount command for instructing mounting of the tape volume 15 of the DEV VSN is issued to the MTL 5. RS6
Confirms that the mounting of the tape volume has been completed, issues an RD command to the MTL 5 in order to read data from the tape volume of the designated VSN.

When the MTL 5 receives the RD command, it reads the dump data of the LDEV to be restored from the tape volume. Next, RS6 is the backup DISK
MTL5 was added to the recovery target LDEV 'of the 21 target LDEVs.
After issuing a WR command for writing the read LDEV data to be restored, the spare DISK 21 writes the data to the LDEV 9 ′, and then reports completion of the writing to the RS 6.

The reading of data from the tape volume 15 and the writing to the LDEV 9 'of the spare DISK 21 are repeated in arbitrary units until all the reading / writing of the dump data stored in the tape volume 15 is completed. When a plurality of LDEVs to be recovered are specified, LDEV No. The above processing is repeated for the specified number of times in ascending order of. Alternatively, when a plurality of tape decks of the MT 13 that can be used for the recovery processing can be secured and a plurality of LDEVs 9 ′ of the recovery destination spare disk 21 can be secured, the recovery processing for a plurality of LDEVs can be executed in parallel.

Next, after all the copying of the dump data of the specified LDEV 9 is completed, the RS 6 refers to the log management table and reads the top of the VSN in which the log data of each subsystem in which the recovery target LDEV exists is stored. A mount command for the tape volume of the VSN with the oldest update occurrence time is issued to the MTL 5. After confirming that the mounting of the tape volume has been completed, the RS 6 issues an RD command to the MTL 5 in order to read the leading log data stored in the tape volume. The MTL 5 that has received the RD command transfers the log record to the LDEV 9 ′ of the disk 21, which is the recovery destination of the target LDEV 9 stored in the tape volume, to the RS 6.

The RS 6 analyzes the transferred log record and determines the LDEV No. And positioning information (CCHHR). The LDEV No. Is determined to be a recovery target LDEV, and if it is a recovery target, actual data is extracted from the log record and the data is transferred to the recovery destination LDEV of the DISK 21.
In order to write to the CCHHR in DEV9 ', WR
A command is issued to the disk 21 to write the data. The LDEV No. Is not the recovery target LDEV, the RS 6 deletes the record from the memory 20.

Thereafter, the RS 6 sequentially reads out the log records and writes only the actual data in the log records of the recovery target LDEV to the recovery destination LDEV. Log record read / data LDEV 'to end of tape volume
When the writing to the tape volume is completed, the RS 6 instructs the MTL 5 to demount the tape volume, and, upon receiving the demount completion report from the MTL, continuously selects the VSN of the second oldest tape volume of the head update occurrence time from the log management table. , And issues an instruction to mount the tape volume to the MTL 5.

After the mounting is completed, the log record reflection processing is performed similarly to the first tape volume. The above processing is repeated until the log data obtained immediately before the occurrence of the failure, and the data of the recovery target LDEV 9 is
To the LDEV 9 'to the state immediately before the occurrence of the failure.

In the remote backup of the computer system as described above, the data transfer control exchange between the disk subsystem 3 and the remote server 6 and the magnetic tape library device 5 and the remote server 6 are as follows.
This is performed by using a command similar to a command used in controlling data transfer between a general host computer, a disk subsystem, and a magnetic tape library device.

Further, in the remote backup of the computer system, when the data of the disk subsystem 3 is recorded on the tape volumes 15 and 16, the host 1
It is also possible to configure the system so that data can be recorded in the same format (standard label) as the format defined by the operating system, and the dump data can be directly read from the host 1.

The CPU 1 and the CPU 22 shown in FIG.
, It is also possible to access the disk subsystem 3 and the magnetic tape library device from either CPU.

As described above, according to the present invention, as a main configuration, a magnetic tape library device is placed on the secondary center side, and this is connected to the disk subsystem on the primary center side without going through a host. A copy (dump) of all data of the entire system or an arbitrary disk volume and an update history (log) of each volume are acquired by the magnetic tape library device. When a failure occurs in the system, recovery can be performed by combining dump data and log data acquired by the magnetic tape library device.

Further, the present invention can adopt the following constitution other than the invention described in the claims.

When a failure occurs in the entire disk subsystem or a part of the disk volume, the disk subsystem and the magnetic tape library device are connected via a control mechanism different from the host computer, and controlled by the control mechanism. By combining the data copy of the entire disk volume and the log of the relevant volume without passing through the host, all data of the failed volume can be transferred to another volume in the relevant subsystem or a disk volume in another subsystem to the state immediately before the failure. Restore
Remote backup system.

[0063]

According to the present invention, as a backup system for a disk subsystem in a disaster backup system, a magnetic tape library device that is less expensive than a disk subsystem can be used for an external storage device on the secondary center side. The system construction cost can be greatly reduced as compared with a disaster backup system in which the system itself is duplicated or the disk subsystems are duplicated.

The disk subsystem and the magnetic tape library device are connected not via the host but via a remote server which is a control mechanism other than the host, and the control mechanism is responsible for duplicating both data. Since the magnetic tape library device on the secondary center side does not require a dedicated function, there is an advantage that an existing device can be used.

Further, regarding the processing accompanying the data duplication, no resources on the host side are used at all, and there is no reduction in the business processing capacity of the CPU due to the construction of the disaster backup system.

[Brief description of the drawings]

FIG. 1 is a diagram showing a system configuration of a remote backup function according to an embodiment of the present invention.

FIG. 2 is a diagram illustrating a method of acquiring dump data and log data during normal business operation according to the present invention.

FIG. 3 is a diagram showing a method of restoring (restoring) data when a failure occurs in a primary center according to the present invention.

FIG. 4 is a diagram showing a detailed flowchart of a dump process in a normal operation shown in FIG. 2;

FIG. 5 is a diagram showing a dump management table in the dump processing during normal operation shown in FIG. 2;

6 is a diagram showing a detailed flowchart of log processing during normal operation shown in FIG. 2;

FIG. 7 is a diagram showing a log management table in log processing during normal operation.

FIG. 8 is a diagram showing a format in a tape volume in log acquisition.

FIG. 9 is a diagram showing a detailed flowchart of a data recovery process when a failure occurs.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 CPU 2 Interface cable 3 Disk subsystem 4 Interface cable 5 Magnetic tape library device 6 Remote server 7 Disk control device 8 Disk drive device 9 Disk volume 10 Channel interface control unit 11 Cache memory 12 Disk interface control unit 13 Magnetic tape device 14 Library device 15, 16, 17 Tape volume 18 Storage shelf 19 Accessor robot 20 Memory 21 Spare disk subsystem 22 CPU

Claims (5)

[Claims] 1. A computer system comprising: a disk subsystem for recording data from a host computer; and a magnetic tape library device installed at a position remote or close to the disk subsystem. Connecting the system and the magnetic tape library device directly without passing through the host computer, and executing data transfer for data multiplexing from the disk subsystem to the magnetic tape library device. Remote backup system. 2. The remote backup system according to claim 1, wherein the transfer data for multiplexing comprises information on a disk volume in the disk subsystem and update history information on the information. Copying all information of any disk volume in the disk subsystem to one or more tape volumes of the magnetic tape library device, the update history information is stored in a disk volume in the disk subsystem. In the case where the update processing of the data in the unit of record has occurred, the identification number of the disk volume, the positioning information in which the record is stored, and the time information when the update processing occurred are added to the updated data. Any of the tapes in the magnetic tape library device. A remote backup system characterized in that updates are recorded in the order in which the updates occurred in the backup volume. 3. The remote backup system according to claim 2, wherein when a failure occurs in the entire disk subsystem or a part of the disk volume, the copied information of the entire disk volume and the update of the tape volume are updated. Restores all data of the failed disk volume to the state immediately before the failure in a separate volume where no failure has occurred in the disk subsystem or a disk volume in a separately installed subsystem by combining with the history information A remote backup system characterized by: 4. A computer system comprising: a disk subsystem for recording data from a host computer; and a magnetic tape library device located at a position remote or close to the disk subsystem. A system and the magnetic tape library device are connected to the host computer via a control mechanism provided separately from the host computer, and from the disk subsystem to the magnetic tape library device without passing through the host computer under the control of the control mechanism. A remote backup system for executing data transfer for data multiplexing. 5. The remote backup system according to claim 4, wherein the transfer data for multiplexing includes information on a disk volume in the disk subsystem and update history information on the information. All information of any disk volume in the disk subsystem is copied to one or more tape volumes of the magnetic tape library device under the control of the control mechanism, and the update history information is stored in the disk subsystem. When the update processing of the record unit stored in the disk volume in the storage unit occurs, the identification number of the disk volume and the record are stored in the updated data under the control of the control mechanism. Positioning information and time information when the update process occurred are added. hand,
A remote backup system wherein information is recorded in an arbitrary tape volume in the magnetic tape library device in the order of occurrence of the update.