WO2011033692A1 - ストレージ装置及びそのスナップショット制御方法 - Google Patents

ストレージ装置及びそのスナップショット制御方法 Download PDF

Info

Publication number
WO2011033692A1
WO2011033692A1 PCT/JP2010/000560 JP2010000560W WO2011033692A1 WO 2011033692 A1 WO2011033692 A1 WO 2011033692A1 JP 2010000560 W JP2010000560 W JP 2010000560W WO 2011033692 A1 WO2011033692 A1 WO 2011033692A1
Authority
WO
WIPO (PCT)
Prior art keywords
volume
snapshot
update data
data
differential
Prior art date
Application number
PCT/JP2010/000560
Other languages
English (en)
French (fr)
Inventor
曉 室谷
克巳 鰭崎
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to US12/811,401 priority Critical patent/US8510526B2/en
Publication of WO2011033692A1 publication Critical patent/WO2011033692A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G06F3/0607—Improving or facilitating administration, e.g. storage management by facilitating the process of upgrading existing storage systems, e.g. for improving compatibility between host and storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/065—Replication mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0689—Disk arrays, e.g. RAID, JBOD

Definitions

  • the present invention relates to a storage apparatus, and more particularly, to a storage apparatus having a function of staticizing a volume in operation at a specific date and providing a static data image as a snapshot to a user computer. Furthermore, the present invention relates to a snapshot control method for a storage apparatus.
  • Protecting user data is one of the important roles of storage systems that store information in the information society.
  • a snapshot function is known as one of functions for protecting user data.
  • the snapshot function refers to a function that freezes a volume in operation at a specific date and provides a static data image to a user computer such as a host computer.
  • a static data image of a volume is called a snapshot.
  • the storage apparatus can provide multiple generations of snapshots to the user.
  • the snapshot function is intended to salvage data from operating mistakes, such as when a file is deleted unintentionally by the user.
  • the user can recover the data at the time of creating the snapshot by returning to the snapshot of the desired generation such as the previous generation.
  • the snapshot function is to guarantee the user a data image at a specific date and time of the volume.
  • Japanese Patent Application Laid-Open No. 2004-342050 discloses a conventional technique for disclosing this snapshot function.
  • a file server as a storage device provides a snapshot to a client computer as a virtual volume.
  • the file server uses the snapshot based on the primary volume as the active volume that is continuously accessed by the client computer and the differential volume that stores the data before the primary volume is updated (data before update). To provide.
  • the file server After the file server acquires a snapshot, if there is a write access from the client computer to the primary volume, the file server reads the pre-update data from the primary volume, writes it to the differential volume, and then updates the primary volume. Record. Which block of the primary volume has been updated is managed by a bitmap.
  • the file server refers to the bitmap, and in the case of access to the flagged block address, the corresponding area of the primary volume is updated.
  • the pre-update data is read from the differential volume and the block address for which the flag is not set is accessed, the corresponding area of the primary volume is not updated, so the data is read from the primary volume and the read data is read We decided to provide it to client computers.
  • JP-A-2005-284609 and JP-A-2007-226596 are JP-A-2005-284609 and JP-A-2007-226596.
  • JP 2004-342050 A JP 2005-284609 A JP 2007-226596 A
  • Snapshot technology that allows users to salvage past files on their own without the hassle of an administrator can be realized simply by providing the user with a virtual volume without stopping I / O to the primary volume.
  • Setting items for operating shots are also simpler than conventional backups, and users can use snapshot technology because they have the advantage that past data of unstructured files can be used online. It has come to be used frequently for backup purposes.
  • the file server when there is a write access to the primary volume, the file server reads the pre-update data from the primary volume, writes it to the differential volume, and then writes the update data to the primary volume.
  • the write processing speed of the pre-update data for the differential volume is significantly reduced, and as a result, the I / O processing performance for the primary volume is greatly impaired.
  • the vendor of the file storage system is forced to construct a differential volume with storage with a high bit cost, and as a result, the capacity of the differential volume is limited. Therefore, in the first place, there is a problem that the operation to use the snapshot function as a backup inevitably gets stuck in the evening.
  • an object of the present invention is to provide a storage apparatus and a snapshot control method for the storage apparatus that prevent the amount of pre-update data held in the differential volume from increasing even if the snapshot is operated as a backup unit for a long period of time. To do.
  • Another object of the present invention is to provide a storage apparatus capable of maintaining I / O performance for an operation volume even when a low bit cost / low speed storage device is used as a differential volume for snapshot, and its snapshot control method. Is to provide.
  • the present invention replaces a snapshot that uses pre-update data with a snapshot that uses post-update data, thereby storing the pre-update data of the differential volume accordingly. Is released as a free area, thereby avoiding accumulation of pre-update data in the differential volume.
  • the present invention does not write updated data to the differential volume even when the client computer performs I / O to the operation volume. Therefore, the updated data storage type differential volume is configured from a high-performance storage device. Even if not, the snapshot function can be provided to the user without adversely affecting the I / O processing performance of the storage apparatus.
  • the present invention it is possible to provide a storage apparatus that prevents the amount of pre-update data held in the differential volume from increasing even if the snapshot is operated as a backup means for a long period of time.
  • FIG. 1 is a hardware block diagram relating to a first embodiment of a storage system according to the present invention.
  • FIG. 3 is a functional block diagram of a memory 114.
  • FIG. It is a detailed block diagram of a snapshot management program. It is a block diagram explaining operation
  • It is a management table for managing the pre-update data utilization type snapshot. The initial state in the process of registering a virtual volume in the management table of the pre-update data use type snapshot is shown. The management table showing the state following FIG. 6A is shown. The management table showing the state following FIG. 6B is shown. The management table which shows the state following Drawing 6C is shown. The management table showing the state following FIG. 6D is shown.
  • FIG. 10 is a flowchart for determining the start of a process for shifting a snapshot operation using a pre-update data storage type differential volume to one using an update data storage type differential volume.
  • FIG. 10 is a flowchart showing details of migration processing referred to in the description of FIG. 9.
  • FIG. 7 is a management table in which a plurality of virtual volumes belonging to the management system of FIG. 7 are registered, and this management table manages snapshots using the pre-update data storage type differential volume.
  • FIG. 7 is a management table in which a plurality of virtual volumes belonging to the management system of FIG. 7 are registered, and this management table manages snapshots using the updated data storage type differential volume. It is a pre-update data use snapshot management table after the operation of the snapshot is shifted from the one using the pre-update data to the one using the update data. A state in which a replication volume is registered in a snapshot management table that uses updated data is shown. It shows a migration target bitmap for migrating a snapshot management table that uses pre-update data to updated data. The migration target bitmap shows a state in which a virtual volume is migrated from a snapshot management table that uses pre-update data to a snapshot management table that uses updated data. FIG.
  • 14C shows a state where another virtual volume has been migrated to the virtual table.
  • 10 is a flowchart for the storage apparatus to process a write command from a client computer after the management of the snapshot is shifted to an operation using updated data. It is a flowchart for explaining that the storage apparatus processes the read processing for the snapshot volume after the management of the snapshot is shifted to the operation using updated data.
  • FIG. 1 is a hardware block diagram showing a first embodiment of a storage system using a storage apparatus according to the present invention.
  • This storage system has a configuration in which a client computer 131, a management client 132, and a media server 133 that are connected to each other via a network 151 are connected to a network attached storage device (NAS) 100.
  • NAS network attached storage device
  • the network 151 performs communication using a protocol such as TCP / IP, and transfers control signals and data between devices connected to the network 151.
  • the client computer 131 is a computer device operated by the user, accesses the NAS 100, and reads and writes data.
  • a plurality of client computers 131 may be connected to the network 151. Examples of the client computer include a host computer, a business server, and a PC client.
  • the management client 132 is a computer device operated by an administrator (administrative user) and is used for management of the NAS 100.
  • the management client 132 includes at least a CPU, a memory, and an interface.
  • the media server 133 is a device for backing up data recorded in the NAS 100 to a recording medium such as a tape, and may be, for example, a magnetic tape device or a large-capacity magnetic disk device.
  • the NAS 100 provides a file sharing service to the client computer 131.
  • the NAS 100 includes a controller 101 and a disk device 115.
  • the disk device 115 includes a plurality of disk drives 200 and 202. On the disk device 115, the file requested to be written by the client 131 is recorded divided into blocks.
  • the disk drive 200 is a high-performance device that can realize high-speed data read / write, and is, for example, compatible with Fiber Channel.
  • the disk drive 202 is a low-performance and low bit cost disk drive such as SATA.
  • a plurality of high-performance disk drives 200 constitute a first RAID group, and a primary volume (hereinafter referred to as “P volume” or “P-VOL”) as an operation volume accessed by the client computer 131.
  • P volume primary volume
  • P-VOL pre-update data storage differential volume
  • D volume D-VOL
  • a plurality of low-performance disk drives 202 constitute a second RAID group, in which updated data storage differential volume (hereinafter referred to as F volume or F volume) that stores update data for the P volume is stored.
  • F volume or F volume updated data storage differential volume
  • -VOL which may be abbreviated as -VOL
  • R volume replication volume
  • the R-volume 142A may be set in a RAID group constituted by the disk drives 200.
  • the P volume 141 is an operational volume that accepts I / O from the client computer 131, and data is written in units of blocks in response to a write request from the client computer 131. In response to a normal read request from the client computer 131, data is read in units of blocks.
  • the controller 101 includes a CPU 111, a network interface (I / F) 112, a storage interface (I / F) 113, and a memory 114.
  • the CPU 111 executes various programs stored in the memory 114, and provides a file supply service and a snapshot function to the user.
  • FIG. 2 is a functional block diagram of the memory 114.
  • the memory 114 includes a file server program 121 that operates under the management of NASOS, a file system processing program 123, a snapshot management program 124, a backup processing program 125, and a snapshot management table 144.
  • the memory 114 generates a virtual volume (V-VOL) 143A by a volume manager program and shows this as a snapshot volume to the user.
  • V-VOL virtual volume
  • the virtual volume 143A freezes the data image of the primary volume 141 at that time and provides this to the user. Therefore, it is generated for user access.
  • the first is a snapshot generated using the operation data of the P volume 141 and the pre-update data of the D volume 142, and the second is a snapshot at a specific time. This is a snapshot generated from the data of the R volume 142A of the P volume and the updated data of the F volume 143.
  • the replication volume corresponds to the data image at the reference time of the operation volume described in the claims.
  • the block recorded in the primary volume 141 at the time of snapshot copy-on-write is copied to the D volume 142.
  • the controller 101 When the controller 101 receives a snapshot creation request from the client computer 131 or the management client 132, when the block of the primary volume 141 is overwritten thereafter, the data before being overwritten (data before update) is the D volume. 142 is copied.
  • the controller 101 combines the blocks recorded in the primary volume 141 and the blocks recorded in the D volume 142 to restore the data image of the primary volume 141 at the time of receiving the snapshot creation request as a snapshot. Can do.
  • the snapshot management table 144 includes a pre-update data use type snapshot (a D-VOL management / control table, which corresponds to FIG. 5 described later), and an update data use type snap. There are some for shots (F-VOL management / control table, which corresponds to FIG. 12 described later).
  • D volume management table When distinguishing the two, the former is referred to as “D volume management table” and the latter is referred to as “F volume management table”. In addition, the “snapshot management table” includes both.
  • the snapshot management table 144 manages one or a plurality of snapshots so that the user can use the snapshots. For each created snapshot, the block address or R of the P volume 141 is used. The correspondence between the block address of the volume 142A and the block address of the differential volume (D volume 142 or F volume 143) is recorded.
  • the “snapshot management table 144” may be simply referred to as the “management table 144”.
  • the file server program 121 In response to a data access request from the client computer 131, the file server program 121 requests the file system processing program 123 to execute a file or directory read process or write process, and the execution result is sent to the request source. Returned to the client computer 131.
  • the file server program 121 manages file sharing when there are a plurality of users by performing user authentication and granting access authority to the users.
  • the file system processing program 123 includes at least a file read request processing subprogram 201 and a file write request processing subprogram 202A.
  • the file system processing program 123 responds to a read request and a write request for a file or directory issued by the file server program 121 or the snapshot management program 124, and a volume storing a file or directory, and a position of a block to be accessed. And a size are designated, and data read processing and write processing are issued to the snapshot management program 124.
  • the file system processing program 123 can use the information at the time when the snapshot was generated by accessing the virtual volume 143A, the file system processing program 123 provides the user computer such as the client computer 131 or the management client 132 with the snapshot image of the file system. It becomes possible to do.
  • the snapshot management program 124 includes at least a snapshot creation processing subprogram 301, a copy-on-write processing subprogram 302, a snapshot composition processing subprogram 303, and a snapshot reconfiguration processing subprogram 304. It has.
  • the snapshot creation processing subprogram 301 generates a snapshot for the P volume 141. Further, the virtual volume 143A is generated so that the user can access the snapshot.
  • the snapshot creation processing subprogram 301 stores the snapshot management table 144, that is, the D-VOL management table (FIG. 5) and the F-VOL.
  • a snapshot virtual volume area is set in each management table (FIG. 12).
  • the client computer 131 can access a snapshot that is a static data image of the P volume at a specific date and time via the virtual volume 143A.
  • the virtual volume 143A itself is a virtual volume with no storage area allocated, and the P volume 141, the D volume 142, the F volume 143, and the R volume 142A have an entity that stores data related to snapshots.
  • the replication volume (R-VOL) 142A is a replication volume obtained by staticizing the P volume 141 at a certain date and time.
  • the copy-on-write processing subprogram 302 uses the snapshot management table 144 to manage the D volume 142 that stores the pre-update differential data necessary for maintaining the snapshot and the F volume 143 that stores the post-update differential data. Even if the data write process according to the request of the file system processing program 123 is performed on the P volume, the process of maintaining the snapshot is performed.
  • the pre-update data stored in the P volume 141 is copied to the D volume 142, and then the storage content of the P volume 141 is updated.
  • the copy-on-write processing subprogram 302 is configured so that the user can access the data stored in the P volume 141 after the generation of the snapshot, and the P volume 141 or the R-volume 142A and the differential volume. Data stored in the (D volume 142, F volume 143) is managed, and the user device (131, 132) is made accessible to the virtual volume 143A for providing a snapshot of the generated P volume 141.
  • the copy-on-write processing subprogram 302 reads data to be read into the P volume 141 when a read from the host computer is made to the virtual volume.
  • a bitmap for determining whether or not there is the D volume 142 is formed and stored in the D volume management table 144 (FIG. 5).
  • the snapshot composition processing subprogram 303 reads the read when the read from the host computer is for the virtual volume.
  • a bit map for determining whether the target data is in the R volume 142A or the F volume 143 is formed and stored in the F volume management table 144 (FIG. 12).
  • the snapshot synthesis processing subprogram 303 performs a read process (that is, a process for using a snapshot) of the virtual volume 143A in response to a request from the file system processing program 123 or the backup processing program 125.
  • the snapshot composition processing subprogram 303 refers to the bitmap area of the D volume management table 144 (FIG. 5) to determine whether to read data from the P volume 141 or the D volume 142. From the determined volume address, the data existing in the P volume 141 is supplied to the file system processing program 123 when the snapshot creation request is made.
  • the snapshot composition processing subprogram 303 refers to the bitmap area of the F volume management table 144 (FIG. 12) to determine whether to read data from the R volume 142A or the F volume 143. From the determined volume address, the data existing in the P volume 141 is supplied to the file system processing program 123 when the snapshot creation request is made.
  • the virtual volume 143A is visible to each of the user computers (131, 132, 133) as a snapshot at a specific date and time.
  • the snapshot reconfiguration processing subprogram 304 performs processing to replace the pre-update data use type snapshot with the update data use type snapshot.
  • the process of deleting the entry of the pre-update data using type snapshot from the D volume management table (FIG. 5) is also performed. Then, by releasing the area storing the pre-update data of the D volume 142 as a free area, the capacity of the D volume 142 is prevented from being compressed.
  • the snapshot reconstruction processing subprogram 304 can be executed without making the user computer aware of such snapshot type replacement.
  • the snapshot composition processing subprogram 303 refers to the management table for the D volume 142 (FIG. 5) and the management table for the F volume 143 (FIG. 12) to create a snapshot.
  • the backup processing program 125 When the backup processing program 125 receives a backup request designating a specific snapshot from the management client 132, the backup processing program 125 transfers data corresponding to the snapshot among the data recorded in the disk device 115 to the media server 133. Backup processing for a specific date and time snapshot.
  • FIG. 4 a snapshot V3 (virtual volume V3) is created at 23:00 on March 31 and the P volume is updated on April 2 and April 20, respectively, and at 23:00 on April 30
  • V4 virtual volume V4
  • FIG. 5 is a snapshot management table (D volume management table) for managing the pre-update data use type snapshot as described in JP-A-2004-342050.
  • D volume management table D volume management table
  • the column 511 of the snapshot management table corresponds to the block address of the P volume 141, and the first row (first row) 501 which is the first row is assigned the block address 0 of the P volume.
  • the second row 502 is assigned the P volume block address No. 1
  • the third row 503 is assigned the P volume block address No. 2
  • the P volume block address is assigned in order
  • the last row 504 is assigned. Is assigned the block address (m-1) of the P volume.
  • a plurality of virtual volumes 143A (513, 514, 515) are registered in the snapshot management table. Each virtual volume corresponds to a snapshot created at a different date and time. Each block 511 of the P volume 141 corresponds to each block of the virtual volume. The numerical value described in each row (501 to 504) of the virtual volume is the segment address of the D volume 142.
  • the first row of virtual volume 1 (513) corresponding to the first snapshot is assigned the D volume segment address “0”, and the second row is the D volume segment address “1”.
  • Registered, “None” is set in the 3rd and m ⁇ 1th rows because there is no D volume segment address assignment.
  • the copy-on-write processing program 302 When the 0th data of the block address of the P volume 141 is updated, the copy-on-write processing program 302 writes the pre-update data of the P volume block address 0 to the unused segment address of the D volume 141, This segment address is written into block address 0 of virtual volume 1.
  • FIG. 5 illustrates that “0” is registered as the segment address of the D volume 142.
  • segment address “1” assigned to the second row of the virtual volume 1 is that of the D volume 142, and when the data of the block address 1 of the P volume is updated, the data before the update is It is written in the segment address “1” of the D volume.
  • “None” is registered in the block address 2 of the P volume in the third row of the virtual volume 1 and the block address (m ⁇ 1) of the P volume in the mth row. “None” indicates that no write (update) has been performed from the client computer to the block address No. 2 and (m ⁇ 1) of the P volume.
  • each of the virtual volumes 2 (514),..., N (515) corresponds to a snapshot at a specific time point.
  • virtual volume 2 (514) is a virtual volume V3 corresponding to a snapshot on March 31 and virtual volume 1 is a virtual volume V4 corresponding to a snapshot on April 30. is there.
  • Virtual volume n (515) corresponds to a snapshot before the end of February.
  • Column 512 shows a CoW bitmap, which is composed of a plurality of bit strings.
  • b-1, b-2,..., Bn are bit strings, respectively.
  • Each bit string corresponds to each virtual volume.
  • Bit string b-1 corresponds to virtual volume 1
  • bit string b-2 corresponds to virtual volume 2
  • bit string b-n corresponds to virtual volume n.
  • Each bit in each bit string corresponds to each block address.
  • bit string indicates that the corresponding block of the P volume 141 has been updated, and “1” indicates that the corresponding block of the P volume 141 has not been updated.
  • the snapshot creation processing subprogram 301 When the NAS 100 receives a request for creating a snapshot at a certain date and time from a client computer, the snapshot creation processing subprogram 301 newly manages a virtual volume entry and a bit string entry corresponding to this virtual volume. Register in the table (FIG. 5). At this point, “none” is set for each block of the new virtual volume entry, and “1” is set for each block of the bit string.
  • the copy-on-write processing subprogram 302 When the copy-on-write processing subprogram 302 receives a write to the P volume 141 from the host computer, it detects the block address, reads the pre-update data of this block address, and stores it in the empty segment of the D volume 142.
  • the copy-on-write processing subprogram 302 registers the segment number of the D volume in which the pre-update data is stored in the corresponding block of the virtual volume (new).
  • the copy-on-write processing subprogram 302 checks the corresponding block of the virtual volume (old), and if it is determined that “None” is registered here, the corresponding block of the virtual volume (new) Register the number registered in. On the other hand, when it is determined that the block number is registered instead of “None”, this is maintained.
  • the copy-on-write processing subprogram 302 registers the segment number of the D volume 142 in the block of the virtual volume (new), the bit “1” of the corresponding block of the bit string corresponding to the virtual volume (new) is set to “0”. Set to.
  • the snapshot composition processing subprogram 303 determines the ID of the virtual volume that has been read from the read access, and refers to the bit string (such as b-1 in FIG. 5A) corresponding to this virtual volume.
  • the snapshot composition processing subprogram 303 refers to the bit corresponding to the block that is the read target of the virtual volume, and determines the bit “0”, and then determines the segment number registered in the corresponding block of the virtual volume. get.
  • the D volume 142 is accessed based on this segment number, the pre-update data of the P volume 141 at the time of creating the snapshot is acquired and transmitted to the client computer.
  • the snapshot composition processing subprogram 303 refers to the bit corresponding to the block that is the read target of the virtual volume, and when determining the bit “1”, accesses the corresponding block of the operation volume 141 and snapshots. Data of the P volume 141 at the time of creation is acquired and transmitted to the client computer.
  • Block ID may be used instead of block address.
  • the snapshot management table 144 (FIG. 5) is created and managed for each P volume. In a typical embodiment, if the block size is 512 bytes and the operation volume size is 128 gigabytes, the number of blocks in the operation volume is 25000000. The maximum number of snapshots is assumed to be 64.
  • V3 is a virtual volume for providing the user with a snapshot on March 31, 23:00
  • V4 is a virtual volume for providing the user with the snapshot on April 30, 23:00. It is a volume.
  • FIG. 6A shows an example of a snapshot management table as of March 31 at 23:00.
  • B3 in FIG. 4 is a map image of the bit string b-1.
  • b1 to b16 correspond to 0 to 15 of the “block address” of the bit string b-1.
  • the copy-on-write processing subprogram 302 enters the block 2 on April 2 at 14:00.
  • the pre-update data (a) is read from the corresponding block “3” of the P volume, and the read data (a) is stored in the empty segment “20” of the D volume 142.
  • the empty segment of the D volume is acquired from the free queue that manages this. Also, the used block of the D volume is released from the free queue.
  • the management table at this point is as shown in FIG. 6B. That is, the copy-on-write processing subprogram 302 registers the segment address “20” of the D volume 142 in the block “2” of the virtual volume V3, and sets “0” in the block “2” of the bit string b-1. To do.
  • the copy-on-write processing subprogram 302 changes the pre-update data (b) to the P volume. Read from the block “12” and store the read data (b) in the empty segment “21” of the D volume 142.
  • the management table at this point is as shown in FIG. 6C. That is, the copy-on-write processing subprogram 302 registers the segment address “21” of the D volume 142 in the block “12” of the virtual volume V3, and sets “0” in the block “12” of the bit string b-1. To do.
  • FIG. 4 further shows that a snapshot is created at 4.30 (23:00).
  • V4 is a virtual volume corresponding to this snapshot.
  • the management table at this point is shown in FIG. 6D.
  • b-2 is a bit string corresponding to the virtual volume V4.
  • B4 in FIG. 4 is a map image of the bit string b-2.
  • the management table at this point is as shown in FIG. 6E. That is, the copy-on-write processing subprogram 302 registers the segment address “22” of the D volume 142 in the block “1” of the virtual volume V4, and sets “0” in the block “1” of the bit string b-2. To do.
  • the copy-on-write processing subprogram 302 registers the segment address “22” of the D volume 142 in the block “1” of the virtual volume V3 in order to guarantee the snapshot of 3.31 (23:00) to the user. Then, “0” is also set in the block “1” of the bit string b-1.
  • the copy-on-write processing subprogram 302 stores the pre-update data (A) in the P volume 141. Read from the corresponding block “3” and store the read data (A) in the empty segment “23” of the D volume 142.
  • the management table at this point is as shown in FIG. 6F. That is, the copy-on-write processing subprogram 302 registers the block address “23” of the D volume 142 in the block “3” of the virtual volume V4, and sets “0” in the block “3” of the bit string b-2. To do.
  • the snapshot composition processing subprogram 303 refers to the bit string b-1 in the management table FIG.
  • the corresponding bit is “0”.
  • the snapshot composition processing subprogram 303 refers to the block address “3” of the virtual volume V3 to confirm the segment address “20” of the D volume 142, and from the segment “20” of the D volume, the pre-update data “ a ”is read and provided to the file system processing program 123.
  • the snapshot composition processing subprogram 303 refers to the bit string b-2 in the management table FIG.
  • the block address “3” is detected, it is confirmed that the corresponding bit is “0”.
  • the snapshot composition processing subprogram 303 refers to the block address “3” of the virtual volume V4 to confirm the segment address “23” of the D volume 142, and from the segment “23” of the D volume, the pre-update data “ A ”is read and provided to the file system processing program 123.
  • the snapshot composition processing subprogram 303 determines “1” with reference to the bit of the management table FIG. 6F, the data is read from the P volume 141 and provided to the client computer 131.
  • storing the pre-update data in the D volume and generating a snapshot of the operating volume (P volume 141) by the client computer is in comparison with a backup that requires a full copy of the operating volume. Therefore, the snapshot function has been frequently used instead of backup because it is simple and convenient, such as without stopping the IO from the client 131 and based on the backup plan.
  • the storage apparatus 100 writes the pre-update data to the D volume composed of a high-performance disk drive every time there is a write access from the client computer 131 to the P volume 141, and the write from the client computer 131 The response performance to access was improved.
  • the NAS 100 operates the D volume for a long time in order to continue the snapshot function, a large amount of pre-update data is accumulated in the D volume, and the capacity of the D volume is considerably compressed.
  • the write to the P volume 141 is not completed until the pre-update data is read from the P volume 141 and written to the D volume 142. If a low-performance storage device is used for the D volume, the write to the D volume is not performed. It becomes the rate-limiting step.
  • the NAS 100 newly sets an update data storage type differential volume (F volume 143) for storing update data, and generates a snapshot based on the update data. By releasing the data staying for a period from the D volume 141, the compression of the capacity of the D volume is prevented.
  • F volume 143 update data storage type differential volume
  • the F volume 143 is for storing updated data and is not accessed by the client computer 131 at the time of writing. Therefore, the F volume 143 is not high performance and expensive like the storage device for the D volume 142. Also good.
  • This operation is realized by a policy for migration. For example, when the used capacity of the D volume 142 exceeds a predetermined threshold value, the migration process is performed, and the number of snapshot volumes has a predetermined threshold value. There are types such as executing the migration process when the number exceeds the limit, and executing the migration process for the snapshots of the year at the end of each year.
  • the latest snapshot is operated by the D volume from the viewpoint of management of the migration process. Is preferably maintained.
  • FIG. 7 is a block diagram showing an embodiment in which the operation of the snapshot function using the D volume is shifted to the operation using the F volume.
  • V3 to V6 are snapshot volumes (virtual volumes) at specific points in time (described in FIG. 7).
  • the snapshot reconfiguration processing subprogram 304 quiesces the replication volume (R-VOL) 142A from the virtual volume V3 in order to generate a quiesced volume that is the basis for determining the post-update data stored in the F volume 143. It is generated as a structured volume (S2 in FIG. 7).
  • the snapshot reconfiguration processing subprogram 304 changes the snapshot volume at the time of 2009.3.30 from the virtual volume V3 to the R-VOL.
  • the snapshot reconfiguration processing subprogram 304 creates a virtual volume V4 and a virtual volume after creating the F volume management table (FIG. 12) so that a snapshot volume can be generated based on the F-VOL and R-VOL. Release allocation of P-VOL and D-VOL to V5 (S8, S9, S12, S13) and allocate F-VOL and R-VOL to these virtual volumes (S6, S7, S10A, S11) .
  • the NAS 100 uses the P-VOL and D-VOL for the operation of the latest virtual volume V6 so that the response to the write access from the host computer 131 does not deteriorate while maintaining the snapshot function. (R1, R2).
  • This operation is mainly achieved by the snapshot reconstruction processing subprogram 304.
  • the snapshot reconstruction processing subprogram 304 first executes the flowchart of FIG. This flowchart determines whether or not to start the migration process.
  • the snapshot reconstruction processing subprogram 304 checks whether or not the snapshot environment matches the migration processing start condition (900). This condition is, for example, a reduction in unused area of the D volume 142 as described above.
  • the snapshot reconfiguration processing subprogram 304 determines that it matches this, it notifies the storage management terminal of this (902).
  • the management terminal asks the storage administrator for input for the migration process.
  • the operation change request may be made to the management client 132, and the operation change input may be made to the management client.
  • This input is an input for specifying the virtual volume to which the migration process is applied. Referring to FIG. 7, the virtual volume V3, virtual volume V4, virtual volume V5, and virtual volume V6 are input to the storage management terminal (904).
  • the snapshot reconstruction processing subprogram 304 does not consider this as a migration target. Therefore, the input of the virtual volume V6 may be omitted.
  • the snapshot reconstruction processing subprogram 304 stores the input virtual volume ID and the migration processing start flag in a predetermined area of the memory 11 (908).
  • the snapshot reconstruction processing subprogram 304 makes a negative determination in step 904 and ends the flowchart of FIG.
  • the snapshot reconstruction processing subprogram 304 repeatedly executes this flowchart every predetermined time.
  • the storage administrator can select a virtual volume to be migrated and set a migration process start flag without being based on the flowchart shown in FIG.
  • FIG. 10 is a flowchart showing details of the migration process.
  • the snapshot reconfiguration processing subprogram 304 refers to the migration start flag every predetermined time and determines that the migration start flag is set, it starts the flowchart of FIG.
  • the snapshot reconstruction processing subprogram 304 resets this flag when the flowchart of FIG. 10 ends.
  • the snapshot reconstruction processing subprogram 304 reads the identification number of the virtual volume (V-VOL) registered as the migration target in the memory 114 (1000).
  • R volume 142A is registered in the RAID group. If there is no R volume 142A, an R volume is created from the earliest virtual volume (S1 in FIG. 6), and the R volume is stored in the F-VOL management table. Register (1004).
  • the earliest virtual volume is V3 according to FIG. If the R volume exists, the snapshot reconstruction processing subprogram 304 skips step 1004.
  • the snapshot reconstruction processing subprogram 304 reads data from all blocks of the virtual volume V3, and copies the data to the corresponding blocks of the R volume (S2).
  • the snapshot reconstruction processing subprogram 304 refers to the bit string b-1 corresponding to the virtual volume V3 in the D volume management table shown in FIG. 6F, and reads data from the P-VOL or D-VOL (S3, S4). ).
  • the snapshot reconstruction processing subprogram 304 selects the next generation virtual volume V4 of the earliest virtual volume (1006), and executes migration processing for this virtual volume. This process will be specifically described.
  • FIG. 11 is an example of a D volume management table for the virtual volumes V3 to V6 in FIG. The way of viewing this table is the same as that of FIG. 6F described above. That is, the numerical value in each block of each virtual volume is the segment address of the D volume.
  • FIG. 12 is an F volume management table at the end of the migration process
  • FIG. 13 is a table for D volume management at the end of the migration process.
  • the virtual volume V3 is registered in the F volume management table (FIG. 112) as a real volume (R-VOL) that does not require reference to the F volume 143.
  • the addresses in the respective blocks of the virtual volume V4 (using F-VOL) and the virtual volume V5 (using F-VOL) indicate the segment address of the F volume that stores the update data for the P volume 141. ing.
  • “None” indicates that the snapshot synthesis processing subprogram 303 refers to the R-VOL without referring to the F-VOL when generating the snapshot.
  • the D volume management table (FIG. 11) before the start of the migration process is changed as shown in FIG. That is, the snapshot reconstruction processing subprogram 304 deletes the entries of the virtual volumes V3 to V5 from the management table.
  • step 1004 the snapshot reconstruction processing subprogram 304 registers the R-VOL in the F volume management table instead of the virtual volume V3.
  • the form of the management table in this state is as shown in FIG. 14A.
  • the snapshot reconstruction processing subprogram 304 selects the virtual volume V4 following the virtual volume V3 (1006), and creates a migration target bitmap (1008).
  • the migration target bitmap is necessary for the snapshot reconstruction processing subprogram 304 to determine whether or not update data for the P volume is registered in the F volume.
  • BA1 is a migration target bitmap for migrating the virtual volume V4 that uses the D volume to a type that uses the F volume
  • BA2 represents the virtual volume V5 that uses the D volume as the F volume.
  • This is a migration target bitmap for migrating to a type that uses. Note that the reference numeral 500 is attached, and the D volume management table shown in FIG. 11 is shown in FIG. 14A for reference.
  • the snapshot reconstruction processing subprogram 304 refers to the migration target virtual volume and the previous virtual volume in order to determine whether or not the P volume has been updated. Compare the values of the same block addresses.
  • the snapshot reconstruction processing subprogram 304 determines whether or not the P-VOL has been updated after setting the virtual volume V3 when creating the migration target bitmap BA1 for the virtual volume V4. Therefore, the migration target virtual volume V4 and the previous virtual volume V3 are compared, and the values of the same block addresses are compared. This is because the value of the same block address changes when there is an update.
  • the snapshot reconstruction processing subprogram 304 has a block address 12 in which the segment address of the D volume is set in the virtual volume V3 and is not set in the virtual volume V4. “0” is set to address 12.
  • the snapshot reconstruction processing subprogram 304 compares the virtual volume V4 and the virtual volume V5, and creates a migration target bitmap BA2 for the virtual volume V5 as shown in FIG. 14B.
  • the snapshot reconstruction processing subprogram 304 stores the migration target bitmap in a predetermined area of the memory 114.
  • step 1008 when the snapshot reconfiguration processing subprogram 304 creates the migration target bitmap BA1 for the virtual volume V4 as described above, the snapshot reconstruction processing subprogram 304 refers to this and sets the value of each block address of the bitmap. Check in order from the top (1010).
  • the snapshot reconstruction processing subprogram 304 executes Steps 1012 to 1018, and when it is “1”, executes Step 1020, which is executed for all bits. Apply.
  • the F volume management table obtained by this series of processing is as shown in FIG.
  • the snapshot reconstruction processing subprogram 304 blocks the block address “3” of the virtual volume V4.
  • the content of the segment address “23” of the D volume is read.
  • the snapshot reconstruction processing subprogram 304 acquires the free segment (eg, “63”) of the F volume from the free queue, and writes the data read in step 1012 to this segment address (1016, FIG. 6). S5A), and the segment address “63” is registered in the block address “3” of the virtual volume V4 (F-VOL use).
  • the data registered in the segment address “63” of the F volume is data updated for the P volume 141 between the virtual volume V3 and the virtual volume V4.
  • the snapshot reconstruction processing subprogram 304 refers to the block address “12” of the virtual volume V4 (FIG. 14B). ).
  • the snapshot reconstruction processing subprogram 304 reads data from the same block address of the P volume and writes it to the free segment “64” of the F volume. Then, the segment address “64” is registered in the block address “12” of the virtual volume V4 (F-VOL use) (FIG. 14C).
  • the snapshot reconstruction processing subprogram 304 uses the virtual volume V4. The same value as that registered in the same block of the R volume that is the snapshot volume before (using F-VOL) is registered.
  • the virtual volume V4 (for F-VOL) other than “3” and “12” is assigned to the block address. “None” is registered.
  • the snapshot reconstruction processing subprogram 304 finishes the above-described processing for all the bits of the migration target bitmap V4, it refers to the value of each block of the virtual volume V4 (F-VOL use), and the F volume “0” is registered in the same block address of the bit string b-2 of the Cow bitmap for the block address in which the segment address is registered, and the block address in which the segment address of the F volume is not registered is stored in the bit string b-2. “1” is registered in the same block address.
  • the format of the F volume management table so far is as shown in FIG. 14C.
  • bitmap in FIG. 12 is an F volume reference bitmap
  • bitmap in FIG. 11 is a D volume reference bitmap
  • the snapshot reconfiguration processing subprogram 304 makes an affirmative decision in step 1022, and because the migration processing for the virtual volume V5 has not ended, in step 1024, there is another virtual volume V5, so affirming step 1024
  • the process returns to Step 1006, and Steps 1012 to 1022 are executed in the same manner as the migration processing for the virtual volume V4 while comparing with the virtual volume V4 (using F-VOL) based on the migration bitmap V5. .
  • the F volume management table obtained as a result is as shown in FIG. 14D.
  • the snapshot reconstruction processing subprogram 304 makes an affirmative decision in step 1022, and then decides that the migration process has been completed for all virtual volumes, that is, makes a negative decision in step S1024 and moves to step 1026. To do.
  • the snapshot reconstruction processing subprogram 304 deletes the entries of the virtual volumes V3 to V5 from the D volume management table (FIG. 11). As a result, the table is as shown in FIG. Further, the used segment address of the D volume included in the deleted entry is released unless it is registered in the block address of another virtual volume registered in the D volume management table.
  • This release is achieved by connecting the used segment address to the free queue. Therefore, even if the capacity of the D volume is limited, the pre-update data used for the snapshot volume V6 can be protected and stored without omission.
  • the snapshot reconstruction processing subprogram 304 ends the flowchart according to FIG.
  • FIG. 15 shows a flowchart when a write is applied from the host computer 131 to the P volume 141 (WR1 in FIG. 7).
  • the copy-on-write processing subprogram 302 acquires the free segment of the D-VOL (1500), reads the pre-update data existing in the specific block address of the P-VOL where there was a write, and reads this data in the D-VOL Store in the free segment (1502, WR2 in FIG. 7).
  • the copy-on-write processing subprogram 302 registers the free segment address of the D-VOL volume in the virtual volume V6 specific block address of the D volume management table (FIG. 13), and sets the D volume bit string for the virtual volume V6. A corresponding bit is set to “0” (1504). Thus, the flowchart of FIG. 15 ends.
  • FIG. 16 shows a flowchart when there is a read request from the host computer 131 to the snapshot volume.
  • FIG. 8 is a snapshot volume management table in which attributes of a plurality of snapshot volumes are recorded.
  • RRR is an attribute flag indicating that it is an R volume (real volume)
  • FFF is an attribute indicating that a difference as updated data is managed by the F volume
  • DDD is an attribute indicating that the difference as data before update is managed by the D volume.
  • the snapshot creation processing subprogram 301 creates a snapshot volume, this is registered in the management table together with the attributes. Further, the snapshot reconstruction processing subprogram 304 operates the snapshot volume using the D volume. Each time the mode is changed to the operation mode using the F volume, the attribute of the volume is updated.
  • the snapshot composition processing subprogram 301 refers to this management table and checks the attribute of the snapshot volume that is the target of reading from the host computer. If the attribute is “RRR” or “FFF”, the F volume Is used to generate a snapshot and provide it to the host computer (1604). In the case of “DDD”, a snapshot is generated using the D volume (1602).
  • the snapshot composition processing subprogram 301 uses the F volume to generate a snapshot
  • the F volume bit string corresponding to the virtual volume to be read in the F volume management table (FIG. 12) is referred to.
  • the data is read from the corresponding block of the R volume and provided to the host computer 131 (1606).
  • the virtual volume that is the read target is determined from the management table (FIG. 12), and the segment address of the F volume is acquired for the block that is the read target of this virtual volume. Then, the snapshot composition processing subprogram 301 accesses the F volume and provides the updated data registered in this segment address to the host computer (1606).
  • the snapshot composition processing program 301 refers to the F volume management table (FIG. 12). (1604), since the values of all bits of the bit string assigned to the R-VOL are NULL, data is directly read from the corresponding block address of the R volume and provided to the host computer (S1606).
  • the storage apparatus has been described as NAS.
  • the storage apparatus may be configured separately from the file server.
  • the present invention suppresses an increase in the amount of pre-update data held in a differential volume even when a snapshot is operated as a backup unit for a long period of time.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【解決課題】スナップショットを、バックアップ手段として長期にわたって運用しても、差分ボリュームにおける更新前データの保持量が増大しないようにするストレージ装置、及びそのスナップショット制御方法を提供する。 【解決手段】本発明は、更新前データを利用したスナップショットを、更新後データを利用するスナップショットに置き換えることによって、その分、差分ボリュームの更新前データを格納している領域を空き領域として解放し、それにより差分ボリュームに更新前データが累積するのを避けようとするものである。

