Methods and apparatus for adjusting a journal area for continuous data protection

[0001] 1. Field of the Invention

[0002] The present invention relates generally to storage systems and to backup and recovery of data.

[0003] 2. Description of Related Art

[0004] A conventional method for achieving backup and recovery of data in storage systems is to backup the data periodically (e.g., once a day) from the storage system to a backup media, such as magnetic tapes. In creating the backup data, a snapshot of a storage area (e.g., a point-in-time copy of a volume) is often used to obtain data with consistency. That is, the data to be backed up is read from a snapshot volume (or a mirror image volume that has been split from a primary volume), and copied to the backup media. Several methods to provide a snapshot of a storage area logically or physically are well known in the prior art for storage systems. When it is necessary for data to be restored, the data saved to the backup media is read from the backup media, and may be written to a new storage area (e.g., a new volume) in the same storage system, or to a different storage system, to enable access to the backed-up data.

[0005] However, with the above method, it is only possible to restore the image of the data at the particular point in time at which the snapshot was taken. Thus, restoring data from backup data taken only periodically may result in a loss of some amount of updates to the original data because there is a difference between the saved back up data and the data that is actually desired to be restored, such as the current data. Further, for example, if the latest backup data has incorrect or corrupted actual data, it is necessary to use older backup data, which results in even larger disparities in data correctness.

[0006] Recently, some storage systems have been configured with a capability of journaling data updates into a journal as the data updates occur, and then, when necessary, restoring data using the journal in a technology that is sometimes referred to as “continuous data protection” (CDP). In a storage system having this capability, all updates for a storage area are recorded as a journal, and the data at an arbitrary point in time can be restored by using the journal. In this journaling and restoring technique, point-in-time snapshots may also be used. That is, besides the journal, snapshots of the storage area may be maintained at predetermined intervals, and restoring the data at a desired arbitrary point in time is achieved by applying the data of the journal to one of the snapshots up to the specified arbitrary point in time at which restore is desired. This technology is disclosed in detail in US Patent Application Publication Number US2004/0268067A1, to K. Yamagami, filed Jun. 26, 2003, the disclosure of which is incorporated herein by reference.

[0007] In the system with journaling capability discussed above, a substantial amount of storage area (storage capacity) may be required to store the journal. Maintaining excessive storage capacity dedicated to storing the journal can increase the total cost of ownership for the system. Thus, a fundamental problem with current CDP technology is that maintaining large storage areas dedicated to the storing of journal data increases the total cost of ownership for such storage systems. Therefore there is a need for methods and an apparatus to automatically adjust and attempt to minimize the amount of storage area dedicated to storing of journals. US Patent Application Publication Number US2004/0162958A1, to Kano et al., filed Feb. 23, 2004, the disclosure of which is incorporated herein by reference, discloses automated online capacity expansion for storage devices. However, the prior art does not address or provide a solution to the problem discussed above.

[0008] The invention enables users to determine an appropriate size of a journal area in accordance with specified requirements for retention periods for backup data. The invention also provides users with a simplified control means to manage the journal area, and reduces the cost of managing the journal area. This invention includes methods and means for users to determine a relation between the amounts (sizes) of journals and periods of journals. With these means, users can determine appropriate sizes of journal areas to meet their specified requirements for preservation periods of backup data. The invention also discloses methods to realize simplified, flexible and automatic adjustment of journal areas having a thin provisioning capability so as to achieve dynamic allocation of journal storage areas from free space on an as-needed basis. These and other features and advantages of the present invention will become apparent to those of ordinary skill in the art in view of the following detailed description of the preferred embodiments.

[0035] In the following detailed description of the invention, reference is made to the accompanying drawings which form a part of the disclosure, and, in which are shown by way of illustration, and not of limitation, specific embodiments by which the invention may be practiced. In the drawings, like numerals describe substantially similar components throughout the several views. Further, the drawings, the foregoing discussion, and following description are exemplary and explanatory only, and are not intended to limit the scope of the invention or this application in any manner.

[0036] In the first embodiments, the system comprises host computers, a management terminal and a storage system having a journaling capability, as described above. The storage system maintains information about an amount (size) of a journal and a time (period) of journal. In response to an inquiry from the management terminal, the storage system provides the information about the size and period of the journal. Thus, the management terminal can monitor the relation between the sizes and the periods of journals that are generated and stored in the storage system. The management terminal also presents the relation to users. By using this information, the users can determine the appropriate sizes of journal areas and can provide instructions for adjustment of the journal areas to suitable sizes.

