WO2013061388A1 - 情報処理システム、及び、それを用いたファイル復元方法 - Google Patents

情報処理システム、及び、それを用いたファイル復元方法 Download PDF

Info

Publication number
WO2013061388A1
WO2013061388A1 PCT/JP2011/006072 JP2011006072W WO2013061388A1 WO 2013061388 A1 WO2013061388 A1 WO 2013061388A1 JP 2011006072 W JP2011006072 W JP 2011006072W WO 2013061388 A1 WO2013061388 A1 WO 2013061388A1
Authority
WO
WIPO (PCT)
Prior art keywords
server device
file
directory
storage device
metadata
Prior art date
Application number
PCT/JP2011/006072
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 PCT/JP2011/006072 priority Critical patent/WO2013061388A1/ja
Priority to CN201180074094.1A priority patent/CN103858109B/zh
Priority to IN3375DEN2014 priority patent/IN2014DN03375A/en
Priority to EP11874819.3A priority patent/EP2772863B1/en
Priority to JP2013540516A priority patent/JP5706966B2/ja
Priority to US13/388,193 priority patent/US20130110790A1/en
Publication of WO2013061388A1 publication Critical patent/WO2013061388A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2069—Management of state, configuration or failover
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/185—Hierarchical storage management [HSM] systems, e.g. file migration or policies thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2071—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring using a plurality of controllers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2082—Data synchronisation

Definitions

  • the present invention relates to an information processing system having a file restoration function.
  • Patent Document 1 describes an i including file attribute information in a hierarchical storage device operating on an operating system in order to reduce the time required for recovery of the hierarchical storage device and to perform high-speed recovery of the hierarchical storage device.
  • the i-node number included in the backup data is used to restore the i of the recovery target file.
  • the node number and assign the specified i-node number to the file to be recovered in the file system It has been described.
  • Patent Document 2 in order to efficiently manage name space backup generation in the HSM, in the HSM control method for controlling the HSM having the primary storage and the secondary storage, the generation of the backup is provided for each backup of the HSM.
  • Generation information which is information including a number is created, and information on the name space is valid using the name space information which is information on the name space for each file in the HSM and the generation number created in the generation information creation step. It describes that a valid generation number range indicating a generation number range is managed as a name space information history.
  • a file using the information processing device is used.
  • a user accessing the system deletes a file by mistake, it is desirable to restore the deleted file by the user's operation.
  • Patent Literature 1 After all of the backup data on the backup device side is restored to the information processing device, the service of the information processing device is resumed. Therefore, for example, when the size of backup data is large, it takes a long time to complete the restoration of the file that the user wants to acquire, and the file system capacity of the information processing apparatus is excessively consumed, and the user's work In some cases, this could have an impact.
  • Patent Document 2 a list for managing the generations of all files of the information processing apparatus is searched to specify a restoration target. Therefore, for example, if there are a large number of files on the file system or if the number of file changes is large, the size of the list increases, and it takes a long time to complete the restoration of the file that the user wants to acquire, and In some cases, the file system capacity of the information processing apparatus is excessively consumed, which affects the user's business.
  • the present invention has been made in view of such a background, and provides a file restoration method in an information processing system and an information processing system capable of quickly restoring a file with a small amount of file system consumption when a user requests a file access
  • the main purpose is to do.
  • the present invention provides a first server device that has a first file system and receives an I / O request from a client device, a first storage device that constitutes storage of the first server device, A second server device that has a second file system and is communicably connected to the first server device; and a second storage device that constitutes storage of the second server device, the first server device Transmits the data of the file that is the target of the I / O request stored in the first storage device to the second server device, The second server device stores the data sent from the first server device in the second storage device while holding the directory image in the first file system in the second file system.
  • the second server device stores, in the second storage device, a first directory image of a predetermined hierarchy among directory images configured in the file system of the first server device.
  • the first directory device is restored to the first storage device after the first directory image sent from the second server device is restored to the first storage device.
  • Accept an I / O request for the file to be processed from the client device Determining whether the second directory image necessary for processing the received I / O request exists in the first directory image of the first storage device, and the second directory image exists. If not, the second server device requests the second server device, and the second server device receives the second directory image from the first storage device when the request is sent from the first server device.
  • the first server device reads the data from the device and transmits it to the first server device.
  • the first server device restores the second directory image to the first storage device, and the first server device receives the first directory image and the first server device.
  • a target directory image including two directory images and the file;
  • the second file system of the second server device manages the created or updated file system object with a different version ID, and the first server device
  • the version ID is used in the process of restoring the target directory.
  • FIG. 1 It is a figure showing a schematic structure of information processing system 1 in a first embodiment. It is an example of the hardware of the client apparatus 2 in 1st embodiment. It is an example of the hardware of the information processing apparatus which can be utilized as 1st server apparatus 3a or 2nd server apparatus 3b in 1st embodiment. It is an example of the hardware of the 1st storage apparatus 10a or the 2nd storage apparatus 10b in 1st embodiment. It is an example of the hardware of the channel board
  • FIG. 12 is a flowchart illustrating details of metadata access processing S2900 in the first embodiment. It is a flowchart explaining the detail of stubbed file entity reference process S3000 in 1st embodiment. It is a flowchart explaining the detail of stubbed file entity update process S3100 in 1st embodiment. It is a flowchart explaining the detail of directory image creation process S3200 in 1st embodiment. It is a flow chart explaining details of on-demand restoration processing S3300 in a first embodiment. It is a flow chart explaining details of on-demand restoration processing S3300 in a first embodiment. It is a flowchart explaining the detail of directory image deletion process S3500 in 1st embodiment. It is a flowchart explaining the detail of the directory image creation process S3200 in 2nd embodiment. It is a flow chart explaining details of on-demand restoration processing S3300 in a second embodiment.
  • FIG. 1 shows a schematic configuration of an information processing system 1 described as an embodiment.
  • an information processing system 1 exemplified as the present embodiment is a base where a user actually conducts business (hereinafter referred to as an edge 50 (hereinafter referred to as an edge 50)), such as a fulcrum or a business office in a company such as a trading company or an electrical manufacturer. Edge)) and a base (hereinafter referred to as Core 51) that manages information processing systems (application servers / storage systems, etc.) and provides cloud services, such as a data center. Hardware provided in the above.
  • the edge 50 is provided with a first server device 3a, a first storage device 10a, and a client device 2.
  • the core 51 is provided with a second server device 3b and a second storage device 10b.
  • the first server device 3a provided at the edge is, for example, a file storage device provided with a file system that provides a data management function in units of files to the client device 2 provided at the edge.
  • the second server device 3b provided in the core is, for example, an archive device that functions as a data archive (archive) destination for the first storage device 10a provided at the edge.
  • the client device 2 and the first server device 3a are communicably connected via a communication network 5.
  • the first server device 3a and the first storage device 10a are communicably connected via the first storage network 6a.
  • the second server device 3b and the second storage device 10b are communicably connected via the second storage network 6b.
  • the first server device 3a and the second server device 3b are communicably connected via the communication network 7.
  • the communication network 5 and the communication network 7 are, for example, a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, a public communication network, a dedicated line, and the like.
  • the first storage network 6a and the second storage network 6b are, for example, a LAN, a WAN, a SAN (Storage Area Network), the Internet, a public communication network, a dedicated line, or the like.
  • Communication performed via the communication network 5, the communication network 7, the first storage network 6a, and the second storage network 6b is, for example, TCP / IP, iSCSI (internet Small Computer System Interface), Fiber Channel Protocol (Fibre Channel Protocol). ), FICON (Fibre Connection) (registered trademark), ESCON (Enterprise System Connection) (registered trademark), ACONARC (Advanced Connection Architecture) (registered trademark), FIBARC (Fibre Connection Architecture) (registered trademark), etc. .
  • the client device 2 is an information processing device (computer) that uses a storage area provided by the first storage device 10a via the first server device 3a, and is, for example, a personal computer or an office computer.
  • the client device 2 functions as a file system, an operating system (Operating System) realized by software modules such as a kernel and a driver, and an application.
  • an operating system Operating System
  • FIG. 2 shows the hardware of the client device 2.
  • the client apparatus 2 includes a CPU 21, a volatile or non-volatile memory 22 (RAM or ROM), a storage device 23 (for example, a hard disk drive, a semiconductor storage device (SSD (Solid State Drive))), a keyboard.
  • an input device 24 such as a mouse
  • an output device 25 such as a liquid crystal monitor or a printer
  • a communication interface hereinafter referred to as a communication I / F 26
  • NIC Network Interface Card
  • the first server device 3a is an information processing device that provides an information processing service to the client device 2 using a storage area provided by the first storage device 10a.
  • the first server device 3a is configured using a personal computer, a mainframe, an office computer, or the like.
  • the first server device 3a is abbreviated as a data frame including a data I / O request (data write request, data read request, etc.).
  • the frame is, for example, a fiber channel frame (FC frame (FC)).
  • the second server device 3b is an information processing device that performs information processing using a storage area provided by the second storage device 10b.
  • the second server device 3b is configured using a personal computer, mainframe, office computer, or the like.
  • the second server device 3b transmits a frame including a data I / O request to the second storage device 10b via the second storage network 6b.
  • FIG. 3 shows the hardware of the first server device 3a.
  • the first server device 3a includes a CPU 31, a volatile or nonvolatile memory 32 (RAM or ROM), a storage device 33 (for example, a hard disk drive, a semiconductor storage device (SSD)), a keyboard, a mouse, and the like.
  • a time measuring device 37 configured using a timer circuit, an RTC, or the like.
  • the second server device 3b existing on the core side also has the same or similar hardware configuration as the first server device 3a.
  • FIG. 4 shows the hardware of the first storage device 10a.
  • the first storage device 10a is, for example, a disk array device.
  • the second storage device 10b existing on the core side also has the same or similar hardware configuration as the first storage device 10a.
  • the storage device 10 accepts a data I / O request sent from the server device 3 (the first server device 3a or the second server device 3b, and so on), and stores it in a recording medium in accordance with the accepted data I / O request. Access and send data and response to the server device 3.
  • the storage apparatus 10 includes one or more channel boards 11, one or more processor boards 12 (Micro Processor), one or more drive boards 13, a cache memory 14 (Cache Memory), and a shared memory. 15 (Shared Memory), an internal switch 16, a storage device 17, and a maintenance device 18 (SVP: SerVice Processor).
  • the channel board 11, the processor board 12, the drive board 13, the cache memory 14, and the shared memory 15 are connected to each other via an internal switch 16 so as to communicate with each other.
  • the channel board 11 receives the frame sent from the server device 3, and responds to the processing for the data I / O request included in the received frame (for example, read data, read completion report, write completion report). Is transmitted to the server device 3.
  • the processor board 12 performs data transfer (DMA (Direct (DMA) (Direct Transfer)) between the channel board 11, the drive board 13, and the cache memory 14. High-speed and large-capacity data transfer using Memory (Access) etc.).
  • the processor board 12 transfers (transfers) data (data read from the storage device 17 and data written to the storage device 17) between the channel board 11 and the drive board 13 via the cache memory 14, and cache Staging of data stored in the memory 14 (reading of data from the storage device 17) and destaging (writing to the storage device 17) are performed.
  • DMA Direct (DMA) (Direct Transfer)
  • the processor board 12 transfers (transfers) data (data read from the storage device 17 and data written to the storage device 17) between the channel board 11 and the drive board 13 via the cache memory 14, and cache Staging of data stored in the memory 14 (reading of data from the storage device 17) and destaging (writing to the storage device 17) are performed.
  • the cache memory 14 is configured using a RAM (Random Access Memory) that can be accessed at high speed.
  • the cache memory 14 stores data written to the storage device 17 (hereinafter referred to as write data), data read from the storage device 17 (hereinafter referred to as read data), and the like.
  • the shared memory 15 stores various information used for controlling the storage apparatus 10.
  • the drive board 13 communicates with the storage device 17 when reading data from the storage device 17 or writing data to the storage device 17.
  • the internal switch 16 is configured using, for example, a high-speed crossbar switch (Cross Bar Switch). Note that communication performed via the internal switch 16 is performed according to a protocol such as Fiber Channel, iSCSI, TCP / IP, or the like.
  • the storage device 17 includes a plurality of storage drives 171.
  • the storage drive 171 is, for example, a hard disk drive of a type such as SAS (Serial Attached SCSI), SATA (Serial ATA), FC (Fibre Channel), PATA (Parallel ATA), SCSI, or a semiconductor storage device (SSD).
  • SAS Serial Attached SCSI
  • SATA Serial ATA
  • FC Fibre Channel
  • PATA Parallel ATA
  • SCSI Serial Integrated Circuit
  • SSD semiconductor storage device
  • the storage device 17 controls the storage drive 171 by a method such as RAID (Redundant ⁇ Arrays of ⁇ Inexpensive (or Independent) Disks), for example.
  • the storage device 17 stores the storage device 17 in the server device 3 in units of logical storage areas. Provides a storage area.
  • This logical storage area is, for example, a logical device (LDEV 172 (LDEV: Logical Device)) configured using a RAID group (parity group (Parity Group)).
  • the storage apparatus 10 also provides a logical storage area (hereinafter referred to as LU (Logical Unit, Logical Volume)) configured using the LDEV 172 to the server apparatus 3.
  • LU Logical Unit, Logical Volume
  • the storage device 10 manages the correspondence (relationship) between the LU and the LDEV 172, and the storage device 10 specifies the LDEV 172 corresponding to the LU or the LU corresponding to the LDEV 172 based on this correspondence.
  • FIG. 5 shows the hardware configuration of the channel substrate 11.
  • the channel board 11 has an external communication interface (hereinafter referred to as an external communication I / F 111) having a port (communication port) for communicating with the server device 3, and a processor 112 (frame processing chip). And a frame transfer chip), a memory 113, and an internal communication interface (hereinafter referred to as an internal communication I / F 114) having a port (communication port) for communicating with the processor board 12.
  • the external communication I / F 111 is configured using NIC (Network Interface Card), HBA (Host Bus Adapter) or the like.
  • the processor 112 is configured using a CPU (Central Processing Unit), an MPU (Micro Processing Unit), and the like.
  • the memory 113 is a RAM (Random Access Memory) and a ROM (Read Only Memory).
  • the memory 113 stores a microprogram.
  • Various functions provided by the channel substrate 11 are realized by the processor 112 reading the microprogram from the memory 113 and executing it.
  • the internal communication I / F 114 communicates with the processor board 12, the drive board 13, the cache memory 14, and the shared memory 15 via the internal switch 16.
  • FIG. 6 shows the hardware configuration of the processor board 12.
  • the processor board 12 has a higher access performance from the processor 122 (high speed access is possible) than the internal communication interface (hereinafter referred to as an internal communication I / F 121), the processor 122, and the shared memory 15. Local memory).
  • the memory 123 stores a microprogram.
  • Various functions provided by the processor board 12 are realized by the processor 122 reading the microprogram from the memory 123 and executing it.
  • the internal communication I / F 121 communicates with the channel board 11, the drive board 13, the cache memory 14, and the shared memory 15 via the internal switch 16.
  • the processor 122 is configured using a CPU, MPU, DMA (Direct Memory Access), and the like.
  • the memory 123 is a RAM or a ROM. The processor 122 can access both the memory 123 and the shared memory 15.
  • FIG. 7 shows the hardware configuration of the drive board 13.
  • the drive board 13 includes an internal communication interface (hereinafter referred to as an internal communication I / F 131), a processor 132, a memory 133, and a drive interface (hereinafter referred to as a drive I / F 134).
  • the memory 133 stores a microprogram.
  • Various functions provided by the drive substrate 13 are realized by the processor 132 reading the microprogram from the memory 133 and executing the microprogram.
  • the internal communication I / F 131 communicates with the channel board 11, the processor board 12, the cache memory 14, and the shared memory 15 via the internal switch 16.
  • the processor 132 is configured using a CPU, MPU, or the like.
  • the memory 133 is, for example, a RAM or a ROM.
  • the drive I / F 134 communicates with the storage device 17.
  • the maintenance device 18 shown in FIG. 4 performs control and status monitoring of each component of the storage device 10.
  • the maintenance device 18 is a personal computer, an office computer, or the like.
  • the maintenance device 18 includes components of the storage device 10 such as the channel board 11, the processor board 12, the drive board 13, the cache memory 14, the shared memory 15, and the internal switch 16 via the internal switch 16 or communication means such as a LAN. Communication is performed as needed, and operation information and the like are acquired from each component and provided to the management device 19.
  • the maintenance device 18 performs setting, control, and maintenance (including software installation and update) of each component based on the control information and operation information sent from the management device 19.
  • the management device 19 is a computer that is communicably connected to the maintenance device 18 via a LAN or the like.
  • the management device 19 includes a user interface using a GUI (Graphical User Interface) or a CLI (Command Line Interface) for controlling and monitoring the storage device 10.
  • GUI Graphic User Interface
  • CLI Common Line Interface
  • FIG. 8 shows basic functions of the storage apparatus 10.
  • the storage apparatus 10 includes an I / O processing unit 811.
  • the I / O processing unit 811 includes a data write processing unit 8111 that performs processing related to writing to the storage device 17, and a data read processing unit 8112 that performs processing related to reading data from the storage device 17.
  • the function of the I / O processing unit 811 is stored in the memory 113, 123, 133 by the hardware included in the channel board 11, the processor board 12, and the drive board 13 of the storage apparatus 10, or by the processors 112, 122, 132. This is realized by reading out and executing the microprogram.
  • FIG. 9 shows a frame in which the storage device 10 (first storage device 10a or second storage device 10b; the same applies hereinafter) includes a data write request from the server device 3 (first server device 3a or second server device 3b).
  • 11 is a flowchart for explaining basic processing (hereinafter referred to as write processing S900) performed by the data write processing unit 8111 of the I / O processing unit 81 when it is received.
  • write processing S900 basic processing performed by the data write processing unit 8111 of the I / O processing unit 81 when it is received.
  • the writing process S900 will be described with reference to FIG.
  • the letter “S” attached before the reference sign means a processing step.
  • a data write request frame transmitted from the server apparatus 3 is received by the channel substrate 11 of the storage apparatus 10 (S911, S912).
  • the channel board 11 When the channel board 11 receives the frame including the data write request from the server apparatus 3, the channel board 11 notifies the processor board 12 to that effect (S913).
  • the processor board 12 When the processor board 12 receives the notification from the channel board 11 (S921), the processor board 12 generates a drive write request based on the data write request of the frame, stores the write data in the cache memory 14, and notifies the channel board 11 of the notification. A reception notification is returned (S922). The processor board 12 transmits the generated drive write request to the drive board 13 (S923).
  • the channel board 11 transmits a completion report to the server apparatus 3 (S914), and the server apparatus 3 receives the completion report from the channel board 11 (S915).
  • the drive board 13 When the drive board 13 receives the drive write request from the processor board 12, the drive board 13 registers the received drive write request in the write process waiting queue (S924).
  • the drive substrate 13 reads the drive write request from the write processing waiting queue as needed (S925), reads the write data specified in the read drive write request from the cache memory 14, and stores the read write data in the storage device (storage drive). 171) is written (S926). Then, the drive board 13 notifies the processor board 12 of a report (completion report) that the writing of the write data for the drive write request is completed (S927).
  • the processor board 12 receives the completion report sent from the drive board 13 (S928).
  • FIG. 10 illustrates an I / O process (hereinafter referred to as “I / O processing”) performed by the read processing unit 8112 of the I / O processing unit 811 of the storage apparatus 10 when the storage apparatus 10 receives a frame including a data read request from the server apparatus 3. , Referred to as a read process S1000).
  • I / O processing an I / O process
  • FIG. 10 illustrates an I / O process (hereinafter referred to as “I / O processing”) performed by the read processing unit 8112 of the I / O processing unit 811 of the storage apparatus 10 when the storage apparatus 10 receives a frame including a data read request from the server apparatus 3.
  • the read processing S1000 will be described with reference to FIG.
  • a frame transmitted from the server apparatus 3 is received by the channel board 11 of the storage apparatus 10 (S1011 and S1012).
  • the channel board 11 When the channel board 11 receives the frame including the data read request from the server device 3, the channel board 11 notifies the processor board 12 and the drive board 13 to that effect (S1013).
  • the drive board 13 When the drive board 13 receives the notification from the channel board 11 (S1014), the drive board 13 stores the data designated in the data read request included in the frame (for example, designated by LBA (Logical Block Address)). Reading from the device (storage drive 171) (S1015). When read data exists in the cache memory 14 (when a cache hit occurs), the read process (S1015) from the storage device 17 is omitted.
  • LBA Logical Block Address
  • the processor board 12 writes the data read by the drive board 13 to the cache memory 14 (S1016). Then, the processor board 12 transfers the data written in the cache memory 14 to the channel board 11 as needed (S1017).
  • the channel board 11 When the channel board 11 receives the read data sent from the processor board 12 as needed, the channel board 11 sequentially transmits them to the server device 3 (S1018). When the transmission of the read data is completed, the channel board 11 transmits a completion report to the server device 3 (S1019). The server device 3 receives the read data and the completion report (S1020, S1021).
  • FIG. 11 shows the main functions of the client device 2.
  • the client apparatus 2 includes functions of an application 211, a file system 212, and a kernel / driver 213. Note that these functions are realized by the CPU 21 of the client device 2 reading and executing a program stored in the memory 22 or the storage device 23.
  • the file system 212 realizes an I / O function to the logical volume (LU) in file units or directory units for the client device 2.
  • the file system 213 includes, for example, FAT (File Allocation Table), NTFS, HFS (Hierarchical File System), ext2 (second extended file system), ext3 (third extended file system), ext4 (fourth extended file system), UDF (Universal Disk Format), HPFS (High Performance File System), JFS (Journaled File System), UFS (Unix File System), VTOC (Volume Table Of Contents), XFS, and the like.
  • the kernel / driver 213 is realized by executing a kernel module and a driver module constituting the operating system software.
  • the kernel module implements basic functions of the operating system, such as process management, process scheduling, storage area management, and handling of interrupt requests from hardware, for software executed in the client device 2.
  • a program for it is included.
  • the driver module includes hardware constituting the client device 2 and a program for communication between a peripheral device used by connecting to the client device 2 and the kernel module.
  • FIG. 12 shows main functions provided in the first server device 3a and main information (data) managed in the first server device 3a.
  • the first server device 3a implements a virtualization control unit 305 that provides a virtual environment, and one or more virtual machines 310 that operate under the control of the virtualization control unit 305. Yes.
  • Each virtual machine 310 implements the functions of the file sharing processing unit 311, the file system 312, the data operation request receiving unit 313, the data replication / migration processing unit 314, the file access log acquisition unit 317, and the kernel / driver 318. Yes.
  • the virtual environment is a so-called host OS type in which an operating system is interposed between the hardware of the first server device 3a and the virtualization control unit 305, or the hardware of the first server device 3a and the virtualization control unit 305. It may be realized by any hypervisor type system without an intervening operating system.
  • the functions of the data operation request accepting unit 313, the data replication / movement processing unit 314, and the file access log acquisition unit 317 may be realized as functions of the file system 312 or as functions independent of the file system 312. May be.
  • each virtual machine 310 manages information (data) such as a replication information management table 331 and a file access log 335. These pieces of information are read from the first storage 10a to the first server device 3a as needed and stored in the memory 32 and the storage device 33 of the first server device 3a.
  • the file sharing processing unit 311 provides the client device 2 with a file sharing environment.
  • the file sharing processing unit 311 provides a function according to a protocol such as NFS (Network File System), CIFS (Common Internet File System), or AFS (Andrew File System).
  • NFS Network File System
  • CIFS Common Internet File System
  • AFS Andrew File System
  • the file system 312 provides the client device 2 with an I / O function for files (or directories) managed by the logical volume (LU) provided by the first storage device 10a.
  • the file system 312 includes, for example, FAT (File Allocation Table), NTFS, HFS (Hierarchical File System), ext2 (second extended file system), ext3 (third extended file system), ext4 (fourth extended file system), UDF (Universal Disk) Format), HPFS (High Performance File System), JFS (Journaled File System), UFS (Unix File System), VTOC (Volume Table Of Content), XFS, and the like.
  • the data operation request accepting unit 313 accepts a request (hereinafter referred to as a data operation request) related to data operation transmitted from the client device 2.
  • Data operation requests include replication start requests, replication file update requests, replication file reference requests, synchronization requests, metadata access requests, file entity reference requests, recall requests, and stubbed file entities, which will be described later. There is an update request.
  • the stubbing means that the metadata of the file (or directory) data is held in the first storage device 10a, but the substance of the file (or directory) data is not managed on the first storage device 10a side. In other words, it means holding only in the second storage device 10b.
  • the first server device 3a accepts a data I / O request that requires the entity of the file (or directory) for the stubbed file (or directory)
  • the file (or directory) Is transmitted from the second storage device 10b to the first storage device 10a (written back (hereinafter referred to as recall)).
  • the data copy / move processing unit 314 includes a replication start process S2400, a stubbing candidate selection process S2500, a synchronization process S2900, a stubbed file entity reference process S3000, a stubbed file entity update process S3100, a virtual machine recovery process S3300, which will be described later.
  • Exchanges data including flags and tables
  • transfers data including file metadata and entities
  • manages various tables such as the replication information management table 331 and metadata 332.
  • the kernel / driver 318 shown in FIG. 12 is realized by executing a kernel module and a driver module constituting the operating system software.
  • the kernel module has basic functions provided by the operating system, such as process management, process scheduling, storage area management, and handling of interrupt requests from hardware, for software executed in the first server device 3a.
  • a program for realizing it is included.
  • the driver module includes a program for communication between the hardware constituting the first server device 3a and peripheral devices used by being connected to the first server device 3a and the kernel module.
  • the file access log acquisition unit 317 illustrated in FIG. 12 accesses a file stored in the logical volume (LU) of the storage apparatus 10 (file update (Write, Update), file read (Read), file open.
  • file update Write, Update
  • Read file read
  • file open file open.
  • access log information indicating the contents (history) of the access
  • a stamp is added and stored as a file access log 335.
  • FIG. 13 shows an example of the replication information management table 331.
  • the replication information management table 331 includes a host name 3311 (for example, a network address such as an IP address) serving as a replication destination, and a threshold value 3312 (stubbing to be described later) used to determine whether or not to stub. Threshold) is set.
  • a host name 3311 for example, a network address such as an IP address
  • a threshold value 3312 (stubbing to be described later) used to determine whether or not to stub. Threshold) is set.
  • FIG. 14 shows an example of the file access log 335.
  • the file access log 335 records an access log including one or more records each including an access date and time 3351, a file name 3352, and a user ID 3353.
  • the access date and time 3351 is set to the date and time when the file (or directory) was accessed.
  • the file name 3352 the file name (or directory name) of the file (or directory) to be accessed is set.
  • the user ID 3353 is set with the user ID of the user who accessed the file (or directory).
  • FIG. 15 shows main functions provided in the second server device 3b and main information (data) managed in the second server device 3b.
  • the second server device 3b includes functions of a file sharing processing unit 351, a file system 352, a data replication / migration processing unit 354, and a kernel / driver 358.
  • the function of the data replication / movement processing unit 354 may be realized as a function of the file system 352 or may be realized as a function independent of the file system 352.
  • the second server device 3b manages a restore log 365 and a file access log 368.
  • the file sharing processing unit 351 provides a file sharing environment to the first server device 3a.
  • the file sharing processing unit 351 is realized using, for example, an HTTP protocol.
  • the file system 352 uses the logical volume (LU) provided by the second storage device 10b, and provides the I / O function to the logical volume (LU) in file units or directory units for the first server device 3a. To do. Further, the file system 352 performs version management of files and directories, thereby providing the first server device 3a with files and directories at a certain point in the past including the latest.
  • a file system that performs version control as described later overwrites files and directories when creating and deleting files, changing file data and metadata, creating and deleting directories, and adding and deleting entries in directories. Keep files and / or directories without.
  • the file system 352 may be, for example, one file system such as ext3cow, or may be a file system combined with an existing file system such as ext3, ReiserFS, or FAT, such as Wayback.
  • the data replication / movement processing unit 354 performs processing related to data movement and replication between the first storage device 10a and the second storage device 10b.
  • the kernel / driver 358 is realized by executing a kernel module and a driver module constituting the operating system software.
  • the kernel module has basic functions of the operating system, such as process management, process scheduling, storage area management, and handling of interrupt requests from hardware, for software executed in the second server device 3b.
  • a program for realizing it is included.
  • the driver module includes a program for communication between the hardware constituting the second server device 3b and peripheral devices used by being connected to the second server device 3b and the kernel module.
  • FIG. 16 shows an example of the restore log 365.
  • the restore log 365 when a directory image to be described later is created (referred to as restore), the contents of processing related to restoration by the first server device 3a or the second server device 3b are recorded.
  • the restore log 365 is composed of one or more records having items of a date and time 3651, an event 3652 and a restore target file 3653.
  • the date and time 3651 is set to the date and time when the event related to restoration was executed.
  • the event 3652 information indicating the contents of the executed event (restore start, restore execution, etc.) is set.
  • the restore target file 3653 information (path name, file name (or directory name), etc.) for specifying the file (or directory) to be restored is set.
  • the content of the file access log 368 managed by the second server device 3b basically matches the content of the file access log 335 in the first server device 3a. By notifying the contents of the file access log 335 from the first server device 3a to the second server device 3b as needed, the identity of both is ensured.
  • FIG. 17 is an example of a data structure (hereinafter referred to as a file system structure 1700) managed by the file system 312 on a logical volume (LU).
  • the file system structure 1700 includes a storage area of a super block 1711, an inode management table 1712, and a data block 1713 in which file entities (data) are stored.
  • the super block 1711 stores information related to the file system 312 (capacity of storage area handled by the file system, used amount, free capacity, etc.).
  • the super block 1711 is provided for each disk partition (partition set on a logical volume (LU)).
  • Specific examples of the information stored in the super block 1711 include the number of data blocks in the partition, the block size, the number of free blocks, the number of free inodes, the number of mounts of the partition, the elapsed time since the latest consistency check, and the like. is there.
  • the inode management table 1712 stores management information (hereinafter referred to as inode) of files (or directories) stored in a logical volume (LU).
  • the file system 312 manages one inode corresponding to one file (or directory).
  • An inode that contains only information about a directory is called a directory entry.
  • the data block of the file to be accessed is accessed with reference to the directory entry. For example, when accessing the file “/home/user-01/a.txt”, as shown in FIG. 20, the inode number 2 ⁇ 10 ⁇ 15 ⁇ 100 and the directory entries are traced in order, and the access target file. Access a data block.
  • FIG. 19 shows the concept of inode in a general file system (for example, a file system provided in a UNIX (registered trademark) operating system).
  • FIG. 20 shows an example of the inode management table 1712.
  • the inode has an inode number 2011 that is an identifier for distinguishing individual inodes, an owner 2012 of the file (or directory), and an access right 2013 set for the file (or directory).
  • the file system 312 of the present embodiment further includes a stubification flag 2111 and a metadata synchronization flag in addition to the contents of the inode management table 1712 in the normal general file system shown in FIG. 2112, an entity synchronization necessity flag 2113, a replication flag 2114, a read-only flag 2115, and a link destination 2116 are managed.
  • the replication of file metadata (including various flags shown in FIG. 21) stored in the first storage device 10a is copied to the second storage device 10b by the management method by replication or the management method by stubbing. Is also stored (in the case of replication), when the metadata of one device is updated by synchronization processing S2900 described later, that fact is also notified to the other device. Thereby, the identity of the metadata of the first storage device 10a and the content of the metadata of the second storage device 10b is ensured almost in real time.
  • stubbing means that when moving (migrating) a file (or directory) from the first storage device 10a to the second storage device 10b, only the entity of the data of the file is deleted from the migration source first storage device 10a.
  • the metadata of the file data is not deleted but left in the migration source first storage device 10a.
  • the stub refers to metadata remaining in the first storage device 10a in that case.
  • the metadata synchronization necessity flag 2112 is synchronized between the metadata of the file (or directory) of the first storage device 10a that is the replication source and the metadata of the file (or directory) of the second storage device 10b that is the replication destination. Information indicating whether or not there is a need to take (the contents need to be matched) is set. If metadata synchronization is required, ON is set for the metadata synchronization required flag 2112, and OFF is set for the metadata synchronization required flag 2112 if synchronization is not required.
  • the entity synchronization necessity flag 2113 it is necessary to synchronize the data entity of the file of the first storage device 10a that is the replication source and the data entity of the file of the second storage device 10b that is the replication destination (match the contents). Information indicating whether or not there is a need is set.
  • the entity synchronization required flag 2113 is set to ON, and when synchronization is not required, the entity synchronization required flag 2113 is set to OFF.
  • the metadata synchronization necessity flag 2112 and the entity synchronization necessity flag 2113 are referred to as needed in a synchronization process S2900 described later.
  • the metadata synchronization required flag 2112 or the entity synchronization required flag 2113 is ON, the metadata or entity of the first storage device 10a and the metadata or entity of the second storage device 10b that is a duplicate of the metadata or entity. Synchronized automatically.
  • the replication flag 2114 information indicating whether or not a file (or directory) corresponding to the inode is currently managed by a replication management method described later is set. If the file corresponding to the inode is currently managed by the replication management method, the replication flag 2114 is set ON. If the file is not managed by replication, the replication flag 2114 is set OFF. Is done.
  • the read-only flag 2115 is set with information indicating whether or not a file (or directory) corresponding to the inode can be written by the client device 2. When the file (or directory) corresponding to the inode cannot be written, the read-only flag 2115 is set to ON. When the file (or directory) can be written, the read-only flag 2115 is set to OFF.
  • a subject other than the client device 2 for example, the file system 312 and the data replication / movement processing unit 314, can write to a file in which the read-only flag 2115 is set to ON.
  • the setting of the read-only flag 2115 is independent of the setting of the access right 2013.
  • the client apparatus 2 cannot write to a file in which the read-only flag 2115 is set to ON and the access right 2013 is set to be writable.
  • the access right 2013 is set to be writable.
  • the link destination 2116 when a file corresponding to the inode is managed by a replication management method to be described later, information indicating the replication destination of the file (for example, a path name specifying a storage destination (a version ID to be described later) RAID group identifier, block address, URL (Uniform Resource Locator), LU, etc.) are set.
  • the file system 352 included in the second server device 3b includes a version management table 221 necessary for managing and manipulating the version of a file (or directory) in addition to the file system 312 provided in the first server device 3a.
  • FIG. 22 shows an example of the version management table 221.
  • the file system 352 maintains one version management table 221 for each file (or directory). Note that files and directories are collectively referred to as file system objects.
  • the version management table 221 records an entry made up of one or more records each consisting of storage date 2211 and version ID 2212 items.
  • the storage date 2211 is set to the date when the file (or directory) was stored in the file system 352.
  • a name necessary for accessing a specific version of the file (or directory) is set.
  • the name set in the version ID 2212 is, for example, a character string (generally called UUID) having a certain number of consecutive numbers or randomly generated.
  • the version ID 2212 may be set by a user (for example, the client device 2 or the first server device 3a), or may be set by a system (for example, the file system 352).
  • the file system 352 creates the version management table 221 when the file (or directory) is created for the first time, and the file system 352 deletes the version management table 221 when all the versions of the file (or directory) are deleted. To do.
  • the file system 352 deletes an outdated version of the file. For example, the file system 352 sets the past version retention days, and deletes the version of the file that has been created and has passed the past version retention days. This deletion prevents the file system 352 from filling up its capacity with past versions.
  • the user can obtain version information of a file (or directory) stored in the file system 352 by issuing a reference request to the file system 352 for a specific path name.
  • the version information is all entries stored in the version management table 221.
  • the user can store a new file (or directory) by making a file (or directory) update request to the path name of the file system 352. For example, when the user makes a file update request to the path name represented by “/home/user01/a.txt”, the file system 352 acquires the current time and creates the version ID 2212. Next, the file system 352 creates a new entry in the version management table 221, and the file associated with the entry is newly stored. At that time, the previous file is not overwritten.
  • FIG. 23 shows an example of the directory image management table 231.
  • the file system 312 on the first server device 3a stores and maintains it in the first storage device 10a in order to manage the directory where the file restoration has been performed.
  • the directory image management table 231 stores a directory 2311, a restoration date 2312, and a deletion date 2313.
  • the directory 2311 is set with a directory on the file system 312 to which a directory image is restored.
  • the restoration date and time 2312 the date and time of the directory image to be restored is set.
  • the date and time 2313 to be deleted the date and time when the restoration destination directory is deleted from the file system 312 is set.
  • the restoration date and time 2312 and the deletion date and time 2313 may be set by the user or the file system 312. For example, the entry “/mnt/fs01/.histroy/09_05/ 2010/9/5 00:00:00 2010/10/5 00:00:00” is /mnt/fs01/.history on the file system 312.
  • Files (or directories) that existed on the file system 312 at the time of 2010/9/5 00:00:00 are restored to the directory represented by / 09_05 /, and at 2010/10/5 00:00:00 It means to be deleted from the file system 312.
  • the metadata of the directory or file immediately under the highest directory (root directory) in the directory hierarchical structure is restored. This is an example, and further, up to a subordinate directory or file may be restored, or a directory or file of a predetermined hierarchy may be restored directly.
  • FIG. 24 shows information processing when the first server device 3a receives a request for starting replication for a file stored in one storage device 10a (hereinafter referred to as a replication start request). It is a figure explaining the process (henceforth replication start process S2400) performed in the system 1.
  • FIG. 24 shows information processing when the first server device 3a receives a request for starting replication for a file stored in one storage device 10a (hereinafter referred to as a replication start request). It is a figure explaining the process (henceforth replication start process S2400) performed in the system 1.
  • FIG. 24 shows information processing when the first server device 3a receives a request for starting replication for a file stored in one storage device 10a (hereinafter referred to as a replication start request). It is a figure explaining the process (henceforth replication start process S2400) performed in the system 1.
  • FIG. 24 shows information processing when the first server device 3a receives a request for starting replication for a file stored in one storage device 10a (herein
  • the first server apparatus 3a When the first server apparatus 3a receives a replication start request from the client apparatus 2, the first server apparatus 3a starts managing a file specified as a target in the request by a replication management method.
  • the first server device 3a accepts a replication start request generated internally in the first server device 3a, for example, in addition to accepting a replication start request from the client device 2 via the communication network 5.
  • the management method by replication is a method of managing file data (metadata and entity) in both the first storage device 10a and the second storage device 10b.
  • the management method using replication when the entity or metadata of a file stored in the first storage device 10a is updated, it is managed as a copy (or archive file) of this file on the second storage device 10b side.
  • the file metadata or entity is updated synchronously or asynchronously.
  • metadata in a file (archive file) on the second storage device 10b side may be managed as a file entity. By doing so, even when the specifications of the file system 312 of the first server device 3a and the file system 352 of the second server device 3b are different, a management method by replication can be realized.
  • the first server device 3a receives the data (metadata and entity) of the file specified in the received replication start request from the first storage device 10a.
  • the read file data is transmitted to the second server device 3b (S2412).
  • the second server 3b When the second server 3b receives the data of the file sent from the first server device 3a, the second server 3b stores the received data in the second storage device 10b (S2413).
  • the data replication / migration processing unit 314 of the first server device 3a sets the replication flag 2114 of the transfer source file to ON (S2414).
  • FIG. 25 shows the stubbing of the file stored in the first storage device 10a and managed by the replication management method (the file with the replication flag 2114 set to ON, hereinafter referred to as a replication file).
  • FIG. 6 is a diagram for explaining a process (hereinafter referred to as a stubification candidate selection process S2500) performed in the information processing system 1 when setting as a candidate.
  • a stubification candidate selection process S2500 will be described with reference to FIG.
  • the first server device 3a monitors the remaining capacity of the file storage area as needed (real time, periodically, preset timing, etc.).
  • the remaining capacity of the storage area of the first storage device 10a allocated to the file system 312 as a file storage area (hereinafter referred to as a file storage area) is set to a preset threshold value.
  • a stubification threshold When the value is less than (hereinafter referred to as a stubification threshold), a stubification candidate is selected from the replication files stored in the first storage device 10a according to a predetermined selection criterion (S2511).
  • the predetermined selection criteria include, for example, the last update date and time in order from the oldest to the lowest access frequency.
  • the first server device 3a selects a candidate for stubbing, it sets the stubbing flag 2111 of the selected replication file to ON, the replication flag 2114 to OFF, and the metadata synchronization required flag 2112 to ON (S2512). .
  • the first server device 3a acquires the remaining capacity of the file storage area from, for example, information managed by the file system 312.
  • FIG. 26 is a diagram for explaining processing (hereinafter referred to as stubification processing S2600) performed in the information processing system 1 when actually stubbing a file selected as a stubification candidate by the stubification candidate selection processing S2500. It is.
  • the stubbing process S2600 is performed, for example, at a preset timing (for example, following the execution of the stubbing candidate selection process S2500).
  • the stubification processing S2600 will be described with reference to FIG.
  • the first server device 3a selects a file selected as a stubbing candidate from the files stored in the file storage area of the first storage device 10a (the stubbing flag 2111 is turned ON).
  • One or more set files are extracted (S2611).
  • the first server device 3a deletes the substance of the extracted file from the first storage device 10a, and sets an invalid value in the information indicating the storage location of the first storage device 10a of the file from the metadata of the extracted file.
  • Set for example, set a NULL value or zero in a column for setting the storage destination of the file of the metadata (for example, a column for setting the block address 2018), and actually select the file selected as the stubification candidate. Stubbing.
  • the first server device 3a sets the metadata synchronization required flag 2112 to ON (S2612).
  • FIG. 27 shows the processing performed in the information processing system 1 when the first server device 3a receives an update request for the replication file stored in the file storage area of the first storage device 10a from the client device 2 (hereinafter referred to as the information processing system 1). , Referred to as replication file update processing S2700).
  • replication file update processing S2700 will be described with reference to FIG.
  • the first server device 3a updates the data (metadata, entity) of the replication file stored in the first storage device 10a according to the received update request. (S2712).
  • the first server device 3a sets the metadata synchronization necessity flag 2112 of the replication file to ON when updating the metadata, and sets the substance synchronization necessity flag 2113 of the replication file when updating the entity of the replication file. It is set to ON (S2713).
  • FIG. 28 shows the processing performed in the information processing system 1 when the file system 312 of the first server device 3a receives a reference request for the replication file stored in the file storage area of the first storage device 10a from the client device 2.
  • FIG. 6 is a diagram for explaining a process (hereinafter referred to as a replication file reference process S2800).
  • the replication file reference process S2800 will be described with reference to FIG.
  • the file system 312 of the first server device 3a receives an update request for a replication file (S2811)
  • the replication file data (metadata or entity) is read from the first storage device 10a (S2812), and the read data is stored in the read data. Based on this, information for responding to the client apparatus 2 is generated, and the generated response information is transmitted to the client apparatus 2 (S2813).
  • FIG. 29 shows an access request (reference request) to the metadata of a file (file with the stubification flag 2111 set to ON) from the client device 2 or the like by the file system 312 of the first server device 3a.
  • (Or update request) is a diagram illustrating a process performed in the information processing system 1 (hereinafter referred to as metadata access process S2900).
  • the metadata access processing S2900 will be described below with reference to FIG.
  • the first server device 3a when the first server device 3a receives an access request for the metadata of the stubbed file (S2911), the first server device 3a stores the metadata of the first storage device 10a that is the target of the access request. Obtaining and referring to the content of the access request (transmission of response information based on the read metadata to the client device 2) or updating the metadata (S2912). If the metadata content is updated, the metadata synchronization required flag 2112 of the file is set to ON (S2913).
  • the first server device 3a is stored in the first storage device 10a. Process the access request using the existing metadata. For this reason, when the access request targets only the metadata of the file, a response can be quickly returned to the client device 2.
  • the first server apparatus 3a requests a reference from the client apparatus 2 to the entity of a stubbed file (file with the stubbed flag 2111 set to ON, hereinafter referred to as a stubbed file).
  • 6 is a diagram for describing processing (hereinafter referred to as stubbed file entity reference processing S3000) that is performed in the information processing system 1 when it is received.
  • stubbed file entity reference processing S3000 will be described with reference to FIG.
  • the first server device 3a When the first server device 3a receives a reference request for the entity of the stub file from the client device 2 (S3011), the first server device 3a refers to the acquired metadata and stores the entity of the stub file in the first storage device 10a. It is determined whether or not (S3012). Here, this determination is made based on, for example, whether or not a valid value is set in the information (for example, block address 2018) indicating the storage location of the stubbed file entity in the acquired metadata.
  • the first server device 3a reads the entity of the stub file from the first storage device 10a. Based on the above, information to respond to the client device 2 is generated, and the generated response information is transmitted to the client device 2 (S3013).
  • the first server device 3a provides the second server device 3b with the entity of the stubbed file.
  • a request is made (hereinafter referred to as a recall request) (S3014). It should be noted that the acquisition request for an entity is not necessarily a request for acquiring the entire entity by a single acquisition request, and for example, only a part of the entity may be requested a plurality of times.
  • the first server device 3a When receiving the entity of the stub file sent from the second server device 3b in response to the acquisition request (S3015), the first server device 3a generates response information based on the received entity, and the generated response information Is transmitted to the client apparatus 2 (S3016).
  • the first server device 3a stores the entity received from the second server device 3b in the first storage device 10a, and information indicating the storage location of the file entity of the metadata of the stubbed file (for example, a block address)
  • the content indicating the storage destination of the file in the first storage device 10a is set in 2018).
  • the first server device 3a sets the stubbing flag 2111 of the file to OFF, sets the replication flag 2114 to ON, and sets the metadata synchronization required flag 2112 to ON (the file is changed from the stubbed file to the replication file). (S3017).
  • the metadata synchronization necessity flag 2112 is set to ON because the contents of the stubbing flag 2111 and the replication flag 2114 of the stubbed file are set afterwards between the first storage device 10a and the second storage device 10b. This is to automatically synchronize with.
  • FIG. 31 illustrates a process performed in the information processing system 1 (hereinafter referred to as a stubified file entity update process S3100) when the first server apparatus 3a receives an update request for the entity of the stubified file from the client apparatus 2.
  • a stubified file entity update process S3100 a process performed in the information processing system 1 (hereinafter referred to as a stubified file entity update process S3100) when the first server apparatus 3a receives an update request for the entity of the stubified file from the client apparatus 2.
  • FIG. illustrates a process performed in the information processing system 1 (hereinafter referred to as a stubified file entity update process S3100) when the first server apparatus 3a receives an update request for the entity of the stubified file from the client apparatus 2.
  • FIG. the stubbed file entity update processing S3100 will be described with reference to FIG.
  • the first server device 3a When the first server device 3a receives an update request for the entity of the stub file (S3111), the first server device 3a acquires the meta data of the stub file that is the object of the update request, and the stub file is based on the acquired metadata. It is determined whether or not the entity is stored in the first storage device 10a (S3112). The determination method is the same as in the case of the stubbed file entity reference process S3000.
  • the first server device 3a requests the update request for the entity of the stub file stored in the first storage device 10a. While updating according to the contents, the entity synchronization required flag 2113 of the stubbed file is set to ON (S3113).
  • the first server device 3a transmits an acquisition request (recall request) of the entity of the stubified file to the second server device 3b ( S3114).
  • the first server device 3a Upon receiving the file entity sent from the second server device 3b in response to the request (S3115), the first server device 3a updates the content of the received entity in accordance with the content of the update request, and the updated entity Is stored in the first storage device 10a as the entity of the stub file.
  • the first server device 3a sets the stubbing flag 2111 of the stubbed file to OFF, the replication flag 2114 to OFF, and the metadata synchronization required flag 2112 to ON (S3116).
  • FIG. 32 is a diagram for explaining processing for creating a directory image at a certain point in the past (hereinafter referred to as directory image creation processing S3200).
  • directory image creation processing S3200 processing for creating a directory image at a certain point in the past
  • the file system 312 of the first server device 3a has a directory configuration (that is, a directory configuration stored in the second storage device 10b) that has been configured in the first storage device 10a at a certain past time.
  • Data, a directory data (metadata), and a file data (metadata and substance) (hereinafter referred to as a directory image)) (hereinafter referred to as a root directory).
  • a request for acquiring the metadata of the directory existing in the directory and the metadata of the file existing in the root directory is transmitted to the second server device 3b (S3211).
  • the directories and files existing in (visible from) the root directory are included, but the root directory includes It does not include directories that are further under the existing directory or files that exist in that directory.
  • the second server device 3b acquires the metadata of the directory existing in the requested root directory and the metadata of the file existing in the root directory from the second storage device 10b (S3212). The acquired metadata is transmitted to the first storage device 10a (S3213).
  • the first server device 3a When receiving the metadata from the second server device 3b (S3213), the first server device 3a restores the directory image based on the received metadata to the first storage device 10a (S3214). At this time, the first server device 3a sets the metadata synchronization required flag 2112 to ON, the entity synchronization required flag 2113 to ON, and the read-only flag 2115 to ON. Since all the restored files are based only on the metadata, these files are all in a stub state, and the stubification flag 2111 is set to ON.
  • the first server device 3a restores the directory image to the first storage device 10a.
  • the file system 312 of the first server device 3a periodically acquires a directory image, for example, as shown in FIG. 23, and continuously manages it with a directory management table.
  • the directory image acquisition mode can be changed as appropriate, and may be a timing each time a predetermined event occurs in the first server device 3a. For example, it is the time when the client device inquires the history of the file to the first server 3a. In this case, the directory image to which the past version belongs is acquired on the assumption that the client may access the past version of the file.
  • FIG. 33 shows a process of restoring the directory image managed by the first server device 3a at a certain past time after the directory image creation process S3200 shown in FIG. 32 (hereinafter referred to as an on-demand restore process S3300). It is a figure explaining. Hereinafter, the on-demand restoration process S3300 will be described with reference to FIG.
  • the first server device 3a When the first server device 3a starts a service and then receives a data I / O request for a certain file from the client device 2 (S3311), the file (hereinafter referred to as access) for the received data I / O request. It is checked whether the metadata of the target file exists in the first storage device 10a (whether the metadata has already been restored in the first storage device 10a after the service starts) (S3312).
  • the first server device 3a receives the received data I / O request target (metadata or entity), the type of the data I / O request (reference request or update). Request), whether it is managed by a replication management method (whether the replication flag 2114 is ON), or whether it is stubbed (whether the stubbing flag is ON) Processing corresponding to the I / O request (replication file update processing S2700, replication file reference processing S2800, metadata access processing S2900, stubified file entity reference processing S3000, stubified file entity update processing S3100 described above) is performed, and the client device A response is returned to 2 (S3318).
  • replication file update processing S2700, replication file reference processing S2800, metadata access processing S2900, stubified file entity reference processing S3000, stubified file entity update processing S3100 described above is performed, and the client device A response is returned to 2 (S3318).
  • the first server device 3a restores the directory image from the root directory to the directory level (directory hierarchy) where the access target file exists.
  • Data is acquired from the second server device 3b (second storage device 10b) (S3313 to S3315), and a directory image from the root directory to the directory level is stored in the first storage device 10a using the acquired data. Restoration is performed (S3316).
  • the first server device 3a sets the stubification flag 2111 of the access target file to ON, the replication flag 2114 to OFF, the metadata synchronization required flag 2112 to ON, and the read-only flag 2115 to ON (S3317). ).
  • the first server device 3a performs processing corresponding to the received data I / O request according to the object and type of the received data I / O request, the management method, the presence / absence of stubbing, and the like, and the client device 2 A response is returned to (S3318).
  • FIG. 34 shows how the directory image is restored to the first storage device 10a step by step by the on-demand restoration processing S3300 described above by repeatedly generating data I / O requests.
  • FIG. 34 (0) is a directory image (directory to be finally restored) that is managed in the first server device 3a (first storage device 10a) at a certain point in the past and has been replicated to the second server device 3b. The whole image).
  • FIG. 34A shows a directory image immediately after the directory image creation process S3200 (a state in which the first server device 3a has not yet received a data I / O request).
  • the metadata of the directories “/ dir1” and “/ dir2” existing immediately under the root directory “/” has been restored, but the metadata of the subordinate directories has not yet been restored.
  • the metadata of the file “a.txt” that exists immediately under the root directory “/” has been restored, but the entity has not yet been restored.
  • FIG. 34B shows a state after receiving a data I / O request for the file “c.txt” existing under the directory “/ dir1” from the client apparatus 2 in the state of FIG. . Since the data I / O request for the file “c.txt” is received from the client apparatus 2, the metadata of the directory “/ dir11” and the metadata of “/c.txt” are restored.
  • FIG. 34C shows a state after the data I / O request for the file “b.txt” existing under the directory “/ dir2” is further received from the client apparatus 2 in the state of FIG. is there.
  • the data I / O request for the file “b.txt” is received from the client apparatus 2
  • the metadata of “/b.txt” is restored. Note that since the metadata of “/b.txt” existing under “/ dir2” has been restored, “/ dir2” is represented by unemphasized characters.
  • FIG. 34D shows a state after a data I / O request (update request) for the file “b.txt” is received from the client apparatus 2 in the state of FIG. Since the data I / O request (update request) for the file “b.txt” is received from the client device 2, the entity of the file “b.txt” is restored.
  • FIG. 35 is a diagram for explaining processing for deleting a directory image at a certain past time (hereinafter referred to as directory image deletion processing S3500).
  • directory image deletion processing S3500 processing for deleting a directory image at a certain past time
  • the first server device 3 monitors whether the directory configured in the first storage device 10a at a certain time in the past by the file system 312 has been stored beyond the date and time set in the file system 312 ( S3511). If the directory has been stored beyond the date and time, the file system 312 deletes the directory (S3512).
  • the directory image creation process S3200 after the directory image creation process is performed in the first server device 3a and before the data I / O request is received, the directory image creation process S3200.
  • the directory image creation process S3200 only the metadata of the directory existing in the root directory and the metadata of the file existing in the root directory are restored.
  • the first server device 3a (first storage device 10a) is gradually added. The directory image is restored.
  • the entire directory image is not restored before the start of accepting the data I / O request, but the directory image necessary for processing the data I / O request is staged.
  • the time required for file restoration can be shortened compared with the case where the entire directory image is restored for file restoration, and the influence on the user's work etc. is prevented. Can do.
  • the resources of the first storage device 10a can be saved until the directory image is completely restored. Furthermore, the consumption of storage capacity is suppressed until the directory image is completely restored.
  • FIG. 36 is a flowchart for explaining the details of the replication start processing S2400 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a monitors in real time whether a replication start request has been received from the client device 2 or the like (S3611).
  • the first server device 3a receives a replication start request from the client device 2 or the like (S3611: YES) (S2411 in FIG. 24)
  • the data (metadata and entity) of the file specified in the received replication start request is received.
  • the storage server (RAID group identifier, block address, etc.) is inquired of the second server device 3b (S3612).
  • the second server apparatus 3b When the second server apparatus 3b receives the above inquiry (S3621), the second server apparatus 3b searches the free space in the second storage apparatus 10b to determine the storage location of the file data, and the determined storage destination is stored in the first server apparatus 3a. Notification is made (S3622).
  • the first server device 3a When the first server device 3a receives the notification (S3613), it reads the data (metadata and entity) of the file specified in the accepted replication start request from the first storage device 10a (S3614) (FIG. 24). S2412), the data of the read file is transmitted to the second server apparatus 3b together with the storage location notified in S3622 (S3615) (S2413 in FIG. 24).
  • the first server device 3a sets the replication flag 2114 of the metadata of the file (metadata of the file stored in the first storage device 10a) to ON, and sets the metadata synchronization required flag 2112 to ON ( S3616) (S2414 in FIG. 24).
  • the file metadata stored in the first storage device 10a by the above-described synchronization processing S2900 and stored as a duplicate in the second storage device 10b. Consistency of the file metadata is ensured (guaranteed) synchronously or asynchronously.
  • the second server device 3b receives the data of the file from the first server device 3a (S3623), the position of the second storage device 10b specified by the storage destination that received the data of the received file together with the file. (S3624).
  • FIG. 37 is a flowchart for explaining details of the stubbing candidate selection process S2500 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a monitors whether or not the remaining capacity of the file storage area is less than the stub threshold (S3711, S3712), and the remaining capacity of the file storage area is less than the stub threshold. Is detected, a stubbing candidate is selected from the replication files stored in the first storage device 10a according to the above-described predetermined selection criteria (S3712) (S2511 in FIG. 25).
  • the stubbing flag 2111 of the selected replication file is set ON, the replication flag 2114 is set OFF, and the metadata synchronization required flag 2112 is set ON (S3713).
  • S3714 (S2512 in FIG. 25).
  • FIG. 38 is a flowchart for explaining the details of the stub processing S2600 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a selects a file selected as a stubbing candidate from the files stored in the file storage area of the first storage device 10a (file with the stubbing flag 2111 set to ON). It extracts at any time (S3811, S3812).
  • the first server device 3a deletes the substance of the extracted file from the first storage device 10a (S3813), and the information indicating the storage location of the first storage device 10a of the file is invalid from the extracted file metadata.
  • a NULL value or zero is set in a column for setting the storage destination of the metadata file (for example, block address 2018)) (S3814), and the metadata synchronization required flag 2112 is set to ON. (S3815) (S2611 in FIG. 26).
  • FIG. 39 is a flowchart for explaining the details of the replication file update processing S2700 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a monitors in real time whether or not an update request for the replication file has been received from the client device 2 (S3911).
  • the first server device 3a stores the data (metadata) of the replication file stored in the first storage device 10a and subject to the update request. (Data or entity) is updated according to the received update request (S3912) (S2712 in FIG. 27).
  • the first server device 3a sets the metadata synchronization necessity flag 2112 of the replication file to ON when the metadata is updated (S3913), and if the entity of the replication file is updated, the entity synchronization necessity of the replication file is required.
  • the flag 2113 is set to ON (S3914) (S2713 in FIG. 27).
  • FIG. 40 is a flowchart for explaining the details of the replication file reference process S2800 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a monitors in real time whether or not a reference request for the replication file has been received from the client device 2 (S4011).
  • the first server device 3a receives the reference request (S4011: YES) (S2811 in FIG. 28)
  • the data (metadata or entity) of the replication file is read from the first storage device 10a (S4012) (FIG. 28).
  • step S2812 information that responds to the client apparatus 2 is generated based on the read data, and the generated response information is transmitted to the client apparatus 2 (S4013) (S2813 in FIG. 28).
  • FIG. 41 is a flowchart for explaining the details of the metadata access processing S2900 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a monitors in real time whether or not an access request (reference request or update request) to the meta data of the stubbed file has been received from the client device 2 (S4111).
  • the first server device 3a When the first server device 3a receives an access request for the meta data of the stubbed file (S4111: YES) (S2911 in FIG. 29), the first server device 3a of the first storage device 10a that is the target of the received access request. Metadata is acquired (S4112), and in accordance with the received access request (S4113), reference to metadata (transmission of response information based on the read metadata to the client apparatus 2) (S1514) or update of metadata is performed. (S4115) (S2912 in FIG. 29). If the content of the metadata is updated (S4115), the metadata synchronization required flag 2112 of the file is set to ON (S2913 in FIG. 29).
  • FIG. 42 is a flowchart for explaining the details of the stubbed file entity reference process S3000 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a When the first server device 3a receives a reference request for the entity of the stub file from the client device 2 (S4211: YES) (S3011 in FIG. 30), the entity of the stub file is stored in the first storage device 10a. It is determined whether or not (S4212) (S3012 in FIG. 30).
  • the first server device 3a When the entity of the stub file is stored in the first storage device 10a (S4212: YES), the first server device 3a reads the entity of the stub file from the first storage device 10a and reads the entity. Based on the above, information to respond to the client apparatus 2 is generated, and the generated response information is transmitted to the client apparatus 2 (S4213) (S3013 in FIG. 30).
  • the first server device 3a requests the entity of the stubified file from the second server device 3b. (Recall Request) (S4214) (S3014 in FIG. 30). At that time, the first server device 3a requests a specific version of the file of the second server device 3b using the link destination 2116 included in the metadata of the stub file.
  • the first server device 3a When the first server device 3a receives the entity of the stub file sent from the second server device 3b in response to the acquisition request (S4221, S4222, S4215) (S3015 in FIG. 30), the first server device 3a is based on the received entity. Response information is generated, and the generated response information is transmitted to the client device 2 (S4216) (S3016 in FIG. 30).
  • the first server device 3a stores the entity received from the second server device 3b in the first storage device 10a, and information indicating the storage location of the file entity of the metadata of the stubbed file (for example, a block address)
  • the content indicating the storage location of the file in the first storage device 10a is set in (2016) (S4217).
  • the first server device 3a sets the stubbing flag 2111 of the file to OFF, the replication flag 2114 to ON, and the metadata synchronization required flag 2112 to ON (S4218) (S3017 in FIG. 30).
  • FIG. 43 is a flowchart for explaining the details of the stubbed file entity update process S3100 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a When the first server device 3a receives an update request for the entity of the stub file from the client device 2 (S4311: YES) (S3111 in FIG. 31), the entity of the stub file is stored in the first storage device 10a. It is determined whether or not (S4312) (S3112 in FIG. 31).
  • the first server device 3a When the entity of the stubified file is stored in the first storage device 10a (S4312: YES), the first server device 3a makes an update request for the entity of the stubated file stored in the first storage device 10a. While updating according to the contents (S4313), the entity synchronization required flag 2113 of the stub file is set to ON (S4314) (S3113 in FIG. 31).
  • the first server device 3a sends the second stub file to the second server device 3b.
  • An entity acquisition request (recall request) is transmitted (S4315) (S3114 in FIG. 31).
  • the first server device 3a When the first server device 3a receives the entity of the file sent from the second server device 3b in response to the request (S4321, S4322, S4316) (S3115), the content of the received entity is changed according to the content of the update request.
  • the updated entity is updated (S4317), and the updated entity is stored in the first storage device 10a as the entity of the stub file (S4318) (S3116 in FIG. 31).
  • the first server device 3a sets the stubbing flag 2111 of the stubbed file to OFF, the replication flag 2114 to OFF, and the metadata synchronization required flag 2112 to ON (S4319).
  • FIG. 44 is a flowchart for explaining the details of the directory image creation process S3200 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a creates a destination directory for restoring a directory image at a certain past time (S4411).
  • the first server device 3a sets the path of the created directory, the current date and time, and the date and time when the directory image retention days are added to the current date and time to the directory 2311, the date and time 2312 to restore, and the date and time 2313 to delete, respectively.
  • a new entry is created in the directory image management table 231.
  • the directory image retention days is the number of days from the creation of the restoration destination directory to the deletion set in the file system 312.
  • the first server device 3a sends the metadata of the directory existing in the root directory of the directory image of the date and time 2312 restored by the file system 312 and the metadata of the file existing in the root directory to the second server device 3b. Acquisition is performed as follows.
  • the first server device 3a requests the root server version information from the second server device 3b (S4412).
  • the second server device 3b Upon receiving the acquisition request (S4421), the second server device 3b acquires version information of the requested root directory from the second storage device 10b, and sends the acquired version information to the first server device 3a. It transmits (S4422).
  • the closest storage date 2211 that does not exceed the date and time 2312 to be restored is displayed as the version information (version management) of the root directory.
  • a search is made from the table 221), and a version ID 2212 corresponding to the searched storage date is obtained (S4414).
  • the first server device 3a transmits to the second server device 3b an acquisition request for the metadata of the directory existing in the root directory having the acquired version ID 2212 and the metadata of the file existing in the root directory. (S4415) (S3211 in FIG. 32).
  • the second server device 3b Upon receiving the acquisition request (S4423), the second server device 3b acquires the metadata of the requested root directory, and performs the same processing as S4412 to S4414 on the directory entry.
  • the metadata of the directory existing in the root directory of the version to be restored and the metadata of the file existing in the root directory of the version to be restored are acquired from the second storage device 10b, and the acquired metadata is acquired in the first storage device 10a. Transmit (S4424) (S3212 and S3213 in FIG. 32).
  • the first server device 3a receives the metadata from the second server device 3b (S4416) (S3213 in FIG. 32)
  • the first storage device 10a configures (restores) a directory image according to the received metadata. (S4417) (S3214 in FIG. 32).
  • the first server device 3a sets the metadata synchronization required flag 2112 to ON, the entity synchronization required flag 2113 to ON, and the read-only flag to ON (S4418).
  • 45 and 46 are flowcharts illustrating details of the on-demand restoration processing S3300 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the user accesses a desired restoration destination directory among the restoration destination directories 2311.
  • the first server device 3a receives a data I / O request for a predetermined file to be restored from the client device 2 (S4511: YES) (S3311 in FIG. 33)
  • the received data I / O It is checked whether or not the metadata of the request target file (access target file) exists under the restore destination directory configured in the first storage device 10a (S4512) (S3312 in FIG. 33). .
  • the first server device 3a determines the target and type of the received data I / O request, the management method, the presence / absence of stubbing, and the like. In response, processing corresponding to the received data I / O request is performed, and a response is returned to the client device 2 (S4513) (S3318 in FIG. 33).
  • the first server device 3a reaches the directory level where the access target file exists, starting from the root directory.
  • the parent directory restoration process is called to restore the directory images up to (S4514).
  • the first server device 3a reaches the directory level (directory hierarchy) where the access target file exists from the root directory of the file system of the date and time 2312 restored by the file system 312 with respect to the second server device 3b.
  • the directory image up to this point is restored as follows (see FIG. 46).
  • the first server device 3a sends the second server device 3b directly below the root directory among the directories that have not been restored to the first storage device 10a based on the path information in the data I / O request. That is, the version information of the directory at the shallowest directory level is requested (S4611).
  • the second server device 3b Upon receiving the acquisition request (S4621), the second server device 3b acquires the version information of the requested shallowest directory from the second storage device 10b, and acquires the acquired version information from the first server device 3a. (S4622).
  • the first server device 3a sends to the second server device 3b a request for acquiring the metadata of the directory existing in the directory having the acquired version ID 2212 and the metadata of the file existing in the root directory.
  • the data is transmitted to the server device 3b (S4614) (S3313 in FIG. 33).
  • the second server device 3b Upon receiving the above acquisition request (S4623), the second server device 3b acquires metadata of the requested directory, and performs the same processing as S4611 to S4616 on the directory entry.
  • the metadata of the directory existing in the directory image of the version to be restored and the metadata of the file existing in the directory of the version to be restored are acquired from the second storage device 10b, and the acquired metadata is transmitted to the first storage device 10a.
  • S4624 (S3214, S3315 of FIG. 33).
  • the first server device 3a Upon receiving the data sent from the second server device 3b (S4615), the first server device 3a restores the directory image to the first storage device 10a using the data (S4616) (FIG. 33). S3316). In step S4617, the first server device 3a determines whether or not the restoration of the parent directory is completed, that is, whether or not the directory image has been restored to the directory where the metadata of the file to be restored can be obtained, and the parent directory restoration process. Is completed, the first server device 3a sets the stubification flag 2111 of the access target file to ON, the replication flag 2114 to OFF, the metadata synchronization required flag 2112 to ON, and the read-only flag to ON. (S4515) (S3317 in FIG. 33).
  • the first server device 3a performs processing corresponding to the received data I / O request according to the object and type of the received data I / O request, the management method, the presence / absence of stubbing, and the like, and the client device 2 A response is returned (S4516) (S3318 in FIG. 33).
  • the first file server requests the file entity from the second file server (recall request: S4214 in FIG. 42), it may request not all of the file entity but a part thereof. .
  • the first server device 3a when the first server device 3a restores the file, the first server device 3a associates the date and time with the directory, and the second server device 3b Prior to the start of acceptance of the data I / O request by the first server device 3a, from the top directory of the version associated with the directory in the file data stored in the second storage device 10b to a predetermined lower hierarchy Is sent to the first server device 3a, and the first server device 3a restores the directory image sent from the second server device 3b to the first storage device 10a, and then accepts the data I / O request. To resume.
  • FIG. 47 is a flowchart for explaining the details of the directory image deletion processing S3500 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a periodically refers to the directory image management table 231 to check whether or not the date 2313 at which the directory 2311 as the file restoration destination has been deleted has passed (S4711, S4711). If it has passed, it is determined as the directory image deletion timing (S4712: YES), and the directory image is deleted (S4713). Finally, the entry including the deleted directory 2311 is deleted from the directory image management table 231.
  • the information processing system 1 when restoring the file of the first server device 3a, not all the directory images existing in the first storage device 10a are restored, but the highest level. Since only the directory images from the current directory to the predetermined lower hierarchy are restored, the time required for file restoration is shortened compared with the case where all the directory images existing in the first storage device 10a at a certain point in the past are restored. Service can be resumed early. Further, as compared with the case where all directory images are restored, the load applied to the information processing system 1 can be reduced, and the storage consumption of the first storage device 10a can be reduced.
  • the second embodiment is different from the first embodiment in a part of the directory image creation process S3200 and a part of the on-demand restoration process S3300.
  • the file system 312 of the first server device 3a maintains a version management table 231 for the root directory.
  • FIG. 48 is a flowchart for explaining the details of the directory image creation processing S3200 shown in FIG. Hereinafter, it will be described with reference to FIG.
  • the first server device 3a creates a destination directory for restoring a directory image at a certain past time (S4811).
  • the first server device 3a sets the path of the created directory, the current date and time, and the date and time when the directory image retention days are added to the current date and time to the directory 2311, the date and time 2312 to restore, and the date and time 2313 to delete, respectively.
  • a new entry is created in the directory image management table 231.
  • the directory image retention days is the number of days from the creation of the restoration destination directory to the deletion set in the file system 312.
  • the first server device 3a sends the metadata of the directory existing in the root directory of the directory image of the date and time 2312 restored by the file system 312 and the metadata of the file existing in the root directory to the second server device 3b. Acquisition is performed as follows.
  • the first server device 3a acquires version information from the version management table 221 of the root directory maintained in the file system 312 (S4812).
  • the first server device 3a sends an acquisition request for the metadata of the directory existing in the root directory having the acquired version ID 2212 and the metadata of the file existing in the root directory to the second server device 3b. 2 is transmitted to the server apparatus 3b (S4814) (S3211 in FIG. 32).
  • the second server device 3b receives the acquisition request (S4821), the metadata of the requested root directory, the metadata of the directory existing in the root directory of the version to be restored, and the root of the version to be restored.
  • the metadata of the file existing in the directory is acquired from the second storage device 10b, and the acquired metadata is transmitted to the first storage device 10a (S4822) (S3212 and S3213 in FIG. 32).
  • the first server device 3a receives metadata from the second server device 3b (S4815) (S3213 in FIG. 32), a directory image according to the received metadata is configured (restored) in the first storage device 10a. (S4816) (S3214 in FIG. 32). At this time, the first server device 3a sets the metadata synchronization required flag 2112 to ON, the entity synchronization required flag 2113 to ON, and the read-only flag to ON (S4817).
  • FIG. 49 is a flowchart for explaining the details of the parent directory restoration process in the on-demand restoration process S3300 shown in FIG. This will be described below with reference to FIGS. 45 and 49.
  • the first server apparatus 3a takes the directory level (directory) where the access target file exists from the root directory of the file system of the date and time 2312 restored by the file system 312.
  • the directory image up to (hierarchy) is restored as follows.
  • the first server device 3a acquires the link destination 2116 of the directory at the shallowest directory level among the directories not restored in the first storage device 10a, and acquires the acquired link destination to the second server device 3b.
  • An acquisition request for the metadata of the directory existing in the directory indicated by 2116 and the metadata of the file existing in the root directory is transmitted to the second server device 3b (S4911) (S3211 of FIG. 32).
  • the second server device 3b Upon receiving the acquisition request (S4921), the second server device 3b stores the requested directory metadata, the directory metadata existing in the restored version directory, and the restored version root directory.
  • the metadata of the existing file is acquired from the second storage device 10b, and the acquired metadata is transmitted to the first storage device 10a (S4822) (S3212 and S3213 in FIG. 32).
  • the first server device 3a Upon receiving the data sent from the second server device 3b (S4912), the first server device 3a restores the directory image to the first storage device 10a using the data (S4913) (FIG. 33). S3316).
  • the first server device 3a repeats S4911 to S4913 until reaching the directory level where the access target file exists (S4914).
  • the version ID search using version information is less than in the first embodiment, the performance for the client device 2 can be improved (response speed can be reduced).
  • the functions of the file sharing processing unit 311, the file system 312, the data operation request receiving unit 313, the data replication / migration processing unit 314, the file access log acquisition unit 317, and the kernel / driver 318 are the virtual machine. Although described as being implemented in 310, these functions are not necessarily implemented in the virtual machine 310.
  • the description has been made assuming that the part from the root directory to the access target file is restored to the first storage device 10a.
  • a part thereof may be restored by the same method.
  • the parent directory of the access target file and the access target file can be restored.