Description

ストレージ装置及びそのスナップショット制御方法
　本発明は、ストレージ装置に係わり、特に、運用中のボリュームをある特定日時において静止化し、静止化したデータイメージをユーザ計算機にスナップショットとして提供する機能を備えたストレージ装置に関するものである。さらに本発明は、ストレージ装置のスナップショット制御方法に関するものである。
　情報化社会における情報を蓄積するストレージシステムの重要な役割の一つに、ユーザデータを保護するということがある。ユーザデータ保護のための機能の一つとしてスナップショット機能が知られている。
　スナップショット機能とは、運用中のボリュームをある特定日時において静止化し、静止化したデータイメージをホスト計算機などのユーザ計算機に提供する機能をいう。ボリュームの静止化されたデータイメージをスナップショットという。ストレージ装置は、スナップショットの複数の世代をユーザに提供することができる。
　スナップショット機能は、ユーザが意図することなくファイルを削除してしまった場合など、オペレーティングミスからデータをサルベージするためのものである。
　ユーザは、直前の世代など所望の世代のスナップショットに戻ることによって、スナップショットを作成した時点でのデータを回復することができる。すなわち、スナップショット機能は、ボリュームの特定日時でのデータイメージをユーザに保障するためのものである。
　このスナップショット機能を開示する従来技術として、例えば、特開２００４－３４２０５０号公報に記載されたものがある。この公報によれば、ストレージ装置としてのファイルサーバは、スナップショットを仮想ボリュームとしてクライアント計算機に提供する。
　ファイルサーバは、クライアント計算機が継続的にアクセスしている運用ボリュームとしてのプライマリボリュームと、プライマリボリュームが更新される前のデータ（更新前データ）を格納する差分ボリュームとに基づいて、スナップショットをユーザに提供する。
　ファイルサーバがスナップショットを取得後、プライマリボリュームにクライアント計算機からライトアクセスがあると、ファイルサーバは、更新前データをプライマリボリュームからリードして、これを差分ボリュームにライトした後、プライマリボリュームに更新データを記録する。プライマリボリュームのどのブロックに更新があったか否かは、ビットマップによって管理される。
　クライアント計算機がスナップショット用の仮想ボリュームにアクセスすると、ファイルサーバは、ビットマップを参照して、フラグが立っているブロックアドレスへのアクセスの場合には、プライマリボリュームの対応領域は更新されているので、差分ボリュームから更新前データをリードし、フラグがセットされていないブロックアドレスへのアクセスの場合には、プライマリボリュームの対応領域は更新されていないので、プライマリボリュームからデータをリードし、リードデータをクライアント計算機に提供することとした。
　なお、本発明に関連する他の従来技術として、特開２００５－２８４６０９号公報と特開２００７－２２６５９６号公報が存在する。
特開２００４－３４２０５０号公報 特開２００５－２８４６０９号公報 特開２００７－２２６５９６号公報
　管理者の手間をかけずに、ユーザが自身で過去ファイルをサルベージできるスナップショット技術は、プライマリボリュームへのＩ／Ｏを止めることなく、仮想ボリュームをユーザに提供するだけで実現でき、そして、スナップショットを運用するための設定項目も従来のバックアップに比べて簡易的であり、しかも、肥大化する非構造化ファイルの過去データをオンラインで利用できるという利点を有することから、ユーザはスナップショット技術をバックアップの目的で頻繁に運用するようになってきている。
　しかしながら、ユーザが、スナップショットの複数の世代を年単位のような長期に渡って作成し、これを運用し続けると、差分ボリュームにおける更新前データの保持量が爆発的に増大するという課題があった。
　そこで、差分ボリュームに、ビットコストが小さく低速なストレージデバイスを大量に割り当ててこの課題を乗り越えることが考えられるが、これでは、プライマリボリュームに対するＩ／Ｏ性能に対する負の影響が大きいという課題がある。
　すなわち、プライマリボリュームにライトアクセスがあると、ファイルサーバはプライマリボリュームから更新前データをリードし、これを差分ボリュームにライトした後、プライマリボリュームに更新データをライトする。
　差分ボリュームに低速なストレージデバイスが使用されると、差分ボリュームに対する更新前データのライト処理速度が大幅に低下し、その結果、プライマリボリュームに対するＩ／Ｏ処理性能が大きく損なわれることになる。
したがって、ファイルストレージシステムのベンダーは、ビットコストが高いストレージによって差分ボリュームを構築せざるを得ず、しかも、結果的に、差分ボリュームの容量に限界が出ることになる。そのため、そもそも、スナップショット機能をバックアップとして利用しようとする運用は、早晩、行き詰まることが避けられないという課題がある。
　そこで、本発明は、スナップショットを、バックアップ手段として長期にわたって運用しても、差分ボリュームにおける更新前データの保持量が増大しないようにするストレージ装置及びそのスナップショット制御方法を提供することを目的とするものである。
　さらに、本発明の他の目的は、低ビットコスト・低速なストレージデバイスを、スナップショット用の差分ボリュームとして利用しても、運用ボリュームに対するＩ／Ｏ性能を維持できるストレージ装置及びそのスナップショット制御方法を提供することにある。
　本発明は、この目的を達成するために、更新前データを利用したスナップショットを、更新後データを利用するスナップショットに置き換えることによって、その分、差分ボリュームの更新前データを格納している領域を空き領域として解放し、それにより差分ボリュームに更新前データが累積するのを避けようとするものである。
　本発明は、さらに、クライアント計算機が運用ボリュームへＩ／Ｏを行っても、差分ボリュームへの更新後データの書き込みは発生しないため、更新後データ格納型差分ボリュームを高性能なストレージデバイスから構成しなくても、ストレージ装置のＩ／Ｏ処理性能に悪影響を与えることなく、ユーザにスナップショット機能を提供することができる。
　本発明によれば、スナップショットを、バックアップ手段として長期にわたって運用するようにしたとしても、差分ボリュームにおける更新前データの保持量が増大しないようにするストレージ装置を提供できる。
　また、低ビットコスト・低速なストレージデバイスを、スナップショット用のボリュームとして利用しても、運用ボリュームに対するＩ／Ｏ性能を維持できるストレージ装置を提供することができる。
本発明に係わるストレージシステムの第１の実施形態に関するハードウエアブロック図である。 メモリ１１４の機能ブロック図である。 スナップショット管理プログラムの詳細なブロック図である。 ストレージ装置のスナップショット機能の動作を説明するブロック図である。 更新前データ利用型スナップショットを管理するための管理テーブルである。 更新前データ利用型スナップショットの管理テーブルに仮想ボリュームを登録する過程における当初の状態を示す。 図６Ａに続く状態を示す上記管理テーブルを示す。 図６Ｂに続く状態を示す上記管理テーブルを示す。 図６Ｃに続く状態を示す上記管理テーブルを示す。 図６Ｄに続く状態を示す上記管理テーブルを示す。 複数の仮想ボリュームの登録が達成された上記管理テーブルである。 スナップショットの運営システムの一例を示すブロック図である。 仮想ボリュームの種類を示す管理フラグを説明するブロック図である。 更新前データ保存型差分ボリュームを用いたスナップショットの運用を、更新データ保存型差分ボリュームを用いたものに移行する処理の開　始を決定するためのフローチャートである。 図９の説明で言及した移行処理の詳細を示すフローチャ―トである。 図７の運営システムに属する複数の仮想ボリュームが登録された管理テーブルであって、この管理テーブルは、更新前データ保存型差分ボリュームを用いたスナップショットを管理する。 図７の運営システムに属する複数の仮想ボリュームが登録された管理テーブルであって、この管理テーブルは、更新後データ保存型差分ボリュームを用いたスナップショットを管理する。 スナップショットの運用を、更新前データを利用するものから更新データを利用するものに移行した後における、更新前データ利用スナップショット管理テーブルである。 更新済みデータを利用するスナップショット管理テーブルにレプリケーションボリュームを登録した状態を示す。 更新前データを利用するスナップショット管理テーブルを更新済みデータに移行するための移行対象ビットマップを示すものである。 移行対象ビットマップによって、更新前データを利用するスナップショット管理テーブルから、仮想ボリュームを、更新済みデータを利用するスナップショット管理テーブルに移行した状態を示したものである。 図１４Ｃの仮想テーブルにさらに他の仮想ボリュームを移行した状態を示す。 スナップショットの管理を、更新済みデータを利用する運用に移行した後での、ストレージ装置がクライアント計算機からのライトコマンドを処理するためのフローチャートである。 スナップショットの管理を、更新済みデータを利用する運用に移行した後での、スナップショットボリュームに対するリード処理をストレージ装置が処理することを説明するフローチャ―トである。
　図１は、本発明に係るストレージ装置を用いたストレージシステムの第１の実施形態を示すハードウエアブロック図である。このストレージシステムは、ネットワーク１５１によって相互に通信可能に接続されたクライアント計算機１３１、管理クライアント１３２、メディアサーバ１３３が、ネットワークアタッチドストレージ装置（ＮＡＳ）１００に接続されるという構成を備えている。ネットワーク１５１は、例えば、ＴＣＰ／ＩＰ等のプロトコルで通信を行い、ネットワーク１５１に接続された装置間で制御信号やデータを転送する。
　クライアント計算機１３１は、ユーザが操作するコンピュータ装置であり、ＮＡＳ１００にアクセスし、データの読み出し及び書き込みを行う。このクライアント計算機１３１は、ネットワーク１５１に複数接続されていてもよい。このクライアント計算機の一例としてホスト計算機、業務サーバ、ＰＣクライアントがある。
　管理クライアント１３２は、管理者（管理ユーザ）が操作するコンピュータ装置であり、ＮＡＳ１００の管理に使用される。この管理クライアント１３２は、少なくとも、ＣＰＵ、メモリ、及びインターフェースを備える。
　メディアサーバ１３３は、ＮＡＳ１００に記録されたデータをテープ等の記録媒体にバックアップするための装置であり、例えば、磁気テープ装置であっても、大容量の磁気ディスク装置であってもよい。
　ＮＡＳ１００は、クライアント計算機１３１にファイル共有サービスを提供する。このＮＡＳ１００は、コントローラ１０１及びディスク装置１１５によって構成されている。
　ディスク装置１１５は、複数のディスクドライブ２００、２０２を備えている。ディスク装置１１５には、クライアント１３１から書き込みを要求されたファイルがブロック単位に分割されて記録されている。
　ディスクドライブ２００は、データの高速リード/ライトを実現できる高性能なものであって、例えば、ファイバチャネル対応のものである。これに対して、ディスクドライブ２０２は、ＳＡＴＡなど低性能で低ビットコストのディスクドライブである。
　複数の高性能ディスクドライブ２００によって、第１のＲＡＩＤグループが構成され、これにクライアント計算機１３１がアクセスする運用ボリュームとしてのプライマリボリューム（以後、ほぼ、これを、Ｐボリューム、又は、Ｐ－ＶＯＬ、と略称する。）１４１と、Ｐボリュームに対する更新があった際、更新前データを格納する、更新前データ格納差分ボリューム（以後、これを、Ｄボリューム、又は、Ｄ－ＶＯＬと略称することがある。）１４２が設定されている。
　そして、複数の低性能ディスクドライブ２０２によって、第２のＲＡＩＤグループが構成され、これに、Ｐボリュームへの更新データを格納する、更新後データ格納差分ボリューム（以後、これをＦボリューム、又は、Ｆ－ＶＯＬ、と略称することがある。）１４３と、レプリケーションボリューム（以後、これを、Ｒボリューム、又は、Ｒ－ＶＯＬ、と略称することがある。）１４２Ａと、が設定されている。なお、Ｒ－ボリューム１４２Ａをディスクドライブ２００によって構成されるＲＡＩＤグループに設定してもよい。
　Ｐボリューム１４１は、クライアント計算機１３１からのＩ／Ｏを受け入れる運用中のボリュームであり、クライアント計算機１３１からの書き込み要求を受けて、ブロック単位でデータが書き込まれる。また、クライアント計算機１３１からの通常の読み出し要求を受けて、ブロック単位にデータが読み出される。
　コントローラ１０１は、ＣＰＵ１１１、ネットワークインターフェース（Ｉ／Ｆ）１１２、ストレージインターフェース（Ｉ／Ｆ）１１３、及び、メモリ１１４によって構成される。ＣＰＵ１１１は、メモリ１１４に格納された各種のプログラムを実行し、ファイル供給サービス、及びスナップショット機能をユーザに提供する。
　図２は、メモリ１１４の機能ブロック図である。メモリ１１４には、ＮＡＳＯＳの管理下で稼動するファイルサーバプログラム１２１と、ファイルシステム処理プログラム１２３と、スナップショット管理プログラム１２４と、バックアップ処理プログラム１２５と、スナップショット管理テーブル１４４とを備えている。
　さらに、メモリ１１４は、ボリュームマネージャプログラムによって、仮想ボリューム（Ｖ‐ＶＯＬ）１４３Ａを生成し、これをユーザに対してスナップショットボリュームとして見せている。
　仮想ボリューム１４３Ａは、クライアント計算機１３１、又は、管理クライアント１３２から、コントローラ１０１がスナップショットの作成要求を受けたときに、その時点のプライマリボリューム１４１のデータイメージを静止化して、これをユーザに提供するために、ユーザのアクセス用として生成されるものである。
　ＮＡＳ１００がユーザに提供するスナップショットには２種類あり、第１が、Ｐボリューム１４１の運用データとＤボリューム１４２の更新前データとを利用して生成されるスナップショット、第２が、特定時点のＰボリュームのＲボリューム１４２ＡのデータとＦボリューム１４３の更新後データとによって生成されるスナップショトである。
　以後、便宜上、前者を、更新前データ利用型スナップショットと、後者を、更新データ利用型スナップショットという。レプリケーションボリュームが、請求項に記載してある、運用ボリュームの基準時のデータイメージに相当する。
　Ｄボリューム１４２には、スナップショットのコピーオンライト（copy on write）時にプライマリボリューム１４１に記録されていたブロックが複写される。
　クライアント計算機１３１又は管理クライアント１３２から、コントローラ１０１がスナップショットの作成要求を受けると、その時点以後、プライマリボリューム１４１のブロックが上書きされるとき、上書きされる前のデータ（更新前データ）がＤボリューム１４２に複写される。
　コントローラ１０１は、プライマリボリューム１４１に記録されたブロックとＤボリューム１４２に記録されたブロックとを組み合わせることによって、スナップショットの作成要求を受けた時点のプライマリボリューム１４１のデータイメージをスナップショットとして復元することができる。
　スナップショット管理テーブル１４４には、更新前データ利用型スナップショット用のもの（Ｄ－ＶＯＬ用の管理・制御テーブルであって、後述の図５がこれに相当する。）と、更新データ利用型スナップショット用のもの（Ｆ－ＶＯＬ用の管理・制御テーブルであって、後述の図１２がこれに相当する。）と、がある。
　両者を区別する場合には、前者を「Ｄボリューム管理用テーブル」と称し、後者を「Ｆボリューム管理テーブル」と称する。また、「スナップショット管理テーブル」と称する場合には、両者を包含する。
　スナップショット管理テーブル１４４は、ユーザにスナップショットを利用させるようにするために、一つ又は複数のスナップショットを管理するものであり、作成されたスナップショットごとに、Ｐボリューム１４１のブロックアドレス又はＲボリューム１４２Ａのブロックアドレスと、差分ボリューム（Ｄボリューム１４２、又は、Ｆボリューム１４３）のブロックアドレスとの対応関係が記録されたものである。以後、「スナップショット管理テーブル１４４」を、単に「管理テーブル１４４」ということもある。
　ファイルサーバプログラム１２１は、クライアント計算機１３１からのデータアクセス要求に応じて、ファイルシステム処理プログラム１２３に対して、ファイルやディレクトリの読み出し処理、又は書き込み処理の実行を要求し、その実行結果を要求元のクライアント計算機１３１に返送する。
　また、ファイルサーバプログラム１２１は、ユーザ認証を行い、ユーザに対してアクセス権限を付与することによって、複数のユーザが存在する場合のファイル共有を管理する。
　ファイルシステム処理プログラム１２３は、少なくとも、ファイル読み出し要求処理サブプログラム２０１、及び、ファイル書き込み要求処理サブプログラム２０２Ａを含む。
　ファイルシステム処理プログラム１２３は、ファイルサーバプログラム１２１やスナップショット管理プログラム１２４が発行するファイルやディレクトリの読み出し要求、及び、書き込み要求に応じて、ファイルやディレクトリを格納しているボリューム、アクセスするブロックの位置及びサイズを指定し、データの読み出し処理や書き込み処理をスナップショット管理プログラム１２４に発行する。
　ファイルシステム処理プログラム１２３は、仮想ボリューム１４３Ａにアクセスすることにより、スナップショットが生成された時点の情報を利用できるため、ファイルシステムのスナップショットイメージをクライアント計算機１３１や管理クライアント１３２などのユーザ計算機に提供することが可能になる。
　スナップショット管理プログラム１２４は、図３に示す様に、少なくとも、スナップショット作成処理サブプログラム３０１、コピーオンライト処理サブプログラム３０２、スナップショット合成処理サブプログラム３０３、そして、スナップショト再構成処理サブプログラム３０４を備えている。
　スナップショット作成処理サブプログラム３０１は、Ｐボリューム１４１に対するスナップショットを生成する。さらに、ユーザがスナップショットにアクセスできるように、仮想ボリューム１４３Ａを生成する。
　スナップショット作成処理サブプログラム３０１は、クライアント計算機１３１からのスナップショット取得要求に対して、スナップショット管理テーブル１４４に、すなわち、Ｄ－ＶＯＬ用の管理テーブ（図５）、及び、Ｆ－ＶＯＬ用の管理テーブル（図１２）のそれぞれに、スナップショットの仮想ボリュームの領域を設定する。
　クライアント計算機１３１は、仮想ボリューム１４３Ａを介して、特定日時でのＰボリュームの静止化されたデータイメージであるスナップショットにアクセスすることができる。
　仮想ボリューム１４３Ａそれ自体は、記憶領域の割り当てがない仮想的なものであり、Ｐボリューム１４１、Ｄボリューム１４２、Ｆボリューム１４３、そして、Ｒボリューム１４２Ａに、スナップショットに関するデータを記憶する実体がある。
　レプリケーションボリューム（Ｒ－ＶＯＬ）１４２Ａは、Ｐボリューム１４１をある日時において静止化したものの複製ボリュームである。
　コピーオンライト処理サブプログラム３０２は、スナップショット管理テーブル１４４を用いて、スナップショットの維持に必要な更新前差分データを格納するＤボリューム１４２と、更新後差分データを格納するＦボリューム１４３とを管理し、ファイルシステム処理プログラム１２３の要求に応じたデータ書き込み処理がＰボリュームに対してあっても、スナップショットを維持する処理を行う。
　具体的には、Ｐボリューム１４１にデータを書き込む際に、Ｐボリューム１４１に記憶されていた更新前データをＤボリューム１４２にコピーした後、Ｐボリューム１４１の記憶内容を更新する。
　また、コピーオンライト処理サブプログラム３０２は、スナップショットの生成時以降に、Ｐボリューム１４１に格納されていたデータにユーザがアクセス可能となるよう、Ｐボリューム１４１又はＲ－ボリューム１４２Ａ、及び、差分ボリューム（Ｄボリューム１４２、Ｆボリューム１４３）に記憶されたデータを管理し、生成されたＰボリューム１４１のスナップショットを提供するための仮想ボリューム１４３Ａにユーザ装置（１３１、１３２）をアクセス可能にする。
　さらに、コピーオンライト処理サブプログラム３０２は、特開２００４－３４２５０号公報で示されているように、ホスト計算機からのリードが仮想ボリュームに対してあった時、リード対象のデータがＰボリューム１４１にあるか、Ｄボリューム１４２にあるかを判別するビットマップを形成して、これをＤボリューム用管理テーブル１４４（図５）に記憶する。
　一方、ＮＡＳ１００が、スナップショットを、更新後データを利用してクライアント計算機に対して生成する場合、スナップショット合成処理サブプログラム３０３は、ホスト計算機からのリードが仮想ボリュームに対してあった時、リード対象のデータがＲボリューム１４２Ａにあるか、Ｆボリューム１４３にあるかを判別するビットマップを形成して、これをＦボリューム用管理テーブル１４４（図１２）に記憶する。
　スナップショット合成処理サブプログラム３０３は、ファイルシステム処理プログラム１２３やバックアップ処理プログラム１２５の要求に応じて、仮想ボリューム１４３Ａの読み出し処理（すなわち、スナップショットを利用ための処理）を行う。
　具体的には、スナップショット合成処理サブプログラム３０３は、Ｄボリューム用管理テーブル１４４（図５）のビットマップ領域を参照して、Ｐボリューム１４１、又は、Ｄボリューム１４２のどちらからデータを読み出すかを決定し、決定されたボリュームのアドレスから、スナップショットの作成要求時にＰボリューム１４１に存在するデータをファイルシステム処理プログラム１２３に供給する。
　また、同様に、スナップショット合成処理サブプログラム３０３は、Ｆボリューム用管理テーブル１４４（図１２）のビットマップ領域を参照して、Ｒボリューム１４２Ａ、又は、Ｆボリューム１４３のどちらからデータを読み出すかを決定し、決定されたボリュームのアドレスから、スナップショットの作成要求時にＰボリューム１４１に存在するデータをファイルシステム処理プログラム１２３に供給する。
　仮想ボリューム１４３Ａは、ユーザ計算機（１３１、１３２，１３３）のそれぞれに、特定日時のスナップショットとして見えているものである。
　スナップショット再構成処理サブプログラム３０４は、更新前データ利用型スナップショットを更新データ利用型スナップショットに置き換える処理を行う。この過程で、更新前データ利用型スナップショットのエントリをＤボリューム用管理テーブル(図５)から削除する処理も行う。そして、Ｄボリューム１４２の更新前データを格納している領域を空き領域として解放することによって、Ｄボリューム１４２の容量の圧迫を防ぐものである。
　スナップショット再構成処理サブプログラム３０４は、このようなスナップショットのタイプの置き換えをユーザ計算機に意識させないように実行することができる。
　スナップショット合成処理サブプログラム３０３は、Ｄボリューム１４２用の管理テーブル（図５）とＦボリューム１４３用の管理テーブル（図１２）を参照して、スナップショットを作成する。
　バックアップ処理プログラム１２５は、管理クライアント１３２から、特定のスナップショットを指定したバックアップ要求を受けると、ディスク装置１１５に記録されているデータのうち、当該スナップショットに対応するデータをメディアサーバ１３３に転送して、特定日時のスナップショットに対するバックアップ処理を実行する。
　次に、図１のストレージ装置１００の更新前データ利用型スナップショット機能の動作を図４に基づいて説明する。図４は、３月３１日２３：００にスナップショットＶ３（仮想ボリュームＶ３）が作成され、４月２日及び４月２０日にそれぞれＰボリュームに更新が入り、４月３０日２３：００にスナップショットＶ４（仮想ボリュームＶ４）が作成され、５月５日と５月１０日にＰボリューム１４１に更新が入った一連の流れを説明している。
　図４を詳しく説明する前に、図５について説明する。図５は、特開２００４-３４２０５０号において説明されているように、更新前データ利用型スナップショットを管理するためのスナップショット管理テーブル（Ｄボリューム用管理テーブル）である。
　スナップショット管理テーブルの列５１１は、Ｐボリューム１４１のブロックアドレスに対応しており、最初の行である１番目の行（第１行）５０１にはＰボリュームのブロックアドレス０番が割り当てられ、第２行５０２にはＰボリュームのブロックアドレス１番が割り当てられ、第３行５０３にはＰボリュームのブロックアドレス２番が割り当てられ、以下順番に，Ｐボリュームのブロックアドレスが割り当てられ、最後の行５０４にはＰボリュームのブロックアドレス（ｍ－１）番が割り当てられている。
　スナップショット管理テーブルには、複数の仮想ボリューム１４３Ａ（５１３，５１４，５１５）が登録されている。各仮想ボリュームのそれぞれが、異なる日時で作られたスナップショットに対応している。Ｐボリューム１４１の各ブロック５１１は仮想ボリュームの各ブロックに対応している。仮想ボリュームの各行（５０１～５０４）に記載された数値はＤボリューム１４２のセグメントアドレスである。
　第１のスナップショットに対応する仮想ボリューム１（５１３）の第１行には、Ｄボリュームのセグメントアドレス「０」番が割り当てられ、第２行にはＤボリュームのセグメントアドレスの「１」番が登録され、第３行と第ｍ－１行にはＤボリュームのセグメントアドレスの割り当てがないので「なし」が設定されている。
　Ｐボリューム１４１のブロックアドレスの０番のデータが更新されると、コピーオンライト処理プログラム３０２は、Ｐボリュームのブロックアドレス０番の更新前のデータをＤボリューム１４１の未使用のセグメントアドレスに書き込み、このセグメントアドレスを仮想ボリューム１のブロックアドレス０番に書き込む。図５は、Ｄボリューム１４２のセグメントアドレスとして「０」が登録されたことを例示している。
　続けて、仮想ボリューム１の第２行に割り当てられたセグメントアドレス「１」番は、Ｄボリューム１４２のものであり、Ｐボリュームのブロックアドレス１番のデータが更新されるとき、更新前のデータはＤボリュームのセグメントアドレス「１」番に書き込まれる。
　さらに、続けて、仮想ボリューム１の第３行のＰボリュームのブロックアドレス２番と、第ｍ行のＰボリュームのブロックアドレス（ｍ－１）番には、「なし」が登録されている。「なし」は、Ｐボリュームのブロックアドレス２番、（ｍ－１）番に、クライアント計算機からライト（更新）が行われていないことを示している。
　仮想ボリューム２（５１４），・・・・ｎ（５１５）は、それぞれ特定の時点でのスナップショットに対応することは説明したとおりである。図４に即して説明すると、仮想ボリューム２（５１４）は３月３１日のスナップショットに対応する仮想ボリュームＶ３であり、仮想ボリューム１は４月３０日のスナップショットに対応する仮想ボリュームＶ４である。仮想ボリュームｎ（５１５）は２月末以前のスナップショットに相当する。
　列５１２は、ＣｏＷビットマップを示すものであり、これは複数のビット列から構成されている。図５Ａのｂ－１，ｂ－２，・・・，ｂ－ｎがそれぞれビット列である。各ビット列は、各仮想ボリュームに対応している。
　ビット列ｂ－１は仮想ボリューム１に対応し、ビット列ｂ－２は仮想ボリューム２に対応し、ビット列ｂ－ｎは仮想ボリュームｎに対応している。そして、各ビット列の各ビットは、各ブロックアドレスに対応している。
　ビット列の「０」は、Ｐボリューム１４１の対応するブロックに更新があったことを示し、「１」はＰボリューム１４１の対応するブロックに更新がなかったことを示す。
　次に、スナップショット作成処理サブプログラム３０１が、スナップショットを作成した際、図５の管理テーブルへ情報を登録する動作について説明する。
　クライアント計算機からある日時でのスナップショットを作成するリクエストをＮＡＳ１００が受け取ると、スナップショット作成処理サブプログラム３０１は、新たに、仮想ボリュームのエントリと、この仮想ボリュームに対応するビット列のエントリと、を管理テーブル（図５）に登録する。この時点で、新たな仮想ボリュームのエントリの各ブロックには「なし」が設定され、かつ、ビット列の各ブロックには、「１」が設定される。
　次に、この仮想ボリュームの登録後、Ｐボリューム１４１に対して、ホスト計算機からライトがあった場合の、ＮＡＳ１００の動作について説明する。なお、この仮想ボリューム、すなわち、今回作成されたスナップショットを、以前に作成されたスナップショットに対応する仮想ボリュームと区別するために、前者の仮想ボリュームを「仮想ボリューム（新）」と呼び、後者の仮想ボリュームを「仮想ボリューム（旧）」と呼ぶ。
　コピーオンライト処理サブプログラム３０２は、ホスト計算機からＰボリューム１４１に対するライトを受信すると、ブロックアドレスを検出し、このブロックアドレスの更新前データを読み出して、これをＤボリューム１４２の空きセグメントに格納する。
　次いで、コピーオンライト処理サブプログラム３０２は、更新前データが格納された、Ｄボリュームのセグメントの番号を仮想ボリューム（新）の対応するブロックに登録する。
　さらに、コピーオンライト処理サブプログラム３０２は、仮想ボリューム（旧）の対応するブロックをチェックし、ここに「なし」が登録されていることを判定した場合には、仮想ボリューム（新）の対応ブロックに登録した番号を登録する。一方、「なし」ではなく、ブロックの番号が登録されている判定した場合には、これを維持する。
　さらに、コピーオンライト処理サブプログラム３０２はＤボリューム１４２のセグメント番号を仮想ボリューム（新）のブロックに登録すると、仮想ボリューム（新）に対応するビット列の対応するブロックのビット「１」を「０」にセットする。
　次に、クライアント計算機がスナップショットにリードアクセスする際の動作を説明する。スナップショット合成処理サブプログラム３０３は、リードアクセスからリード対象となった仮想ボリュームのＩＤを判定し、この仮想ボリュームに対応するビット列（図５Ａのｂ－１等）を参照する。
　次いで、スナップショット合成処理サブプログラム３０３は、仮想ボリュームのリード対象となっているブロックに対応するビットを参照し、ビット「０」を判定すると、仮想ボリュームの対応ブロックに登録されているセグメント番号を取得する。
　次いで、このセグメント番号に基づいてＤボリューム１４２にアクセスして、スナップショット作成時における、Ｐボリューム１４１の更新前データを取得して、クライアント計算機に送信する。
　一方、スナップショット合成処理サブプログラム３０３は、仮想ボリュームのリード対象となっているブロックに対応するビットを参照し、ビット「１」を判定すると、運用ボリューム１４１の対応ブロックにアクセスして、スナップショット作成時における、Ｐボリューム１４１のデータを取得して、クライアント計算機に送信する。
　ブロックアドレスの代わりにブロックＩＤを利用してもよい。スナップショット管理テーブル１４４（図５）は、Ｐボリューム毎に作成・管理される。なお、代表的な実施形態では、ブロックサイズは５１２バイト、運用ボリュームのサイズは１２８ギガバイトとすると、運用ボリュームのブロック数は２５００００００となる。スナップショットの最大数は６４を想定している。
　次に、図４にしたがって、更新前データ差分ボリューム（Ｄボリューム１４２）を利用した、スナップショットの管理のための動作を具体的に説明する。
　図４において、Ｖ３は、３月３１日２３：００のスナップショットをユーザに提供するための仮想ボリュームであり、Ｖ４は、４月３０日２３：００のスナップショットをユーザに提供するための仮想ボリュームである。
　３月３１日２３：００時点でのスナップショットの管理テーブルの例を、図６Ａに示す。図４のＢ３はビット列ｂ－１をマップイメージにしたものである。ｂ１～ｂ１６は、ビット列ｂ－１の「ブロックアドレス」の０～１５のそれぞれに対応する。
　３月３１日２３：００のスナップショットの作成後、Ｐボリューム１４１のブロック「３」にライトアクセス（ａ→Ａ）が４月２日１４：００に入ると、コピーオンライト処理サブプログラム３０２は、更新前データ（ａ）をＰボリュームの対応ブロック「３」からリードし、リードデータ（ａ）をＤボリューム１４２の空きセグメント「２０」に格納する。Ｄボリュームの空きセグメントは、これを管理するフリーキューから取得する。また、Ｄボリュームの使用されたブロックはフリーキューから解放される。
　この時点での管理テーブルは、図６Ｂに示すものになる。すなわち、コピーオンライト処理サブプログラム３０２は、仮想ボリュームＶ３のブロック「２」にＤボリューム１４２のセグメントアドレス「２０」を登録し、そして、ビット列ｂ－１のブロック「２」に「０」をセットする。
　さらに、Ｐボリューム１４１のブロック「１２」にライトアクセス（ｂ→Ｂ）が４月２０日１４：００に入ると、コピーオンライト処理サブプログラム３０２は、更新前データ（ｂ）をＰボリュームの対応ブロック「１２」からリードし、リードデータ（ｂ）をＤボリューム１４２の空きセグメント「２１」に格納する。
　この時点での管理テーブルは、図６Ｃに示すものになる。すなわち、コピーオンライト処理サブプログラム３０２は、仮想ボリュームＶ３のブロック「１２」にＤボリューム１４２のセグメントアドレス「２１」を登録し、そして、ビット列ｂ－１のブロック「１２」に「０」をセットする。
　図４は、さらに、４．３０（２３：００）にスナップショットを作成することを示している。Ｖ４は、このスナップショットに対応する仮想ボリュームである。この時点での管理テーブルは図６Ｄに示すものとなる。図６Ｄにおいて、ｂ－２は仮想ボリュームＶ４に対応するビット列である。図４のＢ４は、ビット列ｂ－２のマップイメージである。
　次いで、４月３０日２３：００のスナップショット（仮想ボリュームＶ４）の作成後、Ｐボリューム１４１のブロック「１」にライトアクセス（ｃ→Ｃ）が５月５日１４：００に入ると、コピーオンライト処理サブプログラム３０２は、更新前データ（ｃ）をＰボリュームの対応ブロック「１」からリードし、リードデータ（ｃ）をＤボリューム１４２のフリーセグメント「２２」に格納する。
　この時点での管理テーブルは、図６Ｅに示すものになる。すなわち、コピーオンライト処理サブプログラム３０２は、仮想ボリュームＶ４のブロック「１」にＤボリューム１４２のセグメントアドレス「２２」を登録し、そして、ビット列ｂ－２のブロック「１」に「０」をセットする。
　コピーオンライト処理サブプログラム３０２は、３．３１（２３：００）のスナップショットをユーザに保障するために、仮想ボリュームＶ３のブロック「１」にもＤボリューム１４２のセグメントアドレス「２２」を登録し、そして、ビット列ｂ－１のブロック「１」にも「０」をセットする。
　次いで、Ｐボリューム１４１のブロック「３」にライトアクセス（Ａ→Ｄ）が５月１０日１４：００に入ると、コピーオンライト処理サブプログラム３０２は、更新前データ（Ａ）をＰボリューム１４１の対応ブロック「３」からリードし、リードデータ（Ａ）をＤボリューム１４２の空きセグメント「２３」に格納する。
　この時点での管理テーブルは、図６Ｆに示すものになる。すなわち、コピーオンライト処理サブプログラム３０２は、仮想ボリュームＶ４のブロック「３」にＤボリューム１４２のブロックアドレス「２３」を登録し、そして、ビット列ｂ－２のブロック「３」に「０」をセットする。
　この後、ユーザが３．３１（２３：００）時点のスナップショット（仮想ボリュームＶ３）にリードアクセスすると、スナップショット合成処理サブプログラム３０３は、管理テーブル図６Ｆのビット列ｂ－１を参照し、ブロックアドレス「３」へのリードアクセスを検出すると、対応するビットが「０」であることを確認する。
　そして、スナップショット合成処理サブプログラム３０３は仮想ボリュームＶ３のブロックアドレス「３」を参照して、Ｄボリューム１４２のセグメントアドレス「２０」を確認し、Ｄボリュームのセグメント「２０」から、更新前データ「ａ」をリードして、ファイルシステム処理プログラム１２３に提供する。
　また、クライアント計算機１３１が４．３０（２３：００）時点のスナップショット（仮想ボリュームＶ４）にリードアクセスすると、スナップショット合成処理サブプログラム３０３は、管理テーブル図６Ｆのビット列ｂ－２を参照し、ブロックアドレス「３」へのリードアクセスを検出すると、対応するビットが「０」であることを確認する。
　そして、スナップショット合成処理サブプログラム３０３は仮想ボリュームＶ４のブロックアドレス「３」を参照して、Ｄボリューム１４２のセグメントアドレス「２３」を確認し、Ｄボリュームのセグメント「２３」から、更新前データ「Ａ」をリードして、ファイルシステム処理プログラム１２３に提供する。
　スナップショット合成処理サブプログラム３０３が、管理テーブル図６Ｆのビットを参照して「１」を判定した場合は、Ｐボリューム１４１からデータをリードして、クライアント計算機１３１に提供する。
　既述したとおり、そもそも、更新前データをＤボリュームに格納して、クライアント計算機が運用ボリューム（Ｐボリューム１４１）のスナップショットを生成することは、運用ボリュームのフルコピーを必要とするバックアップに比較して、クライアント１３１からのＩＯを止めることなく、かつ、バックアップ計画に基づかなくてもよいなど、簡単便利であるために、スナップショット機能をバックアップ代わりに利用することが頻繁に行われてきた。
　スナップショット機能を実現するために、ストレージ装置１００は、クライアント計算機１３１からＰボリューム１４１にライトアクセスがある都度、更新前データを高性能ディスクドライブからなるＤボリュームに書き込んで、クライアント計算機１３１からのライトアクセスに対する応答性能を向上させていた。
　ところで、ＮＡＳ１００がスナップショット機能を継続するために、Ｄボリュームを長期に渡って運用すると、膨大な更新前データがＤボリュームに累積され、Ｄボリュームの容量を相当に圧迫することになる。
　そこで、Ｄボリュームの容量を拡張することが考えられるが、Ｄボリュームは高価で高性能なデバイスであることから、ＮＡＳサーバにおける記憶資源のビットコストを上昇させてしまう。
　一方、Ｄボリュームを低ビットコストであるディスクドライブ（このようなディスクドライブは、低価格である分、低性能であって、データのライト速度が顕著に遅い。）に置き換えることは、Ｐボリューム１４１に対するＩ／Ｏ性能が目立って低下するためこれを採用できない。
　すなわち、Ｐボリューム１４１に対するライトは、更新前データがＰボリューム１４１からリードされてＤボリューム１４２にライトされるまで完了せず、Ｄボリュームに低性能のストレージデバイスを使用すると、Ｄボリュームへのライトが律速段階となる。
　そこで、ＮＡＳ１００は、更新データを格納する更新データ格納型差分ボリューム（Ｆボリューム１４３）を新たに設定して、更新データを基にしてスナップショットを生成することとし、その分、Ｄボリュームに中長期間滞留しているデータをＤボリューム１４１から解放することによって、Ｄボリュームの容量の圧迫を防ぐこととした。
　一方、予め準備すべきＤボリュームの容量を少なくしたとしても、Ｄボリュームが更新前データの累積による容量圧迫に晒されることもなくなる。Ｆボリューム１４３は更新後のデータを格納するためのものであり、クライアント計算機１３１がライト時にアクセスするものでもないために、Ｄボリューム１４２用の記憶デバイスのように高性能・高価なものでなくてもよい。
　次に、スナップショットのユーザへの提供について、差分ボリュームに対する管理を、Ｄボリュームを用いる運用からを、Ｆボリュームを用いる運用に移行するための実施形態について説明する。
　この運用は、移行のためのポリシーによって実現されるものであり、例えば、Ｄボリューム１４２の使用済み容量が所定の閾値を越えた場合に移行処理を実施する、スナップショットボリューム数が所定の閾値を越えた場合に移行処理を実施する、毎年度末にその年のスナップショットボに対して移行処理を実施する等の種類がある。
　なお、ストレージ管理ユーザが、Ｄボリューム１４２に基づくスナップショット機能の運用を、Ｆボリューム１４２を用いた運用に移行する場合、移行処理の管理上の観点から、最新のスナップショットはＤボリュームによって運用されることを維持されることが好ましい。
　図７はＤボリュームを用いたスナップショット機能の運用を、Ｆボリュームを用いた運用に移行する一つの実施形態を示したブロック図である。Ｖ３～Ｖ６は、それぞれ特定時点(図７に記載)のスナップショットボリューム(仮想ボリューム)である。
　スナップショット再構成処理サブプログラム３０４は、Ｆボリューム１４３に格納する更新後データを確定する上で基となる静止化ボリュームを生成するために、仮想ボリュームＶ３からレプリケーションボリューム（Ｒ－ＶＯＬ）１４２Ａを静止化ボリュームとして生成する（図７のＳ２）。
　なお、Ｒ－ＶＯＬをＰ－ＶＯＬのバックアップから構成してもよい。スナップショット再構成処理サブプログラム３０４は、2009.3.30時点のスナップショットボリュームを仮想ボリュームＶ３からＲ－ＶＯＬに変更する。
　スナップショット再構成処理サブプログラム３０４は、Ｆ－ＶＯＬとＲ－ＶＯＬに基づいてスナップショットボリュームを生成できるようにするために、Ｆボリューム管理テーブル(図１２)の作成後、仮想ボリュームＶ４と仮想ボリュームＶ５とへのＰ－ＶＯＬとＤ－ＶＯＬの割り当てを解放して（Ｓ８，Ｓ９，Ｓ１２，Ｓ１３）、これら仮想ボリュームにＦ－ＶＯＬとＲ－ＶＯＬとを割り当てる（Ｓ６，Ｓ７，Ｓ１０Ａ，Ｓ１１）。
　ＮＡＳ１００は、スナップショット機能を維持しながら、ホスト計算機１３１からのライトアクセスに対する応答性の低下がないようにするために、最新の仮想ボリュームＶ６に対する運用を、Ｐ－ＶＯＬとＤ－ＶＯＬとを利用したものに維持している（Ｒ１，Ｒ２）。
　次に、Ｄボリュームを用いた運用を、Ｆボリュームを用いた運用に移行する動作を詳しく説明する。この動作は、スナップショット再構成処理サブプログラム３０４によって主に達成される。
　スナップショット再構成処理サブプログラム３０４は、先ず、図９のフローチャートを実行する。このフローチャートは、移行処理を開始するか否かを決定するものである。スナップショット再構成処理サブプログラム３０４は、スナップショットの環境が移行処理開始条件に合致しているか否かをチェックする（９００）。この条件とは、既述のとおり、例えば、Ｄボリューム１４２の未使用領域の減少などである。
　スナップショット再構成処理サブプログラム３０４が、これに合致すると判定すると、ストレージ管理用端末にこれを通知する（９０２）。管理端末は、ストレージ管理者に移行処理のための入力を求める。なお、運用の変更の要請は管理クライアント１３２に対して行われ、運用の変更の入力は管理クライアントに対して行われてもよい。この入力は、移行処理が適用される仮想ボリュームを特定するための入力である。図７に照らすと、仮想ボリュームＶ３、仮想ボリュームＶ４と、仮想ボリュームＶ５と、そして、仮想ボリュームＶ６がストレージ管理端末に入力される（９０４）。
　既述のとおり、スナップショット再構成処理サブプログラム３０４は、最新の仮想ボリュームの入力があっても、これを移行対象としない。したがって、仮想ボリュームＶ６の入力を省略してもよい。
　次いで、スナップショット再構成処理サブプログラム３０４は、入力された仮想ボリュームのＩＤと、移行処理開始フラグをメモリ１１の所定領域に記憶する（９０８）。
　スナップショット再構成処理サブプログラム３０４は、移行対象の仮想ボリュームが無いと、ステップ９０４を否定判定して図９のフローチャートを終了する。スナップショット再構成処理サブプログラム３０４は、このフローチャートを所定時間毎に繰り返し実行する。
　なお、ストレージ管理者は、図９に示すフローチャートに基づくことなく、移行処理対象となる仮想ボリュームの選択と、移行処理開始フラグのセットを行うことができる。
　図１０は、移行処理の詳細を示すフローチャートである。スナップショット再構成処理サブプログラム３０４は、移行開始フラグを所定時間毎に参照し、移行開始フラグがセットされていることを判定すると、図１０のフローチャートを開始する。なお、スナップショット再構成処理サブプログラム３０４は図１０のフローチャートを終了すると、このフラグをリセットする。
　スナップショット再構成処理サブプログラム３０４は、メモリ１１４に移行対象として登録された仮想ボリューム（Ｖ－ＶＯＬ）の識別番号をリードする（１０００）。
　次いで、ＲＡＩＤグループにＲボリューム１４２Ａが登録されているかを判定し、これがない場合には、最先の仮想ボリュームからＲボリュームを作成し（図６のＳ１）、ＲボリュームをＦ－ＶＯＬ管理テーブルに登録する（１００４）。
　最先の仮想ボリュームは、図６に照らすと、Ｖ３である。Ｒボリュームが存在する場合、スナップショット再構成処理サブプログラム３０４は、ステップ１００４をスキップする。
　スナップショット再構成処理サブプログラム３０４は、仮想ボリュームＶ３の全ブロックからデータをリードして、Ｒボリュームの対応するそれぞれのブロックにデータをコピーする（Ｓ２）。
　スナップショット再構成処理サブプログラム３０４は、図６Ｆに示すＤボリューム管理テーブルの仮想ボリュームＶ３に対応するビット列ｂ－１を参照して、データをＰ-ＶＯＬ又はＤ－ＶＯＬからリードする（Ｓ３，Ｓ４）。
　次いで、スナップショット再構成処理サブプログラム３０４は、最先の仮想ボリュームの次の世代仮想ボリュームＶ４を選択して（１００６）、この仮想ボリュームに対して移行処理を実行する。この処理を具体的に説明する。
　図１１は、図７の仮想ボリュームＶ３～Ｖ６に対するＤボリューム管理用のテーブルの一例である。このテーブルの見方は、既述した図６Ｆのものと同じである。すなわち、各仮想ボリュームの各ブロック内の数値は、Ｄボリュームのセグメントアドレスである。
　一方、図１２は、移行処理終了の際でのＦボリューム管理用テーブルであり、図１３は移行処理終了の際でのＤボリューム管理用のテーブルである。仮想ボリュームＶ３はＦボリューム管理用テーブル(図１１２)に、Ｆボリューム１４３の参照を要しない実ボリューム（Ｒ－ＶＯＬ）として登録されている。
　図１２において、仮想ボリュームＶ４（Ｆ－ＶＯＬ利用）、仮想ボリュームＶ５（Ｆ－ＶＯＬ利用）の各ブロック内のアドレスは、Ｐボリューム１４１に対する更新データを格納している、Ｆボリュームのセグメントアドレスを示している。
　「なし」は、スナップショット合成処理サブプログラム３０３がスナップショットを生成する際に、Ｆ－ＶＯＬを参照することなく、Ｒ－ＶＯＬを参照することを示している。
　移行処理が完了した時点で、移行処理開始前の時点のＤボリューム管理テーブル(図１１)は図１３のように変更される。すなわち、スナップショット再構成処理サブプログラム３０４は、仮想ボリュームＶ３～Ｖ５のエントリを管理テーブルから削除する。
　図１０のフローチャートに戻って説明を続ける。ステップの１００４　段階では、スナップショット再構成処理サブプログラム３０４は、Ｒ－ＶＯＬを仮想ボリュームＶ３に代えてＦボリューム用管理テーブルに登録する。この状態の管理テーブルの形態は図１４Ａに示すとおりである。
　次いで、スナップショット再構成処理サブプログラム３０４は、仮想ボリュームＶ３に続く仮想ボリュームＶ４を選択し（１００６）、移行対象ビットマップを作成する（１００８）。
　移行対象ビットマップとは、Ｆボリュームに、Ｐボリュームに対する更新データを登録するか否かを、スナップショット再構成処理サブプログラム３０４が判定するために必要なものである。
　図１４Ｂにおいて、ＢＡ１は、Ｄボリュームを利用する仮想ボリュームＶ４を、Ｆボリュームを利用するタイプに移行させるための移行対象ビットマップであり、ＢＡ２は、Ｄボリュームを利用する仮想ボリュームＶ５を、Ｆボリュームを利用するタイプに移行させるための移行対象ビットマップである。なお、符号５００を付して、図１１に示されたＤボリューム管理用テーブルを、参考のために図１４Ａに記す。
　このビットマップにおいて、「１」はＦボリュームに更新データが登録されず、「０」はＦボリュームに更新データが登録されることを示している。
　スナップショット再構成処理サブプログラム３０４は、移行対象ビットマップを作成する際、Ｐボリュームに更新があったか否かを判定するために、移行対象仮想ボリュームとこの一つ前の仮想ボリュームとを参照し、同じブロックアドレス同士の値を比較する。
　図１４Ｂに基づいて説明すると、スナップショット再構成処理サブプログラム３０４は、仮想ボリュームＶ４に対する移行対象ビットマップＢＡ１を作成する際、仮想ボリュームＶ３の設定後、Ｐ－ＶＯＬに更新があったか否かを判定するために、移行対象仮想ボリュームＶ４とこの一つ前の仮想ボリュームＶ３とを対比して、同じブロックアドレス同士の値を比較する。更新があると、同じブロックアドレス同士の値が変化するからである。
　ブロックアドレス０において、両方の仮想ボリュームにＤボリュームのセグメントアドレスが設定されていないために、移行対象ビットマップＢＡ１のブロックアドレス０には「１」が設定される。ブロックアドレス１について、両仮想ボリュームとも値が同じであるため、同様にＢＡ１のブロックアドレス１には「１」が設定される。
　スナップショット再構成処理サブプログラム３０４は、ブロックアドレス３において、両仮想ボリュームの値が異なるので、Ｐボリュームに対する更新があり、その結果として更新前データを格納するＤボリュームのセグメントアドレスが異なるものになったと判断して、移行対象ビットマップＢＡ１のブロックアドレス３に「０」を設定する。
　スナップショット再構成処理サブプログラム３０４は、ブロックアドレス１２において、仮想ボリュームＶ３にはＤボリュームのセグメントアドレスが設定されており、仮想ボリュームＶ４にはこれが設定されていないので、移行対象ビットマップＢＡ１のブロックアドレス１２に「０」を設定する。
　また、スナップショット再構成処理サブプログラム３０４は、仮想ボリュームＶ４と仮想ボリュームＶ５とを比較して、図１４Ｂに示すように、仮想ボリュームＶ５用の移行対象ビットマップＢＡ２を作成する。スナップショット再構成処理サブプログラム３０４は、移行対象ビットマップをメモリ１１４の所定領域に記憶する。
　ステップ１００８において、スナップショット再構成処理サブプログラム３０４は、仮想ボリュームＶ４用の移行対象ビットマップＢＡ１を既述のようにして作成すると、これを参照して、当該ビットマップの各ブロックアドレスの値を上から順番にチェックする（１０１０）。
　ビットの値が「０」が場合には、スナップショット再構成処理サブプログラム３０４は、ステップ１０１２～１０１８を実行し、「１」の場合には、ステップ１０２０を実行し、これを全てのビットについて適用する。この一連の処理によって、得られたＦボリューム管理テーブルは既述の図１２に示すとおりである。
　例えば、移行対象ビットマップＢＡ１（図１４Ｂ）のブロックアドレス「３」のビットは「０」であることから、スナップショット再構成処理サブプログラム３０４は、ステップ１０１２において、仮想ボリュームＶ４のブロックアドレス「３」にある、Ｄボリュームのセグメントアドレス「２３」の内容をリードする。
　そして、スナップショット再構成処理サブプログラム３０４は、Ｆボリュームのフリーセグメント（例えば、「６３」）をフリーキューから取得し、このセグメントアドレスにステップ１０１２でリードしたデータをライトし（１０１６、図６のＳ５Ａ）、そして、当該セグメントアドレス「６３」を仮想ボリュームＶ４（Ｆ－ＶＯＬ利用）のブロックアドレス「３」に登録する。
　Ｆボリュームのセグメントアドレス「６３」に登録されたデータは、仮想ボリュームＶ３と仮想ボリュームＶ４との間で、Ｐボリューム１４１に対して更新されたデータである。
　さらに、例えば、移行対象ビットマップのブロックアドレス「１２」のビットは「０」であることから、スナップショット再構成処理サブプログラム３０４は、仮想ボリュームＶ４のブロックアドレス「１２」を参照する（図１４Ｂ）。
　ここには、「なし」が登録されていることから、スナップショット再構成処理サブプログラム３０４は、Ｐボリュームの同じブロックアドレスからデータをリードし、これをＦボリュームのフリーセグメント「６４」にライトし（図６のＳ５）、そして、当該セグメントアドレス「６４」を仮想ボリュームＶ４（Ｆ－ＶＯＬ利用）のブロックアドレス「１２」に登録する（図１４Ｃ）。
　一方、移行ビットマップＢＡ１のブロックアドレスが「３」と「１２」以外には、「１」が登録されていることから、これらブロックアドレスについて、スナップショット再構成処理サブプログラム３０４は、仮想ボリュームＶ４（Ｆ－ＶＯＬ利用）の前のスナップショットボリュームであるＲボリュームの同一ブロックにおいて登録されている値と同じものを登録する。
　図１４Ｃに示すように、Ｒボリュームの全ブロックアドレスにはＦボリュームのセグメントアドレスの登録が無いことから、ブロックアドレスが「３」と「１２」以外の、仮想ボリュームＶ４（Ｆ－ＶＯＬ用）には、「なし」が登録される。
　そして、スナップショット再構成処理サブプログラム３０４は、移行対象ビットマップＶ４の全てのビットに対する既述の処理を終了すると、仮想ボリュームＶ４（Ｆ－ＶＯＬ利用）の各ブロックの値を参照し、Ｆボリュームのセグメントアドレスが登録されているブロックアドレスについて、Ｃｏｗビットマップのビット列ｂ－２の同一ブロックアドレスに「０」を登録し、Ｆボリュームのセグメントアドレスの登録が無いブロックアドレスについて、ビット列ｂ－２の同一ブロックアドレスに「１」を登録する。ここまでのＦボリューム管理用テーブルの形態は図１４Ｃに示すとおりである。
　既述のとおり、図１２のビットマップは、Ｆボリューム参照用ビットマップであり、図１１のビットマップは、Ｄボリューム参照用ビットマップである。
　なお、Ｆボリューム用ビット列の各ビットに対する、「０」又は「１」の登録処理を、移行対象ビットマップＶ４の各ブロックに対する、Ｆボリュームのセグメントアドレスを登録するか否かの処理の都度行うようにしてもよい。このようにして、スナップショット再構成処理サブプログラム３０４は、仮想ボリュームＶ４に対する移行処理を終了する。
　次いで、スナップショット再構成処理サブプログラム３０４は、ステップ１０２２を肯定判定し、仮想ボリュームＶ５に対する移行処理が終了していないために、ステップ１０２４において、他の仮想ボリュームＶ５があるため、ステップ１０２４を肯定判定して、ステップ１００６にリターンし、移行ビットマップＶ５用に基づき、仮想ボリュームＶ４（Ｆ－ＶＯＬ利用）と対比しながら、仮想ボリュームＶ４に対する移行処理と同様にして、ステップ１０１２～１０２２を実行する。この結果得られた、Ｆボリューム管理テーブルが図１４Ｄに示すとおりのものである。
　次いで、スナップショット再構成処理サブプログラム３０４は、ステップ１０２２を肯定判定し、次いで、全ての仮想ボリュームについて移行処理が終了したことを判定し、すなわち、ステップＳ１０２４を否定判定して、ステップ１０２６に移行する。
　スナップショット再構成処理サブプログラム３０４は、Ｄボリューム用管理テーブル（図１１）から仮想ボリュームＶ３～Ｖ５のエントリを削除する。その結果、同テーブルは、図１３に示す通りになる。さらに、削除されたエントリに含まれるＤボリュームの使用済みセグメントアドレスが、Ｄボリューム用管理テーブルに登録がある他の仮想ボリュームのブロックアドレスに登録されていない限り、これを解放する。
　この解放は、使用済みセグメントアドレスをフリーキューに接続することによって達成される。したがって、Ｄボリュームの容量を限られたものにしても、スナップショットボリュームＶ６に利用される更新前データを漏れなく保護・保管することができる。
　以上により、スナップショット再構成処理サブプログラム３０４は、図１０に係るフローチャートを終了する。
　次に、図１５は、ホスト計算機１３１からライトがＰボリューム１４１に適用（図７のＷＲ１）された場合における、フローチャートを示すものである。
　コピーオンライト処理サブプログラム３０２は、Ｄ－ＶＯＬのフリーセグメントを取得し（１５００）、ライトがあった、Ｐ－ＶＯＬの特定ブロックアドレスに存在する更新前データをリードしてこれをＤ－ＶＯＬのフリーセグメントに記憶する（１５０２、図７のＷＲ２）。
　そして、コピーオンライト処理サブプログラ３０２ムは、Ｄ－ＶＯＬボリュームのフリーセグメントアドレスをＤボリューム用管理テーブル（図１３）の仮想ボリュームＶ６特定ブロックアドレスに登録し、仮想ボリュームＶ６に対するＤボリューム用ビット列の対応するビットに「０」をセットする（１５０４）。以上により、図１５のフローチャートは終了する。
　なお、既述のとおり、仮想ボリュームＶ３からＶ５に対するスナップショット機能の運用を、Ｄボリュームを利用する運用から、Ｆボリュームを利用する運用に移行したので、これらの仮想ボリュームのエントリーは、図１３に示すように、Ｄボリューム管理用テーブルから削除されている。
　図１６は、スナップショットボリュームに、ホスト計算機１３１からリード要求があった場合のフローチャートを示すものである。
　図８はスナップショットボリュームの管理テーブルであって、複数ある複数のスナップショットボリュームの属性が記録されている。「RRR」はＲボリューム（実ボリューム）であることを示す属性フラグであり、「FFF」は、Ｆボリュームによって、更新後データとしての差分が管理されることを示す属性であり、「DDD」は、Ｄボリュームによって、更新前データとしての差分が管理されることを示す属性である。
　スナップショット作成処理サブプログラム３０１が、スナップショットボリュームを作成した時点で、これを属性とともに管理テーブルに登録し、さらに、スナップショット再構成処理サブプログラム３０４がスナップショットボリュームを、Ｄボリュームを利用した運用形態からＦボリュームを利用した運用形態に変更する都度、当該ボリュームの属性を更新する。
　スナップショット合成処理サブプログラム３０１は、この管理テーブルを参照して、ホスト計算機からのリード対象となったスナップショットボリュームの属性をチェックし、属性が「RRR」又は「FFF」の場合は、Ｆボリュームを利用してスナップショットを生成してこれをホスト計算機に対して提供し（１６０４）、「DDD」の場合は、Ｄボリュームを利用してスナップショットを生成する（１６０２）。
　スナップショット合成処理サブプログラム３０１がＦボリュームを利用してスナップショットを生成する場合、Ｆボリューム管理テーブル（図１２）にある、リード対象となった仮想ボリュームに対応するＦボリューム用ビット列を参照する。
　リード対象となったブロックアドレス対応するビットの値が「１」の場合は、Ｒボリュームの対応ブロックからデータをリードしこれをホスト計算機１３１に提供する（１６０６）。
　一方、「０」の場合には、管理テーブル（図１２）から、リード対象となった仮想ボリュームを判定し、この仮想ボリュームのリード対象となったブロックについて、Ｆボリュームのセグメントアドレスを取得する。そして、スナップショット合成処理サブプログラム３０１は、Ｆボリュームにアクセスし、このセグメントアドレスに登録されている更新後データをホスト計算機に提供する（１６０６）。
　また、ホスト計算機１３１からのリード対象となったスナップショットボリューム（Ｒ－ＶＯＬ）の属性が「RRR」であると、スナップショット合成処理プログラム３０１は、Ｆボリューム管理用テーブル（図１２）を参照するが（１６０４）、Ｒ－ＶＯＬに割り当てられているビット列の全ビットの値はＮＵＬＬであるため、Ｒボリュームの対応するブロックアドレスからデータを直接リードして、ホスト計算機に提供する（Ｓ１６０６）。
　なお、既述の実施形態では、ストレージ装置を、ＮＡＳとして説明したが、ファイルサーバとは別体になっている構成でもよい。
　産業上の利用性
　本発明は、スナップショットを、バックアップ手段として長期にわたって運用するようにしたとしても、差分ボリュームにおける更新前データの保持量の増大を抑制する。
　符号の説明
１００　ストレージ装置（ＮＡＳ）
１０１　コントローラ
１１４　メモリ
１１５　ディスク装置
１３１　クライアント計算機
１４１　プライマリボリューム（運用ボリューム）
１４２　更新前データ格納型差分ボリューム
１４３　更新後データ格納型差分ボリューム
 

