JP2007172365A - Data duplicate system, duplicate data processing program and duplicate data processing method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a data duplicate system capable of using a duplicate data storage area for virtually storing duplicate data and an actual data storage area for actually storing them and shortening an interval from the deletion of the duplicate data to the production start of new duplicate data, a duplicate data processing program and a duplicate data processing method. <P>SOLUTION: A disk array sub system 300 is provided with a master volume 341 storing master data, a snapshot volume 342 to be a duplicate volume, and a shared pool volume 343 to be the actual storage destination of the duplicate data. A plurality of directory regions not shown in the figure for managing which of the shared pool volume 343 actual data are stored are prepared, an unused one of them is cyclically selected and used, and the actual deletion of the actual data is processed on the background. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a data replication system, a replicated data processing program, and a replicated data processing method used in a storage device such as a disk array subsystem, and in particular, a data replication system that performs data replication using a snapshot technique, The present invention relates to a duplicate data processing program and a duplicate data processing method.

  With the spread of computers and data communications, the social infrastructure is rapidly becoming IT (Information Technology). As a result, the amount of data held by companies or individuals has increased rapidly. In addition, the spread of electronic commerce and the storage of visa data have been legislated, and the quality and value of the data itself has increased. In response to such changes in the environment, the effects of data loss are widely recognized. Further, as a means for preventing such data loss, there is a great interest in backup technology.

  As an example, a description will be given of a backup procedure based on a mirroring method conventionally employed in a disk array subsystem using a plurality of hard disks. In order to record a backup of data, it is necessary to secure a quiesce point as a partition of a volume (master volume) to be backed up. Therefore, in this case, processing for stopping processing of an application such as a database that is accessing the master volume is first performed. Next, a volume (backup volume) having the same capacity as the master volume is created, and all data of the master volume is copied (replicated) to the backup volume. When copying to the backup volume is completed, the stopped application such as a database is resumed, while data is read from the backup volume and stored in a backup device such as a tape.

  In the procedure of the mirroring method described above, after the application is stopped, the creation of the backup volume and the copying of data from the master volume to the backup volume are executed. In contrast to this, a method of creating a backup volume in parallel with the operation of an application has been realized. In this latter method, the time from when the quiesce point is secured until the master volume and the backup volume are synchronized is started by copying data from the master volume to the backup volume in advance. To shorten. However, in either method, it takes a time corresponding to the copy amount from the time when the quiesce point is ensured until the master volume data is completely copied to the backup volume.

  In addition, backup volumes are often created for purposes other than backup. For example, data mining that discovers meaningful correlations and effective business patterns from a huge amount of data accumulated in a company consumes data capacity several times that of the master volume. become.

  In order to avoid such problems related to the time required for backup and data capacity, recently, backups employing a snapshot method have been frequently used (see, for example, Patent Document 1).

  FIG. 9 shows the configuration of an example of a disk array subsystem as a conventionally proposed data replication system employing a snapshot method. This disk array subsystem 100 has a master volume 101 and a virtual volume that has the same capacity as the master volume 101 but does not actually have a physical capacity (hereinafter referred to as a snapshot volume). Three types of volumes are prepared: a volume 102 and a volume (hereinafter referred to as a shared pool volume) 103 that stores data of this snapshot volume. In addition to these, the data replication control means 104 for managing data access to the snapshot volume 102 and the address conversion means 105 for managing the actual storage destination of the replicated data replicated by the data replication control means 104 are provided on the disk. It is provided in the array subsystem 100.

