JP4877921B2 - Storage system, storage controller, and recovery point detection method for storage controller - Google Patents

Description

  The present invention relates to a storage system, a storage control device, and a recovery point detection method for the storage control device.

In order to efficiently manage a large amount of data that increases day by day, a storage system that manages a large number of data distributed and managed by a plurality of computers in one place is used. Here, a technique is known in which journal data is managed in preparation for a case where a user accidentally erases data, and the user data is recovered to an arbitrary point in time using the journal data (Patent Document 1).
JP 2005-18738 A

  The prior art described in the above-mentioned document is effective when the user clearly knows the point in time when data recovery is desired, but is not convenient when the user does not know the point in time when recovery is desired. . If the user clearly recognizes the point in time when the user wishes to recover, it is easy to recover the user data to the specified recovery point.

  However, there are many cases where the user has no idea at what time the data should be recovered. It takes time and effort to recover a file that is not normally used to a point desired by the user, unless the file that has been worked on is accidentally deleted. In order to recover a volume to a specified point in time, a large number of journal data must be sequentially applied to a reference data group.

  The user needs to execute the recovery operation for the entire volume many times while appropriately specifying the recovery time point until the desired result is obtained. As described above, even when the user has an idea about the content to be recovered, it is rare that the user knows exactly what time it is. Therefore, it is necessary for the user to execute a plurality of recovery operations until the desired result is obtained and to confirm the result.

  The present invention has been made in view of the above-described problems, and a purpose thereof is a storage system, a storage control device, and a storage control device that can detect a time point that satisfies a user's desired condition relatively easily. It is to provide a recovery point detection method. Another object of the present invention is to provide a user with a time point that satisfies a user's desired condition, and to recover the storage contents of the data volume up to the time point specified by the user. It is an object of the present invention to provide a recovery point detection method for a control device. Other objects of the present invention will become clear from the description of the embodiments described later.

  In order to solve the above problem, a storage system according to one aspect of the present invention is a storage system including a host computer and a storage control device that provides a data volume to the host computer. A search request issuing unit that issues a search request for designating a restoration target range and a search condition, and the storage control unit receives an update history management unit for managing the update history of the data volume, and a search request Includes a first restoration unit that restores data in the restoration target range of the data stored in the data volume for each update history and stores the data in the temporary restoration area, and is restored in the temporary restoration area. Whether the restored data matches the search criteria, and detects the period when the restored data matches the search criteria continuously It comprises a search unit that notifies the strike computer, a.

  In the embodiment of the present invention, the host computer designates a predetermined time point included in the period notified from the search unit, and issues a restoration request for restoring the storage contents of the data volume to the state at the predetermined time point. The storage controller further includes a second restorer that restores the storage contents of the data volume to a predetermined point in time by using the update history when a restore request is received.

  In the embodiment of the present invention, the update history management unit manages the storage contents of the data volume for each of a plurality of designated generations, and the first restoration unit includes a restoration target period in the search request. If there is, the data within the restoration target range within the restoration target period in the data volume is restored for each update history and stored in the temporary restoration area.

  In the embodiment of the present invention, the host computer can access the data restored in the temporary restoration area.

  In the embodiment of the present invention, the storage control device can transmit data restored in the temporary restoration area to the host computer.

  In the embodiment of the present invention, the search unit notifies the host computer of the start time when the data restored in the temporary restoration area first matches the search condition and the end time finally matching the search condition as the period.

  In the embodiment of the present invention, when a plurality of periods in which the data restored in the temporary restoration area continuously match the search condition are detected, the search unit notifies the host computer of all the plurality of periods.

  In the embodiment of the present invention, when a plurality of restoration target ranges are specified in the search request, the first restoration unit prepares a temporary restoration area for each of the plurality of restoration target ranges, and performs a plurality of restorations. Restore the data within the target range.

  In the embodiment of the present invention, every time the host computer updates the data volume, the update history management unit manages the data before update in association with the update time.

  In the embodiment of the present invention, the update history management unit stores an image of the storage content of the data volume at at least one checkpoint that is designated regularly or irregularly, and from the checkpoint to the next check Manage the history of updates made up to the point.

  In the embodiment of the present invention, the update history management unit manages the update history in file units, and the restoration target range can be specified in file units.

  In the embodiment of the present invention, the update history management unit manages the update history in file units, and the restoration target range can be specified in file units by file path information.

  In the embodiment of the present invention, the update history management unit manages the update history in file units, and the restoration target range can be specified in file units by hash values based on the path information of the files.

  In the embodiment of the present invention, the restoration target range can be specified by a logical unit number, an offset logical block address, and a data size.

  In the embodiment of the present invention, the storage control device receives an access request in file units from the host computer, and converts the access request in file units into input / output requests in block units, and the first controller And a second controller that transmits and receives data to and from a plurality of storage drives based on input / output requests in units of blocks input from the first controller. The first controller includes a first restoration unit, a search unit, The update history acquisition unit for acquiring the update history managed by the update history management unit by the first restoration unit and a temporary restoration area are provided, and the update history management unit is provided in the second controller. Is provided.

  A storage control device according to another aspect of the present invention is a storage control device that provides a data volume to a host computer, an update history management unit for managing an update history of the data volume, and at least a restoration target range from the host computer. And a first restoration unit that restores data in the restoration target range of the data volume for each update history and stores the data in the temporary restoration area when the retrieval request including the retrieval condition is received, and temporary restoration A search unit that determines whether or not the data restored in the area matches the search condition, detects a period in which the restored data continuously matches the search condition, and notifies the host computer of the period.

  A storage control device according to still another aspect of the present invention is a storage control device that provides a data volume to a host computer, and a storage drive that is controlled by the controller and provides a storage area for providing the data volume. The controller includes an access request processing unit that performs file access to the data volume in accordance with a file access request from the host computer, and updates when the host computer requests an update of the file stored in the data volume. A journal creation processing unit for managing the update history by storing the previous data in the journal volume, and further storing the update time and the position where the data before the update is stored in the journal volume as journal management information; Ho When a search request including at least information for specifying a file to be restored and a search condition to be satisfied by the file to be restored is issued from the target computer, the file to be restored from among a group of files stored in the data volume Is restored for each update history based on the journal management information and the journal volume, and the restored data is stored in the temporary restoration area, and the files restored in the temporary restoration area are searched conditions. A search unit that determines whether the restored file matches the search condition and notifies the host computer of the period when the restored file matches the search condition, and a period when the host computer matches the search condition continuously If you specify the specified point in time and request to restore the storage contents of the data volume, the journal management information Based on the fine journal volume comprises a second restoring section for restoring the stored contents of the data volume to the state of the predetermined time, the.

  In another embodiment of the present invention, the host computer issues a search request in a predetermined case. In the predetermined case, if the file to be restored is infected with a computer virus, the file to be restored is When it is lost, at least one of the files when the restoration target file is updated is included.

  A recovery point detection method for a storage control device according to still another aspect of the present invention is a method for detecting a recovery point using a storage control device that provides a data volume to a host computer. A first step for determining whether or not a search request including a search condition has been issued; and if it is determined that the search request has been issued in the first step, a second step of securing a temporary restoration area in the storage area Step and update history information that manages the history of updates to the data volume by the host computer are acquired in order from the old history, and it is determined whether the data related to the acquired update history information is included in the restoration target range 3rd step to be performed and the data related to the acquired update history information is included in the restoration target range In the fourth step, data related to update history information is read from the update data management volume and stored in the temporary restoration area, and it is determined whether or not the data stored in the temporary restoration area matches the search condition. A fifth step, a sixth step for storing the update time when the data stored in the temporary restoration area matches the search condition in the update time storage area, and a sixth step for storing the update time in the update time storage area A seventh step of reading the stored update time and transmitting the update time as a recovery point to the host computer.

  All or part of the means, functions, and steps of the present invention may be configured as a computer program executed by a computer system. When all or part of the configuration of the present invention is configured by a computer program, the computer program can be distributed and fixed to various storage media, for example, or can be transmitted via a communication network. it can.

  FIG. 1 is an explanatory diagram showing the overall outline of an embodiment of the present invention. The storage system of this embodiment includes a host computer (hereinafter “host”) 1 and a storage control device 2 as will be described later.

  The host 1 is configured, for example, as a server computer or a personal computer, and is connected to the storage control device 2 via the communication network CN so as to be capable of bidirectional communication. Further, the host 1 can be configured to include, for example, an application program 1A, a recovery point search request issuing unit 1B, and a recovery instruction unit 1C.

  The application program 1A is a program used for various operations of the user, such as a database, an e-mail management program, a customer management program, a sales management program, and the like.

  The recovery point search request issuing unit (hereinafter sometimes abbreviated as “search request issuing unit”) 1B corresponds to the “search request issuing unit”. The search request issuing unit 1B issues a search request D1 for searching for a recovery point desired by the user. The search request D1 includes, for example, a recovery target range, a recovery target period, and a search condition. The search request issuing unit 1B issues a request for investigating a recovery point desired by the user. Therefore, the search request issuing unit 1B can also be called, for example, a “recovery point investigation requesting unit”.

  Examples of the recovery target range include a file unit (a file includes a directory) and a block data unit. By designating a desired file name as a restore target, the user can temporarily restore only that file and investigate a recovery point.

  As the recovery target period, an update history management unit can be designated. For example, when the update history of the user data volume V1 is managed in a management unit such as a day unit, a week unit, a month unit, etc., the user designates a desired period or a desired date and time, Request recovery point investigation.

  Examples of search conditions include conditions such as keywords, time stamps, and the entire contents of files. For example, the user can confirm the period (recovery point candidate) during which the restoration target file includes the predetermined keyword by specifying that the predetermined keyword is included as a search condition.

  The recovery instruction unit 1C corresponds to a “restore request issuing unit”. The recovery instruction unit 1C designates any recovery point from the recovery point search result (recovery point candidate) D2, and restores the stored contents of the user data volume V1.

  The storage control device 2 is configured as a disk array device, for example. The storage controller 2 includes, for example, an R / W processing unit 2A, a journal creation processing unit 2B, a partial restore processing unit 2C, a search processing unit 2D, a restore processing unit 2E, a user data volume V1, and a journal volume. V2, a temporary restore area V3, and a restore volume V4 can be provided.

  The R / W processing unit 2A processes access requests (read requests and write requests) from the host 1. When a read request is issued from the host 1, the R / W processing unit 2A reads the requested data from the user data volume V1 and transmits it to the host 1. When a write request is issued from the host 1, the R / W processing unit 2A causes the write data to be written to the user data volume V1.

  The journal creation processing unit 2B corresponds to an “update history management unit”. The journal creation processing unit 2B is for managing an update history for the user data volume V1. The journal creation processing unit 2B generates journal data each time a write request is issued from the host 1, and stores this journal data in the journal volume V2. For example, the journal creation processing unit 2B saves the data before update in the journal volume V2, and associates the save time (that is, update time) of this data with the save location (storage destination address in the journal volume V2). to manage.

  The partial restore processing unit 2C corresponds to a “first restoration unit”. The partial restore processing unit 2C partially restores the stored contents of the user data volume V1 based on the search request D1 issued from the search request issuing unit 1B. That is, the partial restore processing unit 2C restores only the data belonging to the restore target range in the search request D1 for each update history, and stores the restoration result in the temporary restore area V3. For example, when a specific file is specified as the restore target range, the partial restore processing unit 2C determines the oldest state in history management, the state at the next update, the state at the next update, and the history management. As shown in the latest state, each update history related to the specific file is restored.

  The search processing unit 2D corresponds to a “search unit”. The search processing unit 2D detects the update time of data that matches the search condition in the search request D1 for the restored data stored in the temporary restore area V3. The search processing unit 2D creates a recovery point candidate list D2 based on the update time of data that matches the search condition, and transmits it to the host 1. The search processing unit 2D specifies a period during which the recovery target file continues to match the search conditions in the search request D1, and notifies the host 1 as the recovery point candidate list D2.

  The restore processing unit 2E corresponds to a “second restoration unit”. The restore processing unit 2E restores the stored contents of the user data volume V1 up to the recovery point designated by the recovery instruction unit 1C. The restore processing unit 2E sequentially applies the journal data managed by the journal volume V2 to the storage contents of the user data volume V1, and stores the application result in the restore volume V4. As a result, the storage content of the specified recovery point is restored to the restore volume V4. Then, by switching the access destination of the host 1 from the user data volume V1 to the restore volume V4, the application program 1A of the host 1 can use the data recovered at the time desired by the user.

  The storage control device 2 includes a plurality of storage drives either inside or outside the casing (see FIG. 2). Each storage drive is configured, for example, as a hard disk drive or a semiconductor memory drive. By gathering a predetermined number of storage areas of each storage drive, a virtualized physical storage device can be obtained. Each of the volumes V1, V2, V3, and V4, which are logical storage devices, can be provided in this physical storage device.

  The user data volume V1 stores user data used by the application program 1A. The journal volume V2 stores the update history for the user data volume V1 as journal data.

  The temporary restore area V3 is used for partial restore processing by the partial restore processing unit 2C. The temporary restore area V3 can be generated using the storage area of the storage drive, or can be generated using the storage area of the memory included in the storage control device 2. The restore volume V4 is used by the restore processing unit 2E. In the restore volume V4, the storage contents of the user data volume V1 at the recovery point designated by the user are reproduced.

  Next, the operation of this embodiment will be described. When the application program 1A updates the data in the user data volume V1, the journal creation processing unit 2B generates journal data for storing this update history. The generated journal data is stored in the journal volume V2.

  Here, there are cases where the user desires the stored contents at a predetermined point in the past. For example, a user may accidentally delete a necessary file. If the user clearly recognizes the timing (point) to be recovered, the timing may be designated as a recovery point and restored by the restore processing unit 2E.

  On the other hand, when the user does not clearly grasp the timing to be recovered, the user can cause the storage control device 2 to investigate the timing to be recovered using another information as a clue.

  That is, the user can request a recovery point survey by specifying a recovery target range (name of a file desired to be recovered), a recovery target period (recovery point survey period), and a search condition. This recovery point investigation request is given to the storage controller 2 as a search request D1.

  The partial restore processing unit 2C does not restore the entire user data volume V1, but restores only the file designated by the user for each update history of the file.

  Each restored file is stored in the temporary restore area V3. The search processing unit 2D determines whether or not a search condition is satisfied for each restored file, and specifies a period that matches the search condition. Then, the search processing unit 2D reports the period that matches the search condition to the host 1 as the recovery point candidate list D2. The user can select a desired point in time from the reported recovery point candidate list D2 as a recovery point, and can request the restore processing unit 2E to restore. The restore processing unit 2E recovers the stored contents of the user data volume V1 up to the recovery point instructed by the user.

  An example will be described. For example, assume that a user accidentally deletes a document file named “2005 Second Half Report”. It is assumed that the user knows that the directory name to which the document file belongs is “business relation”, but does not remember when the document file was deleted.

  In this case, the user designates the directory name “business relation” as the restoration target range and the file name “2005 first half report” as the search condition. Thereby, the search request issuing unit 1B issues a search request D1.

  The partial restore processing unit 2C restores, for each update history, only the file group included in the directory “business relationship” designated as the restore target range among the many files stored in the user data volume V1. Let The restored file group is stored in the temporary restore area V3.

  The search processing unit 2D detects only files including the keyword “2005 first half report” from the file group stored in the temporary restore area V3. Then, the search processing unit 2D may detect that a file including the keyword “2005 first half report” first appeared on October 1, 2005, and that November 30, 2005 was the last appearance. it can. The search processing unit 2D reports to the host 1 the recovery point candidate list D2 from the first appearance time to the last appearance time.

  By referring to the recovery point candidate list D2, the user can designate any time point between the first appearance time point and the last appearance time point as a recovery point, and can instruct the restoration of the user data volume V1. As a result, the restore processing unit 2E reproduces the storage contents at the time desired by the user in the restore volume V4.

  As will be described later in the embodiment, for example, when it is not necessary to restore the entire user data volume V1, the storage control device 2 may provide the host 1 with the file stored in the temporary restore area V3. it can.

  In this embodiment, since it is configured in this way, even when the user does not recognize the point to be recovered, a suitable recovery point candidate is presented by using a small amount of information that the user remembers as a clue. Can do. Therefore, the user does not need to restore the entire user data volume V1 through trial and error, and can obtain a desired file relatively easily and quickly, improving usability. Hereinafter, this embodiment will be described in detail.

  Embodiments of the present invention will be described in detail. FIG. 2 is a configuration explanatory diagram showing a simplified hardware configuration of the storage system. This storage system includes a host 10 and a storage control device 20. For example, the host 10 and the storage control device 20 are connected via a communication network CN1 having a switch 30 so that bidirectional communication is possible.

  Examples of the communication network CN1 include a LAN (Local Area Network) using TCP / IP (Transmission Control Protocol / Internet Protocol), a SAN (Storage Area Network) using FCP (Fibre Channel Protocol), and the like. It is also possible to directly connect the host 10 and the storage control device 20 by omitting the switch 30 as a relay device.

  The host 10 is configured as a computer device including, for example, a CPU (Central Processing Unit) 11, a memory 12, a communication interface (“I / F” in the figure) 13, and a user interface (“UI” in the figure) 14.

  The memory 12 can be configured to include, for example, a ROM (Read Only Memory), a RAM (Random Access Memory), a local disk, and the like. The memory 12 stores various programs such as an OS (Operating System) and application programs. The CPU 11 implements the function of each program by reading and executing the program stored in the memory 12. The user interface 14 can include, for example, an information output device such as a display device and a speaker, and an information input device such as a keyboard switch, a pointing device, and a microphone.

  The storage control device 20 can be configured with a file controller 100, a block controller 200, and a disk enclosure 300. In addition, as shown in the Example mentioned later, the file controller 100 and the block controller 200 can also be integrated into one controller.

  The file controller 100 corresponds to a “controller” or a “first controller”. The file controller 100 is configured as a computer device that manages data input / output in file units. The file controller 100 is connected to the block controller 200 via the communication path CN2 so as to be capable of bidirectional communication. The communication path CN2 is configured as a fiber cable (SAN) using FCP, for example.

  The file controller 100 includes, for example, an MPU (Micro Processing Unit) 110, a memory 120, a front end interface (hereinafter, the interface may be abbreviated as “I / F”) 130, a back end I / F 140, and a memory controller 150. It is prepared for.

  The memory 120 can be composed of, for example, a semiconductor memory such as a ROM or a RAM, and stores various programs executed by the MPU 110. The memory 120 also has a cache area, and this cache area is used for data communication with the host 10 and the block controller 200.

  The front-end I / F 130 performs file-level data communication (file-unit data communication) with the host 10. The back-end I / F 140 performs block-level data communication (block-unit data communication) with the block controller 200. The memory controller 150 controls an internal communication path so that the MPU 110, each front end I / F 130, each back end I / F 140, and the memory 120 are connected to each other.

  Write data received from the host 10 via the front end I / F 130 is temporarily stored in the memory 120. Then, the back-end I / F 140 transmits the write data to the block controller 200 after converting the write destination address of the write data into a logical block address (LBA). Note that the address conversion may be performed in the front end I / F 130 and then stored in the memory 120. Moreover, the structure which MPU110 performs address conversion may be sufficient.

  Block data received from the block controller 200 via the back-end I / F 140 is temporarily stored in the memory 120. Then, the front end I / F 130 converts the logical block address into a file level address, collects it as file data, and transmits this data to the host 10. The conversion from block data to file data may be performed by the back end I / F 140 and then stored in the memory 120. Further, the MPU 210 may perform conversion processing to file data.

  The block controller 200 corresponds to a “controller” or a “second controller”. The block controller 200 is connected to the disk enclosure 300 via the communication path CN3 so as to be capable of bidirectional communication. The communication path CN3 is configured as a fiber cable (SAN) using FCP, similar to CN2.

  The block controller 200 is a computer device that manages data input / output in units of blocks. Similar to the file controller 100, the block controller 200 can include, for example, an MPU 210, a memory 220, a front end I / F 230, a back end I / F 240, and a memory controller 250.

  Various programs executed by the MPU 210 are stored in the memory 220. As with the memory 120, the memory 220 also includes a cache area. This cache area is used for data exchange with the file controller 100 and the disk enclosure 300.

  The front end I / F 230 performs block level data communication with the file controller 100. The back-end I / F 240 performs block-level data communication with the disk drive 310. The memory controller 250 controls an internal communication path so that the MPU 210, each front end I / F 230, each back end I / F 240, and the memory 220 are connected to each other.

  Write data received from the file controller 100 via the front end I / F 230 is temporarily stored in the memory 220. Then, the back-end I / F 240 converts the logical block address of the write data into a physical address of each disk drive 310 and writes it to a predetermined disk drive 310. Data read from the disk drive 310 is converted into a logical block address by the back end I / F 240 and stored in the memory 220. The front end I / F 230 reads the data from the memory 220 and transfers it to the file controller 100.

  The disk enclosure 300 can be expressed as “storage device” or “disk array storage device”, for example. The disk enclosure 300 includes a plurality of disk drives 310 arranged in an array. These disk drives 310 correspond to “storage devices”.

  The disk drive 310 can be configured as various storage devices such as a hard disk drive, a semiconductor memory drive, an optical disk drive, a magneto-optical disk drive, a magnetic tape drive, and the like. In the case of a hard disk drive, for example, various types of hard disk drives such as FC (Fibre Channel) disk, SATA (Serial AT Attachment) disk, and SCSI (Small Computer System Interface) disk can be used. Further, different types of storage devices can be mixed in the disk enclosure 300.

  For example, a group is constituted by a predetermined number of disk drives 310 such as four or eight. This group is called a RAID group or a parity group. Each disk drive 310 participating in the RAID group provides a physical storage area, and an aggregate of these physical storage areas is formed. Thus, a RAID group can also be called a physical storage device. Although different depending on the RAID level, one or a plurality of disk drives 310 among the disk drives 310 participating in the group are used for storing parity data.

  One or a plurality of logical volumes can be set in the physical storage area of the RAID group. The logical volume is assigned to a port of the front end I / F 130 of the file controller 100 and is a target to be accessed by the host 10. A logical volume can be referred to as a logical storage device.

  Before describing the functional configuration of the storage system, the arrangement relationship between the file controller 100 and the block controller 200 will be described with reference to FIGS. As shown in FIG. 3A, the file controller 100 and the block controller 200 are provided in one control housing, the disk enclosure 300 is configured as a separate housing, and these housings are connected by a fiber cable or the like. be able to.

  As shown in FIG. 3B, a file controller 100, a block controller 200, and a disk enclosure 300 may be provided in the same housing. As shown in FIG. 3C, the file controller 100 may be separated from the housing of the storage controller 20, and the file controller 100, the block controller 200, and the disk enclosure 300 may be connected via a network.

  As illustrated in FIG. 4D, the file controller 100 may be separated from the housing of the storage control device 20 and the file controller 100 may be provided in the switch 30. Further, as shown in FIG. 4E, the file controller 100 may be provided in the host 10.

  A functional configuration of the storage system will be described with reference to FIG. The host 10 includes, for example, an application program 410 and a recovery point search interface 420 (hereinafter sometimes abbreviated as a search interface). The application program 410 corresponds to the application program 1A in FIG. Examples of the application program 410 include a database, a customer management program, a document creation program, and the like.

  The search interface 420 corresponds to the recovery point search request issuing unit 1B and the recovery instruction unit 1C in FIG. The search interface 420 can instruct the storage control device 20 to investigate the recovery point, and can specify the selected recovery point and order recovery. The recovery point survey is given to the storage control device 20 as a search request 600. This search request 600 corresponds to the search request D1 in FIG. The recovery point investigation result is transmitted to the host 10 as a recovery point candidate list 700. This candidate list 700 corresponds to the candidate list D2 in FIG.

  The file controller 100 includes, for example, a file R / W processing unit 430, a partial restore processing unit 440, a data search processing unit 450, a journal read function 460, and a temporary restore area 540.

  The file R / W processing unit 430 is for reading and writing file level data in response to an access request from the host 10. The partial restore processing unit 440 restores only the recovery target file indicated by the search request 600 for each update history, and stores the restored file in the temporary restore area 540. The data search processing unit 450 checks whether or not a specific file group temporarily restored meets the search condition in the search request 600. The data search processing unit 450 specifies a period that matches the search condition, and transmits the specified period to the host 10 as the recovery point candidate list 700. The journal read function 460 will be described later.

  The temporary restore area 540 corresponds to a “temporary restore area” and corresponds to the temporary restore area V3 in FIG. This temporary restore area 540 is used to perform a temporary restore of a range designated as a recovery target in the entire range of the user data volume 510. The temporary restore area 540 can be configured as the logical volume described above, or can be provided as a virtual volume in the memory 120 of the file controller 100.

  The block controller 200 can include, for example, a block R / W processing unit 470, a journal creation processing unit 480, a restore processing unit 490, and a journal access function 461. The block R / W processing unit 470 reads and writes block level data. The journal creation processing unit 480 creates and manages journal data when the data stored in the user data volume 510 is updated. Journal data is stored in the journal volume 520. The restore processing unit 490 restores the stored contents of the user data volume 510 up to the recovery point instructed from the search interface 420. The restored storage content is stored in the restore volume 530.

  The journal read function 460 and journal access function 461 are functions provided for the file controller 100 to acquire journal data from the journal volume 520. The journal read function 460 in the file controller 100 can access the journal volume 520 via the journal access function 461 in the block controller 200. The partial restore processing unit 440 acquires predetermined journal data from the journal volume 520 via the journal read function 460 and the journal access function 461, and performs partial restore. The journal read function 460 and the journal access function 461 can be called, for example, “journal data acquisition function (acquisition unit) for the file controller to acquire journal data via the block controller”.

  The disk enclosure 300 includes, for example, a user data volume 510, a journal volume 520, and a restore volume 530. The user data volume 510 corresponds to a “data volume” and corresponds to the user data volume V1 in FIG. The journal volume 520 corresponds to “journal volume” or “update data management volume”, and corresponds to the journal volume V2 in FIG. The restore volume 530 is used to recover the entire user data volume 510 to the recovery point state designated by the user.

  The configuration of the journal volume 520 will be described with reference to FIG. The journal volume 520 is roughly divided into a journal record area 521 and a data area 522. The journal record area 521 is a management area for managing journal data. The data area 522 is an area for storing journal data.

  A configuration example of the journal record area 521 is shown in a table format in FIG. The journal record area 521 is configured by associating, for example, a journal identifier, a recording date and time, a path name, an offset, a size, and a data storage position for each data update of the user data volume 510. The

  The journal identifier is identification information for uniquely specifying a data update within the storage controller 20. The journal identifier has, for example, a serial number, and the number increases by one each time the user data volume 510 is updated. The recording date and time is information indicating the date and time when journal data is stored in the journal volume 520, that is, the date and time when data update to the user data volume 510 is performed.

  The path name is file identification information for specifying the updated file. The path name indicates a path on the file system for reaching the updated file from the root directory (top directory). The offset is address information indicating the position of updated data in the file. The size is update amount information indicating the size of updated data. The data storage position is storage destination address information indicating a position where updated data (data immediately before being updated) is stored in the data area 522.

  FIG. 7 is an explanatory diagram schematically showing a state in which partial restoration is performed using journal data. For convenience of explanation, it is assumed here that “FILE_D” is designated as the recovery target range.

  The partial restore processing unit 440 sequentially examines “path names” of journal records from the beginning to the end of the journal record area 521. When a journal record related to the file name “FILE_D” is found, the data storage position is referred to, data is read from the data area 522 and stored in the temporary restore area 540. The partial restore processing unit 440 arranges the read data at the position of the “offset” address.

  In the example shown in FIG. 7, the data “B” is read from the journal identifier “0011”, the data “O” is read from the journal identifiers “0013” and “0015”, and the data “K” is read from the journal identifier “0016”. And is arranged in the temporary restore area 540 according to the offset address of the file. As a result, the file “FILE_D” having the word “BOOK” is reproduced in the temporary restore area 540.

  Since each journal data has only the data updated for the file, each journal data itself cannot find a meaningful keyword or the like. However, since the partial restore processing unit 440 restores the target file unit designated as the recovery target, a keyword search described later can be performed.

  Further, as described above, the partial restore processing unit 440 partially restores the contents of the user data volume 510 only for files designated as recovery targets. Even when the specified file is related to another file in the user data volume 510, the partial restore processing unit 440 is specified as a recovery target without considering the relationship or dependency between the files. Restore only the desired files.

  As described later, a plurality of recovery target ranges can be specified in the search request 600. Therefore, when there is a relationship between specific files, the user can designate each related file and restore it.

  FIG. 8 is an explanatory diagram schematically showing a configuration example of the search request 600. As shown in FIG. 8A, the search request 600 can include, for example, a recovery target range 610, a recovery target period 620, a search condition 630, and a logical operation condition 640. In addition, search request identification information for identifying each search request 600, a transmission destination address, and the like are provided and transmitted from the host 10 to the storage control device 20.

  Significant values (valid values, character strings) need not be set for all of the pieces of information 610 to 640. It is sufficient that at least meaningful values are set in the recovery target range 610 and the search condition 630. The other information 620 and 640 need only be set to valid values when they are used.

  In the recovery target range 610, a path name for specifying a target file (including a directory) is set. The recovery target period 620 is preferably used in an embodiment described later. When the time condition of the recovery target file can be specified, a value indicating the time is set. In the search condition 630, an arbitrary character string or data selected or input by the user, or a time stamp of a file is set. For the logical operation condition 640, for example, a logical operation expression such as an “AND” condition or an “OR” condition is set.

  As shown in FIG. 8B, a search request 600 can be generated by setting a path name of a file in the recovery target range 610 and setting an arbitrary keyword in the search condition 630. By issuing such a search request 600, it is possible to detect when the target file contains a predetermined keyword.

  As shown in FIG. 8C, a directory path name can be set in the recovery target range 610 and a file name can be set in the search condition 630. By issuing such a search request 600, a lost file that should have existed in a predetermined directory can be detected.

  As shown in FIG. 8D, a plurality of recovery target ranges 610 and search condition 630 pairs and a logical operation condition 640 between these pairs can be set. By issuing such a search request 600, it is possible to detect a period in which files including different keywords satisfy a predetermined logical operation condition.

  As shown in FIG. 8E, a plurality of recovery target ranges 610, recovery target periods 620 and search condition 630 pairs, and logical operation conditions 640 between these pairs may be set. By issuing such a search request 600, as described in FIG. 8D, it is possible to detect a period in which files including different keywords satisfy a predetermined logical condition. In the example shown in FIG. 8E, since the recovery target period 620 is set, the range of partial restore processing by the partial restore processing unit 440 can be narrowed down in time, and partial restore processing can be performed at higher speed. Can do.

  FIG. 9 is an explanatory diagram of a configuration example of the recovery point candidate list 700. As shown in FIG. 9A, the recovery point candidate list (hereinafter may be abbreviated as “candidate list”) 700 includes, for example, a first appearance time 710 and a last appearance time 720. it can.

  The first appearance time 710 indicates the first point (time point) at which the recovery target file satisfies the search condition. The last appearance time 720 indicates a point at which the recovery target file finally satisfies the search condition. For example, if a file created at a certain time Tf is deleted at time Tl, the first appearance time 710 is Tf and the last appearance time 720 is Tl. One initial appearance time 710 and one final appearance time 720 constitute one pair. The pair 710 and 720 indicates a period during which the recovery target file satisfies the search condition.

  As shown in FIG. 9B, the first appearance time 710 and the last appearance time 720 can be expressed in the format of year, month, day, hour, minute and second. By expressing in the format of this year / month / day / hour / minute / second, the user can intuitively understand.

  Instead of this, for example, a value of a counter timer that counts up by a predetermined amount every day may be used. That is, the value of the counter timer in the storage control device 20 can be set in the candidate list 700. Even when the value of the counter timer is used, when it is displayed on the search interface 420, it can be converted into a format such as the year, month, day.

  As shown in FIG. 9C, the candidate list 700 may include a plurality of pairs of the first appearance time 710 and the last appearance time 720. For example, the recovery target file may satisfy the search condition at a certain time, and then the data is updated so that the search condition is not met, and the search condition is satisfied again by subsequent data update. In this case, the candidate list 700 includes all periods in which the recovery target file matches the search condition.

  In this way, the candidate list 700 specifies the start time (first appearance time 710) and the end time (final appearance time 720) that the recovery target file satisfies the search condition from the first appearance time 710 and the last appearance time 720, The period that matches the search condition is expressed. As a result, it is possible to specify a period that matches the search condition with a relatively small amount of data. However, the present invention is not limited to this, and a configuration may be adopted in which all points whose recovery target files match the search condition are included in the candidate list 700. For example, if a certain file has a time T1, T2, T3, T4, T5,. . . If the search condition is satisfied at times T1, T2, and T3, all of these times T1, T2, and T3 can be included in the candidate list 700. In the example shown in FIG. 9, only T1 and T3 are included in the candidate list 700.

  FIG. 10 is an explanatory diagram showing an example of a user interface provided to the user by the recovery point search interface 420. FIG. 10A shows a screen G10 for issuing a recovery point search request 600. FIG. This screen G10 can be called, for example, a “recovery point search condition designation screen” or a “recovery point search request issue screen”.

  The search condition designation screen G10 includes, for example, a recovery target range designation unit G11, a recovery target period designation unit G12, a search condition designation unit G13, a logical operation condition designation unit G14, a search execution button B11, and a cancel button B12. Can be included.

  The recovery target range specifying unit G11 is used for specifying a file that the user desires to recover. In the designation part G11, for example, each directory under the top directory is displayed in a so-called pull-down menu format, and a desired file can be selected.

  The recovery target period designating unit G12 is for designating the time to restore the recovery target file. In this designation part G11, the time range to be investigated can be selected in a pull-down menu format.

  The search condition designating part G13 designates a keyword and a file name that the recovery target file should have. The user can input an arbitrary character string (alphanumeric characters, symbols, etc.). The user can specify all or part of the data of the selected file as a search condition by selecting the file name in the pull-down menu format. By specifying the file data itself as a search condition, a recovery point before infection can be searched for a file infected with a computer virus, as in an embodiment described later.

  The logical operation condition designating part G14 is for designating logical operation conditions such as AND and OR. The search execution button B11 is for issuing a search request 600 in which the values specified in G11 to G14 are set. The cancel button B12 is for canceling the issuance of the search request 600.

  FIG. 10B shows a screen G20 for displaying a recovery point search result (survey result). The search result screen G20 is generated based on the recovery point candidate list 700 transmitted from the storage control device 20 to the host 10.

  The search result screen G20 includes, for example, a recovery target range display unit G21, a search condition display unit G22, an initial appearance time display unit G23, a final appearance time G24, a recovery point specification unit G25, a recovery execution button B21, and a cancel button. A button B22 can be provided.

  The recovery target range display unit G21 displays the file name specified by the recovery target range specification unit G11. The search condition display part G22 displays the search conditions specified by the search condition specifying part G13 described above. When the recovery target period and the logical operation conditions are also specified on the screen G10, how the recovery target period and the logical operation conditions are specified can be displayed on the screen G20.

  The first appearance time display unit G23 displays the value set at the first appearance time 710 in the candidate list 700. Similarly, the last appearance time display unit G24 displays the value set at the last appearance time 720 in the candidate list 700.

  The recovery point designation unit G25 is for designating a recovery point desired by the user. For example, the user can select any one desired recovery point from a plurality of recovery point candidates displayed in a pull-down menu format.

  The recovery execution button B21 is a button for restoring the stored contents of the user data volume 510 up to the recovery point designated by the user. The cancel button B22 is a button for canceling execution of restoration. Note that the screen shown in FIG. 10 and the description thereof are merely examples, and the present invention is not limited to the above configuration.

  Next, the operation of the storage system will be described with reference to FIGS. Each flowchart described below shows an outline of processing, and is different from an actual computer program. In the description of the flowchart, the step is abbreviated as “S”.

  FIG. 11 is a flowchart showing command processing for the storage controller 20 to process an access request from the host 10. For example, the host 10 can request update of data using a write command (write request) or can request data read using a read command (read request). As described above, the command processing is performed by the cooperative operation of the file controller 100 and the block controller 200. Here, for convenience of explanation, the storage control device 20 will be described as the subject of the processing.

  When the storage controller 20 receives a command from the host 10, it determines the type of the command (S11). If the received command is a read command, it is determined whether or not the data requested by the host 10 is stored in a cache area of the memory (hereinafter also referred to as a cache memory) (S12).

  When the data requested from the host 10 is stored in the cache memory (S12: YES), the storage control device 20 reads the data from the cache memory and transmits it to the host 10 (S15). When the data requested from the host 10 is not stored in the cache memory (S12: NO), the storage controller 20 reads the data requested from the host 10 from the disk drive 310 (S13). The storage control device 20 stores the read data in the cache memory (S14), and then transmits it to the host 10 (S15).

  When a write command is received from the host 10, the storage controller 20 secures an area for storing write data in the cache memory, and stores the write data in this secured area (S16). After storing the write data in the cache memory, the storage controller 20 notifies the host 10 that the processing of the write command has been completed (S17).

  The storage controller 20 generates journal data based on the data update by the write command (S18), and stores the generated journal data in the journal volume 520 (S19). That is, every time the host 10 updates the stored contents of the user data volume 510, journal data is generated and saved.

  The storage controller 20 stores the write data stored in the cache memory in the predetermined disk drive 310 at an appropriate timing (S20). The predetermined disk drive 310 is a disk drive having a storage area corresponding to an address specified by a write command.

  After the write data is stored in the cache memory, before the write data is written to the disk drive 310, the response performance of the storage control device 20 can be improved by notifying the host 10 of the completion of the write command processing. it can. However, the present invention is not limited to this, and a configuration may be adopted in which after the write data is stored in the disk drive 310, the host 10 is notified of the completion of the write command processing.

  If the command received from the host 10 is neither a write command nor a read command, the storage control device 20 performs processing according to the command (S21). Examples of other commands include an inquiry command for inquiring the state of the storage control device 20.

  FIG. 12 is a flowchart showing a process for searching for a recovery point. The storage controller 20 determines whether or not a recovery point search request 600 has been issued from the host 10 (S31). When a search request 600 is issued (S31: YES), the storage control device 20 secures a temporary restore area 540 for each recovery target file specified in the search request 600, and temporarily restores one for each file. 540 is assigned (S32).

  Next, the storage controller 20 initializes the recovery point list (S33). The recovery point list is a temporary work file for detecting the first appearance time and the last appearance time. One recovery point list is prepared for each temporary restore area 540.

  The storage controller 20 repeats the following processing in order from the beginning to the end of each journal record in the journal record area 521 described in FIG. 6 (S34, S39). The storage controller 20 compares the file name (path name) recorded in this journal record with the file name (path name) specified in the search request 600 for one journal record read from the journal record area 521. (S35).

  If both file names match (S35: YES), the journal data managed by the journal record is read from the data area 522 and stored in the temporary restore area 540 (S36).

  The storage controller 20 determines whether or not the files restored in the temporary restore area 540 meet the search conditions specified in the search request 600 (S37). If the search condition is met (S37: YES), the storage control device 20 stores the update time (recording date and time in the journal record) of the temporarily restored file in the recovery point list (S38). The process for updating the recovery point list will be described later.

  In this way, the storage control device 20 checks whether or not the search condition is met while restoring only the recovery target file. In addition, it is good also as a structure which test | inspects whether it matches search conditions after restoring all the files of recovery object.

  After completing the restore process and the search process for all journal records related to the recovery target file, the storage controller 20 transmits the recorded contents of the recovery point list to the host 10 as a candidate list 700 (S40).

  FIG. 13 is a flowchart showing the recovery point list update process shown in S38 in FIG. When the storage control device 20 finds a file that matches the search condition, the storage control device 20 determines whether or not the update time (that is, the recovery point) of this file appears for the first time (S381). When the update time is the first appearance time (S381: YES), the storage control device 20 records the update time as the first appearance time in the recovery point list (S382). On the other hand, if the update time is not the first appearance time (S381: NO), the storage control device 20 records the update time as the last appearance time in the recovery point list (S383). The last appearance time of the recovery point list is updated each time a new update time is discovered.

  Since the present embodiment is configured as described above, the following effects can be obtained. In this embodiment, the host 10 is provided with a recovery point search interface 420 for issuing a search request 600. Then, the storage controller 20 includes a journal creation processing unit 480 for managing the update history of the user data volume 510, and a recovery target among all files stored in the user data volume 510 based on the search request 600. A partial restore processing unit 440 that restores only the files for each update history and stores them in the temporary restore area 540, determines whether the files restored in the temporary restore area 540 meet the search conditions, and A data search processing unit 450 is provided for notifying the host 10 of a period matching the above as the recovery point candidate list 700. Therefore, in this embodiment, a recovery point candidate can be presented to a user whose point to be recovered is unknown, and the usability can be improved by supporting selection of an appropriate recovery point.

  In this embodiment, the recovery of the user data volume 510 can be requested based on the recovery point candidate list 700. Accordingly, the user can restore the stored contents of the user data volume 510 to a desired point in time with a relatively simple operation, and the usability is improved.

  In the present embodiment, the first appearance time 710 and the last appearance time 720 are used to specify a period during which the recovery target file matches the search condition. Therefore, even when the frequency of data update for the recovery target file is high, the data amount of the recovery point candidate list 700 can be reduced.

  A second embodiment will be described with reference to FIGS. Each embodiment described below corresponds to a modification of the first embodiment. In this embodiment, the hash value of a file is adopted as information for specifying a file instead of a path name.

  FIG. 14 is an explanatory diagram showing the structure of a journal record. In this embodiment, instead of the path name of the file, a combination of a file name (the name of the file that appears at the end of the path itself) and a hash value is used. The file hash value is obtained, for example, by inputting a file path name to the hash function 523. A simple file name can also be referred to in case that different files accidentally have the same file hash value.

  FIG. 15 is a flowchart showing the recovery point search process according to this embodiment. This flowchart includes steps common to the flowchart described in FIG. Therefore, omitting the description of the common steps and focusing on the steps characteristic of this embodiment, in this embodiment, the file hash value recorded in the journal record and the file specified as the recovery target are obtained. Are compared with each other to determine whether or not they match (S35A).

  This embodiment configured as described above can obtain the same effects as those of the first embodiment described above. In addition to this, in this embodiment, since a file hash value is used as information for specifying a file, data compared to the case where a path name (so-called full path) from the top directory to the target file is used. The amount can be reduced. Thereby, the data size of the journal record can be reduced, and the journal data can be managed more efficiently.

  A third embodiment will be described with reference to FIGS. In this embodiment, the file controller 100 and the block controller 200 are integrated into a single controller 101.

  FIG. 16 is an explanatory diagram of a hardware configuration of the storage system according to this embodiment. The storage control device 20A of this embodiment includes a single controller 101. The controller 101 realizes the functions of the file controller 100 and the block controller 200 described above, and can be called, for example, an “integrated controller”.

  Similar to the file controller 100, the controller 101 includes an MPU 111, a memory 121, a front end I / F 131, a back end I / F 141, and a memory controller 151. These units are substantially the same as the units 110 to 150 described in the file controller 100.

  However, the controller 101 performs file level data communication with the host 10 and performs block level data communication with the disk enclosure 300. For this reason, the back-end I / F 141 has a function of performing mutual conversion between a logical block address and a physical address.

  FIG. 17 is an explanatory diagram showing the functional configuration of the storage system according to this embodiment. Since the storage controller 20A of this embodiment includes a single controller 101, the processing units 430, 440, 450, 470, 480, and 490 described in the first embodiment are provided in the controller 101. .

  In this embodiment, since a single controller 101 is used, the functions 460 and 461 for the file controller 100 to acquire journal data via the block controller 200 as in the first embodiment are not necessary.

  Also in this embodiment configured as described above, the same operational effects as those of the first embodiment can be obtained. In addition to this, since the single controller 101 is used in this embodiment, the number of parts can be reduced, and the storage controller 20A can be downsized.

  A fourth embodiment will be described with reference to FIGS. In this embodiment, recovery target data can be specified at the block level.

  FIG. 18 is an explanatory diagram showing the structure of a journal record. In the present embodiment, in order to manage journal data in units of blocks, journal data is specified by LUN (Logical Unit Number), logical block address (LBA) indicating an offset, and size. That is, the LUN is information for specifying the user data volume 510, and the LBA indicates an offset value from the head address of the volume.

  FIG. 19 is an explanatory diagram showing a configuration example of the search request 600. In this embodiment, the recovery target range 610 is configured by a LUN 611, an LBA 612 indicating an offset, and a data size 613. Thereby, it is possible to restore only a specific block in the user data volume 510 and check whether or not the search condition is met.

  This embodiment, which is configured in this way, also has the same operational effects as the first embodiment. In addition to this, in this embodiment, a recovery target range can be specified at the block level. By combining the present embodiment and the first embodiment, it is possible to obtain a configuration in which the recovery target range can be specified at either the file level or the block level.

  A fifth embodiment will be described with reference to FIGS. In this embodiment, a snapshot 550 of the user data volume 510 is created at predetermined intervals, and the user can specify a recovery target period by using the snapshot 550 and the journal volume 520.

  The block controller 200 includes a snapshot creation processing unit 481. The snapshot creation processing unit 481 creates a storage image of the user data volume 510 at the time when creation of a snapshot is instructed. This stored image is stored as a snapshot 550. The snapshot 550 can be created at predetermined intervals set in advance, for example, every day or every week. The snapshot 550 can be created at any time designated by the user.

  FIG. 21 is a flowchart showing the recovery point search process according to this embodiment. Similar to the previous embodiment, the description will focus on the features that are characteristic of this embodiment. It is assumed that a valid value is set in the recovery target period 620 in the search request 600.

  After initializing the recovery point list (S33), the storage controller identifies the snapshot 550 corresponding to the recovery target period designated by the user, and detects a journal record group within the recovery target period (S50). In the following, the process proceeds in the same manner as in the first embodiment.

  This embodiment, which is configured in this way, also obtains the same operational effects as the first embodiment. In addition to this, in this embodiment, it is possible to specify a period during which a recovery target file is restored by combining the snapshot 550 and the journal volume 520 that are created regularly or irregularly. Thus, the partial restore processing unit 440 and the data search processing unit 450 need only target fewer journal records, and can detect recovery point candidates earlier.

  A sixth embodiment will be described with reference to FIG. In this embodiment, the recovery target file stored in the temporary restore area 540 can be used by the host 10. FIG. 22 is a flowchart showing the recovery point search process.

  After transmitting the recovery point list to the host 10 (S40), the storage controller 20 transmits the data (file data or block data) in the temporary restore area 540 to the host 10 (S60). Therefore, the user can refer to the recovery target data before recovering the entire user data volume 510 to a desired recovery point.

  Configuring this embodiment like this also achieves the same effects as the first embodiment. In addition, in this embodiment, the data in the temporary restore area 540 can be confirmed without restoring the entire user data volume 510. Therefore, for example, when the user only wants to refer to the recovery target data, the user uses the target data without waiting for the entire restoration of the user data volume 510 to be completed. It is possible to improve usability. Instead of the configuration in which the data in the temporary restore area 540 is transmitted from the storage control device 20 to the host 10, the configuration in which the data in the temporary restore area 540 can be accessed from the host 10 may be used. For example, the temporary restore area 540 configured as a virtual volume on the memory may be temporarily mounted on the host 10 and used exclusively for reference.

  A seventh embodiment will be described with reference to FIG. In the following embodiments including this embodiment, a specific application example of the first embodiment is shown. In this embodiment, when a user's file is infected with a computer virus (hereinafter “virus”), the file is restored to the state before the infection.

  FIG. 23 is a flowchart showing the main part of the overall operation of the storage system. The security management program installed in the host 10 checks whether or not a file group used by the host 10 is infected with a virus (S100). Since this inspection method is known and is not the subject of the present invention, its detailed description is omitted.

  If the file is infected with a virus, the security management program issues a warning to the host 10 specifying the name of the file infected with the virus (S101). Upon receiving this warning, the host 10 recognizes the presence of a file infected with a virus (S102).

  In the search interface 420 provided in the host 10, the path name of the infected file is specified by the user in the recovery target range (S103), and the data of the file infected by the virus is specified in the search condition (S103). S104).

  The host 10 issues a search request 600 that clearly indicates the path name of the infected file and the infected data (S105). As described in the first embodiment, the storage controller 20 restores only the range designated as the recovery target (S106), and determines whether or not the restored file matches the search condition. (S107). Here, since file data itself infected with a virus is set as a search condition, a file that matches the search condition means a file infected with a virus.

  The storage controller 20 creates a recovery point list (S108), and transmits the recovery point candidate list 700 to the host 10 (S109). The host 10 displays recovery point candidates based on the candidate list 700 (S110). Note that the recovery point list can be called both without distinguishing between the recovery point candidate list 700 and the recovery point list.

  In the host 10, the user selects a time before the first appearance time as a recovery point (S111). If the time is earlier than the first appearance time, the target file is not infected with a virus. Therefore, the host 10 designates a recovery point before the first appearance time, and requests restoration (recovery) of the user data volume 510 (S112).

  The storage controller 20 restores the stored contents of the user data volume 510 up to the designated recovery point (S113), and sets a path between the restore volume 530 and the host 10 (S114). Then, the storage control device 20 notifies the user that the recovery is completed (S115). Thereby, the user can use the file in the state before the virus infection (S116).

  The eighth embodiment will be described with reference to FIG. FIG. 24 is a flowchart showing the overall operation when restoring a file that has been lost due to a user's erroneous operation or the like. The user notices that the target file is missing from the file tree. It is assumed that the user has an idea of only the directory name where the target file should exist.

  In order to use the target file, the user requests the file management program to list a predetermined directory where the target file should exist (S120). The file management program causes the entry in the specified directory to be displayed on the user interface 14 of the host 10 (S121).

  The host (user) 10 recognizes that the target file is not found in the predetermined directory (S122). Therefore, the host 10 sets the path name of a predetermined directory in the recovery target range and the file name of the lost file as a search condition (S123, S124), and issues a search request 600 (S125).

  Here, the file name set in the search condition is not a path name of the lost file but a simple file name. Further, it is preferable that the entire simple file name can be specified completely, but only a part of the simple file name may be specified.

  The storage control device 20 restores only the file group included in the specified directory (S126), and checks whether the search condition is met (S127). Then, the storage controller 20 creates a recovery point list (S128), and transmits the recovery point candidate list 700 to the host 10 (S129).

  The host 10 displays the recovery point candidates (recovery point list) on the user interface 14 (S130). The user selects the last appearance time among the displayed recovery points (S131), and requests the restoration of the user data volume 510 (S132). The file that the user desires last exists because it is the last appearance time and is lost immediately after that.

  The storage controller 20 restores the storage contents of the user data volume 510 to the designated recovery point (S133), and sets a path between the restore volume 530 and the host 10 (S134). The storage controller 20 notifies the host 10 that the restoration has been completed (S135). Thereby, the user can use the file before disappearance (S136).

  A ninth embodiment will be described with reference to FIG. FIG. 25 is a flowchart showing the overall operation when detecting unauthorized access to the host 10. The host 10 uses one or a plurality of security related files. Examples of the security-related file include an authentication information file in which user authentication information (user ID and password) is recorded, an access control list for managing access authority to the file, and the like. These security-related files are not updated in a normal case, and are only referred to as needed by a user having administrator authority.

  When auditing unauthorized access to the host 10, the user sets the file name (path name) of the security-related file in the recovery target range (S140), and sets the file update time in the search condition (S141). The reason for designating the file update time is to discover whether or not the security related file has been updated. If there is a person who illegally accesses the host 10, the person rewrites a part of the security-related file in order to hide the trace of unauthorized access.

  When the host 10 issues a search request 600, the storage controller 20 restores only the designated security-related file (S143), and checks whether the security-related file has been updated (S144). Then, the storage controller 20 creates a recovery point list (S145), and transmits the recovery point candidate list 700 to the host 10 (S146).

  The host 10 displays the detected recovery point on the user interface 14 (S147). The host (user) 10 determines whether or not the update time of the security-related file is updated in an unnatural time zone (S148). For example, when the security-related file is updated in a time zone when the system administrator is absent (S148: YES), there is a possibility that the host 10 has been illegally accessed. Therefore, the host 10 performs a more detailed security audit using another program (S149).

  In addition, this invention is not limited to each Example mentioned above. A person skilled in the art can make various additions and changes within the scope of the present invention.