Claims (13)

  1. 　ユーザ計算機にデータストレージサービスを適用するストレージ装置であって、
    　前記ユーザ計算機から継続的にアクセスされる運用ボリュームを設定し、さらに、当該運用ボリュームに対して、第１のスナップショットと第２のスナップショットとを設定するコントローラを備え、
    　前記コントローラは、
    　前記第１のスナップショットを、前記運用ボリュームと、当該運用ボリュームの更新前データを差分データとして格納する第１の差分ボリュームと、に基づいて生成し、
    　前記第２のスナップショットを、前記運用ボリュームの基準時のデータイメージと、前記運用ボリュームに対する更新データを差分データとして格納する第２の差分ボリュームと、に基づいて生成する、ストレージ装置。
  2. 　前記コントローラは、
    　前記ユーザ計算機から前記運用ボリュームにライトアクセスがあると前記運用ボリュームの前記更新前データを前記第１の差分ボリュームに格納し、
    　その後前記ライトアクセスに伴う更新データを前記運用ボリュームに格納し、
    　前記ユーザ計算機の前記第１のスナップショットへのアクセス位置を求め、
    　前記運用ボリュームに前記更新データが格納された位置を管理する管理情報を参照して、前記アクセス位置を前記運用ボリュームが前記更新データを格納した位置に対応するものであると判定すると、前記第１の差分ボリュームから前記更新前データを読んで、前記ユーザ計算機に供給し、前記アクセス位置を前記更新デーが格納されていない領域であると判定する、前記運用ボリュームからデータを読んで前記ユーザ計算機に供給し、
    　前記運用ボリュームの基準時のデータイメージを作成し、
    　前記基準時から前記第２のスナップショットの設定時までに前記運用ボリューム加わった更新データを前記第２の差分ボリュームに格納し、
    　前記ユーザ計算機の前記第２のスナップショットへのアクセス位置を求め、
    　前記運用ボリュームに前記更新データが格納された位置を管理する管理処理情報を参照して、前記アクセス位置を前記運用ボリュームが前記更新データを格納した位置に対応するものであると判定すると、前記第２の差分ボリュームから前記更新前データを読んで、前記ユーザ計算機に供給し、前記アクセス位置を前記更新デーが格納されていない領域であると判定する、前記データイメージからデータを読んでユーザ計算機に供給し、
    　前記第１のスナップショットとして、複数の世代のスナップショットを設定し、
    　前記複数の世代のうちの第１の世代のスナップショットに前記管理情報として第１の管理情報を設定し、
    　前記第１の世代以降の次世代のスナップショットに前記管理情報として第２の管理情報を設定し、
    　前記第１の管理情報と前記第２の管理情報とに基づいて、前記第１の世代のスナップショットの設定から前記次世代のスナップショット設定迄の前記運用ボリュームの更新位置を示す前記管理処理情報を生成し、
    　前記第１の世代のスナップショットから前記運用ボリュームの基準時のデータイメージとしての前記運用ボリュームのレプリケーションボリュームを生成し、
    　前記第２のスナップショットを前記次世代のスナップショットが設定時に設定されたスナップショットとして定義し、
    　前記次世代のスナップショットを削除し、
    　前記第１の差分ボリュームの記憶領域のうち、前記次世代のスナップショットに利用される前記更新前データを記憶する領域を空き領域として解放し、
    　前記第１の差分ボリュームが複数の高性能ディスク装置のＲＡＩＤグループに設定され、前記第２の差分ボリュームが複数の汎用低ビットコストのディスク装置のＲＡＩＤグループに設定されている請求項１記載のストレージ装置。
  3. 　前記第１のスナップショットを設定した前記コントローラは、
    　前記ユーザ計算機から前記運用ボリュームにライトアクセスがあると前記運用ボリュームの前記更新前データを前記第１の差分ボリュームに格納し、
    　その後前記ライトアクセスに伴う更新データを前記運用ボリュームに格納し、
    　前記ユーザ計算機の前記第１のスナップショットへのアクセス位置を求め、
    　前記運用ボリュームに前記更新データが格納された位置を管理する管理情報を参照して、前記アクセス位置を前記運用ボリュームが前記更新データを格納した位置に対応するものであると判定すると、前記第１の差分ボリュームから前記更新前データを読んで、前記ユーザ計算機に供給し、前記アクセス位置を前記更新デーが格納されていない領域であると判定する、前記運用ボリュームからデータを読んで前記ユーザ計算機に供給する、請求項１記載のストレージ装置。
  4. 　前記第２のスナップショットを設定した前記コントローラは、
    　前記運用ボリュームの基準時のデータイメージを作成し、
    　前記基準時から前記第２のスナップショットの設定時までに前記運用ボリューム加わった更新データを前記第２の差分ボリュームに格納し、
    　前記ユーザ計算機の前記第２のスナップショットへのアクセス位置を求め、
    　前記運用ボリュームに前記更新データが格納された位置を管理する管理処理情報を参照して、前記アクセス位置を前記運用ボリュームが前記更新データを格納した位置に対応するものであると判定すると、前記第２の差分ボリュームから前記更新前データを読んで、前記ユーザ計算機に供給し、前記アクセス位置を前記更新デーが格納されていない領域であると判定する、前記データイメージからデータを読んでユーザ計算機に供給する、請求項１記載のストレージ装置。
  5. 　前記コントローラは、前記第１のスナップショットとして、複数の世代のスナップショットを設定し、各世代のスナップショット毎に前記管理情報を設定する、請求項３記載のストレージ装置。
  6. 　前記運用ボリュームの基準時のデータイメージが前記運用ボリュームのレプリケーションボリュームからなる、請求項４記載のストレージ装置。
  7. 　前記コントローラは、前記複数の世代のスナップショットの一つから前記レプリケーションボリュームを生成する、請求項５記載のストレージ装置。
  8. 　前記第２のスナップショットを設定した前記コントローラは、
    　前記運用ボリュームの基準時のデータイメージを作成し、
    　前記基準時から前記第２のスナップショットの設定時までに前記運用ボリューム加わった更新データを前記第２の差分ボリュームに格納し、
    　前記ユーザ計算機の前記第２のスナップショットへのアクセス位置を求め、
    　前記運用ボリュームに前記更新データが格納された位置を管理する管理処理情報を参照して、前記アクセス位置を前記運用ボリュームが前記更新データを格納した位置に対応するものであると判定すると、前記第２の差分ボリュームから前記更新前データを読んで、前記ユーザ計算機に供給し、前記アクセス位置を前記更新デーが格納されていない領域であると判定する、前記データイメージからデータを読んでユーザ計算機に供給する、請求項３記載のストレージ装置。
  9. 　前記コントローラは、
    　前記第１のスナップショットとして、複数の世代のスナップショットを設定し、
    　前記第２のスナップショットを前記複数の世代のスナップショットの一部を置き換えるものとして定義し、
    　前記第２のスナップショットによって置き換えられた前記複数世代のスナップショットの一部を削除し、
    　前記第１の差分ボリュームの記憶領域のうち、前記削除されるスナップショットに利用される前記更新前データを記憶する領域を空き領域として解放する、請求項８記載のストレージ装置。
  10. 　前記コントローラは、
    　前記第１のスナップショットとして、複数の世代のスナップショットを設定し、
    　前記複数の世代のうちの第１の世代のスナップショットに前記管理情報として第１の管理情報を設定し、
    　前記第１の世代以降の次世代のスナップショットに前記管理情報として第２の管理情報を設定し、
    　前記第１の管理情報と前記第２の管理情報とに基づいて、前記第１の世代のスナップショットの設定から前記次世代のスナップショット設定迄の前記運用ボリュームの更新位置を示す前記管理処理情報を生成し、
    　前記第１の世代のスナップショットから前記運用ボリュームの基準時のデータイメージとしての前記運用ボリュームのレプリケーションボリュームを生成し、
    　前記第２のスナップショットを前記次世代のスナップショットが設定時に設定されたスナップショットとして定義し、
    　前記次世代のスナップショットを削除し、
    　前記第１の差分ボリュームの記憶領域のうち、前記次世代のスナップショットに利用される前記更新前データを記憶する領域を空き領域として解放する、請求項８記載のストレージ装置。
  11. 　前記第１の差分ボリュームが複数の高性能ディスク装置のＲＡＩＤグループに設定され、前記第２の差分ボリュームが複数の汎用低ビットコストのディスク装置のＲＡＩＤグループに設定されている、請求項９記載のストレージ装置。
  12. 　前記コントローラは、複数の世代のスナップショットを設定し、過去世代のスナップショットを前記第２のスナップショットから構成し、それ以降の世代のスナップショットを前記第１のスナップショットから構成した、請求項１記載のストレージ装置。
  13. 　ユーザ計算機にデータストレージサービスを適用するストレージ装置のスナップショット制御方法であって、
    　ストレージ装置は、
    　前記ユーザ計算機から継続的にアクセスされる運用ボリュームと、
    　前記運用ボリュームに対して、第１のスナップショットと第２のスナップショットとを設定するコントローラと、
    　を備え、
    　前記コントローラは、更新前データを利用したスナップショットを、更新後データを利用するスナップショットに置き換え、
    　差分ボリュームの更新前データを格納している領域を空き領域として解放する、ストレージ装置のスナップショット制御方法。

     
