Storage and storage data protection method
Patent Information
- Application Number
- JP2023137013
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-08-25
- Publication Date
- 2025-03-07
- Estimated Expiration
- 2043-08-25
AI Technical Summary
【0007】 本発明によれば、データをより安全に格納することが可能になる。上記した以外の課題、構成及び効果は以下の実施の形態の説明により明らかにされる。
Smart Images

Figure 2025031052000001_ABST
Abstract
Description
[Technical field]
[0001] The present disclosure relates to a storage and a method for protecting data in the storage. [Background technology]
[0002] The storage has a snapshot function for protecting data. The snapshot function is a logical copy of a volume in which user data is stored at a certain moment. Furthermore, in recent years, a backup method for storing backup data in a public cloud has appeared. Specifically, there is a backup to an object storage service of a public cloud characterized by low cost. Patent Document 1 states that "the local storage creates a backup area that is used as a backup destination for data written to the business volume. The local storage associates the backup area with a server system that provides access from the local storage to the cloud storage. The local storage writes data associated with the write request to the business volume and backs up the data in the backup area. The local storage transmits the data from the backup area to the server system to write the data in the cloud storage." [Prior art documents] [Patent documents]
[0003] [Patent Document 1] JP 2021-149773 A Summary of the Invention [Problem to be solved by the invention]
[0004] In recent years, cyber attacks, including ransomware, have been increasing. Snapshot functions are used to protect data stored in storage from such attacks. On the other hand, cyber attacks are becoming more sophisticated every year, and attacks on protected data are also increasing. Specifically, attacks such as deleting snapshots or destroying data by writing to snapshots are considered. Furthermore, data backed up to object storage, including the public cloud mentioned above, can also be targeted by attacks. In the case of public clouds, access is made via a network from IT equipment installed in an on-premise data center, so there are access routes from outside the public cloud, which raises security concerns.
[0005] An object of the present disclosure is to provide a data protection method for enhancing data protection using a snapshot function in a storage and data protection for data transferred outside the storage. [Means for solving the problem]
[0006] In order to achieve the above-mentioned object, one representative storage of the present invention is a storage having a processor that processes data to be stored in a storage device and is connected to other storage devices via a network, wherein the processor obtains a first snapshot of a volume generated using a storage area of the storage device, compares the first snapshot with a second snapshot which is a previously obtained snapshot, extracts incremental data, transfers the incremental data to the other storage device, stores it as backup data, and sets a lock on the backup data stored in the other storage device. Furthermore, one representative data protection method for storage of the present invention is a data protection method for storage having a processor that processes data to be stored in a storage device and connected to another storage device via a network, characterized in that the processor obtains a first snapshot of a volume generated using a storage area of the storage device, compares the first snapshot with a second snapshot which is a previously obtained snapshot, extracts incremental data, transfers the incremental data to the other storage device, stores it as backup data, and sets a lock on the backup data stored in the other storage device. Effect of the Invention
[0007] According to the present invention, data can be stored more safely. Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]
[0008] [Figure 1] FIG. 1 is a diagram illustrating a storage system according to a first embodiment of the present disclosure. [Diagram 2] FIG. 2 illustrates an example of a storage configuration. [Diagram 3] FIG. 4 is a diagram illustrating an example of information stored in a memory of a storage. [Figure 4] FIG. 1 is a diagram for explaining an overview of snapshots and snapshot protection. [Diagram 5] 13 is a flowchart illustrating an example of a snapshot lock process. [Figure 6] FIG. 13 illustrates an example of a snapshot table. [Figure 7] 11 is a flowchart illustrating an example of a snapshot deletion process. [Figure 8] 11 is a flowchart illustrating an example of a write process. [Figure 9] FIG. 1 is a diagram for explaining an overview of a backup process. [Figure 10] 11 is a flowchart illustrating an example of a backup process. [Figure 11] 11A and 11B are diagrams illustrating an example of a catalog, generation information, difference information, and data. [Figure 12] FIG. 13 illustrates an example of a backup table. [Figure 13] 10 is a flowchart illustrating an example of a lock setting process. [Figure 14] 11 is a flowchart illustrating an example of a cyber attack detection process. [Figure 15] 13 is a flowchart illustrating an example of a backup processing delay detection process. [Figure 16] FIG. 13 illustrates an example of a backup performance table. [Figure 17] 13 is a flowchart illustrating an example of a data migration process. [Figure 18] 13 is a flowchart illustrating an example of a backup deletion process. [Figure 19] 13 is a flowchart illustrating an example of an object deletion process. [Figure 20] FIG. 13 illustrates an example of a lock management table. [Figure 21] 13 is a flowchart illustrating an example of a lock extension process. [Figure 22] FIG. 13 is a diagram illustrating another example of the configuration of the storage. [Diagram 23] 2 is a diagram illustrating the relationship between a volume, a capacity pool, and a pool volume 291. [Figure 24] FIG. 13 is a diagram illustrating an example of a pool table. [Diagram 25] FIG. 13 is a diagram illustrating an example of a volume table. [Figure 26] 11 is a flowchart illustrating an example of a tearing process. [Figure 27] 13 is a flowchart illustrating an example of a demotion process. [Figure 28]13 is a flowchart illustrating an example of a promotion process. [Figure 29] 11 is a diagram illustrating an example of information recorded in a memory and a management server. FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0009] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.
[0010] In the following, the processing may be described with a "program" as the operating subject, but since the program is executed by the processor unit to perform a predetermined processing while appropriately using at least one of the memory unit and the interface unit, the subject of the processing may be the processor unit (or a computer or storage system having a processor unit). The program may be installed in the computer from a program source. The program source may be, for example, a program distribution server or a storage medium readable by a computer. In the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs. At least a part of the processing realized by executing the program may be realized by a hardware circuit (for example, an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array)). EXAMPLES
[0011] Fig. 1 is a diagram showing a storage system according to a first embodiment of the present disclosure. The storage system shown in Fig. 1 includes a data center (on-premise) 1 including a server 100 and a storage 200, and a cloud 2 including an object storage 400 and external management software 410, and the data center 1 and the cloud 2 are connected to each other via a network 300 so as to be able to communicate with each other. There may be a plurality of these configurations. The data center 1 may be a public cloud.
[0012] The data center 1 functions as a primary site that performs business processing under normal conditions. The cloud 2 stores backup data of data related to business processing of the data center 1, and functions as a secondary site (secondary environment) that takes over business processing of the server 100 under specific conditions such as a disaster. A secondary server may be arranged at the secondary site. The external management software 410 is management software that manages the storage 200 and the object storage 400. Although an example of operation in the cloud 2 is shown, it may also operate in the data center 1 or another data center.
[0013] The server 100 is a host that performs business processing by executing computer programs (hereinafter referred to as application programs) for performing business processing, such as application programs and middleware. The storage 200 is a first storage device that stores data used and generated in the business processing by the server 100, and stores data in response to I / O requests (read / write requests) from the server 100.
[0014] The object storage 400 is a storage device that stores backup data of data stored in the primary storage 200. In this embodiment, the backup data is used as restoration data for restoring data at the secondary site, and the object storage 400 functions as a restoration storage device that stores the restoration data. The object storage 400 may be a lower-cost storage device compared to the storage 200, and in this embodiment, it is an object storage device that stores data on an object-by-object basis, which is generally considered to be inexpensive. In this embodiment, an object storage is used as an example, but a storage other than the object storage may be used as long as it is lower in cost than the storage 200. A file storage or the like may be used. It may be a storage service provided by a storage vendor on a public cloud. The cloud 2 may not be a public cloud, but may be a data center different from the data center 1.
[0015] Fig. 2 is a diagram showing an example of the configuration of a storage 200 and a management terminal 270 connected to the storage 200. As shown in Fig. 2, the storage 200 has one or more controllers 210 and one or more physical drives 220. In the example of Fig. 2, two controllers 210 and five physical drives 220 are shown.
[0016] The controller 210 is a control unit that controls I / O requests from the server 100, controls reading and writing of data from and to the physical drive 220, and controls processing for transferring data to the cloud. The controller 210 has a FE (Front-End) I / F 211, a BE (Back-End) I / F 212, a management I / F 213, an RC (Remote Copy) I / F 214, a memory 215, and a processor 216.
[0017] The FEI / F 211 is an interface for connecting to the server 100 so as to be able to communicate with it, and in this embodiment has a plurality of Fibre Channel ports. However, the FEI / F 211 may include ports other than Fibre Channel, such as iSCSI ports, instead of Fibre Channel ports.
[0018] The BEI / F 212 is an interface for communicatively connecting to the physical drive 220. The management I / F 213 is an interface for communicatively connecting to the management terminal 270 via the management network 230. The RCI / F 214 is an interface for communicatively connecting to the object storage 400 of the cloud 2 via the network 300. The RCI / F 214 has, for example, a plurality of IP (Internet Protocol) ports. It may also have a Fibre Channel port. The FEI / F 211, the RCI / F 214, and the BEI / F 212 may share one I / F board.
[0019] The memory 215 records programs that define the operation of the processor 216, control information used by the programs, and the like. The memory 215 can also store data as a cache for data to be stored in the physical drive 220. The processor 216 executes various processes by executing the programs recorded in the memory 215.
[0020] The physical drives 220 are physical data storage devices that store data. A plurality of physical drives 220 may constitute one or more RAID (Redundant Array of Independent (or Inexpensive) Disks) groups. A primary volume 217 is configured across the plurality of physical drives 220 and provided to the server 100.
[0021] The management terminal 270 is a terminal for maintaining and managing the storage 200, and has a management port 271, an input / output unit 272, a memory 273, and a CPU 274. The management port 271 is communicatively connected to the storage 200 via the management network 230. The input / output unit 272 has an input function for receiving various information from a user who uses the management terminal 270, and an output function for outputting various information to the user. The memory 273 stores various programs that define the operation of the CPU 274. The CPU 274 reads the programs recorded in the memory 273 and executes the read programs to execute various processes for maintaining and managing the storage 200.
[0022] The configuration of the storage 200 shown in Fig. 2 is merely an example and is not limited thereto. For example, the storage 200 may be an SDS (Software Defined Storage) that realizes storage functions using a program that executes storage processing in each of a plurality of servers. Fig. 22 shows an example of an SDS. Since the SDS in Fig. 22 operates in a public cloud, the storage server 503 is a virtual machine, but it may also be a physical server.
[0023] The storage 200 may have hardware for performing specific processing, etc. Examples of this type of hardware include hardware for compressing data and hardware for encrypting data, etc. The storage 200 may be a storage device provided as a service.
[0024] Fig. 3 is a diagram showing an example of information stored in the memory 215 of the storage 200. As shown in Fig. 3, the memory 215 stores control information 221 and a program 222 as information related to snapshot processing and backup processing. The memory 215 also has a cache unit 223 that temporarily stores data. The control information 221 has a snapshot table 2210, a backup table 2211, and a transfer amount table 2212. Details of these tables will be described later. The program 222 has a snapshot lock program 2221, a snapshot deletion program 2222, a write program 2223, a backup program 2224, a data transfer program 2225, a bucket setting program 2226, and an attack detection program 2227. 3 describes the programs related to this embodiment. In reality, other programs may be included. For example, there may be a read program for reading data from the volume 217.
[0025] Fig. 4 is a diagram showing an outline of the invention. As a method for recovering data after a cyber attack, there is a method of creating a backup of data and recovering the data from the backup data. In storage, a backup of data can be created using a snapshot function.
[0026] A snapshot is a logical copy of a volume that stores user data at a certain moment. Creating a snapshot does not require copying the actual user data, and can be completed in a short time.
[0027] A snapshot creates a logical copy by pointing to data stored in volume 241. This pointer information is called metadata. If data is written to volume 241 after a snapshot is created, the data is saved to a different physical address and the metadata of volume 241 is updated to the different physical address. The same applies when data is written to snapshot 242. This allows the data in volume 241 and snapshot 242 to be saved correctly.
[0028] By using snapshots, data can be protected from cyber attacks on business data. If business data is attacked and cannot be used for business processing, the data can be restored by writing the snapshot data back to the volume 241 (hereinafter, referred to as "restoring").
[0029] However, if a cyber-attack is carried out against a snapshot, it is not possible to restore normal data before the attack to volume 241. For example, possible examples of an attack include writing data to a snapshot, deleting a snapshot, etc. Writing data also includes encrypting the data in the snapshot.
[0030] This requires a protection function for snapshots (lock function). Locking refers to prohibiting the deletion or modification of physical data. The lock function is a function that prohibits access (writing and reading) to snapshots and prohibits the deletion of snapshots. It may also be a function that only allows reading of data. It may also be possible to set a lock period that prohibits access and snapshots. For example, access and deletion may be prohibited for one month. Administrators with specific roles may be able to access and delete snapshots. When the lock period has elapsed, the lock is released and the snapshot can be accessed and deleted.
[0031] A finite period is set as the lock period. However, if a long period is set, the snapshot cannot be deleted even if it is no longer needed, and unnecessary data will continue to be stored. In addition, in such a cyber attack, snapshots 242 may be taken frequently in order to restore with the most recent data at the time of recovery. For this reason, it is unlikely that an extremely long period will be set.
[0032] If volume 241 is infected with ransomware due to a cyber attack, the data in the snapshots created after the ransom attack will also be infected. The example in the figure shows that snapshot 242 created on April 4th is infected.
[0033] In this case, it is necessary to restore a snapshot before April 3. On the other hand, as time passes, snapshots before April 3 may not be locked, or may be unlocked if the lock period expires in the future.
[0034] In this invention, when a cyber attack is detected, a lock is set, or a lock that is about to expire is extended. In the following explanation, data that may be infected with ransomware, other viruses, or encrypted by ransomware is collectively called attacked data. Data that has not been attacked is called normal data.
[0035] 5 is a diagram showing an example of the processing of the snapshot lock program 2221. The snapshot lock program 2221 is a program that, upon detecting a cyber-attack, identifies snapshots that require locking and sets a lock or extends the lock period.
[0036] The snapshot lock program 2221 can run on any of the storage 200 , the management terminal 270 , and the external management software 410 .
[0037] Several methods for detecting cyber attacks are already known in the art. Technologies that learn the IO to storage, data compression rate within storage, and the like, and detect attacks from changes in these are known. If an attack is detected by these functions, the process from step S101 onwards is executed and the snapshot is locked.
[0038] The detection of a cyber attack does not have to be detection of a cyber attack on storage. Step S101 and subsequent steps may be executed when an attack on a network, a server, middleware, an application, or the like is detected.
[0039] The snapshot lock program 2221 executes a cyber-attack detection program to determine whether or not an attack has occurred (step S100). If there is no attack, the process ends (step S107). If an attack has occurred, the snapshot lock program 2221 identifies the snapshots that have already been acquired (step S102). This process can be realized by referring to the snapshot table of the storage 200.
[0040] Next, the snapshot lock program 2221 judges whether the snapshot is locked (step S103), and if it is not locked, issues a command to lock the target snapshot (step S104). This process is realized by storing information on the snapshot lock setting, snapshot lock period, and access mode in the snapshot table. On the other hand, if it is locked, the process proceeds to step S105.
[0041] In step S105, the snapshot lock program 2221 judges whether the remaining time of the set lock is equal to or longer than a certain time (step S105). This can be realized by referring to the information on the snapshot lock period in the snapshot table.
[0042] If the remaining time is equal to or less than a certain time, the snapshot lock program 2221 instructs to extend the lock period (step S106). This process is realized by changing the value of the snapshot lock period in the snapshot table 2210. On the other hand, if the remaining time is equal to or more than a certain time, the process proceeds to step S107 and ends (step S107).
[0043] The snapshot lock program 2221 can run anywhere in the management terminal 270, the external management software 410, or the storage 200. When the snapshot lock program 2221 runs in the management terminal 270 or the external management software 410, the processes of steps S102, S104, and S106 acquire and update the information in the snapshot table 2210 through a program running in the storage 200.
[0044] This program is executed periodically. The snapshot lock program 2221 may be called from the cyber attack detection program. In the above description, the process from step S102 onwards is performed on each snapshot. In cases where the lock period is set for each group of multiple snapshots, the process from step S102 onwards may be performed for each group. When a cyber-attack is detected as an attack on a specific volume, the process from step S102 onwards may be executed on a snapshot of the volume. Also, the process from step S102 onwards may be executed preferentially on the volume under attack. The process from S102 to S107 may be executed on a volume 241 designated in advance by the user.
[0045] Since a snapshot created after detecting a cyber attack may indicate that the snapshot is under attack, the possibility of the snapshot being under attack may be managed in the snapshot table 2210, and the possibility of the snapshot being under attack may be displayed using management software, etc.
[0046] FIG. 6 is a diagram showing an example of the snapshot table 2210. As shown in FIG. 6, a snapshot table 2210 is information for managing information related to snapshots created for volumes. The snapshot table 2210 holds information on the consistency group number, volume number, snapshot number, snapshot lock setting, snapshot lock period, and access mode.
[0047] The volume number is a volume number for identifying the target volume 217 for snapshot creation. The snapshot number is a number for identifying a snapshot created for the volume identified by the volume number. A single snapshot can have multiple snapshots. Snapshots can also be managed as volumes, and a volume number can be assigned to each snapshot to take a snapshot as a target. The snapshot lock setting is information indicating whether or not a lock is set for the snapshot identified by the snapshot number. If "ON" is set, the lock is set and the snapshot cannot be deleted. In addition, access to the snapshot is performed according to the access mode. The snapshot lock period is information indicating the date and time when a lock is set on a snapshot. The access mode manages the type of access that can be performed to the target snapshot. Values such as read prohibited, write prohibited, both read and write prohibited, and both read and write permitted can be stored. In the example shown in the figure, snapshot 1 is locked until 3:00 p.m. on April 25th, meaning that reading is possible but writing is not possible.
[0048] The consistency group number is information that associates multiple volumes in order to manage them as a single group. By using a consistency group, when one application uses multiple volumes, it becomes possible to obtain snapshots of the same date and time for all of those volumes at once. In the example shown in the figure, Volume 1-1 and Volume 1-2 belong to Consistency Group 1. The snapshot table 2210 may include information other than the information shown in Fig. 6. For example, it may include information such as the creation time of the snapshot. It may be determined that a snapshot lock is set by storing a finite value in the snapshot lock period, in which case the value of the snapshot lock setting may not be necessary.
[0049] FIG. 7 is a diagram showing an example of the processing of the snapshot deletion program 2222 for deleting a snapshot. The snapshot deletion program 2222 runs on the storage 200 and updates the snapshot table 2210 to delete the snapshot. The snapshot deletion program 2222 receives a snapshot deletion instruction via the management terminal 270 or the external management software 410 (step S200).
[0050] The snapshot deletion program 2222 checks the snapshot lock setting to determine whether or not a lock has been set for a snapshot (step S201).
[0051] If a lock has already been set for the snapshot, that is, if the value of the snapshot lock setting is ON, an error is reported in step S203, and the process ends (step S204). On the other hand, if no lock has been set for the snapshot, that is, if the value of the snapshot lock setting is OFF, the snapshot is deleted in step S202, and the process ends (step S204).
[0052] Since the snapshot deletion process is a common process, a detailed description will be omitted from the flowchart in Fig. 7. A snapshot can be deleted by deleting the snapshot information to be deleted from the snapshot table 2210 and deleting data that is referenced only by that snapshot. Note that this data deletion may be performed asynchronously.
[0053] FIG. 8 is a diagram showing an example of the processing of the write program 2223 which receives a write request from the server 100 and stores the write data in a volume. The write program 2223 runs on the storage 200 . The write program 2223 receives a write request from the server 100 (step S205). The write program 2223 checks the snapshot lock setting to determine whether or not a lock has been set for the snapshot (step S206). If writing is not possible, that is, if the access mode value does not include "WR", an error is reported in step S209 and the process ends (step S210). On the other hand, if writing is possible, that is, if the access mode value includes "WR", the write process is executed in step S207, and the process ends (step S210).
[0054] Through the above process, the backup data acquired within the storage 200 can be protected from cyber attacks and attacks by malicious administrators. Next, a case will be described in which backup data is acquired in an external storage device, rather than in the storage 200. Although the object storage 400 will be taken as an example of the external storage device, other storage devices may be used.
[0055] FIG. 9 is a diagram for explaining the flow of a process for acquiring a backup in the object storage 400. There are several types of transfer methods for transferring backup data to the object storage 400. For example, the transfer methods include incremental backup, differential backup, and remote copy. Incremental backup and differential backup are methods for periodically transferring backup data. Incremental backup is a method for transferring updated data that has been updated since the previous transfer of backup data as the next backup data, and differential backup is a method for transferring differential data from the initially transferred backup data as the backup data. Remote copy is a method for reflecting updates of the volume 241 in the object storage 400. In remote copy, there is a method for transferring data sequentially every time the data is written to the volume 241, and a method for periodically transferring the written data together. In addition, in the method for periodically transferring data, if the same address is updated multiple times, only the last updated data may be transferred. In this embodiment, the transfer method is incremental backup. The technology of this embodiment can be applied to differential backup by changing the snapshot used when extracting differential data, which will be described later, to the snapshot acquired this time and the snapshot corresponding to the initially transferred backup data.
[0056] In incremental backup, a snapshot of the data stored in storage 200 (more specifically, the data stored in storage 200 that is stored in the volume 241 to be protected) is created periodically (daily in the example of Figure 9) and transferred to object storage 400.
[0057] For example, at the time of the first transfer on April 1st, data stored in volume 241 is transferred to and stored in object storage 400 as object 3000. Generally, the ratio of the number of volumes 241 to the number of objects 3000 is 1:N (an integer equal to or greater than 2), but it may be 1:1, for example.
[0058] At the time of April 2, which is the next transfer timing, the snapshot holds only the differential data generated between April 1 and April 2, and the snapshot is transferred to and stored in the object storage 400. In the example of FIG. 9, data A0 is updated to data A1 between April 1 and April 2. Therefore, A1 is transferred to the object storage 400 as the difference. The write destination addresses (storage addresses of A0 and A1) generated between April 1 and April 2 are extracted, and the data of the addresses is read from the snapshot of April 2, thereby extracting the differential data. Similarly, at the time of April 3, which is the further next transfer timing, the snapshot holds only the differential data generated between April 2 and April 3, and the snapshot is transferred to and stored in the object storage 400.
[0059] The frequency at which snapshots are generated and the frequency at which snapshots are transferred to the object storage 400 may be different. For example, a snapshot that has not been referenced for a certain period of time in the storage 200 may be transferred to the object storage 400. Transfer of data identical to data stored in the object storage 400 may be avoided. In this case, instead of transferring data, management information indicating the identical data may be transferred. In this case, it is possible to reduce the amount of data transferred and the amount of data stored in the object storage 400.
[0060] 1, the object storage is an object storage 400 provided by the cloud 2, but it may be an appliance-type object storage. For example, it may be an object storage installed in the data center 1, or it may be an object storage installed in another data center.
[0061] Each object may be compressed to reduce the amount of data. The data may be compressed when transferred from the storage 200, or may be compressed in the object storage 400. When the data is compressed when transferred from the storage 200, it is possible to reduce not only the amount of data stored in the object storage 400 but also the amount of data transferred over the network.
[0062] Next, the problems caused by cyber attacks will be explained. Problem 1: While the difference between the April 3rd and April 2nd snapshots is being extracted and transferred to object storage, the April 3rd snapshot may be attacked. For example, the data may be rewritten. In that case, the attacked data will also be stored in object storage 400. To protect data from such attacks, the April 3rd snapshot is locked until the transfer of object 3002 is complete. Snapshot deletion and write prohibition are set. Data needs to be read in order to be transferred to object storage 400, so reading is permitted.
[0063] Problem 2: Next, consider the case where an attack is made against the snapshot on April 2 when transferring the backup on April 3. For example, if all the data on April 2 is rewritten, when the differential data between April 3 and April 2 is extracted, the data of all addresses will be extracted as the differential. This is because all the data on April 2 is rewritten and becomes different from the data on April 3. In that case, even the extra data that does not need to be transferred needs to be transferred to the object storage 400. In the example shown in the figure, if B0 in the snapshot on April 2 is rewritten to B5, the address of B0 is also extracted as the differential in the data transfer on April 3, and B0 is also transferred to the object storage. The data itself does not become inconsistent, but it consumes the capacity of the object storage. In the case of the cloud, if charges are incurred according to the storage capacity, extra costs will be incurred. In order to protect data from such attacks, it is desirable to lock the snapshot on April 2 as well when transferring the data on April 3. However, since locking on April 2 is not essential, it is possible to lock only the snapshot on April 3 and not the snapshot on April 2. This is because, even if the above-mentioned attack occurs, although the amount of data transferred to the object storage increases, the data itself can be normal data transferred to the object storage.
[0064] Problem 3: As problem 3, consider an attack on the object storage 400. There is a possibility that objects stored in the object storage 400 may be rewritten or deleted by a cyber attack. If such an attack occurs, it will be impossible to recover the correct data from the object storage 400. In order to protect data from such attacks, it is necessary to lock the objects themselves stored in the object storage 400. Objects are locked using a lock function provided by object storage products or public cloud object storage services. Basically, loss of normal data can be avoided by deleting or updating objects. Also, the lock period can be set in the same way as snapshot locking. In addition, a function is provided to extend the set lock period. The following diagrams will explain how to avoid these problems.
[0065] 10 is an example of a process for explaining an example of a backup process to an object storage. This process avoids the above-mentioned problems 1, 2, and 3 by locking the snapshot created in the storage 200 and locking the object stored in the object storage 400. These processes are realized by the backup program 2224 and the data transfer program 2225. These programs run in the storage 200.
[0066] The backup program 2224 determines the lock period when it is time to create a snapshot (step S300). This snapshot lock is a lock to solve the above-mentioned problems 1 and 2. If only problem 1 is to be solved, only the lock of the snapshot created this time in step S301 needs to be created. The lock period is sufficient if the snapshot is locked while steps S301 to S309 are executed. Most of the time of steps S301 to S309 is the data transfer time of step S307. This data transfer time depends on the amount of difference data to be transferred. The lock period can be determined by estimating the amount of difference data to be transferred. The amount of difference data to be transferred can be estimated from the amount of difference data between the volume 241 and the previous snapshot 242. An example of FIG. 9 will be used for explanation. If the snapshot to be created this time is April 3, if the difference between the volume 241 and the snapshot of April 2 is extracted before creating the snapshot of April 3, it is found that the difference data is A2. This difference data roughly matches the snapshot of April 3 and the snapshot of April 2. Once the amount of difference is known, the transfer time can be calculated from the track record of transfer performance from storage 200 to object storage 400. The lock period for the April 3rd snapshot can also be determined using the following method. A snapshot for April 3rd is created. At this time, a lock period that is long enough to calculate the amount of difference, such as 10 minutes, is set. The difference between the snapshot created for April 3rd and the previous snapshot taken on April 2nd is extracted, and the transfer time is calculated. The lock period for the April 3rd snapshot is then extended using the calculated transfer time. Alternatively, the lock period can simply be determined based on the track record of past transfer times. For example, in the case of date and time backups, the track record would be that the transfer time is within five hours. Track records can also be managed and applied by day of the week.
[0067] Next, to solve problem 2 or problem 1 and problem 2, both the snapshot created this time in step S301 and the snapshot created last time in step S301 must be locked. In other words, the snapshot created this time in step S301 must be kept locked until the next snapshot is created. The lock period is calculated from the frequency of backups stored in a backup table, which will be described later. In the example of FIG. 9, a backup is created once a day. That is, the snapshot used in the backup process is also created once a day. For this reason, in the example of FIG. 9, it can be seen that the lock period for the snapshot created in step S301 should be one day. Taking into account delays in snapshot creation and delays in the backup acquisition schedule, the lock period may be set to one day plus several hours to one day. After determining the lock period, the backup program creates a snapshot for each volume 241 to be protected (step S301). At this time, a snapshot lock is set for the lock period determined in step S300. This makes it possible to avoid the problems described above and store normal data in the object storage.
[0068] The backup program 2224 determines the generation number of the current snapshot acquired in step S300 (step S302). For example, if the generation number is a consecutive number, the backup program 2224 determines the current generation number by incrementing the previous generation number.
[0069] The backup program 2224 extracts the difference between the previous snapshot and the current snapshot (step S303). The extraction of the difference can be realized, for example, by holding the write address of the data written to the primary volume 217 after the snapshot was acquired, or by comparing the snapshot metadata of the previous snapshot and the current snapshot. Snapshot metadata is information indicating the address where the snapshot data is physically stored. If it is the same as the data of the protected volume, the capacity consumption by the snapshot can be reduced by storing the address indicating the physical location where the data of the protected volume is stored. The previous snapshot refers to a snapshot created in step S301 of the previously executed backup program. There is a possibility that a function other than the backup process to the object storage 400 may acquire a snapshot of the volume 241. When taking such a case into consideration, by storing snapshot creation source information in the snapshot table 2210, it is possible to identify the snapshot created in step S301 of the previously executed backup program.
[0070] The backup program 2224 refers to the backup table 2211, identifies the cloud 2 and bucket to which the backup data, which is the difference between the snapshots, is to be transferred, and further determines the format, which is the data transfer method (step S304). For example, the backup program 2224 determines, as the format, which data is to be combined into one object according to the upper limit of the object size.
[0071] The backup program 2224 creates a catalog, which is management information for managing the backup process, and metadata for managing the backup data (step S305). A more detailed description of the catalog and metadata will be given later with reference to FIG.
[0072] Thereafter, the data transfer program 2225 transfers the backup data as an object to the object storage 400 of the cloud 2 in accordance with the format confirmed in step S304 (step S307). At this time, the data transfer program 2225 specifies a lock for the object to be transferred. The lock period is specified as a lock period stored in a backup table, which will be described later. At this time, the data transfer program 2225 may also appropriately perform processing related to the transfer of the backup data, such as a process of adding a header to the object.
[0073] Next, the data transfer program 2225 records the transferred transfer amount table in the object storage (step S308). Details of the transfer amount table are omitted, but it is a table that manages the history of the amount of data transferred so far for each destination bucket. Next, the data transfer program 2225 transfers the catalog and metadata created in step S305 (step S309). For example, the data transfer program 2225 may transfer the catalog and metadata to the object storage 400 as an object, or may transfer them to another storage means such as a database on the cloud 2. They may be stored as information in the object key of the object. For example, if the number of the protected volume or the like is used as the object key name, there is no need to store the protected volume number in the object.
[0074] Furthermore, the backup program 2224 that requested the data transfer program 2225 to transfer data monitors the lock set for the snapshot during data transfer to ensure that it does not expire, and extends the lock period if the lock expiration date falls within a certain period of time (step S306). This makes it possible to continue locking the snapshot even if the amount of difference is large or the transfer of backup data is delayed due to network trouble, etc.
[0075] After the processing of the data transfer program 2225 is completed, the backup program 2224 waits for the lock on the previous snapshot in the storage 200 to be released (step S310), and when the lock is released, it deletes the previous generation snapshot (step S311) and ends the processing (step S312). Note that the current snapshot is not deleted because it will be used in step S303 of the next backup process. In the example of Fig. 10, the backup program 2224 waits for the lock to be released and deletes the previous generation snapshot, but a different program may delete the previous snapshot at a different opportunity.
[0076] It is not necessary to delete all previous snapshots. If snapshots are left in the storage 200, the capacity consumed in the storage 200 increases, but the time required for restoring data can be reduced. For example, when restoring a snapshot acquired at 11:00 from the cloud 2, if the storage 200 has a snapshot at 9:00, the difference between 9:00 and 11:00 is acquired from the cloud 2. In contrast, if the storage 200 has a snapshot at 10:00, only the difference between 10:00 and 11:00 is acquired from the cloud 2, which reduces the amount of data transfer and reduces the time required for restoration. In addition, the process of transferring data in the storage 200 has been described using an example in which a program stored in the memory 215 executes the process. However, the RC I / F 212 may be the main body in transferring data stored in a volume to the cloud 2. In that case, the backup table 2211 may also be stored in a memory in the RC I / F, or information may be acquired from a table stored in the memory of the storage 200. Other divisions of roles are also possible, but the present invention is applicable regardless of these methods.
[0077] Although a lock was specified in step S307, if a lock has been set on the destination bucket itself, the lock specification in step S307 may be omitted. Also, if the lock period specified in step S307 is longer than the lock period set on the destination bucket, a lock may be specified in step S307. In that case, information indicating whether the bucket is already locked is stored in the backup table. Also, after the bucket setting program sets a lock on the bucket, it is notified that the lock has been set in order to update the backup table of storage 200. A step of checking whether the two snapshots 242 used in step S303 are locked may be added immediately before step S303. If the snapshots used in step S303 are not locked, an alert may be issued. If they are not locked, information as to whether the snapshots used for the backup were locked or not is added and stored in the backup data stored in steps S307 to S309. Information indicating the lock status of the snapshots used for the backup is stored in backup information 1001, which will be described later. If the snapshots were locked, "locked" is stored, and if the snapshots were not locked, "not locked", etc. is stored.
[0078] It is also possible to lock the snapshot in step S301, but not to lock the data transferred to the object storage in step S307. In this case, attacks on the object storage cannot be avoided, but attacks on the snapshot can be avoided. In other words, the level of security is improved compared to the conventional technology. Conversely, it is also possible not to lock the snapshot in step S301, but to lock only the data transferred to the object storage in step S307. In addition, the user may set whether or not to lock the data transferred to the object storage for each volume or consistency group. On the other hand, it is also possible to lock the data transferred to the object storage in step S307, and not lock in step S301. Also, the user may set whether or not to lock the snapshot for each volume or consistency group. By doing so, problems 1, 2, and 3 can be avoided.
[0079] FIG. 11 is a diagram showing an example of objects stored in the object storage 400 and data stored in the objects. In the example of Fig. 11, there are four types of objects: catalog 1000, backup information 1001, differential information 1002, and data 1003. Each object may be divided into multiple objects and stored. Also, the object configuration is one example, and other storage methods and object keys may be used. The present invention is applicable to any object configuration. An object key is information specified to extract an object.
[0080] The catalog 1000 shown in FIG. 11 has a volume number, a storage number, and acquired generation information. The volume number is an identification number that identifies the volume 241 to be protected. The storage number is an identification number that identifies a storage device having the volume 241 to be protected. The acquired generation information is information that is acquired for the volume number and that manages the generation information of the backup stored in the object storage 400. The catalog 1000 is updated every time a backup is acquired in the object storage 400. The object key for accessing the catalog 1000 may be the volume number, etc. By specifying the volume number, it is possible to acquire the generation information of the backup acquired for that volume.
[0081] Next, the backup information 1001 has a generation number, a volume number, a storage number, a time, and a type. The generation number is the generation number of the backup. The time is the time when this backup was obtained. The type is the type of backup process, for example, "full backup," "incremental backup," or "differential backup." The object key for accessing the backup information 1001 may be, for example, a volume number + generation number. The generation number is obtained by accessing the catalog 1000. Information indicating the lock status, indicating whether the backup data of the backup generation identified by the generation number was obtained with or without a lock on the snapshot 242, may also be stored.
[0082] Next, the differential information 1002 has differential data presence / absence information. The differential information 1002 has the information shown in FIG. 11 for each generation of backup of the volume to be backed up. The object key for accessing the differential information 1002 may be, for example, volume number+generation number+information indicating a differential information acquisition request. The differential data presence / absence information stores information indicating the presence / absence of differential information for each address of the volume to be backed up. "Differential data presence / absence information (address 0)" in FIG. 11 indicates whether data at address 0 of the volume to be backed up is included in data 1003, which will be described later. For example, it can be managed with 1-bit information. If the bit is 1, it indicates that it is stored, and if the bit is 0, it indicates that it is not stored.
[0083] Finally, data 1003 includes data. Data includes backup data itself. For example, in the differential information 1002, differential data of an address indicating that there is differential data is stored front-loaded. If information indicating that there is a difference is stored at addresses 0, 2, and 3 in the differential information 1002, data stored at addresses 0, 2, and 3 is stored front-loaded in the data 1003. By matching the information in the differential information 1002 with the data 1003, data at each address of the volume to be backed up can be extracted. The address is, for example, an LBA (Logical Block Addressing). The object key for accessing the data 1003 may be, for example, a volume number + generation number + information indicating a data acquisition request. The catalog information 1000 and backup information 1001 shown in FIG. 11 may be provided to the user as backup data information using the external management software 410 or the management terminal 270.
[0084] FIG. 12 is a diagram showing an example of the backup table 2211. 12, the backup table is information for managing the backup target volume, backup destination, backup schedule, and backup data lock setting. The backup table holds information on the volume number, object bucket, object lock setting, acquisition frequency, lock period, and backup retention period.
[0085] The volume number records the volume number of the backup target. An object bucket is information about object storage that stores backup data. The object lock setting is information that indicates whether or not to set a lock on the objects that make up the backup data stored in the object bucket. ON means that a lock is set. OFF means that a lock is not set. The lock period controls the period for which an object is locked. The acquisition frequency manages how often a backup is taken. Daily means that a backup is taken once a day. The time at which the backup is taken once a day may also be managed. The acquisition frequency may be a value input by the management software from the user.
[0086] The backup retention period manages the period for which the acquired backups are stored. In the example shown in the figure, a backup is acquired every week for Volume 1-1. Each acquired backup is stored in object storage for four weeks. This means that a four-week lock is set so that the backup cannot be deleted or rewritten. The lock period value may be stored as a value input by the management software from the user, or may be determined by the management software, etc. Information such as the backup retention period may be used to determine the lock period. Furthermore, to determine the lock period, the lock period may be calculated from the number of backups retained and the backup frequency. For example, input information is obtained from the user to obtain a backup once a week and to retain 10 backups. In this case, when the 11th backup is obtained, the first backup becomes unnecessary. The first backup is required for 10 weeks until the 11th backup is obtained. Therefore, 10 weeks is set as the lock period. The acquisition frequency, backup retention period, number of backups retained, etc. are called backup schedule information. Information on whether or not a lock is set may be managed for each bucket.
[0087] In the examples of Fig. 9 to Fig. 12, an object lock is set for an object. Some public cloud object lock functions can set a lock for a bucket, which is an area in which an object is stored. In this case, a lock may be set for the bucket. Also, a default lock period for locking objects stored in the bucket may be set for the bucket.
[0088] As shown in FIG. 13, the bucket setting program 2226 is a program for setting a lock on an object storage on a bucket-by-bucket basis.
[0089] The bucket setting program 2226 runs on a management terminal or external management software. It is also possible to run it on the storage 200, but as this is mainly for settings when creating buckets, it is preferable to set it using management software.
[0090] The bucket setting program 2226 acquires destination bucket information (step S400). This process can be realized by acquiring the value of the object bucket in the backup table 2211.
[0091] Next, the bucket setting program 2226 sets a lock on the acquired bucket (step S401). The shortest period among the lock periods managed by the backup table 2211 may be set as the lock period of the bucket.
[0092] A lock period may be set for a bucket only when the lock periods for all volumes to be backed up are the same. By doing so, lock setting for each object can be avoided, and the number of communications with the object storage can be significantly reduced.
[0093] In Fig. 13, a lock period is set for a created bucket stored in the backup table. However, a lock period may be set when creating a new bucket. For example, the following processes are performed: create a new bucket, set a lock period for the bucket to be created, notify the storage 200 of the created bucket information and the set lock period, and set the object bucket and object lock information in the backup table.
[0094] A method for extending the lock period of a snapshot in the storage 200 after detecting a cyber-attack has been described with reference to Fig. 5. Similarly, the lock period of an object transferred to and stored in the object storage 400 can also be extended.
[0095] FIG. 14 illustrates an example of a cyber-attack detection method in a configuration in which backup data is stored in an object storage 400. The object storage attack detection program is an example of a program that detects cyber attacks against object storage. The object storage attack detection program acquires the transfer amount history from the storage (step S500), and calculates the total transfer amount (step S501). Through this process, the amount of data stored in the object storage during the backup process is calculated. Next, the object storage attack detection program accesses the object storage and acquires the amount of data stored in the object storage (step S502). Next, the object storage attack detection program acquires the accumulated reduction amount of the object storage (step S503). The capacity acquired in steps S502 and S503 may be in bucket units, not in object storage 400 units.
[0096] Next, the object storage attack detection program detects cyber attacks by comparing the storage amount (the capacity stored in the object storage) with the transfer amount (the amount of data transferred to the object storage by the backup process) (step S504). In the object storage 400, there are cases where backups are deleted by user instructions. For this reason, specifically, the value obtained by subtracting the cumulative reduction amount from the transfer amount is compared with the storage amount. The formula is storage amount > (transfer amount - cumulative reduction amount). If the storage amount is greater than (transfer amount - cumulative reduction amount), it can be determined that a process other than the backup process has transferred data to the object storage. In other words, it can be said that there is a possibility of a cyber attack.
[0097] If step S504 is Yes, that is, if there is a possibility of a cyber attack, the object storage attack detection program issues an alert (step S505) and extends the lock period of the object (step S506). Step S506 makes it possible to prevent the lock period from ending and the lock from being released while the object is under cyber attack. If step S504 is No, steps S505 and S506 are skipped, and the process ends in step S507.
[0098] Step S506 does not need to extend the locks of all objects, but only extends the locks of objects whose remaining lock time is less than a certain number. Also, if there are multiple generations of backups of a certain volume, only the lock of the object of the newest generation may be extended. For example, if a volume has backup data of April 1, backup data of April 2, and backup data of April 3, only the lock of the object constituting the latest backup data of April 3 may be extended. Also, the lock period of the object constituting a predetermined number of backup data from the latest backup generation may be extended. When there are multiple backup data (snapshots) acquired at different times for the same volume (storage area), if the newest backup data remains in a locked state, it is possible to recover correct data from that backup data. On the other hand, if multiple locked data acquired at different times for the same volume (storage area) are left, unnecessary data cannot be deleted, and capacity will be wasted. For this reason, the lock period is set so that at least the newest locked backup data exists, that is, so that it is longer than the backup interval and the number of locked backup data is equal to or less than a predetermined number. Then, when a cyber attack is detected, the lock period is extended to maintain the state in which the newest locked backup data exists. By controlling in this way, it is possible to ensure the state in which normal data exists and delete unnecessary data as appropriate.
[0099] In step S506, instead of extending the lock period, the access control list for the object storage may be updated and access may be stopped. For example, access to the object storage may be stopped while the cause of the cyber attack is being investigated. Both the extension of the lock period for the object and the update of the access control list may be performed. When the object storage attack detection program detects a cyber attack, the process of FIG. 5 may be executed and the lock on the snapshot in the storage 200 may be extended.
[0100] Some object storages 400, even when an object lock is set, do not prohibit updates themselves, but rather manage the version of the object and leave the data before the update as the old version. In this case, writing to the object storage 400 does not result in an error, but the correct data is left as the old version. In particular, in the case of object storage with such specifications, there is a large discrepancy between the amount of storage and the amount of transfer, making it easy to detect cyber attacks. An object storage attack detection program may be applied only in the case of object storage 400 that manages versions. If data is compressed before transfer, the transferred capacity should be calculated taking this into account.
[0101] An example of a method for detecting a cyber-attack has been described with reference to FIG. 14. A cyber-attack can also be detected by other methods. The transfer amount used in FIG. 14 may be stored as information in the backup information 1001. The backup information 1001 is composed of a generation number, a volume number, a storage number, a time, a type, and a transfer amount. The transfer amount is the same as the data size of the backup generation. Therefore, when managing the backup size, there is no need to additionally manage the transfer amount. In this case, a cyber-attack can be detected using the total value of the storage amount of the object storage 400 and the transfer amount of the backup information 1001. A cyber-attack can be detected by only obtaining information from the object storage 400, without accessing the storage 200.
[0102] In the example of Fig. 14, it is assumed that the backup data stored in the object storage 400 is necessary backup data, and therefore the objects that make up this backup data are locked. However, it is also possible that old backup data that has exceeded the lock period has not been deleted and remains. Such backup data may be subject to cyber attacks.
[0103] If backup data in the object storage 400 is deleted due to a cyber attack, the transfer amount and the storage amount will differ, making it possible to detect the cyber attack. In this case, the storage amount will be smaller than the transfer amount, so in step S504 it is necessary to make a determination based on storage amount ≠ (transfer amount - reduction amount). When backup data is updated, the amount of data generally changes (increases or decreases), and this can be detected by determining whether or not the amount of storage is not equal to (amount of transfer - amount of reduction). Backup data is updated, but if the amount of data does not change, it cannot be detected because storage amount ≠ (transfer amount - reduction amount). To detect such cyber attacks, a checksum can be added to the backup data and a periodic check can be performed to see if the data has changed. Checksums can be added on an object-by-object basis, or on a backup data-by-data basis. In periodic checks, a predetermined number of checks can be performed by sampling, rather than checking all data.
[0104] A method for extending the lock period of an object after detecting a cyber-attack has been described with reference to Fig. 14. There are other cases where the lock period may be extended, such as when there is a delay in the data transfer process during backup from the storage 200 to the object storage 400. Backup delays can occur due to network failures, a large amount of backup data, and so on.
[0105] If the transfer of backup data is delayed, the lock period for the backup data (i.e., old generation backup data) stored in the object storage 400 may expire, and the lock may be released. If the delay is due to a network problem that takes a long time to recover from, there is a high possibility that all the locked backup data may be lost. To avoid this situation, when a delay detection program, an example of which is shown in FIG. 15, detects a delay in the transfer of backup data, it extends the lock period.
[0106] The delay detection program is an example of a program for detecting a delay in backup data from the storage 200 to the object storage 400. The delay detection program can run on any of the storage 200 , the management terminal 270 , and the external management software 410 .
[0107] The delay detection program acquires the difference amount extracted by the backup process in step S303 and the transferred capacity from the storage 200 (steps S900, S901). Next, the delay detection program calculates the progress of the backup process and the estimated completion date and time (steps S902, S903). The progress can be calculated by dividing the transferred capacity (obtained in step S901) by the difference (obtained in step S900). If the data is compressed before transfer, the transferred capacity is calculated taking this into account.
[0108] Next, the delay detection program determines whether there is any backup data for which the lock will be released before the date and time calculated in step S903 (step S904). If the answer is Yes in step S904, that is, if there is an acquired backup for which the lock will be released before the backup being processed is completed due to a backup delay, the delay detection program extends the lock on the object that constitutes the backup data until the date and time calculated in step S903 (step S905).
[0109] If step S904 is No, that is, if there is no acquired backup for which the lock will be released before the backup being processed is completed due to a backup delay, the process ends in step S906. In step S903, the estimated completion date and time may be calculated by linear interpolation, or may be calculated by another method. In step S905, a date and time may be set that is the date and time calculated in step S903 + α, where α is the number of days that will be a buffer in case the backup process is delayed again in the future. The objects for which the lock is extended may be limited by taking into consideration the number of backups held as described above. For example, if five backups are available and three backups are required to be held, steps S904 and S905 may be performed for the three newest backups acquired at the acquisition date and time.
[0110] In the case of a network device trouble or a line carrier trouble, it may not be possible to calculate the backup completion date and time in step S903. Specifically, this may occur when the actual network transfer volume is 0 MB / s and the estimated completion time is calculated to be infinity. In such a case, in step S905, the lock is extended for a fixed period of time (such as one week). Then, when the fixed period of time has elapsed (such as one week later), the delay detection program may be executed again. Furthermore, if the extended lock period is longer than a specified length (such as one month), the lock period may be extended by the specified length and the delay detection program may be executed again.
[0111] FIG. 16 is a diagram illustrating an example of a backup performance table. 16, the backup performance table manages the performance of transfer to the object storage. Using this transfer performance, the date and time when the backup process described above will be completed can be calculated. The backup performance table holds information on the volume number, object bucket, and transfer performance. The volume number records the volume number of the backup target. An object bucket is information about object storage that stores backup data. The transfer performance manages the performance results of the backup process for the volume identified by the volume number. The actual amount of data transferred may also be managed. EXAMPLES
[0112] In the first embodiment, a lock on a snapshot, a lock on an object, and a method of extending a lock (snapshot lock, object lock) when a predetermined condition is detected are described. In the second embodiment, a method of setting a lock period in the object storage 400 that is shorter than the lock period that should originally be set, and extending the set lock period if necessary is described. The lock period that should originally be set is, for example, a lock period specified by a user or a lock period stored in the lock period of a backup table. The reason why such a method is effective will be described.
[0113] Once a lock is set on the object storage 400, data cannot be deleted while the lock is in place. On the other hand, in the case of backup data, there are cases where a specific generation of backup becomes unnecessary and needs to be deleted. There are also cases where backup data needs to be migrated to another storage with lower costs. When an object is locked, the object cannot be deleted even if the backup of the unnecessary generation is deleted. Also, when backup data is migrated to another storage, the data that has been migrated and is no longer necessary cannot be deleted. In the case of object storage 400 provided as a storage service such as a public cloud, charges are incurred for unnecessary data that cannot be deleted. In the case of appliance-type object storage, storage capacity continues to be consumed by unnecessary data.
[0114] Hereinafter, the process of migrating backup data to another storage will be described with reference to Fig. 17. The process of deleting backup data of a specific generation will be described with reference to Fig. 18. The process of deleting an object that is no longer necessary will be described with reference to Fig. 19.
[0115] The data migration program shown in FIG. 17 is an example of a program for migrating an object stored in the object storage 400 to another storage. The data migration program receives a request to migrate backup data (step S700). At this time, it receives the backup information to be migrated (target volume and / or generation) and the migration destination information (in the case of another object storage, the object storage information and the destination bucket, etc.). When migrating multiple backup generations, the following process may be executed multiple times.
[0116] Next, the data migration program identifies the object to be migrated (step S701), and copies it to the migration destination (step S702). Finally, the object of the copy source is recorded as an unnecessary object (step S703), and the process ends (step S704).In step S703, the unnecessary object may be deleted after waiting for the lock to be released.
[0117] Step S701 will now be described. Step S701 is processed differently depending on the migration target. Possible migration targets include (a) all backups of all volumes, (b) a backup of a specific generation of a specific volume, and (c) all backups of a specific volume.
[0118] The case (a) will be explained. This case is used when changing the backup destination, etc. The catalog 1000, backup information 1001, differential information 1002, and data 1003 can all be copied to the migration destination. If backups acquired thereafter are also to be acquired at the migration destination, the object bucket of the backup table in the storage 200 may also be updated with the information on the migration destination storage.
[0119] Let us now consider the case of (b). For example, this is used when migrating backup data that is older than a certain period of time to cheaper storage. The data migration program uses the volume number and generation of the target backup received in step S700 to obtain differential information 1002. As described above, the object key of the differential information 1002 is information indicating a volume number + generation number + differential information acquisition request, and can be accessed using the information received in step S700. Next, the data migration program uses the volume number and generation of the target backup received in step S700 to obtain data 1003. As described above, the object key of data 1003 is information indicating a volume number + generation number + data obtainment request, and can be accessed using the information received in step S700.
[0120] The data migration program writes the acquired differential information 1002 and data 1003 to the migration destination storage. In order to access the backup of the migrated generation, it is necessary to manage the migration destination storage information. This can be achieved by storing the differential information 1002 and storage information for storing the data 1003 in the backup information 1001. The backup information 1001 will have fields for the generation number, volume number, storage number, time, type, and stored storage information. The migration destination object storage and bucket information are stored in the stored storage information.
[0121] The case of (c) will now be described. All backups of a specific volume can be migrated by executing the process shown in (b) for each generation of the specific volume. The data migration program can run on a virtual computer (VM) of cloud 2, in addition to external management software and a management terminal. It may also be realized by a service such as serverless provided by cloud 2. The unnecessary objects in step S703 are notified to the external management software and management terminal, and are managed by the external management software and management terminal. As described above, if the data migration program waits for the lock to be released and deletes the unnecessary objects, there is no need to manage the unnecessary objects. If the unnecessary objects are managed and deleted asynchronously with the data migration program, the object deletion program described below will delete the objects.
[0122] An example of a process for merging objects that make up a backup is shown in Figure 18. A case in which object merging is required is the deletion of a backup, and the example in Figure 18 shows a process for merging objects when a backup deletion is received.
[0123] The backup deletion program shown in FIG. 18 is a program for deleting backups, and the difference merge program is a program for merging objects. The backup deletion program and the difference merging program can run on external management software, a management terminal, or on a VM of cloud 2. This may be achieved by a service such as serverless provided by cloud 2. These two programs may run on different devices; for example, the backup deletion program may run on external management software, and the difference merging program may run on a service or VM of cloud 2.
[0124] Merging of objects will now be described. As explained with reference to FIG. 9, the backup method of the present invention stores in the object storage 400 only the differential data that occurs between backups.
[0125] For example, the backup on April 1st contains data from addresses 1, 2, and 3. The backup on April 2nd contains data from addresses 4, 5, and 6. The backup on April 3rd contains data from addresses 5 and 6. When restoring the data from April 3rd, the data from April 1st to 3rd is written in order from oldest to newest to the volume to which the data is restored. In other words, in order to restore the data from April 3rd, the data from April 1st and 2nd are also required. If all the data from April 2nd is deleted in conjunction with the deletion of the backup from April 2nd, the backup from April 3rd cannot be restored. The data from April 2nd required for the restoration from April 3rd is only the data from address 4. This is because the data from addresses 1, 2, and 3 are included in the backup from April 1st, and the data from addresses 5 and 6 are also included in the backup from April 3rd. From the above, when deleting the backup from April 2nd, the data from address 4 from April 2nd is merged into the backup data from April 3rd. This merging of objects is called a differential merge.
[0126] The backup deletion program receives a backup deletion request (step S600). At this time, it receives the volume number and generation to be deleted. Multiple generations may be specified. The backup deletion program starts the difference merge program and notifies it of information on the generation to be deleted and information on the generation to be merged with the differences. The generation to be merged with the differences will be the backup of the next generation after the backup generation to be deleted. In the example of Figure 18, generations 1 to 4 are deleted, and necessary data from generations 1 to 4 is merged into generation 5.
[0127] The difference merge program acquires difference information 1002 for each generation (generations 1 to 4 and generation 5 in the illustrated example) (step S601). Next, the difference merge program uses the difference information to identify data that will be necessary after merging (step S602). In the above example, the data at address 4 on April 2 is identified.
[0128] Next, the difference merge program reads the data of each generation, generates merged data (step S603), and stores the merged data (step S604). In the above example, data is generated by merging address 4 on April 2nd with addresses 5 and 6 on April 3rd, and stored. The object to be stored may be stored with the object key of generation 5. In other words, generation 5 may be overwritten. It may also be saved as a different object key. The difference merge program notifies the backup deletion program of the increase in capacity of generation 5 that accompanies the difference merging (step S605).
[0129] The backup deletion program records the objects that become unnecessary due to the deletion of the backup (step S606). This process is the same as that of step S703. Next, the backup deletion program records the increased capacity (step S607).
[0130] When merging objects, the increased capacity recorded in step S607 is added to the storage capacity determined in step S504. For this reason, it is recorded in step S607. Finally, the backup deletion program deletes the backup information 1001 of the backup target, updates the generation information of the catalog 1000 (step S608), and ends the process (step S609).
[0131] 19 shows an example of a process for deleting an object that is no longer necessary. An object that is no longer necessary means an object that was recorded as no longer necessary in step S606 or step S703 described above. The object deletion program deletes the object that is no longer necessary by instructing the object storage 400 or the like to delete the object.
[0132] The object deletion program can run on an external management software, a management terminal, or a VM of the cloud 2. It may also be realized by a service such as serverless provided by the cloud 2.
[0133] The object deletion program acquires a list of unnecessary objects (step S800). This is realized by acquiring the information recorded in steps S606 and S703.
[0134] Next, the object deletion program executes steps S801 to S804 for each acquired object. In step S801, the object deletion program determines whether or not the object can be deleted. Specifically, if the lock period of the object has ended, it is determined that the object can be deleted. On the other hand, if the lock period of the object has not ended, the object cannot be deleted.
[0135] If the result of step S801 is that deletion is not possible, the object deletion program skips steps S802 and S803 and ends the process (step S804). On the other hand, if the result of step S801 is that the object can be deleted, the object deletion program deletes the unnecessary object (step S802), adds the size of the deleted object to the cumulative deletion capacity (step S803), and ends the process (step S804).
[0136] Management of unnecessary objects can be achieved, for example, by adding unnecessary generation information to the catalog 1000. In this case, the catalog 1000 is composed of a volume number, a storage number, acquired generation information, and unnecessary generation information. The object deletion program can periodically access the catalog 1000 and identify unnecessary generations. Once an unnecessary generation is identified, the unnecessary objects can be deleted by deleting the backup information 1001, differential information 1002, and data 1003 of the unnecessary generation. In steps S606 and S703, the unnecessary generation information or unnecessary object information may be recorded in a management terminal, external management software, or another database.
[0137] When a long-term lock is set for the object storage 400, it takes a long time for the object that is no longer needed in FIG. 17 or FIG. 18 to be deleted by the object deletion program in FIG. Therefore, a method will be described in which a lock period shorter than the lock period that should be set is set in the object storage 400, and the set lock period is extended if necessary.
[0138] FIG. 20 is an example of a lock management table for managing the lock period that should be set and the lock period that has actually been set in the object storage 400. In FIG. The lock management table manages the volume number, the backup generation, the requested lock period, the set lock period, and the necessity.
[0139] The volume number records the volume number of the backup target. The backup generation is generation information of the backup for the volume identified by the volume number. The requested lock period is information indicating the period during which the backup needs to be locked. Specifically, it manages the date information on which the lock may be released. The requested lock period may store a value input by the management software from the user, or may be determined by the management software, etc. The set lock period manages the lock period that is actually set for the object storage 400.
[0140] In the example of Fig. 20, a lock is required until 3pm on September 30th. Meanwhile, a lock has already been set for the object storage 400 until 3pm on April 25th. Then, as 3pm on April 25th approaches, the lock period is extended as necessary. The process of extending the lock period will be described with reference to Fig. 21.
[0141] Necessity is an example of information for managing unnecessary generations, as described with reference to FIG. 19. It indicates whether or not a backup specified by the volume number and backup generation is necessary. In step S703 in FIG. 17 and step S606 in FIG. 18, the value of "necessity" is set to "unnecessary." In FIG. 17 and FIG. 18, unnecessary objects are recorded, but in the examples of FIG. 17 and FIG. 18, all objects constituting the backup data of a specific generation become unnecessary, so that the necessity of objects can be managed for each backup generation. The necessity of objects for each backup generation can be managed by "necessity" in the lock management table. Necessity can also be managed for each object. For example, this can be achieved by list management of the object keys of unnecessary objects.
[0142] The lock management table is stored in external management software, a management terminal, or a database service provided by cloud 2. Since the object deletion program mentioned above refers to the table, storing the table in the same device as the device on which the object deletion program runs minimizes communication between devices, which is efficient.
[0143] FIG. 21 shows an example of a program for extending the lock period set for the object storage 400. The lock period extension program can run on a VM in cloud 2, in addition to external management software and a management terminal. It may be realized by a service such as serverless provided by cloud 2. Since the lock period extension program may be subject to cyber attacks, the lock period extension program may be executed in a data center other than data center 1 and cloud 2. In cloud 2, it may be operated in a logically isolated environment.
[0144] The lock extension program acquires the lock period that is actually set for the object storage 400 (step S1000). This process is realized by acquiring the already-set lock period from the lock management table.
[0145] Next, the lock extension program determines whether the lock end date and time acquired in step S1000 is within a certain number of days (step S1001). For example, whether it is within five days. In other words, the lock extension program determines whether the set lock period is within a certain range before expiration. This process is realized by comparing the date and time when the lock will be released with the current date and time. If the result of step S1001 is "No", that is, if there are a certain number of days or more until the lock is released, the lock extension program ends the process (step S1004).
[0146] On the other hand, if the result of step S1001 is "Yes", that is, if the number of days until the lock is released is less than the fixed number, the lock extension program judges whether to extend the lock or not (step S1002). The requested lock period is compared with the set lock period, and if the requested lock period is a future date and time, the lock may be extended. In other words, if the expiration of the set lock period is earlier than the expiration of the requested lock period, the lock extension program may extend the set lock period. In addition to this condition, if the target object is necessary for backup, it is judged that the lock period should be extended. Since unnecessary objects have been recorded in steps S703, S606, and S802, if they are not recorded in these steps, the lock period is extended.
[0147] If the result of step S1002 is "No", that is, if the lock period does not need to be extended, the lock extension program ends the process (step S1003). On the other hand, if the result of step S1002 is "Yes", that is, if the lock period needs to be extended, the lock extension program extends the lock period (step S1003), and ends the process (step S1004).
[0148] The period extended in step S1003 may be any period. For example, it may be one week. This may be determined based on the cycle in which the lock extension program is executed. It may also be determined from the requested lock period and the number of extensions. For example, if the requested lock period is 10 months and the number of extensions is 10, it may be updated in monthly units. Depending on the object storage 400, there may be an upper limit on the number of extensions. In that case, it is preferable to determine the period based on the requested lock period and the number of extensions as described above.
[0149] When the extension period is decided, the date and time is controlled so that it is not later than the requested lock period. For example, when extending by one week, if the date and time is later than the requested lock period, the requested lock period is set to the extended date and time.
[0150] The lock extension is executed for each object that constitutes the backup data. If the backup data is composed of multiple objects, the lock extension is instructed for each object in turn. EXAMPLES
[0151] In the first and second embodiments, a configuration of only the data center 1 or a configuration in which the data center 1 and the cloud 2 cooperate with each other is described as an example. In the third embodiment, a configuration of only the cloud 2 is described. The object storage 400 is utilized in the cloud 2, including a public cloud. For example, data of a software-defined storage (Software Defined Storage, SDS) operating in the cloud 2 is backed up to the object storage 400. Another possible example is moving low-frequency access data of the SDS to the object storage 400. Even if the security of the SDS itself is strong, the data placed in the object storage 400 may be accessed using the access method of the object storage 400 without going through the SDS. For this reason, it is necessary to lock the data stored in the object storage 400.
[0152] Fig. 22 is a diagram showing a configuration example of the storage 500. The storage 500 shown in Fig. 22 is constructed by SDS operating on a public cloud. However, the storage 500 may have hardware for performing specific processing and the like. Examples of this type of hardware include hardware for compressing data and hardware for encrypting data. The storage 500 may be storage provided as a service.
[0153] 22, the storage 500 is communicably connected to a management server 501 via a network 502. The storage 500 also includes a plurality of storage servers 503 and a plurality of cloud storages 507 configuring a volume 509. The storage server 503 is configured from a physical server, a virtual machine, a container, or the like. The storage server 503 also has a communication port 504, a memory 505, and a CPU 506. The communication port 504 is communicatively connected to the management server 501 via a network 502. The communication port 504 is also connected to the object storage 400. The communication port 504 may also be connected to a server that executes an application. The server is also configured from a physical server, a virtual machine, a container, or the like. Data used in services such as databases and computing provided by the public cloud may be stored.
[0154] The memory 505 records a program that defines the operation of the CPU 506, and control information used in the program. The CPU 506 is a processor that reads the program recorded in the memory 505, executes the read program, and executes various processes. In this embodiment, the CPU 506 of each storage executes a program to realize the function of the storage. The CPU 506 receives an I / O request from a server that executes the above-mentioned application, and writes and reads data to and from the cloud storage 507 in accordance with the I / O request.
[0155] Cloud storage 507 is a storage area of storage server 503. A storage area may be created using a public cloud storage service and installed in storage server 503 as cloud storage 507. A volume 509 may be configured across multiple cloud storages 507 and provided to the server. Note that data written to the volume may be made redundant among multiple cloud storages 507. The method of making the data redundant is not particularly limited, but may be, for example, a method using data duplication or a method using erasure coding.
[0156] The configuration of the storage 500 shown in FIG. 22 is merely an example, and is not limited thereto. For example, the storage 500 may have the same configuration as the storage 200. Each storage server 503 may be installed across multiple areas (such as a data center, a partition that ensures availability, or a partition (tenant, etc.) that is logically divided for each purpose or user) that can operate and be run independently. The storage 500 and the server may be installed across multiple areas (such as a data center, a partition that ensures availability, or a partition (tenant, etc.) that is logically divided for each purpose or user). The storage 500 and the server may be installed on different clouds, or may be on a cloud service provided by another vendor on a public cloud vendor.
[0157] The management server 501 is a management device for managing and maintaining the secondary storage 500. The management server 501 has a memory 501a and a CPU 501b. The memory 501a records a program that defines the operation of the CPU 501b, and various information used by the program. The CPU 501b is a processor that reads the program recorded in the memory 501a, executes the read program, and executes various processes. The functions of the management server 501 may be realized by any of the storage servers 503.
[0158] When the storage 500 operating in the cloud 2 backs up data stored in the storage 500 to the object storage 400, the method of locking the object in the object storage 400 is the same as the method described in the first and second embodiments. The storage 200 is the storage 500, and the data center 1 is the cloud 2. The storage 500 has a backup program, a data transfer program, and other programs and tables that the storage 200 has among the necessary tables.
[0159] A method for locking an object in the object storage 400 when part of the data stored in the storage 500 operating in the cloud 2 is stored in the object storage 400 will be described. This example can also be applied to the case where part of the data stored in the storage 200 is stored in the object storage 400. However, considering that the distance between the data center 1 and the cloud 2 is long and the access time is long, a configuration in which part of the data stored in the storage 500 is stored in the object storage 400 is considered to be more common.
[0160] The hierarchical control function for moving low-frequency access data of the SDS to the object storage 400 will be described below with reference to FIGS. 23 to 28.
[0161] The hierarchical control function uses information on the frequency of access to data to determine and change the storage destination of data. It is common to move data in units of finer granularity than in units of volumes. The basic structure, such as the unit of data movement, will be explained using Fig. 23. Fig. 23 explains movement in units smaller than volumes called pages, but the present invention can also be applied when moving in volume units.
[0162] FIG. 23 is a diagram illustrating the relationship between the volume 509, the capacity pool 290, the pool volume 291, and the cloud storage 507. The storage 500 creates a pool volume 291 from the storage areas of multiple cloud storages 507. The capacity pool 290 includes one or more pool volumes 291. The pool volume 291 includes pages 292, which are physical storage areas that serve as units of allocation to the volumes 509. The capacity of the pages 292 is, for example, several KB to several tens of MB.
[0163] When data is written to a storage area in volume 509, storage 500 allocates a page 292 in pool volume 291 to that area. That is, since a page 292 is not allocated to an unused area of volume 509, the storage area of cloud storage 507 is not consumed. A page, which is a physical storage area, may be created in cloud storage 507. In that case, pool volume 291 becomes unnecessary. In that case, a pool table, which will be described later, manages the addresses of cloud storage 507 as a start address and an end address.
[0164] FIG. 24 shows an example of a pool table. The pool table is a table for managing each page 292 in the capacity pool 290, and is stored in the control information section of the memory of the storage 500, for example. The pool table manages records (entries) that associate fields of page number, start address, end address, status, and allocation destination. The page number stores a page number that identifies a page 292 in the capacity pool 290. The start address and end address are used to identify the area of the page 292. This address is an address that manages the entire capacity pool 290. Naturally, the area of the page 292 may be managed by a pool volume number and an address within the pool volume. If the page size is fixed length, the end address is not necessary.
[0165] The start address stores the start address of the corresponding page 292. The end address stores the end address of the corresponding page 292. The status stores information indicating whether the corresponding page 292 has been allocated to the volume 509 or is unallocated. The allocation destination stores the volume number to which the corresponding page 292 has been allocated. According to the top record of the pool table, it can be seen that the page with page number "1" has a start address of "0", an end address of "99", and has been allocated to the volume 509 with a volume number of "1". A table for managing unallocated page numbers may be provided. In that case, it becomes possible to search for unallocated pages at high speed.
[0166] FIG. 25 shows an example of a volume table. The volume table is a table that manages the allocation of pages 292 to volumes 509, and is stored in the control information section of the memory of the storage 500, for example. The volume table 225 manages records including fields for volume number, address, page allocation status, page number, read frequency (times / hr), and write frequency (times / hr). The address range within the volume 509 is divided into areas of the same size as the pages 292. One record indicates one area. This area may also be called a virtual page.
[0167] The volume number stores a volume number for identifying the volume 509. The address stores a range of addresses in the corresponding volume 509. The page allocation status stores information indicating whether a page has been allocated to the area indicated by the corresponding address range. Here, the page allocated to the area may correspond to a page 292 in the capacity pool 290, or may not correspond to a page 292 in the capacity pool 290. The page number stores the page number of the page allocated to the area, or an identifier indicating that the page allocated to the area does not correspond to a page 292 in the capacity pool 290. When the data stored in the area is physically stored in the capacity pool 290, the page number stores the number of the page 292 in the capacity pool 290. When the data stored in the area is not physically stored in the capacity pool 290 but is stored in the object storage 400, the page number stores information indicating the object storage 400, such as object storage information and bucket information, instead of the page 292 in the capacity pool 290.
[0168] The read frequency (times / hr) stores the number of reads issued per unit time for the corresponding area. The write frequency (times / hr) stores the number of writes issued per unit time for the corresponding area. In this example, the unit time is one hour, but it could also be one day, one minute, or one second. The storage 500 measures the access frequency (read frequency and write frequency) of each area and updates the volume table.
[0169] According to the top record of the volume table, page 292 with page number “2” is allocated to the address area 0 to 99 of volume 509 with volume number “1”, and it can be seen that the read frequency and write frequency are higher than those of other addresses.
[0170] FIG. 26 is an example of a flowchart of a tiering program for storing low-frequency access data (cold data) stored in the storage 500 in the object storage 400 and storing high-frequency access data (hot data) in the storage 500. The tiering program calculates the optimal data storage layout based on the change in IO frequency information, and launches a demotion program and a promotion program that actually change the data placement. Note that changing the data storage location in association with a change from hot data to cold data is called demotion. Furthermore, changing the data storage location in association with a change from cold data to hot data is called promotion. The tiering program is executed periodically within the storage 500. For example, if the data placement review frequency is once per hour, the tiering program is launched once per hour. The data placement review frequency can be set by a user or a storage administrator via a management server or the like.
[0171] First, the tearing program acquires IO frequency information for each area of the volume 509 from the volume table (step S3000), and calculates the optimal allocation of data using the IO frequency information (step S3001). Next, the tearing program compares the optimal allocation with the current allocation, and determines the data to be promoted and the data to be demotion (steps S3002 and S3003).
[0172] As an example of placement decision, the tiering program arranges each area of the volume 509 in order of highest IO frequency. Next, the tiering program derives an IO frequency threshold for distinguishing between Hot Data and Col Data from the capacity of the capacity pool 290 of the storage 500, and decides which area of data should be stored as Hot Data in the capacity pool of the storage 500.
[0173] Then, the tearing program identifies data to be promoted, excluding data already stored in the capacity pool 290. Similarly, the tearing program identifies data that is already stored in the capacity pool 290 and cannot be put into the capacity pool 290, as data to be demotion.
[0174] The tearing program's steps from step S3004 onwards are explained below. The tearing program specifies the demotion target and calls the demotion program (step S3004). Finally, the tearing program 511 specifies the promotion target, calls the promotion program, and ends the process (step S3005). The capacity of the storage 500 is often smaller than the capacity of the object storage 400. In order to create free pages in the capacity pool 290, the tearing program basically executes the demotion program first. When promoting and demotion multiple pieces of data, the hot data storage area can be used effectively by alternately executing demotion and promotion.
[0175] According to the tiering program, the storage 500 classifies each area into either a first group or a second group based on the access frequency of each area, and allocates pages associated with the capacity pool 290 to areas classified into the first group, and allocates pages not associated with the capacity pool 290 to areas classified into the second group. The first group, for example, is an area corresponding to hot data. The second group, for example, is an area corresponding to cold data. This makes it possible to prevent a decrease in the performance of access to data stored in the storage 500, and also to conserve the capacity of the storage 500.
[0176] FIG. 27 is an example of a flowchart of a demotion program. The demotion program is called from the tearing program and executed in the storage 500. First, the demotion program receives a demotion instruction (step S4000). At this time, the demotion program receives as parameters the area in one or more volumes 509 to be demotioned (area identified by a volume number and an address in the volume).
[0177] In this embodiment, the demotion program receives multiple area information and processes multiple areas. However, the demotion program may have a function for performing demotion of one area, and the tearing program may call the demotion program multiple times.
[0178] Next, the demotion program selects one unprocessed area from among the demotion targets (step S4001), and transfers the data stored in that area to the object storage 400 (step S4003). At this time, the data transfer program specifies the lock of the object to be transferred. Next, the demotion program records the transfer amount table transferred to the object storage (step S4004). This process is the same as steps S307 and S308 described using the data transfer program.
[0179] Next, the demotion program updates the volume table of the volume 509 that is using that area (step S4005). Specifically, the demotion program stores the object storage information and bucket information in the page number. After the change, the demotion program releases the area of the capacity pool 290 that stored the hot data (step S4006).
[0180] Next, the demotion program checks whether all the specified areas have been processed (step S4007). If all the specified areas have been processed, the demotion program ends the process (step S4008). On the other hand, if there are unprocessed areas remaining, the demotion program returns to S4001 and executes steps S4001 to S4006 for the next unprocessed area.
[0181] FIG. 28 is an example of a flowchart of a promotion program. The promotion program is called from the tearing program 511 and executed in the storage 200 . First, the promotion program receives a promotion instruction (step S5000). At this time, the promotion program receives as parameters the areas in one or more volumes to be promoted (areas identified by volume numbers and addresses in the volumes).
[0182] Next, the promotion program selects one unprocessed area from among the promotion targets (step S5001), and reserves an area in the capacity pool 290 to store that area (step S5002). Specifically, the promotion program updates the status 224d and allocation destination of the pool table 224. The promotion program also updates the page number 225d of the volume table 225.
[0183] Next, the promotion program issues a read request to the object storage 400, reads the target data, and stores it in the area secured in step S5002 (step S5003).
[0184] The promotion program then records the source object as an unnecessary object (step S5004). In step S5004, the unnecessary object may be deleted after waiting for the lock to be released. In the examples of Figs. 17, 18 and 20, the unnecessary object is recorded by changing the "necessary" value in the lock management table to "unnecessary". In the case of hierarchical control, the entire backup data does not become unnecessary as shown in Figs. 17, 18 and 20. For this reason, the necessity is managed for each unnecessary object. For example, this can be achieved by managing the object keys of the unnecessary objects in a list.
[0185] The page number 225d of the volume table 225 stores the page number of the pool volume 291. This data is to be stored by the storage 500 in the cloud storage 507 mounted on the storage 500. Next, the promotion program checks whether all the designated areas have been processed (step S5005). If all the designated areas have been processed, the promotion program ends the processing (step S5006). On the other hand, if unprocessed regions remain, the promotion program returns to step S5001 and executes steps S5001 through S5005 for the next unprocessed region.
[0186] In hierarchical control, it is difficult to determine the lock period because the access frequency of data changes. If a long-term lock is set, but the access frequency increases and the data is promoted to the storage 500, the object will remain in the object storage 400 for a long period of time without being deleted. For this reason, it is desirable to set a short lock period as shown in Figs. 20 and 21 and extend the lock periodically. The difference from Figs. 20 and 21 is that there is no requested lock period. It is considered that the data stored in the object storage 400 should be locked until the volume is deleted and the data itself becomes unnecessary. In other words, the requested lock period is until the data becomes unnecessary. Therefore, it is possible to refer to only the set lock period and periodically extend the lock period.
[0187] In the above explanation, the locking when low-frequency data is moved to the object storage 400 is explained using the hierarchical control as an example. However, in the snapshot function explained in the storage 200, the present invention can also be applied to a case where data that is referenced only from snapshots is stored in the object storage 400. That is, instead of identifying low-frequency access data and moving it to the object storage 400, data that is referenced only from snapshots may be moved to the object storage 400.
[0188] The present invention can also be applied to a case where all data is basically stored in the object storage 400, and some data is stored in the cache of the storage 500 or in the cloud storage 507. In addition to the cache and cloud storage 507, in the case of a public cloud, an instance store of the storage server 503 may also be used.
[0189] Most of the data stored in the object storage 400 is locked and the lock period is periodically extended. The lock period is periodically extended until the object becomes unnecessary due to the deletion of a volume or updating of data. When the storage 500 stores data using a log structure, data that is not referenced by any volume occurs due to data updates. In such cases, the data becomes unnecessary even if the volume is not deleted, so there is no need to extend the lock.
[0190] FIG. 29 shows the programs and control tables stored in the memory 505 of the storage 500, and the programs and control tables stored in the management server 501. A hierarchical control program, a promotion program, a demotion program, a pool table, and a volume table are stored in the memory 505. These programs and tables have been described above with reference to the figures. A lock extension program and an unnecessary object table are stored in the management server 501. These programs and tables have already been explained using the figures above.
[0191] In this manner, data stored in the object storage 400 can be locked and stored safely.
[0192] As described above, the disclosed storage is a storage 200 equipped with a processor 216 that processes data to be stored in a storage device (220) and connected to another storage (400) via a network, in which the processor 216 obtains a first snapshot of a volume generated using the storage area of the storage device, compares the first snapshot with a second snapshot which is a previously obtained snapshot, extracts incremental data, transfers the incremental data to the other storage, stores it as backup data, and sets a lock on the backup data stored in the other storage. This allows data to be stored more safely.
[0193] Furthermore, the processor 216 sets a lock on the first snapshot and the second snapshot when the processor 216 acquires the first snapshot and the second snapshot. This means that even if the snapshot before transfer is subjected to a cyber attack, or if the object storage is subjected to a cyber attack, data can be restored to normal.
[0194] Furthermore, when the processor 216 detects the cyber-attack, it extends the lock period of the backup data transferred to the other storage. The lock also prohibits the deletion and overwriting of the data that is the subject of the lock. This prevents backup data from becoming a new target for attack if it is unlocked, and ensures that healthy data is maintained.
[0195] As an example, the processor 216 calculates the lock period to be set for the first snapshot when the first snapshot is acquired, from backup schedule information previously set by the user. As an example, the processor 216 determines the lock period to be set for the backup data by calculating the lock period designated in advance by the user, or the number of backups to be retained and the backup frequency designated by the user. As an example, the processor 216 may raise an alert if the first snapshot and the second snapshot are not locked. As an example, the processor 216 determines whether or not a lock needs to be set for the snapshot and the backup data based on a lock target designated by a user. This prevents the lock from being released due to a transfer delay or the like, which could result in the data becoming the target of an attack, and ensures that normal data is preserved.
[0196] In addition, the processor 216 calculates the total transfer amount of data transferred to the other storage, obtains the storage amount of the transferred data in the other storage, and detects that a cyber attack has occurred if there is an inconsistency between the total transfer amount and the storage amount. Furthermore, when the processor 216 detects the cyber-attack, it extends the lock period of the backup data transferred to the other storage. This enables accurate detection of cyber attacks and protects backup data.
[0197] In addition, the processor 216 sets a lock period for the backup data that is shorter than the requested lock period, which is a lock period specified by the user, and extends the lock period if the set lock period is within a specified range before expiration and the target backup data has not become unnecessary, and if the expiration of the lock period is earlier than the expiration of the requested lock period. Furthermore, after the transfer of the backup data to the other storage is completed, the processor 216 waits for the unlocking of backup data that is older than the transferred backup data, and then deletes the data. As an example, when the other storage receives an instruction to delete the backup data, it identifies and records objects that will become unnecessary due to the deletion of the backup data, monitors the identified objects for being unlocked, and deletes the identified objects when the lock on the objects is released. This makes it possible to avoid a situation in which unnecessary backup data remains. In addition, the other storage is a storage located in a cloud, and the storage connected to the other storage is a storage located on-premise. Therefore, when on-premise data is stored in the cloud, the data can be protected.
[0198] The above-mentioned embodiments of the present disclosure are illustrative examples of the present disclosure, and are not intended to limit the scope of the present disclosure to only those embodiments. A person skilled in the art can implement the present disclosure in various other forms without departing from the scope of the present disclosure. [Explanation of symbols]
[0199] 1: Data center 2: Cloud 100: Server 200: Storage 210: Controller 211: I / F 212: I / F 213: Management I / F 214: I / F 215: Memory 216: Processor 217: Volume 220: Physical drive 221: Control information 222: Program 223: Cache unit 230: Management network 270: Management terminal 271: Management port 272: Input / output unit 273: Memory 274: CPU 300: Network 400: Object storage
Claims
1. A storage device comprising a processor for processing data to be stored in a storage device, the storage device being connected to other storage devices via a network, The processor, obtaining a first snapshot of a volume generated using a storage area of the storage device; extracting incremental data by comparing a second snapshot, which is a previously acquired snapshot, with the first snapshot; Transferring the incremental data to the other storage and storing it as backup data; Locking the backup data stored in the other storage device A storage device comprising:
2. The storage according to claim 1 , The storage device according to claim 1, wherein the processor sets a lock on the first snapshot and the second snapshot when the first snapshot and the second snapshot are acquired.
3. The storage according to claim 2, The storage is characterized in that the lock prohibits deletion and overwriting of the data that is the subject of the lock.
4. The storage according to claim 3 , The storage device is characterized in that the processor calculates the lock period to be set for the first snapshot when the first snapshot is obtained from backup schedule information previously set by the user.
5. The storage according to claim 3 , The storage device is characterized in that the processor determines the lock period to be set for the backup data by calculating either a lock period specified in advance by the user or the number of backups to be retained and the backup frequency set by the user.
6. The storage according to claim 3 , The storage device according to claim 1, wherein the processor issues an alert if the first snapshot and the second snapshot are not locked.
7. The storage according to claim 3 , The storage device is characterized in that the processor determines whether or not a lock needs to be set for the snapshot and the backup data based on a lock target designated by a user.
8. The storage according to claim 1 , The processor, Calculating a total amount of data transferred to the other storage device; Obtaining the amount of the transferred data stored in the other storage device; When the total transfer amount and the storage amount are inconsistent, it is detected that a cyber attack has occurred. A storage device comprising:
9. The storage device according to claim 8, The storage is characterized in that the processor extends the lock period of the backup data transferred to the other storage when the cyber attack is detected.
10. The storage according to claim 1 , The processor sets a lock period for the backup data that is shorter than a requested lock period, which is a lock period specified by a user, and when the set lock period is within a specified range before expiration and the target backup data is not no longer necessary, extends the lock period if the expiration of the lock period is earlier than the expiration of the requested lock period.
11. The storage according to claim 1 , The storage device according to claim 1, wherein, after the transfer of the backup data to the other storage device is completed, the processor waits for backup data that is older than the transferred backup data to be unlocked, and then deletes the data.
12. The storage device according to claim 11, When the other storage receives the instruction to delete the backup data, Identifying and recording objects that become unnecessary due to the deletion of the backup data; Watch for the identified objects to be unlocked, When a specified object is unlocked, the object is deleted. A storage device comprising:
13. The storage according to claim 1 , the other storage is a storage located in a cloud; The storage connected to the other storage is characterized in that the storage is located on-premise.
14. 1. A data protection method for a storage device connected to another storage device via a network, the method comprising: The processor, obtaining a first snapshot of a volume generated using a storage area of the storage device; extracting incremental data by comparing a second snapshot, which is a previously acquired snapshot, with the first snapshot; Transferring the incremental data to the other storage and storing it as backup data; Locking the backup data stored in the other storage device A data protection method for storage comprising:
Citation Information
Patent Citations
Storage system, computer system and control method
JP2023001471A
Method and system for blocking ransomware or phishing attacks
JP2023503760A
Method for protecting data in hybrid cloud
JP2021149773A