System, method, or program for data transfer processing
By mounting a common volume for data transfer and dynamically allocating computer resources, the system enhances data transfer speed and efficiency, addressing the inefficiencies of existing methods in utilizing broadband storage and adjusting resource configurations.
Patent Information
- Application Number
- JP2023113357
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-07-10
- Publication Date
- 2025-01-23
AI Technical Summary
Existing data transfer methods, such as those described in Patent Document 1, are inefficient in utilizing the bandwidth of broadband storage and do not adequately adjust computer resource configurations based on the volume size, leading to slow data transfer processing, especially with increased data volumes.
The system includes a first storage section, a second storage section, and a data transfer section with a computer resource activation unit and an area allocation unit to mount one common volume for data transfer processing, allowing parallel data transfer and adjusting computer resources based on volume size and required transfer capacity.
This approach increases data transfer speed by fully utilizing the bandwidth of the storage and dynamically allocating computer resources, reducing costs and optimizing resource usage based on transfer needs.
Smart Images

Figure 2025010997000001_ABST
Abstract
Description
[Technical field]
[0001] The present disclosure relates to a technique for performing data transfer processing for volume data. [Background technology]
[0002] In recent years, a new operating model called hybrid cloud has emerged, in which on-premise IT assets and public cloud services are combined according to cost and purpose.Compared to on-premise IT assets, public clouds are characterized by the flexibility of using the necessary computing resources on a pay-as-you-go basis. A representative public cloud service is an object store that stores data in object storage format and accesses it through a REST API (Representational State Transfer Application Interface). Object stores can be used for data backup and archiving because they can use almost unlimited capacity at a low bit cost without prior capacity planning. Furthermore, it is known that the backed up data can be restored to an environment constructed using cloud computing and storage services to offload some of the work on an on-premise system constructed in the user's data center, or used as a recovery site (secondary site) in the event of a disaster. When using the above-mentioned services and storages, data transfer processing (e.g., backup processing or restore processing) is involved. Patent Document 1 discloses a method for speeding up backup processing by providing a data mover and transferring data between storages without going through a host. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] U.S. Patent No. 7,496,723 Summary of the Invention [Problem to be solved by the invention]
[0004] Generally, data transfer takes time. Therefore, in order to offload part of the business or to quickly use a secondary site in the event of a disaster, it is important to complete data transfer processing (for example, backup processing or restore processing) as quickly as possible. In particular, the amount of data to be transferred has increased dramatically in recent years, making it increasingly important to speed up data transfer processing. On the other hand, high-bandwidth storage devices are being provided as storage devices that can be used as destinations or sources in data transfer processes (e.g., destinations in backup processes or sources in restore processes). For example, the bandwidth of the object stores described above is so high that it is not possible for a single computer resource to fully use up the bandwidth. Patent Document 1 discloses a method of transferring data between volumes using a data mover without going through a host, but does not disclose a method of dividing and having multiple data movers take charge of the data transfer process for one volume. Therefore, with the technology of Patent Document 1, it takes time depending on the amount of data to be transferred, that is, the volume size. Patent Document 1 does not specify the processing performance (data transfer performance) of the data mover, but when a data mover is applied to a wide-bandwidth storage (for example, the above-mentioned object store), the data transfer speed provided by the data mover will not be sufficient if it only has the performance of one computer resource. Patent Document 1 does not disclose any method or control for temporarily increasing or decreasing the configuration of computer resources according to the amount of data to be transferred or the required speed of data transfer. Therefore, with the technology of Patent Document 1, it is difficult to change the configuration of the data mover according to the volume size.
[0005] In view of the above, one of the objectives of the present disclosure is to speed up data transfer processing. Another objective of the present disclosure is to speed up data transfer processing by fully utilizing the bandwidth of the storage that is the destination or source of the data transfer processing. Another objective of the present disclosure is to configure computer resources according to the required transfer capacity by adjusting the configuration of computer resources for performing data transfer processing according to the amount of data to be transferred in the data transfer processing and the required speed of the data transfer processing. [Means for solving the problem]
[0006] In order to achieve at least one of the above objects, the present disclosure may have the following features, for example. The system comprises a first storage unit, a second storage unit, and a data transfer unit. The first storage unit comprises a volume for storing data. One volume consists of one or more storage areas. The data transfer unit comprises a computer resource starting unit and an area allocation unit. When performing data transfer processing between one volume and the second storage unit, the computer resource starting unit starts one or more computer resources that perform the data transfer processing, and mounts one common volume that serves as the transfer source or transfer destination in the data transfer processing to any of the started computer resources. Mounting a volume to a computer resource means making the computer resource recognize the volume and enabling the computer resource to access data in the volume. The area allocation unit allocates data transfer processing to the computer resources for each storage area. The computer resource performs data transfer processing between the storage area allocated to the computer resource in the one common volume and the second storage unit. Effect of the Invention
[0007] As described above, the present disclosure can mount a common volume that is a source or destination of the data transfer process on one or more computer resources that perform the data transfer process, and can cause each of the computer resources to perform the data transfer process in parallel, thereby speeding up the data transfer process. Also, as described above, even if the bandwidth of the second storage unit that is the storage that is the destination or source of the data transfer process is wide, the present disclosure can fully utilize the bandwidth of the storage by having one or more computer resources access the storage in parallel. Furthermore, as described above, the present disclosure assigns data transfer processing to computer resources for each storage area in a common volume that is a source or destination of the data transfer process, and can therefore configure computer resources according to the transfer capacity required for the data transfer process.
[0008] A method or program that achieves the same processing as that achieved by the above system can also achieve the same effects as the above system. Furthermore, if it is in the form of a program, costs can be reduced in many cases. With a program, design changes regarding processing can be easily made. Other features that the present disclosure may have and the effects corresponding to these features will be disclosed in this specification, the claims, or the drawings. [Brief description of the drawings]
[0009] [Figure 1] 1 illustrates a functional configuration of an embodiment of the present disclosure. [Diagram 2] 1 illustrates a computer architecture for implementing an embodiment of the present disclosure. [Diagram 3] 1 illustrates a system configuration of a first embodiment (restore process) of the present disclosure. [Figure 4] An on-premise data centre is shown. [Diagram 5] The management area of the volume and the differential management bitmap (first management information) are shown. [Figure 6] A backup setting screen is shown. [Figure 7A]The following shows the first backup process. [Figure 7B] The second backup process is shown below. [Figure 7C] The third backup process is shown below. [Figure 8] This shows a backup data store (second storage unit). [Figure 9A] This shows the first generation backup catalog. [Figure 9B] Shows the second generation backup catalog. [Figure 10] 1 shows a storage volume service (first storage unit). [Figure 11] 1 shows computer resources constructed in a restore process. [Figure 12] 13 shows a restore setting screen. [Figure 13] The process up to instructing the restore system to perform restore is shown. [Figure 14] The process performed by the restore system during restoration is shown below. [Figure 15] 1 shows a process for constructing a restore plan. [Figure 16] This shows the allocation (queuing) of processing to computer resources during restoration. [Figure 17] 13 shows the process performed by the virtual machine instance during restoration. [Figure 18] This shows the process when the queue length becomes zero during restoration. [Figure 19] 13 illustrates a system configuration of a second embodiment (backup process) of the present disclosure. [Figure 20] 1 shows computer resources constructed in the backup process. [Figure 21] This shows the process up to instructing the backup & restore system to perform a backup. [Figure 22] This shows the process performed by the backup and restore system during backup. [Figure 23] 13 shows the process performed by a virtual machine instance during backup. [Figure 24] This shows the process when the queue length becomes zero during backup. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0010] Hereinafter, the embodiments of the present disclosure will be described in detail with reference to the drawings. Note that the embodiments described below do not limit the disclosure according to the claims, and all of the elements and combinations thereof described in the embodiments are not necessarily essential to the solution of the present disclosure. The following description and drawings are examples for explaining the present disclosure, and are omitted and simplified as appropriate for clarity of explanation. The present disclosure can be implemented in various other forms. Unless otherwise limited, each component may be singular or plural. The position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc. in order to facilitate understanding of the invention. For this reason, the present disclosure is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings. Each of the systems, services, devices, or units of the present disclosure may be integrated as a single piece of hardware, or may be divided into multiple parts that work together to perform their roles. Several systems, services, devices, or units may be integrated as hardware. Each of the systems, devices, or units may be realized by having a computer execute software (programs) (as in FIG. 2). Some of the functions of the system, service, device, or unit may be realized by hardware (e.g., hardwired logic or FPGA), and the remaining functions may be realized by executing software (programs). All of the functions of the system, service, device, or unit may be realized by hardware. Some or all of the steps of the processes shown in the flowcharts and the like described in the present disclosure may be realized by hardware. The program of the present disclosure may be included in the concept that includes software in general, such as software and hardware resources working together to construct a specific information processing device or its operating method according to the purpose of use. In other words, the program of the present disclosure is not limited to a specific type or form of program. In addition, the program may be initially recorded in a compressed format. The same reference numbers are used in multiple drawings to indicate similar things. In the drawings showing the flowcharts described below, rectangular boxes indicate processing steps, and diamond-shaped boxes indicate conditional branch steps. In the drawings showing the flowcharts, "step" is abbreviated as "S." Also, the screen aspects shown in the drawings described below are examples, and are not limited to these.
[0011] In the following, a first embodiment and a second embodiment will be described as embodiments of the present disclosure. Among them, the functional configuration will be described collectively in "1. Functional configuration of the embodiment of the present disclosure". The computer architecture for realizing the embodiments will be described collectively in "2. Computer architecture for realizing the embodiment of the present disclosure". The system configuration and the processing will be described separately for each embodiment.
[0012] 1. Functional configuration of the embodiment of the present disclosure Fig. 1 shows a functional configuration of an embodiment of the present disclosure. Note that not all of the functional configurations shown in Fig. 1 are essential. In FIG. 1, the system 100 includes a first storage unit 101, a second storage unit 102, and a data transfer unit 103. The data transfer unit 103 is for performing data transfer processing between the first storage unit 101 and the second storage unit 102 (for example, a backup processing for transferring data from the first storage unit 101 to the second storage unit 102, or a restore processing for transferring data from the second storage unit 102 to the first storage unit 101). The first storage unit 101 includes one or more volumes 111 for storing data. One volume 111 includes one or more storage areas. This storage area is also referred to as a management area 112 when it includes first management information or second management information described later. (In the drawings, "storage area" or "management area" is abbreviated to "area".) The data transfer unit 103 may include a computer resource number determination unit 132 ("computer resource number determination unit" is abbreviated to "number determination unit" in the drawings). When performing data transfer processing between one volume 111 and the second storage unit 102, the computer resource number determination unit 132 determines the number of computer resources performing the data transfer processing, and transmits the number to a computer resource startup unit 133 described below. The data transfer unit 103 includes a computer resource startup unit 133 ("computer resource startup unit" is abbreviated to "startup unit" in the drawings). The computer resource startup unit 133 starts up the number of computer resources determined by the computer resource number determination unit 132. In the example of FIG. 1, the computer resource startup unit 133 constructs (starts up) three computer resources 131. The computer resource startup unit 133 mounts one common volume 111, which is to be the transfer source or transfer destination in the data transfer processing, to any of the started computer resources 131. Here, mounting the volume 111 on the computer resource 131 means making the computer resource 131 recognize the volume 111 and enabling the computer resource 131 to access the data in the volume 111. Furthermore, when backup processing is performed multiple times (for multiple generations), the second storage unit 102 may store the backup data 121 for each combination of generation and storage area (management area). The data transfer unit 103 includes an area allocating unit 134 (the "area allocating unit" is abbreviated to "allocating unit" in the drawings). The area allocating unit 134 allocates data transfer processing to the computer resource 131 for each storage area or management area 112.1 shows an example in which the computer resource startup unit 133 constructs (starts) three computer resources 131, and the area allocation unit 134 assigns data transfer processing to the three constructed (started) computer resources 131 for each storage area or management area 112. The computer resource 131 performs data transfer processing between the storage area or management area 112 assigned to the computer resource 131 in one common volume 111 and the second storage unit 102. The data transfer unit 103 may include a setting change unit 135. When mounting one common volume 111 for multiple computer resources 131, the setting change unit 135 changes the setting of the one common volume 111 to a disk type that can be multi-attached, and when the data transfer processing is completed, returns the setting of the one common volume 111 to a disk type that cannot be multi-attached. The data transfer unit 103 may include a computer resource release unit 136 (the "computer resource release unit" is abbreviated to "release unit" in the drawings). Here, the computer resource 131 may be a temporary computer resource. The computer resource release unit 136 releases the computer resource 131, which is a temporary computer resource that has completed its allocated data transfer process, even before the entire data transfer process is completed. Furthermore, when a data transfer process is made up of multiple generations of data transfer processes for each storage area or management area 112 that is the source or destination of the data transfer process, the area allocating unit 134 may allocate multiple generations of data transfer processes relating to the same storage area or management area 112 to the same computer resource 131 during the data transfer process. The computer resource 131 may execute multiple generations of data transfer processes relating to the same storage area or management area 112 in the order in which the processing results are normal.
[0013] Since the system 100 in the present disclosure has the functional configuration described above, it can have the effects shown in the above-mentioned [Effects of the Invention]. The system 100 of the present disclosure can set the volume to a multi-attachable setting only for a necessary period, thereby enhancing the security strength regarding access to the volume. Also, in the case where the level of charge is determined according to the volume setting content, the system 100 can reduce the cost of using the volume by setting the volume to a multi-attachable setting only for a necessary period. Furthermore, the system 100 according to the present disclosure can sequentially release computer resources after completing the allocated data transfer processing, and therefore can provide computer resources according to changes in the situation. In addition, the system 100 of the present disclosure can execute a data transfer process so that the processing result is normal when the data transfer process consists of multiple generations of data transfer processes for each storage area or management area 112 that is the source or destination of the data transfer process.
[0014] 2. Computer architecture for implementing embodiments of the present disclosure FIG. 2 illustrates a computer architecture for implementing an embodiment of the present disclosure. To realize the system 100, an information processing device (e.g., a CPU) 201, a storage device (e.g., a memory) 202, a non-volatile recording medium (e.g., a non-volatile memory, a non-volatile disk device) 203, an external recording medium drive (e.g., a disk drive) 204, a display or output device (e.g., a display, a printer) 206, an input device (e.g., a mouse, a keyboard, an imaging device, a sensor) 207, a communication device (e.g., a communication device for wired communication, a communication device for wireless communication; it may be a network interface device (NIC) that controls communication with other systems, services, devices or servers according to a predetermined protocol) 208, and some or all of an external input / output port 209 may be interconnected by an interconnection unit (e.g., a bus, a crossbar switch) 210. The non-volatile recording medium 203 may record the program 220a and various information. As the various information, for example, various databases (DB) 221 or various information 222 may be recorded in the non-volatile recording medium 203. Alternatively, a part or all of the above-mentioned program or various information may be acquired (accessed) from the outside of FIG. 2. The external recording medium drive 204 can connect an external recording medium (for example, a portable recording disk (DVD, etc.), an IC card, an SD card) 205. Note that the program 220a and the above-mentioned various information may be transferred and stored from the external recording medium 205 to the non-volatile recording medium 203 or the storage device 202. The program 220a and the above-mentioned various information may be brought via the communication device 208, the external input / output port 209, or the input device 207, and stored in the non-volatile recording medium 203 or the storage device 202. In order for the architecture of FIG. 2 to function as the system 100, a service, a device, each unit (functional unit) or a part of each unit in the system 100 (to execute one or a series of processes (steps)), the program 220a may be loaded into the storage device 202 (for example, from the non-volatile recording medium 203). The loaded program is indicated by 220b in FIG. 2. The information processing device 201 may then execute the program 220b (using various information present in the non-volatile recording medium 203, etc., as necessary). By executing the program 220b, the function of the system 100, a service, a device, each unit (functional unit) or a part of each unit in the system 100 is realized (one or a series of processes (steps) is executed). At this time, various buffers 223 temporarily formed in the storage device 202 may also be used as appropriate.
[0015] 3. First embodiment of the present disclosure (restore process) The first embodiment has a configuration for restoring backed up data to a logical volume (one example of a volume) on the cloud in a short time. In addition, the following shows an example in which temporary computer resources are used as computer resources for performing the restore process.
[0016] 3.1 System Configuration of the First Embodiment (Restore Processing) of the Present Disclosure 3.1.1 System configuration of a computer system including the system of the present disclosure FIG. 3 shows a system configuration of a computer system 300 including the system 100 according to the first embodiment of the present disclosure. The computer system 300 shown in FIG. 3 includes a data center 301 which is the on-premise side for a terminal 380 and performs main operations, and a data center 302 which is the cloud side for the terminal 380 and serves as a transfer destination for backup processing or restore processing. The data center 301 is, for example, an on-premise system owned by a user as an IT asset, and includes an on-premise storage device 310 and a server group 311. The data center 302 is, for example, a virtual data center provided by a public cloud service provider. The data center 302 is composed of a storage volume service 320, a storage operation management service 330, a backup data store 340, a cloud restore system 350, an internal network 360 which interconnects these, and a related resource group 390 which is temporarily constructed and used. The related resource group 390 is a computer resource which is temporarily constructed and used for processing, and includes, for example, computer instances such as virtual computers and containers, and peripheral services such as a queue service and an event monitor. The data center 301, the data center 302, and the terminal 380 are connected to each other by an appropriate network 370. The network 370 is, for example, the Internet or an IP leased line. A user can access the devices and services of both data centers using the terminal 380. The terminal 380 is, for example, a PC or a mobile terminal. Instead of or in addition to the route via the network 370 shown in FIG. 3, the data centers 301, 302 and the terminal 380 may be connected to each other via another type of network. The data center 302, storage volume service 320, and backup data store 340 in Fig. 3 correspond to the system 100, first storage unit 101, and second storage unit 102 in Fig. 1, respectively. Also, the cloud restore system 350 and part or all of the related resource group (computer resources) 390 in Fig. 3 correspond to the data transfer unit 103 in Fig. 1. Part of the storage operation management service 330 in Fig. 3 may also be included in the data transfer unit 103 in Fig. 1. In this way, the present disclosure can be effectively utilized in cloud services.
[0017] 3.1.2. Internal configuration of on-premise storage device FIG. 4 shows the internal configuration of the on-premise storage device 310. The on-premise storage device 310 includes a plurality of redundant I / O control subsystems 450 (450a, 450b), a device management subsystem 460, a plurality of host interfaces (I / F) 430 (430a, 430b), a plurality of drives 440 (440-0 to 440-n), a management network interface (I / F) 480, and a plurality of backup / restore interfaces (I / F) 410 (410a, 410b). The host interface 430 is for communicating with the server group 311 via the storage network 400. The server group 311 performs read / write I / O to the logical volume 470 via the host interface 430. The drive 440 is a physical storage device such as an SSD (Solid State Drive) or an HDD (Hard Disk Drive). The management network interface 480 communicates with the terminal 380 via the network 370, and also communicates with the storage operation management service 330. The I / O control subsystem 450 configures logical volumes 470 (470-0, 470-1) based on the storage area of the connected drive 440, and provides them to the server group 311. Based on read / write I / O to the logical volume 470 issued from the server group 311, the I / O control subsystem 450 issues read / write I / O to the drive 440 and performs I / O processing. In addition, the I / O control subsystem 450 manages the logical volume 470 in units of a predetermined logical block size (e.g., 8 kilobytes), and records where data has been written. The I / O control subsystem 450 has a processor (CPU) 451 and a memory 452. The processor 451 executes various processes as described above according to the programs stored in the memory 452. The memory 452 is, for example, a RAM (Random Access Memory), and stores the programs executed by the processor 451 and necessary information. The device management subsystem 460 executes processing for performing various settings and monitoring of the on-premise storage device 310. The device management subsystem 460 receives user operation instructions from a terminal 380 via a network 370 and a management network interface 480.The device management subsystem 460 performs various processes by having an internal processor (CPU) 461 execute a program stored in a memory 462. In the example of FIG. 4, the device management subsystem 460 is provided inside the on-premise storage device 310, but the device management subsystem 460 may be provided outside the on-premise storage device 310. In addition, a part of the functions provided by the device management subsystem 460 may be realized by the storage operation management service 330. The backup / restore interface 410 is connected to the backup data store 340 via the network 370, and performs backup processing of the logical volume 470. The backup / restore interface 410 includes a data conversion and transfer control unit 420 (abbreviated as "conversion and transfer control 420" in FIG. 4) for transmitting and receiving data to and from the backup data store 340, and performs conversion and compression of data formats, interpretation of data configurations, and generation of additional information required for storage. In addition, when the backup processing is completed, the backup / restore interface 410 transmits a completion notification and summary information regarding the backup contents to the storage operation management service 330. The summary information may include, for example, what may be a pointer to a backup catalog (described below) corresponding to the backup process (eg, an object name and object key (described below)).
[0018] 3.1.3. Volume management area and differential management bitmap (first management information) A data group held by each of one volume 111 in FIG. 1 and one logical volume 470 in FIG. 4 (further, one logical volume 1070 and 2070 managed by a data center 302 on the cloud side described later) may be managed by dividing them into a plurality of management areas 112. Each of the management areas 112 may be accompanied by first management information indicating which data in the management area 112 should be the target of the backup process. In the following, the logical volume 470 is used as an example of a volume, and the differential management bitmap 500 is used as an example of the first management information. The following description can also be applied to the logical volumes 1070 and 2070 described later. The following description can also be applied to physical volumes that are not logical volumes. In other words, the present disclosure is not limited to logical volumes. FIG. 5 is a diagram showing a schematic diagram of a management state of a logical volume 470 in the on-premise storage device 310. The logical volume 470 (corresponding to the volume 111 in FIG. 1) assigns an LBA (Logical Block Address) for each fixed block size, and manages a storage location of (write) data (block data) 510 written from the server group 311. Since the logical volume 470 generally has a large capacity, the on-premise storage device 310 internally divides it (for example, for every 32 gigabytes) into a plurality of management areas 571A, 571B, 571C (corresponding to the management areas 112A, 112B, 112C in FIG. 1, respectively), and associates first management information with each management area. The on-premise storage device 310 manages the presence or absence of storage of (write) data (block data) 510 by a differential management bitmap 500 (500A, 500B, 500C) (one of the embodiments of the first management information). The differential management bitmap 500 is provided corresponding to the management areas 571A, 571B, 571C of the logical volume 470. When new (write) data is written to the logical volume 470, in the differential management bitmap 500, the bit corresponding to the storage destination LBA of the (write) data is changed to ON (represented by a black square in FIG. 5), and the fact that the (write) data has been written is recorded in the differential management bitmap 500. The differential management bitmap 500 is replaced with a new bitmap every time a backup is acquired. In other words, it is possible to determine the differential data (write data) to be backed up and its location in each generation of backup processing. Some storage devices have a volume snapshot acquisition function (for example, a function to acquire a snapshot of block data of all LBAs contained in a volume). In this case, the storage device may create the differential management bitmap 500 by comparing snapshots of two generations. Alternatively, if the snapshot acquisition function is accompanied by management information having the same effect as the function provided by the differential management bitmap, the storage device may use that management information. In addition, instead of using a bitmap, the storage device may manage the update information using another means capable of maintaining the information, such as recording the start LBA of the area updated by the (write) data and the size of the (write) data (e.g., the number of blocks) as a list. In this way, the present disclosure provides first management information (e.g., differential management bitmap 500) for each management area within a volume, making it possible to identify the data (block data) that is the target of backup processing, and to perform backup processing efficiently. Furthermore, the present disclosure can utilize space management in units of blocks in a logical block addressing space (LBA space). (Note that, in a modified example, addresses other than in units of blocks may be set in a volume. For such a volume, first management information suitable for the address management may be provided.)
[0019] 3.1.4. Backup Settings Screen The backup process can be set by a user or the like operating a backup setting screen displayed on a terminal 380. In the following, an example will be described in which the transfer source of the backup process is the on-premise storage device 310. The following description can also be applied to a case in which the transfer source of the backup process is a logical volume 1070 or 2070 in a remote data center 302 described later. 6 is a diagram showing a backup setting screen 600 displayed on the terminal 380 for the on-premise storage device 310 to perform backup processing through the backup / restore interface 410. The backup setting screen 600 is operated through the terminal 380. Note that information to be displayed on the backup setting screen 600 may be prepared by the terminal 380, or may be prepared by a device other than the terminal 380 (for example, the data center 301 or the storage operation management service 330 in the data center 302), or may be prepared in cooperation with a plurality of devices. The backup setting screen 600 includes a logical volume selection area 601, a backup data store selection area 602, and a backup schedule setting area 603. The logical volume selection area 601 is an area for selecting the logical volume 470 to be backed up. In the example of FIG. 6, the logical volume 470 of Volume B (16 terabytes) indicated by logical volume number 7F is selected. The backup data store selection area 602 is configured by, for example, a drop-down box (pull-down menu), and is an area for selecting the backup data store 340 to be the transfer destination of the backup process of the logical volume 470. In the backup data store selection area 602, the backup data store 340 already registered using another backup store registration screen (not shown) is displayed so that it can be selected. In the example of FIG. 6, the backup data store 340 (with account name) indicated by "ABC Cloud (Account 1940032)" is selected. (Note that the account may be, for example, one given to a user, etc.) The backup schedule setting area 603 is an area for setting a backup schedule. In the backup schedule setting area 603, for example, a One shot designation button 631 for setting the execution of a one-time backup process and a Periodically designation button 632 for setting the execution of a periodic backup process are displayed. When the user etc. selects the One shot designation button 631, the user etc. can further designate whether to execute immediately (Now) or the execution start time. When the user etc. selects the Periodically designation button 632, the user etc. can designate a period (e.g., daily, weekly, monthly) that is a unit of repetition. When the user etc. designates the date and time (Daily), the user etc. can designate the execution start time, the execution interval time, the maximum number of executions, etc. For example, the user etc. may be allowed to designate only one of the execution interval time and the maximum number of executions.When the maximum number of executions is specified, the on-premise storage device 310 may determine the execution interval time of the backup process so that the backup process of the maximum number of executions is executed at nearly equal intervals within a period (daily, weekly, monthly) that is a specified unit. In addition, in the example of FIG. 6, an example in which a date and time (Daily) is specified is shown, but when a weekly or monthly is specified, a setting screen suitable for setting the weekly or monthly backup process may be displayed on the backup setting screen 600. In the example of FIG. 6, periodic execution is selected as the schedule for the backup process, and it is specified that the backup process is performed daily and at 30-minute intervals from 0:00 every day. The OK button 605 is a button for receiving an instruction to register the schedule of the backup process set on the backup setting screen 600. When the OK button 605 is pressed, the schedule of the backup process that has been set is registered in the scheduler of the device management subsystem 460, and information regarding the schedule is also sent to the storage operation management service 330. (Note that the scheduler may be constructed, for example, by the device management subsystem 460 executing a scheduler program.) When the transfer source in the backup process is the logical volume 470 in the on-premise storage device 310, the processing entity of the backup process may be any of the device management subsystem 460, the I / O control subsystem 450, or the backup / restore interface 410. When the transfer source in the backup process is the logical volume 1070 or 2070 in the storage volume service 320, the processing entity of the backup process may be the storage operations management service 330.
[0020] 3.1.5. Generational backup process When a volume (logical volume) is backed up using a method other than the method of acquiring a snapshot of all data in the volume, generation management is performed in the backup and restore processes. Specifically, the backup process is a differential backup process in which only data written to the volume that is the transfer source in the backup process after the previous backup process is transferred to the backup data store 340, which is the second storage unit 102. The restore process is a process in which restore processes of all generations prior to the generation indicating the time point to be restored by the restore process are executed in order from the oldest generation. 7A, 7B, and 7C are schematic diagrams showing how block data groups 721, 722, and 723 to be backed up are extracted as differences when a backup process is performed. In the examples of FIG. 7A, 7B, and 7C, the symbols "A", "B", and "C" are used for the sake of explanation, but in reality, the presence or absence of updates to these data is managed using the difference management bitmap 500 described above. In FIG. 7A, 7B, and 7C, the description of the difference management bitmap 500 is omitted, and instead, blocks corresponding to ON are shown in inverted black for the sake of convenience. FIG. 7A shows the state of the first backup process. Comparing the state 710 of the data stored in the initial logical volume with the state 711 of the data stored in the logical volume at the time of the current (first generation) backup process, it can be seen that blocks indicated by "A", "B", and "C" have been newly written. Therefore, "A", "B", and "C" are extracted as the block data group 721. FIG. 7B shows the state of the second (second generation) backup process. When comparing the state 711 of the stored data in the logical volume at the time of the previous (first generation) backup with the stored data 712 in the logical volume at the time of the current (second generation) backup, it is found that the block indicated by "A'" has been updated. Therefore, block "A'" is extracted as part of the block data group 722. FIG. 7C shows the state of the third (third generation) backup process. When comparing the stored data 712 in the logical volume at the time of the previous (second generation) backup with the stored data 713 in the logical volume at the time of the current (third generation) backup, it is found that the blocks indicated by "B'" and "C'" have been updated. Therefore, blocks "B'" and "C'" are extracted as part of the block data group 723. As is clear from the above, since only the update difference is backed up for each generation, when restoring, it is necessary to overlap with the backup data of the previous generation (parent generation). For example, in order to restore the logical volume to the state of 712 in FIG. 7B, "ABC" must be restored using the block data group 721 of the first generation, and then "A'" must be restored using the block data group 722 of the second generation ("A" is overwritten with "A'"). For this reason, it is necessary to note that the restore process described later may handle backup data of multiple generations. For the sake of efficiency of the restore process, only "BC" may be restored from the block data group 721, and "A'" may be restored from the block data group 722.
[0021] 3.1.6 Internal structure of backup data store (second storage unit) The backup data store 340 associated with the second storage unit 102 may be of the object storage format. The backup data store of the object storage format can provide a wide bandwidth as a transfer destination in the backup process or a transfer source in the restore process. The internal configuration of the backup data store 340 will be described below. 8 shows the state in which the backup data 121 is stored in the backup data store 340. The backup data store 340 in this embodiment is, for example, an object storage type store located on the public cloud side. For the backup data store 340, the presence or absence of access rights can be set for each combination of an access request source and an access destination (for example, a bucket) (in the backup data store 340). In the example of FIG. 8, the backup data store 340 may include bucket 801, bucket 802, and bucket 803 in the object storage format. Each bucket corresponds to a generation of the backup process. Although not shown, another bucket due to a backup process of another logical volume may also be included in the backup data store 340. Bucket 801 stores the first generation backup data (Vol#7F Gen1) of the logical volume indicated by logical volume number 7F, and is identified by bucket name vsp56342-7f-001. Bucket 802 stores the second generation backup data (Vol#7F Gen2) of the logical volume indicated by logical volume number 7F, and is identified by bucket name vsp56342-7f-002. Bucket 803 stores the third generation backup data (Vol#7F Gen3) of the logical volume indicated by logical volume number 7F, and is identified by bucket name vsp56342-7f-003. The bucket 801 stores a differential management bitmap (second management information) 811, a block data group 812, and a backup catalog 810 as object files. Here, the differential management bitmap (second management information) 811 and the block data group 812 are divided into management areas 571 or 112 (A, B, C, etc.) included in one logical volume. Each object file is assigned an object name with a consecutive number for each type, and is stored so that the relationship can be determined. For example, the differential management bitmaps 811A, 811B, and 811C are assigned "bitmap-7f-001.000", "bitmap-7f-001.001", and "bitmap-7f-001.002", respectively, and the block data groups 812A, 812B, and 813C are assigned "block-7f-001.000", "block-7f-001.001", and "block-7f-001.002", respectively. The difference management bitmaps (second management information) 811A, 811B, and 811C correspond to the difference management bitmap (first management information) 500 shown in FIG. 5, and are information indicating the storage location of difference data (write data, block data) in the logical volume.The block data groups 812A, 812B, and 812C correspond to the block data group 721 shown in FIG. 7A, and are a collection of a plurality of block data extracted based on the differential management bitmaps 811A, 811B, and 811C (500A, 500B, and 500C). In the example of FIG. 8, the block data groups 812A, 812B, and 813C are illustrated as single files, but may be divided into a plurality of object files depending on the size. The backup catalog 810 describes summary information of the backup process, and details will be described later in FIG. 9. Similarly, the bucket 802 stores the differential management bitmaps 821A, 821B, and 821C, the block data groups 822A, 822B, and 822C, and the backup catalog 820 as object files. The bucket 803 is similar, so a description thereof will be omitted. In this embodiment, the information on the backup process is stored in a different bucket for each generation, but the information on the backup process for multiple generations may be stored in one bucket. The object names of the object files stored in the bucket include information on the generation. Therefore, there is no problem even if one bucket contains the information on the backup process for multiple generations. Each object file in the backup data store 340 is accessed using an object key consisting of the object name, bucket name, account name, URL address of the backup data store, etc. 9A and 9B explain the information held by the backup catalogs stored in each bucket of the backup data store 340. Fig. 9A shows the internal configuration of the first generation backup catalog 810 contained in bucket 801 of Fig. 8. The backup catalog 810 has an object name of "catalog-7f-001-0.dat", and holds the following information: backup source device product number 910, transfer source volume number 911 for backup processing, volume size 912, volume name (nickname) 913, backup generation number 914, backup acquisition time 915, catalog name of parent generation 916, and number of files in differential management bitmap 917 (in the drawings, "number of files in differential management bitmap" is abbreviated as "number of differential management bitmaps" or "number of bitmaps"). In the example of Figure 9A, the device product number is "VSP56432", the source volume number for the backup process is "0x7F", the volume size is "16.0TB" (16.0 terabytes), the volume name (nickname) is "Volume B", the backup generation number is "01" (first generation), and the backup acquisition time is "2021-04-28 0:00". Also, since this is the first generation, there is no parent generation. Therefore, the catalog name of the parent catalog is blank "-". The number of files in the differential management bitmap is "512". In other words, one logical volume is composed of 512 management areas, which means that there are 512 object files in the differential management bitmap with object names from "bitmap-7f-001.000" to "bitmap-7f-001.511". FIG. 9B shows the configuration of the second generation backup catalog 820 included in the bucket 802 in FIG. 7. The backup catalog 820 has the same configuration as the backup catalog 810. The object name of the backup catalog 820 is "catalog-7f-002-0.dat". In the example of FIG. 9B, the device product number is "VSP56432", the volume number of the transfer source in the backup process is "0x7F", the volume size is "16.0TB", the volume name (nickname) is "Volume B", the backup generation number is "02" (second generation), and the backup acquisition time is "2021-04-28 3:00". The catalog name of the parent generation is the object name "catalog-7f-001-0.dat" under the bucket name "vsp56342-7f-001". This points to the backup catalog 810 (FIG. 9A). In other words, when performing restore processing for this generation, it is necessary to first perform restore processing of the first generation backup data indicated by the backup catalog 810. The number of files in the differential management bitmap is "512". As in Fig. 9A, the logical volume is made up of 512 management areas, which means that there are 512 object files in the differential management bitmap, with object names from "bitmap-7f-002.000" to "bitmap-7f-002.511". In this way, the present disclosure provides second management information (e.g., a differential management bitmap) for each management area within a backed up volume, so that the data to be restored can be placed in an appropriate location in the volume to which the data is transferred in the restore process. Furthermore, the present disclosure can fully utilize the broadband capabilities of object stores in the object storage format described above.
[0022] 3.1.7. Logical configuration of storage volume service (first storage unit) Fig. 10 shows a logical configuration of the storage volume service 320 associated with the first storage unit 101 in the embodiment 1. The logical configuration shown in Fig. 10 is constructed by hardware resources (for example, hardware resources included in the architecture shown in Fig. 2, which may include physical drives that are storage devices or recording media for constructing virtualized drives) and software resources provided in the data center 302 on the cloud side. The storage volume service 320 is composed of multiple storage controller virtual machines 1011, 1012...101n (hereinafter, "virtual machine" will be abbreviated as "VM", as in many places in the drawings), multiple virtualized drives 1021, 1022...102n, 1031, 1032...103n (in FIG. 10, "virtualized drive" will be abbreviated as "drive"), an access control layer 1040, logical volumes 1070 (1070-1, 1070-2, 1070-3...), and an access endpoint 1050. A plurality of storage controller VMs 1011, 1012...101n operate to ensure fault tolerance (for example, configure RAID) by using a plurality of virtualized drives 1021, 1022...102n, 1031, 1032...103n in cooperation with each other, and provide logical volumes 1070 (1070-1, 1070-2, 1070-3...). Similarly to the on-premise storage device 310, the storage volume service 320 (for example, storage controller VM) has a function of managing which LBA data is written to, and has a differential management bitmap 500 for each LBA area (management area 571 or 112) as shown in FIG. 5, for example. A group of logical volumes 1070 (1070-1, 1070-2, 1070-3...) is a group of storage volumes provided by the storage volume service 320. The storage operation management service 330 shown in FIG. 3 creates a logical volume 1070 with an arbitrary volume size. In the example of FIG. 10, the logical volumes 1070 (1070-1, 1070-2, 1070-3, . . . ) are iSCSI block volumes accessible via an IP network.The access control layer 1040 manages the access rights to the logical volume 1070, and operates to pass only the access to the authorized computer resource by using a combination of the host group, the IP address (owned by the access request source), the port, the protocol, and the like. The access endpoint 1050 is an end point (endpoint) for other computer resources to access the logical volume 1070 provided by the storage volume service 320. The example of FIG. 10 shows the endpoint information of the logical volume 1070-1. In the example of FIG. 10, in order to access the logical volume 1070-1, the other computer resource uses "10.0.2.1" as the IP address (as the access destination), "iqn.yyyy-mm.com.example" as the iSCSI node name, and "logical-volume-230a" as the iSCSI target name. In the above description, the logical volume 1070 is an iSCSI volume provided by a plurality of storage controller VMs, but it may be a standard storage volume service provided by a cloud service vendor.
[0023] 3.1.8. Computer resources configured for restore processing The cloud restore system 350 according to the first embodiment of the present disclosure constructs (starts) a computer resource 390 as a group of related resources. The computer resource 390 performs restoration processing. Fig. 11 is a diagram showing the relationship between the cloud restore system 350 in the first embodiment and the computer resources 390 that the cloud restore system 350 constructs (launches, generates) during processing, the storage volume service 320 (first storage unit 101), and the backup data store 340 (second storage unit 102). As shown in Fig. 3, these are connected to each other via an internal network 360 and configured to be able to communicate with each other (not shown). Note that multiple computer resources shown in the computer resources 390 in Fig. 11 may be associated with one hardware resource for realizing the computer resources 390. The cloud restore system 350 includes an information processing device 201 as shown in FIG. 2, and also includes a storage device 202 or a non-volatile recording medium 203. The storage device 202 or the non-volatile recording medium 203 stores a restore operation control program 1151 (in the drawings, "program" is abbreviated as "PG"), a restore plan generation program 1152, a volume service setting program 1153, a virtual machine (VM) OS image 1154 (in the drawings, "image" is abbreviated as "IM"), an instance management program 1155, and a queue management program 1156. The information processing device 201 executes these programs or images to realize the processing performed by the cloud restore system 350. The restore operation control program 1151 is a main program for instructing the entire processing up to the completion of the restore processing when a restore instruction is received from the terminal 380. The restore plan generation program 1152 is a program for determining whether or not the restore (restoration) of another generation (parent generation) is necessary when restoring (restoring) the target generation, and for constructing an execution procedure. The volume service setting program 1153 is a program for acquiring information on the logical volume 1070 and the access control layer 1040 included in the storage volume service 320, and setting the VM instance 1191 so that it can access the logical volume 1070. The VM instance 1191 will be described later. The VMOS image 1154 is a file that stores an OS for operating the VM instance 1191 and a program that operates on the OS. The instance management program 1155 is a program for controlling the start and end of the VM instance 1191. The queue management program 1156 is a program for controlling the settings of the queue service 1194 and the event monitoring unit 1195. The computer resources 390, which are a group of related resources, may include the queue service 1194 (1194A, 1194B, 1194C), the VM instance 1191 (1191A, 1191B, 1191C), and the event monitoring unit 1195, which are dynamically created by executing each program or image of the cloud restore system 350.The queue service 1194 (1194A, 1194B, 1194C) is a computer resource used to queue an instruction from the cloud restore system 350 to the VM instance 1191. Each queue service 1194 has identification information for receiving operations from other computer resources. The VM instance 1191 is a server computer resource executed using the VMOS image 1154. When each VM instance 1191 is started, the identification information of the queue service 1194 in charge is passed as an argument. After the OS of the VM is started, the VM instance 1191 executes a program included in the VMOS image 1154 to build (start) a data transfer process 1193 (1193A, 1193B, 1193C). The data transfer process 1193 monitors the presence or absence of a request for, for example, a restore process in the queue service 1194 in charge based on the identification information passed as an argument. The event monitor 1195 monitors, for example, the queue length of restore processing requests accumulated in the queue service 1194, and notifies the cloud restore system 350 when the queue length exceeds / falls below a specified threshold. Note that, although the cloud restore system 350 is illustrated as an independent system in this embodiment, it may be configured as a part of the storage operation management service 330.
[0024] 3.1.9.Restore setting screen The restore process can be set by the user or the like operating a restore setting screen displayed on the terminal 380. In the following, an example will be described in which the transfer destination of the restore process is the logical volume 1070 in the storage volume service 320 (first storage unit 101). As will be apparent from the restore setting screen described later, it is also possible to set the transfer destination of the restore process to the logical volume 470 in the on-premise storage device 310. 12 shows a restore setting screen 1200. The restore setting screen 1200 is operated via the terminal 380. As a result, the storage operation management service 330 instructs the cloud restore system 350 (or the on-premise storage device 310) to perform restore processing. Note that the information to be displayed on the restore setting screen 1200 may be prepared by the terminal 380, may be prepared by a device other than the terminal 380 (for example, the data center 301 or the storage operation management service 330 in the data center 302), or may be prepared in cooperation with a plurality of devices. The restore setting screen 1200 is composed of a backup data store selection area 1201, a volume selection area 1202, a backup generation selection area 1203, a restore destination selection area 1204, a restore execution button 1205, and a cancel button 1206. The backup data store selection area 1201 is composed of, for example, a drop-down box (pull-down menu), and is used to select the backup data store 340 that is the transfer source in the restore process. In the example of FIG. 12, "ABC Cloud (Account 1940032)" is selected (along with the account name). The volume selection area 1202 is used to select the logical volume with which the backup data to be transferred in the restore process was associated before the backup process. In the example of FIG. 12, the logical volume (logical volume on which the backup process was performed) indicated by logical volume number "7F" and logical volume name (nickname) "Volume B" (16 terabytes (16TB)) included in the device with device number "VSP56342" is selected as the target. The backup generation selection area 1203 is for selecting the state of the logical volume selected in the volume selection area 1202 at which generation's backup acquisition time is to be restored (which range of generations of backup data is to be restored). In the example of FIG. 12, "Backup02" (second generation) acquired at "April 28, 2021, 3:00" is selected. In this selection, the first and second generation backup data are restored to the logical volume by the restore process. The restore destination selection area 1204 is for selecting the transfer destination in the restore process. The restore destination selection area 1204 shows an original logical volume selection 1241, which is an option for selecting the original logical volume (Original Volume) selected in the volume selection area 1202 as the transfer destination in the restore process, and a new logical volume selection 1242, which is an option for selecting a new logical volume (New Volume) as the transfer destination in the restore process.When the user or the like selects the new logical volume selection 1242, a volume selection area 1243 is used to select which storage system is used to create the logical volume. In the example of FIG. 12, it is selected to set a new logical volume as the transfer destination in the restore process, and a new logical volume for storing the transfer data in the restore process is created in the cloud volume service (for example, a new logical volume 1070 is created in the storage volume service 320 in the data center 302 and set as the transfer destination in the restore process). The restore execution button 1205 is a button that is selected when executing based on the contents set in the restore setting screen 1200. When the restore execution button 1205 is selected, the setting contents are sent to the storage operation management service 330 (or the on-premise storage device 310), and the restore process is started. The cancel button 1206 is a button that is selected when discarding and canceling the contents set in the restore setting screen 1200. In addition, when the transfer destination in the restore process is the on-premise storage device 310, the processing entity of the restore process can be any of the device management subsystem 460, the I / O control subsystem 450, or the backup / restore interface 410.
[0025] 3-2. Processing of the first embodiment of the present disclosure (restoration processing) Based on the system configuration of the first embodiment described above, a series of processes performed for restore processing from the backup data store 340 associated with the second memory unit 102 to the logical volume 1070 in the storage volume service 320 associated with the first memory unit 101 will be described below.
[0026] 3.2.1. Until you instruct the cloud restore system to execute the restore process The following will first explain the process up to when the storage operations management service 330, having received the settings for the restore process input by a user or the like using the restore settings screen 1200, instructs the cloud restore system 350 to execute the restore process. FIG. 13 shows a flowchart illustrating the process up to when the storage operation management service 330 instructs the cloud restore system 350 to perform restore processing when the cloud-side storage volume service 320 is selected as the transfer destination for the restore processing using the restore setting screen 1200 of FIG. 12. In step 1301, when the storage operation management service 330 receives the information specified on the restore setting screen 1200, it searches the summary information received at the completion of the backup process and acquires the object key of the backup catalog corresponding to the backup data to be restored. Next, in step 1302, the storage operation management service 330 accesses the storage volume service 320 and creates a logical volume 1070 that is the transfer destination in the restore process. Then, in step 1303, the storage operation management service 330 acquires information on the access endpoint 1050 required to access the logical volume 1070. After that, in step 1304, the storage operation management service 330 grants the cloud restore system 350 the right to access the backup data store 340 (indicated as "ABC Cloud (Account 1940032)" in the example of FIG. 12) that is the transfer source in the restore process. Finally, in step 1305, the storage operation management service 330 uses the object key of the backup catalog previously acquired and information on the access endpoint 1050 of the logical volume 1070 to instruct the cloud restore system 350 to execute the restore process.
[0027] 3.2.2 Processing of the cloud restore system that has been instructed to execute the restore process The cloud restore system 350, which has been instructed by the storage operation management service 330 to execute a restore process, determines the number of temporary computer resources (e.g., VM instances 1191) to be constructed (activated) for the restore process, and constructs (activates) the determined number of temporary computer resources (VM instances 1191). The cloud restore system 350 also mounts one common logical volume 1070, which is the transfer destination in the restore process, for each of the activated temporary computer resources (VM instances 1191). The cloud restore system 350 also assigns backup data for each combination of generation and management area for backup data to be the target of the restore process to each of the activated temporary computer resources (VM instances 1191). The above process will be explained step by step below. FIG. 14 shows a flowchart of the process performed by the cloud restore system 350 when an instruction to execute a restore process is received from the storage operation management service 330. First, in step 1401, the cloud restore system 350 uses the object key received at the time of the instruction to obtain a backup catalog from the backup data store 340. Then, in step 1402, the cloud restore system 350 executes the restore plan generation program 1152 to check the parent-child relationship of the backup data and create a list (restore plan) of backup data for which restore processing should be performed.
[0028] 3.2.2.1. Create a restoration plan FIG. 15 shows how the cloud restore system 350 executes the restore plan generation program 1152 to build a restore plan (an ordered list of backup catalogs for which restore processing is to be performed). In step 1501, the cloud restore system 350 executing the restore plan generation program 1152 acquires a backup catalog of the backup data to be restored, and adds the backup catalog to the top of the temporary list. Then, in step 1502, the cloud restore system 350 executing the restore plan generation program 1152 analyzes the backup catalog and checks whether a parent generation backup catalog exists. If a parent generation backup catalog exists (Yes in step 1502), that is, if differential backup data of the previous generation required for restore processing exists, in step 1503, the cloud restore system 350 executing the restore plan generation program 1152 acquires the parent generation backup catalog from the backup data store 340. In step 1501 again, the parent generation backup catalog is added in order to the temporary list. Thereafter, the process is similarly repeated recursively. On the other hand, if there are no more parent generation backup catalogs in the acquired backup catalog (No in step 1502), the cloud restore system 350 executing the restore plan generation program 1152 in step 1504 adds the backup catalogs stored in the temporary list to the list of restore plans in reverse order (LIFO) from the end of the temporary list. In other words, the restore plan is configured to be arranged in order from the oldest generation for which restore processing should be performed. For example, when restore processing is performed to obtain the state at the time of the second generation backup processing, the restore plan includes the first generation backup catalog 810 and the second generation backup catalog 820 in this order. Then, the cloud restore system 350 executing the restore plan generation program 1152 in step 1505 notifies the restore plan within the cloud restore system 350. The explanation of FIG. 15 ends here and we return to the explanation of FIG.
[0029] 3.2.2.2. Determining the number of computer resources to be configured (started) for restore processing After step 1402 in FIG. 14, in step 1404, the setting change unit 135 constructed by the cloud restore system 350 checks whether the logical volume 1070 that is the transfer destination in the restore process is multi-attachable. If multi-attachable (Yes in step 1404), in step 1405, the setting change unit 135 enables multi-attach for the logical volume 1070 that is the transfer destination in the restore process. The setting for enabling multi-attach may be performed, for example, by enabling permission for multi-attach or by changing the disk type to one that is multi-attachable. Note that when the logical volume 1070 cannot be made multi-attachable (No in step 1404), it may be impossible to change the logical volume 1070 to multi-attachable due to specification constraints or contractual constraints held by the user or the like. Thereafter, in step 1406, the computer resource number determination unit 132 constructed by the cloud restore system 350 checks the number of connectable hosts, which is the number of computer resources (e.g., temporary computer resources, VM instances) capable of mounting one logical volume 1070 that is the transfer destination in the restore process. Note that various factors may be assumed to determine the number of connectable hosts. The number of connectable hosts may be based on, for example, the design specifications of the storage volume service 320, the design specifications of the entire data center 302, or contractual constraints of users who use the services provided by the data center 302. Next, in step 1407, the computer resource count determination unit 132 compares the number of connectable hosts confirmed in step 1406 with the number of files in the differential management bitmap described in the backup catalogue targeted for restore processing. Here, the number of files in the differential management bitmap refers to the number of differential management bitmaps corresponding to one generation of backup data among the backup data targeted for restore processing. In other words, the number of files in the differential management bitmap refers to the number of management areas 571 (112) included in one logical volume that is the transfer source in the backup processing when backup processing was previously performed on the backup data targeted for restore processing. If the number of files in the differential management bitmap is greater than the number of connectable hosts (Yes in step 1407), in step 1409 the computer resource number determination unit 132 sets the number of computer resources to be constructed (activated) for the subsequent restore processing to the same number as the number of connectable hosts confirmed in step 1406. On the other hand, if the number of files in the differential management bitmap is equal to or less than the number of connectable hosts (No in step 1407), the computer resource number determination unit 132 sets the number of computer resources to be constructed (activated) for the restore processing to the same number as the number of files in the differential management bitmap. Also, if the logical volume 1070 to be the transfer destination of the restore processing is not multi-attachable (No in step 1404), in step 1408 the computer resource number determination unit 132 sets the number of computer resources to be constructed (activated) for the restore processing to 1. Although not shown in the figures, if the number of computer resources to be set in either step 1409 or step 1410 in the above-described manner conflicts with the specifications of the cloud system (for example, the design specifications of the storage volume service 320, the design specifications of the entire data center 302, or contractual constraints of users who use the services provided by the data center 302), the computer resource number determination unit 132 re-determines the number of computer resources within a range that does not conflict. A computer resource number determination step may be configured by some or all of steps 1406, 1407, 1408, 1409, and 1410. In this way, the present disclosure can appropriately determine the number of computer resources to be constructed (started) by considering both the maximum number of hosts related to the volume and the number of management areas included in the volume. Here, the present disclosure determines the number of management areas included in the volume based on the number of second management information (e.g., differential management bitmaps) associated with the management areas, so that the number of management areas included in the volume can be appropriately determined.
[0030] 3.2.2.3. Construction (startup) and mounting (multi-attach) settings of computer resources After determining the number of computer resources to be constructed (activated) for the restore process, in step 1411, the computer resource startup unit 133 constructed by the cloud restore system 350 creates queue services 1194 in the number corresponding to the number of computer resources to be constructed (activated). In step 1412, the computer resource startup unit 133 uses the identification information of each queue service 1194 and the VMOS image 1154 to construct (activate) VM instances 1191 corresponding to the number of computer resources described above, and links the VM instances 1191 to the queue services 1194. Thereafter, in step 1413, the computer resource startup unit 133 executes the volume service setting program 1153 to set access rights in the access control layer 1040 so that each VM instance 1191 can access a common logical volume 1070 that is the transfer destination in the restore process. In addition, the computer resource startup unit 133 performs processing to grant the VM instance 1191 access rights to the backup data store 340. Then, in step 1414, the computer resource startup unit 133 executes the instance management program 1155 to set a connection path 1192 to the access endpoint 1050 corresponding to the logical volume 1070 that is the transfer destination in the restore process (the setting of the connection path 1192 enables the VM instance 1191 to access the logical volume 1070), and mounts one common logical volume 1070 that is the transfer destination in the restore process for each VM instance 1191. After that, in step 1415, the computer resource startup unit 133 sets an event monitor 1195 that monitors the queue length. A computer resource startup step may be constructed by some or all of steps 1411, 1412, 1413, 1414, and 1415.
[0031] 3.2.2.4. Allocation of processing to each computer resource After the cloud restore system 350 constructs (starts) the computer resources 390, in step 1416 the area allocating unit 134 constructed by the cloud restore system 350 references the restore plan created in step 1402 and the processing of Fig. 15 to acquire the backup catalog to be processed first. Then, in step 1417, the area allocating unit 134 acquires information on the number of files in the differential management bitmap (917 in Fig. 9A or Fig. 9B) from the backup catalog, and generates the object name of the object file of the differential management bitmap (any of 811, 821, or 831 in Fig. 8) and the object name of the block data group (any of 812, 822, or 832 in Fig. 8). For example, if the volume number of the logical volume that was the transfer source in the past backup process is 7f, the generation of the backup process is the first generation, and the number of files in the differential management bitmap is 512, the area allocating unit 134 generates "bitmap-7f-001.000" to "bitmap-7f-001.511" which are the object names of the differential management bitmap for each management area, and "block-7f-001.000" to "block-7f-001.511" which are the object names of the block data group for each management area. Here, the "001" part corresponds to the backup generation number 914, and the "000" to "511" parts correspond to the numbers of the management area 571 (112). Then, the area allocating unit 134 configures an object key from the object name, the destination bucket name, the account name, the URL address of the access destination backup data store, and the like. In step 1418, the area allocating unit 134 pairs the object key of the differential management bitmap with the object key of the corresponding block data group, and queues them in order to the queue service 1194 (1194A, 1194B, 1194C, . . . ) as processing targets.If all the remaining object key pairs have not been queued even though one object key pair has been queued in each of the queue services 1194 (No in step 1419) (for example, when the number of queue services 1194 is three and there are 512 object key pairs (one logical volume has 512 management areas)), the process returns to step 1418, and the area allocating unit 134 repeats the process to queue the remaining object key pairs. If all the remaining object key pairs have been queued by queuing one object key pair in each of the queue services 1194 (Yes in step 1419), in step 1420, the area allocating unit 134 refers to the restore plan and checks whether there is a backup catalog to be processed next. If there is a backup catalog to be processed next (Yes in step 1420), in step 1421, the area allocating unit 134 resets the starting point so that the destination for queuing the object key pairs is the first queue service 1194A. Returning to step 1416, the area allocating unit 134 acquires the next backup catalog to be processed and repeats the process. The reason for resetting the start point in step 1421 is to ensure the correct order of the restore processes of different generations related to the same management area by having the same VM instance 1191 process the restore processes of different generations related to the same LBA management area, and to prevent the generation of the restore process from being mixed up. When the queuing process corresponding to all the backup catalogs included in the restore plan is completed (No in step 1420), the area allocating unit 134 completes the queuing process of the object key pair for the restore process. A part or all of steps 1416, 1417, 1418, 1419, 1420, and 1421 may constitute an area allocation step.
[0032] 3.2.2.5. Allocation of processing to computer resources in restore processing involving multiple generations FIG. 16 is for explaining step 1421 in FIG. 14 in detail, and shows an example of allocation of processing to computer resources (VM instance 1191) in restore processing including multiple generations. The example in FIG. 16 is for performing restore processing from the backup data store 340 to one logical volume 1070 of the storage volume service 320. The logical volume 1070 (volume 111) of the transfer destination of the restore processing includes 512 management areas 571 (112). In FIG. 16, the 512 management areas 571 (112) are represented as "area 1" to "area 512". The example in FIG. 16 is intended to restore (restore) the state at the time of the backup processing of the second generation. If differential backup processing has been performed for each generation, in the restore processing, it is necessary to reflect the backup data of the first generation (if the backup data of the first generation exists) in the logical volume 1070 and then reflect the backup data of the second generation (if the backup data of the second generation exists) in the logical volume 1070 for each management area 571 (112). In the example of FIG. 16, three VM instances 1191 are constructed (activated) to perform the restore process. That is, FIG. 16 shows a case in which, in step 1407 of FIG. 14, it is determined that the number of differential management bitmaps, 512, is greater than the number of connectable hosts, 3, and therefore, in step 1409, it is determined that the number of computer resources (VM instances 1191) to be constructed (activated) is the number of connectable hosts, 3. In the example of FIG. 16, for example, a box with "generation 1 area 1" written therein indicates an object key pair (an object key of the differential management bitmap 811A and an object key of the block data group 812A) corresponding to the first generation and the first management area 571A (112A). The VM instance 1191 that receives this object key pair is assigned a portion of the restore process corresponding to the combination of the generation and management area corresponding to the object key pair. In the example of FIG. 16, the object key pair of "generation 1 area 1" is queued in the queue service 1194A and assigned to the VM instance 1191A. Then, the object key pairs corresponding to the management areas of the first generation are sequentially assigned to the three VM instances 1191. As in the example of FIG. 16, a cyclical assignment may be performed. In the case of a cyclical assignment, the object key pair of "generation 1 area 512" is assigned to the VM instance 1191B. The area allocating unit 134 next assigns the object key pair of "generation 2 area 1". In this case, the object key pair of "generation 2 area 1" is assigned to the VM instance 1191A to which the object key pair of "generation 1 area 1" is assigned, not to the VM instance 1191C which is the next position in the cyclical assignment. In other words, even in the case of a cyclical assignment, the area allocating unit 134 resets a pointer indicating the assignment destination (queue destination in the queue service 1194) of the object key pair at the time of switching the generation to which the assignment process is performed. In this way, pairs of object keys of different generations in the same management area 571 (112) are assigned to the same VM instance 1191. Note that the assignment is not limited to cyclical assignment, and it is sufficient that the restore process is performed in the correct order for backup data of different generations in the same management area 571 (112). When the VM instance 1191 is assigned parts of restore processes for multiple generations related to the same management area 571 (112), it executes each part of the restore process in the order that results in a normal process result. In this way, the present disclosure makes it possible to properly perform restore processing when multiple generations of backup data are to be sequentially subjected to restore processing. Note that the area allocating unit 134 may queue an object key pair for the combination in the queue service 1194 only when the differential management bitmaps 811, 821, 831 (second management information) corresponding to the combination of a generation and a management area 571 (112) indicate that at least one data in the management area 571 (112) is backed up in the backup data store 340 (second storage unit 102). By controlling queuing in this manner, the area allocating unit 134 can allocate the restore process for the combination to the VM instance 1191 (computer resource 131) only for the combination of a generation and a management area 571 (112) in which data to be restored exists, thereby making it possible to improve the efficiency of the restore process.
[0033] 3.2.2.6. Processing performed by VM instances during restore processing The VM instance 1191 executes the portion of the restore process that corresponds to the combination of the generation and management area 571 (112) that corresponds to the pair of object keys received from the corresponding queue service 1194. FIG. 17 shows a flowchart of the processing of the VM instance 1191 during the restore processing. In step 1701, the VM instance 1191 reads and starts the VMOS image 1154, thereby starting the data transfer process 1193 corresponding to the program included in the VMOS image 1154. Note that in step 1413 and step 1414 of FIG. 14, the VM instance 1191 is set to be able to access the backup data store 340 and the logical volume 1070. In step 1702, the data transfer process 1193 running on the VM instance 1191 periodically checks the queue service 1194 corresponding to the queue service identification information passed as an argument at the time of starting. If the object key pair (processing target) exists in the queue service 1194 (Yes in step 1703), in step 1704, the data transfer process 1193 acquires the object key pair from the queue service 1194. Then, in step 1705, the data transfer process 1193 acquires the object file of the block data group corresponding to the differential management bitmap from the backup data store 340 based on the acquired object key pair. Next, in step 1706, the data transfer process 1193 sequentially scans the bits of the differential management bitmap to determine which LBA of the logical volume 1070 needs to be written to. If the bit is ON (Yes in step 1707), this means that there is data to be restored to the LBA corresponding to the bit, so in step 1708, the data transfer process 1193 obtains the first block data from the block data group and writes it to the logical volume 1070. Then, in step 1709, the data transfer process 1193 moves the reference to the next block data. Next, in step 1710, the data transfer process 1193 advances the value of the reference LBA of the logical volume 1070 and the position of the reference bit in the differential management bitmap by one.On the other hand, if the bit of the differential management bitmap acquired (scanned) in step 1706 is OFF (No in step 1707), this means that there is no data to be restored to the LBA corresponding to that bit, so in step 1710 the data transfer process 1193 does nothing and advances the value of the reference LBA of the logical volume 1070 and the position of the reference bit in the differential management bitmap by one. Then, in step 1711, the data transfer process 1193 determines whether or not all the bits of the differential management bitmap have been referenced (acquired, scanned). If there are still bits remaining (No in step 1711), the data transfer process 1193 repeats the processing from step 1706 to step 1710. On the other hand, if all bits have been referenced (obtained, scanned) (Yes in step 1711), then processing corresponding to the object key pair (processing target) targeted in the series of steps from step 1704 to 1711 has been completed, and therefore in step 1713 the data transfer process 1193 removes (dequeues) the object key pair (processing target) from the queue service 1194. After step 1713, the data transfer process 1193 returns control to step 1702, thereby returning to the process of periodically checking whether or not there are any unprocessed object key pairs in the queue service 1194.
[0034] 3.2.2.7. Releasing VM instance resources during restore process When there are multiple VM instances 1191 constructed (activated) to perform restore processing, the cloud restore system 350 and computing resources 390 can sequentially release the VM instances 1191 starting from the ones whose assigned processing has been completed, without waiting for the entire restore processing to be completed. FIG. 18 shows a flowchart of the processing of the cloud restore system 350 when the event monitor 1195 notifies the queue service 1194 that the queue length (the number of object key pairs) has reached zero. In step 1801, when the cloud restore system 350 receives a notification from the event monitor 1195 that the queue length has become zero, it acquires the identification information of the target queue service 1194. In step 1802, the cloud restore system 350 checks whether there is a dead queue in the queue service 1194 corresponding to the identification information. If there is a dead queue (Yes in step 1802), this means that a processing failure has occurred, and therefore in step 1803, the cloud restore system 350 performs appropriate failure processing. After step 1803, in step 1802, the cloud restore system 350 checks the dead queue again. The failure processing performed in step 1803 is, for example, re-executing the processing of step 1402 and steps 1416 to 1420 only for the LBA management area 571 corresponding to the object key pair stored in the dead queue. If there is no dead queue (No in step 1802), in step 1804, the computer resource release unit 136 constructed by the cloud restore system 350 terminates the queue service 1194 whose queue length has become zero (releases resources). In addition, in step 1805, the computer resource release unit 136 terminates the VM instance 1191 associated with the queue service 1194 (releases resources). In the process of releasing resources, the connection path 1192 configured in step 1414 of FIG. 14 is also released. When all the VM instances 1191 (and the queue service 1194) have been terminated (Yes in step 1806), this means that the restore process has been terminated (completed). Therefore, in step 1807, the computer resource release unit 136 deletes the event monitor unit 1195 remaining in the computer resource 390 (releases resources). In addition, in step 1808, the computer resource release unit 136 deletes the access right setting content for the logical volume 1070 that is the transfer destination in the restore process from the access control layer 1040. Furthermore, in step 1809, the setting change unit 135 constructed by the cloud restore system 350 invalidates the multi-attach setting of the logical volume 1070 as necessary.Thereafter, in step 1811, the cloud restore system 350 notifies the storage operation management service 330 of the completion of the restore process. Upon receiving the notification of the completion of the restore process, the storage operation management service 330 deletes the access right to the backup data store 340 granted to the cloud restore system 350, and notifies the user, etc., via the terminal 380, etc., that the restore process has been completed (not shown).
[0035] According to this first embodiment, the logical volume 1070 can be divided into a plurality of LBA management areas 571 and processed in parallel using the VM instance 1191, which is a temporary computer resource, so that the restoration time can be shortened. In addition, the restore process corresponding to the differential backup process requires overlapping of multiple generations, but since the restore process for the same LBA management area 571 but different generations is processed by the same VM instance, data can be written in the correct generation order. Furthermore, since computer resources are temporarily increased during restoration processing, the computer resources during normal operation can be made to have appropriate performance, making it possible to reduce computer resources and their power consumption.
[0036] 4. Second embodiment of the present disclosure (backup process) The second embodiment has a configuration for backing up a logical volume (one example of a volume) on a cloud to a backup data store in a short time. In addition, the following shows an example in which a temporary computer resource is used as a computer resource for performing a backup process.
[0037] 4.1 System configuration of the second embodiment (backup processing) of the present disclosure 4.1.1 System configuration of a computer system including the system of the present disclosure FIG. 19 shows a system configuration of a computer system 1900 including the system 100 according to the second embodiment of the present disclosure. The computer system 1900 includes a data center 302 (the system 100) and a terminal 380 that are capable of communicating with each other via a network 370, but does not include the on-premise data center present in the first embodiment (although this does not mean that it must not exist). As in the first embodiment, the data center 302 in the second embodiment is, for example, a virtual data center provided by a public cloud service provider. The difference from the first embodiment is that the data center 302 includes a cloud backup and restore system 1951 instead of the cloud restore system 350.
[0038] 4.1.2. Computer resources built for backup processing A cloud backup and restore system 1951 according to the second embodiment of the present disclosure constructs (starts) a computer resource 390 as a group of related resources, and the computer resource 390 performs backup processing. Fig. 20 is a diagram showing the relationship between a cloud backup & restore system 1951 in the second embodiment, a computer resource 390 that the cloud backup & restore system 1951 constructs (launches, generates) during processing, a storage volume service 320 (first storage unit 101), and a backup data store 340 (second storage unit 102). As shown in Fig. 19, these are connected to each other via an internal network 360 so that they can communicate with each other (not shown). In the following, a description of elements that are the same as or similar to those in the first embodiment will be omitted, and only different elements will be described. In the second embodiment, the logical volume 2070 provided by the storage volume service 320 is a logical volume that is a transfer source in the backup process. The logical volume 2070 is provided so as to be accessible through the access endpoint 1050, as in the first embodiment. The cloud backup & restore system 1951 is an expanded version of the cloud restore system 350 of the first embodiment, and additionally has a function for backing up data from the storage volume service 320 to the backup data store 340. The cloud backup & restore system 1951 includes an information processing device 201 as shown in FIG. 2, and also includes a storage device 202 or a non-volatile recording medium 203. The storage device 202 or the non-volatile recording medium 203 stores a restore operation control program 1151, a restore plan generation program 1152, a volume service setting program 1153, a virtual machine (VM) OS image 1154, an instance management program 1155, and a queue management program 1156. In addition, the storage device 202 or the non-volatile recording medium 203 additionally stores a backup operation control program 2057 and a VMOS image (2) 2059. The information processing device 201 executes these programs or images to realize the processing performed by the cloud backup & restore system 1951. The backup operation control program 2057 is a main program for instructing the entire processing up to the completion of the backup processing when an instruction for backup processing is received from the terminal 380. The VMOS image (2) 2059 is a file that stores an OS for operating the VM instance 2098 and a program that operates on the OS. Note that the VMOS image (2) 2059 and the VMOS image 1154 may be integrated into one by standardizing the operating program. The computer resource 390 is the same as that of the first embodiment, and is composed of a queue service 1194, a virtual machine (VM) instance 2098, and an event monitor 1195 that are dynamically constructed (created) by the cloud backup & restore system 1951 executing each program or image.The VM instance 2098 is a server computational resource constructed using the VMOS image (2) 2059. After the OS starts, each VM instance 2098 constructs (starts) a data transfer process 2099 (2099A, 2099B, 2099C) by executing a program included in the VMOS image (2) 2059. The data transfer process 2099 monitors the presence or absence of a processing request in the queue service 1194 it is responsible for, based on the identification information passed as an argument.
[0039] 4-2. Processing of the second embodiment (backup processing) of the present disclosure Based on the system configuration of the second embodiment (and the system configuration of the first embodiment) described above, a series of processes performed for backup processing from the logical volume 2070 in the storage volume service 320 associated with the first memory unit 101 to the backup data store 340 associated with the second memory unit 102 will be described below.
[0040] 4.2.1. Until the backup and restore system is instructed to execute the backup process The following will first explain the process in which the storage operation management service 330, having accepted the backup processing settings entered by a user or the like using the backup settings screen 600, instructs the cloud backup & restore system 1951 to execute the backup processing. 21 shows a flowchart of the process in the second embodiment up to the time when the storage operation management service 330 instructs the cloud backup & restore system 1951 to perform backup processing. The process in FIG. 21 is executed based on a schedule set in the storage operation management service 330 by a user or the like using the backup setting screen 600 in FIG. In step 2101, the storage operation management service 330 instructs the storage volume service 320 to acquire a snapshot of the logical volume 2070 in order to acquire a still image of the logical volume 2070 that is the transfer source in the backup process. Next, in step 2102, the storage operation management service 330 instructs the storage volume service 320 to create an access endpoint 1050 for the snapshot so that the snapshot can be used for backup, and acquires information on the access endpoint 1050. (Note that in step 2102, the storage operation management service 330 may itself create the access endpoint 1050 for the snapshot.) Next, in step 2103, the storage operation management service 330 creates a bucket in the backup data store 340 that is to be the backup storage destination. In step 2104, the storage operation management service 330 grants the cloud backup & restore system 1951 the right to access the bucket. Then, in step 2105, the storage operation management service 330 uses the information of the access endpoint 1050 of the logical volume 2070 (snapshot of the logical volume 2070) and the backup storage destination information of the backup data store 340 to instruct the cloud backup & restore system 1951 to perform backup processing.
[0041] 4.2.2. Processing of the backup and restore system that has been instructed to perform backup processing The cloud backup & restore system 1951, which has been instructed by the storage operation management service 330 to execute a backup process, determines the number of temporary computer resources (e.g., VM instances 2098) to be constructed (activated) for the backup process, and constructs (activates) the determined number of temporary computer resources (VM instances 2098). The cloud backup & restore system 1951 also mounts (a snapshot of) one common logical volume 2070, which is the transfer source in the backup process, for each of the activated temporary computer resources (VM instances 2098). The cloud backup & restore system 1951 also allocates (write) data groups (block data groups) for each management area with respect to data to be the target of the backup process, to each of the activated temporary computer resources (VM instances 2098). The above process will be explained below step by step. FIG. 22 shows a flowchart of the process when the cloud backup & restore system 1951 receives an instruction to execute a backup from the storage operation management service 330 in the second embodiment.
[0042] 4.2.2.1. Determining the number of computer resources to be constructed (started) for backup processing In step 2201 of FIG. 22, the cloud backup & restore system 1951 uses the information of the access endpoint 1050 received at the time of the instruction to acquire information on the capacity of the logical volume 2070 (snapshot) that is the transfer source in the backup process. In step 2202, the cloud backup & restore system 1951 acquires the first differential management bitmap 500. In step 2203, the cloud backup & restore system 1951 acquires configuration information of the differential management bitmap 500, and calculates how many management areas 571 (112) the logical volume 2070 (snapshot) is divided into and managed based on the configuration information, that is, how many differential management bitmaps 500 are included. Next, in step 2204, the setting change unit 135 constructed by the cloud backup & restore system 1951 checks whether the logical volume 2070 (snapshot) is multi-attachable or not. If multi-attach is possible (Yes in step 2204), in step 2205 the setting change unit 135 enables multi-attach of the logical volume 2070 (snapshot). The method of enabling the setting may be, for example, enabling permission of multi-attach of the logical volume 2070 (snapshot), or changing the logical volume 2070 (snapshot) to a disk type that allows multi-attach. Thereafter, in step 2206 the computer resource number determination unit 132 constructed by the cloud backup & restore system 1951 checks the number of connectable hosts of the logical volume 2070 (snapshot) that is the target of the backup process. In step 2207, the computer resource number determination unit 132 compares the number of difference management bitmaps 500 corresponding to the logical volume 2070 with the number of connectable hosts of the logical volume 2070 (snapshot). If the number of differential management bitmaps 500 is greater than the number of connectable hosts (Yes in step 2207), then in step 2209 the computer resource number judgment module 132 sets the number of computer resources to be started in the subsequent backup process to the same number as the connectable hosts.On the other hand, if the number of the differential management bitmaps 500 is equal to or less than the number of connectable hosts (No in step 2207), in step 2210, the computer resource number determination unit 132 sets the number of computer resources for performing the restore process to the same number as the number of the differential management bitmaps 500. Also, if the logical volume 2070 (snapshot of the logical volume 2070) is not multi-attachable (No in step 2204), in step 2208, the computer resource number determination unit 132 sets the number of computer resources for performing the backup process to 1. Although not shown, if the number of computer resources for performing the backup process determined in the above description of step 2209 or step 2210 conflicts with the specifications of the cloud system (for example, the design specifications of the storage volume service 320, the design specifications of the entire data center 302, or contractual constraints of users who use the services provided by the data center 302), the computer resource number determination unit 132 may re-determine the number of computer resources within a range that does not conflict with the specifications. A part or all of the above steps 2206, 2207, 2208, 2209, and 2210 may constitute a computer resource count determination step. In this way, the present disclosure can appropriately determine the number of computer resources to be constructed (started) by considering both the maximum number of hosts related to the volume and the number of management areas included in the volume. Here, the present disclosure determines the number of management areas included in the volume based on the number of first management information (e.g., differential management bitmaps) associated with the management areas, so that the number of management areas included in the volume can be appropriately determined.
[0043] 4.2.2.2. Construction (startup) and mounting (multi-attach) settings for computer resources After the computer resource number determination unit 132 determines the number of computer resources performing backup processing, in steps 2211 to 2215, the cloud backup & restore system 1951 constructs (starts) the queue service 1194 and the VM instance 2098 based on the determined number of computer resources, sets access rights, sets the mount of the logical volume 2070 (snapshot of the logical volume), and sets the connection path 1192. The cloud backup & restore system 1951 also sets the event monitor 1195. The contents of the processes in steps 2211 to 2215 are basically the same as those in steps 1411 to 1415 of FIG. 14 in the first embodiment, and therefore detailed description will be omitted.
[0044] 4.2.2.3. Allocation of processing to each computer resource After completing construction (startup) of the VM instance 2090, which is a computing resource, in step 2216, the area allocating unit 134 constructed by the cloud backup & restore system 1951 sequentially acquires the differential management bitmap 500. In step 2218, the area allocating unit 134 creates a processing request using four pieces of information: information on the differential management bitmap 500, information on the start LBA of the management area 571 (112) corresponding to the differential management bitmap 500, information on the storage destination bucket of the backup data store 340, and information on the seed of the object name, and queues the processing request sequentially to the queue service 1194. Here, the seed of the object name is information that becomes the basis of the object name given when storing the differential management bitmap (bitmap-) or the block data group (block-), and is, for example, "7f-001.000" consisting of a volume number (e.g., 7F), a generation (e.g., 001), and a differential management bitmap number (e.g., 000). The queued processing request may include the differential management bitmap 500 itself, or may include information specifying the location of the differential management bitmap 500. In step 2219, the area allocating unit 134 judges whether or not all the differential management bitmaps 500 included in the logical volume 2070 that is the transfer source in the backup processing have been acquired, based on the number of differential management bitmaps 500 found in step 2203. If there are still remaining differential management bitmaps 500 (No in step 2219), the area allocating unit 134 repeats the processing in steps 2216 and 2218. On the other hand, if the queuing processing has been completed for all the differential management bitmaps 500 corresponding to the logical volume 2070 (Yes in step 2219), the cloud backup & restore system 1951 creates a backup catalog for this backup processing. An area allocation step may be constructed by some or all of steps 2216, 2218, and 2219.
[0045] 4.2.2.4. Processing performed by VM instances during backup processing The VM instance 2098 executes the portion of the backup process corresponding to the management area corresponding to the processing request received from the corresponding queue service 1194 . FIG. 23 shows a flowchart of the processing of a VM instance 2098 during a backup process. In step 2301, the VM instance 2098 starts the data transfer process 2099 by executing a program included in the VMOS image (2) 2059. Note that, according to the operation flow of FIG. 22, the VM instance 2098 is set to be able to access the backup data store 340 and (a snapshot of) the logical volume 2070 that is the transfer source in the backup process. In step 2302, the data transfer process 2099 operating in the VM instance 2098 periodically checks whether or not there is a processing request in the queue service 1194 corresponding to the identification information of the queue service passed as an argument at the time of startup. If there is a processing request in the queue service 1194 (Yes in step 2303), in step 2304, the data transfer process 2099 refers to the processing request in the queue service 1194 and acquires various information such as information on the differential management bitmap 500, information on the start LBA of the management area 571 (112) corresponding to the differential management bitmap 500, information on the storage destination bucket in the backup data store 340, and information on the seed of the object name. Then, in step 2305, the data transfer process 2099 sets the acquired start LBA position as the reference LBA for the backup process (moves to the start LBA). In step 2306, the data transfer process 2099 acquires (scans) the bits of the differential management bitmap 500 in order. If the bit is ON (Yes in step 2307), this means that data to be backed up exists in the LBA corresponding to the bit, so in step 2308, the data transfer process 2099 reads block data from the LBA of the logical volume 2070 (snapshot). In step 2309, the data transfer process 2099 adds the block data read in step 2308 to a temporary file that stores the block data group to be backed up. In step 2310, the data transfer process 2099 advances the reference LBA of the logical volume 2070 (snapshot) and the reference bit of the differential management bitmap 500 by one.On the other hand, if the bit is OFF (No in step 2307), this means that there is no data to be backed up in the LBA corresponding to the bit, so in step 2310 the data transfer process 2099 does nothing and advances the reference LBA of the logical volume 2070 (its snapshot) and the reference bit of the differential management bitmap 500 by one. In step 2311, the data transfer process 2099 determines whether or not all the bits of the differential management bitmap 500 have been referenced. If there are any bits that have not yet been referenced (No in step 2311), the data transfer process 2099 repeats the processing from step 2306 to step 2310. On the other hand, if all bits have been referenced (Yes in step 2311), then the process of reading the block data group from (a snapshot of) the logical volume 2070 to a temporary file, among the processes related to the processing request handled in step 2304, has been completed, so in step 2312 the data transfer process 2099 stores the differential management bitmap 500 and the block data group stored in the temporary file as an object file in the destination bucket of the backup data store 340. At this time, the data transfer process 2099 determines the object name using the seed of the object name. For example, if the seed of the object name is "7f-001.000", the data transfer process 2099 names the object file of the differential management bitmap 500 "bitmap-7f-001.000" and the object file of the block data group "block-7f-001.000". After storing in the backup data store 340, in step 2313 the data transfer process 2099 removes (dequeues) the processing request handled in step 2304 from the queue service 1194, returns control to step 2302, and again periodically checks whether there are any unprocessed processing requests in the queue service 1194. In the operational flow of Fig. 23, the block data group is added to a temporary file and finally stored collectively in the backup data store 340. Here, the block data group may be transferred to the backup data store 340 in units of a certain size, or the block data may be transferred to the backup data store 340 each time. At this time, the block data(s) may be stored in the backup data store 340 in a form in which the block data(s) is divided into object files of smaller sizes, or the block data(s) to be stored later may be added to the object file of the block data(s) previously stored.
[0046] 4.2.2.5. Releasing VM instance resources during backup processing When there are multiple VM instances 2098 constructed (activated) to perform backup processing, the cloud backup & restore system 1951 and computing resources 390 can sequentially release the VM instances 2098 starting from the ones that have completed their assigned processing, without waiting for the entire backup processing to be completed. FIG. 24 is a flowchart showing the operation of the cloud backup and restore system 1951 in the second embodiment when the event monitor 1195 notifies the system that the number of processing requests (queue length) stacked in the queue service 1194 has reached zero. In step 2401, when the cloud backup & restore system 1951 is notified by the event monitor 1195 that the queue length is zero, it acquires the identification information of the queue service 1194 whose queue length is zero. In step 2402, the cloud backup & restore system 1951 checks whether there is a dead queue in the queue service 1194 corresponding to the identification information. If there is a dead queue (Yes in step 2402), this means that a processing failure has occurred, so in step 2403, the cloud backup & restore system 1951 performs appropriate failure processing. Thereafter, in step 2402, the cloud backup & restore system 1951 checks the dead queue again. The failure processing may be, for example, the area allocator 134 re-executing the processing of steps 2216 and 2218 only for the LBA management area stored in the dead queue. If there is no dead queue (No in step 2402), in step 2404, the computer resource release unit 136 constructed by the cloud backup & restore system 1951 terminates the queue service 1194 whose queue length is zero. At the same time, in step 2405, the computer resource release unit 136 terminates the VM instance 2098 associated with the queue service 1194 whose queue length is zero (releases the resources). In the process of releasing, the connection path 1192 configured in step 2214 of FIG. 22 is also released. When all the VM instances 2098 (and the queue service 1194) have been terminated (Yes in step 2406), this means that the backup process has been completed. Therefore, in step 2407, the computer resource release unit 136 deletes the event monitor unit 1195 remaining in the computer resource 390. In step 2408, the computer resource release unit 136 deletes the setting of the access right of the logical volume 2070 (snapshot of the logical volume 2070) that is the transfer source of the backup process from the access control layer. In step 2409, the setting change unit 135 constructed by the cloud backup & restore system 1951 invalidates the multi-attach setting of (a snapshot of) the logical volume 2070 that is the transfer source of the backup process, as necessary.After that, in step 2410, the cloud backup & restore system 1951 stores the backup catalog previously created in step 2220 in the backup data store 340. Then, in step 2411, the cloud backup & restore system 1951 uses the backup catalog to notify the storage operation management service 330 of the completion of the backup process. According to the second embodiment, the backup of a logical volume can be divided into a plurality of LBA management areas 571 and processed in parallel using the VM instance 2098, which is a temporary computer resource, thereby shortening the backup time.
[0047] 5.Other (variations) The present disclosure is not limited to the above-described embodiment, but includes various modifications. A part of the configuration or processing of the embodiment may be replaced with the configuration or processing of another conceivable embodiment. The configuration or processing of the embodiment may be added to the configuration or processing of another conceivable embodiment.
[0048] In the above embodiment, a virtual machine (VM) instance, which is a temporary computer resource, is taken as the computer resource that performs the data transfer process (e.g., backup process or restore process), but other types of temporary computer resources (e.g., containers) may be used. Also, a computer resource that is not a temporary computer resource may be the computer resource that performs the data transfer process. For example, a hardware-based computer resource may be directly assigned to the data transfer process. In this way, the present disclosure allows the configuration of computer resources for realizing the data transfer process to be appropriately selected from a wide range of options.
[0049] The technical matters described in each of the embodiments of the present disclosure and the modified examples of the embodiments described above can be combined as appropriate as long as no technical contradiction occurs.
Claims
1. 1. A system comprising: The system includes a first storage unit, a second storage unit, and a data transfer unit, the first storage unit includes a volume for storing data, and each volume includes one or more storage areas; the data transfer unit includes a computer resource starting unit and an area allocating unit; the computer resource starting unit, when performing a data transfer process between one of the volumes and the second storage unit, starts one or more computer resources that perform the data transfer process, and mounts a common one of the volumes that will be a transfer source or a transfer destination in the data transfer process to any of the started computer resources; Mounting the volume on the computer resource means making the computer resource recognize the volume and enabling the computer resource to access data in the volume; the area allocating unit allocates the data transfer process to the computer resources for each of the storage areas; A system in which the computer resource performs the data transfer process between the storage area allocated to the computer resource in the common single volume and the second storage unit.
2. 2. The system of claim 1, the data transfer process is a backup process from one of the volumes to the second storage unit, or a restore process from the second storage unit to one of the volumes, the storage area is a management area, the first storage section includes first management information for each of the management areas of the existing volumes, the first management information indicating at which position within the management area the data should be targeted for the backup process; the second storage unit stores one or more generations of backup data for each backup process for one generation for the volume that has been backed up; A system in which the backup data for one generation includes, for each management area, a data group consisting of the data backed up from the management area of the volume, and second management information indicating a position within the volume corresponding to the data included in the data group.
3. 3. The system of claim 2, the data transfer unit includes a computer resource count determination unit, the computing resource is a temporary computing resource; A number of connectable hosts, which is the number of temporary computer resources capable of mounting the volume, is associated with the volume; and The computer resource number determination unit determines, for one of the volumes that is the source of transfer in the backup process or the destination of transfer in the restore process, the number of management areas contained in the one volume and the number of connectable hosts associated with the one volume, whichever is larger, as the number of temporary computer resources that will perform the backup process or the restore process, and transmits this number to the computer resource startup unit as the number of temporary computer resources to be started.
4. 4. The system of claim 3, The computer resource number determination unit determines the number of management areas contained in one of the volumes based on the number of first management information corresponding to one of the volumes, or the number of second management information corresponding to one generation of the backup processing of one of the volumes.
5. 3. The system of claim 2, the backup process is a differential backup process that transfers to the second storage unit only data that has been written to the volume that is the transfer source of the backup process since the time of the previous backup process, The restore process is a process of executing restore processes of all generations before the generation indicating the time point to be restored by the restore process, in order from the oldest generation, the area allocating unit, when allocating the restore processes of different generations relating to the same management area in one of the volumes that is a transfer destination of the restore processes, allocates these restore processes to the same computer resource; A system in which, when the computer resource is assigned the restore processes for a plurality of generations relating to the same management area, the computer resource executes the restore processes in an order that produces normal processing results.
6. 6. The system of claim 5, The system further comprises an area allocation unit which, when performing the restore process, allocates the restore process relating to each combination of a generation that may be the target of the restore process and a management area that may be the target of the restore process to one of the computer resources when the second management information corresponding to the combination indicates that at least one piece of data in the management area has been backed up to the second storage unit.
7. 2. The system of claim 1, the data transfer unit includes a computer resource count determination unit, The computer resource number determination unit determines the number of computer resources performing data transfer processing between one of the volumes and the second memory unit, and transmits the number to the computer resource startup unit as the number of computer resources to be started.
8. 2. The system of claim 1, the data transfer process includes a plurality of generations of data transfer processes for each of the storage areas that is a transfer source or a transfer destination in the data transfer process, the area allocating unit allocates the data transfer processes of a plurality of generations relating to the same storage area to the same computer resource during the data transfer process; The computer resource executes the data transfer process for multiple generations relating to the same storage area in an order that produces normal processing results.
9. 2. The system of claim 1, The system is a cloud system, A system, wherein the volume or the second storage unit is available to other systems or devices via a network.
10. 2. The system of claim 1, The second storage unit is a backup data store in an object storage format.
11. 2. The system of claim 1, The computer resource startup unit establishes a connection path from the computer resource to be started to the volume to be mounted on the computer resource.
12. 2. The system of claim 1, the data transfer unit includes a setting change unit, The system further comprises a setting change unit that, when mounting one of the volumes common to multiple computer resources, changes the setting of the one volume to a multi-attachable disk type, and, when the data transfer process is completed, returns the setting of the one volume to a disk type that does not support multi-attachment.
13. 2. The system according to claim 1, wherein the data transfer unit includes a computer resource release unit, the computing resource is a temporary computing resource; The computer resource release unit releases the temporary computer resource that has been allocated and that has completed the data transfer process even before the entire data transfer process is completed.
14. A method implemented by the system, comprising: The system includes a first storage unit and a second storage unit, the first storage unit includes a volume for storing data, and one of the volumes includes one or more storage areas. The method includes a computer resource activation step and an area allocation step, the computer resource activation step is a step of activating one or more computer resources that perform data transfer processing between one of the volumes and the second storage unit, and mounting a common single volume that is to be a transfer source or a transfer destination in the data transfer processing to any of the activated computer resources; Mounting the volume on the computer resource means making the computer resource recognize the volume and enabling the computer resource to access data in the volume; the area allocation step is a step of allocating the data transfer process to the computer resources for each of the storage areas; A method, wherein the computer resource performs the data transfer process between the storage area allocated to the computer resource in the common single volume and the second storage unit.
15. A program executed in the system, The system includes a first storage unit and a second storage unit, the first storage unit includes a volume for storing data, and one of the volumes includes one or more storage areas. the program is for causing the system to execute a computer resource activation step and an area allocation step, the computer resource activation step is a step of activating one or more computer resources that perform data transfer processing between one of the volumes and the second storage unit, and mounting a common single volume that is to be a transfer source or a transfer destination in the data transfer processing to any of the activated computer resources; Mounting the volume on the computer resource means making the computer resource recognize the volume and enabling the computer resource to access data in the volume; the area allocation step is a step of allocating the data transfer process to the computer resources for each of the storage areas; A program, wherein the computer resource performs the data transfer process between the storage area allocated to the computer resource in the common single volume and the second storage unit.
Citation Information
Patent Citations
Server-free archival of backup data
US7496723B1