It is explanatory drawing which shows the outline | summary of embodiment of this invention. It is explanatory drawing which shows the hardware constitutions of a storage system. It is explanatory drawing which shows the modification of the arrangement | positioning method of a file controller. It is explanatory drawing which shows the modification of another arrangement | positioning method of a file controller. It is explanatory drawing which shows the function structure of a storage system. It is explanatory drawing which shows the structure of a journal volume and a journal record. It is explanatory drawing which shows typically a mode that only the designated file is restored. It is explanatory drawing which shows the structure of a recovery point search request. It is explanatory drawing which shows the structure of a recovery point candidate list. It is explanatory drawing which shows the issuance screen (a) of a recovery point search request, and the display screen (b) of a recovery point candidate list. It is a flowchart which shows command processing. It is a flowchart which shows a recovery point search process. It is a flowchart which shows the recovery point list update process in FIG. It is explanatory drawing which shows the structure of the journal record used by the storage control apparatus which concerns on 2nd Example. It is a flowchart which shows a recovery point search process. It is explanatory drawing which shows the hardware constitutions of the storage system which concerns on 3rd Example. It is explanatory drawing which shows the function structure of a storage system. It is explanatory drawing which shows the structure of the journal record used by the storage control apparatus based on 4th Example. It is explanatory drawing which shows the structure of a recovery point search request. It is explanatory drawing which shows the function structure of the storage system which concerns on 5th Example. It is a flowchart which shows a recovery point search process. It is a flowchart which shows the recovery point search process performed by the storage control apparatus which concerns on 6th Example. It is a flowchart which shows the application example of this embodiment. It is a flowchart which shows another application example of this embodiment. It is a flowchart which shows another example of application of this embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Host, 1A ... Application program, 1B ... Recovery point search request issuing part, 1C ... Recovery instruction part, 2 ... Storage control apparatus, 2A ... Read / write processing part, 2B ... Journal creation processing part, 2C ... Partial restoration process , 2D ... search processing unit, 2E ... restore processing unit, V1 ... user data volume, V2 ... journal volume, V3 ... temporary restore area, V4 ... restore volume, 10 ... host, 11 ... CPU, 12 ... memory, 13 ... Communication interface, 14 ... User interface, 20, 20A ... Storage controller, 30 ... Switch, 100 ... File controller, 101 ... Controller, 110, 111,210 ... MPU, 120, 121,220 ... Memory, 130,131, 230 ... Front-end interface, 1 0, 141, 240 ... back-end interface, 150, 151, 250 ... memory controller, 200 ... block controller, 300 ... disk enclosure, 310 ... disk drive, 410 ... application program, 420 ... recovery point search interface, 430 ... file Read / write processing unit, 440 ... partial restore processing unit, 450 ... data search processing unit, 460 ... journal read function, 461 ... journal access function, 470 ... block read / write processing unit, 480 ... journal creation processing unit, 481 ... Snapshot creation processing unit, 490 ... restore processing unit, 510 ... user data volume, 520 ... journal volume, 521 ... journal record area, 522 ... data area, 5 3 ... hash function 530 ... volume for restoring, 540 ... temporary restoring area 550 ... snapshot, 600 ... recovery point retrieval request, 700 ... recovery point candidate list