FIG. 10 shows the configuration of the data replication control means in the proposed disk array subsystem. A description will be given with FIG. The data replication control unit 104 includes an attribute management table 111 that manages attributes of volumes such as a master and a snapshot, a volume correspondence management table 112 that holds a snapshot relationship between volumes, a master volume 101, and a snapshot volume. And a difference management table 113 for managing differences from the information 102. Here, the difference management table 113 takes a value “0” when the snapshot volume 102 does not hold data, and takes a value “1” when the snapshot volume 102 holds data. Yes. In the attribute management table 111, “LV ₀ ” indicates that the attribute is a master, and “LV ₁ ” indicates that the attribute is a snapshot. “LV ₂ ” indicates that the attribute is a shared pool.

  FIG. 11 shows the configuration of the address conversion means shown in FIG. A description will be given with FIG. The address conversion unit 105 includes a directory 131 that holds the actual storage address of the snapshot volume 102 and an allocation management table 132 that manages the usage status of the shared pool volume 103. The directory 131 is registered when data is held, and stores the location of actual data referenced by the snapshot volume 102. In the allocation management table 132, the unused page of the shared pool volume 103 takes the value “0”, and the used page takes the value “1”.

FIG. 12 shows the operation of a conventionally proposed disk array subsystem having such a configuration. As a procedure for replicating a volume, first, as shown in FIG. 12, a shared pool volume 103 is created in the disk array subsystem 100 shown in FIG. 9, and the attribute management table 111 shown in FIG. Then, the assignment management table 132 shown in FIG. 11 is initialized (step S201). That is, the shared pool attribute is set to “LV ₂ ” as the “LV number” in the attribute management table 111, and the shared pool volume 103 (FIG. 9) is unused in the allocation management table 132 of FIG. Is set to a value “0”.

  In the next step S202, the master volume 101 and the snapshot volume 102 having the same storage capacity as the master volume 101 are created. The state at this time is shown in FIG.

In the next step S203, the disk array subsystem receives the snapshot command. In step S204, the attribute management table 111, the volume correspondence management table 112, the difference management table 113 shown in FIG. 10, and the directory 131 shown in FIG. 11 are initialized. That is, in the attribute management table 111 of the master attribute to "LV _0", set the snapshot attribute to "LV _1", the volume management table 112 as "LV _0" and "LV _1" is the relationship of the snapshot As shown, “LV ₁ ” is set in the “LV ₀ ” of the snapshot, and “LV ₀ ” is set in the “LV ₁ ” of the snapshot. A value “0” indicating that the snapshot volume 102 does not hold data is set in the snapshot volume 102 of the difference management table 113, that is, in this case “LV ₁ ”. Then, a null value indicating that the storage space of the shared pool volume 103 is not allocated to the snapshot volume 102 in the directory 131 shown in FIG. 11 is set. The state of each table at this time is shown in FIGS. Thereafter, the snapshot volume 102 holds the volume image at the time when the snapshot command is received.

  FIG. 13 shows snapshot volume deletion processing in this disk array subsystem. First, as shown in FIG. 13, in step S221, the disk array subsystem 100 (FIG. 9) receives a snapshot volume deletion command for deleting a snapshot volume. Then, in the next step S222, it is confirmed by referring to the volume correspondence management table 112 shown in FIG. 10 that there is a corresponding volume. In the next step S223, the attribute management table 111 in FIG. 10 is referred to and it is confirmed that the corresponding volumes confirmed in step S222 are the master volume 101 and the snapshot volume 102. In the next step S224, the attribute of the snapshot volume 102 to be deleted is changed during snapshot deletion, and the deletion command processing for the snapshot volume 102 is terminated.

  FIG. 14 shows snapshot data deletion processing on the shared pool volume in this disk array subsystem. The process of deleting the actual data of the shared pool volume, which is the data reference destination of the snapshot volume, will be described with reference to this figure. First, in step S241, the attribute management table 111 shown in FIG. 10 is referenced to search for a volume having an attribute for which a snapshot is being deleted (step S242). If there is no volume having the attribute during snapshot deletion (N), the deletion process ends as it is (end).

  When there is a volume having an attribute during snapshot deletion (step S242: Y), a page for deletion search is arbitrarily set (step S243). Then, the difference management table 113 is referred to (step S244), and it is checked whether or not there is data on the deletion search page set in the previous step S243 in the snapshot volume 102 (step S245).

  As a result, if it is determined that there is no data in the deletion search page (N), it is determined whether deletion of actual data referred to by the snapshot volume designated for deletion is completed (step S246). If it is determined that there is data to be deleted (N), the process returns to step S243, a page different from the previous one is set as the deletion search page, and the deletion process is continued.

  On the other hand, if it is determined in step S245 that there is data in the snapshot volume 102 (Y), the shared pool volume 103 referred to by the snapshot volume 102 is referred to by referring to the directory 131. The position of the actual data is checked (step S247). Then, the actual data of the shared pool / volume indicated by the directory 131 (FIG. 11) is deleted (step S248).

