CN113467989A - Snapshot creating and reading method, equipment and storage medium - Google Patents

Snapshot creating and reading method, equipment and storage medium Download PDF

Info

Publication number
CN113467989A
CN113467989A CN202010245187.7A CN202010245187A CN113467989A CN 113467989 A CN113467989 A CN 113467989A CN 202010245187 A CN202010245187 A CN 202010245187A CN 113467989 A CN113467989 A CN 113467989A
Authority
CN
China
Prior art keywords
snapshot
data
incremental
data block
key used
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010245187.7A
Other languages
Chinese (zh)
Inventor
廖武钧
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN202010245187.7A priority Critical patent/CN113467989A/en
Publication of CN113467989A publication Critical patent/CN113467989A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1448Management of the data involved in backup or backup restore
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services

Abstract

The embodiment of the application provides a snapshot creating and reading method, equipment and a storage medium. In the snapshot creating process provided by the embodiment of the application, if the incremental snapshot to be created needs to depend on the data block in the historical snapshot, in the metadata of the incremental snapshot to be created, not only the position index of the data block in the historical snapshot on which the incremental snapshot to be created depends is recorded, but also the data key used by the historical snapshot is recorded to decrypt the data block in the historical snapshot on which the incremental snapshot to be created depends, so that the incremental snapshot can be created after the key rotation without creating a full number of snapshots, time consumed for creating the snapshot can be reduced, and the creating speed can be increased.

Description

Snapshot creating and reading method, equipment and storage medium
Technical Field
The present application relates to the field of data storage technologies, and in particular, to a snapshot creating and reading method, a snapshot creating and reading device, and a storage medium.
Background
The disk snapshot is mainly used for backup and disaster recovery. A user can create a plurality of snapshots on a disk at different time points to form a snapshot chain. Existing snapshot creation typically employs an incremental snapshot technique, i.e., a block of data in an old snapshot may be referenced in a new snapshot.
In an encrypted storage scenario, in order to improve data security, a key needs to be rotated, and keys used by new and old snapshots are inconsistent before and after key rotation. However, key rotation requires: after the disk key is replaced, the new key is used to completely decrypt the data block in the whole new snapshot.
Therefore, in the prior art, the first snapshot after the key rotation does not depend on any old snapshot, but directly creates a full snapshot, and all data blocks of the snapshot can be decrypted by using the new key after the key rotation. However, the data volume of the full snapshot is large, and the snapshot creation takes longer and is slow.
Disclosure of Invention
Aspects of the present application provide a snapshot creating and reading method, a device, and a storage medium, so as to reduce time consumption for creating a snapshot and improve a creating speed.
The embodiment of the application provides a snapshot creating method, which comprises the following steps: determining an incremental data block required by an incremental snapshot to be created and a target data block in a target historical snapshot which needs to be relied on according to metadata of a data storage space; recording position indexes of an incremental data block and a target data block and a data key used by a target historical snapshot in metadata of an incremental snapshot to be created so as to decrypt the target data block in snapshot reading; and storing the incremental data block into a snapshot storage space according to the position index of the incremental data block to obtain a new incremental snapshot.
An embodiment of the present application further provides a snapshot reading method, including: determining a snapshot to be read and a data block to be read in the snapshot; if the data block to be read is a data block in the historical snapshot on which the snapshot to be read depends, acquiring a data key used by the historical snapshot from metadata of the snapshot to be read; and decrypting the data block to be read by using the data key used by the historical snapshot, and returning the decrypted original data to the snapshot user.
An embodiment of the present application further provides a snapshot management apparatus, including: a memory and a processor; a memory for storing a program; a processor coupled with the memory for executing a program for: determining an incremental data block required by an incremental snapshot to be created and a target data block in a target historical snapshot which needs to be relied on according to metadata of a data storage space; recording position indexes of an incremental data block and a target data block and a data key used by a target historical snapshot in metadata of the incremental snapshot to be created; and storing the incremental data block into the snapshot storage space according to the position index of the incremental data block.
An embodiment of the present application further provides a snapshot management apparatus, including: a memory and a processor; a memory for storing a program; a processor coupled with the memory for executing a program for: determining a snapshot to be read and a data block to be read in the snapshot; if the data block to be read is a data block in the historical snapshot on which the snapshot to be read depends, acquiring a data key used by the historical snapshot from metadata of the snapshot to be read; and decrypting the data block to be read by using the data key used by the historical snapshot, and returning the decrypted original data to the snapshot user.
Embodiments of the present application further provide a computer-readable storage medium storing a computer program, where the computer program can implement the steps in the snapshot creating and reading method when executed.
In the snapshot creating process provided by the embodiment of the application, if the incremental snapshot to be created needs to depend on the data block in the historical snapshot, in the metadata of the incremental snapshot to be created, not only the position index of the data block in the historical snapshot on which the incremental snapshot to be created depends is recorded, but also the data key used by the historical snapshot is recorded to decrypt the data block in the historical snapshot on which the incremental snapshot to be created depends, so that the incremental snapshot can be created after the key rotation without creating a full number of snapshots, time consumed for creating the snapshot can be reduced, and the creating speed can be increased.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a schematic structural diagram of a snapshot management system according to an exemplary embodiment of the present application;
FIG. 2a is a schematic structural diagram of a data storage space according to an exemplary embodiment of the present application;
FIG. 2b is a schematic structural diagram of a snapshot storage space according to an exemplary embodiment of the present application;
FIG. 2c is a diagram illustrating a structure of snapshot metadata according to an exemplary embodiment of the present application;
FIG. 2d is a block diagram illustrating another example of snapshot metadata according to an exemplary embodiment of the present application;
FIG. 2e is a schematic structural diagram of another snapshot storage space provided in an exemplary embodiment of the present application;
FIG. 3 is a flowchart illustrating a snapshot creation method according to an exemplary embodiment of the present application;
fig. 4 is a flowchart illustrating a snapshot reading method according to an exemplary embodiment of the present application;
fig. 5 is a schematic structural diagram of a snapshot management device according to an exemplary embodiment of the present application;
fig. 6 is a schematic structural diagram of another snapshot management device according to an exemplary embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
In the embodiment of the application, in the snapshot creation process, if an incremental snapshot to be created needs to depend on a data block in a historical snapshot, in metadata of the incremental snapshot to be created, not only a position index of the data block in the historical snapshot on which the incremental snapshot to be created depends is recorded, but also a data key used by the historical snapshot is recorded for decrypting the data block in the historical snapshot on which the incremental snapshot to be created depends.
The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.
Fig. 1 is a schematic structural diagram of a snapshot management system according to an exemplary embodiment of the present application. As shown in fig. 1, the system 10 includes: at least one storage device 11 and a snapshot management device 12 coupled to the at least one storage device 11.
At least one storage device 11 is configured to provide a data storage space for a user of the snapshot management system 10, and provide a corresponding snapshot storage space for the data storage space, where each snapshot of the data storage space is stored.
For different users, at least one storage device 11 may provide data storage spaces and snapshot storage spaces of the same size, or may provide data storage spaces and snapshot storage spaces of different sizes. In addition, in the embodiments of the present application, the sizes of the data storage space and the snapshot storage space are not limited. For example, the data storage space may be a block of storage space of 500MB, 800MB or 50GB in size. The snapshot storage space may be a block of storage space of size 500MB, 200MB, or 1 GB.
The snapshot management system 10 may include at least one storage device 11 that is the same type of storage device or different types of storage devices. Any storage device 11 may be any device with storage function, such as a server, a desktop computer, a personal computer, a mobile phone, a tablet computer, a database, etc. The server may be a conventional server, a cloud host, a virtual center, or the like. The implementation structure of each storage device 11 may include a processor, a system bus, and at least one physical storage medium such as a hard disk and a memory.
For any storage device 11, the at least one physical storage medium included therein may be the same type of physical storage medium or different types of physical storage medium. For example, any one of the physical storage media may be selected from phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory, read only compact disc read only memory (CD-ROM), Digital Versatile Disc (DVD), Solid State Drive (SSD), magnetic cassette tape, and the like.
The data storage space provided by the at least one storage device 11 for the user of the snapshot management system 10 is mainly used for storing data related to the user of the snapshot management system 10, and may include, for example, user data, system data, various application data, and the like. The user of the snapshot management system 10 may write data to the data storage space or read data from the data storage space. The user of the snapshot management system 10 may be a computer, a virtual machine, various applications, a terminal device, a user, and the like, which have access and/or use rights to the snapshot management system 10. There may be one or more users of the snapshot management system 10.
In an exemplary implementation, the snapshot management system 10 provides data storage space to its users in the form of cloud disks. The cloud disk provided by the snapshot management system 10 is a disk instance established on at least one storage device 11. The cloud disk is similar to a computer disk, and a user can read and write the cloud disk. The cloud disk needs to be mapped onto a physical storage medium of at least one storage device 11, such as a disk, ROM, etc. It should be noted that fig. 1 shows a case where the snapshot management system 10 provides data storage space to its user in a cloud disk manner, but the manner in which the snapshot management system 10 provides data storage space to its user is not limited to the cloud disk manner. For example, the snapshot management system 10 may also provide data storage space to its users in the form of a database or a conventional disk.
In the snapshot management system 10, the snapshot management device 12 mainly implements a snapshot function of the snapshot management system 10 to backup and disaster-tolerant data in the snapshot management system 10. In a deployment implementation, the snapshot management apparatus 12 may be separately deployed independently from the at least one storage apparatus 11, as shown in fig. 1. When the snapshot management device 12 is separately deployed and implemented, the snapshot management device 12 may be any device with certain processing capability, such as a server, a desktop computer, a personal computer, a mobile phone, a tablet computer, and the like. In addition to a separate deployment implementation, the snapshot management apparatus 12 may also be deployed on one or more storage apparatuses 11. The storage device 11, in which the snapshot management device 12 is deployed, has a capability of creating, maintaining, and managing snapshots in addition to the storage capability.
During the use of the snapshot management system 10, the snapshot management device 12 may create a plurality of snapshots at different time points for the data storage space provided by the at least one storage device 11 to the user of the snapshot management system 10, and form a snapshot chain. The snapshot at each point in time can be viewed as a copy or replica of the data stored in the data storage space at the corresponding point in time. The snapshots are stored in a snapshot storage space provided by at least one storage device 11. When the storage device 11 corresponding to the data storage space fails or the data stored in the data storage space is lost, data rollback can be performed according to the snapshot, and the data in the data storage space can be restored to the data state recorded in a certain snapshot on the snapshot chain.
Considering that the data stored in the data storage space has a cold-hot score, many data will be changed long. Thus, there is often only a small amount of data differentiation in the individual snapshots of the data storage space. To save space, the snapshot management device 12 uses incremental snapshot techniques when creating snapshots and, correspondingly, deduplication storage techniques when storing snapshots.
In an embodiment of the deduplication storage technique, a data storage space provided by at least one storage device 11 in the snapshot management system 10 to a user of the snapshot management system 10 is divided into a plurality of storage partitions according to address offsets. The size of the storage partition can be adaptively divided according to the size of the data storage space, for example, every 2MB, 10MB or 20MB of the storage area can be used as a storage partition. A snapshot of data stored in a storage partition is referred to as a data Block (Block), that is, the data Block is snapshot data of the storage partition. In the snapshot management system 10, snapshot management is performed with data block granularity. In this way, when a snapshot is created for the data storage space each time, only each storage partition needs to be checked, if the content of the data currently stored in the storage partition is the same as the content of the data block corresponding to the storage partition in the existing snapshot, the data block in the existing snapshot is continuously used in the new snapshot, and the data block is not stored repeatedly; and if the content of the data currently stored in the storage partition is different from the content of the data block corresponding to the storage partition in the existing snapshot, the data block corresponding to the storage partition is stored in the new snapshot again.
As shown in FIG. 2a, it is assumed that the data storage space provided by at least one storage device 11 to the user of the storage system 10 is partitioned into 4 storage partitions, denoted as storage partitions Q1-Q4. In connection with the storage partition shown in fig. 2a, the process of creating a snapshot for the data storage space includes:
a snapshot is created for the data storage space for the first time, and is denoted as snapshot a, and snapshot a is stored in the snapshot storage space provided by at least one storage device 11. The storage pattern of snapshot A in the snapshot storage space is shown in FIG. 2b, and includes data block 1-A, data block 2-A, data block 3-A, and data block 4-A.
After creating snapshot A, assume that the user issues an IO operation to the data storage space that changed the data in storage partitions Q1 and Q3, and that the data of the other storage partitions did not change. The change information of these memory partitions is recorded in the metadata of the data storage space. After the change, creating a snapshot for the data storage space for the second time, and recording the snapshot as a snapshot B, wherein the snapshot B is stored in the snapshot storage space. The storage style of the snapshot B in the snapshot storage space is shown in fig. 2B, and includes: data blocks 1-B and data blocks 3-B. In the snapshot B, the data block 2-A and the data block 4-A in the snapshot A are continuously used, the data block 2-A and the data block 4-A do not need to be stored again, and only the name of the used data block in the existing snapshot is recorded in the metadata of the snapshot B, so that the corresponding data block is read from the storage space of the snapshot A. Taking the example of creating two snapshots (i.e., snapshot a and snapshot B) for the data storage space as an example, in practical applications, more snapshots can be created for the data storage space. Wherein snapshot a and snapshot B and subsequent snapshots may form a snapshot chain of data storage space.
For a snapshot chain of a data storage space, there is a snapshot list that records the name of each snapshot that the snapshot chain contains. Each snapshot has metadata in which the name and position index of each data block used by the snapshot are recorded. For example, as shown in fig. 2c, the name of the data block and the corresponding position index are sequentially recorded in the metadata of snapshot a: 1-A, 2-A, 3-A and 4-A; the position index corresponding to the data block is as follows: a1, a2, A3 and a 4; the metadata of snapshot B sequentially records the names of data blocks: 1-B, 2-A, 3-B and 4-A; the position index corresponding to the data block is as follows: b1, a2, B3 and a 4. Wherein the location index of the data block points to the storage location of the data block in the snapshot storage space. The location index of the data block may be any information capable of pointing to the storage location of the data block in the snapshot storage space, for example, absolute address information of the data block in the snapshot storage space, pointer information pointing to the storage location of the data block in the snapshot storage space, a name of the data block, and the like. When the position index of the data block is the name of the data block, the name of the data block and the storage position of the data block in the snapshot storage space have a corresponding relation.
As can be seen from fig. 2b and fig. 2c, the same data block only needs to be stored once in the snapshot storage space, or different data blocks are stored in the snapshot storage space, so that a large amount of storage space can be saved.
In this embodiment, in order to ensure the security of the data, the data is stored in the data storage space in an encrypted manner, and the snapshot created based on the encrypted data is also encrypted. To further improve the security of the data, the data key used to encrypt the data is periodically rotated. After the key rotation, the data in the data storage space is encrypted by using a new key, and if an incremental snapshot technology is adopted, the snapshot created after the key rotation may contain the data block in the snapshot created before the key rotation, the new key cannot decrypt all the data blocks in the snapshot created after the key rotation, so that the first snapshot created after the key rotation needs to be a full snapshot in order that the new key can access all the data in the snapshot, but the full snapshot has a large data volume, the snapshot creation takes a long time, and the speed is slow.
In view of the above problem, in the present embodiment, the snapshot management device 12 adopts a new snapshot creation scheme. In this scenario, the snapshot management device 12 is specifically configured to: determining an incremental data block required by an incremental snapshot to be created and a target data block in a target historical snapshot which needs to be relied on according to metadata of a data storage space; recording position indexes of an incremental data block and a target data block and a data key used by a target historical snapshot in metadata of the incremental snapshot to be created so as to decrypt the target data block in snapshot reading; and storing the incremental data block into a snapshot storage space according to the position index of the incremental data block to obtain a new incremental snapshot.
In the embodiment of the present application, a data block in which a to-be-created incremental snapshot changes with respect to a target historical snapshot is referred to as an incremental data block, and the incremental data block may be one or multiple. There may be one or more history snapshots before the incremental snapshot is to be created, and for convenience of description and distinction, the history snapshot on which the incremental snapshot is to be created is referred to as a target history snapshot, and the target history snapshot may also be one or more. Similarly, each target history snapshot has a plurality of data blocks, wherein a data block of the target history snapshot, which is unchanged with respect to the to-be-created delta snapshot, is referred to as a target data block, the target data block is a data block on which the to-be-created delta snapshot depends, and the target data block may be one or a plurality of data blocks. As shown in FIG. 2B, assume that snapshot B is to be an incremental snapshot, and data blocks 1-B and 3-B in snapshot B are incremental data blocks; snapshot A on which snapshot B depends is the target history snapshot, and data blocks 2-A and 4-A in snapshot A are the target data blocks. Further, in combination with the incremental relationship between snapshot a and snapshot B shown in fig. 2B, as shown in fig. 2c, the metadata of the to-be-created incremental snapshot B records the name of the incremental data block: 1-B and 3-B, target history data chunk name: 2-a and 4-a, the position index of each data block: b1, a2, B3, and a4, and the data key a used by the target history snapshot a.
In the embodiment of the present application, the data key used by each snapshot is not limited, and the data key used by each snapshot is different according to different data encryption manners. For example, if the data encryption mode is a symmetric encryption mode, the encryption process and the decryption process use the same key; if the data encryption mode is an asymmetric encryption mode, two keys are required: a public key and a private key, and if the data is encrypted with the public key, the data is decrypted with the private key. If the system adopts a symmetric encryption mode, the same key used in the encryption process and the decryption process is used as the data key used by each snapshot, and the data key a of the snapshot a in fig. 2c is the key in the symmetric encryption mode; if the system adopts an asymmetric encryption mode and uses the public key to encrypt data, the private key is used as the data key used by each snapshot, and the data key a of the snapshot a in fig. 2c is the private key in the asymmetric encryption mode.
In this embodiment, the snapshot creation process is mainly divided into two steps, namely metadata creation and incremental data block transmission. In the metadata creating process, not only the position index of the target data block in the target history snapshot depended on by the incremental snapshot to be created is recorded, but also the data key used by the target history snapshot is recorded and used for decrypting the target data block in the target history snapshot depended on by the incremental snapshot to be created. In the process of transmitting the incremental data blocks, the incremental data blocks required by the incremental snapshot to be created can be transmitted to the snapshot storage space, so as to obtain a new incremental snapshot. The index of the location of the incremental data block in the snapshot storage space is also recorded in the metadata of the new incremental snapshot, thereby obtaining the complete metadata of the new incremental snapshot. It should be noted that the process of creating the metadata and the process of transmitting the incremental data block may be executed in parallel, and the order of the two processes may not be limited. Therefore, by adopting the snapshot creation scheme provided by the embodiment, the problem that the new key cannot decrypt the old data block on which the new incremental snapshot depends can be solved, so that the incremental snapshot can be created after the key rotation without creating a full snapshot, time consumed by creating the snapshot is reduced, and the creation speed is increased.
In the embodiment of the present application, a manner of recording a data key used by a target history snapshot in metadata of an incremental snapshot to be created is not limited. For example, the data key used by the historical snapshot is not encrypted, and is recorded in the metadata of the incremental snapshot to be created in a plaintext mode. Or, in order to ensure the security of the data, the data key used by the target history snapshot may also be encrypted, and the encrypted data key is recorded in the metadata of the incremental snapshot to be created. Under the condition of encrypting and storing the data key used by the historical snapshot, when the target data block on which the incremental snapshot to be created depends needs to be read, the data key used by the target historical snapshot needs to be decrypted first, and then the decrypted data key is used for decrypting the target data block on which the incremental snapshot to be created depends.
In the embodiment of the present application, an encryption method for encrypting the data key used by the target history snapshot is not limited. Further optionally, when encrypting the data key used by the target historical snapshot, the snapshot management device 12 is specifically configured to: encrypting a data key used by the target historical snapshot by using the data key used by the incremental snapshot to be created; alternatively, the data key used by the target history snapshot may be encrypted using the first key. Wherein the first key refers to a key different from a data key used by the incremental snapshot to be created.
No matter which kind of key is used to encrypt the data key used by the target history snapshot, optionally, when the snapshot management device 12 records the data key used by the target history snapshot in the metadata of the incremental snapshot to be created, the method is specifically configured to: setting a key table in metadata of an incremental snapshot to be created; and recording the data key used by the encrypted target history snapshot in a key table. Of course, in the case of no encryption, a key table may also be set in the metadata of the incremental snapshot to be created, and the data key used by the unencrypted target history snapshot is recorded in the key table. In combination with the incremental relationship between the target history snapshot a and the incremental snapshot B to be created, as shown in fig. 2B, a key table is created in the metadata of the snapshot B, and then the data key a used by the snapshot a is recorded in the key table. The process of recording the data key a used by snapshot a in the key table of the incremental snapshot B to be created is described below in three cases. In fig. 2d, the following three cases are illustrated, but do not indicate that the three cases may occur simultaneously.
Mode 1: and encrypting the data key a used by the target historical snapshot A by using the data key B used by the incremental snapshot B to be created to obtain a key c, and recording the key c in a key table.
Mode 2: and encrypting the data key a used by the target history snapshot A by using the first key d to obtain a key e, and recording the key e in a key table.
Mode 3: and directly recording the data key a used by the target history snapshot A in a plaintext manner in the key table.
In practical applications, the snapshot management system 10 may decide to use any one of the above-described manners 1 to 3 to perform encrypted storage on the data key a used by the target history snapshot a. Alternatively, the user of the snapshot management system 10 may determine whether the data key a used by the target history snapshot a needs to be stored in an encrypted manner and configure the data key a in advance. If the user selects a mode of encrypting the data key a used by the target historical snapshot A by using the data key B used by the incremental snapshot B to be created, obtaining a key c by using the mode 1, and recording the key c in a key table; if the user selects a mode of encrypting the data key a used by the target history snapshot A by using the first key d, obtaining a key e by using the mode 2, and recording the key e in a key table; if the user selects the method of not encrypting the data key a used by the target history snapshot a, the data key a used by the target history snapshot a is directly recorded in the key table according to the method of the method 3.
In an optional embodiment, after encrypting the data key used by the target historical snapshot, the snapshot management device 12 is further configured to: and providing the encryption key used for encrypting the data key used by the target historical snapshot to a snapshot user, so that the snapshot user can successfully read the new incremental snapshot according to the encryption key. Specifically, for the above mode 1, the data key B used by the incremental snapshot B to be created is provided to the snapshot user; for mode 2, the first key d is provided to the snapshot user. The snapshot user may be a user of the snapshot management system 10, or may be other computers, virtual machines, various applications, terminal devices, users, and the like, which have access and/or usage rights to the snapshot storage space, and there may be one or more snapshot users. In the foregoing embodiment, in combination with the password rotation state, the snapshot state in the embodiment of the present application may be divided into three types of rotation states, which are: a non-rotation state (i.e., a snapshot state when the incremental snapshot is not created), a metadata rotation state (i.e., a snapshot state after the new incremental snapshot is successfully created), and a snapshot data rotation state (i.e., a state after the new full snapshot is obtained); the three states have a conversion relation, namely the non-conversion state can enter a metadata rotation state after the incremental snapshot is established; the metadata rotation state may enter the snapshot data rotation state after the target data block is re-encrypted for storage to obtain a new full snapshot. The non-rotation state refers to a state in which the creation of the incremental snapshot to be created is not completed. The metadata rotation state refers to a snapshot state in which the snapshot management device 12 records position indexes of the incremental data block and the target data block and a data key used by the target historical snapshot in metadata of the incremental snapshot to be created, and obtains a new incremental snapshot after storing the incremental data block in the snapshot storage space according to the position index of the incremental data block. In a metadata rotation state, a snapshot user can access a new incremental snapshot according to a data key used by the new incremental snapshot (i.e., a newly created incremental snapshot), a target data block in a target historical snapshot on which the new incremental snapshot depends can be decrypted by using the data key used by the target historical snapshot, the snapshot user can successfully access the new incremental snapshot, and the data block in the new incremental snapshot is in a normally usable state at this time.
Further, after the new incremental snapshot reaches the metadata rotation state, the snapshot management device 12 may further encrypt the target data block in the target historical snapshot, which is depended by the new incremental snapshot, again by using the data key used by the new incremental snapshot and store the target data block in the snapshot storage space, so as to complete the transition from the metadata rotation state to the snapshot data rotation state. Specifically, the snapshot management device 12 is further configured to: decrypting the target data block by using a data key used by the target historical snapshot to obtain original data; re-encrypting the original data by using a data key used by the new incremental snapshot, and storing a new data block obtained by re-encrypting into a snapshot storage space; and correcting the position index of the target data block recorded in the metadata of the new incremental snapshot into the position index of the new data block to obtain a new full snapshot. At this time, the new incremental snapshot is changed from the incremental snapshot to the full snapshot, and the data blocks in the full snapshot are encrypted by using the data key used by the new snapshot.
Multiple snapshots may be created for the data storage space periodically, or intermittently, between two adjacent key rotations. Wherein, for the first snapshot after each key rotation, the creation process is mainly divided into two steps: for the detailed process of metadata creation and transmission of the incremental data block, reference may be made to the creation process of the incremental snapshot to be created in the foregoing embodiment, and details are not described here again. For other snapshots after the first snapshot between two adjacent key rotations, the snapshots may be created before the first snapshot reaches the snapshot data rotation state or after the first snapshot reaches the snapshot data rotation state.
For other snapshots created after the first snapshot reaches the snapshot data rotation state, at this time, the first snapshot is already a full snapshot, so other snapshots can be created on the basis of the first full snapshot after the key rotation using the incremental snapshot technique, and the creation process mainly includes creation of metadata and transmission of incremental data blocks. In the process of creating the metadata, only the position index of the incremental data block and the position index of the data block in the first full snapshot referred by the snapshot need to be recorded, and because the snapshot and the first full snapshot use the same data key, the data key used by the first indexed snapshot may not be recorded. The transmission process of the incremental data block is the same as that in the foregoing embodiment, and details thereof are not repeated.
For other snapshots created before the first snapshot reaches the snapshot data rotation state, the creation process may refer to the historical snapshot before the key rotation and may also refer to the data block in the first snapshot after the key rotation, and for other snapshots, the historical snapshot before the key rotation and the first snapshot after the key rotation are both historical snapshots. In this case, the creation process of the other snapshot mainly includes two steps: creation of metadata and transmission of incremental data blocks. For the creation process of the metadata, the snapshot management device 12 may determine whether the data key used by the target historical snapshot is the same as the data key used by the incremental snapshot to be created; if the judgment results are different, executing the operation of recording the data key used by the target historical snapshot in the metadata of the incremental snapshot to be created; if the judgment results are the same, the operation of the data key used by the target historical snapshot may not be recorded in the metadata of the incremental snapshot to be created.
The process of creating the next snapshot before the first snapshot reaches the snapshot data rotation state is illustrated below with reference to the incremental relationship between snapshot a and snapshot B shown in fig. 2B. The data key used by snapshot a is a, after snapshot a is created and before snapshot B is created, the data storage space is assumed to have performed a key rotation, and the data key used by the first snapshot B after the key rotation is B. Assume that the first snapshot B depends on data block 2-a and data block 4-a in snapshot a, and assume that the next snapshot that needs to be created after snapshot B is snapshot C, and that the next snapshot C depends on snapshot B.
Based on the above, as shown in fig. 2e, the first snapshot B is in the metadata rotation state, and the first snapshot B stores the data block 2-a based on the snapshot a as the data block 2-B after being encrypted by the data key used by itself. Assume that at this time, a next snapshot C needs to be created based on the first snapshot B, and the data keys used by the snapshots C and B are both B. Data blocks 1-C and 4-C are data blocks that change relative to data blocks 1-B and 4-A in the first snapshot B, and data blocks 2-B and 3-B are data blocks in snapshot B that snapshot C needs to depend on. Since the data key used by the snapshot B is the same as the data key used by the snapshot C and is the data key B, the data key B used by the snapshot B does not need to be recorded in the metadata of the snapshot C, and at this time, the data blocks 2-B and 3-B can be successfully decrypted by using the data key B used by the snapshot C. Of course, since data blocks 1-C and 4-C are incremental data blocks, which are themselves encrypted using data key b, data key b used with snapshot C can also be successfully decrypted. From the perspective of the snapshot user, only the data key b needs to be recorded to successfully access each data block in the snapshot C.
The purpose of creating the snapshot is to backup or disaster recovery, and when a fault occurs or data stored in the data storage space is lost, data rollback can be performed according to the snapshot to restore the data in the data storage space to a data state recorded in a certain snapshot on a snapshot chain, which may involve a read operation on the snapshot. Based on this, the snapshot management device 12 also reads the data blocks in the corresponding snapshot from the snapshot storage space. In the data encryption scenario, the snapshot management apparatus 12 needs to decrypt the read data block and provide the decrypted data block to the user. In this embodiment, the snapshot management apparatus 12 reads the snapshot in different ways according to the state of the snapshot.
One of the situations is: if the snapshot to be read is in the metadata rotation state, the snapshot management device 12 may determine the snapshot to be read and the data block to be read therein when reading the snapshot; judging whether the data block to be read is a data block in the historical snapshot on which the snapshot to be read depends or an incremental data block in the snapshot to be read; if the data block to be read is a data block in the historical snapshot on which the snapshot to be read depends, acquiring a data key used by the historical snapshot from metadata of the snapshot to be read; decrypting the data block to be read by using the data key used by the historical snapshot and returning the decrypted original data to a snapshot user; and if the data block to be read is the incremental data block in the snapshot to be read, acquiring the data key of the snapshot to be read, decrypting the incremental data block by using the data key of the snapshot to be read, and returning the decrypted original data to the snapshot user.
In the above process, according to different application scenarios, the manner of determining the snapshot to be read and the data block to be read in the snapshot to be read may be different. For example, in one scenario, the snapshot management device 12 may receive a read request of a snapshot user, where the read request includes a snapshot name and a data block number; and determining the snapshot to be read and the data block to be read in the snapshot according to the snapshot name and the data block number. In another scenario, the snapshot management device 12 manages the snapshot periodically, and the snapshot and the data block in the snapshot that the snapshot management device 12 needs to manage at present are the snapshot to be read and the data block to be read, respectively.
In an optional embodiment, in the process of creating the snapshot to be read, the data key used by the target history snapshot is encrypted. Correspondingly, when the snapshot management device 12 acquires the data key used by the historical snapshot from the metadata of the snapshot to be read, the data key is specifically configured to: acquiring a data key used by the encrypted historical snapshot from metadata of the snapshot to be read; and decrypting the encrypted data key used by the history snapshot to obtain the data key used by the history snapshot.
Further optionally, when the snapshot management device 12 decrypts the data key used by the encrypted historical snapshot, the method is specifically configured to: decrypting the encrypted data key used by the historical snapshot by using the data key used by the snapshot to be read to obtain the data key used by the historical snapshot; or the first key is used for decrypting the encrypted data key used by the historical snapshot to obtain the data key used by the historical snapshot. Wherein the first key is a key other than a data key used by the snapshot to be read.
Based on the above, in an optional embodiment, when the snapshot management device 12 obtains the data key used by the encrypted historical snapshot from the metadata of the snapshot to be read, the data key is specifically configured to: reading a key table from the metadata of the snapshot to be read; and reading the data key used by the encrypted historical snapshot from the key table. Of course, for the case of no encryption, the snapshot management device 12 may also read the key table from the metadata of the snapshot to be read, and read the data key used by the unencrypted historical snapshot from the key table.
In another case: if the snapshot to be read is in the snapshot data rotation state, the data block in the historical snapshot does not exist in the snapshot to be read, so that the snapshot to be read and the data block to be read in the snapshot can be directly determined; and decrypting the data block to be read by using the data key used by the snapshot to be read, and returning the decrypted original data to the snapshot user.
In the snapshot creation process provided by the embodiment of the application, not only the position index of the data block in the historical snapshot, on which the incremental snapshot to be created depends, but also the data key used by the historical snapshot is recorded in the metadata of the incremental snapshot to be created, so that the problem that the old data block, on which the incremental snapshot to be created depends, cannot be decrypted by the new key can be solved, the incremental snapshot can be created after the key rotation, the creation of the full snapshot is not needed, the time consumed by creating the snapshot is reduced, and the creation speed is increased. Further, when the metadata is created, the data key used by the historical snapshot is encrypted, so that the safety of the system is greatly improved.
Fig. 3 further provides a snapshot creating method for an exemplary embodiment of the present application, as shown in fig. 3, the method includes:
31. determining an incremental data block required by an incremental snapshot to be created and a target data block in a target historical snapshot which needs to be relied on according to metadata of a data storage space;
32. recording position indexes of an incremental data block and a target data block and a data key used by a target historical snapshot in metadata of an incremental snapshot to be created so as to decrypt the target data block in snapshot reading;
33. and storing the incremental data block into a snapshot storage space according to the position index of the incremental data block to obtain a new incremental snapshot.
In the embodiment of the present application, a data block in which a to-be-created incremental snapshot changes with respect to a target historical snapshot is referred to as an incremental data block, and the incremental data block may be one or multiple. There may be one or more history snapshots before the incremental snapshot is to be created, and for convenience of description and distinction, the history snapshot on which the incremental snapshot is to be created is referred to as a target history snapshot, and the target history snapshot may also be one or more. Similarly, each target history snapshot has a plurality of data blocks, wherein a data block of the target history snapshot, which is unchanged with respect to the to-be-created delta snapshot, is referred to as a target data block, the target data block is a data block on which the to-be-created delta snapshot depends, and the target data block may be one or a plurality of data blocks.
In the embodiment of the present application, the data key used by each snapshot is not limited, and the data key used by each snapshot is different according to different data encryption manners. For example, if the data encryption mode is a symmetric encryption mode, the encryption process and the decryption process use the same key; if the data encryption mode is an asymmetric encryption mode, two keys are required: a public key and a private key, and if the data is encrypted with the public key, the data is decrypted with the private key. If a symmetric encryption mode is adopted, the same key used in the encryption process and the decryption process is used as the data key used in each snapshot, and the data key a of the snapshot a in fig. 2c is the key in the symmetric encryption mode; if an asymmetric encryption mode is adopted and the public key is used to encrypt data, the private key is used as the data key used by each snapshot, and the data key a of the snapshot a in fig. 2c is the private key in the asymmetric encryption mode.
In this embodiment, the snapshot creation process is mainly divided into two steps, namely metadata creation and incremental data block transmission. In the metadata creating process, not only the position index of the target data block in the target history snapshot depended on by the incremental snapshot to be created is recorded, but also the data key used by the target history snapshot is recorded and used for decrypting the target data block in the target history snapshot depended on by the incremental snapshot to be created. In the process of transmitting the incremental data blocks, the incremental data blocks required by the incremental snapshot to be created can be transmitted to the snapshot storage space, so as to obtain a new incremental snapshot. The index of the location of the incremental data block in the snapshot storage space is also recorded in the metadata of the new incremental snapshot, thereby obtaining the complete metadata of the new incremental snapshot. It should be noted that the process of creating the metadata and the process of transmitting the incremental data block may be executed in parallel, and the order of the two processes may not be limited. Therefore, by adopting the snapshot creation scheme provided by the embodiment, the problem that the new key cannot decrypt the old data block on which the new incremental snapshot depends can be solved, so that the incremental snapshot can be created after the key rotation without creating a full snapshot, time consumed by creating the snapshot is reduced, and the creation speed is increased.
In the embodiment of the present application, a manner of recording a data key used by a target history snapshot in metadata of an incremental snapshot to be created is not limited. For example, the data key used by the historical snapshot is not encrypted, and is recorded in the metadata of the incremental snapshot to be created in a plaintext mode. Or, in order to ensure the security of the data, the data key used by the target history snapshot may also be encrypted, and the encrypted data key is recorded in the metadata of the incremental snapshot to be created. Under the condition of encrypting and storing the data key used by the historical snapshot, when the target data block on which the incremental snapshot to be created depends needs to be read, the data key used by the target historical snapshot needs to be decrypted first, and then the decrypted data key is used for decrypting the target data block on which the incremental snapshot to be created depends.
In the embodiment of the present application, an encryption method for encrypting the data key used by the target history snapshot is not limited. Further optionally, encrypting the data key used by the target history snapshot includes: encrypting a data key used by the target historical snapshot by using the data key used by the incremental snapshot to be created; alternatively, the data key used by the target history snapshot may be encrypted using the first key. Wherein the first key refers to a key different from a data key used by the incremental snapshot to be created.
No matter which kind of key is used to encrypt the data key used by the target history snapshot, optionally, in the metadata of the incremental snapshot to be created, the data key used by the target history snapshot is recorded, which includes: setting a key table in metadata of an incremental snapshot to be created; and recording the data key used by the encrypted target history snapshot in a key table. Of course, in the case of no encryption, a key table may also be set in the metadata of the incremental snapshot to be created, and the data key used by the unencrypted target history snapshot is recorded in the key table.
In practical applications, it may be decided by the snapshot management system which way to use for encrypted storage of the data key used by the target historical snapshot. Alternatively, the user of the snapshot management system may determine whether the data key used by the target history snapshot needs to be stored in an encrypted manner and configure the data key in advance.
In an optional embodiment, after encrypting the data key used by the target history snapshot, the method further includes: and providing the encryption key used for encrypting the data key used by the target historical snapshot to a snapshot user, so that the snapshot user can successfully read the new incremental snapshot according to the encryption key. The snapshot user may be a user of the snapshot management system, or may be other computers, virtual machines, various applications, terminal devices, users, and the like, which have access and/or use rights to the snapshot storage space, and there may be one or more snapshot users.
In the foregoing embodiment, in combination with the password rotation state, the snapshot state in the embodiment of the present application may be divided into three types of rotation states, which are: a non-rotation state (i.e., a snapshot state in which the incremental snapshot is not created), a metadata rotation state (i.e., a snapshot state after the new incremental snapshot is successfully created), and a snapshot data rotation state (i.e., a snapshot state after the new full snapshot is obtained); the three states have a conversion relation, namely the non-conversion state can enter a metadata rotation state after the creation of the incremental snapshot to be created is completed; the metadata rotation state may enter the snapshot data rotation state after the target data block is re-encrypted for storage to obtain a new full snapshot. The non-rotation state refers to a state in which the creation of the incremental snapshot to be created is not completed. The metadata rotation state refers to a snapshot state in which position indexes of an incremental data block and a target data block and a data key used by a target historical snapshot are recorded in metadata of an incremental snapshot to be created, and a new incremental snapshot is obtained after the incremental data block is stored in a snapshot storage space according to the position indexes of the incremental data block. In the metadata rotation state, the snapshot user can access the new incremental snapshot (actually, the incremental snapshot) according to the data key used by the new incremental snapshot, and for the target data block in the target history snapshot on which the new incremental snapshot depends, the data key used by the target history snapshot can be used for decryption, and at this time, the data block in the new incremental snapshot is in a normal usable state.
Further, after a new incremental snapshot is obtained (i.e., the metadata rotation state is entered), the data key used by the new incremental snapshot may be used to re-encrypt the target data block in the target history snapshot on which the new incremental snapshot depends and store the target data block in the snapshot storage space, so as to complete the transition from the metadata rotation state to the snapshot data rotation state. Specifically, the method further comprises the following steps: decrypting the target data block by using a data key used by the target historical snapshot to obtain original data; re-encrypting the original data by using a data key used by the new incremental snapshot, and storing a new data block obtained by re-encrypting into a snapshot storage space; and correcting the position index of the target data block recorded in the metadata of the new incremental snapshot into the position index of the new data block to obtain a new full snapshot. At this time, the newly created snapshot is changed from the incremental snapshot to the full snapshot, and the data blocks in the full snapshot are encrypted by using the data key used by the new snapshot.
Multiple snapshots may be created for the data storage space periodically, or intermittently, between two adjacent key rotations. Wherein, for the first snapshot after each key rotation, the creation process is mainly divided into two steps: for the detailed process of metadata creation and transmission of the incremental data block, reference may be made to the creation process of the incremental snapshot to be created in the foregoing embodiment, and details are not described here again. For other snapshots after the first snapshot between two adjacent key rotations, the snapshots may be created before the first snapshot reaches the snapshot data rotation state or after the first snapshot reaches the snapshot data rotation state.
For other snapshots created after the first snapshot reaches the snapshot data rotation state, at this time, the first snapshot is already a full snapshot, so other snapshots can be created on the basis of the first full snapshot after the key rotation using the incremental snapshot technique, and the creation process mainly includes creation of metadata and transmission of incremental data blocks. In the process of creating the metadata, only the position index of the incremental data block and the position index of the data block in the first full snapshot referred by the snapshot need to be recorded, and because the snapshot and the first full snapshot use the same data key, the data key used by the first indexed snapshot may not be recorded. The transmission process of the incremental data block is the same as that in the foregoing embodiment, and details thereof are not repeated.
For other snapshots created before the first snapshot reaches the snapshot data rotation state, the creation process may refer to the historical snapshot before the key rotation and may also refer to the data block in the first snapshot after the key rotation, and for other snapshots, the historical snapshot before the key rotation and the first snapshot after the key rotation are both historical snapshots. In this case, the creation process of the other snapshot mainly includes two steps: creation of metadata and transmission of incremental data blocks. Wherein, for the creation process of the metadata, the method further comprises the following steps: judging whether a data key used by the target historical snapshot is the same as a data key used by the incremental snapshot to be created; if the judgment results are different, the operation of recording the data key used by the target historical snapshot in the metadata of the incremental snapshot to be created is executed; if the judgment results are the same, the operation of the data key used by the target historical snapshot can be recorded without the metadata of the incremental snapshot to be created.
The purpose of creating the snapshot is to backup or disaster recovery, and when a fault occurs or data stored in the data storage space is lost, data rollback can be performed according to the snapshot to restore the data in the data storage space to a data state recorded in a certain snapshot on a snapshot chain, which may involve a read operation on the snapshot. Based on this, fig. 4 is a snapshot reading method provided in an exemplary embodiment of the present application, and as shown in fig. 4, the method includes:
41. determining a snapshot to be read and a data block to be read in the snapshot;
42. if the data block to be read is a data block in the historical snapshot on which the snapshot to be read depends, acquiring a data key used by the historical snapshot from metadata of the snapshot to be read;
43. and decrypting the data block to be read by using the data key used by the historical snapshot, and returning the decrypted original data to the snapshot user.
In the embodiment of the present application, the data blocks in the corresponding snapshot may be read from the snapshot storage space. In the data encryption scenario, the read data block needs to be decrypted and then provided to the user. The method for reading the snapshot is different according to the state of the snapshot.
One of the situations is: if the snapshot to be read is in the metadata rotation state, determining the snapshot to be read and the data block to be read in the snapshot when the snapshot is read; judging whether the data block to be read is a data block in the historical snapshot on which the snapshot to be read depends or an incremental data block in the snapshot to be read; if the data block to be read is a data block in the historical snapshot on which the snapshot to be read depends, acquiring a data key used by the historical snapshot from metadata of the snapshot to be read; decrypting the data block to be read by using the data key used by the historical snapshot and returning the decrypted original data to a snapshot user; and if the data block to be read is the incremental data block in the snapshot to be read, acquiring the data key of the snapshot to be read, decrypting the incremental data block by using the data key of the snapshot to be read, and returning the decrypted original data to the snapshot user.
In the above process, according to different application scenarios, the manner of determining the snapshot to be read and the data block to be read in the snapshot to be read may be different. For example, in one scenario, a read request of a snapshot user may be received, the read request including a snapshot name and a data block number; and determining the snapshot to be read and the data block to be read in the snapshot according to the snapshot name and the data block number. In another scenario, the snapshot management system may manage snapshots periodically, where the current snapshot to be managed and the data block in the snapshot are the snapshot to be read and the data block to be read, respectively.
In an optional embodiment, in the process of creating the snapshot to be read, the data key used by the target history snapshot is encrypted. Correspondingly, the step of obtaining the data key used by the historical snapshot from the metadata of the snapshot to be read comprises the following steps: acquiring a data key used by the encrypted historical snapshot from metadata of the snapshot to be read; and decrypting the encrypted data key used by the history snapshot to obtain the data key used by the history snapshot.
Further optionally, decrypting the data key used by the encrypted historical snapshot includes: decrypting the encrypted data key used by the historical snapshot by using the data key used by the snapshot to be read to obtain the data key used by the historical snapshot; or the first key is used for decrypting the encrypted data key used by the historical snapshot to obtain the data key used by the historical snapshot. Wherein the first key is a key other than a data key used by the snapshot to be read.
Based on the above, in an optional embodiment, obtaining the data key used by the encrypted historical snapshot from the metadata of the snapshot to be read includes: reading a key table from the metadata of the snapshot to be read; and reading the data key used by the encrypted historical snapshot from the key table. Of course, for the case of no encryption, the key table may be read from the metadata of the snapshot to be read, and the data key used by the unencrypted historical snapshot may be read from the key table.
In another case: if the snapshot to be read is in the snapshot data rotation state, the data block in the historical snapshot does not exist in the snapshot to be read, so that the snapshot to be read and the data block to be read in the snapshot can be directly determined; and decrypting the data block to be read by using the data key used by the snapshot to be read, and returning the decrypted original data to the snapshot user.
Corresponding to the snapshot creation method provided by the embodiment of the application, in the snapshot reading process, if the data block to be read is the data block in the historical snapshot on which the snapshot to be read depends, the data key used by the historical snapshot is obtained from the metadata of the snapshot to be read, and the data block to be read is decrypted by using the data key used by the historical snapshot, so that the problem that the data key used by the snapshot to be read cannot decrypt the historical data block on which the snapshot depends is solved.
It should be noted that the execution subjects of the steps of the methods provided in the above embodiments may be the same device, or different devices may be used as the execution subjects of the methods. For example, the execution subjects of steps 31 to 33 may be device a; for another example, the execution subject of steps 31 and 32 may be device a, and the execution subject of step 33 may be device B; and so on.
In addition, in some of the flows described in the above embodiments and the drawings, a plurality of operations are included in a specific order, but it should be clearly understood that the operations may be executed out of the order presented herein or in parallel, and the sequence numbers of the operations, such as 31, 32, etc., are merely used for distinguishing different operations, and the sequence numbers do not represent any execution order per se. Additionally, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel. It should be noted that, the descriptions of "first", "second", etc. in this document are used for distinguishing different messages, devices, modules, etc., and do not represent a sequential order, nor limit the types of "first" and "second" to be different.
Fig. 5 is a schematic structural diagram of a snapshot management device according to an exemplary embodiment of the present application. As shown in fig. 5, the apparatus includes: a memory 54 and a processor 55.
A memory 54 for storing computer programs and may be configured to store other various data to support operations on the snapshot management device. Examples of such data include instructions for any application or method operating on the snapshot management device, contact data, phonebook data, messages, pictures, videos, and so forth.
The memory 54 may be implemented by any type or combination of volatile or non-volatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.
A processor 55 coupled to the memory 54 for executing computer programs in the memory 54 for: determining an incremental data block required by an incremental snapshot to be created and a target data block in a target historical snapshot which needs to be relied on according to metadata of a data storage space; recording position indexes of an incremental data block and a target data block and a data key used by a target historical snapshot in metadata of an incremental snapshot to be created so as to decrypt the target data block in snapshot reading; and storing the incremental data block into a snapshot storage space according to the position index of the incremental data block to obtain a new incremental snapshot.
In an optional embodiment, when the processor 55 records, in the metadata of the incremental snapshot to be created, the data key used by the target historical snapshot, specifically configured to: and encrypting the data key used by the target historical snapshot, and recording the encrypted data key in the metadata of the incremental snapshot to be created.
In an optional embodiment, when encrypting the data key used by the target history snapshot, the processor 55 is specifically configured to: encrypting a data key used by the target historical snapshot by using the data key used by the incremental snapshot to be created; or encrypting the data key used by the target historical snapshot by using a first key, wherein the first key is different from the data key used by the incremental snapshot to be created.
In an alternative embodiment, the processor 55, after encrypting the data key used by the target history snapshot, is further configured to: and providing the encryption key used for encrypting the data key used by the target historical snapshot to a snapshot user, so that the snapshot user can successfully read the new incremental snapshot according to the encryption key.
In an optional embodiment, when the processor 55 records, in the metadata of the incremental snapshot to be created, the data key used by the target historical snapshot, specifically configured to: setting a key table in metadata of an incremental snapshot to be created; and recording the data key used by the target historical snapshot in a key table.
In an alternative embodiment, before recording the data key used by the target historical snapshot in the metadata of the incremental snapshot to be created, the processor 55 is further configured to: judging whether a data key used by the target historical snapshot is the same as a data key used by the incremental snapshot to be created; and if the judgment results are different, executing the operation of recording the data key used by the target historical snapshot in the metadata of the incremental snapshot to be created.
In an alternative embodiment, processor 55, after storing the incremental data block in the snapshot storage space, is further configured to: decrypting the target data block by using a data key used by the target historical snapshot to obtain original data; re-encrypting the original data by using a data key used by the incremental snapshot to be created, and storing a new data block obtained by re-encrypting into a snapshot storage space; and correcting the position index of the target data block recorded in the metadata of the incremental snapshot to be created into the position index of the new data block to obtain a new full snapshot.
Further, as shown in fig. 5, the snapshot management apparatus further includes: communication components 56, display 57, power components 58, audio components 59, and the like. Only some of the components are schematically shown in fig. 5, and it is not meant that the snapshot management apparatus includes only the components shown in fig. 5. In addition, the components within the dashed box in fig. 5 are optional components, not necessary components, and may be determined according to the product form of the snapshot management apparatus.
Accordingly, the present application further provides a computer-readable storage medium storing a computer program, where the computer program can implement the steps that can be executed by the snapshot management apparatus in the foregoing method embodiments when executed.
Fig. 6 is a schematic structural diagram of a snapshot management device according to an exemplary embodiment of the present application. As shown in fig. 6, the apparatus includes: a memory 64 and a processor 65.
A memory 64 for storing computer programs and may be configured to store other various data to support operations on the snapshot management device. Examples of such data include instructions for any application or method operating on the snapshot management device, contact data, phonebook data, messages, pictures, videos, and so forth.
The memory 64 may be implemented by any type or combination of volatile or non-volatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.
A processor 65, coupled to the memory 64, for executing computer programs in the memory 64 for: determining a snapshot to be read and a data block to be read in the snapshot; if the data block to be read is a data block in the historical snapshot on which the snapshot to be read depends, acquiring a data key used by the historical snapshot from metadata of the snapshot to be read; and decrypting the data block to be read by using the data key used by the historical snapshot, and returning the decrypted original data to the snapshot user.
In an optional embodiment, when the processor 65 obtains the data key used by the historical snapshot from the metadata of the snapshot to be read, the processor is specifically configured to: acquiring a data key used by the encrypted historical snapshot from metadata of the snapshot to be read; and decrypting the encrypted data key used by the history snapshot to obtain the data key used by the history snapshot.
In an optional embodiment, when the processor 65 decrypts the data key used by the encrypted history snapshot to obtain the data key used by the history snapshot, specifically: and decrypting the encrypted data key used by the historical snapshot by using the data key used by the snapshot to be read to obtain the data key used by the historical snapshot.
In an optional embodiment, when obtaining, from the metadata of the snapshot to be read, the data key used by the encrypted historical snapshot, the processor 65 is specifically configured to: reading a key table from the metadata of the snapshot to be read; and reading the data key used by the encrypted historical snapshot from the key table.
In an optional embodiment, when determining the snapshot to be read and the data block to be read in the snapshot to be read, the processor 65 is specifically configured to: receiving a reading request of a snapshot user, wherein the reading request comprises a snapshot name and a data block number; and determining the snapshot to be read and the data block to be read in the snapshot according to the snapshot name and the data block number.
Further, as shown in fig. 6, the snapshot management apparatus further includes: communication components 66, display 67, power components 68, audio components 69, and the like. Only some of the components are schematically shown in fig. 6, and it is not meant that the snapshot management apparatus includes only the components shown in fig. 6. In addition, the components within the dashed box in fig. 6 are optional components, not necessary components, and may be determined according to the product form of the snapshot management apparatus.
Accordingly, the present application further provides a computer-readable storage medium storing a computer program, where the computer program can implement the steps that can be executed by the snapshot management apparatus in the foregoing method embodiments when executed.
The communication components of fig. 5 and 6 described above are configured to facilitate wired or wireless communication between the device in which the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as a WiFi, a 2G, 3G, 4G/LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.
The displays in fig. 5 and 6 described above include screens, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.
The power supply components of fig. 5 and 6 described above provide power to the various components of the device in which the power supply components are located. The power components may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device in which the power component is located.
The audio components of fig. 5 and 6 described above may be configured to output and/or input audio signals. For example, the audio component includes a Microphone (MIC) configured to receive an external audio signal when the device in which the audio component is located is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal may further be stored in a memory or transmitted via a communication component. In some embodiments, the audio assembly further comprises a speaker for outputting audio signals.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims (15)

1. A snapshot creation method, comprising:
determining an incremental data block required by an incremental snapshot to be created and a target data block in a target historical snapshot which needs to be relied on according to metadata of a data storage space;
recording position indexes of the incremental data block and the target data block and a data key used by the target historical snapshot in metadata of an incremental snapshot to be created so as to decrypt the target data block in snapshot reading; and
and storing the incremental data block into a snapshot storage space according to the position index of the incremental data block to obtain a new incremental snapshot.
2. The method of claim 1, wherein recording a data key used by the target historical snapshot in metadata of a to-be-created delta snapshot comprises:
and encrypting the data key used by the target historical snapshot, and recording the encrypted data key in the metadata of the incremental snapshot to be created.
3. The method of claim 2, wherein encrypting the data key used by the target history snapshot comprises:
encrypting the data key used by the target historical snapshot by using the data key used by the incremental snapshot to be created;
or
And encrypting the data key used by the target historical snapshot by using a first key, wherein the first key is different from the data key used by the incremental snapshot to be created.
4. The method of claim 2 or 3, further comprising, after encrypting the data key used by the target history snapshot:
and providing the encryption key used for encrypting the data key used by the target historical snapshot to a snapshot user, so that the snapshot user can successfully read a new incremental snapshot according to the encryption key.
5. The method of any of claims 1-3, wherein recording, in the metadata of the incremental snapshot to be created, a data key used by the target historical snapshot comprises:
setting a key table in metadata of an incremental snapshot to be created;
and recording the data key used by the target historical snapshot in the key table.
6. The method according to any one of claims 1-3, further comprising, before recording the data key used by the target historical snapshot in the metadata of the incremental snapshot to be created:
judging whether the data key used by the target historical snapshot is the same as the data key used by the incremental snapshot to be created;
and if the judgment results are different, executing the operation of recording the data key used by the target historical snapshot in the metadata of the incremental snapshot to be created.
7. The method of any of claims 1-3, further comprising, after storing the delta data block into a snapshot storage space:
decrypting the target data block by using the data key used by the target historical snapshot to obtain original data;
re-encrypting the original data by using a data key used by the incremental snapshot to be created, and storing a new data block obtained by re-encrypting into a snapshot storage space;
and correcting the position index of the target data block recorded in the metadata of the incremental snapshot to be created into the position index of the new data block to obtain a new full snapshot.
8. A snapshot reading method, comprising:
determining a snapshot to be read and a data block to be read in the snapshot;
if the data block to be read is a data block in the historical snapshot on which the snapshot to be read depends, acquiring a data key used by the historical snapshot from metadata of the snapshot to be read;
and decrypting the data block to be read by using the data key used by the historical snapshot, and returning the decrypted original data to the snapshot user.
9. The method according to claim 8, wherein obtaining the data key used by the historical snapshot from the metadata of the snapshot to be read comprises:
acquiring a data key used by the encrypted historical snapshot from the metadata of the snapshot to be read;
and decrypting the encrypted data key used by the history snapshot to obtain the data key used by the history snapshot.
10. The method of claim 9, wherein decrypting the encrypted data key used by the history snapshot to obtain the data key used by the history snapshot comprises:
and decrypting the encrypted data key used by the historical snapshot by using the data key used by the snapshot to be read to obtain the data key used by the historical snapshot.
11. The method according to any one of claims 8 to 10, wherein obtaining the encrypted data key used by the historical snapshot from the metadata of the snapshot to be read comprises:
reading a key table from the metadata of the snapshot to be read;
and reading the encrypted data key used by the historical snapshot from the key table.
12. The method according to any one of claims 8-10, wherein determining the snapshot to be read and the data block to be read therein comprises:
receiving a reading request of a snapshot user, wherein the reading request comprises a snapshot name and a data block number;
and determining the snapshot to be read and the data block to be read in the snapshot according to the snapshot name and the data block number.
13. A snapshot management apparatus, comprising: a memory and a processor;
the memory is used for storing programs;
the processor, coupled with the memory, to execute the program to:
determining an incremental data block required by an incremental snapshot to be created and a target data block in a target historical snapshot which needs to be relied on according to metadata of a data storage space;
recording position indexes of the incremental data block and the target data block and a data key used by the target historical snapshot in metadata of an incremental snapshot to be created so as to decrypt the target data block in snapshot reading; and
and storing the incremental data block into a snapshot storage space according to the position index of the incremental data block to obtain a new incremental snapshot.
14. A snapshot management apparatus, comprising: a memory and a processor;
the memory is used for storing programs;
the processor, coupled with the memory, to execute the program to:
determining a snapshot to be read and a data block to be read in the snapshot;
if the data block to be read is a data block in the historical snapshot on which the snapshot to be read depends, acquiring a data key used by the historical snapshot from metadata of the snapshot to be read;
and decrypting the data block to be read by using the data key used by the historical snapshot, and returning the decrypted original data to the snapshot user.
15. A computer readable storage medium having stored thereon a computer program enabling, when executed, the implementation of the steps of the method according to any one of claims 1 to 11.
CN202010245187.7A 2020-03-31 2020-03-31 Snapshot creating and reading method, equipment and storage medium Pending CN113467989A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010245187.7A CN113467989A (en) 2020-03-31 2020-03-31 Snapshot creating and reading method, equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010245187.7A CN113467989A (en) 2020-03-31 2020-03-31 Snapshot creating and reading method, equipment and storage medium