Claims (6)

A storage system comprising a host computer and a storage control device for providing a data volume to the host computer,
The host computer
A search request issuing unit for issuing a search request specifying at least a path name for specifying a file to be restored and a predetermined keyword as a search condition;
The storage control device
An update history management unit for managing an update history of the data volume;
A first restoration unit that, when receiving the search request, restores the data of the restoration target file among the data stored in the data volume for each update history and stores it in the temporary restoration area. When,
It is determined whether or not the data restored in the temporary restoration area matches the search condition, and a period in which the restored data continuously matches the search condition is detected in the host computer. A search unit that notifies the host computer of a start time when the data restored in the temporary restoration area first matches the search condition and an end time that last matches the search condition as the period; A search section ;
Equipped with a,
The host computer designates a predetermined time point included in the period notified from the search unit, and issues a restoration request to restore the storage contents of the data volume to the state at the predetermined time point Further comprising
The storage control device further includes a second restoration unit that restores the storage content of the data volume to the state at the predetermined time by using the update history when the restoration request is received.
Storage system. The update history management unit manages the storage contents of the data volume for each of a plurality of designated generations,
When the search request includes a restoration target period, the first restoration unit restores the data of the restoration target file within the restoration target period of the data volume for each update history. The storage system according to claim 1, wherein the storage system is stored in the temporary restoration area.   The storage system according to claim 1, wherein the host computer can access the data restored in the temporary restoration area.   The storage system according to claim 1, wherein the storage control device can transmit the data restored in the temporary restoration area to the host computer.   The search unit, when detecting a plurality of periods in which the data restored in the temporary restoration area continuously matches the search condition, notifies all of the plurality of periods to the host computer. The described storage system. In the case where a plurality of path names specifying the restoration target file are specified in the search request, the first restoration unit prepares the temporary restoration area for each of the plurality of restoration target files , The storage system according to claim 1, wherein the data of the plurality of restoration target files is restored.

Images