When data on the shared pool volume 103 is deleted, usable free pages are created in the shared pool volume 103. Therefore, in the next step S249, the page information of the shared pool volume 103 deleted this time in the allocation management table 132 shown in FIG. 11 is set to a value “0” indicating a free area. Then, the information of the directory 131 corresponding to the deletion search page is cleared (step S250), and then the value “0” indicating that there is no actual data to be managed is set in the value of the difference management table 113 (step S250). S251), the deletion of the page designated as the deletion search page is completed. In the next step S246, it is determined whether deletion of the allocation area of the shared pool volume 103 used by the snapshot volume 102 has been completed, and if it is determined that there is still data to be deleted (N ), Returning to step S243, a page different from the previous one is set as the deletion search page, and the deletion process is continued. If it is determined that the deletion has been completed (step S246: Y), the snapshot deletion attribute is cleared (step S252), and the deletion processing of the snapshot volume 102 is completed.
Japanese Patent Laying-Open No. 2005-310159 (paragraph 0007, FIG. 4C)

  As described above, since the snapshot volume 102 is a virtual volume, the presence / absence of data is indicated in the difference management table 113 shown in FIG. 10 to indicate the status, and the reference destination of the actual data is the directory shown in FIG. 131. When deleting a snapshot, these management tables must be updated. However, the directory area used by the snapshot volume 102 is usually fixed in units of volumes. If it is performed, the snapshot cannot be started again until the deletion process of the directory area is completed.

  In addition, the update amount of each table when deleting the snapshot including the update of the directory 131 is increased in proportion to the increase in the capacity of the snapshot volume 102, and the waiting time for the completion of deletion is further increased. There was a problem.

  Therefore, an object of the present invention is to use a replicated data storage area for virtually storing replicated data and an actual data storage area for actually storing the replicated data, thereby shortening the interval from the deletion of the replicated data to the start of production of new replicated data. An object of the present invention is to provide a data replication system, a replicated data processing program, and a replicated data processing method that can be performed.

  In the present invention, (a) master data storage means for storing master data to be replicated, and (b) duplicate data as a replica of the master data stored in the master data storage means, respectively. A replicated data storage means having a replicated data storage area for storing data, (c) an actual data storage means having an actual data storage area for storing replicated data as actual data, and (d) a virtual data storage means. A plurality of directory area setting means for preparing in advance a plurality of directory areas for managing the storage location of the actual data in correspondence with one or a plurality of replicated data stored in the storage, and (e) an actual data stored in the actual data storage means. A directory area to which one of the unused areas among the plurality of directory areas prepared in the multiple directory area setting means is assigned for each data. To and a assigning means to copy data storage system.

  That is, in the present invention, the duplicate data of the master data stored in the master data storage means is virtually stored in the duplicate data storage area of the duplicate data storage means, while the real data is stored in the real data storage area of the real data storage means. Multiple directory area setting means prepare a plurality of directory areas for managing the storage location of the actual data in advance, and the plurality of directory area setting means prepare for each actual data stored in the actual data storage means. One of the unused areas of the plurality of directory areas is dynamically allocated. Therefore, since the information for managing the storage location of the actual data can be stored in the unused directory area prior to the actual data deletion process, the interval from the deletion of the replicated data to the start of the production of new replicated data can be shortened. is there.

  In the replicated data processing program of the present invention, (b) a master data storage process for storing master data to be replicated in data in a computer equipped with a storage device for storing data; C) Replicated data storage processing for virtually storing the replicated data as a replica of the master data stored in this master data storage processing in the replicated data storage area; and (d) Actual data using the replicated data as actual data. Real data storage processing stored in the storage area and (e) a plurality of directory areas prepared in advance for managing the storage location of the actual data corresponding to the replicated data virtually stored in the replicated data storage process Directory area allocation that allocates unused directory areas that are not used to manage other replicated data one by one for each actual data It is characterized in that to perform the management.

  That is, according to the present invention, when replica data of the master data is virtually stored in the replicate data storage area, and when the actual data is stored in the actual data storage area, the master data is stored in the computer equipped with the storage device for storing the data. Replicated data storage processing for virtually storing the replicated data as a replica of the master data stored in the data storage processing in the replicated data storage area, and actual data storage processing for actually storing the replicated data in the actual data storage area In addition, it is used for managing other replicated data from a plurality of directory areas prepared in advance for managing the storage location of actual data corresponding to each replicated data virtually stored in the replicated data storage process. It is possible to execute a directory area allocation process that dynamically allocates unused directory areas one by one for each actual data. It was. As a result, information for managing the storage location of the actual data can be stored in an unused directory area prior to the actual data deletion process, so the interval from deletion of the replicated data to the start of creation of new replicated data can be shortened. It is. Deletion of actual data can be processed in the background.

  In the present invention, (a) a replicated data storage step for virtually storing replicated data as a replica of master data in the replicated data storage area; and (b) the replicated data as actual data in the actual data storage area. An actual data storage step to store, and (c) another replica from a plurality of directory areas prepared in advance for managing the storage location of the actual data corresponding to the replicated data virtually stored in the replicated data storage step The replication data processing method includes a directory area allocation step of allocating an unused directory area that is not used for data management.

  That is, in the present invention, it is used for management of other replicated data from a plurality of directory areas prepared in advance for managing the storage location of actual data corresponding to the replicated data virtually stored in the replicated data storage step. By providing a directory area allocation step that dynamically allocates unused directory areas that have not been used, it is possible to store information for managing the storage location of actual data in unused directory areas prior to actual data deletion processing. The interval from deletion of duplicate data to the start of creation of new duplicate data can be shortened.

  As described above, according to the present invention, since a plurality of directory areas are prepared in advance and used dynamically, the deletion process can be performed only by performing an operation on the directory area when deleting actual data. Appearance is completed, and the actual data can be deleted in the background.

  Hereinafter, the present invention will be described in detail with reference to examples.

  In this embodiment, the data replication system is applied to a disk array subsystem as a storage device. First, the hardware configuration of the disk array subsystem will be described.

FIG. 1 shows an outline of the hardware configuration of the disk array subsystem used in this embodiment. The disk array subsystem 300 is connected to a management terminal (computer) 301 and a host (computer) 302 as host devices via an interface control unit 311. In the disk array subsystem 300, a plurality of magnetic disk devices 313 _{1 to} 313 ₆ are connected via a RAID (Redundant Arrays of Inexpensive Disks) control unit 312. These magnetic disk devices 313 _{1 to} 313 ₆ are for performing predetermined processing such as backup of data stored in the management terminal 301 or the host 302. The RAID control unit 312 performs control for connecting the interface control unit 311 and the magnetic disk devices 313 _{1 to} 313 ₆ .

  In addition, the disk array subsystem 300 further includes a microprocessor (hereinafter simply referred to as a CPU) 314 and a control memory 315 that stores a control program used by the CPU 314. The interface control unit 311 and the RAID control unit 312 are controlled by a CPU 314 that operates based on a control program stored in the control memory 315 to input / output data. The control memory 315 of the present embodiment can use the CPU 314 as various function realizing means by rewriting a control program to be written. In this embodiment, the CPU 314 is mainly used for data replication control means 321 for controlling data replication and access to the replicated data, address conversion means 322 for controlling the storage destination of the replicated data, and the shared pool volume. The stored data is used as a pool data deleting unit 323 that deletes the stored data.

  The control memory 315 also stores the attribute management table 331, the volume correspondence management table 332, the storage directory management table 333, the difference management table 334, the directory 335, the allocation management table 336, and the pool data deletion table 337. It has become. These will be described in detail later.