[0037] In the second embodiments and the third embodiments, storage areas in the storage system are divided into multiple fixed-size areas (i.e., storage chunks), and the storage system performs dynamic allocation of the chunks (i.e., thin provisioning). The storage system allocates the chunks to the journal areas on demand and releases the chunks from the journal areas based on users' policy for preservation periods of the journals.

[0038] FIG. 1 describes and exemplary system and hardware configuration of an information system under which first embodiments of the invention may be practiced. A storage system 100 includes an array controller 110 for receiving data access commands from one or more host computers 500 via a network 901. Network 901 may be a storage area network (SAN), such as a Fibre Channel network, iSCSI(IP) or other network type or communications link enabling communications between hosts 500 and storage system 100.

[0039] Array controller 110 may include a main processor 111, a switch 112, one or more host interface (I/F) controllers 113, a system memory 200, a cache memory 300, and one or more disk controllers 400. Disk controllers 400 couple array controller 110 to one or more hard disk drives (HDDs) 600 via a backend path 601. Back end path 601 may be Fibre Channel, SATA, SAS, iSCSI(IP), or other suitable type of connection.

[0040] Main processor 111 performs various processes in array controller 100 to facilitate storing data to and retrieving data from HDDs 600. Additionally, to enable operation of the invention, memory 200 stores consistency group information 201, volume information 202, journal information 203, and period-amount information 204, each of which will be described in more detail below.

[0041] A management terminal 520 may be connected for communication with host interface 113 of array controller 100 via SAN 901. Hosts 500 and management terminal 520 may also be connected to each other for communication via a local area network (LAN) 903. Further, management terminal 520 may also be connected for communication with array controller 110 via an out-of-band network 902 (e.g., IP), separate from the SAN 901 to enable monitoring functions, and the like.

[0042] One or more logical volumes 602 (logical units) are provided by storage system 100 for storage of data received from hosts 500. Volumes 602 are provided using a concatenation of one or more physical storage areas in HDDs 600. Preferably volumes 602 are protected by storing parity code for the stored data (i.e., such as by a RAID configuration), and may include physical storage areas distributed across multiple HDDs 600 to provide data protection for the data stored to volumes 602. The volumes discussed below may each be of the type of volume 602 described here and as illustrated in FIG. 1. Further, while FIG. 1 illustrates an exemplary system arrangement for practicing the invention, other system and hardware arrangements will be apparent to those of skill in the art in light of the disclosed invention.

[0043] Basic Process of Journaling

[0044] FIG. 2 describes a basic process of journaling and snapshot generation carried out in the configuration set forth in FIG. 1. In FIG. 2, host 500 includes software 501, such as application software (APP), a database management system (DBMS) and operating system (OS) which generates data to be stored to a production volume 620. Software 501 stores data to production volumes 620 provided by storage system 100, such as through write commands. Storage system 100 also includes base volumes 640 that constitute a pair (i.e., a replica) with production volumes 620. When data protection is initiated for a production volume 620, a base volume 640 is created that is a replica of the data contained in the corresponding paired production volume 620. The base volume receives the same updates to data as are made to the production volume 620, in the manner described below.

[0045] One or more production volumes 620 constitute a consistency group 610. Each consistency group 610 includes one or more assigned journal volumes 630 upon which journal entries are recorded. A Generate Journal (JNL) Function 810 in storage system 100 obtains write data (update data) that is written to production volumes 620. The Generate Journal Function 810 duplicates the received update data as journal data, and assigns a sequence number (incremental number) to each journal data in write order (i.e. chronological order). The sequence number is generated for each consistency group 610, in other words, the journal data in a consistency group 610 has a unique sequence number for the consistency group 610. Then, Generate Journal Function 810 records the journal data and sequence number as a journal entry on journal volumes 630 that are assigned for the consistency group 610. The sequence number is recorded on metadata 634 described below.

[0046] FIG. 3 illustrates an example of consistency group information 201 maintained for each consistency group 610 according to the invention. Consistency group information 201 includes entries for consistency group ID 2011, journal volume ID 2012, production volume ID 2013, sequence number 2014 and status 2015. Thus, consistency group information 201 includes information about each consistency group and maintains the relations between production volumes 620 and journal volumes 630. Consistency group information 201 also records the current sequence number in each consistency group 610.