Abstract

【課題】ユーザによるファイルアクセス要求に際して少ないストレージ消費量で迅速にファイルを復元する。 【解決手段】ファイル復元に際し、第２サーバ装置３ｂが、第２ストレージ装置１０ｂに記憶しているファイルのデータのうち、復元先ディレクトリに関連づけた日時に第１サーバ装置３ａのファイルシステムに構成されていたディレクトリイメージの、最上位ディレクトリから所定の下位階層までのディレクトリイメージを第１サーバ装置３ａに送信し、第１サーバ装置３ａがディレクトリイメージを第１ストレージ装置１０ａに復元する。第２サーバ装置３ｂは、第１サーバ装置３ａから要求が送られてきた場合、追加のディレクトリイメージを第２ストレージ装置１０ｂから読み出して第１サーバ装置３ａに送信する。

Description

情報処理システム、及び、それを用いたファイル復元方法
　この発明は、ファイルの復元機能を備えた情報処理システムに関するものである。
　情報処理システムにおけるファイルの復元システムの従来例として、下記特許文献１及び特許文献２があることが知られている。このうち、特許文献１には、階層記憶装置の復旧に要する時間を低減し、階層記憶装置の復旧を高速に行うべく、オペレーティングシステム上で稼動する階層記憶装置において、ファイルの属性情報を含むｉノードを有し且つそのｉノード番号で当該ファイルを一意に識別するファイルシステムが構築された第１の記憶装置と、ファイルシステムのバックアップデータを含むデータを格納する第２の記憶装置とを有する階層記憶装置の復旧方法において、第２の記憶装置上のバックアップデータから第１の記憶装置上にファイルシステムが復旧されるときに、バックアップデータに含まれるｉノード番号を用いて、復旧対象ファイルのｉノード番号を指定し、指定されたｉノード番号をファイルシステムの復旧対象ファイルに割り当てることが記載されている。
　特許文献２には、ＨＳＭにおける名前空間のバックアップの世代管理を効率的に行うべく、一次ストレージと二次ストレージを有するＨＳＭの制御を行うＨＳＭ制御方法において、ＨＳＭのバックアップ毎に、該バックアップの世代番号を含む情報である世代情報を作成し、ＨＳＭにおけるファイル毎の名前空間に関する情報である名前空間情報と、世代情報作成ステップにより作成された世代番号を用いて該名前空間に関する情報が有効である世代番号の範囲を示す有効世代番号範囲とを名前空間情報履歴として管理することが記載されている。
特開２００５－３１６７０８号公報 特開２００８－０４０６９９号公報
　ところで、企業における支店や事業所等に設けられている情報処理装置のデータのバックアップをデータセンタ等に設けられているバックアップ装置で管理している情報処理システムにおいて、情報処理装置を利用してファイルにアクセスするユーザが誤ってファイルを削除した場合に、削除したファイルをそのユーザの操作によって復元することが望まれる。
　特許文献１に開示される方法では、バックアップ装置側のバックアップデータの全てを情報処理装置に復元した後に情報処理装置のサービスを再開する。そのため、例えば、バックアップデータのサイズが大きい場合は、ユーザが取得したいファイルの復元を完了するまでに長時間を要し、かつ、情報処理装置のファイルシステム容量を過大に消費し、ユーザの業務等への影響が生じる場合があった。
　一方、特許文献２に開示される方法では、情報処理装置の持つ全ファイルの世代を管理するリストを検索して復元対象を特定する。そのため、例えば、ファイルシステム上に多数のファイルが存在する場合やファイルの変更回数が多い場合はリストのサイズが大きくなり、ユーザが取得したいファイルの復元を完了するまでに長時間を要し、かつ、情報処理装置のファイルシステム容量を過大に消費し、ユーザの業務等への影響が生じる場合があった。
　本発明はこのような背景に鑑みてなされたもので、ユーザによるファイルアクセス要求に際して少ないファイルシステム消費量で迅速にファイルを復元可能な、情報処理システムにおけるファイル復元方法、及び、情報処理システムを提供することを主たる目的とする。
　上記目的を達成するための本発明は、第１ファイルシステムを有し、Ｉ／Ｏ要求をクライアント装置から受け付ける第１サーバ装置と、前記第１サーバ装置のストレージを構成する第１ストレージ装置と、第２ファイルシステムを有し、前記第１サーバ装置に通信可能に接続された第２サーバ装置と、前記第２サーバ装置のストレージを構成する第２ストレージ装置と、を備え、前記第１サーバ装置は、前記第１ストレージ装置に記憶されている、前記Ｉ／Ｏ要求の対象であるファイルのデータを前記第２サーバ装置に送信し、
　前記第２サーバ装置は、前記第１サーバ装置から送られてくる前記データを、前記第１ファイルシステムにおけるディレクトリイメージを前記第２のファイルシステムで保持しつつ、前記第２ストレージ装置に記憶する、情報処理システムであって、前記第２サーバ装置は、前記第１サーバ装置のファイルシステムに構成されていたディレクトリイメージのうちの所定の階層の第１ディレクトリイメージを、前記第２ストレージ装置に記載されているディレクトリイメージから取得して前記第１サーバ装置に送信し、前記第１サーバ装置は、前記第２サーバ装置から送られた前記第１ディレクトリイメージを前記第１ストレージ装置に復元した後、復元されようとしているファイルに対するＩ／Ｏ要求を前記クライアント装置から受け付けると、当該受け付けた前記Ｉ／Ｏ要求を処理するために必要となる第２ディレクトリイメージが前記第１ストレージ装置の前記第１ディレクトリイメージに存在するか否かを判定し、当該第２ディレクトリイメージが存在しない場合、当該第２ディレクトリイメージを前記第２サーバ装置に要求し、前記第２サーバ装置は、前記第１サーバ装置から前記要求が送られてくると、前記第２ディレクトリイメージを前記第２ストレージ装置から読み出して前記第１サーバ装置に送信し、当該第１サーバ装置は、前記第２ディレクトリイメージを前記第１ストレージ装置に復元し、前記第１サーバ装置は前記第１ディレクトリイメージと、前記第２ディレクトリイメージと、前記ファイルと、を含む、目的ディレクトリイメージを前記第１ストレージに復元し、前記第２サーバ装置の前記第２ファイルシステムは、ファイルシステムオブジェクトの作成又は更新の都度、当該作成又は更新後のファイルシステムオブジェクトを異なるバージョンＩＤで管理し、前記第１サーバ装置は前記目的ディレクトリを復元する過程で前記バージョンＩＤを利用することを特徴とする。
　本発明によれば、ユーザによるファイルアクセス要求に際して少ないストレージ消費量で迅速にファイルを復元することができる。
第一の実施形態における、情報処理システム１の概略的な構成を示す図である。 第一の実施形態における、クライアント装置２のハードウエアの一例である。 第一の実施形態における、第１サーバ装置３ａ又は第２サーバ装置３ｂとして利用可能な情報処理装置のハードウエアの一例である。 第一の実施形態における、第１ストレージ装置１０ａ又は第２ストレージ装置１０ｂのハードウエアの一例である。 第一の実施形態における、チャネル基板１１のハードウエアの一例である。 第一の実施形態における、プロセッサ基板１２のハードウエアの一例である。 第一の実施形態における、ドライブ基板１３のハードウエアの一例である。 第一の実施形態における、ストレージ装置１０が備える基本的な機能を示す図である。 第一の実施形態における、書き込み処理Ｓ９００を説明するフローチャートである。 第一の実施形態における、読み出し処理Ｓ１０００を説明するフローチャートである。 第一の実施形態における、クライアント装置２が備える主な機能を示す図である。 第一の実施形態における、第１サーバ装置３ａが備える主な機能、及び第１サーバ装置３ａにおいて管理される主な情報（データ）を示す図である。 第一の実施形態における、レプリケーション情報管理テーブル３３１の一例である。 第一の実施形態における、ファイルアクセスログ３３５の一例である。 第一の実施形態における、第２サーバ装置３ｂが備える主な機能、及び第２サーバ装置３ｂにおいて管理される主な情報（データ）を示す図である。 第一の実施形態における、リストアログ３６５の一例である。 第一の実施形態における、ｉｎｏｄｅを説明する図である。 第一の実施形態における、ｉｎｏｄｅの概念を説明する図である。 第一の実施形態における、ｉｎｏｄｅの概念を説明する図である。 第一の実施形態における、一般的なｉｎｏｄｅ管理テーブル１７１２の一例である。 第一の実施形態における、本実施形態のｉｎｏｄｅ管理テーブル１７１２の一例である。 第一の実施形態における、バージョン管理テーブル２２１の一例である。 第一の実施形態における、ディレクトリイメージ管理テーブル２３１の一例である。 第一の実施形態における、レプリケーション開始処理Ｓ２４００を説明する図である。 第一の実施形態における、スタブ化候補選出処理Ｓ２５００を説明する図である。 第一の実施形態における、スタブ化処理Ｓ２６００を説明する図である。 第一の実施形態における、レプリケーションファイル更新処理Ｓ２７００を説明する図である。 第一の実施形態における、レプリケーションファイル参照処理Ｓ２８００を説明する図である。 第一の実施形態における、メタデータアクセス処理Ｓ２９００を説明する図である。 第一の実施形態における、スタブ化ファイル実体参照処理Ｓ３０００を説明する図である。 第一の実施形態における、スタブ化ファイル実体更新処理Ｓ３１００を説明する図である。 第一の実施形態における、ディレクトリイメージ作成処理Ｓ３２００を説明する図である。 第一の実施形態における、オンデマンド復元処理Ｓ３３００を説明する図である。 第一の実施形態における、第１ストレージ装置１０ａにディレクトリイメージが復元されていく様子を説明する図である。 第一の実施形態における、ディレクトリイメージ削除処理Ｓ３５００を説明する図である。 第一の実施形態における、レプリケーション開始処理Ｓ２４００の詳細を説明するフローチャートである。 第一の実施形態における、スタブ化候補選出処理Ｓ２５００の詳細を説明するフローチャートである。 第一の実施形態における、スタブ化処理Ｓ２６００の詳細を説明するフローチャートである。 第一の実施形態における、レプリケーションファイル更新処理Ｓ２７００の詳細を説明するフローチャートである。 第一の実施形態における、レプリケーションファイル参照処理Ｓ２８００の詳細を説明するフローチャートである。 第一の実施形態における、メタデータアクセス処理Ｓ２９００の詳細を説明するフローチャートである。 第一の実施形態における、スタブ化ファイル実体参照処理Ｓ３０００の詳細を説明するフローチャートである。 第一の実施形態における、スタブ化ファイル実体更新処理Ｓ３１００の詳細を説明するフローチャートである。 第一の実施形態における、ディレクトリイメージ作成処理Ｓ３２００の詳細を説明するフローチャートである。 第一の実施形態における、オンデマンド復元処理Ｓ３３００の詳細を説明するフローチャートである。 第一の実施形態における、オンデマンド復元処理Ｓ３３００の詳細を説明するフローチャートである。 第一の実施形態における、ディレクトリイメージ削除処理Ｓ３５００の詳細を説明するフローチャートである。 第二の実施形態における、ディレクトリイメージ作成処理Ｓ３２００の詳細を説明するフローチャートである。 第二の実施形態における、オンデマンド復元処理Ｓ３３００の詳細を説明するフローチャートである。
（第一の実施形態）
　以下、発明を実施するための第一の形態について図面とともに説明する。
　図１に実施形態として説明する情報処理システム１の概略的な構成を示している。同図に示すように、本実施形態として例示する情報処理システム１は、商社や電機メーカ等の企業における支点や事業所などのように、ユーザが実際に業務を行う拠点（以下、エッジ５０（Edge）と称する。）に設けられるハードウエアと、データセンタのように、情報処理システム（アプリケーションサーバ／ストレージシステム等）の管理やクラウドサービスの提供などを行う拠点（以下、コア５１（Core）と称する。）に設けられるハードウエアと、を備える。
　同図に示すように、エッジ５０には、第１サーバ装置３ａ、第１ストレージ装置１０ａ、及びクライアント装置２が設けられている。またコア５１には、第２サーバ装置３ｂ及び第２ストレージ装置１０ｂが設けられている。
　エッジに設けられている第１サーバ装置３ａは、例えば、エッジに設けられているクライアント装置２に対してファイルを単位としたデータの管理機能を提供するファイルシステムを備えたファイルストレージ装置である。またコアに設けられている第２サーバ装置３ｂは、例えば、エッジに設けられている第１ストレージ装置１０ａに対してデータのアーカイブ（書庫）先として機能するアーカイブ装置である。
　同図に示すように、クライアント装置２と第１サーバ装置３ａとは、通信ネットワーク５を介して通信可能に接続している。また第１サーバ装置３ａと第１ストレージ装置１０ａとは、第１ストレージネットワーク６ａを介して通信可能に接続している。また第２サーバ装置３ｂと第２ストレージ装置１０ｂとは、第２ストレージネットワーク６ｂを介して通信可能に接続している。また第１サーバ装置３ａと第２サーバ装置３ｂとは、通信ネットワーク７を介して通信可能に接続している。
　通信ネットワーク５及び通信ネットワーク７は、例えば、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、公衆通信網、専用線などである。第１ストレージネットワーク６ａ及び第２ストレージネットワーク６ｂは、例えば、ＬＡＮ、ＷＡＮ、ＳＡＮ（Storage Area Network）、インターネット、公衆通信網、専用線などである。
　通信ネットワーク５、通信ネットワーク７、第１ストレージネットワーク６ａ、及び第２ストレージネットワーク６ｂを介して行われる通信は、例えば、ＴＣＰ／ＩＰ、ｉＳＣＳＩ（internet Small Computer System Interface）、ファイバーチャネルプロトコル（Fibre Channel Protocol）、ＦＩＣＯＮ（Fibre Connection）（登録商標）、ＥＳＣＯＮ（Enterprise System Connection）（登録商標）、ＡＣＯＮＡＲＣ（Advanced Connection Architecture）（登録商標）、ＦＩＢＡＲＣ（Fibre Connection Architecture）（登録商標）などのプロトコルに従って行われる。
　クライアント装置２は、第１サーバ装置３ａを介して第１ストレージ装置１０ａが提供する記憶領域を利用する情報処理装置（コンピュータ）であり、例えば、パーソナルコンピュータ、オフィスコンピュータなどである。クライアント装置２では、ファイルシステム、カーネルやドライバなどのソフトウエアモジュールによって実現されるオペレーティングシステム（Operating System）、及びアプリケーションなどが機能している。
　図２にクライアント装置２のハードウエアを示している。同図に示すように、クライアント装置２は、ＣＰＵ２１、揮発性または不揮発性のメモリ２２（ＲＡＭまたはＲＯＭ）、記憶装置２３（例えばハードディスクドライブ、半導体記憶装置（ＳＳＤ（Solid State Drive）））、キーボードやマウス等の入力装置２４、液晶モニタやプリンタ等の出力装置２５、及びＮＩＣ（Network Interface Card）（以下、ＬＡＮアダプタ２６１と称する。）等の通信インタフェース（通信Ｉ／Ｆ２６と称する。）を備えている。
　第１サーバ装置３ａは、第１ストレージ装置１０ａが提供する記憶領域を利用してクライアント装置２に情報処理サービスを提供する情報処理装置である。第１サーバ装置３ａは、パーソナルコンピュータ、メインフレーム（Mainframe）、オフィスコンピュータなどを用いて構成されている。第１サーバ装置３ａは、第１ストレージ装置１０ａが提供する記憶領域へのアクセスに際し、データＩ／Ｏ要求（データ書き込み要求、データ読み出し要求等）を含んだデータフレーム（以下、フレームと略記する。）を、第１ストレージネットワーク６ａを介して第１ストレージ装置１０ａに送信する。尚、上記フレームは、例えば、ファイバーチャネルのフレーム（ＦＣフレーム（FC:Fibre Channel））である。
　第２サーバ装置３ｂは、第２ストレージ装置１０ｂが提供する記憶領域を利用して情報処理を行う情報処理装置である。第２サーバ装置３ｂは、パーソナルコンピュータ、メインフレーム、オフィスコンピュータなどを用いて構成されている。第２サーバ装置３ｂは、第２ストレージ装置１０ｂが提供する記憶領域へのアクセスに際し、データＩ／Ｏ要求を含んだフレームを、第２ストレージネットワーク６ｂを介して第２ストレージ装置１０ｂに送信する。
　図３に第１サーバ装置３ａのハードウエアを示している。同図に示すように、第１サーバ装置３ａは、ＣＰＵ３１、揮発性または不揮発性のメモリ３２（ＲＡＭまたはＲＯＭ）、記憶装置３３（例えばハードディスクドライブ、半導体記憶装置（ＳＳＤ））、キーボードやマウス等の入力装置３４、液晶モニタやプリンタ等の出力装置３５、ＮＩＣ（以下、ＬＡＮアダプタ３６１と称する。）やＨＢＡ（以下、ＦＣアダプタ３６２と称する。）等の通信インタフェース（通信Ｉ／Ｆ３６と表記する。）、及びタイマ回路やＲＴＣ等を用いて構成される計時装置３７を備えている。尚、コア側に存在する第２サーバ装置３ｂも第１サーバ装置３ａと同一又は類似のハードウエア構成を有する。
　図４に第１ストレージ装置１０ａのハードウエアを示している。第１ストレージ装置１０ａは、例えばディスクアレイ装置である。尚、コア側に存在する第２ストレージ装置１０ｂも第１ストレージ装置１０ａと同一又は類似のハードウエア構成を有する。ストレージ装置１０は、サーバ装置３（第１サーバ装置３ａ又は第２サーバ装置３ｂ。以下同様）から送られてくるデータＩ／Ｏ要求を受け付け、受け付けたデータＩ／Ｏ要求に応じて記録媒体にアクセスしてサーバ装置３にデータやレスポンスを送信する。
　同図に示すように、ストレージ装置１０は、一つ以上のチャネル基板１１、一つ以上のプロセッサ基板１２（Micro Processor）、一つ以上のドライブ基板１３、キャッシュメモリ１４（Cache Memory）、共有メモリ１５（Shared Memory）、内部スイッチ１６、記憶装置１７、及び保守装置１８（SVP:SerVice Processor）を備える。チャネル基板１１、プロセッサ基板１２、ドライブ基板１３、キャッシュメモリ１４、及び共有メモリ１５は、内部スイッチ１６を介して互いに通信可能に接続されている。
　チャネル基板１１は、サーバ装置３から送られてくるフレームを受信し、受信したフレームに含まれているデータＩ／Ｏ要求についての処理の応答（例えば読み出したデータ、読み出し完了報告、書き込み完了報告）を含んだフレームをサーバ装置３に送信する。
　プロセッサ基板１２は、チャネル基板１１が受信したフレームに含まれている上記データＩ／Ｏ要求に応じて、チャネル基板１１、ドライブ基板１３、及びキャッシュメモリ１４の間で行われるデータ転送（ＤＭＡ（Direct Memory Access）等を用いた高速大容量のデータ転送)に関する処理を行う。プロセッサ基板１２は、キャッシュメモリ１４を介して行われる、チャネル基板１１とドライブ基板１３との間のデータ（記憶装置１７から読み出したデータ、記憶装置１７に書き込むデータ）の転送（引き渡し）や、キャッシュメモリ１４に格納されるデータのステージング（記憶装置１７からのデータの読み出し）及びデステージング（記憶装置１７への書き出し）等を行う。
　キャッシュメモリ１４は、高速アクセスが可能なＲＡＭ（Random Access Memory）を用いて構成されている。キャッシュメモリ１４には、記憶装置１７に書き込まれるデータ（以下、書き込みデータと称する。）や記憶装置１７から読み出されたデータ（以下、読み出しデータと記載する。）等が格納される。共有メモリ１５には、ストレージ装置１０の制御に用いられる様々な情報が格納される。
　ドライブ基板１３は、記憶装置１７からのデータの読み出しや記憶装置１７へのデータの書き込みに際して記憶装置１７と通信を行う。内部スイッチ１６は、例えば高速クロスバースイッチ（Cross Bar Switch）を用いて構成される。尚、内部スイッチ１６を介して行われる通信は、例えば、ファイバーチャネル、ｉＳＣＳＩ、ＴＣＰ／ＩＰ等のプロトコルに従って行われる。
　記憶装置１７は、複数の記憶ドライブ１７１を備えて構成されている。記憶ドライブ１７１は、例えば、ＳＡＳ（Serial Attached SCSI）、ＳＡＴＡ（Serial ATA）、ＦＣ（Fibre Channel）、ＰＡＴＡ（Parallel ATA）、ＳＣＳＩ等のタイプのハードディスクドライブ、半導体記憶装置（ＳＳＤ）等である。
　記憶装置１７は、記憶ドライブ１７１を、例えば、ＲＡＩＤ（Redundant Arrays of Inexpensive （or Independent) Disks）等の方式で制御することによって提供される論理的な記憶領域を単位としてサーバ装置３に記憶装置１７の記憶領域を提供する。この論理的な記憶領域は、例えばＲＡＩＤグループ（パリティグループ（Parity Group））を用いて構成される論理装置（ＬＤＥＶ１７２（LDEV:Logical Device））である。
　またストレージ装置１０は、サーバ装置３に対してＬＤＥＶ１７２を用いて構成される論理的な記憶領域（以下、ＬＵ（Logical Unit、Logical Volume、論理ボリューム）と称する。）を提供する。ストレージ装置１０は、ＬＵとＬＤＥＶ１７２との対応（関係）を管理しており、ストレージ装置１０は、この対応に基づきＬＵに対応するＬＤＥＶ１７２の特定、もしくは、ＬＤＥＶ１７２に対応するＬＵの特定を行う。
　図５にチャネル基板１１のハードウエア構成を示している。同図に示すように、チャネル基板１１は、サーバ装置３と通信するためのポート（通信ポート）を有する外部通信インタフェース（以下、外部通信Ｉ／Ｆ１１１と表記する。）、プロセッサ１１２（フレーム処理チップ及びフレーム転送チップを含む）、メモリ１１３、プロセッサ基板１２と通信するためのポート（通信ポート）を有する内部通信インタフェース（以下、内部通信Ｉ／Ｆ１１４と表記する。）を備えている。
　外部通信Ｉ／Ｆ１１１は、ＮＩＣ（Network Interface Card）やＨＢＡ（Host Bus Adaptor）等を用いて構成されている。プロセッサ１１２は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等を用いて構成されている。メモリ１１３は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）である。メモリ１１３にはマイクロプログラムが格納されている。プロセッサ１１２が、メモリ１１３から上記マイクロプログラムを読み出して実行することにより、チャネル基板１１が提供する各種の機能が実現される。内部通信Ｉ／Ｆ１１４は、内部スイッチ１６を介してプロセッサ基板１２、ドライブ基板１３、キャッシュメモリ１４、共有メモリ１５と通信する。
　図６にプロセッサ基板１２のハードウエア構成を示している。プロセッサ基板１２は、内部通信インタフェース（以下、内部通信Ｉ／Ｆ１２１と表記する。）、プロセッサ１２２、及び共有メモリ１５に比べてプロセッサ１２２からのアクセス性能が高い（高速アクセスが可能な）メモリ１２３（ローカルメモリ）を備えている。メモリ１２３にはマイクロプログラムが格納されている。プロセッサ１２２が、メモリ１２３から上記マイクロプログラムを読み出して実行することにより、プロセッサ基板１２が提供する各種の機能が実現される。
　内部通信Ｉ／Ｆ１２１は、内部スイッチ１６を介してチャネル基板１１、ドライブ基板１３、キャッシュメモリ１４、及び共有メモリ１５と通信を行う。プロセッサ１２２は、ＣＰＵ、ＭＰＵ、ＤＭＡ（Direct Memory Access）等を用いて構成されている。メモリ１２３は、ＲＡＭ又はＲＯＭである。プロセッサ１２２は、メモリ１２３及び共有メモリ１５のいずれにもアクセスすることができる。
　図７にドライブ基板１３のハードウエア構成を示している。ドライブ基板１３は、内部通信インタフェース（以下、内部通信Ｉ／Ｆ１３１と表記する。）、プロセッサ１３２、メモリ１３３、及びドライブインタフェース（以下、ドライブＩ／Ｆ１３４と表記する。）を備えている。メモリ１３３にはマイクロプログラムが格納されている。プロセッサ１３２が、メモリ１３３から上記マイクロプログラムを読み出して実行することにより、ドライブ基板１３が提供する各種の機能が実現される。内部通信Ｉ／Ｆ１３１は、内部スイッチ１６を介して、チャネル基板１１、プロセッサ基板１２、キャッシュメモリ１４、及び共有メモリ１５と通信する。プロセッサ１３２は、ＣＰＵ、ＭＰＵ等を用いて構成されている。メモリ１３３は、例えば、ＲＡＭ、ＲＯＭである。ドライブＩ／Ｆ１３４は、記憶装置１７との間で通信を行う。
　図４に示した保守装置１８は、ストレージ装置１０の各構成要素の制御や状態監視を行う。保守装置１８は、パーソナルコンピュータやオフィスコンピュータ等である。保守装置１８は、内部スイッチ１６又はＬＡＮ等の通信手段を介してチャネル基板１１、プロセッサ基板１２、ドライブ基板１３、キャッシュメモリ１４、共有メモリ１５、及び内部スイッチ１６等のストレージ装置１０の構成要素と随時通信を行い、各構成要素から稼働情報等を取得して管理装置１９に提供する。また保守装置１８は管理装置１９から送られてくる制御情報や稼働情報に基づき、各構成要素の設定や制御、保守（ソフトウエアの導入や更新を含む）を行う。
　管理装置１９は、保守装置１８とＬＡＮ等を介して通信可能に接続されるコンピュータである。管理装置１９はストレージ装置１０の制御や監視のためのＧＵＩ（Graphical User Interface）やＣＬＩ（Command Line Interface）等を用いたユーザインタフェースを備える。
　図８にストレージ装置１０が備える基本的な機能を示している。同図に示すように、ストレージ装置１０は、Ｉ／Ｏ処理部８１１を備えている。Ｉ／Ｏ処理部８１１は、記憶装置１７への書き込みに関する処理を行うデータ書き込み処理部８１１１、記憶装置１７からのデータの読み出しに関する処理を行うデータ読み出し処理部８１１２を備えている。
　尚、Ｉ／Ｏ処理部８１１の機能は、ストレージ装置１０のチャネル基板１１やプロセッサ基板１２、ドライブ基板１３が備えるハードウエアにより、又はプロセッサ１１２，１２２，１３２が、メモリ１１３，１２３，１３３に格納されているマイクロプログラムを読み出して実行することにより実現される。
　図９は、ストレージ装置１０（第１ストレージ装置１０ａ又は第２ストレージ装置１０ｂ。以下同様。）がサーバ装置３（第１サーバ装置３ａ又は第２サーバ装置３ｂ）からデータ書き込み要求を含んだフレームを受信した場合に、Ｉ／Ｏ処理部８１のデータ書き込み処理部８１１１によって行われる基本的な処理（以下、書き込み処理Ｓ９００と称する。）を説明するフローチャートである。以下、同図とともに書き込み処理Ｓ９００について説明する。尚、以下の説明において、符号の前に付している「Ｓ」の文字は処理ステップを意味している。
　同図に示すように、まずサーバ装置３から送信されてくるデータ書き込み要求のフレームが、ストレージ装置１０のチャネル基板１１によって受信される（Ｓ９１１，Ｓ９１２）。
　チャネル基板１１は、サーバ装置３からデータ書き込み要求を含んだフレームを受信すると、その旨をプロセッサ基板１２に通知する（Ｓ９１３）。
　プロセッサ基板１２は、チャネル基板１１から上記通知を受信すると（Ｓ９２１）、当該フレームのデータ書き込み要求に基づくドライブ書き込み要求を生成し、書き込みデータをキャッシュメモリ１４に格納し、チャネル基板１１に上記通知の受信通知を応答する（Ｓ９２２）。またプロセッサ基板１２は、生成したドライブ書き込み要求をドライブ基板１３に送信する（Ｓ９２３）。
　一方、チャネル基板１１は、プロセッサ基板１２からの上記応答を受信すると、サーバ装置３に完了報告を送信し（Ｓ９１４）、サーバ装置３は、チャネル基板１１から完了報告を受信する（Ｓ９１５）。
　ドライブ基板１３は、プロセッサ基板１２からドライブ書き込み要求を受信すると、受信したドライブ書き込み要求を書き込み処理待ちキューに登録する（Ｓ９２４）。
　ドライブ基板１３は、書き込み処理待ちキューからドライブ書き込み要求を随時読み出し（Ｓ９２５）、読み出したドライブ書き込み要求に指定されている書き込みデータをキャッシュメモリ１４から読み出して、読み出した書き込みデータを記憶装置（記憶ドライブ１７１）に書き込む（Ｓ９２６）。そしてドライブ基板１３は、ドライブ書き込み要求について書き込みデータの書き込みが完了した旨の報告（完了報告）をプロセッサ基板１２に通知する（Ｓ９２７）。
　プロセッサ基板１２は、ドライブ基板１３から送られてきた完了報告を受信する（Ｓ９２８）。
　図１０は、ストレージ装置１０が、サーバ装置３からデータ読み出し要求を含んだフレームを受信した場合に、ストレージ装置１０のＩ／Ｏ処理部８１１の読み出し処理部８１１２によって行われるＩ／Ｏ処理（以下、読み出し処理Ｓ１０００と称する。）を説明するフローチャートである。以下、同図とともに読み出し処理Ｓ１０００について説明する。
　同図に示すように、まずサーバ装置３から送信されてくるフレームが、ストレージ装置１０のチャネル基板１１によって受信される（Ｓ１０１１，Ｓ１０１２）。
　チャネル基板１１は、サーバ装置３からデータ読み出し要求を含んだフレームを受信すると、その旨をプロセッサ基板１２及びドライブ基板１３に通知する（Ｓ１０１３）。
　ドライブ基板１３は、チャネル基板１１から上記通知を受信すると（Ｓ１０１４）、当該フレームに含まれているデータ読み出し要求に指定されているデータ（例えばＬＢＡ（Logical Block Address）によって指定される）を、記憶装置（記憶ドライブ１７１）から読み出す（Ｓ１０１５）。尚、キャッシュメモリ１４に読み出しデータが存在する場合（キャッシュヒットした場合）には、記憶装置１７からの読み出し処理（Ｓ１０１５）は省略される。
　プロセッサ基板１２は、ドライブ基板１３によって読み出されたデータをキャッシュメモリ１４に書き込む（Ｓ１０１６）。そしてプロセッサ基板１２は、キャッシュメモリ１４に書き込んだデータをチャネル基板１１に随時転送する（Ｓ１０１７）。
　チャネル基板１１は、プロセッサ基板１２から随時送られてくる読み出しデータを受信すると、それらをサーバ装置３に順次送信する（Ｓ１０１８）。読み出しデータの送信が完了すると、チャネル基板１１は、サーバ装置３に完了報告を送信する（Ｓ１０１９）。サーバ装置３は、読み出しデータ及び完了報告を受信する（Ｓ１０２０，Ｓ１０２１）。
　図１１にクライアント装置２が備える主な機能を示している。同図に示すように、クライアント装置２は、アプリケーション２１１、ファイルシステム２１２、及びカーネル／ドライバ２１３の各機能を備える。尚、これらの機能は、クライアント装置２のＣＰＵ２１が、メモリ２２や記憶装置２３に格納されているプログラムを読み出して実行することにより実現される。
　ファイルシステム２１２は、クライアント装置２に対してファイル単位又はディレクトリ単位での論理ボリューム（ＬＵ）へのＩ／Ｏ機能を実現する。ファイルシステム２１３は、例えば、ＦＡＴ(File Allocation Table）、ＮＴＦＳ、ＨＦＳ（Hierarchical File System）、ｅｘｔ２（second extended file system）、ｅｘｔ３(third extended file system)、ｅｘｔ４(fourth extended file system)、ＵＤＦ（Universal Disk Format）、ＨＰＦＳ（High Performance File system）、ＪＦＳ（Journaled File System）、ＵＦＳ（Unix File System）、ＶＴＯＣ(Volume Table Of Contents)、ＸＦＳ等である。
　カーネル／ドライバ２１３は、オペレーティングシステムのソフトウエアを構成しているカーネルモジュールやドライバモジュールを実行することにより実現される。カーネルモジュールには、クライアント装置２において実行されるソフトウエアについて、プロセスの管理、プロセスのスケジューリング、記憶領域の管理、ハードウエアからの割り込み要求のハンドリング等、オペレーティングシステムが備える基本的な機能を実現するためのプログラムが含まれている。ドライバモジュールには、クライアント装置２を構成しているハードウエアやクライアント装置２に接続して用いられる周辺機器とカーネルモジュールとが通信するためのプログラム等が含まれている。
　図１２に第１サーバ装置３ａが備える主な機能、及び第１サーバ装置３ａにおいて管理される主な情報（データ）を示している。同図に示すように、第１サーバ装置３ａでは、仮想環境を提供する仮想化制御部３０５、及びこの仮想化制御部３０５の制御の下で動作する１つ以上の仮想マシン３１０が実現されている。
　各仮想マシン３１０では、ファイル共有処理部３１１、ファイルシステム３１２、データ操作要求受付部３１３、データ複製／移動処理部３１４、ファイルアクセスログ取得部３１７、及びカーネル／ドライバ３１８の各機能が実現されている。
　尚、仮想環境は、第１サーバ装置３ａのハードウエアと仮想化制御部３０５との間にオペレーティングシステムを介在させるいわゆるホストＯＳ型、もしくは第１サーバ装置３ａのハードウエアと仮想化制御部３０５との間にオペレーティングシステムを介在させないハイパーバイザー型のいずれの方式で実現されていてもよい。またデータ操作要求受付部３１３、データ複製／移動処理部３１４、ファイルアクセスログ取得部３１７の各機能は、ファイルシステム３１２の機能として実現してもよいし、ファイルシステム３１２とは独立した機能として実現してもよい。
　同図に示すように、各仮想マシン３１０は、レプリケーション情報管理テーブル３３１、ファイルアクセスログ３３５などの情報（データ）を管理している。これらの情報は、第１ストレージ１０ａから第１サーバ装置３ａに随時読み出されて第１サーバ装置３ａのメモリ３２や記憶装置３３に格納される。
　同図に示す機能のうち、ファイル共有処理部３１１は、クライアント装置２にファイルの共有環境を提供する。ファイル共有処理部３１１は、例えば、ＮＦＳ（Network File System）、ＣＩＦＳ（Common Internet File System）、ＡＦＳ（Andrew File System）等のプロトコルに従った機能を提供する。
　ファイルシステム３１２は、クライアント装置２に対して、第１ストレージ装置１０ａによって提供される論理ボリューム（ＬＵ）に管理されるファイル（又はディレクトリ）に対するＩ／Ｏ機能を提供する。ファイルシステム３１２は、例えばＦＡＴ(File Allocation Table）、ＮＴＦＳ、ＨＦＳ（Hierarchical File System）、ｅｘｔ２（second extended file system）、ｅｘｔ３(third extended file system)、ｅｘｔ４(fourth extended file system)、ＵＤＦ（Universal Disk Format）、ＨＰＦＳ（High Performance File system）、ＪＦＳ（Journaled File System）、ＵＦＳ（Unix File System）、ＶＴＯＣ(Volume Table Of Contents)、ＸＦＳ等である。
　データ操作要求受付部３１３は、クライアント装置２から送信されてくるデータの操作に関する要求（以下、データ操作要求と称する。）を受け付ける。データ操作要求には、後述する、レプリケーション開始要求、レプリケーションファイルに対する更新要求、レプリケーションファイルに対する参照要求、同期要求、メタデータに対するアクセス要求、ファイルの実体に対する参照要求、リコール要求、スタブ化ファイルの実体に対する更新要求などがある。
　尚、スタブ化とは、ファイル（又はディレクトリ）のデータのメタデータについては第１ストレージ装置１０ａにて保持するが、ファイル（又はディレクトリ）のデータの実体については第１ストレージ装置１０ａ側では管理せず、第２ストレージ装置１０ｂにおいてのみ保持するようにすることをいう。スタブ化されたファイル（又はディレクトリ）に対してそのファイル（又はディレクトリ）の実体が必要になるようなデータＩ／Ｏ要求を第１サーバ装置３ａが受け付けた場合には、そのファイル（又はディレクトリ）の実体が第２ストレージ装置１０ｂから第１ストレージ装置１０ａに送信される（書き戻される（以下、リコールと称する。））。
　データ複製／移動処理部３１４は、後述する、レプリケーション開始処理Ｓ２４００、スタブ化候補選出処理Ｓ２５００、同期処理Ｓ２９００、スタブ化ファイル実体参照処理Ｓ３０００、スタブ化ファイル実体更新処理Ｓ３１００、仮想マシン復旧処理Ｓ３３００、ディレクトリイメージ作成処理Ｓ３２００、オンデマンド復元処理Ｓ３３００、などにおいて、第１サーバ装置３ａと第２サーバ装置３ｂとの間、もしくは、第１ストレージ装置１０ａと第２ストレージ装置１０ｂとの間での制御情報（フラグやテーブルを含む）の授受やデータ(ファイルのメタデータや実体を含む）の転送、レプリケーション情報管理テーブル３３１、メタデータ３３２などの各種テーブルの管理を行う。
　図１２に示すカーネル／ドライバ３１８は、オペレーティングシステムのソフトウエアを構成しているカーネルモジュールやドライバモジュールを実行することにより実現される。カーネルモジュールには、第１サーバ装置３ａにおいて実行されるソフトウエアについて、プロセスの管理、プロセスのスケジューリング、記憶領域の管理、ハードウエアからの割り込み要求のハンドリング等、オペレーティングシステムが備える基本的な機能を実現するためのプログラムが含まれる。ドライバモジュールには、第１サーバ装置３ａを構成しているハードウエアや第１サーバ装置３ａに接続して用いられる周辺機器とカーネルモジュールとが通信するためのプログラムが含まれる。
　図１２に示すファイルアクセスログ取得部３１７は、ストレージ装置１０の論理ボリューム（ＬＵ）に格納されているファイルへのアクセス（ファイルの更新（Write,Update）、ファイルの読み出し（Read）、ファイルのオープン（Open）、ファイルのクローズ（Close）等）が行われると、そのアクセスの内容（履歴）を示す情報（以下、アクセスログと称する。）を、計時装置３７から取得される日時情報に基づくタイムスタンプを付与してファイルアクセスログ３３５として記憶する。
　図１３にレプリケーション情報管理テーブル３３１の一例を示している。同図に示すように、レプリケーション情報管理テーブル３３１には、レプリケーション先となるホスト名３３１１（例えばＩＰアドレス等のネットワークアドレス。）、スタブ化するか否かの判断に用いる閾値３３１２（後述するスタブ化閾値）が設定される。
　図１４にファイルアクセスログ３３５の一例を示している。同図に示すように、ファイルアクセスログ３３５には、アクセス日時３３５１、ファイル名３３５２、及びユーザＩＤ３３５３の各項目からなる一つ以上のレコードで構成されるアクセスログが記録される。
　このうちアクセス日時３３５１には、そのファイル（又はディレクトリ）に対するアクセスがされた日時が設定される。ファイル名３３５２には、アクセス対象となったファイル（又はディレクトリ）のファイル名（又はディレクトリ名）が設定される。ユーザＩＤ３３５３には、そのファイル（又はディレクトリ）にアクセスしたユーザのユーザＩＤが設定される。
　図１５に第２サーバ装置３ｂが備える主な機能、及び第２サーバ装置３ｂにおいて管理される主な情報（データ）を示している。同図に示すように、第２サーバ装置３ｂは、ファイル共有処理部３５１、ファイルシステム３５２、データ複製／移動処理部３５４、及びカーネル／ドライバ３５８の各機能を備えている。尚、データ複製／移動処理部３５４の機能は、ファイルシステム３５２の機能として実現してもよいし、ファイルシステム３５２とは独立した機能として実現してもよい。
　また同図に示すように、第２サーバ装置３ｂは、リストアログ３６５及びファイルアクセスログ３６８を管理している。
　ファイル共有処理部３５１は、第１サーバ装置３ａに対してファイルの共有環境を提供する。ファイル共有処理部３５１は、例えばＨＴＴＰプロトコルを用いて実現されている。
　ファイルシステム３５２は、第２ストレージ装置１０ｂによって提供される論理ボリューム（ＬＵ）を用い、第１サーバ装置３ａに対してファイル単位又はディレクトリ単位での論理ボリューム（ＬＵ）へのＩ／Ｏ機能を提供する。さらに、ファイルシステム３５２は、ファイルやディレクトリのバージョン管理を行うことで、第１サーバ装置３aに対して、最新を含む過去のある時点のファイルやディレクトリを提供する。後述のようにバージョン管理を行うファイルシステムは、ファイルの作成や削除、ファイルのデータやメタデータの変更、ディレクトリの作成や削除、及びディレクトリへのエントリの追加や削除に際して、ファイルやディレクトリを上書きすることなくファイル、及び/又はディレクトリを保持する。
　ファイルシステム３５２は、例えば、ｅｘｔ３ｃｏｗのような１つのファイルシステムであってもよいし、Ｗａｙｂａｃｋのようにｅｘｔ３やＲｅｉｓｅｒＦＳ、ＦＡＴなどの既存のファイルシステムと組み合わせたファイルシステムであってもよい。
　データ複製／移動処理部３５４は、第１ストレージ装置１０ａと第２ストレージ装置１０ｂとの間でのデータの移動や複製に関する処理を行う。
　カーネル／ドライバ３５８は、オペレーティングシステムのソフトウエアを構成しているカーネルモジュールやドライバモジュールを実行することにより実現される。カーネルモジュールには、第２サーバ装置３ｂにおいて実行されるソフトウエアについて、プロセスの管理、プロセスのスケジューリング、記憶領域の管理、ハードウエアからの割り込み要求のハンドリング等、オペレーティングシステムが備える基本的な機能を実現するためのプログラムが含まれる。ドライバモジュールには、第２サーバ装置３ｂを構成しているハードウエアや第２サーバ装置３ｂに接続して用いられる周辺機器とカーネルモジュールとが通信するためのプログラムが含まれる。
　図１６にリストアログ３６５の一例を示している。リストアログ３６５は、後述するディレクトリイメージの作成（これをリストアと呼ぶ）が行われた場合に、第１サーバ装置３ａ又は第２サーバ装置３ｂによって復元に関する処理の内容が記録される。同図に示すように、リストアログ３６５は、日時３６５１、イベント３６５２、及びリストア対象ファイル３６５３の各項目を有する一つ以上のレコードで構成される。
　このうち日時３６５１には、リストアに関するイベントが実行された日時が設定される。イベント３６５２には、実行されたイベントの内容を示す情報（リストア開始、リストア実行等）が設定される。リストア対象ファイル３６５３には、リストアの対象となったファイル（又はディレクトリ）を特定する情報（パス名、ファイル名（又はディレクトリ名）等）が設定される。
　第２サーバ装置３ｂが管理しているファイルアクセスログ３６８の内容は、第１サーバ装置３ａにおけるファイルアクセスログ３３５の内容に基本的に一致している。第１サーバ装置３ａからファイルアクセスログ３３５の内容を第２サーバ装置３ｂに随時通知することにより、両者の同一性が確保されている。
　次に第１サーバ装置３ａが備えるファイルシステム３１２について詳細に説明する。
　図１７は、ファイルシステム３１２が論理ボリューム（ＬＵ）上に管理するデータの構造（以下、ファイルシステム構造１７００と称する。）の一例である。同図に示すように、ファイルシステム構造１７００には、スーパーブロック１７１１、ｉｎｏｄｅ管理テーブル１７１２、ファイルの実体（データ）が格納されるデータブロック１７１３の各記憶領域が含まれている。
　このうちスーパーブロック１７１１には、ファイルシステム３１２に関する情報（ファイルシステムが取り扱う記憶領域の容量、使用量、空き容量等）が格納される。スーパーブロック１７１１は、原則としてディスク区画（論理ボリューム（ＬＵ）上に設定されるパーティション）ごとに設けられる。スーパーブロック１７１１に格納される上記情報の具体例として、区画内のデータブロック数、ブロックサイズ、空きブロック数、空きｉｎｏｄｅ数、当該区画のマウント数、最新の整合性チェック時からの経過時間等がある。
　ｉｎｏｄｅ管理テーブル１７１２には、論理ボリューム（ＬＵ）に格納されるファイル（又はディレクトリ）の管理情報（以下、ｉｎｏｄｅと称する。）が格納される。ファイルシステム３１２は、１つのファイル（又はディレクトリ）に対して１つのｉｎｏｄｅを対応させて管理している。ｉｎｏｄｅのうちディレクトリに関する情報のみを含むものはディレクトリエントリと称される。ファイルに対するアクセスが行われる場合にはディレクトリエントリを参照してアクセス対象のファイルのデータブロックにアクセスする。例えば、「/home/user-01/a.txt」というファイルにアクセスする場合には、図２０に示すように、ｉｎｏｄｅ番号２→１０→１５→１００とディレクトリエントリを順に辿ってアクセス対象ファイルのデータブロックにアクセスする。
　図１９に一般的なファイルシステム（例えば、ＵＮＩＸ（登録商標）系のオペレーティングシステムが備えるファイルシステム）におけるｉｎｏｄｅの概念を示している。また図２０にｉｎｏｄｅ管理テーブル１７１２の一例を示している。
　これらの図に示すように、ｉｎｏｄｅには、個々のｉｎｏｄｅを区別する識別子であるｉｎｏｄｅ番号２０１１、当該ファイル（又はディレクトリ）の所有者２０１２、当該ファイル（又はディレクトリ）について設定されているアクセス権２０１３、当該ファイル（又はディレクトリ）のファイルサイズ２０１４、当該ファイル（又はディレクトリ）の最終更新日時２０１５、当該ｉｎｏｄｅがディレクトリエントリである場合に設定される当該ディレクトリの親ディレクトリ２０１６、当該ｉｎｏｄｅがディレクトリエントリである場合に設定される当該ディレクトリの子ディレクトリ２０１７、当該ファイルのデータの実体が格納されるデータブロックを特定する情報（以下、ブロックアドレス２０１８と称する。）などの情報が含まれる。
　図２１に示すように、本実施形態のファイルシステム３１２は、図２０に示した通常の一般的なファイルシステムにおけるｉｎｏｄｅ管理テーブル１７１２の内容に加えて、更にスタブ化フラグ２１１１、メタデータ同期要フラグ２１１２、実体同期要フラグ２１１３、レプリケーションフラグ２１１４、読み取り専用フラグ２１１５、及びリンク先２１１６を管理している。
　尚、レプリケーションによる管理方式やスタブ化による管理方式により、第１ストレージ装置１０ａに記憶されているファイルのメタデータ（図２１に示した各種のフラグを含む。）の複製が第２ストレージ装置１０ｂにも記憶されている場合（レプリケーションされている場合）には、後述する同期処理Ｓ２９００によって一方の装置のメタデータが更新されるとその旨が他方の装置にも通知される。これにより第１ストレージ装置１０ａのメタデータと第２ストレージ装置１０ｂのメタデータの内容の同一性がほぼリアルタイムに確保される。
　同図において、スタブ化フラグ２１１１には、当該ｉｎｏｄｅに対応するファイル（又はディレクトリ）がスタブ化されているか否かを示す情報が設定される。ここでスタブ化とは、第１ストレージ装置１０ａから第２ストレージ装置１０ｂにファイル（又はディレクトリ）を移動（マイグレーション）するに際し、移動元の第１ストレージ装置１０ａからそのファイルのデータのうち実体のみ削除し、そのファイルのデータのうちメタデータについては削除せずに移動元の第１ストレージ装置１０ａに残すことをいう。
　尚、スタブ（stub）とは、その場合に第１ストレージ装置１０ａに残留するメタデータのことをいう。当該ｉｎｏｄｅに対応するファイル（又はディレクトリ）がスタブ化されている場合はスタブ化フラグ２１１１にＯＮが設定され、スタブ化されていない場合はスタブ化フラグ２１１１にＯＦＦが設定される。
　メタデータ同期要フラグ２１１２には、複製元の第１ストレージ装置１０ａのファイル（又はディレクトリ）のメタデータと複製先の第２ストレージ装置１０ｂのファイル（又はディレクトリ）のメタデータとの間で同期をとる必要（内容を一致させる必要）が有るか否かを示す情報が設定される。メタデータの同期が必要な場合はメタデータ同期要フラグ２１１２にＯＮが設定され、同期が不要な場合はメタデータ同期要フラグ２１１２にＯＦＦが設定される。
　実体同期要フラグ２１１３には、複製元の第１ストレージ装置１０ａのファイルのデータの実体と複製先の第２ストレージ装置１０ｂのファイルのデータの実体との間で同期をとる必要（内容を一致させる必要）が有るか否かを示す情報が設定される。ファイルのデータの実体について同期が必要な場合は実体同期要フラグ２１１３にＯＮが設定され、同期が不要な場合は実体同期要フラグ２１１３にＯＦＦが設定される。
　メタデータ同期要フラグ２１１２及び実体同期要フラグ２１１３は、後述する同期処理Ｓ２９００において随時参照される。メタデータ同期要フラグ２１１２、もしくは実体同期要フラグ２１１３がＯＮになっている場合は、第１ストレージ装置１０ａのメタデータ又は実体と、その複製である第２ストレージ装置１０ｂのメタデータ又は実体とが自動的に同期される。
　レプリケーションフラグ２１１４には、そのｉｎｏｄｅに対応するファイル（又はディレクトリ）が、現在後述するレプリケーション管理方式による管理の対象になっているか否かを示す情報が設定される。当該ｉｎｏｄｅに対応するファイルが、現在、レプリケーション管理方式による管理の対象になっている場合はレプリケーションフラグ２１１４にＯＮが設定され、レプリケーションによる管理の対象になっていない場合はレプリケーションフラグ２１１４にＯＦＦが設定される。
　読み取り専用フラグ２１１５は、そのｉｎｏｄｅに対応するファイル（又はディレクトリ）が、クライアント装置２によって書き込まれることが可能か否かを示す情報が設定される。当該ｉｎｏｄｅに対応するファイル（又はディレクトリ）が、書き込まれることが不可能な場合は読み取り専用フラグ２１１５にＯＮが設定され、書き込まれることが可能な場合は読み取り専用フラグ２１１５にＯＦＦが設定される。
　尚、クライアント装置２以外の主体、例えばファイルシステム３１２とデータ複製／移動処理部３１４は、読み取り専用フラグ２１１５にＯＮが設定されたファイルに書き込むことができる。
　尚、読み取り専用フラグ２１１５の設定は、アクセス権２０１３の設定と互いに独立である。例えば、クライアント装置２は、読み取り専用フラグ２１１５にＯＮが設定され、かつ、アクセス権２０１３で書き込み可能に設定されたファイルに、書き込むことができない。これにより、ファイルに対する、ACLやUNIXパーミッション等公知のアクセス権２０１３のビューをそのままにして書き込みを防ぐ事ができる。
　リンク先２１１６には、そのｉｎｏｄｅに対応するファイルが、後述するレプリケーション管理方式で管理されている場合は、そのファイルの複製先を示す情報（例えば、格納先を特定するパス名（後述するバージョンＩＤを含む）、ＲＡＩＤグループの識別子、ブロックアドレス、ＵＲＬ（Uniform Resource Locator）、ＬＵ等）が設定される。
　次に第２サーバ装置３ｂが備えるファイルシステム３５２について詳細に説明する。ファイルシステム３５２は、第１サーバ装置３ａが備えるファイルシステム３１２に加えて、ファイル（又はディレクトリ）のバージョンを管理・操作するために必要な、バージョン管理テーブル２２１を備える。
　図２２に、バージョン管理テーブル２２１の一例を示している。ファイルシステム３５２は、バージョン管理テーブル２２１を、一つのファイル（又はディレクトリ）毎に対して１つ維持する。なお、ファイル及びディレクトリを総称して、ファイルシステムオブジェクトと呼ぶ。
　同図に示すように、バージョン管理テーブル２２１には、格納日時２２１１及びバージョンＩＤ２２１２の各項目からなる一つ以上のレコードで構成されるエントリが記録される。格納日時２２１１には、そのファイル（又はディレクトリ）がファイルシステム３５２に格納された日時が設定される。バージョンＩＤ２２１２には、そのファイル（又はディレクトリ）の特定のバージョンにアクセスするために必要な名前が設定される。バージョンＩＤ２２１２に設定される名前は、例えば、連続した数字やランダムに生成された一定の長さを持つ文字列（一般にＵＵＩＤと呼ばれる）である。バージョンＩＤ２２１２は、ユーザ（例えばクライアント装置２や第１サーバ装置３ａ）によって設定されてもよいし、システム（例えば、ファイルシステム３５２）によって設定されてもよい。
　ファイルシステム３５２は、ファイル（又はディレクトリ）が初めて作成された時にバージョン管理テーブル２２１を作成し、ファイルシステム３５２は、ファイル（又はディレクトリ）の全てのバージョンが削除されると、バージョン管理テーブル２２１を削除する。なお、ファイルシステム３５２は、ファイルの古くなったバージョンの削除を行う。例えば、ファイルシステム３５２は、過去バージョン保持日数を設定され、作成されてから前記過去バージョン保持日数を過ぎたファイルのバージョンを削除する。この削除により、ファイルシステム３５２は、その容量が過去バージョンによって満杯になることを防ぐ。
　ユーザは、ファイルシステム３５２に対して特定のパス名に対して参照要求を発行することで、ファイルシステム３５２に格納されたファイル（又はディレクトリ）のバージョン情報を取得することができる。ここで、バージョン情報は、バージョン管理テーブル２２１に格納されたすべてのエントリである。例えば、ユーザは「/home/user01/a.txt」で表されるパス名のファイルのバージョン情報を、「/home/user01/a.txt?version=list」への参照要求で取得できる。
　ユーザは、ファイルシステム３５２に対してパス名にバージョンＩＤ２２１２を加えて参照要求を発行することで、ファイルシステム３５２に格納されたファイル（又はディレクトリ）の特定のバージョンを読み込むことができる。例えば、ユーザは「/home/user01/a.txt」で表されるパス名のファイルの「v2」で表されるバージョンを、「/home/user01/a.txt?version=v2」への参照要求で取得できる。
　ユーザは、ファイルシステム３５２のパス名に対してファイル（又はディレクトリ）の更新要求をすることで、新しくファイル（又はディレクトリ）を格納することができる。例えば、ユーザは「/home/user01/a.txt」で表されるパス名にファイルの更新要求を行うと、ファイルシステム３５２は現在時刻の取得とバージョンＩＤ２２１２の作成を行う。次に、ファイルシステム３５２はバージョン管理テーブル２２１に新しくエントリを作成し、そしてエントリに関連づけられたファイルが新しく格納される。その際、以前のファイルに上書きを行わない。
　図２３に、ディレクトリイメージ管理テーブル２３１の一例を示している。第１サーバ装置３ａ上のファイルシステム３１２が、ファイル復元を行ったディレクトリを管理するために、第１ストレージ装置１０ａに格納してこれを維持する。
　同図に示すように、ディレクトリイメージ管理テーブル２３１には、ディレクトリ２３１１、復元する日時２３１２、及び削除する日時２３１３が格納される。
　このうちディレクトリ２３１１には、ファイルシステム３１２上の、ディレクトリイメージを復元する先のディレクトリが設定される。復元する日時２３１２には、復元するディレクトリイメージの日時が設定される。削除する日時２３１３には、復元する先のディレクトリが、ファイルシステム３１２上から削除される日時が設定される。復元する日時２３１２及び削除する日時２３１３は、ユーザが設定してもよいし、ファイルシステム３１２が設定しても良い。例えば、「/mnt/fs01/.histroy/09_05/ 2010/9/5 00:00:00 2010/10/5 00:00:00」のエントリは、ファイルシステム３１２上の/mnt/fs01/.history/09_05/で表されるディレクトリに、2010/9/5 00:00:00時点でファイルシステム３１２上に存在したファイル（又はディレクトリ）が復元され、そして2010/10/5 00:00:00にファイルシステム３１２から削除されることを意味する。復元されるのは、後述のとおり、ディレクトリの階層構造における最上位ディレクトリ（ルートディレクトリ）の直下のディレクトリ又はファイルのメタデータである。これは一例であって、さらに、配下のディレクトリ又はファイルまでが復元されてもよいし、また、所定の階層のディレクトリ又はファイルが直接復元されるものであってもよい。
＝概略的な動作＝
　次に、以上の構成からなる情報処理システム１の動作について説明する。
　図２４は、第１サーバ装置３ａが、１ストレージ装置１０ａに格納されているファイルを対象としたレプリケーションを開始させる旨の要求（以下、レプリケーション開始要求と称する。）を受け付けた場合に、情報処理システム１において行われる処理（以下、レプリケーション開始処理Ｓ２４００と称する）を説明する図である。
　第１サーバ装置３ａは、クライアント装置２からレプリケーション開始要求を受け付けると、当該要求に対象として指定されているファイルについてレプリケーションによる管理方式による管理を開始する。尚、第１サーバ装置３ａは、通信ネットワーク５を介してクライアント装置２からレプリケーション開始要求を受け付ける以外に、例えば、当該第１サーバ装置３ａにおいて内部的に発生するレプリケーション開始要求も受け付ける。
　ここでレプリケーションによる管理方式とは、ファイルのデータ（メタデータ及び実体）を、第１ストレージ装置１０ａ及び第２ストレージ装置１０ｂの双方において管理する方式である。
　レプリケーションによる管理方式では、第１ストレージ装置１０ａに格納されているファイルの実体又はメタデータが更新されると、このファイルの複製(又はアーカイブファイル）として管理されている、第２ストレージ装置１０ｂ側のファイルのメタデータ又は実体が、同期又は非同期に更新される。レプリケーションによる管理方式が行われることにより、第１ストレージ装置１０ａに格納されているファイルのデータ（メタデータ又は実体）と、その複製として第２ストレージ装置１０ｂに格納されているファイルのデータ（メタデータ又は実体）の一致性が、同期又は非同期に確保（保証）される。
　尚、第２ストレージ装置１０ｂ側のファイル（アーカイブファイル）におけるメタデータはファイルの実体として管理してもよい。そのようにすることで、第１サーバ装置３ａのファイルシステム３１２と第２サーバ装置３ｂのファイルシステム３５２の仕様が相違する場合でもレプリケーションによる管理方式を実現することができる。
　同図に示すように、レプリケーション開始要求を受け付けると（Ｓ２４１１）、第１サーバ装置３ａは、受け付けたレプリケーション開始要求に指定されているファイルのデータ（メタデータ及び実体）を第１ストレージ装置１０ａから読み出し、読み出したファイルのデータを第２サーバ装置３ｂに送信する（Ｓ２４１２）。
　第２サーバ３ｂは、第１サーバ装置３ａから送られてくる、上記ファイルのデータを受信すると、受信したデータを第２ストレージ装置１０ｂに格納する（Ｓ２４１３）。
　尚、上記転送に際し、第１サーバ装置３ａのデータ複製／移動処理部３１４は、転送元ファイルのレプリケーションフラグ２１１４をＯＮに設定する（Ｓ２４１４）。
　図２５は、第１ストレージ装置１０ａに格納されている、レプリケーション管理方式により管理されているファイル（レプリケーションフラグ２１１４がＯＮに設定されているファイル。以下、レプリケーションファイルと称する。）を前述したスタブ化の候補として設定する際に、情報処理システム１において行われる処理（以下、スタブ化候補選出処理Ｓ２５００と称する。）を説明する図である。以下、同図とともにスタブ化候補選出処理Ｓ２５００について説明する。
　第１サーバ装置３ａは、ファイル格納領域の残容量を随時（リアルタイム、定期的、予め設定されたタイミング等）監視している。
　第１サーバ装置３ａは、ファイルシステム３１２に対してファイルの格納領域として割り当てられている第１ストレージ装置１０ａの記憶領域（以下、ファイル格納領域と称する。）の残容量が、予め設定された閾値（以下、スタブ化閾値と称する。）未満になると、所定の選出基準に従い、第１ストレージ装置１０ａに格納されているレプリケーションファイルの中からスタブ化の候補を選出する（Ｓ２５１１）。尚、上記所定の選出基準としては、例えば、最終更新日時が古い順、アクセス頻度の低い順などがある。
　次に第１サーバ装置３ａは、スタブ化の候補を選出すると、選出したレプリケーションファイルのスタブ化フラグ２１１１をＯＮ、レプリケーションフラグ２１１４をＯＦＦ、メタデータ同期要フラグ２１１２をＯＮに夫々設定する（Ｓ２５１２）。尚、第１サーバ装置３ａは、ファイル格納領域の残容量を、例えば、ファイルシステム３１２が管理している情報から取得する。
　図２６は、スタブ化候補選出処理Ｓ２５００によってスタブ化候補として選出されたファイルを実際にスタブ化する際、情報処理システム１において行われる処理（以下、スタブ化処理Ｓ２６００と称する。）を説明する図である。スタブ化処理Ｓ２６００は、例えば、予め設定されたタイミング（例えばスタブ化候補選出処理Ｓ２５００が行われたのに続いて）で行われる。以下、同図とともにスタブ化処理Ｓ２６００について説明する。
　同図に示すように、第１サーバ装置３ａは、第１ストレージ装置１０ａのファイル格納領域に格納されているファイルの中から、スタブ化候補として選出されているファイル（スタブ化フラグ２１１１がＯＮに設定されているファイル）を一つ以上抽出する（Ｓ２６１１）。
　そして第１サーバ装置３ａは、抽出したファイルの実体を第１ストレージ装置１０ａから削除するとともに、抽出したファイルのメタデータからそのファイルの第１ストレージ装置１０ａの格納先を示す情報に無効な値を設定し（例えば、メタデータの当該ファイルの格納先を設定する欄（例えばブロックアドレス２０１８を設定する欄）にＮＵＬＬ値やゼロを設定する。）、スタブ化候補として選出されているファイルを実際にスタブ化する。またこのとき第１サーバ装置３ａは、メタデータ同期要フラグ２１１２をＯＮに設定する（Ｓ２６１２）。
　図２７は、第１サーバ装置３ａが、クライアント装置２から第１ストレージ装置１０ａのファイル格納領域に格納されているレプリケーションファイルに対する更新要求を受け付けた場合に、情報処理システム１において行われる処理（以下、レプリケーションファイル更新処理Ｓ２７００と称する。）を説明する図である。以下、同図とともにレプリケーションファイル更新処理Ｓ２７００について説明する。
　第１サーバ装置３ａは、レプリケーションファイルに対する更新要求を受け付けると（Ｓ２７１１）、その第１ストレージ装置１０ａに格納されているそのレプリケーションファイルのデータ（メタデータ、実体）を、受け付けた更新要求に従って更新する（Ｓ２７１２）。
　そして第１サーバ装置３ａは、メタデータを更新した場合はそのレプリケーションファイルのメタデータ同期要フラグ２１１２をＯＮに設定し、レプリケーションファイルの実体を更新した場合はそのレプリケーションファイルの実体同期要フラグ２１１３をＯＮに設定する（Ｓ２７１３）。
　図２８は、第１サーバ装置３ａのファイルシステム３１２が、クライアント装置２から、第１ストレージ装置１０ａのファイル格納領域に格納されているレプリケーションファイルに対する参照要求を受け付けた場合に情報処理システム１において行われる処理（以下、レプリケーションファイル参照処理Ｓ２８００と称する。）を説明する図である。以下、同図とともにレプリケーションファイル参照処理Ｓ２８００について説明する。
　第１サーバ装置３ａのファイルシステム３１２は、レプリケーションファイルに対する更新要求を受け付けると（Ｓ２８１１）、そのレプリケーションファイルのデータ（メタデータ又は実体）を第１ストレージ装置１０ａから読み出し（Ｓ２８１２）、読み出したデータに基づきクライアント装置２に対して応答する情報を生成し、生成した応答情報をクライアント装置２に送信する（Ｓ２８１３）。
　図２９は、第１サーバ装置３ａのファイルシステム３１２が、クライアント装置２等から、スタブ化されているファイル（スタブ化フラグ２１１１がＯＮに設定されているファイル）のメタデータに対するアクセス要求（参照要求又は更新要求）を受け付けた場合に情報処理システム１において行われる処理（以下、メタデータアクセス処理Ｓ２９００と称する。）を説明する図である。以下、同図とともにメタデータアクセス処理Ｓ２９００について説明する。
　同図に示すように、第１サーバ装置３ａは、スタブ化されているファイルのメタデータに対するアクセス要求を受け付けると（Ｓ２９１１）、アクセス要求の対象になっている第１ストレージ装置１０ａのメタデータを取得し、アクセス要求の内容に従い参照（読み出したメタデータに基づく応答情報のクライアント装置２への送信）、又はメタデータの更新を行う（Ｓ２９１２）。またメタデータの内容を更新した場合には、そのファイルのメタデータ同期要フラグ２１１２にＯＮを設定する（Ｓ２９１３）。
　このように、第１サーバ装置３ａは、スタブ化されているファイルに対するアクセス要求が発生し、そのアクセス要求がそのファイルのメタデータのみを対象としている場合には、第１ストレージ装置１０ａに格納されているメタデータを用いてアクセス要求を処理する。このため、アクセス要求がそのファイルのメタデータのみを対象としている場合にはクライアント装置２に迅速に応答を返すことができる。
　図３０は、第１サーバ装置３ａが、クライアント装置２から、スタブ化されているファイル（スタブ化フラグ２１１１がＯＮに設定されているファイル。以下、スタブ化ファイルと称する。）の実体に対する参照要求を受け付けた場合に情報処理システム１において行われる処理（以下、スタブ化ファイル実体参照処理Ｓ３０００と称する。）を説明する図である。以下、同図とともにスタブ化ファイル実体参照処理Ｓ３０００について説明する。
　第１サーバ装置３ａは、クライアント装置２からスタブ化ファイルの実体に対する参照要求を受け付けると（Ｓ３０１１）、取得したメタデータを参照して当該スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されているか否かを判断する（Ｓ３０１２）。ここでこの判断は、例えば、取得したメタデータにスタブ化ファイルの実体の格納先を示す情報（例えばブロックアドレス２０１８）に有効な値が設定されているか否かに基づいて行う。
　上記判断の結果、スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されている場合には、第１サーバ装置３ａは、第１ストレージ装置１０ａから当該スタブ化ファイルの実体を読み出し、読み出した実体に基づきクライアント装置２に応答する情報を生成し、生成した応答情報をクライアント装置２に送信する（Ｓ３０１３）。
　一方、上記判断の結果、スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されていない場合には、第１サーバ装置３ａは、第２サーバ装置３ｂに対してスタブ化ファイルの実体の提供を要求する（以下、リコール要求と称する。）（Ｓ３０１４）。　尚、実体の取得要求は、必ずしも一度の取得要求によって実体の全体を取得する要求でなくてもよく、例えば実体の一部のみを複数回要求するようにしてもよい。
　第１サーバ装置３ａは、上記取得要求に応じて第２サーバ装置３ｂから送られてくるスタブ化ファイルの実体を受信すると（Ｓ３０１５）、受信した実体に基づき応答情報を生成し、生成した応答情報をクライアント装置２に送信する（Ｓ３０１６）。
　また第１サーバ装置３ａは、上記第２サーバ装置３ｂから受信した実体を第１ストレージ装置１０ａに格納し、当該スタブ化ファイルのメタデータの当該ファイルの実体の格納先を示す情報（例えばブロックアドレス２０１８）に、当該ファイルの第１ストレージ装置１０ａにおける格納先を示す内容を設定する。また第１サーバ装置３ａは、当該ファイルのスタブ化フラグ２１１１をＯＦＦに、レプリケーションフラグ２１１４をＯＮに、メタデータ同期要フラグ２１１２をＯＮに、夫々設定する（当該ファイルをスタブ化ファイルからレプリケーションファイルに変更する。）（Ｓ３０１７）。
　尚、メタデータ同期要フラグ２１１２をＯＮに設定するのは、第１ストレージ装置１０ａと第２ストレージ装置１０ｂとの間で、当該スタブ化ファイルのスタブ化フラグ２１１１及びレプリケーションフラグ２１１４の内容を事後的に自動的に同期させるためである。
　図３１は、第１サーバ装置３ａが、クライアント装置２からスタブ化ファイルの実体に対する更新要求を受け付けた場合に、情報処理システム１において行われる処理（以下、スタブ化ファイル実体更新処理Ｓ３１００と称する。）を説明する図である。以下、同図とともにスタブ化ファイル実体更新処理Ｓ３１００について説明する。
　第１サーバ装置３ａは、スタブ化ファイルの実体に対する更新要求を受け付けると（Ｓ３１１１）、更新要求の対象になっているスタブ化ファイルのメタデータを取得し、取得したメタデータに基づき当該スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されているか否かを判断する（Ｓ３１１２）。尚、判断方法はスタブ化ファイル実体参照処理Ｓ３０００の場合と同様である。
　上記判断の結果、スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されていた場合、第１サーバ装置３ａは、第１ストレージ装置１０ａに格納されている当該スタブ化ファイルの実体を更新要求の内容に従って更新するとともに、当該スタブ化ファイルの実体同期要フラグ２１１３をＯＮに設定する（Ｓ３１１３）。
　一方、スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されていない場合、第１サーバ装置３ａは、第２サーバ装置３ｂに当該スタブ化ファイルの実体の取得要求(リコール要求）を送信する（Ｓ３１１４）。
　第１サーバ装置３ａは、上記要求に応じて第２サーバ装置３ｂから送られてきたファイルの実体を受信すると（Ｓ３１１５）、受信した実体の内容を更新要求の内容に従って更新し、更新後の実体を当該スタブ化ファイルの実体として第１ストレージ装置１０ａに格納する。また第１サーバ装置３ａは、当該スタブ化ファイルのスタブ化フラグ２１１１をＯＦＦ、レプリケーションフラグ２１１４をＯＦＦ、メタデータ同期要フラグ２１１２をＯＮに夫々設定する（Ｓ３１１６）。
＜ファイル復元時の処理＞
　図３２は、過去のある時点のディレクトリイメージを作成する処理（以下、ディレクトリイメージ作成処理Ｓ３２００と称する。）を説明する図である。以下、同図とともにディレクトリイメージ作成処理Ｓ３２００について説明する。
　まず第１サーバ装置３ａのファイルシステム３１２が、過去のある時点で第１ストレージ装置１０ａに構成されていたディレクトリの構成（つまり、第２ストレージ装置１０ｂに記憶されているディレクトリの構成であり、ディレクトリの階層構造を示すデータ、ディレクトリのデータ（メタデータ）、及びファイルのデータ（メタデータ及び実体)を含む。以下、ディレクトリイメージと称する。）における、最上位ディレクトリ（以下、ルートディレクトリと称する。）に存在するディレクトリのメタデータ、及びルートディレクトリに存在するファイルのメタデータの取得要求を、第２サーバ装置３ｂに送信する（Ｓ３２１１）。
　本実施形態において、ルートディレクトリに存在するディレクトリのメタデータ、及びルートディレクトリに存在するファイルのメタデータという場合には、ルートディレクトリに存在する（から見える）ディレクトリ及びファイルは含まれるが、ルートディレクトリに存在するディレクトリの更に配下に存在するディレクトリやそのディレクトリに存在するファイルは含まれない。
　第２サーバ装置３ｂは、上記取得要求を受信すると、要求されているルートディレクトリに存在するディレクトリのメタデータ、及びルートディレクトリに存在するファイルのメタデータを、第２ストレージ装置１０ｂから取得し（Ｓ３２１２）、取得したメタデータを第１ストレージ装置１０ａに送信する（Ｓ３２１３）。
　第１サーバ装置３ａは、第２サーバ装置３ｂからメタデータを受信すると（Ｓ３２１３）、受信したメタデータに基づくディレクトリイメージを、第１ストレージ装置１０ａに復元する（Ｓ３２１４）。またこのとき、第１サーバ装置３ａは、メタデータ同期要フラグ２１１２をＯＮ、実体同期要フラグ２１１３をＯＮ、読み取り専用フラグ２１１５をＯＮに夫々設定する。尚、復元されたファイルはいずれもメタデータのみに基づくものであるため、これらのファイルはいずれもスタブ化された状態になっており、スタブ化フラグ２１１１がＯＮに設定されている。
　このように第１サーバ装置３ａは、第１ストレージ装置１０ａにディレクトリイメージが復元する。第１のサーバ装置３ａのファイルシステム３１２は、ディレクトリイメージを、例えば、図２３に示すように、定期的に取得し、これをディレクトリ管理テーブルで継続的に管理する。なお、ディレクトリイメージの取得の形態としては、適宜変更可能であり、第１のサーバ装置３ａで所定のイベントが発生する都度のタイミングでもよい。例えば、クライアント装置が第１のサーバ３ａにファイルの履歴を照会した時点である。この場合、クライアントがこのファイルの過去のバージョンにアクセスする可能性があるとして、過去バージョンの属するディレクトリイメージを取得することとした。
　図３３は、図３２に示したディレクトリイメージ作成処理Ｓ３２００の後、過去のある時点に当該第１サーバ装置３ａが管理していたディレクトリイメージを復元していく処理（以下、オンデマンド復元処理Ｓ３３００と称する。）を説明する図である。以下、同図とともにオンデマンド復元処理Ｓ３３００について説明する。
　第１サーバ装置３ａは、サービスを開始した後、クライアント装置２からあるファイルについてデータＩ／Ｏ要求を受け付けると（Ｓ３３１１）、受け付けたデータＩ／Ｏ要求の対象になっているファイル（以下、アクセス対象ファイルと称する。）のメタデータが、第１ストレージ装置１０ａに存在するか否か（サービス開始後、既に第１ストレージ装置１０ａにメタデータが復元されているか否か）を調べる（Ｓ３３１２）。
　メタデータが第１ストレージ装置１０ａに復元されている場合、第１サーバ装置３ａは、受け付けたデータＩ／Ｏ要求の対象（メタデータ又は実体）、データＩ／Ｏ要求の種類（参照要求か更新要求か）、レプリケーションによる管理方式で管理されているか否か（レプリケーションフラグ２１１４がＯＮか否か）、スタブ化されているか否か（スタブ化フラグがＯＮか否か）に応じて、受け付けたデータＩ／Ｏ要求に対応する処理（前述したレプリケーションファイル更新処理Ｓ２７００、レプリケーションファイル参照処理Ｓ２８００、メタデータアクセス処理Ｓ２９００、スタブ化ファイル実体参照処理Ｓ３０００、スタブ化ファイル実体更新処理Ｓ３１００）を行い、クライアント装置２に応答を返す（Ｓ３３１８）。
　一方、アクセス対象ファイルのメタデータが復元されていない場合には、第１サーバ装置３ａは、ルートディレクトリを起点としてアクセス対象ファイルが存在するディレクトリレベル（ディレクトリ階層）に至るまでのディレクトリイメージを復元するためのデータを第２サーバ装置３ｂ（第２ストレージ装置１０ｂ）から取得し（Ｓ３３１３～Ｓ３３１５）、取得したデータを用いてルートディレクトリから上記ディレクトリレベルに至るまでのディレクトリイメージを第１ストレージ装置１０ａに復元する（Ｓ３３１６）。
　また第１サーバ装置３ａは、アクセス対象ファイルのスタブ化フラグ２１１１をＯＮに、レプリケーションフラグ２１１４をＯＦＦに、メタデータ同期要フラグ２１１２をＯＮに、読み込み専用フラグ２１１５をＯＮに、夫々設定する（Ｓ３３１７）。
　次に第１サーバ装置３ａは、受け付けたデータＩ／Ｏ要求の対象や種類、管理方式、スタブ化の有無等に応じて、受け付けたデータＩ／Ｏ要求に対応する処理を行い、クライアント装置２に応答を返す（Ｓ３３１８）。
　図３４に、データＩ／Ｏ要求が繰り返し発生することにより、以上に説明したオンデマンド復元処理Ｓ３３００によって段階的に第１ストレージ装置１０ａにディレクトリイメージが復元されていく様子を示している。
　同図中、強調された文字列（アンダーラインが付与されている文字列）で示すディレクトリは、そのディレクトリのメタデータは復元されているがその配下のディレクトリのメタデータは未だ復元されていない。また強調されていない文字で示すディレクトリは、そのディレクトリの配下のディレクトリのメタデータも既に復元されている。また強調された文字で示すファイルは、そのファイルのメタデータは復元されているが、その実体は未だ復元されていない。また強調されていない文字で示すファイルは、そのファイルの実体が既に復元されている。
　図３４の図（０）は、過去のある時点で第１サーバ装置３ａ（第１ストレージ装置１０ａ）において管理され、かつ第２サーバ装置３ｂにレプリケーション済みのディレクトリイメージ（最終的に復元されるディレクトリイメージの全体）である。
　図３４の図（Ａ）は、ディレクトリイメージ作成処理Ｓ３２００直後（まだ第１サーバ装置３ａがデータＩ／Ｏ要求を受け付けていない状態）におけるディレクトリイメージである。この段階ではルートディレクトリ「／」の直下に存在するディレクトリ「／ｄｉｒ１」及び「／ｄｉｒ２」のメタデータは復元されているが、その更に配下のディレクトリのメタデータについては未だ復元されていない。またルートディレクトリ「／」の直下に存在するファイル「ａ．ｔｘｔ」のメタデータは復元されているが、実体については未だ復元されていない。
　図３４の図（Ｂ）は、図（Ａ）の状態でクライアント装置２からディレクトリ「／ｄｉｒ１」の配下に存在するファイル「ｃ．ｔｘｔ」に対するデータＩ／Ｏ要求を受け付けた後の状態である。クライアント装置２からファイル「ｃ．ｔｘｔ」に対するデータＩ／Ｏ要求を受け付けたため、ディレクトリ「／ｄｉｒ１１」のメタデータと「／ｃ．ｔｘｔ」のメタデータが復元されている。
　図３４の図（Ｃ）は、図（Ｂ）の状態で更にクライアント装置２からディレクトリ「／ｄｉｒ２」の配下に存在するファイル「ｂ．ｔｘｔ」に対するデータＩ／Ｏ要求を受け付けた後の状態である。同図に示すように、クライアント装置２からファイル「ｂ．ｔｘｔ」に対するデータＩ／Ｏ要求を受け付けたため、「／ｂ．ｔｘｔ」のメタデータが復元されている。尚、「／ｄｉｒ２」の配下に存在する「／ｂ．ｔｘｔ」のメタデータが復元されたため、「／ｄｉｒ２」は強調されていない文字で表記している。
　図３４の図（Ｄ）は、図（Ｃ）の状態でクライアント装置２からファイル「ｂ．ｔｘｔ」に対するデータＩ／Ｏ要求（更新要求）を受け付けた後の状態である。クライアント装置２からファイル「ｂ．ｔｘｔ」に対するデータＩ／Ｏ要求（更新要求）を受け付けたため、ファイル「ｂ．ｔｘｔ」の実体が復元されている。
　図３５は、過去のある時点のディレクトリイメージを削除する処理（以下、ディレクトリイメージ削除処理Ｓ３５００と称する。）を説明する図である。以下、同図とともにディレクトリイメージ作成処理Ｓ３５００について説明する。
　まず第１サーバ装置３は、ファイルシステム３１２が過去のある時点で第１ストレージ装置１０ａに構成していたディレクトリが、ファイルシステム３１２に設定された日時を超えて保管されていないかを監視する（Ｓ３５１１）。前述のディレクトリが前述の日時を超えて保管されていた場合、ファイルシステム３１２は前述のディレクトリを削除する（Ｓ３５１２）。
　以上に説明したように、本実施形態の情報処理システム１においては、第１サーバ装置３ａにおいてディレクトリイメージ作成処理が実施された後、データＩ／Ｏ要求を受け付ける前までは、ディレクトリイメージ作成処理Ｓ３２００によってルートディレクトリに存在するディレクトリのメタデータ、及びルートディレクトリに存在するファイルのメタデータのみが復元される。そしてその後は第１サーバ装置３ａに対してクライアント装置２からまだ復元されていないファイルに対してデータＩ／Ｏ要求が発生する度に、段階的に第１サーバ装置３ａ（第１ストレージ装置１０ａ）にディレクトリイメージが復元されていく。
　このようにファイル復元のために、データＩ／Ｏ要求の受け付けを開始する前にディレクトリイメージの全体を復元してしまうのではなく、データＩ／Ｏ要求を処理するのに必要なディレクトリイメージを段階的に復元するようにすることで、ファイル復元のためにディレクトリイメージの全体を復元しておく場合に比べ、ファイル復元に要する時間を短縮することができ、ユーザの業務等への影響を防ぐことができる。
　またディレクトリイメージが完全に復元されるまでの間は、第１ストレージ装置１０ａの資源を節約することができる。さらにディレクトリイメージが完全に復元されるまでの間は記憶容量の消費が抑えられる。
＜処理詳細＞
　次に情報処理システム１において行われる処理の詳細について説明する。
　図３６は、図２４に示したレプリケーション開始処理Ｓ２４００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　第１サーバ装置３ａは、クライアント装置２等からレプリケーション開始要求を受け付けたか否かをリアルタイムに監視している（Ｓ３６１１）。第１サーバ装置３ａは、クライアント装置２等からレプリケーション開始要求を受け付けると（Ｓ３６１１：ＹＥＳ）（図２４のＳ２４１１）、受け付けたレプリケーション開始要求に指定されているファイルのデータ（メタデータ及び実体）の格納先（ＲＡＩＤグループの識別子、ブロックアドレス等）を第２サーバ装置３ｂに問い合わせる（Ｓ３６１２）。
　第２サーバ装置３ｂは、上記の問い合わせがあると（Ｓ３６２１）、第２ストレージ装置１０ｂの空き領域を探索してファイルのデータの格納先を決定し、決定した格納先を第１サーバ装置３ａに通知する（Ｓ３６２２）。
　第１サーバ装置３ａは、上記通知を受信すると（Ｓ３６１３）、受け付けたレプリケーション開始要求に指定されているファイルのデータ（メタデータ及び実体）を、第１ストレージ装置１０ａから読み出し（Ｓ３６１４）（図２４のＳ２４１２）、読み出したファイルのデータをＳ３６２２で通知された格納先とともに第２サーバ装置３ｂに送信する（Ｓ３６１５）（図２４のＳ２４１３）。
　また第１サーバ装置３ａは、当該ファイルのメタデータ（第１ストレージ装置１０ａに格納されている当該ファイルのメタデータ）のレプリケーションフラグ２１１４をＯＮ、メタデータ同期要フラグ２１１２をＯＮに夫々設定する（Ｓ３６１６）（図２４のＳ２４１４）。
　尚、メタデータ同期要フラグ２１１２をＯＮに設定しておくことで、前述した同期処理Ｓ２９００により第１ストレージ装置１０ａに格納されているファイルのメタデータと、その複製として第２ストレージ装置１０ｂに格納されているファイルのメタデータの一致性が、同期又は非同期に確保（保証）される。
　一方、第２サーバ装置３ｂは、第１サーバ装置３ａからファイルのデータを受信すると（Ｓ３６２３）、受信したファイルのデータを、当該ファイルとともに受信した格納先で特定される第２ストレージ装置１０ｂの位置に格納する（Ｓ３６２４）。
　図３７は、図２５に示したスタブ化候補選出処理Ｓ２５００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　第１サーバ装置３ａは、ファイル格納領域の残容量がスタブ化閾値未満になっているか否かを随時監視し（Ｓ３７１１、Ｓ３７１２）、ファイル格納領域の残容量がスタブ化閾値未満になっていることを検知すると、前述した所定の選出基準に従い第１ストレージ装置１０ａに格納されているレプリケーションファイルの中からスタブ化の候補を選出する（Ｓ３７１２）（図２５のＳ２５１１）。
　そして第１サーバ装置３ａは、スタブ化の候補を選出すると（Ｓ３７１３）、選出したレプリケーションファイルのスタブ化フラグ２１１１をＯＮ、レプリケーションフラグ２１１４をＯＦＦ、メタデータ同期要フラグ２１１２をＯＮに夫々設定する（Ｓ３７１４）（図２５のＳ２５１２）。
　図３８は、図２６に示したスタブ化処理Ｓ２６００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　第１サーバ装置３ａは、第１ストレージ装置１０ａのファイル格納領域に格納されているファイルの中から、スタブ化候補として選出されているファイル（スタブ化フラグ２１１１がＯＮに設定されているファイル）を随時抽出する（Ｓ３８１１，Ｓ３８１２）。
　そして第１サーバ装置３ａは、抽出したファイルの実体を第１ストレージ装置１０ａから削除するとともに（Ｓ３８１３）、抽出したファイルのメタデータからそのファイルの第１ストレージ装置１０ａの格納先を示す情報に無効な値を設定し（例えば、メタデータの当該ファイルの格納先を設定する欄（例えばブロックアドレス２０１８）にＮＵＬＬ値やゼロを設定する。）（Ｓ３８１４）、メタデータ同期要フラグ２１１２をＯＮに設定する（Ｓ３８１５）（図２６のＳ２６１１）。
　図３９は、図２７に示したレプリケーションファイル更新処理Ｓ２７００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　第１サーバ装置３ａは、クライアント装置２からレプリケーションファイルに対する更新要求を受け付けたか否かをリアルタイムに監視している（Ｓ３９１１）。第１サーバ装置３ａは、更新要求を受け付けると（Ｓ３９１１：ＹＥＳ）（図２７のＳ２７１１）、第１ストレージ装置１０ａに格納されている、当該更新要求の対象になっているレプリケーションファイルのデータ（メタデータ又は実体）を、受け付けた更新要求に従って更新する（Ｓ３９１２）（図２７のＳ２７１２）。
　また第１サーバ装置３ａは、メタデータを更新した場合はそのレプリケーションファイルのメタデータ同期要フラグ２１１２をＯＮに設定し（Ｓ３９１３）、レプリケーションファイルの実体を更新した場合はそのレプリケーションファイルの実体同期要フラグ２１１３をＯＮに設定する（Ｓ３９１４）（図２７のＳ２７１３）。
　図４０は、図２８に示したレプリケーションファイル参照処理Ｓ２８００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　第１サーバ装置３ａは、クライアント装置２からレプリケーションファイルに対する参照要求を受け付けたか否かをリアルタイムに監視している（Ｓ４０１１）。第１サーバ装置３ａは、参照要求を受け付けると（Ｓ４０１１：ＹＥＳ）（図２８のＳ２８１１）、そのレプリケーションファイルのデータ（メタデータ又は実体）を第１ストレージ装置１０ａから読み出し（Ｓ４０１２）（図２８のＳ２８１２）、読み出したデータに基づきクライアント装置２に対して応答する情報を生成し、生成した応答情報をクライアント装置２に送信する（Ｓ４０１３）（図２８のＳ２８１３）。
　図４１は、図２９に示したメタデータアクセス処理Ｓ２９００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　第１サーバ装置３ａは、クライアント装置２からスタブ化されているファイルのメタデータに対するアクセス要求（参照要求又は更新要求）を受け付けたか否かをリアルタイムに監視している（Ｓ４１１１）。
　第１サーバ装置３ａは、スタブ化されているファイルのメタデータに対するアクセス要求を受け付けると（Ｓ４１１１：ＹＥＳ）（図２９のＳ２９１１）、受け付けたアクセス要求の対象になっている第１ストレージ装置１０ａのメタデータを取得し（Ｓ４１１２）、受け付けたアクセス要求に従い（Ｓ４１１３）、メタデータの参照（読み出したメタデータに基づく応答情報のクライアント装置２への送信）（Ｓ１５１４）、又はメタデータの更新を行う（Ｓ４１１５）（図２９のＳ２９１２）。またメタデータの内容を更新した場合は（Ｓ４１１５）、そのファイルのメタデータ同期要フラグ２１１２にＯＮを設定する（図２９のＳ２９１３）。
　図４２は、図３０に示したスタブ化ファイル実体参照処理Ｓ３０００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　第１サーバ装置３ａは、クライアント装置２からスタブ化ファイルの実体に対する参照要求を受け付けると（Ｓ４２１１：ＹＥＳ）（図３０のＳ３０１１）、当該スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されているか否かを判断する（Ｓ４２１２）（図３０のＳ３０１２）。
　スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されている場合には（Ｓ４２１２：ＹＥＳ）、第１サーバ装置３ａは、第１ストレージ装置１０ａから当該スタブ化ファイルの実体を読み出し、読み出した実体に基づきクライアント装置２に応答する情報を生成し、生成した応答情報をクライアント装置２に送信する（Ｓ４２１３）（図３０のＳ３０１３）。
　一方、スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されていない場合には（Ｓ４２１２：ＮＯ）、第１サーバ装置３ａは、第２サーバ装置３ｂに対してスタブ化ファイルの実体を要求する（リコール要求）（Ｓ４２１４）（図３０のＳ３０１４）。その際、第１サーバ装置３ａは、スタブ化ファイルのメタデータに含まれるリンク先２１１６を使って第２サーバ装置３ｂのファイルの特定のバージョンを要求する。
　第１サーバ装置３ａは、上記取得要求に応じて第２サーバ装置３ｂから送られてくるスタブ化ファイルの実体を受信すると（Ｓ４２２１、Ｓ４２２２、Ｓ４２１５）（図３０のＳ３０１５）、受信した実体に基づき応答情報を生成し、生成した応答情報をクライアント装置２に送信する（Ｓ４２１６）（図３０のＳ３０１６）。
　また第１サーバ装置３ａは、上記第２サーバ装置３ｂから受信した実体を第１ストレージ装置１０ａに格納し、当該スタブ化ファイルのメタデータの当該ファイルの実体の格納先を示す情報（例えばブロックアドレス２０１８）に、当該ファイルの第１ストレージ装置１０ａにおける格納先を示す内容を設定する（Ｓ４２１７）。
　また第１サーバ装置３ａは、当該ファイルのスタブ化フラグ２１１１をＯＦＦに、レプリケーションフラグ２１１４をＯＮに、メタデータ同期要フラグ２１１２をＯＮに、夫々設定する（Ｓ４２１８）（図３０のＳ３０１７）。
　図４３は、図３１に示したスタブ化ファイル実体更新処理Ｓ３１００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　第１サーバ装置３ａは、クライアント装置２からスタブ化ファイルの実体に対する更新要求を受け付けると（Ｓ４３１１：ＹＥＳ）（図３１のＳ３１１１）、当該スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されているか否かを判断する（Ｓ４３１２）（図３１のＳ３１１２）。
　スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されている場合（Ｓ４３１２：ＹＥＳ）、第１サーバ装置３ａは、第１ストレージ装置１０ａに格納されている当該スタブ化ファイルの実体を更新要求の内容に従って更新するとともに（Ｓ４３１３）、当該スタブ化ファイルの実体同期要フラグ２１１３をＯＮに設定する（Ｓ４３１４）（図３１のＳ３１１３）。
　一方、上記判断の結果、スタブ化ファイルの実体が第１ストレージ装置１０ａに格納されていない場合には（Ｓ４３１２：ＮＯ）、第１サーバ装置３ａは、第２サーバ装置３ｂに当該スタブ化ファイルの実体の取得要求（リコール要求）を送信する（Ｓ４３１５）（図３１のＳ３１１４）。
　第１サーバ装置３ａは、上記要求に応じて第２サーバ装置３ｂから送られてくるファイルの実体を受信すると（Ｓ４３２１、Ｓ４３２２、Ｓ４３１６）（Ｓ３１１５）、受信した実体の内容を更新要求の内容に従って更新し（Ｓ４３１７）、更新後の実体を当該スタブ化ファイルの実体として第１ストレージ装置１０ａに格納する（Ｓ４３１８）（図３１のＳ３１１６）。
　また第１サーバ装置３ａは、当該スタブ化ファイルのスタブ化フラグ２１１１をＯＦＦ、レプリケーションフラグ２１１４をＯＦＦ、メタデータ同期要フラグ２１１２をＯＮに夫々設定する（Ｓ４３１９）。
　図４４は、図３２に示したディレクトリイメージ作成処理Ｓ３２００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　まず、第１サーバ装置３ａは、過去のある時点のディレクトリイメージを復元する先のディレクトリを作成する（Ｓ４４１１）。第１サーバ装置３ａは、作成したディレクトリのパスと、現在日時と、ディレクトリイメージ保持日数を現在日時に加えた日時とを、それぞれ、ディレクトリ２３１１、復元する日時２３１２、削除する日時２３１３に設定することで、ディレクトリイメージ管理テーブル２３１に新しいエントリを作成する。ここで、ディレクトリイメージ保持日数は、ファイルシステム３１２に設定される、復元先ディレクトリが作成されてから削除されるまでの日数である。
　次に、第１サーバ装置３ａは、第２サーバ装置３ｂに対し、ファイルシステム３１２が復元する日時２３１２のディレクトリイメージのルートディレクトリに存在するディレクトリのメタデータ及びルートディレクトリに存在するファイルのメタデータの取得を次のように行う。
　（１）第１サーバ装置３ａは、第２サーバ装置３ｂに対し、ルートディレクトリのバージョン情報を要求する（Ｓ４４１２）。
　（２）第２サーバ装置３ｂは、上記取得要求を受信すると（Ｓ４４２１）、要求されているルートディレクトリのバージョン情報を第２ストレージ装置１０ｂから取得し、取得したバージョン情報を第１サーバ装置３ａに送信する（Ｓ４４２２）。
　（３）第１サーバ装置３ａは、第２サーバ装置３ｂからバージョン情報を受信すると（Ｓ４４１３）、復元する日時２３１２を超えない、かつ、最も近い格納日時２２１１を、ルートディレクトリのバージョン情報（バージョン管理テーブル２２１）から検索し、検索された格納日時に対応するバージョンＩＤ２２１２を取得する（Ｓ４４１４）。
　（４）第１サーバ装置３ａは、第２サーバ装置３ｂに対し、取得したバージョンＩＤ２２１２をもつルートディレクトリに存在するディレクトリのメタデータ、及びルートディレクトリに存在するファイルのメタデータの取得要求を、送信する（Ｓ４４１５）（図３２のＳ３２１１）。
　（５）第２サーバ装置３ｂは、上記取得要求を受信すると（Ｓ４４２３）、要求されているルートディレクトリのメタデータを取得し、そのディレクトリエントリに対してＳ４４１２～Ｓ４４１４と同様の処理を行うことで、復元するバージョンのルートディレクトリに存在するディレクトリのメタデータ、及び復元するバージョンのルートディレクトリに存在するファイルのメタデータを第２ストレージ装置１０ｂから取得し、取得したメタデータを第１ストレージ装置１０ａに送信する（Ｓ４４２４）（図３２のＳ３２１２、Ｓ３２１３）。
　次に、第１サーバ装置３ａは、第２サーバ装置３ｂからメタデータを受信すると（Ｓ４４１６）（図３２のＳ３２１３）、受信したメタデータに従ったディレクトリイメージを第１ストレージ装置１０ａに構成（復元）する（Ｓ４４１７）（図３２のＳ３２１４）。またこのとき、第１サーバ装置３ａは、メタデータ同期要フラグ２１１２をＯＮに、実体同期要フラグ２１１３をＯＮに、読み込み専用フラグをＯＮに、夫々設定する（Ｓ４４１８）。
　図４５及び図４６は、図３３に示したオンデマンド復元処理Ｓ３３００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　先ず、ユーザはクライアント装置２を介して、ファイル復元を第１サーバ装置３ａに要求する際、復元先ディレクトリ２３１１のうち所望の復元先ディレクトリにアクセスする。次いで、第１サーバ装置３ａは、クライアント装置２からファイル復元対象になる所定の復元対象ファイルについてデータＩ／Ｏ要求を受け付けると（Ｓ４５１１：ＹＥＳ）（図３３のＳ３３１１）、受け付けたデータＩ／Ｏ要求の対象になっているファイル（アクセス対象ファイル）のメタデータが、第１ストレージ装置１０ａに構成された、前記復元先ディレクトリ以下に存在するか否かを調べる（Ｓ４５１２）（図３３のＳ３３１２）。
　そして、メタデータが第１ストレージ装置１０ａに復元されている場合（Ｓ４５１２：ＹＥＳ）、第１サーバ装置３ａは、受け付けたデータＩ／Ｏ要求の対象や種類、管理方式、スタブ化の有無等に応じて、受け付けたデータＩ／Ｏ要求に対応する処理を行い、クライアント装置２に応答を返す（Ｓ４５１３）（図３３のＳ３３１８）。
　一方、アクセス対象ファイルのメタデータが第１ストレージ装置１０ａに復元されていない場合には（Ｓ４５１２：ＮＯ）、第１サーバ装置３ａは、ルートディレクトリを起点としてアクセス対象ファイルが存在するディレクトリレベルに至るまでのディレクトリイメージを復元するために親ディレクトリ復元処理を呼び出す（Ｓ４５１４）。
　次に、第１サーバ装置３ａは、第２サーバ装置３ｂに対し、ファイルシステム３１２が復元する日時２３１２のファイルシステムの、ルートディレクトリを起点としてアクセス対象ファイルが存在するディレクトリレベル（ディレクトリ階層）に至るまでのディレクトリイメージの復元を、次のように行う（図４６参照）。
　（１）第１サーバ装置３ａは、第２サーバ装置３ｂに対し、前記データＩ／Ｏ要求におけるパス情報に基づいて、第１ストレージ装置１０aに復元されていないディレクトリのうち、前記ルートディレクトリの直下にある、即ち、最も浅いディレクトリレベルのディレクトリのバージョン情報を要求する（Ｓ４６１１）。
　（２）第２サーバ装置３ｂは、上記取得要求を受信すると（Ｓ４６２１）、要求されている最も浅いディレクトリのバージョン情報を第２ストレージ装置１０ｂから取得し、取得したバージョン情報を第１サーバ装置３ａに送信する（Ｓ４６２２）。
　（３）第１サーバ装置３ａは、第２サーバ装置３ｂからバージョン情報を受信すると（Ｓ４６１２）、復元する日時２３１２を超えない、かつ、最も近い格納日時２２１１を、復元するディレクトリのバージョン情報（バージョン管理テーブル２２１）から検索し、検索された格納日時に対応するバージョンＩＤ２２１２を取得する（Ｓ４６１３）。
　（４）第１サーバ装置３ａは、第２サーバ装置３ｂに対し、取得したバージョンＩＤ２２１２をもつディレクトリに存在するディレクトリのメタデータ、及びルートディレクトリに存在するファイルのメタデータの取得要求を、第２サーバ装置３ｂに送信する（Ｓ４６１４）（図３３のＳ３３１３）。
　（５）第２サーバ装置３ｂは、上記取得要求を受信すると（Ｓ４６２３）、要求されているディレクトリのメタデータを取得し、そのディレクトリエントリに対してＳ４６１１～Ｓ４６１６と同様の処理を行うことで、復元するバージョンのディレクトリイメージに存在するディレクトリのメタデータ、及び復元するバージョンのディレクトリに存在するファイルのメタデータを第２ストレージ装置１０ｂから取得し、取得したメタデータを第１ストレージ装置１０ａに送信する（Ｓ４６２４）（図３３のＳ３２１４、Ｓ３３１５）。
（６）第１サーバ装置３ａは、第２サーバ装置３ｂから送られてくるデータを受信すると（Ｓ４６１５）、そのデータを用いてディレクトリイメージを第１ストレージ装置１０ａに復元する（Ｓ４６１６）（図３３のＳ３３１６）。ステップＳ４６１７では、第１サーバ装置３ａは、親ディレクトリの復元が完了したか、即ち、復元すべきファイルのメタデータが得られるディレクトリまでディレクトリイメージが復元できたか否、を判定し、親ディレクトリ復元処理が完了すると、第１サーバ装置３ａは、アクセス対象ファイルのスタブ化フラグ２１１１をＯＮに、レプリケーションフラグ２１１４をＯＦＦに、メタデータ同期要フラグ２１１２をＯＮに、読み込み専用フラグをＯＮに、夫々設定する（Ｓ４５１５）（図３３のＳ３３１７）。
　次に第１サーバ装置３ａは、受け付けたデータＩ／Ｏ要求の対象や種類、管理方式、スタブ化の有無等に応じて、受け付けたデータＩ／Ｏ要求に対応する処理を行い、クライアント装置２に応答を返す（Ｓ４５１６）（図３３のＳ３３１８）。なお、第１のファイルサーバが第２のファイルサーバにファイルの実体を要求する際（リコール要求：図４２のＳ４２１４）、ファイルの実体の全てでなくその一部を要求するものであってもよい。
　以上詳細に説明したように、本実施形態の情報処理システム１にあっては、第１サーバ装置３ａのファイル復元に際し、第１サーバ装置３ａは日時をディレクトリに関連付け、第２サーバ装置３ｂが、第１サーバ装置３ａがデータＩ／Ｏ要求の受け付けを開始するのに先立ち、第２ストレージ装置１０ｂに記憶しているファイルのデータのうちディレクトリに関連付けたバージョンの最上位ディレクトリから所定の下位階層までのディレクトリイメージを第１サーバ装置３ａに送信し、第１サーバ装置３ａが、第２サーバ装置３ｂから送られてくるディレクトリイメージを第１ストレージ装置１０ａに復元した後、データＩ／Ｏ要求の受け付けを再開する。
　図４７は、図３５に示したディレクトリイメージ削除処理Ｓ３５００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　まず第１サーバ装置３ａは、定期的にディレクトリイメージ管理テーブル２３１を参照し、ファイル復元先であるディレクトリ２３１１が削除する日時２３１３を過ぎているか否かを確認する（Ｓ４７１１、Ｓ４７１１）。過ぎている場合、ディレクトリイメージ削除のタイミングと判定し（Ｓ４７１２：ＹＥＳ）、ディレクトリイメージを削除する（Ｓ４７１３）。最後に、ディレクトリイメージ管理テーブル２３１から、削除したディレクトリ２３１１を含むエントリを削除する。
　このように、本実施形態の情報処理システム１にあっては、第１サーバ装置３ａのファイル復元に際し、第１ストレージ装置１０ａに存在していたディレクトリイメージの全てを復元するのではなく、最上位のディレクトリから所定の下位階層までのディレクトリイメージのみを復元するので、過去のある時点で第１ストレージ装置１０ａに存在していた全てのディレクトリイメージを復元する場合に比べてファイル復元に要する時間を短縮することができ、早期にサービスを再開することができる。また全てのディレクトリイメージを復元する場合に比べて、情報処理システム１に与える負荷が少なくて済むし、第１ストレージ装置１０ａのストレージ消費量が少なくて済む。
（第二の実施形態）
　第二の実施形態における情報処理システム１では、第２サーバ装置３ｂがバージョン情報を第１サーバ装置３ａに送信できない場合にも、第一の実施形態と同様の効果を実現する。第二の実施形態は、ディレクトリイメージ作成処理Ｓ３２００の一部、オンデマンド復元処理Ｓ３３００の一部が、第一の実施形態と異なる。
　以下、発明を実施するための第二の形態について図面とともに説明する。第１サーバ装置３ａのファイルシステム３１２は、ルートディレクトリのバージョン管理テーブル２３１を維持する。
　図４８は、図３２に示したディレクトリイメージ作成処理Ｓ３２００の詳細を説明するフローチャートである。以下、同図とともに説明する。
　まず、第１サーバ装置３ａは、過去のある時点のディレクトリイメージを復元する先のディレクトリを作成する（Ｓ４８１１）。第１サーバ装置３ａは、作成したディレクトリのパスと、現在日時と、ディレクトリイメージ保持日数を現在日時に加えた日時とを、それぞれ、ディレクトリ２３１１、復元する日時２３１２、削除する日時２３１３に設定することで、ディレクトリイメージ管理テーブル２３１に新しいエントリを作成する。ここで、ディレクトリイメージ保持日数は、ファイルシステム３１２に設定される、復元先ディレクトリが作成されてから削除されるまでの日数である。
　次に、第１サーバ装置３ａは、第２サーバ装置３ｂに対し、ファイルシステム３１２が復元する日時２３１２のディレクトリイメージのルートディレクトリに存在するディレクトリのメタデータ及びルートディレクトリに存在するファイルのメタデータの取得を次のように行う。
　（１）第１サーバ装置３ａは、ファイルシステム３１２に維持されるルートディレクトリのバージョン管理テーブル２２１からバージョン情報を取得する（Ｓ４８１２）。
　（２）次に、ルートディレクトリのバージョン情報（バージョン管理テーブル２２１）から、復元する日時２３１２を超えない、かつ、最も近い格納日時２２１１を、検索し、検索された格納日時に対応するバージョンＩＤ２２１２を取得する（Ｓ４８１３）。
　（３）第１サーバ装置３ａは、第２サーバ装置３ｂに対し、取得したバージョンＩＤ２２１２をもつルートディレクトリに存在するディレクトリのメタデータ、及びルートディレクトリに存在するファイルのメタデータの取得要求を、第２サーバ装置３ｂに送信する（Ｓ４８１４）（図３２のＳ３２１１）。
　（４）第２サーバ装置３ｂは、上記取得要求を受信すると（Ｓ４８２１）、要求されているルートディレクトリのメタデータ、復元するバージョンのルートディレクトリに存在するディレクトリのメタデータ、及び復元するバージョンのルートディレクトリに存在するファイルのメタデータを第２ストレージ装置１０ｂから取得し、取得したメタデータを第１ストレージ装置１０ａに送信する（Ｓ４８２２）（図３２のＳ３２１２、Ｓ３２１３）。
　次に第１サーバ装置３ａは、第２サーバ装置３ｂからメタデータを受信すると（Ｓ４８１５）（図３２のＳ３２１３）、受信したメタデータに従ったディレクトリイメージを第１ストレージ装置１０ａに構成（復元）する（Ｓ４８１６）（図３２のＳ３２１４）。またこのとき、第１サーバ装置３ａは、メタデータ同期要フラグ２１１２をＯＮに、実体同期要フラグ２１１３をＯＮに、読み込み専用フラグをＯＮに、夫々設定する（Ｓ４８１７）。
　図４９は、図３３に示したオンデマンド復元処理Ｓ３３００のうち、親ディレクトリ復元処理の詳細を説明するフローチャートである。以下、図４５と図４９を使って説明する。
　図４５における、Ｓ４５１１～Ｓ４５１３は第一の実施形態における処理と同じである。
　次に、親ディレクトリ復元処理が呼び出されると（Ｓ４５１４）、第１サーバ装置３ａは、ファイルシステム３１２が復元する日時２３１２のファイルシステムの、ルートディレクトリを起点としてアクセス対象ファイルが存在するディレクトリレベル（ディレクトリ階層）に至るまでのディレクトリイメージの復元を、次のように行う。
　（１）第１サーバ装置３ａは、第１ストレージ装置１０aに復元されていないディレクトリのうち、最も浅いディレクトリレベルのディレクトリのリンク先２１１６を取得し、第２サーバ装置３ｂに対し、取得したリンク先２１１６の示すディレクトリに存在するディレクトリのメタデータ、及びルートディレクトリに存在するファイルのメタデータの取得要求を、第２サーバ装置３ｂに送信する（Ｓ４９１１）（図３２のＳ３２１１）。
　（２）第２サーバ装置３ｂは、上記取得要求を受信すると（Ｓ４９２１）、要求されているディレクトリのメタデータ、復元するバージョンのディレクトリに存在するディレクトリのメタデータ、及び復元するバージョンのルートディレクトリに存在するファイルのメタデータを第２ストレージ装置１０ｂから取得し、取得したメタデータを第１ストレージ装置１０ａに送信する（Ｓ４８２２）（図３２のＳ３２１２、Ｓ３２１３）。
（３）第１サーバ装置３ａは、第２サーバ装置３ｂから送られてくるデータを受信すると（Ｓ４９１２）、そのデータを用いてディレクトリイメージを第１ストレージ装置１０ａに復元する（Ｓ４９１３）（図３３のＳ３３１６）。
　（４）第１サーバ装置３ａは、アクセス対象ファイルが存在するディレクトリレベルに至るまで、Ｓ４９１１～Ｓ４９１３を繰り返す（Ｓ４９１４）。
　親ディレクトリ復元処理Ｓ４５１４が完了したら、図４５のＳ４５１５～Ｓ４５１６を実行し、処理を完了する。
　このように、本実施形態の情報処理システム１にあっては、第２サーバ装置３ｂがバージョン情報を外部に提供しない場合においても、第一の実施形態と同様の効果を得ることができる。
　さらに、第一の実施形態に比べて、バージョン情報を使ったバージョンＩＤの検索が少ないことから、クライアント装置２に対する性能を高めることができる（応答速度を小さくすることができる）。
　以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。
　例えば、以上の説明では、ファイル共有処理部３１１、ファイルシステム３１２、データ操作要求受付部３１３、データ複製／移動処理部３１４、ファイルアクセスログ取得部３１７、及びカーネル／ドライバ３１８の各機能が仮想マシン３１０において実現されているものとして説明したが、これらの機能は必ずしも仮想マシン３１０において実現されるものでなくてもよい。
　また、以上の説明では、ルートディレクトリからアクセス対象ファイルまでを第１ストレージ装置１０ａに復元するものとして説明したが、同様の方法でその一部を復元するように構成することもできる。例えば、アクセス対象ファイルの親ディレクトリとアクセス対象ファイルを復元することもできる。
１　情報処理システム
２　クライアント装置
３ａ　第１サーバ装置
３ｂ　第２サーバ装置
５　通信ネットワーク
６ａ　第１ストレージネットワーク
６ｂ　第２ストレージネットワーク
７　通信ネットワーク
１０ａ　第１ストレージ装置
１０ｂ　第２ストレージ装置
５０　エッジ
５１　コア
３１１　ファイル共有処理部
３１２　ファイルシステム
３１３　データ操作要求受付部
３１４　データ複製／移動処理部
３１７　ファイルアクセスログ取得部
３１８　カーネル／ドライバ
３３１　レプリケーション情報管理テーブル
３３５　ファイルアクセスログ
３６５　リストアログ
３６８　ファイルアクセスログ

Claims (14)

  1. 　第１ファイルシステムを有し、Ｉ／Ｏ要求をクライアント装置から受け付ける第１サーバ装置と、
    　前記第１サーバ装置のストレージを構成する第１ストレージ装置と、
    　第２ファイルシステムを有し、前記第１サーバ装置に通信可能に接続された第２サーバ装置と、
    　前記第２サーバ装置のストレージを構成する第２ストレージ装置と、
    　を備え、
    　前記第１サーバ装置は、前記第１ストレージ装置に記憶されている、前記Ｉ／Ｏ要求の対象であるファイルのデータを前記第２サーバ装置に送信し、
    　前記第２サーバ装置は、前記第１サーバ装置から送られてくる前記データを、前記第１ファイルシステムにおけるディレクトリイメージを前記第２のファイルシステムで保持しつつ、前記第２ストレージ装置に記憶する、
    情報処理システムであって、
    　前記第２サーバ装置は、前記第１サーバ装置のファイルシステムに構成されていたディレクトリイメージのうちの所定の階層の第１ディレクトリイメージを、前記第２ストレージ装置に記載されているディレクトリイメージから取得して前記第１サーバ装置に送信し、
    　前記第１サーバ装置は、前記第２サーバ装置から送られた前記第１ディレクトリイメージを前記第１ストレージ装置に復元した後、復元されようとしているファイルに対するＩ／Ｏ要求を前記クライアント装置から受け付けると、当該受け付けた前記Ｉ／Ｏ要求を処理するために必要となる第２ディレクトリイメージが前記第１ストレージ装置の前記第１ディレクトリイメージに存在するか否かを判定し、当該第２ディレクトリイメージが存在しない場合、当該第２ディレクトリイメージを前記第２サーバ装置に要求し
    　前記第２サーバ装置は、前記第１サーバ装置から前記要求が送られてくると、前記第２ディレクトリイメージを前記第２ストレージ装置から読み出して前記第１サーバ装置に送信し、当該第１サーバ装置は、前記第２ディレクトリイメージを前記第１ストレージ装置に復元し、
    　前記第１サーバ装置は前記第１ディレクトリイメージと、前記第２ディレクトリイメージと、を含む、目的ディレクトリイメージを前記第１ストレージに復元し、
    　前記第２サーバ装置の前記第２ファイルシステムは、ファイルシステムオブジェクトの作成又は更新の都度、当該作成又は更新後のファイルシステムオブジェクトを異なるバージョンＩＤで管理し、前記第１サーバ装置は前記目的ディレクトリを復元する過程で前記バージョンＩＤを利用する、
    　情報処理システム。
  2. 　前記第１サーバ装置の第１ファイルシステムは、過去のある時点での復元されたルートディレクトリに存在するディレクトリのメタデータと、前記ルートディレクトリに存在するファイルのメタデータと、を前記第２サーバ装置に要求し、
    　前記第２サーバは、当該要求を受けると、前記メタデータを前記第２ストレージ装置から取得して前記１サーバ装置に設定された復元先ディレクトリに送信し、
    　前記第１サーバ装置は、前記復元先ディレクトリの前記メタデータに従って前記ルートディレクトリと、当該ルートディレクトリ直下のファイルシステムオブジェクトとからなるディレクトリイメージを構成し、当該ディレクトリイメージを前記第１ディレクトリイメージとして前記第１ストレージ装置に復元する、
    　請求項１記載の情報処理システム。
  3. 　前記第１サーバ装置は、前記目的ディレクトリイメージに存在する前記ファイルのメタデータを前記第１ストレージ装置から取得し、当該メタデータに基づいて前記第２サーバに前記ファイルの実体であるデータを要求し、
    　前記第２サーバ装置は、この要求に基づいて当該データを前記第２ストレージ装置から取得して前記第１サーバ装置に送信し、
    　当該第１サーバ装置は、当該データを取得すると、これを前記第１ストレージ装置の前記目的ディレクトリイメージの前記ファイルに格納する、
    　請求項２記載の情報処理システム。
  4. 　前記第１ファイルシステムは、当該第１ファイルシステムに属するファイルシステムオブジェクトのメタデータ又はデータに対する書き込みを、当該ファイルシステムオブジェクトに対するアクセス権のビューを変えることなく抑制するためのフラグを有し、
    　前記第１サーバ装置は、前記目的ディレクトリイメージに対する前記フラグを、前記メタデータ又はデータに対する読取専用の状態に設定する、請求項１記載の情報処理システム。
  5. 　前記第１サーバ装置は、前記第１ディレクトリイメージが復元された復元先ディレクトリを作成し、当該復元先ディレクトリに前記第１ディレクトリイメージが復元された復元日時を前記復元先ディレクトリと共に、ディレクトリイメージ管理テーブルに記録し、当該ディレクトリイメージ管理テーブルへの前記復元先ディレクトリと前記復元日時との記録を、所定のタイミングで複数実行する、請求項１記載の情報処理システム。
  6. 　前記第２サーバ装置の前記第２ファイルシステムは、ファイルシステムオブジェクトの作成又は更新の都度、当該作成又は更新後のファイルシステムオブジェクトを前記異なるバージョンＩＤと共に前記作成又は更新が実行された日時とによって管理する、請求項１記載の情報処理システム。
  7. 　前記第１サーバ装置は、前記バージョンＩＤの情報及び前記日時の情報、さらに、前記復元されようとしているファイルの復元日とに基づいて、前記第１ディレクトリイメージに属するファイルシステムオブジェクトのバージョンＩＤの中から特定のバージョンＩＤを決定し、当該特定バージョンＩＤで特定される前記ファイルシステムオブジェクトの前の取得要求を前記第２サーバに送信し、
    　前記第２サーバ装置は、前記特定バージョンＩＤのファイルシステムオブジェクトを含む第１ディレクトリイメージを前記第２ストレージ装置から取得して前記第１サーバ装置に送信し、当該第１サーバ装置は、当該第１ディレクトリイメージを前記第１ストレージ装置に復元する、請求項６記載の情報処理システム。
  8. 　前記第１サーバ装置は、前記特定のバージョンＩＤで特定される前記ファイルシステムオブジェクトを、前記ファイルの復元日に最も近い日付によって管理された前記ファイルシステムオブジェクトに設定する、請求項７記載の情報処理システム。
  9. 　前記第１サーバ装置は、
    　前記クライアント装置から前記復元されようとしているファイルに対するＩ／Ｏ要求を受付けると、前記クライアント装置からの前記復元先ディリクトリに構成された前記第１ディレクトリイメージに前記ファイルのメタデータが存在するか否かを調べ、
    　前記ファイルのメタデータが前記第１ディレクトリイメージに存在しない場合、前記Ｉ／Ｏ要求におけるパス情報に基づいて、前記第１ディレクトリイメージの直下の階層を含めた下層の階層にある前記第２ディレクトリイメージのメタデータとして前記ファイルのメタデータが得られるまで、前記第２サーバに対する当該第２のディレクトリイメージのメタデータの要求と、当該第２サーバの前記第２ストレージ装置からのメタデータの取得、そして、取得したメタデータの前記第１サーバへの送信とを繰り返し、
    　前記復元対象ファイルのメタデータを復元できた後、当該メタデータに従った特定ディレクトリイメージを構成した後前記第１ストレージ装置に格納する、請求項１記載の情報処理システム。
  10. 　前記第１サーバ装置は、前記特定ディレクトリイメージに存在する前記復元対象ファイルを更新するＩ／Ｏ要求を前記クライアント装置から受け付けると、当該復元対象ファイルの実体を前記第２サーバに要求し、
    　前記第２サーバ装置が当該要求に基づいて前記第２ストレージ装置から前記実体を取得して前記第１サーバ装置に送信し、
    　前第１サーバ装置は前記実体を、前記特定ディレクトリイメージの前記復元対象ファイルに格納する、請求項９記載の情報処理システム。
  11. 　前記第１サーバ装置は前記ファイルの実体を前記第２サーバ装置に要求する際、当該ファイルの実体の全てではなく、一部の実体を前記第２サーバ装置に要求する、請求項１０記載の情報処理システム。
  12. 　前記第１サーバ装置は、請求項５記載のディレクトリ管理テーブルに存在する複数の復元日時のうち、前記クライアント装置から要求があった所定の復元日時の復元先ディレクトリに格納されている前記第１ディレクトリイメージに基づいて、前記復元対象ファイルの前記メタデータを復元する、請求項６記載の情報処理システム。
  13. 　前記第１サーバ装置は、前記第１ストレージ装置に格納されている前記第１ディレクトリイメージについて、当該第１ディレクトリイメージの復元日からの経過日時をチェックし、当該経過日時が所定日時を経過すると判定すると、前記第１ディレクトリイメージを前記第１ストレージ装置から削除する、請求項１記載の情報処理システム。
  14. 　第１ファイルシステムを有し、Ｉ／Ｏ要求をクライアント装置から受け付ける第１サーバ装置と、前記第１サーバ装置のストレージを構成する第１ストレージ装置と、第２ファイルシステムを有し、前記第１サーバ装置に通信可能に接続された第２サーバ装置と、前記第２サーバ装置のストレージを構成する第２ストレージ装置と、を備え、前記第１サーバ装置は、前記第１ストレージ装置に記憶されている、前記Ｉ／Ｏ要求の対象であるファイルのデータを前記第２サーバ装置に送信し、前記第２サーバ装置は、前記第１サーバ装置から送られてくる前記データを、前記第１ファイルシステムにおけるディレクトリイメージを前記第２のファイルシステムで保持しつつ、前記第２ストレージ装置に記憶する、
    情報処理システムにおけるファイルの復元方法であって、
    　前記第２サーバ装置は、前記第１サーバ装置のファイルシステムに構成されていたディレクトリイメージのうちの所定の階層の第１ディレクトリイメージを、前記第２ストレージ装置に記載されているディレクトリイメージから取得して前記第１サーバ装置に送信し、
    　前記第１サーバ装置は、前記第２サーバ装置から送られた前記第１ディレクトリイメージを前記第１ストレージ装置に復元した後、復元されようとしているファイルに対するＩ／Ｏ要求を前記クライアント装置から受け付けると、当該受け付けた前記Ｉ／Ｏ要求を処理するために必要となる第２ディレクトリイメージが前記第１ストレージ装置の前記第１ディレクトリイメージに存在するか否かを判定し、当該第２ディレクトリイメージが存在しない場合、当該第２ディレクトリイメージを前記第２サーバ装置に要求し
    　前記第２サーバ装置は、前記第１サーバ装置から前記要求が送られてくると、前記第２ディレクトリイメージを前記第２ストレージ装置から読み出して前記第１サーバ装置に送信し、当該第１サーバ装置は、前記第２ディレクトリイメージを前記第１ストレージ装置に復元し、
    　前記第１サーバ装置は前記第１ディレクトリイメージと、前記第２ディレクトリイメージと、を含む、目的ディレクトリイメージを前記第１ストレージに復元し、
    前記第２サーバ装置の前記第２ファイルシステムは、ファイルシステムオブジェクトの作成又は更新の都度、当該作成又は更新後のファイルシステムオブジェクトを異なるバージョンＩＤで管理し、前記第１サーバ装置は前記目的ディレクトリを復元する過程で前記バージョンＩＤを利用する、
    　ファイルの復元方法。
PCT/JP2011/006072 2011-10-28 2011-10-28 情報処理システム、及び、それを用いたファイル復元方法 WO2013061388A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
PCT/JP2011/006072 WO2013061388A1 (ja) 2011-10-28 2011-10-28 情報処理システム、及び、それを用いたファイル復元方法
CN201180074094.1A CN103858109B (zh) 2011-10-28 2011-10-28 信息处理系统及使用该信息处理系统的文件恢复方法
IN3375DEN2014 IN2014DN03375A (ja) 2011-10-28 2011-10-28
EP11874819.3A EP2772863B1 (en) 2011-10-28 2011-10-28 Information processing system and file restoration method using same
JP2013540516A JP5706966B2 (ja) 2011-10-28 2011-10-28 情報処理システム、及び、それを用いたファイル復元方法
US13/388,193 US20130110790A1 (en) 2011-10-28 2011-10-29 Information processing system and file restoration method using same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/006072 WO2013061388A1 (ja) 2011-10-28 2011-10-28 情報処理システム、及び、それを用いたファイル復元方法

Publications (1)

Publication Number Publication Date
WO2013061388A1 true WO2013061388A1 (ja) 2013-05-02

Family

ID=48167256

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/006072 WO2013061388A1 (ja) 2011-10-28 2011-10-28 情報処理システム、及び、それを用いたファイル復元方法

Country Status (6)

Country Link
US (1) US20130110790A1 (ja)
EP (1) EP2772863B1 (ja)
JP (1) JP5706966B2 (ja)
CN (1) CN103858109B (ja)
IN (1) IN2014DN03375A (ja)
WO (1) WO2013061388A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016098152A1 (ja) * 2014-12-15 2016-06-23 株式会社日立製作所 情報システム

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7631151B2 (en) 2005-11-28 2009-12-08 Commvault Systems, Inc. Systems and methods for classifying and transferring information in a storage network
US20200257596A1 (en) 2005-12-19 2020-08-13 Commvault Systems, Inc. Systems and methods of unified reconstruction in storage systems
US8930496B2 (en) 2005-12-19 2015-01-06 Commvault Systems, Inc. Systems and methods of unified reconstruction in storage systems
US7882077B2 (en) 2006-10-17 2011-02-01 Commvault Systems, Inc. Method and system for offline indexing of content and classifying stored data
US8370442B2 (en) 2008-08-29 2013-02-05 Commvault Systems, Inc. Method and system for leveraging identified changes to a mail server
US20080228771A1 (en) 2006-12-22 2008-09-18 Commvault Systems, Inc. Method and system for searching stored data
US8442983B2 (en) 2009-12-31 2013-05-14 Commvault Systems, Inc. Asynchronous methods of data classification using change journals and other data structures
US8719264B2 (en) 2011-03-31 2014-05-06 Commvault Systems, Inc. Creating secondary copies of data based on searches for content
US8954492B1 (en) * 2011-11-30 2015-02-10 F5 Networks, Inc. Methods for inlining content externally referenced in a web page prior to providing the web page to a requestor and devices thereof
US8892523B2 (en) * 2012-06-08 2014-11-18 Commvault Systems, Inc. Auto summarization of content
US9208163B2 (en) * 2013-01-15 2015-12-08 Ca, Inc. Methods for preserving generation data set sequences
US9319265B2 (en) * 2013-02-22 2016-04-19 Hitachi Data Systems Engineering UK Limited Read ahead caching of data from cloud storage and method thereof
US10013217B1 (en) * 2013-06-28 2018-07-03 EMC IP Holding Company LLC Upper deck file system shrink for directly and thinly provisioned lower deck file system in which upper deck file system is stored in a volume file within lower deck file system where both upper deck file system and lower deck file system resides in storage processor memory
US10452484B2 (en) * 2014-05-15 2019-10-22 Carbonite, Inc. Systems and methods for time-based folder restore
US9992298B2 (en) * 2014-08-14 2018-06-05 International Business Machines Corporation Relationship-based WAN caching for object stores
WO2016033056A1 (en) 2014-08-26 2016-03-03 Ctera Networks, Ltd. A method and computing device for allowing synchronized access to cloud
US9836476B2 (en) * 2014-09-25 2017-12-05 Netapp, Inc. Synchronizing configuration of partner objects across distributed storage systems using transformations
US10120920B2 (en) 2015-07-10 2018-11-06 International Business Machines Corporation Increasing storage space for processes impacting data storage systems
US10353994B2 (en) 2015-11-03 2019-07-16 Commvault Systems, Inc. Summarization of email on a client computing device based on content contribution to an email thread using classification and word frequency considerations
US10296594B1 (en) 2015-12-28 2019-05-21 EMC IP Holding Company LLC Cloud-aware snapshot difference determination
US11023433B1 (en) * 2015-12-31 2021-06-01 Emc Corporation Systems and methods for bi-directional replication of cloud tiered data across incompatible clusters
CN106484566B (zh) * 2016-09-28 2020-06-26 上海爱数信息技术股份有限公司 基于ndmp协议的nas数据备份和文件细粒度浏览恢复方法
US9933945B1 (en) 2016-09-30 2018-04-03 EMC IP Holding Company LLC Efficiently shrinking a dynamically-sized volume
US10540516B2 (en) 2016-10-13 2020-01-21 Commvault Systems, Inc. Data protection within an unsecured storage environment
US10599626B2 (en) 2016-10-25 2020-03-24 International Business Machines Corporation Organization for efficient data analytics
US10331115B2 (en) * 2016-11-28 2019-06-25 Asm Ip Holding B.V. Substrate processing system, storage medium and data processing method
CN110235118B (zh) * 2017-02-13 2023-09-19 日立数据管理有限公司 通过存根化优化内容存储
US10423609B1 (en) * 2017-03-29 2019-09-24 Amazon Technologies, Inc. Consistent snapshot points in a distributed storage service
US10984041B2 (en) 2017-05-11 2021-04-20 Commvault Systems, Inc. Natural language processing integrated with database and data storage management
US10635632B2 (en) 2017-08-29 2020-04-28 Cohesity, Inc. Snapshot archive management
US11874805B2 (en) 2017-09-07 2024-01-16 Cohesity, Inc. Remotely mounted file system with stubs
US11321192B2 (en) * 2017-09-07 2022-05-03 Cohesity, Inc. Restoration of specified content from an archive
US10719484B2 (en) 2017-09-07 2020-07-21 Cohesity, Inc. Remotely mounted file system with stubs
US10642886B2 (en) 2018-02-14 2020-05-05 Commvault Systems, Inc. Targeted search of backup data using facial recognition
US11301421B2 (en) * 2018-05-25 2022-04-12 Microsoft Technology Licensing, Llc Scalable multi-tier storage structures and techniques for accessing entries therein
US11159469B2 (en) 2018-09-12 2021-10-26 Commvault Systems, Inc. Using machine learning to modify presentation of mailbox objects
CN109600600B (zh) * 2018-10-31 2020-11-03 万维科研有限公司 涉及深度图转换的编码器、编码方法以及三层表达式的存储方法和格式
JP7287026B2 (ja) * 2019-03-18 2023-06-06 富士フイルムビジネスイノベーション株式会社 情報処理装置、ファイル管理装置、ファイル管理システム及びプログラム
US11204892B2 (en) 2019-03-21 2021-12-21 Microsoft Technology Licensing, Llc Techniques for snapshotting scalable multitier storage structures
CN111459710B (zh) * 2020-03-27 2021-06-11 华中科技大学 感知热度与风险的纠删码内存恢复方法、设备及内存系统
US11704035B2 (en) 2020-03-30 2023-07-18 Pure Storage, Inc. Unified storage on block containers
US11494417B2 (en) 2020-08-07 2022-11-08 Commvault Systems, Inc. Automated email classification in an information management system
US11487701B2 (en) 2020-09-24 2022-11-01 Cohesity, Inc. Incremental access requests for portions of files from a cloud archival storage tier

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005316708A (ja) 2004-04-28 2005-11-10 Nec Software Tohoku Ltd 階層記憶装置、その復旧方法、及び復旧プログラム
JP2006039942A (ja) * 2004-07-27 2006-02-09 Nec Software Tohoku Ltd 階層記憶システムにおけるファイル管理装置及びそのファイル管理方法
JP2006164211A (ja) * 2004-11-12 2006-06-22 Nec Corp ストレージ管理システムと方法並びにプログラム
JP2008040699A (ja) 2006-08-04 2008-02-21 Fujitsu Ltd Ｈｓｍ制御プログラム、ｈｓｍ制御装置、ｈｓｍ制御方法
JP2009289252A (ja) * 2008-05-30 2009-12-10 Hitachi Ltd 階層ストレージシステムでのリモート複製
JP2011039805A (ja) * 2009-08-12 2011-02-24 Hitachi Ltd 階層管理ストレージシステムおよびストレージシステムの運用方法
JP2011076294A (ja) * 2009-09-30 2011-04-14 Hitachi Ltd 階層ストレージ管理システムにおける重複ファイルの転送方法及びシステム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6829617B2 (en) * 2002-02-15 2004-12-07 International Business Machines Corporation Providing a snapshot of a subset of a file system
US7475098B2 (en) * 2002-03-19 2009-01-06 Network Appliance, Inc. System and method for managing a plurality of snapshots
US7752176B1 (en) * 2004-03-31 2010-07-06 Emc Corporation Selective data restoration
US9501368B2 (en) * 2008-09-30 2016-11-22 Veritas Technologies Llc Backing up and restoring selected versioned objects from a monolithic database backup
US8504515B2 (en) * 2010-03-30 2013-08-06 Commvault Systems, Inc. Stubbing systems and methods in a data replication environment
US8799231B2 (en) * 2010-08-30 2014-08-05 Nasuni Corporation Versioned file system with fast restore
US8548959B2 (en) * 2010-11-29 2013-10-01 Ca, Inc. System and method for minimizing data recovery window

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005316708A (ja) 2004-04-28 2005-11-10 Nec Software Tohoku Ltd 階層記憶装置、その復旧方法、及び復旧プログラム
JP2006039942A (ja) * 2004-07-27 2006-02-09 Nec Software Tohoku Ltd 階層記憶システムにおけるファイル管理装置及びそのファイル管理方法
JP2006164211A (ja) * 2004-11-12 2006-06-22 Nec Corp ストレージ管理システムと方法並びにプログラム
JP2008040699A (ja) 2006-08-04 2008-02-21 Fujitsu Ltd Ｈｓｍ制御プログラム、ｈｓｍ制御装置、ｈｓｍ制御方法
JP2009289252A (ja) * 2008-05-30 2009-12-10 Hitachi Ltd 階層ストレージシステムでのリモート複製
JP2011039805A (ja) * 2009-08-12 2011-02-24 Hitachi Ltd 階層管理ストレージシステムおよびストレージシステムの運用方法
JP2011076294A (ja) * 2009-09-30 2011-04-14 Hitachi Ltd 階層ストレージ管理システムにおける重複ファイルの転送方法及びシステム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2772863A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016098152A1 (ja) * 2014-12-15 2016-06-23 株式会社日立製作所 情報システム

Also Published As

Publication number Publication date
EP2772863A1 (en) 2014-09-03
JPWO2013061388A1 (ja) 2015-04-02
JP5706966B2 (ja) 2015-04-22
US20130110790A1 (en) 2013-05-02
EP2772863A4 (en) 2015-08-12
EP2772863B1 (en) 2016-07-27
CN103858109B (zh) 2016-08-17
IN2014DN03375A (ja) 2015-06-26
CN103858109A (zh) 2014-06-11

Similar Documents

Publication Publication Date Title
JP5706966B2 (ja) 情報処理システム、及び、それを用いたファイル復元方法
JP5452765B2 (ja) 情報処理システムにおける障害復旧方法、及び情報処理システム
JP5716099B2 (ja) 情報処理システム及び情報処理システムの制御方法
JP5439607B2 (ja) サーバ装置及びサーバ装置の制御方法
WO2013001581A1 (en) Server system and method for controlling information system
US8538924B2 (en) Computer system and data access control method for recalling the stubbed file on snapshot
US10852996B2 (en) System and method for provisioning slave storage including copying a master reference to slave storage and updating a slave reference
US20080195827A1 (en) Storage control device for storage virtualization system
WO2012147124A1 (en) Server apparatus and method of controlling information system
JP6604115B2 (ja) ストレージ装置およびストレージ制御プログラム
US9063892B1 (en) Managing restore operations using data less writes
US20200073584A1 (en) Storage system and data transfer control method
JP5681783B2 (ja) 情報処理システムにおける障害復旧方法、及び情報処理システム
Xu et al. YuruBackup: a space-efficient and highly scalable incremental backup system in the cloud
US8447944B2 (en) Information processing device and data shredding method
WO2017122313A1 (ja) オブジェクト履歴として表示される情報をクライアントに提供する計算機システム及び計算機
US8311992B2 (en) Information processing device and data shredding method
Appuswamy et al. File-level, host-side flash caching with loris

Legal Events

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

Ref document number: 13388193

Country of ref document: US

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

Ref document number: 11874819

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013540516

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2011874819

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011874819

Country of ref document: EP