In FIG. 1, six magnetic disk devices 313 _{1 to} 313 ₆ are connected to the RAID control unit 312, but in reality, each of them is a logically independent volume such as a master volume or a snapshot volume. There is no need to configure volumes or shared pool volumes. An apparently single volume may be provided across a plurality of magnetic disk devices under the control of the RAID control unit 312. Alternatively, a partition may be set in one magnetic disk device and apparently a plurality of volumes may be set to 1 It can also be provided in one magnetic disk device.

FIG. 2 shows a simplified functional view of the disk array subsystem of this embodiment. This disk array subsystem 300 includes a master volume (LV ₀ ) 341 that stores master data that is a replication source, a snapshot volume (LV ₁ ) 342 that is a replication volume of the master volume 341, and a replication A shared pool volume (LV ₂ ) 343 serving as an actual storage destination of data is provided. Here, “LV” means a logical volume. In addition, the disk array subsystem 300 includes a data replication control unit 321 (see FIG. 1) for managing data replication from the master volume 341 to the snapshot volume 342, and a shared pool volume from the snapshot volume 342. Address conversion means 322 (see FIG. 1) for managing data storage in the H.343 and pool data deletion means 323 (FIG. 1) for deleting data in the shared pool volume 343 used by the deleted snapshot volume 342 1). There are no particular restrictions on the number of master volumes 341, snapshot volumes 342, and shared pool volumes 343. In FIG. 2, the number of master volumes 341, snapshot volumes 342, and shared pool volumes 343 is one to simplify the illustration and description.

  In this embodiment, data stored in the master volume 341, the snapshot volume 342, and the shared pool volume 343 is managed in units of pages. Here, “page” is a unit for performing data difference management, and in this embodiment, 32 KB (kilobytes) is one page. Therefore, data of 32 KB or less is stored in the 0th page, and for example, the data of the third page is in the range of 96 KB to 128 KB on the logical disk.

FIG. 2 shows a state immediately after updating the data of the second page of the master volume (LV ₀ ) 341 from “CC” to “CE” after starting the snapshot. Since the data of the second page of the master volume 341 was “CC” at the time when the snapshot was started, the second page of the snapshot volume 342 holds the data image of “CC”. Thereafter, when the data of the second page of the master volume 341 is updated from “CC” to “CE”, in order to maintain the data image held by the snapshot volume 342, before the data update of “CE”, The data replication control means 104 replicates the data of “CC” from the master volume 341 to the snapshot volume 342. As a result, the second page of the snapshot volume 342 can hold data “CC”. However, the data “CC” that appears to be held by the snapshot volume 342 is actually stored in the 0th page of the actual shared pool volume (LV ₂ ) 343 by the address conversion unit 322. Will be.

  FIG. 3 shows the configuration of the data replication control means shown in FIG. The data replication control unit 321 uses an attribute management table 331 that manages attributes of volumes such as masters and snapshots, a volume correspondence management table 332 that holds snapshot relationships between volumes, and snapshot volumes. A storage directory management table 333 for managing the directory storage location, and a difference management table 334 for managing the difference between the master volume and the snapshot volume are provided.

  FIG. 4 shows the configuration of the address conversion means. The address conversion unit 322 includes a directory 335 that holds the actual storage address of the snapshot volume 342 (FIG. 2), and an allocation management table 336 that manages the usage status of the shared pool volume 343. The directory 335 is prepared from the 0th directory to the Xth directory, and each is associated with the 0th page (page) to the nth page. Here, the directory 335 is a member of the address conversion means 322, but is not limited thereto. That is, the directory 335 may be written in the logical volume. In this case, the storage directory management table 333 shown in FIG. 3 stores not the directory number but the volume number in which the directory 335 is stored and the address in the volume.

In FIG. 4, for example, “LV ₂ , 0th page” is described in the first directory of the second page of the directory 335. This indicates that duplicate data exists at the location of “LV ₂ , page 0”. Physical data cannot be allocated to the snapshot volume (LV ₁ ) 342. Therefore, when the snapshot volume 342 needs to have data, the data is stored in the actual shared pool volume (LV ₂ ) 343. Here, the corresponding replicated data is stored in the 0th page of the shared pool volume 343.