[0047] FIG. 4 illustrates an example of volume information 202 that is maintained for each production volume 620. Volume information 202 includes entries for production volume ID 2021, consistency group ID 2022, base volume information 2023, including volume ID and status, and snapshot information 2024, including snapshot ID, volume ID, point in time of a snapshot and sequence number for the snapshot. Thus, volume information 202 includes information about the relations between production volumes 620, base volumes 640 and snapshot volumes 650.

[0048] FIG. 5 illustrates a method of storing journal entries in a journal volume 630. Journal volume 630 is divided into two areas: a metadata area 631 and a journal data area 632. Generate JNL Function 810 determines a location for storing the update data as journal data 635 in journal data area 632. Then, Generate JNL Function 810 generates information with a fixed length (metadata 634) for each journal entry 635, records the location of the journal data 635 on the metadata 634, and stores the metadata entry 634 in metadata area 631. Then, Generate JNL Function 810 also stores the update data to the location in journal data area 632 as journal data 635. Typically, the journal entries are stored sequentially into the journal volume 630 as the data updates are received from the host computers 500.

[0049] FIG. 6 illustrates an example of contents of a metadata entry 634 in journal volume 630. For example, metadata 634 may includes a consistency group field 6341, a sequential number field 6342, a time field 6343, a system ID for the journal volume field 6344, a volume ID of metadata field 6345, a location of metadata field 6346, a volume ID of journal data field 6347, a location of journal data field 6348, a system ID for the production volume field 6349, a production volume ID field 6350, a location in production volume field 6351, a system ID for the base volume field 6352, a base volume ID field 6353, a location in base volume field 6354, a data length field 6355, and a type field 6356. Thus, from the metadata 634, information about the journal entry 635 may be obtained, including sequence number and time of the journal entry, and also information about data length, location of the journal entry in the journal volume 630 and location of corresponding data in the production volume 620.

[0050] In FIG. 2, an Update Base Volume Function 820 in storage system 100 reads metadata, acquires journal data from journal volume 630, and updates base volume 640 with the journal data according to the sequence number. Additionally, a Make Snapshot Function 830 in storage system 100 obtains a snapshot 650 of each base volume 640 at predetermined point-in-time intervals, and updates snapshot information 2024 in volume information 202. As described in FIG. 4, volume information 202 has snapshot information 2024 about snapshot volumes 650. Make Snapshot Function 830 records time and sequence number of journal entries corresponding to snapshots 650 on volume information 202. Time stamps entered in time field 6342 of metadata 634 and recorded in volume information 202 are attached by storage controller 110 using the received time or attached by a host 500 using a write time.

[0051] Basic Process of Restoring Data with a Journal

[0052] FIG. 7 illustrates a basic process of restoring data by using the journal volume 630 and a snapshot volume 650. First, host 500 instructs a restore data operation by specifying a production volume 620 and by indicating a point in time to which the data is to be restored. According to the instruction including an indication of the data and the point in time, the storage system 100 uses an Apply Journal Function 840 to select a snapshot that contains the data before the specified point in time.

[0053] The Apply Journal Function 840 then applies (writes) journal entries from the journal volume 630 corresponding to the selected snapshot volume 650. The journal entries are applied to the snapshot volume to update the snapshot volume to the specified point in time by applying sequentially journal entries starting with the journal entry immediately after the point in time of the snapshot up to the specified point in time and sequence number in the metadata 634. Preferably, the snapshot taken closest to the specified point in time should be selected for applying the journal entries so as to minimize the number of journal entries that must be applied to the snapshot. The Apply Journal Function 840 is able to recognize the journal entries to be applied by referring to volume information 202 and metadata 634. After completion of applying the journal entries to the selected snapshot volume 650, the Apply Journal Function 840 changes the status of the snapshot to make it accessible (i.e., read/write access is allowed). Then, as illustrated in FIG. 8, host 500 can use the recovered point-in-time (PiT) image of the data as the current production volume 620.

[0054] Process of Generating a Journal

[0055] FIG. 9 illustrates a process of generating a journal. The process includes steps 1001-1006, as described in detail below.

[0056] At step 1001, host 500 issues a write request and transfers write data to array controller 110 for storage of the write data to a targeted production volume 620.

[0057] At step 1002, array controller 110 stores the write data in the targeted production volume 620 in accordance with the write request.

[0058] At step 1003, array controller 110 also stores the write data as a journal entry in the appropriate journal volume 630. In the case of a consistency group 610, the write data would be stored as a journal entry in the journal volume 630 for the corresponding consistency group 610 that includes the targeted production volume 620. The metadata for the journal entry is also created and stored in the journal volume 630 at this step.

[0059] Also during step 1003, array controller 110 updates journal information 203 that is maintained in the memory 200. FIG. 10 illustrates an example of journal information 203. Journal information 203 includes a field for consistency group ID 2031, an oldest journal field 2032, and a latest journal field 2033, including sequence number and time for each. Information regarding the latest (newest) journal of a consistency group 610 is updated according sequence number and time stamp when a new journal entry is made for that consistency group. The journal entries between the oldest sequence number and the latest sequence number in journal information 203 indicate the current effective journal for each consistency group 610.

[0060] At step 1004, array controller 110 determines the time of the journal and compares the determined time to a start time of a period defined in period-amount information 204 maintained in memory 200. FIG. 11 illustrates an example of period-amount information 204 maintained by array controller 110 for each consistency group 610. Period-amount information 204 includes a period number field 2041, a start time field 2042, an oldest sequence number field 2043 and a total size (amount) of journal generated field 2044. Thus, in period-amount information 204, periods are defined for each consistency group 610 according to intervals specified by users. Period-amount information 204 maintains the total size of the journals that are generated in each period in addition to information on the first journal entry of each period, such as sequence number of the journal entry.

[0061] When the time of the journal entry determined in step 1004 corresponds to a period of “not recorded yet” in period-amount information 204, then this means that a new time period has started, and this is the first journal entry for the next period. Thus, when the journal entry is the first journal entry of the period, the process proceeds to step 1005. However, when the time of the journal entry is not in the next period, the process skips to step 1006.

[0062] At step 1005, array controller 110 records the information about the journal entry for the corresponding period in period-amount information 204. In other words, in the embodiments illustrated, the sequence number of the journal entry is entered into the oldest sequence number field 2043 of period-amount information 204.

[0063] At step 1006, array controller 110 updates period-amount information 204 by adding the size of the journal entry to the total size of journal field 2044 in the corresponding period, and the process ends.

[0064] Operation and Process to Diminish Journal Area

[0065] FIG. 12 illustrates a process to diminish (minimize) the journal area. The process carried out includes steps 1101-1110, as described below.

[0066] At step 1101, management terminal 520 sends to array controller 110 a request to obtain information about the journal stored in journal volumes 630 of a consistency group 610, such as for a specified time period.

[0067] At step 1102, array controller 110 acquires the size of the journal generated in the specified consistency group 610 during the specified period. One method to acquire the amount of journal data generated is by referring to period-amount information 204 and calculating the size of the journal. Searching corresponding metadata and reading the data contained therein can be used as another method to acquire the size information over the specified time period.

[0068] At step 1103, array controller 110 reports the information about the size of the journal for the requested period, and may also report the latest snapshot time of the consistency group 610 to management terminal 520. The latest snapshot time may be obtained from the volume information 202.

[0069] At step 1104, management terminal 520 presents to users the relation between the requested period and the amount of journal data generated over the requested period. The latest snapshot time may also be presented.

[0070] FIG. 13 is an example of the relation between the specified time period and the amount of journal data generated over the specified time period. Management terminal 520 can display charts like this to users via a graphic user interface (GUI), as well as by just displaying the numerical data (values) of the amount of journal data and the time period.

[0071] At step 1105, a user or management software 521 on management terminal 520 determines a new size of a storage area to store the journal (i.e., a new size for journal volume 630) for the consistency group 610 by referring to the presented information described above.

[0072] At step 1106, a user or management software 521 instructs array controller 110 to change the size of the journal area for the consistency group 610. For reducing the size of the journal volume 630, this can entail the array controller 110 reducing the size of the journal volume by eliminating storage areas storing journal entries older than the latest snapshot. For increasing the size of the journal volume, additional physical storage space may be allocated.

[0073] At step 1107, array controller 110 inspects what the effect of the instructed change in the journal area size would have on the journal data already stored. If the oldest journal after the change would be older than the latest (newest) snapshot, the proposed change is acceptable, and the process proceeds to step 1108. However, if the oldest journal after the change would be newer than the latest snapshot, then the change is not acceptable, and the process proceeds to step 1110.

[0074] At step 1108, array controller 110 updates the information about the oldest journal in journal information 203 to invalidate the journal data to be deleted, so that the new oldest journal entry is the oldest journal entry remaining after the resizing.

[0075] At step 1109, array controller 110 changes the size of the journal area of the consistency group 610 and releases the surplus storage area containing journal entries older that the new oldest journal entry, so that the surplus storage area may be applied to another use. The size of the journal area may be reduced in several ways. Two examples of this include the following:

[0076] (1) Making a contiguous free (unused) area in the last part of journal volume 630 (volume 602) by copying (or moving) valid journal entries; or

[0077] (2) Changing the configuration of the volumes 602 (i.e., by shrinking of the volumes 602).

[0078] At step 1110, array controller 110 rejects the instruction to change the journal area size because the restoring of data by applying journal entries to a snapshot would not be able to be performed if there would be no snapshot that is older than the oldest journal entry. Alternatively, rejection of the instruction due to time of the latest snapshot may be performed by management terminal 520 as a result of evaluation of the latest snapshot time received from the storage controller 110.

[0079] In addition to the dynamic changing of the journal area while keeping a part of the journal data, as mentioned above, reconfiguration may also be made from the initial state to achieve a change in the size of the journal area. In the case of such initial reconfiguration, inspection for existence of a snapshot is not required.

[0080] Continual Monitoring of Relation between the Amount and the Period of the Stored Journal

[0081] Management terminal 520 can monitor the relation between the amount and time period of the stored journal data in each consistency group 610 by inquiring on a regular continual basis to array controller 110 regarding the relation between the amount and period of journal data in each journal volume. Management terminal 520 is able to store a log of the acquired information as monitoring data 522, and can display the acquired information to users. Users or management software 521 can use the acquired information for making various decisions, including determination an optimal size of the journal storage area.

[0082] FIG. 14 illustrates the system configuration of the second embodiments. The differences from the configuration of the first embodiments are that memory 200 includes chunk mapping information 205 and chunk usage information 206. In this configuration, storage areas provided by disks 600 are divided into a number of fixed-length storage area (i.e. chunks 690), and volumes (logical units) including journal volumes 630 are provided by allocating chunks of storage on demand. Moreover, in the second embodiments, as illustrated in FIG. 15, consistency group information 201 includes an additional preservation period field 2016, which retains information on a specified preservation period for journal data, as is discussed further below.

[0083] FIG. 16 illustrates a manner to provide volumes 602 in the storage system 100 of the second embodiment. In FIG. 16, a journal volume 630 is constituted by multiple segments 692 virtually, and one chunk 690 is assigned to one segment 692 as physical storage area on an as-used basis. Thus, each logical volume 602 is composed of a plurality of logical segments 692, and each segment 692 of the volume has a segment size that is equal to the size of a chunk 690 of physical storage area. For example, as illustrated in FIG. 14, in one embodiment, each chunk 690 might be composed of physical storage space from four HDDs 600, such as 512 bytes on each HDD, so that the chunk size would be a storage capacity amount of 2048 bytes. The size of a segment 692 in such a configuration would preferably also be 2048 bytes. The segments 692 are typically numbered sequentially starting from zero to a maximum segment size, as illustrated in FIG. 16, while also being associated with logical block addresses for storage. Initially, no chunks or a predetermined small number of chunks might be allocated to the journal volume 630. When a write is made to an address in a segment of the journal volume that does not yet have a physical storage chunk allocated to it, the storage system allocates a chunk to the targeted segment.

[0084] To enable this dynamic chunk allocation functionality, array controller 110 uses chunk mapping information 205, as illustrated in FIG. 17, and chunk usage information 206, as illustrated in FIG. 18. FIG. 17 is an example of chunk mapping information 205, which may include a volume ID field 2051, a segment ID field 2052, an assigned/unassigned field 2053 and a chunk ID field 2054. Thus, chunk mapping information 205 maintains the mapping between chunks 690 and segments 692 of each volume. Status of assignation is ‘No’ in field 2053 if no chunk is assigned to the segment, and “Yes” when a chunk has been assigned. This information 205 can also be constructed as a list or a directory of each element to achieve faster searching capability.

[0085] FIG. 18 illustrates an example of chunk usage information 206 that includes a chunk ID field 2061, a usage field 2062, a volume ID field 2063 and a segment ID field 2064. The chunk usage information 206 enables the array controller 110 to quickly determine whether a chunk is used or not, and if the chunk is used, the volume and volume segment to which it is assigned. By using this information, array controller 110 is able to find free (unused) chunks in the process described below. This information also can be constructed as a list or a directory of each element to achieve faster searching capability.

[0086] Process of Generating a Journal

[0087] FIG. 19 illustrates a process of generating a journal in the second embodiments. The process includes steps 1301-1312, as described in detail below.

[0088] At step 1301, host 500 issues a write request and transfers write data to array controller 110.

[0089] At step 1302, array controller 110 stores the write data in the targeted production volume 620 in accordance with the write request.

[0090] At step 1303, array controller 110 checks the remaining (unused) size of the current chunks (or segments) for metadata and for journal data in the journal volume 630.

[0091] At step 1304, as a result of the inspection in step 1303, if the size of metadata of the new journal entry is larger than the remaining size of the current chunk (or segment) for the metadata area 631, the process proceeds to step 1305. If not, the process proceeds to step 1307.

[0092] At step 1305, array controller 110 assigns a new chunk to a segment as an area to store metadata. The new chunk is assigned from free chunks located using chunk usage information 206, and when the chunk is assigned, the chunk mapping information 205 and chunk usage information 206 is updated.

[0093] At step 1306, array controller 110 stores the metadata to the new chunk.

[0094] At step 1307, since it was determined at step 1304 that sufficient storage capacity is already present for storing the metadata for the new journal entry, array controller 110 stores the metadata to the current chunk/segment.

[0095] At step 1308, as a result of the inspection in step 1303, if the size of the write data (i.e., the journal data) for the new journal entry is larger than the remaining size of the current chunk/segment for journal data area 632, the process proceeds to step 1309. On the other hand, if there is sufficient capacity in the current chunk/segment to store the journal data for the new journal entry, the process proceeds to step 1311.

[0096] At step 1309, array controller 110 assigns a new chunk to a segment of journal volume 630 as an area to store the journal data for the new journal entry. The new chunk is selected from free chunks by referring to the chunk usage information 206, and the chunk mapping information 205 and chunk usage information 206 are updated. The segment 692 in journal volume 630 that is selected to store the new chunk typically will be the next unused segment in the journal volume 630, so that segments of the journal volume are filled sequentially from lower-numbered segments to higher-numbered segments.

[0097] At step 1310, array controller 110 stores the write data to the new chunk/segment as journal data.

[0098] At step 1311, since there was sufficient capacity in the existing chunk/segment, array controller 110 stores the write data to the current chunk/segment as journal data.

[0099] At step 1312, array controller 110 updates information about the latest journal entry, such as sequence number and time in journal information 203, and the process ends.

[0100] Accordingly, it may be seen that, by the above process, a series of journal entries are stored in multiple chunks/segments, as illustrated in FIG. 20. Using this method, the starting point of a chunk is always the starting point of a journal entry (either journal data or metadata). A new chunk is allocated when the remaining length (capacity) of a current chunk is less than the length (size) of the journal data or metadata, respectively, to be stored.

[0101] Process to Diminish Journal Area

[0102] FIG. 21 illustrates a process to diminish or minimize the journal area in the storage system in the second embodiments. Array controller 110 may perform the process to diminish the journal area on a regular periodic basis for each consistency group, such as by checking journal volumes in order of sequence number, i.e., chronological order. Accordingly, steps 1401-1406 may be carried out for each journal volume in the storage system.

[0103] At step 1401, array controller 110 checks information about the newest journal entry in the chunk that stores the oldest journal data in the consistency group 610. Thus, the array controller checks for the time stamp of the most recent journal entry in the chunk having the oldest journal data to determine the time of that journal entry.

[0104] At step 1402, as the result of the inspection in step 1401, if the time of the newest journal data in the chunk is outside (i.e., older than) the specified preservation period entered in field 2016 of information 201, then the data contained in this chunk/segment is no longer needed, so the process proceeds to step 1403 to prepare to release the chunk. However, if the time of the newest journal in the chunk is not older than the specified preservation period, the process ends because the journal data is required to be retained until the predetermined preservation period for the journal data has expired.

[0105] At step 1403, array controller 110 updates the information about the oldest journal in journal information 203 to invalidate all journal data in the chunk to be released. Thus, the oldest journal field 2032 for the journal volume 630 of the consistency group is updated to the sequence number and time of the journal entry that immediately follows the journal entry identified in step 1401. This is carried out by determining the first journal entry at the start of the next chunk/segment that follows the chunk to be released.

[0106] At step 1404, array controller 110 releases the chunk to be released. This is accomplished by array controller 110 updating chunk mapping information 205 and chunk usage information 206 to make the chunk to be released a free chunk.

[0107] At step 1405, array controller 110 checks metadata that was invalidated by release of the chunk released at step 1404. If all metadata in one chunk/segment storing metadata has been invalidated, the process proceeds to step 1406. If not, the process ends, since at least some of the metadata in that chunk/segment still relates to stored journal entries.

[0108] At step 1406, array controller 110 releases the chunk for the metadata. This is accomplished by array controller 110 updating chunk mapping information 205 and chunk usage information 206 to make the chunk storing the metadata a free chunk.

[0109] The predetermined preservation period (retention period) mentioned above is determined for each consistency group 610 by users or policy, and is set to array controller 110 via management terminal 520. As described in the first embodiments, management terminal 520 may perform inquiry and monitoring about relations between the amount and the period of the journal data. Users may determine the predetermined preservation period by referring to the amount-period information acquired based on monitoring data 522 presented by management terminal 520, as discussed above with reference to FIG. 13 in the first embodiments.

[0110] FIG. 22 illustrates another method to diminish journal area. In this process, the amount of the journal is used as a condition to delete journal entries and diminish the journal area, instead of the preservation period described in FIG. 21 and FIG. 15. With this process, a user can diminish the journal area from the perspective of the amount of journal data.

[0111] At step 1501, array controller 110 checks the amount of the journal data in the consistency group. One technique for accomplishing this is by determining the number of chunks assigned to the journal volume 630 using chunk mapping information 205, and then multiplying the number of chunks used for the journal volume by the set storage capacity of an individual chunk.

[0112] At step 1502, following the inspection in step 1501, the array controller determines whether the amount of journal data is larger than a predetermined amount set by a user, or set according to a predetermined policy. If the amount of journal data exceeds the predetermined amount, the process goes to step 1503. If the amount of journal data does not exceed the predetermined amount, the process ends.

[0113] At step 1503, array controller 110 updates the journal information to invalidate the journal in the chunk that stores the oldest journal data. Thus, the oldest journal field 2032 for the journal volume 630 of the consistency group is updated to the sequence number and time of the first journal entry in the second-to-oldest chunk.

[0114] At step 1504, array controller 110 releases the oldest chunk by updating chunk mapping information 205 and chunk usage information 206 to make the oldest chunk a free chunk.

[0115] At step 1505, array controller 110 checks metadata that was invalidated by release of the oldest chunk released at step 1504. If all metadata in one chunk/segment storing metadata has been invalidated, the process proceeds to step 1506. If not, the process ends, since at least some of the metadata in that chunk/segment containing metadata still relates to stored journal entries.

[0116] At step 1506, array controller 110 releases the chunk for the metadata. This is accomplished by array controller 110 updating chunk mapping information 205 and chunk usage information 206 to make the chunk storing the metadata a free chunk.

[0117] The above steps are repeated periodically for each consistency group or individual journal volume. Moreover, as described in the first embodiments, both of above processes can include steps for checking the time of the latest snapshot. If there would be no snapshot that is older than the oldest journal after deletion of journal data, the deletion should not be performed. Thus, by the system and the processes described above, flexible and automatic adjustment of the journal area is carried out, and the management of the journal area is simplified.

[0118] FIG. 23 illustrates a process of generating a journal in the third embodiments. The system configuration of the third embodiments may be the same as described above for the second embodiments. In the third embodiments, journal entries are able to be stored across chunks, such that a portion of a journal entry may be stored in a first chunk, and the remainder of the journal entry may be stored in a second chunk, thereby reducing wasted storage capacity. The process includes steps 1601-1609, as described below.

[0119] At step 1601, host 500 issues a write request and transfers write data to array controller 110.

[0120] At step 1602, array controller 110 stores the write data in production volume 620 according to the write request.

[0121] At step 1603, array controller 110 checks the remaining unused capacity (length) of the current chunk for containing metadata and the remaining unused capacity of the current chunk for containing journal data.

[0122] At step 1604, as a result of the inspection in step 1603, if the size of the metadata of the new journal entry is larger than the remaining size of the current chunk for metadata area, the process proceeds to step 1605. If not, the process proceeds to step 1606.

[0123] At step 1605, array controller 110 assigns a new chunk as an area to store metadata from the free chunks by updating chunk mapping information 205 and chunk usage information 206.

[0124] At step 1606, as the result of the inspection in step 1603, if the size of the write data (i.e. the journal data) for the new journal entry is larger than the remaining size of the current chunk be used to store new journal data, the process proceeds to step 1607. If not, the process proceeds to step 1608.

[0125] At step 1607, array controller 110 assigns a new chunk as an area to store new journal data from the free chunks by updating chunk mapping information 205 and chunk usage information 206.

[0126] At step 1608, array controller 110 stores the new metadata for the new journal entry contiguously in the chunk(s) for storing metadata and stores the write data for the new journal entry as new journal data contiguously in the chunk(s) for storing journal data, such that if the entry is too large for the remaining capacity of the chunk, a portion of the entry is stored in the remaining capacity, with the remaining portion of the entry being stored contiguously in the newly allocated chunk.

[0127] At step 1609, array controller 1 10 updates information about the latest journal entry in journal information 203.

[0128] By the above process, a series of journals are stored in multiple chunks as illustrated in FIG. 24. Thus, one journal can be divided into multiple parts and stored across multiple chunks, so that a first part of the journal data or metadata is stored in a portion of a first chunk, and a second part of the journal data or metadata is stored in a second chunk.

[0129] Process to Diminish Journal Area

[0130] FIG. 25 illustrates a process to diminish or minimize the journal area in the third embodiments. Array controller 110 may perform the process regularly for each consistency group by checking journals in order of sequence number, i.e. chronological order. Steps 1701-1702 and 1704-1706 of this process are similar to steps 1401-1402 and 1404-1406 of the process described in FIG. 21 in the second embodiments, and thus, step 1703 is different.

[0131] At step 1701, array controller 110 checks information about the newest journal entry in the chunk that stores the oldest journal data in the consistency group 610. Thus, the array controller checks for the time stamp of the most recent journal entry in the chunk having the oldest journal data to determine the time of that journal entry.

[0132] At step 1702, as the result of the inspection in step 1401, if the time of the newest journal data in the chunk is outside (i.e., older than) the specified preservation period entered in field 2016 of information 201, then the data contained in this chunk/segment is no longer needed, so the process proceeds to step 1703 to prepare to release the chunk. However, if the time of the newest journal in the chunk is not older than the specified preservation period, the process ends because the journal data is required to be retained until the predetermined preservation period for the journal data has expired.

[0133] At step 1703, array controller 110 updates the information about the oldest journal in journal information 203 to invalidate all journal data in the chunk to be released and any contiguous journal data for the last journal entry of the chunk that may be located in the adjacent (subsequent) chunks. Thus, the time and sequence number for next journal in the next chunk is entered in the oldest journal field 2032.

[0134] At step 1704, array controller 110 releases the chunk to be released. This is accomplished by array controller 110 updating chunk mapping information 205 and chunk usage information 206 to make the chunk to be released a free chunk.

[0135] At step 1705, array controller 110 checks metadata that was invalidated by release of the chunk released at step 1404. If all metadata in one chunk/segment storing metadata has been invalidated, the process proceeds to step 1706. If not, the process ends, since at least some of the metadata in that chunk/segment still relates to stored journal entries.

[0136] At step 1706, array controller 110 releases the chunk for the metadata. This is accomplished by array controller 110 updating chunk mapping information 205 and chunk usage information 206 to make the chunk storing the metadata a free chunk.

[0137] Thus, it may be seen that the invention provides flexible and automatic adjustment of a journal area and simplifies management of the journal area. While the invention has been described in the environment of an “after” journal (i.e., where the journal contains the data as it is after being updated), the invention may also be carried out in the environment of a “before” journal (i.e., where the journal contains the data as it existed before the update was conducted), as described, e.g., in U.S. Pat. No. 7,062,628, to Takashi Amano, filed Sep. 28, 2004, the disclosure of which is incorporated herein by reference. Thus, in the case of a “before” journal, as the journal area grows, the journal area may be managed as described in the three embodiments discussed above. Further, while specific embodiments have been illustrated and described in this specification, those of ordinary skill in the art appreciate that any arrangement that is calculated to achieve the same purpose may be substituted for the specific embodiments disclosed. This disclosure is intended to cover any and all adaptations or variations of the present invention, and it is to be understood that the above description has been made in an illustrative fashion, and not a restrictive one. Accordingly, the scope of the invention should properly be determined with reference to the appended claims, along with the full range of equivalents to which such claims are entitled.