PCT/JP2010/000560 2009-09-17 2010-01-29 ストレージ装置及びそのスナップショット制御方法 WO2011033692A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/811,401 US8510526B2 (en) 2009-09-17 2010-01-29 Storage apparatus and snapshot control method of the same

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-216147 2009-09-17
JP2009216147A JP2013011919A (ja) 2009-09-17 2009-09-17 ストレージ装置及びそのスナップショット制御方法

Publications (1)

Publication Number Publication Date
WO2011033692A1 true WO2011033692A1 (ja) 2011-03-24

Family

ID=43758313

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/000560 WO2011033692A1 (ja) 2009-09-17 2010-01-29 ストレージ装置及びそのスナップショット制御方法

Country Status (3)

Country Link
US (1) US8510526B2 (ja)
JP (1) JP2013011919A (ja)
WO (1) WO2011033692A1 (ja)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9235474B1 (en) * 2011-02-17 2016-01-12 Axcient, Inc. Systems and methods for maintaining a virtual failover volume of a target computing system
US8954544B2 (en) 2010-09-30 2015-02-10 Axcient, Inc. Cloud-based virtual machines and offices
US9705730B1 (en) 2013-05-07 2017-07-11 Axcient, Inc. Cloud storage using Merkle trees
US8589350B1 (en) 2012-04-02 2013-11-19 Axcient, Inc. Systems, methods, and media for synthesizing views of file system backups
US10284437B2 (en) 2010-09-30 2019-05-07 Efolder, Inc. Cloud-based virtual machines and offices
US8924360B1 (en) 2010-09-30 2014-12-30 Axcient, Inc. Systems and methods for restoring a file
US8566543B2 (en) 2011-12-19 2013-10-22 Hitachi, Ltd. Computer system and reclamation control method
US9304946B2 (en) * 2012-06-25 2016-04-05 Empire Technology Development Llc Hardware-base accelerator for managing copy-on-write of multi-level caches utilizing block copy-on-write differential update table
WO2014051544A2 (en) 2012-09-25 2014-04-03 Empire Technology Development Llc Improved performance and energy efficiency while using large pages
US9785647B1 (en) 2012-10-02 2017-10-10 Axcient, Inc. File system virtualization
US9852140B1 (en) 2012-11-07 2017-12-26 Axcient, Inc. Efficient file replication
US9292153B1 (en) 2013-03-07 2016-03-22 Axcient, Inc. Systems and methods for providing efficient and focused visualization of data
US9397907B1 (en) 2013-03-07 2016-07-19 Axcient, Inc. Protection status determinations for computing devices
IN2013CH01006A (ja) * 2013-03-08 2015-08-14 Lsi Corp
US10353783B1 (en) 2013-06-26 2019-07-16 EMC IP Holding Company LLC Pluggable recovery in a data protection system
US10235392B1 (en) 2013-06-26 2019-03-19 EMC IP Holding Company LLC User selectable data source for data recovery
US9641486B1 (en) * 2013-06-28 2017-05-02 EMC IP Holding Company LLC Data transfer in a data protection system
JP2015162001A (ja) * 2014-02-26 2015-09-07 富士通株式会社 ストレージ管理装置、ストレージ装置、及びストレージ管理プログラム
US11010409B1 (en) * 2016-03-29 2021-05-18 EMC IP Holding Company LLC Multi-streaming with synthetic replication
EP3274896B1 (en) * 2016-04-22 2019-08-21 Hewlett-Packard Enterprise Development LP Configuration of a memory controller for copy-on-write with a resource controller
US11755226B2 (en) 2020-09-18 2023-09-12 Hewlett Packard Enterprise Development Lp Tracking changes of storage volumes during data transfers
US11720274B2 (en) 2021-02-03 2023-08-08 Hewlett Packard Enterprise Development Lp Data migration using cache state change
JP2023001471A (ja) * 2021-06-21 2023-01-06 株式会社日立製作所 ストレージシステム、計算機システム及び制御方法
US11693565B2 (en) 2021-08-10 2023-07-04 Hewlett Packard Enterprise Development Lp Storage volume synchronizations responsive to communication link recoveries

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11120055A (ja) * 1997-10-13 1999-04-30 Toshiba Corp コンピュータシステムおよびデータ退避方法
JP2005332067A (ja) * 2004-05-18 2005-12-02 Hitachi Ltd バックアップ取得方法及びディスクアレイ装置
JP2007140746A (ja) * 2005-11-16 2007-06-07 Hitachi Ltd 計算機システム及び管理計算機並びにリカバリ管理方法
JP2007213345A (ja) * 2006-02-09 2007-08-23 Hitachi Ltd ストレージシステム及びその制御方法
JP2007226596A (ja) * 2006-02-24 2007-09-06 Hitachi Ltd 記憶制御装置及び記憶制御装置を用いたデータマイグレーション方法
JP2007280323A (ja) * 2006-04-12 2007-10-25 Hitachi Ltd 記憶システム及びデータ管理方法
JP2008015768A (ja) * 2006-07-05 2008-01-24 Hitachi Ltd 記憶システム並びにこれを用いたデータの管理方法
JP2009020914A (ja) * 2008-10-14 2009-01-29 Fujitsu Ltd ストレージ制御装置、ストレージ制御プログラム、ストレージ制御方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6934822B2 (en) * 2002-08-06 2005-08-23 Emc Corporation Organization of multiple snapshot copies in a data storage system
US7266654B2 (en) 2003-03-18 2007-09-04 Hitachi, Ltd. Storage system, server apparatus, and method for creating a plurality of snapshots
JP4292882B2 (ja) 2003-03-18 2009-07-08 株式会社日立製作所 複数のスナップショット維持方法及びサーバ装置及びストレージ装置
JP4456909B2 (ja) 2004-03-29 2010-04-28 株式会社日立製作所 バックアップ方法、ストレージシステム及びそのプログラム

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11120055A (ja) * 1997-10-13 1999-04-30 Toshiba Corp コンピュータシステムおよびデータ退避方法
JP2005332067A (ja) * 2004-05-18 2005-12-02 Hitachi Ltd バックアップ取得方法及びディスクアレイ装置
JP2007140746A (ja) * 2005-11-16 2007-06-07 Hitachi Ltd 計算機システム及び管理計算機並びにリカバリ管理方法
JP2007213345A (ja) * 2006-02-09 2007-08-23 Hitachi Ltd ストレージシステム及びその制御方法
JP2007226596A (ja) * 2006-02-24 2007-09-06 Hitachi Ltd 記憶制御装置及び記憶制御装置を用いたデータマイグレーション方法
JP2007280323A (ja) * 2006-04-12 2007-10-25 Hitachi Ltd 記憶システム及びデータ管理方法
JP2008015768A (ja) * 2006-07-05 2008-01-24 Hitachi Ltd 記憶システム並びにこれを用いたデータの管理方法
JP2009020914A (ja) * 2008-10-14 2009-01-29 Fujitsu Ltd ストレージ制御装置、ストレージ制御プログラム、ストレージ制御方法