FIG. 5 shows the configuration of the pool data deleting means shown in FIG. The pool data deleting unit 323 is a unit that deletes unnecessary backup data stored in the plurality of magnetic disk devices 313 _{1 to} 313 ₆ shown in FIG. The pool data deletion means 323 has a pool data deletion table 337 for managing directory information used by the snapshot volume 342 designated for deletion.

  Next, the operation of the disk array subsystem 300 of this embodiment having such a configuration will be described in detail.

FIG. 6 shows a copy preparation operation for creating copy data from master data. First, as advance preparation for performing a snapshot operation, a shared pool volume 343 (FIG. 2) is created in the disk array subsystem 300 shown in FIG. 1, and an attribute management table 331 and an allocation management table 336 are created. Initialization is performed (step S401). That is, for the attribute management table 331, the shared pool attribute is set to “LV ₂ ” as shown in FIG. 3, and for the allocation management table 336, the shared pool volume 343 is unused as shown in FIG. Is set to a value “0”. The storage capacity of the shared pool volume 343 may be arbitrarily determined, but it is preferable to create it after estimating the amount of data required for the time being, considering that it becomes the data storage destination of a plurality of snapshot volumes 342 .

  In the next step S402, a master volume 341 and a snapshot volume having the same storage capacity as the master volume 341 are created. The snapshot volume that functions as a duplicate data storage area has the same storage capacity as the master volume. However, the actual data storage destination of the snapshot volume 342 is the shared pool volume 343. Therefore, the snapshot volume 342 itself does not consume the storage area. That is, the snapshot volume 342 is merely a volume virtually constructed in the disk array subsystem 300, and does not have a substantial storage capacity.

  The master volume 341 may be created at the stage of processing in step S402, or an already existing volume may be designated. When specifying a volume that already exists, a volume that does not have a snapshot relationship may be specified, or a snapshot volume 342 may be further associated with a master volume 341 that already has a snapshot relationship.

  In the next step S403, a snapshot command is received. Thereby, in the next step S404, the storage directory management table 333 (FIG. 3) and the pool data deletion table 337 (FIG. 1) are referred to search for available free directories.

In the next step S405, the attribute management table 331, the volume correspondence management table 332, the difference management table 334, the directory 335 shown in FIG. 4, and the storage directory management table 333 shown in FIG. 3 are initialized. That is, for the attribute management table 331, the master attribute is set to “LV ₀ ” as shown in FIG. 3, and for the volume correspondence management table 332, “LV ₀ ” and “LV ₁ ” have a snapshot relationship. to indicate that a sets "LV _1" to "LV _0", sets the "LV _0" to "LV _1". For the difference management table 334, a value “0” indicating that the image of the data in the snapshot volume 342 is not in the snapshot volume 342 is set. Then, the usable directory searched in the previous step S404 is registered in the storage directory management table 333, and the directory 335 shown in FIG. 4 is a null value indicating that the shared volume volume 343 is not allocated to the snapshot volume 342. It will be initialized.

  Thereafter, the snapshot volume 342 holds the volume image when the snapshot command is received.

  FIG. 7 shows the flow of processing when a snapshot volume deletion command of this embodiment is received. When the delete command for the snapshot volume 342 is received, the volume correspondence management table 332 is referred to in step S421, and it is confirmed that there is a volume having a snapshot correspondence relationship (step S421). Next, with reference to the attribute management table 331 shown in FIG. 3, it is confirmed that the volume having the correspondence relationship is in the relationship between the master volume 341 and the snapshot volume 342 (step S422).

  Next, the pool data deletion table 337 shown in FIG. 5 is constructed (step S423). In the pool data deletion table 337, the directory storage destination information used by the snapshot volume 342 designated for deletion is copied from the storage directory management table 333 shown in FIG.

  In the next step S424, the values of the volume correspondence management table 332 and the storage directory management table 333 are cleared. As a result, the snapshot volume deletion command is terminated, and the snapshot volume 342 that has been deleted becomes ready to receive the snapshot start command again. In the conventional method, the directory area used by the snapshot volume 342 is fixed. For this reason, when the snapshot command 342 is deleted and the snapshot command is issued again, it is necessary to wait for the deletion of the directory 335 (FIG. 4) used so far. On the other hand, in this embodiment, the area used for the directory 335 is dynamically secured at the start of the snapshot, thereby eliminating the waiting time for deleting the directory 335.

  FIG. 8 shows snapshot data deletion processing on the shared pool volume. This is a process of releasing the allocation area of the shared pool volume 343 used by the snapshot volume 342 by the pool data deleting means 323 shown in FIG. The pool data deletion unit 323 is activated every few seconds and executes processing. Then, the pool data deletion table 337 is referred to at the time of activation (step S441), and then it is determined whether there is an entry registered in the pool data deletion table (step S442). If the entry is not registered (N), the process is terminated as it is (end).

  If the entry has been registered (step S442: Y), the process proceeds to a process for deallocating the shared pool volume 343. That is, first, a page on which deletion search is performed is arbitrarily set (step S443). At this time, the range that does not exceed the capacity of the snapshot volume 342 that has been specified for deletion can be specified on the deletion search page. Next, the directory 335 registered in the pool data deletion table 337 is referred to (step S444). Then, it is determined whether there is data in the searched page (step S445). If it is determined that there is no data in the searched page (N), it is determined whether or not the data deletion of the entry being processed has been completed (step S446). As a result, if the data deletion of the entry being processed has not been completed (N), the process returns to step S443, a page different from the previous one is set as the deletion search page, and the deletion process is continued.

  On the other hand, if it is determined in step S445 that there is data in the deletion search page (Y), the actual data of the shared pool volume registered in the directory 335 is deleted (step S447). Then, the value of the deletion search page in the allocation management table 336 shown in FIG. 4 is set to a value “0” indicating that it is a free area (step S448). In this case, the directory value of the deletion search page is cleared, and the deletion of the page designated as the deletion search page is completed (step S449). Next, it is determined whether or not deletion of the entry being deleted is completed (step S446). If deletion of the entry has not been completed (N), the process returns to step S443, a page different from the previous one is set as the deletion search page, and the deletion process is continued.

  On the other hand, if it is determined in step S446 that the deletion is complete (Y), the entry of the directory that has been deleted is cleared from the pool data deletion table 337 shown in FIG. 5 (step S450), and the shared pool volume The deletion process 343 ends (END).

  In the embodiment described above, various table information including the directory 335 is described as being on the control memory 315. However, the present invention is not limited to this. For example, the free area on the shared pool / volume may be stored in any location on a storage medium such as a magnetic disk device or an optical disk device.

  Further, in the embodiment, it is used for volume level backup in the disk array subsystem, but it can also be used for data backup in other systems.

It is a schematic block diagram of the hardware of the disk array subsystem used by a present Example. 1 is a schematic configuration diagram illustrating a functional configuration of a disk array subsystem according to an embodiment. It is explanatory drawing showing the structure of the data replication control means of a present Example. It is explanatory drawing showing the structure of the address conversion means of a present Example. It is explanatory drawing showing the structure of the pool data deletion means of a present Example. 5 is a flowchart showing a replication preparation operation for creating replication data from master data in this embodiment. 10 is a flowchart showing processing when a snapshot volume deletion command is received in the embodiment. It is a flowchart showing the snapshot data deletion processing on the shared pool volume in the present embodiment. It is the schematic block diagram which showed the function structure of the disk array subsystem as a data replication system conventionally proposed which employ | adopted the snapshot system. It is explanatory drawing which shows the structure of the data replication control means in this proposal disk array subsystem. It is explanatory drawing which shows the structure of the address conversion means shown in FIG. 6 is a flowchart showing the operation of a conventionally proposed disk array subsystem. It is a flowchart which shows the deletion process of the snapshot volume in the disk array subsystem proposed conventionally. 10 is a flowchart showing snapshot data deletion processing on a shared pool volume in a conventionally proposed disk array subsystem.

Explanation of symbols

300 Disk Array Subsystem 301 Management Terminal 302 Host 313 Magnetic Disk Device 314 Microprocessor (CPU)
321 Data replication control means 322 Address conversion means 323 Pool data deletion means 331 Attribute management table 332 Volume correspondence management table 333 Storage directory management table 334 Difference management table 335 Directory 336 Assignment management table 337 Pool data deletion table

Claims (9)

Master data storage means for storing master data to be replicated;
Replicated data storage means comprising a replicated data storage area for virtually storing replicated data as a replica of the master data stored in the master data storage means;
Real data storage means comprising a real data storage area for storing the replicated data as real data;
A plurality of directory area setting means for preparing in advance a plurality of directory areas for managing the storage location of the actual data in correspondence with one or a plurality of duplicate data virtually stored in the duplicate data storage means;
Directory area allocating means for allocating one of the unused areas of the plurality of directory areas prepared in the plurality of directory area setting means for each of the actual data stored in the actual data storage means. Data replication system.   The directory area allocating unit includes an unused directory area searching unit that searches for an unused directory area that is not used for managing other replicated data, and one of the unused directory areas searched by the unused directory area searching unit. The data replication system according to claim 1, wherein one is assigned. A duplicate data deletion request receiving means for receiving the duplicate data deletion request;
A directory area search means for searching a directory area for managing a storage area of actual data corresponding to the copy data for which the copy request has been received received by the copy data deletion request receiving means;
And a directory area attribute changing means for completing the deletion processing of the duplicate data by changing the directory area in use obtained by the search of the directory area searching means to an unused directory area. Item 3. The data replication system according to Item 2.   2. The data according to claim 1, wherein the directory area allocating means is an address changing means for changing the directory area to one of the addresses of the respective directory areas prepared by the plurality of directory area setting means. Replication system. A deletion specifying means for specifying deletion of the duplicated data;
2. The data replication system according to claim 1, further comprising actual data deletion means for deleting the corresponding real data in the actual data storage means when deletion of the replicated data is designated by the deletion designation means. In a computer equipped with a storage device for storing data,
A master data storage process for storing master data to be replicated;
A duplicate data storage process for virtually storing the duplicate data as a duplicate of the master data stored in the master data storage process in the duplicate data storage area;
An actual data storage process for storing the replicated data as actual data in an actual data storage area;
Of the plurality of directory areas prepared in advance for managing the storage location of the actual data corresponding to the replicated data virtually stored in the replicated data storage process, it is not used for the management of other replicated data. A duplicate data processing program for executing directory area allocation processing for allocating one directory area to be used for each actual data. A duplicate data deletion request reception process for receiving a deletion request for the duplicate data stored in the actual data storage process;
A directory search process for searching a directory area for managing a storage area of actual data corresponding to the copy data of the deletion request received in the copy data deletion request reception process;
A directory area attribute change process for completing the deletion process of the duplicate data by changing a directory area in use obtained by the search of the directory search process to an unused directory area. 6. A duplicate data processing program according to 6. A replicated data storage step for virtually storing replicated data as a replica of the master data in a replicated data storage area;
An actual data storage step of storing the replicated data as actual data in an actual data storage area;
Among the plurality of directory areas prepared in advance for managing the storage location of actual data corresponding to the replicated data virtually stored in the replicated data storage step, unused that is not used for managing other replicated data A duplicate data processing method comprising: a directory area allocation step for allocating a directory area. A duplicate data deletion request receiving step for receiving a deletion request for the duplicate data stored in the actual data storing step;
A directory search step for searching a directory area for managing a storage area of actual data corresponding to the copy data of the deletion request received in the copy data deletion request reception step, from the directory area in use;
The directory area attribute changing step of completing the deletion processing of the duplicated data by changing the directory area in use obtained by the search in the directory search step to an unused directory area. 9. The duplicate data processing method according to 8.

Images