Publications (1)

Publication Number Publication Date
CN113467989A true CN113467989A (en) 2021-10-01

Family

ID=77865540

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010245187.7A Pending CN113467989A (en) 2020-03-31 2020-03-31 Snapshot creating and reading method, equipment and storage medium

Country Status (1)

Country Link
CN (1) CN113467989A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024051090A1 (en) * 2022-09-09 2024-03-14 上海爱数信息技术股份有限公司 Data index management method, storage device, and medium

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030046260A1 (en) * 2001-08-30 2003-03-06 Mahadev Satyanarayanan Method and system for asynchronous transmission, backup, distribution of data and file sharing
US20140019769A1 (en) * 2012-07-16 2014-01-16 Compellent Technologies Encryption/decryption for data storage system with snapshot capability
CN109753380A (en) * 2017-11-08 2019-05-14 阿里巴巴集团控股有限公司 Snapshot data backup method, apparatus and system
US20190158281A1 (en) * 2017-11-20 2019-05-23 Rubrik, Inc. Managing key encryption keys using a key wrapping tree
US20190319785A1 (en) * 2018-04-13 2019-10-17 Amazon Technologies, Inc. Encryption by default in an elastic computing system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030046260A1 (en) * 2001-08-30 2003-03-06 Mahadev Satyanarayanan Method and system for asynchronous transmission, backup, distribution of data and file sharing
US20140019769A1 (en) * 2012-07-16 2014-01-16 Compellent Technologies Encryption/decryption for data storage system with snapshot capability
CN109753380A (en) * 2017-11-08 2019-05-14 阿里巴巴集团控股有限公司 Snapshot data backup method, apparatus and system
US20190158281A1 (en) * 2017-11-20 2019-05-23 Rubrik, Inc. Managing key encryption keys using a key wrapping tree
US20190319785A1 (en) * 2018-04-13 2019-10-17 Amazon Technologies, Inc. Encryption by default in an elastic computing system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024051090A1 (en) * 2022-09-09 2024-03-14 上海爱数信息技术股份有限公司 Data index management method, storage device, and medium

Similar Documents

Publication Publication Date Title
US10594481B2 (en) Replicated encrypted data management
CN106612285B (en) Distributed cloud data management method and system based on peer-to-peer network
CN108833091B (en) Encryption method, decryption method and device for log file
US10951406B2 (en) Preventing encryption key recovery by a cloud provider
US11695806B2 (en) Intercepting calls for encryption handling in persistent access multi-key systems
US10367789B2 (en) Data synchronization method and apparatus
WO2018218953A1 (en) Data backup method and device, storage medium and server
US9544140B1 (en) Multi-level key hierarchy for securing cloud-based data sets
WO2017003891A1 (en) Intelligent deletion of revoked data
CN110661748B (en) Log encryption method, log decryption method and log encryption device
US10027660B2 (en) Computer program, method, and system for secure data management
WO2017206754A1 (en) Storage method and storage device for distributed file system
US20140129848A1 (en) Method and Apparatus for Writing and Reading Hard Disk Data
CN109063011B (en) Log processing method, electronic device and computer readable storage medium
US11190353B2 (en) Computer implemented methods and systems for managing a cryptographic service
CN107066346A (en) A kind of data back up method, data reconstruction method and device
CN109753379B (en) Snapshot data backup and deletion method, device and system
CN111427860B (en) Distributed storage system and data processing method thereof
CN113467989A (en) Snapshot creating and reading method, equipment and storage medium
CN112788151B (en) Method, device and system for data synchronization
US20210218570A1 (en) Methods and systems for encrypting shared information through its lifecycle
CN110046510B (en) Cross-cloud data migration method, device and system
CN115765998A (en) Encryption machine cluster migration upgrade access method and device
CN114995949A (en) Container mirror image construction method and device
EP3598689B1 (en) Managing central secret keys of a plurality of user devices associated with a single public key

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20211001