Also Published As

Publication number Publication date
US8510526B2 (en) 2013-08-13
JP2013011919A (ja) 2013-01-17
US20110238937A1 (en) 2011-09-29

Similar Documents

Publication Publication Date Title
WO2011033692A1 (ja) ストレージ装置及びそのスナップショット制御方法
JP4292882B2 (ja) 複数のスナップショット維持方法及びサーバ装置及びストレージ装置
US10977124B2 (en) Distributed storage system, data storage method, and software program
JP4559046B2 (ja) 仮想テープライブラリ装置
JP4990066B2 (ja) 論理ボリュームのペアを利用したデータ保存の方式を変更する機能を備えたストレージシステム
JP5346536B2 (ja) 情報バックアップ／リストア処理装置、及び情報バックアップ／リストア処理システム
US7536291B1 (en) System and method to support simulated storage operations
US7467275B2 (en) Capacity expansion volume migration method
US7266654B2 (en) Storage system, server apparatus, and method for creating a plurality of snapshots
US7873600B2 (en) Storage control device to backup data stored in virtual volume
US8204858B2 (en) Snapshot reset method and apparatus
US8615641B2 (en) System and method for differential backup
US20060047926A1 (en) Managing multiple snapshot copies of data
US20090216973A1 (en) Computer system, storage subsystem, and data management method
US20060155944A1 (en) System and method for data migration and shredding
JP2005031716A (ja) データバックアップの方法及び装置
US20070061540A1 (en) Data storage system using segmentable virtual volumes
US8140886B2 (en) Apparatus, system, and method for virtual storage access method volume data set recovery
US7549029B2 (en) Methods for creating hierarchical copies
US6629203B1 (en) Alternating shadow directories in pairs of storage spaces for data storage
JP4937863B2 (ja) 計算機システム、管理計算機及びデータ管理方法
US20220011977A1 (en) Storage system, control method, and recording medium
JP2006011811A (ja) 記憶制御システム及び記憶制御方法
US20060059188A1 (en) Operation environment associating data migration method
JP4394467B2 (ja) ストレージシステム、サーバ装置及び先行コピーデータ生成方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 12811401

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10816809

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10816809

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP