Apparatus and method for fast backup

Abstract

A backup entity and a method for backing up a disk volume of a production device are disclosed. The backup entity is configured to create a first backup image of the disk volume in a backup repository. Furthermore, the backup entity is configured to obtain a first indication from the production device, wherein the first indication indicates a first operation to be performed on the disk volume by the production device. The backup entity is further configured to perform the first operation on the first backup image to obtain a second backup image in the backup repository. In this way, a solution is provided to mimic operations that change data of a production storage in a backup system. The present disclosure can reduce the amount of data sent from the production storage to the backup system, thereby reducing the backup window.

Description

Technical Field

[0001] This disclosure relates to the field of computer systems with backup mechanisms, and more particularly to an improved backup method. This disclosure enables the rapid and efficient backup of computer systems. To this end, this disclosure provides a backup entity, a backup system, and a method for rapidly backing up data. Background Technology

[0002] Customers may periodically run tools that perform numerous input / output (I / O) operations and modify disk data, files, software programs, and the operating system. Examples of such operations include full disk encryption, operating system (OS) and program upgrades, disk defragmentation, application maintenance, defragmentation, and repair. Because these operations perform many I / O operations and modify disk data, they can result in longer backup windows and degrade the performance of the production server during the next backup. Typically, a backup window refers to the optimal time slot / window for backing up data, applications, or the system. It is a predetermined or pre-scheduled time that allows backup software to initiate the backup process on a computer system. For example, virtual machine (VM) snapshots are larger and therefore require more time to back up. This means that the VM snapshot will remain for a longer period (due to backup needs), and VM performance will be degraded during this time. Furthermore, these operations can also increase network traffic load as a significant amount of data is being sent to the backup server.

[0003] Typically, after multiple write operations to the disk, the backup system performs a regular backup, which may be a full backup. Alternatively, if the backup system detects that data changes exceed a certain percentage, it can initiate a backup task more quickly. In both cases, all changes will be transferred to the repository in one long backup process or several short backup processes. Summary of the Invention

[0004] In view of the above-mentioned challenges, embodiments of the present invention aim to provide a backup entity and method for backing up production equipment in a fast and efficient manner. In particular, the objective is to quickly back up the production equipment in scenarios where operations involving numerous I / O operations and disk data changes will be performed on the production equipment. One objective is to avoid transferring all data to the backup entity after the operations. Furthermore, it is desirable to reduce the backup window.

[0005] This objective is achieved by embodiments of the invention as described in the appended independent claims. Advantageous implementations of the embodiments of the invention are further defined in the dependent claims.

[0006] A first aspect of this disclosure provides a backup entity for backing up a disk volume, wherein the disk volume is a disk volume of a production device, wherein the backup entity is configured to: create a first backup image of the disk volume in a backup repository; obtain a first instruction from the production device, wherein the first instruction indicates a first operation to be performed by the production device on the disk volume; and perform the first operation on the first backup image to obtain a second backup image in the backup repository.

[0007] Accordingly, this disclosure proposes mirroring operations to be performed on production equipment within a backup repository. Specifically, these operations can be those that involve significant changes to the disk. Therefore, when creating a new backup, the backup entity may have already factored in such anticipated future changes. Consequently, the production equipment can be backed up more quickly and efficiently, especially in scenarios where operations will be performed on the production equipment.

[0008] The backup entity can identify the first operation based on the first indication. The first indication may include the name of the first operation, and / or may include a predetermined ID of the first operation, and / or may include basic parameters of the first operation. The second backup image may be a first backup image on which the first operation has been performed.

[0009] In one embodiment of the first aspect, the backup entity is further configured to obtain a first snapshot of the disk volume from the production equipment; and to back up the first snapshot to create a first backup image of the disk volume in the backup repository.

[0010] In one embodiment of the first aspect, the backup entity is further configured to perform block partitioning on the second backup image to obtain a first set of blocks; and to calculate a hash value for each block in the first set of blocks to obtain a first set of hash values.

[0011] It is worth noting that hash values ​​can be used to uniquely identify the corresponding blocks.

[0012] In one embodiment of the first aspect, the backup entity is configured to, after the production device performs the first operation, obtain a second snapshot of the disk volume from the production device; perform block division on the second snapshot to obtain a second group of blocks; and calculate a hash value for each block in the second group of blocks to obtain a second group of hash values.

[0013] It is worth noting that new data can also be written to the production device after the previous backup and before the first operation is performed. That is, the block / hash value of the second snapshot of the production device is not necessarily the same as the block / hash value of the second backup image of the backup repository.

[0014] In one embodiment of the first aspect, the step of performing block division on the second snapshot includes: instructing the production equipment to perform block division on the second snapshot to obtain a second block.

[0015] In one embodiment of the first aspect, the backup entity is configured to: compare the first set of hash values ​​and the second set of hash values; determine a third set of hash values, wherein the third set of hash values ​​includes hash values ​​that are in the second set of hash values ​​but not in the first set of hash values; and add blocks associated with hash values ​​in the third set of hash values ​​to the second backup image to obtain a third backup image in the backup repository.

[0016] In other words, the third set of hash values ​​may be related to new / different blocks / data that do not currently exist in the backup repository. Backing up the new data only in the backup repository reduces the amount of data to be transferred and stored.

[0017] In one embodiment of the first aspect, the first operation includes one of the following operations: disk encryption, program upgrade, disk defragmentation, and application maintenance.

[0018] These operations are heavy I / O operations that modify large amounts of data on the disk.

[0019] In one embodiment of the first aspect, the first instruction includes an encryption key and an encryption algorithm.

[0020] In the case where the first operation is to encrypt the disk, it is necessary to have the encryption key and encryption algorithm to be used in the production equipment.

[0021] A second aspect of this disclosure provides a backup system including a backup entity according to the first aspect or one embodiment of the first aspect, and the backup repository.

[0022] In one embodiment of the second aspect, the backup system further includes the production equipment.

[0023] In one embodiment of the second aspect, the production equipment is configured to create the first snapshot of the disk volume before performing the first operation.

[0024] In one embodiment of the second aspect, the production equipment is further configured to: perform the first operation on the disk volume; and, after performing the first operation, create a second snapshot of the disk volume.

[0025] A third aspect of this disclosure provides a method for backing up a disk volume, wherein the disk volume is a disk volume of a production device, wherein the method includes: creating a first backup image of the disk volume in a backup repository; obtaining a first instruction from the production device, wherein the first instruction indicates a first operation to be performed by the production device on the disk volume; and performing the first operation on the first backup image to obtain a second backup image in the backup repository.

[0026] In one embodiment of the third aspect, the method further includes: obtaining a first snapshot of the disk volume from the production equipment; and backing up the first snapshot to create a first backup image of the disk volume in the backup repository.

[0027] In one embodiment of the third aspect, the method further includes: performing block division on the second backup image to obtain a first group of blocks; and calculating a hash value for each block in the first group of blocks to obtain a first group of hash values.

[0028] In one embodiment of the third aspect, the method further includes: after the production equipment performs the first operation, obtaining a second snapshot of the disk volume from the production equipment; performing block division on the second snapshot to obtain a second group of blocks; and calculating a hash value for each block in the second group of blocks to obtain a second group of hash values.

[0029] In one embodiment of the third aspect, the step of performing block division on the second snapshot includes: instructing the production equipment to perform block division on the second snapshot to obtain the second block.

[0030] In one embodiment of the third aspect, the method further includes: comparing the first set of hash values ​​and the second set of hash values; determining a third set of hash values, wherein the third set of hash values ​​includes hash values ​​that are in the second set of hash values ​​but not in the first set of hash values; and adding a block associated with a hash value in the third set of hash values ​​to the second backup image to obtain a third backup image in the backup repository.

[0031] In one embodiment of the third aspect, the first operation includes one of the following operations: disk encryption, program upgrade, disk defragmentation, and application maintenance.

[0032] In one embodiment of the third aspect, the first instruction includes an encryption key and an encryption algorithm.

[0033] The method and its implementation in the third aspect provide the same advantages and effects as those described in the device and its corresponding implementation in the first aspect.

[0034] A fourth aspect of this disclosure provides a computer program including program code for performing, when implemented on a processor, the method according to the second aspect or any embodiment thereof.

[0035] It should be noted that all devices, elements, units, and apparatuses described in this application can be implemented as software or hardware elements or any combination thereof. All steps performed by the various entities described in this application, and the functions performed by the various entities as described, are intended to indicate that the various entities are suitable or configured to perform the various steps and functions. Even if a particular function or step performed by an external entity is not reflected in the specific detailed description of the elements of the entity performing that particular step or function in the following description of specific embodiments, those skilled in the art will understand that these methods and functions can also be implemented in the corresponding software or hardware elements or any combination thereof. Attached Figure Description

[0036] The above aspects and embodiments will be explained in the following description of specific embodiments with reference to the accompanying drawings, wherein:

[0037] Figure 1 A backup entity is shown according to an embodiment of the present invention.

[0038] Figure 2 A schematic diagram of a production device and a backup entity according to an embodiment of the present invention is shown.

[0039] Figure 3 A schematic diagram of a production device and a backup entity according to an embodiment of the present invention is shown.

[0040] Figure 4 An overview of a system according to an embodiment of the present invention is shown.

[0041] Figure 5 A method according to an embodiment of the present invention is shown. Detailed Implementation

[0042] Illustrative embodiments of methods, apparatus, and program products for efficient packet transmission in a communication system are described with reference to the accompanying drawings. While this description provides detailed examples of possible implementations, it should be noted that these details are merely exemplary and in no way limit the scope of this application.

[0043] Furthermore, an embodiment / example may refer to other embodiments / examples. For instance, any descriptions, including but not limited to terms, elements, processes, descriptions, and / or technical advantages, mentioned in one embodiment / example are applicable to other embodiments / examples.

[0044] Figure 1A backup entity 100 according to an embodiment of the present invention is shown. The backup entity 100 is adapted to back up a disk volume, wherein the disk volume is a disk volume of a production device 110. Specifically, the backup entity 100 is configured to create a first backup image 101 of the disk volume in a backup repository. The backup entity 100 is also configured to obtain a first instruction 111 from the production device 110. Specifically, the first instruction 111 indicates a first operation 1111 that the production device 110 will perform on the disk volume. Furthermore, the backup entity 100 is configured to perform the first operation 1111 on the first backup image 101 to obtain a second backup image 102 in the backup repository.

[0045] It is worth noting that backup entity 100 may be a backup application. This backup application may be installed on production device 110 or on other devices within the system. Backup entity 100 may also include the backup repository. Optionally, the backup repository may be an external storage device, i.e., outside of backup entity 100 and / or production device 110.

[0046] Possibly, backup entity 100 may be adapted to back up the entire disk of production device 110. Alternatively, backups may be applied at the granularity of volumes such as C:\, D:\ on the disk of production device 110 (e.g., when using a Windows operating system), or at the granularity of disk partitions of production device 110 (e.g., in a Linux system).

[0047] Backup entity 100 may include processing circuitry (not shown) configured to perform, implement, or initiate various operations of backup entity 100 as described herein. The processing circuitry may include hardware and software. The hardware may include analog or digital circuitry, or analog and digital circuitry. The digital circuitry may include components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multifunction processors. In one embodiment, the processing circuitry includes one or more processors and non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code that, when executed by the one or more processors, causes backup entity 100 to perform, implement, or initiate the operations or methods described herein.

[0048] This disclosure proposes mirroring changes to critical portions of the disk in a backup repository to create new backups that already contain such anticipated future changes.

[0049] Specifically, according to one embodiment of the present invention, backup entity 100 may be configured to obtain a first snapshot of the disk volume from production device 110. Backup entity 100 may also be configured to back up the first snapshot to create a first backup image 101 of the disk volume in the backup repository.

[0050] Optionally, according to an embodiment of the present invention, the backup entity 100 may also be configured to perform chunking on the second backup image 102 to obtain a first set of chunks; and to calculate a hash value for each chunk in the first set of chunks to obtain a first set of hash values.

[0051] It's important to note that chunking is the process of dividing a file into smaller parts (called chunks) using a chunking algorithm. This helps eliminate duplicate copies of data in storage. A chunk is typically a smaller-granularity block. That is, a block can be divided into multiple chunks. There is no restriction that the chunk size should be equal to the block size, but this would reduce efficiency in implementation. Typically, in backup applications, the chunk size is 4K-4M (depending on the backup application), while the smallest unit of I / O is a sector, which is 512 bytes for a hard drive. By convention, when one sector is modified, the backup application will mark one chunk as modified, for example, a 4M chunk. This invention proposes dividing the chunk into smaller chunks (e.g., chunk size 16K, in this example: 16K * 256 chunks = 4M) instead of calculating the hash value of the entire chunk (e.g., 4M). Therefore, the hash value is calculated for each 16K chunk, instead of calculating the hash value for the entire 4M chunk at once. Therefore, the hash calculation of blocks and blocks is essentially different in granularity.

[0052] The hash value of a data block can be obtained by applying a hash function or hash algorithm to the block. The hash value can be used to uniquely identify each block. It should be understood that different types of hash algorithms or functions can be applied to obtain hash values ​​in this invention. There are no specific limitations on this in the embodiments of this invention.

[0053] Optionally, according to an embodiment of the present invention, backup entity 100 may be configured to obtain a second snapshot of the disk volume from production device 110 after production device 110 has performed the first operation 1111. Backup entity 100 may also be configured to perform block partitioning on the second snapshot to obtain a second set of blocks. Then, backup entity 100 may be configured to calculate a hash value for each block in the second set of blocks to obtain a second set of hash values.

[0054] It is worth noting that this second snapshot is created at a point in time after the first snapshot was created. The first operation 1111 could be an operation that performs numerous I / O operations and modifies disk data, files, software programs, and the operating system. This means that after the first operation 1111, a large amount of data on the disk will be changed.

[0055] Specifically, according to one embodiment of the present invention, performing block division on the second snapshot may further include instructing the production equipment 110 to perform block division on the second snapshot in order to obtain the second block.

[0056] Having known two sets of hash values ​​(the first set of hash values ​​and the second set of hash values ​​according to a previous embodiment), alternatively, according to an embodiment of the invention, backup entity 100 may be configured to compare the first set of hash values ​​and the second set of hash values. Backup entity 100 may also be configured to determine a third set of hash values, wherein the third set of hash values ​​includes hash values ​​that are in the second set of hash values ​​but not in the first set of hash values. Backup entity 100 may then be configured to add blocks associated with hash values ​​in the third set of hash values ​​to the second backup image 102 to obtain a third backup image 103 in the backup repository.

[0057] It should be understood that this third set of hash values ​​relates to new data. This new data refers to data that was added to the disk of production device 110 after the creation of the first snapshot but before the execution of the first operation 1111. In other words, this new data does not exist in the backup repository.

[0058] Based on the foregoing embodiments, it can be seen that backup entity 100 can verify whether the hash values ​​of these (blocks) exist in the backup repository. If they do not exist, backup entity 100 needs to request this data from production device 110 and store this data and the hash values ​​in the backup repository. Conversely, if the hash values ​​already exist, there is no need to transfer this data between production device 110 and the backup repository. In this way, since the first operation 1111 is pre-executed in the backup repository using the same algorithm, key block size, and hash algorithm, most hash values ​​already exist, thus the amount of data that needs to be transferred from the production network (production device 110) to the infrastructure network (the backup repository) is greatly reduced.

[0059] In the following scenario: an operation such as disk encryption is performed on the production server at 20:00, and a backup of that server is scheduled for 22:00. A previous backup was performed at 19:00. The same operation will be performed on the backup server: encrypting the disk backup (the one performed at 19:00), specifically using the same key that will be used in the encryption on the production side at 20:00. The result of this encryption on the backup server side will be stored there. At 22:00, when the next backup occurs, the disk on the production server and the result of the encryption on the backup server side will be chunked and hashed (specifically, using the same chunking and hashing algorithm). Then, hash values ​​are transmitted between the production server and the backup server (the production server sends its hash value to the backup server, and vice versa), and these hash values ​​are used to determine which data blocks have been modified. These data blocks are then passed to the backup server, and together with the unmodified, pre-computed encryption blocks on the backup server side, constitute the backup at 22:00.

[0060] It's important to note that the encryption of this backup disk is performed before the next backup occurs. This is to avoid transmitting all encrypted data. Therefore, when the backup system performs a cyclic redundancy check on blocks / blocks, it identifies existing data and reduces network load. Consequently, only altered hashes and blocks are passed to the backup system, resulting in significantly less data compared to a full disk backup using traditional methods.

[0061] The embodiments of the present invention will now be described in detail. In this example, disk encryption is used as an example of the first operation 1111, and not as a limitation.

[0062] 1. VM1 has a 100GB disk (Disk 1).

[0063] 2. At time T1, a snapshot of VM1 is taken and backed up to the backup server.

[0064] 3. The backup repository now has a backup of VM1, called snapshot 1 (i.e., Figure 1 and Figure 2 The first backup image in the image (101) represents VM1 at time T1.

[0065] 4. At time T2, the user knows that he wants to encrypt the data in VM1 using algorithm E1, so he provides the backup application with a key (key 1) for encrypting the latest backup and specifies that the encryption algorithm to be used is E1.

[0066] 5. The backup application uses algorithm E1 and key 1 (received from the user) to encrypt the VM1 disk (i.e., the first backup image 101) in the backup repository (performing the following steps). Figure 1 and Figure 2 The first operation shown is 1111). This is to obtain, as shown in the diagram. Figure 1 and Figure 2 The second backup image 102 is shown.

[0067] 6. The backup application also performs block splitting on the changed blocks and calculates a hash value for each block.

[0068] 7. At time T3, the production server data was modified due to certain writes.

[0069] 8. At time T4, the user encrypts the data on VM1 (disk 1) using key = key1 (i.e., performs the following...). Figure 1 and 3 The first operation shown is 1111).

[0070] 9. The backup of VM1 begins, and a snapshot of the VM occurs at time T5.

[0071] 10. The backup application performs block splitting on the modified blocks and calculates a hash value for each block in the production server.

[0072] 11. The backup application verifies whether the hashes of these blocks exist in the backup repository. If they do not exist, the backup application needs to send their data and hashes to the backup repository for storage. Otherwise (if the hashes exist), there is no need to send their data.

[0073] 12. Since disk encryption was pre-performed in the backup repository using the same algorithm, key block size, and hash algorithm, most hash values ​​already exist and there is no need to send their data.

[0074] 13. The result is that most of the hash values ​​are transmitted over the network, along with the data written at time T4. Backup operations are completed faster, and VM snapshots can be deleted more quickly, thus improving VM performance.

[0075] Figure 2 and Figure 3 A schematic diagram of a production apparatus 110 and a backup entity 100 according to an embodiment of the present invention is shown. It is worth noting that... Figure 2 and Figure 3 It is continuous. In this embodiment, as... Figure 2As shown, after T2, encryption is performed on the first backup image 101 (using key 1). Therefore, all blocks containing data will be modified (in this example, blocks 0, 1, 4, 7, and 9). The hash values ​​of these blocks will be calculated and saved. It is worth noting that the second backup image 102 is actually created at a later point in time than T2.

[0076] It should be understood that the encryption process on backup entity 100 can be performed before or after the encryption process on production equipment 110. However, the encryption process on backup entity 100 must be performed before a new backup occurs to avoid transmitting all encrypted data.

[0077] like Figure 3 As shown, in T3, new data has been written to blocks 0 and 2 (in block 0, "a" is changed to "L"; in block 2, the new data "e" is written). Furthermore, in T4, after the encryption process is performed on production device 110, all blocks containing data will be modified (in this example, blocks 0, 1, 2, 4, 7, and 9).

[0078] According to this embodiment, the hash values ​​of the modified blocks 0, 1, 2, 4, 7, and 9 will be calculated. Backup entity 100 can further verify which hash values ​​exist in the backup repository. In this particular embodiment, only blocks 0 and 2 (data f(L, key 1) and f(e, key 1)) will be passed to backup entity 100.

[0079] Furthermore, according to one embodiment of the present invention, backup entity 100 may include an application installed on production equipment 110. This application may be a client-in-guest application (within production equipment 110) capable of identifying heavy I / O operations and notifying backup entity 100. Specifically, backup entity 100 may be configured to receive a first instruction 111 via this application.

[0080] In this embodiment, the backup system / administrator is unaware of the heavy I / O operations that will occur on the production server (VM or physical server) due to user actions. The client-side built-in application / agent provides a first instruction 111 to the backup entity 100 so that the same operations can be emulated (mirrored) in the backup repository.

[0081] Optionally, according to an embodiment of the present invention, the first operation 1111 may include one of the following operations: disk encryption, program upgrade, disk defragmentation, and application maintenance.

[0082] Disk defragmentation is the process of merging fragmented files on a user's hard drive. When data is written to the disk, files become fragmented, and there isn't enough contiguous space to hold the complete file. Storage algorithms break the data down to fit the available space.

[0083] Optionally, according to an embodiment of the present invention, the first instruction 111 may include an encryption key and an encryption algorithm. It is worth noting that when the first operation 1111 is disk encryption, the backup entity 100 needs to mimic disk encryption using the encryption key and encryption algorithm used in the production device 110.

[0084] It should be understood that in order to use the client-side built-in agent, the following issues should be considered: agent deployment, identification of heavy I / O operations, communication between the agent and the backup system, and the process of performing the first backup after heavy write operations on the production server.

[0085] The deployment of the client-side built-in agent takes into account both the hypervisor environment and the physical server environment.

[0086] Modern hypervisors support various built-in guest operations, such as injecting agents, running agents, getting responses, monitoring agents, and acquiring VM resources. Essentially, a backup system can inject an agent to run on a production server during the first full backup. This allows for automatic deployment across large VMs without manual intervention. For example, the vSphere Guest Software Development Kit (SDK) provides such built-in guest functionality, along with others. Therefore, all communication with the agent is not via direct TCP communication within the VM (on an open port), but rather through the more secure Hypervisor Application Programming Interface (API). However, a limitation is that it requires login credentials for each guest's running VM and VMware tools.

[0087] Regarding physical server environments, to deploy this client-embedded solution, the backup system should have full access to the physical server to inject, run, and monitor the agent. Similar to hypervisor solutions, it will inject the agent into the production server after the initial full backup of the computer. Furthermore, the client network should be configured to allow communication from the backup system (infrastructure network) to the server (production network) so that the backup system can communicate directly with the "injected" agent (TCP communication).

[0088] There may be agents for Linux and agents for Windows, so the backup system should know the OS type to inject the correct agent. This can be addressed by providing the backup system with credentials and the OS type. Alternatively, for hypervisors, the backup system can obtain the OS type by using the Guest SDK API. In this case, VMware tools will provide the information "internally" to the Guest API.

[0089] Once the agent is running on a production server, identifying heavy I / O operations is the same for both VMs and physical servers. For example, the agent can identify defragmentation running in Windows by monitoring the Event Viewer; for Linux, it can monitor ` / var / log / messages`, which logs various events. It's worth noting that the agent can "catch" events by monitoring related events when defragmentation starts running on volume "X," or if, for example, when swap defragmentation starts running on an application database. This is just one example; there are likely many more ways to detect such client-side built-in operations.

[0090] Typically, for each operating system, the agent will support a set of applications to detect such heavy I / O operations. For cryptographic operations (disk / VM), the agent should integrate with the cryptographic system running built into the client machine. This is not only intended to identify that encryption is in progress, but also to obtain the algorithm and key.

[0091] For hypervisors, the agent can update the backup system via the hypervisor API. In a physical environment, the agent can update the backup system via direct TCP communication. For operations like defragmentation, the agent can inform the backup system which volume / partition or application (a database file) the operation is starting on. For operations like encryption, the agent can provide the backup system with the algorithm, key, and which partition on the disk it is running on.

[0092] Once the first backup is initiated after the image operation is complete, the backup system will instruct the client's built-in agent to perform an internal snapshot (not a hypervisor snapshot). For example, in Windows, the agent can perform a Volume Shadow Service (VSS) snapshot, and in Linux, it can perform a Logical Volume Manager (LVM) snapshot. After the snapshot is created, the agent will divide the snapshot into blocks, calculate hash values, and update the hash value of each block in the backup system. In this way, only hash values ​​will be passed from the production network to the infrastructure (backup system) network. For each hash value that already exists in the backup repository, only some metadata updates will be performed. For new hash values ​​that do not exist in the backup repository, the backup system will request the agent to send the data for that block. This solution is suitable for both physical and virtual environments.

[0093] In summary, the client-side built-in solution "tailors" the agent to each OS type and application performing heavy writes on the production server, identifying the operation and providing relevant information to the backup system for image processing. Additionally, this solution reduces the amount of data sent from the production network (where the production servers are located) to the infrastructure network (backup system).

[0094] In a specific embodiment, the entire process of a virtual environment (a VM with a Windows OS) can be described as follows:

[0095] 1. The backup system configuration is used to perform backups of server 1 and receive server credentials.

[0096] 2. The backup system checks the OS type via the Guest API.

[0097] 3. The backup system injects the agent into the client.

[0098] 4. Perform a regular VM backup on the backup system.

[0099] 5. The user decides to run disk defragmentation.

[0100] 6. The monitoring event viewer's agent detected that disk defragmentation had begun on all disks.

[0101] 7. Agent update backup system: Defragmentation is running on all disks on server 1.

[0102] 8. The backup system performs this operation, namely defragmentation, on the backup repository of server 1.

[0103] 9. The image operation on the backup system is complete.

[0104] 10. The backup system policy triggers another backup.

[0105] 11. The backup system knows that an image processing operation has occurred, so instead of performing a "regular backup," it requests an agent to perform an operation on an internal snapshot (using VSS).

[0106] 12. The agent informs the backup system that the snapshot has been successfully created.

[0107] 13. The backup system requires the agent to send the hash values ​​of all snapshot blocks.

[0108] 14. For each hash value, if it already exists, the backup system updates the metadata in the backup repository; otherwise, the backup system requests the agent to send block data and stores it in the backup repository.

[0109] 15. Once the first backup following the successful mirroring operation is completed, the backup system will update the backup metadata of server 1, so that the next backup should be a "regular backup" (without agent assistance).

[0110] 16. According to the policy, a new backup is triggered, and this time the backup will be performed in the normal way without using an agent.

[0111] Figure 4 A backup system 400 according to an embodiment of the present invention is shown. System 400 includes a backup entity 100. Specifically, Figure 4 The backup entity 100 shown in the diagram can be Figure 1 The backup entity 100 is shown in the figure. In particular, the backup system also includes a backup repository. It is worth noting that the same elements in all the figures are labeled with the same reference numerals and have the same function.

[0112] According to one embodiment of the present invention, the backup system 400 may further include production equipment 110, wherein Figure 4 The production equipment 110 shown in the figure can be Figure 1 The production equipment 110 shown is typically a device that can be directly accessed by a user and includes user data (also referred to as a production system in the embodiments).

[0113] Optionally, according to one embodiment of the present invention, the production equipment 110 may be configured to create a first snapshot of the disk volume before the first operation 1111 is performed.

[0114] Optionally, according to an embodiment of the present invention, the production device 110 may also be configured to perform a first operation 1111 on the disk volume. Then, the production device 110 may be configured to create a second snapshot of the disk volume after the first operation 1111 is performed.

[0115] Figure 5 A method 500 for backing up a disk volume according to an embodiment of the present invention is shown. Specifically, the disk volume is a disk volume of a production device 110. In a particular embodiment of the invention, method 500 is performed by… Figure 1 or Figure 4 The device 100 shown is used for execution. Method 500 includes: step 501, creating a first backup image 101 of the disk volume in a backup repository; step 502, obtaining a first instruction 111 from production device 110, wherein the first instruction 111 indicates a first operation 1111 that production device 110 will perform on the disk volume; step 503, performing the first operation 1111 on the first backup image 101 to obtain a second backup image 102 in the backup repository.

[0116] It is worth noting that method 500 may further include actions as described in the aforementioned embodiments of backup entity 100.

[0117] This disclosure has been described in conjunction with various embodiments as examples and implementations. However, by studying the drawings, this disclosure, and the independent claims, those skilled in the art can understand and practice the claimed invention and implement other variations. In the claims and description, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "a" does not exclude multiple. A single element or other unit can perform the function of several entities or items recited in the claims. The mere fact that certain measures are recited in different dependent claims does not imply that combinations of these measures cannot be used in advantageous implementations.

[0118] Furthermore, any method according to embodiments of the present invention can be implemented in a computer program having code means, which, when executed by a processing means, causes the processing means to perform the steps of the method. The computer program is contained in a computer-readable medium of the computer program product. The computer-readable medium can substantially include any memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable PROM (EPROM), flash memory, electrically erasable PROM (EEPROM), or a hard disk drive.

[0119] Furthermore, those skilled in the art will recognize that embodiments of backup entity 100 include the necessary communication capabilities, in the form of functions, devices, units, and elements, for performing the solution. Examples of other such devices, units, elements, and functions include: processors, memories, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selection units, switches, interleavers, deinterleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, trellis-coded modulation (TCM) encoders, TCM decoders, power supply units, power supplies, communication interfaces, communication protocols, etc., which are appropriately arranged together to perform the solution.

[0120] Specifically, the processor of backup entity 100 may include, for example, one or more of the following: a central processing unit (CPU), a processing unit, a processing circuit, a processor, an ASIC, a microprocessor, or other processing logic capable of parsing and executing instructions. Therefore, the term "processor" can refer to a processing circuit that includes multiple processing circuits, such as any, some, or all of those mentioned above. The processing circuit can also perform data processing functions for data input, output, and processing, including data buffering and device control functions, such as call processing control, user interface control, etc.

Claims

1. A backup entity (100) for backing up a disk volume, wherein the disk volume is a disk volume of a production device (110), wherein the backup entity (100) is configured to: Create the first backup image of the disk volume in the backup repository (101). Obtain a first instruction (111) from the production equipment (110), wherein the first instruction (111) instructs the production equipment (110) to perform a first operation (1111) on the disk volume, wherein the first operation (111) is a disk encryption procedure; and Perform the first operation (1111) on the first backup image (101) to obtain the second backup image (102) in the backup repository.

2. The backup entity (100) according to claim 1, configured for: Obtain a first snapshot of the disk volume from the production equipment (110); and Back up the first snapshot to create the first backup image (101) of the disk volume in the backup repository.

3. The backup entity (100) according to claim 1, configured for: The second backup image (102) is chunked to obtain the first set of chunks; and Calculate the hash value for each block in the first group of blocks to obtain the first group of hash values.

4. The backup entity (100) according to claim 3, configured for: After the production equipment (110) performs the first operation (1111), a second snapshot of the disk volume is obtained from the production equipment (110); The second snapshot is divided into blocks to obtain the second set of blocks; as well as Calculate the hash value for each block in the second group of blocks to obtain the second group of hash values.

5. The backup entity (100) according to claim 4, wherein: The step of performing block division on the second snapshot includes instructing the production equipment (110) to perform block division on the second snapshot to obtain the second block.

6. The backup entity (100) according to claim 4, configured for: Compare the first set of hash values ​​with the second set of hash values; Determine a third set of hash values, wherein the third set of hash values ​​includes hash values ​​that are in the second set of hash values ​​but not in the first set of hash values; and Add the block associated with the hash value in the third set of hash values ​​to the second backup image (102) to obtain the third backup image (103) in the backup repository.

7. The backup entity (100) according to any one of claims 1 to 6, configured for: The backup entity (100) includes an application installed on the production equipment (110); and The backup entity (100) is configured to receive the first instruction (111) through the application.

8. The backup entity (100) according to any one of claims 1 to 6, wherein the first instruction (111) includes an encryption key and an encryption algorithm.

9. A backup system (400) comprising a backup entity (100) according to any one of claims 1 to 6 and the backup repository.

10. The backup system (400) according to claim 9 further includes the production equipment (110).

11. The backup system (400) according to claim 10, wherein the production equipment (110) is configured for: Before performing the first operation (1111), a first snapshot of the disk volume is created.

12. The backup system (400) according to claim 10 or 11, wherein the production equipment (110) is further configured to: Perform the first operation (1111) on the disk volume; and After performing the first operation (1111), a second snapshot of the disk volume is created.

13. A method (500) for backing up a disk volume, wherein the disk volume is a disk volume of a production device (110), the method comprising: Create (501) the first backup image (101) of the disk volume in the backup repository. Obtain (502) a first instruction (111) from the production equipment (110), wherein the first instruction (111) instructs the production equipment (110) to perform a first operation (1111) on the disk volume, wherein the first operation (1111) is a disk encryption procedure; as well as Perform (503) the first operation (1111) on the first backup image (101) to obtain the second backup image (102) in the backup repository.

14. A computer program product comprising program code, said program code being configured to: when implemented on a processor, perform the method according to claim 13.

Images