Data backup method and computing device

Abstract

The embodiment of the invention provides a data backup method and computing equipment, and relates to the technical field of virtual machines. The method comprises the steps that first bitmap data corresponding to current disk data is obtained and stored in a first file, the first file is stored in a nonvolatile memory, and the first bitmap data is used for indicating the data change condition of the current disk data relative to original disk data of a virtual machine; based on the first bitmap data, second bitmap data is determined and stored in a first file, and the second bitmap data is used for indicating the data change condition of the current disk data relative to the original disk data and the first backup frequency; according to the method, the changed data of the current disk data relative to the original disk data is stored, so that a new backup mode of the disk data of the virtual machine is realized, preparation is made for avoiding full-amount backup again aiming at the condition that backup data is abnormal, and a basis is provided for reducing storage resources and time consumption.

Description

Technical Field

[0001] The present application relates to the field of virtual machine technology, and in particular to a data backup method and computing device. Background Art

[0002] Currently, in order to better improve the resource utilization of physical computing devices, accelerate the deployment of applications, reduce energy consumption, and improve application compatibility, more and more enterprises and organizations use virtualization technology, that is, deploying virtual machines on physical computing devices to perform operations.

[0003] In order to protect the data security of enterprises and organizations, how to provide a data backup method for virtual machine disk data has become an urgent problem to be solved.

[0004] Currently, when backing up virtual machine disk data, incremental backup is often used to reduce backup resource consumption and speed up data backup. For example, CBT (Changed Block Tracking) technology can be used to identify the data on the virtual machine's current disk that has changed since the previous backup (hereinafter referred to as incremental data). This incremental data is then backed up, achieving incremental backup of the virtual machine's disk data.

[0005] However, during the incremental backup process, within a backup cycle, since the backup data chain formed by the backup cycle, except for the first backup which is a full data backup, the incremental backup data of each subsequent backup are the data that have changed since the previous backup. If a backup data in the backup data chain is damaged (or lost), the damaged (or lost) backup data and the backup data after it in the backup data chain cannot be used, and accordingly, it is no longer possible to continue incremental backup relative to the backup data in the backup data chain.

[0006] In related technologies, when this problem occurs, the incremental backup process for the current backup cycle is generally stopped and a new incremental backup process begins. Specifically, a full backup of the virtual machine's disk data is performed again to generate new full backup data. Subsequently, based on this new full backup data, each subsequent backup within a backup cycle only backs up the virtual machine's disk data that has changed since the previous backup, i.e., the incremental backup data. This process increases the storage resources and time consumption of data backup to a certain extent.

[0007] Therefore, how to provide a new data backup method to help solve the above problems becomes an urgent problem to be solved. Summary of the Invention

[0008] Embodiments of the present application provide a data backup method, apparatus, computing device, computer storage medium, and computer program product to implement a new method for backing up virtual machine disk data that reduces storage resources and time consumption.

[0009] In a first aspect, an embodiment of the present application provides a data backup method, the method comprising:

[0010] Obtaining first bitmap data corresponding to current disk data of the virtual machine, and storing the first bitmap data in a first file, wherein the first file is stored in a non-volatile memory, the first bitmap data being used to indicate data changes of the current disk data of the virtual machine relative to original disk data of the virtual machine;

[0011] Determining second bitmap data based on the first bitmap data, and storing the second bitmap data in the first file, the second bitmap data being used to indicate a data change of current disk data of the virtual machine relative to original disk data of the virtual machine and a first backup number;

[0012] First backup data is stored, where the first backup data is data obtained by changing the current disk data of the virtual machine relative to the original disk data of the virtual machine.

[0013] In the above process, a first file stored in a non-volatile memory is added. When backing up the disk data of the virtual machine, the first bitmap data corresponding to the current disk data of the virtual machine is stored in the first file to achieve persistent storage of the first bitmap data that can indicate the data changes of the current disk data relative to the original disk data of the virtual machine; then, based on the first bitmap data, second bitmap data indicating the data changes of the current disk data relative to the original disk data and the first backup number is determined, and the second bitmap data is stored in the first file, and the first backup data is stored. In this way, the second bitmap data can persistently indicate that the first backup data is the data stored in the backup process corresponding to the first backup number. Accordingly, after multiple backup processes, the second bitmap data stored in the first file can persistently indicate which data blocks in the disk have the backup data stored in each backup. This provides a basis for realizing disaster recovery backup in subsequent backup processes. For example, during a backup process, if it is determined that the backup data stored in the previous backup process is damaged, the backup data in which data blocks on the disk are stored during each backup (that is, a backup corresponding to a backup number identifier) ​​can be combined with the second bitmap data to more conveniently locate the backup data after the damaged backup data, and then the damaged backup data and the backup data after it can be re-backed up to achieve disaster recovery backup without the need for a full backup again, providing a basis for reducing storage resources and time consumption during the data backup process, and improving the disaster recovery capability of the backup data.

[0014] In some possible examples, before obtaining the first bitmap data corresponding to the current disk data of the virtual machine, it also includes: creating a snapshot based on the current disk data of the virtual machine; after storing the first backup data, it also includes: merging the snapshot with the current disk data of the virtual machine.

[0015] In the above example, at the beginning of the backup process, a snapshot is created based on the current disk data of the virtual machine, and after the first backup data is stored, the snapshot is merged with the current disk data to avoid loss of new data written by the user during the backup process.

[0016] In some possible examples, before obtaining the first bitmap data corresponding to the current disk data of the virtual machine, it also includes: creating a first file corresponding to the virtual machine, wherein the first file includes a metadata area, a dynamic bitmap area and a static bitmap area, the metadata area is used to store the metadata of the first file, the dynamic bitmap area is used to store the first bitmap data, and the static bitmap area is used to store the second bitmap data.

[0017] In the above example, a first file is created for storing the first bitmap data and the second bitmap data to provide a basis for persistent storage of the first bitmap data and the second bitmap data. The first bitmap data and the second bitmap data are respectively stored in different areas of the first file to facilitate the management of different bitmap data.

[0018] In some possible examples, the dynamic bitmap area includes a first area and a second area, which are used to alternately store the first bitmap data corresponding to each backup process. In this example, the dynamic bitmap area includes the first area and the second area to ensure the integrity of the first bitmap data and facilitate management of the stored first bitmap data.

[0019] In some possible examples, the metadata area also stores a first bitmap check code, and the first bitmap check code is generated based on the first bitmap data corresponding to the previous backup process; before obtaining the first bitmap data corresponding to the current disk data of the virtual machine, it also includes: after detecting a loading request of the virtual machine to load the first bitmap data into its host machine memory, generating a second bitmap check code based on the first bitmap data corresponding to the previous backup process currently stored in the dynamic bitmap area, and the loading request is sent after the virtual machine is restarted; comparing the first bitmap check code with the second bitmap check code; if the first bitmap check code is the same as the second bitmap check code, loading the first bitmap data currently stored in the dynamic bitmap area into the host machine memory.

[0020] In the above example, after detecting the load request for loading the first bitmap data into its host machine memory sent after the virtual machine is restarted, the first bitmap check code generated and stored when the first bitmap data corresponding to the previous backup process is stored in the first file is first used to verify the first bitmap data corresponding to the previous backup process stored in the dynamic bitmap area when the load request is obtained, that is, the first bitmap check code is compared with the second bitmap check code. If the first bitmap check code is the same as the second bitmap check code, it is determined that the first bitmap data stored in the first file has not been modified, that is, the first bitmap data corresponding to the previous backup process currently stored in the first file is accurate and consistent with the first bitmap data corresponding to the previous backup process stored in the first file. At this time, the first bitmap data corresponding to the previous backup process currently stored in the dynamic bitmap area is loaded into the host machine memory to ensure the accuracy of the loaded first bitmap data, thereby realizing effective perception of whether the first bitmap data loaded from the first file to the host machine memory is consistent.

[0021] In some possible examples, after storing the second bitmap data in the first file, the method further includes: initializing the bitmap data in the host memory of the virtual machine.

[0022] In the above example, after storing the second bitmap data in the first file, the bitmap data in the host machine of the virtual machine can also be initialized, that is, the value of the bit indicating data change is modified to indicate that the data has not changed, so as to better and more accurately indicate the data changes in the next backup process.

[0023] In some possible examples, storing the first backup data includes: performing integrity verification on each second backup data backed up before the current backup; if the integrity verification of each second backup data passes, storing the first backup data.

[0024] In the above example, after the first backup data is stored, the integrity of the second backup data backed up before it is checked. If the integrity check of each second backup data passes, it can be indicated that the data backed up before the first backup data (i.e., this backup) has not been damaged. Then the first backup data can continue to be stored to ensure the effective storage of the backup data and the availability of the backup data chain composed of the second backup data and the first backup data to avoid any damage to the second backup data. Even if the first backup data continues to be stored, it cannot be used (used to restore the corresponding state of the virtual machine), resulting in a waste of storage resources and storage time.

[0025] In some possible examples, the integrity check of each second backup data backed up before the current backup includes: obtaining a first data verification code corresponding to each second backup data, wherein the first data verification code corresponding to each second backup data is generated and stored based on the corresponding second backup data when the corresponding second backup data is backed up; generating each second data verification code based on each currently stored second backup data; for each second backup data, comparing the first data verification code and the second data verification code corresponding to the second backup data, wherein if the comparison result indicates that the first data verification code and the second data verification code corresponding to each second backup data are the same, it is determined that the integrity check of each second backup data has passed.

[0026] In the above example, by comparing the first data verification code and the second data verification code corresponding to each second backup data, it is determined whether each second backup data is damaged (for example, modified). If the comparison result indicates that the first data verification code and the second data verification code corresponding to each second backup data are the same, it is determined that each second backup data at the time of this backup is consistent with the second backup data itself when it was backed up, and none of them has been damaged or modified, thereby achieving integrity verification of each second backup data.

[0027] In some possible examples, it also includes: if the integrity check of the third backup data in each second backup data fails, determining the second backup number corresponding to the third backup data; based on the second backup number and the second bitmap data, determining the disaster recovery backup data of the virtual machine, the disaster recovery backup data including the data indicated by the second backup number, the first backup number and the backup number identifiers therebetween; storing the disaster recovery backup data, and using the second backup number, the first backup number and the backup number identifiers therebetween to identify the disaster recovery backup data.

[0028] In the above example, when the integrity check of the third backup data fails, it can be determined that the third backup data is damaged (for example, modified). When the backup process adopts the incremental backup method, the third backup data and the second backup data thereafter cannot be used (used to restore the corresponding state of the virtual machine), that is, the disaster recovery backup data is directly determined and stored, that is, the disaster recovery backup process is executed, avoiding re-full backup, and reducing the storage resources and time consumption of the backup process.

[0029] In some possible examples, the first bitmap data includes a specified bit set to a specified value, and the specified value is used to indicate the changed data of the current disk data of the virtual machine relative to the original disk data of the virtual machine; determining the second bitmap data based on the first bitmap data includes: replacing the specified value of the specified bit in the first bitmap data with the first backup number to obtain the second bitmap data.

[0030] In the above example, the value of the designated bit in the first bitmap data, which indicates the changed data of the current disk data relative to the original disk data, is replaced with the first backup number to obtain the second bitmap data, so that the second bitmap data can indicate the changed data of the current disk data relative to the original disk data (i.e., the data that needs to be backed up) and the first backup number (i.e., the backup), and the correspondence between them.

[0031] In some possible examples, storing the first backup data includes: storing the first backup data in a designated storage area of ​​the host machine of the virtual machine; or, storing the first backup data in a backup pool corresponding to the virtual machine; or, storing the first backup data in a designated storage area of ​​the host machine of the virtual machine; and storing the first backup data stored in the designated storage area to the backup pool corresponding to the virtual machine.

[0032] In the above examples, storage methods for storing the first backup data are provided, such as storing on the host machine, storing in the backup pool, or first storing on the host machine and then storing in the backup pool, so as to implement multiple backup storage methods for data.

[0033] In some possible examples, the format of the first file is any one of the following formats: raw format or qcow2 format, so as to accurately and conveniently store the first bitmap data and the second bitmap data persistently.

[0034] In a second aspect, an embodiment of the present application provides a data backup device, the device comprising:

[0035] a first acquisition module configured to acquire first bitmap data corresponding to the current disk data of the virtual machine, and store the first bitmap data in a first file, wherein the first file is stored in a non-volatile memory, and the first bitmap data is used to indicate a data change in the current disk data of the virtual machine relative to the original disk data of the virtual machine;

[0036] a first determining module configured to determine second bitmap data based on the first bitmap data, and store the second bitmap data in the first file, the second bitmap data being used to indicate a data change in the current disk data of the virtual machine relative to the original disk data of the virtual machine and a first backup number;

[0037] The first storage module is configured to store first backup data, where the first backup data is data representing changes in the current disk data of the virtual machine relative to the original disk data of the virtual machine.

[0038] In a third aspect, an embodiment of the present application provides a computing device, comprising: a first memory for storing a program; a second memory for storing a first file, the second memory being a non-volatile memory; and at least one processor for executing the program stored in the first memory; wherein, when the program stored in the first memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0039] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

[0040] In a fifth aspect, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

[0041] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 A schematic diagram of an incremental backup scenario provided in an embodiment of the present application;

[0043] Figure 2 This is a schematic diagram of a data backup application scenario provided by an embodiment of the present application;

[0044] Figure 3 This is a flow chart of a data backup method provided in an embodiment of the present application;

[0045] Figure 4 This is a schematic diagram of the structure of the first file provided in the embodiment of the present application;

[0046] Figure 5 This is a schematic diagram of a process for updating the second bitmap data in the first file provided in an embodiment of the present application;

[0047] Figure 6 This is a schematic diagram of a data backup process in a specific embodiment of the present application;

[0048] Figure 7 This is a flowchart of another data backup method in an embodiment of the present application;

[0049] Figure 8 This is a schematic diagram of a disaster recovery backup scenario in an embodiment of the present application;

[0050] Figure 9 This is a structural diagram of a data backup device in a specific embodiment of the present application;

[0051] Figure 10 It is a structural diagram of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0052] The term "and / or" as used herein describes an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. The symbol " / " as used herein indicates that the related objects are in an "or" relationship, for example, A / B means either A or B.

[0053] The terms "first" and "second" in this specification and claims are used to distinguish different objects rather than to describe a specific order of objects. For example, "first response message" and "second response message" are used to distinguish different response messages rather than to describe a specific order of response messages.

[0054] In the description of this document, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", "circumferential", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operate in a specific orientation.

[0055] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0056] To facilitate understanding of the technical solutions of the embodiments of the present application, the terms involved in this document are explained below.

[0057] A virtual machine (VM) is a complete computer system with complete hardware system functions, running in a completely isolated environment, simulated by software. Any work that can be done in a physical computer (also called a physical computing device) can be done in a virtual machine. When creating a virtual machine in a physical computing device, part of the physical computing device's hard disk and memory capacity is used as the virtual machine's hard disk and memory capacity. Each virtual machine has its own independent CMOS (Complementary Metal-Oxide-Semiconductor), hard disk, and operating system, and can be operated on the virtual machine just like a physical computing device. The physical computing device that creates and runs a virtual machine can be called the host machine where the virtual machine resides.

[0058] A virtual disk is a virtualized hard disk that can be divided into N data blocks (Block IDs) to store and back up disk data written by the corresponding virtual machine. The disk data stored on a virtual disk, i.e., the disk data written by a virtual machine to its corresponding virtual disk, can include, but is not limited to, the virtual machine's user data and the virtual machine's operating system data.

[0059] QEMU is an open-source virtualization platform that can emulate a variety of hardware platforms, including x86 and ARM, and supports multiple operating systems, such as Linux, Windows, and FreeBSD. QEMU can be used in a variety of application scenarios, including virtualization, simulation, debugging, and testing. QEMU can simulate a single physical computing device into multiple virtual machines, providing users with an isolated environment to run different applications and operating systems. QEMU is lightweight virtual machine software that is easy to install and configure, and offers excellent portability and cross-platform capabilities.

[0060] QEMU can also manage virtual machines and track the virtual machine's virtual disk I / O (Input / Output) in real time. Upon receiving a disk I / O write request from the virtual machine, it writes the data carried in the request to one or more data blocks on the virtual disk. Based on Changed Block Tracking (CBT) technology, it supports incremental backups of virtual machines. Specifically, it creates bitmap data (i.e., a bitmap table) in the virtual machine's host memory and updates this bitmap data based on the ID (Identity Document) of the data block to which the data was written (i.e., the changed block). The bitmap data includes bits corresponding to the ID of each data block on the virtual disk to identify whether the data stored in the data block has changed. When the value of the bit corresponding to the data block's ID is a specified value (e.g., 1), it indicates that the data in the corresponding data block has changed compared to the previous backup. When the value of the bit corresponding to the data block's ID is an unspecified value (e.g., 0), it indicates that the data in the corresponding data block has not changed compared to the previous backup. When performing backup, only the modified data blocks (ie, the data blocks marked as "1" in the bitmap data) may be backed up, without having to perform a full backup of the entire virtual disk (ie, all data blocks).

[0061] Incremental backup is a data backup method that, after a full backup, backs up only the data that has been added or modified since the previous one. This means that the first incremental backup targets the data that has been added or modified since the full backup (i.e., the data in the data blocks that have changed, also known as incremental data). The second incremental backup targets the data that has been added or modified since the first incremental backup, and so on until the next full backup, which constitutes a backup cycle.

[0062] like Figure 1The figure shows an exemplary scenario diagram of incremental backup, in which, at time T1, a full backup is performed on the data in the disk to obtain full backup data #1; at time T2, an incremental backup is performed on the data in the disk to obtain incremental backup data *1, which is the data that has changed relative to the full backup data #1 at time T1; at time T3, an incremental backup is performed on the data in the disk to obtain incremental backup data *2, which is the data that has changed relative to the data in the disk at time T1; and so on. At time Tn, incremental backup data *Tn-1 is obtained.

[0063] Bitmap: It is a collection of bits and a data structure that can be used to record a large number of 0-1 states. Its advantage is that it can save a large number of 0-1 states with a very high space utilization.

[0064] A snapshot is a technology that records the state of all data on a virtual disk, preserving the complete state of the disk at a specific moment. This snapshot can then be used to restore the state at that moment (for example, to the state of a virtual machine at that moment). A snapshot can also be understood as a completely usable copy of a specified data set (such as a virtual disk), consisting of an image of the corresponding data at a specific point in time (the point in time when the copy was started). A snapshot can be a copy or a replica of the data it represents.

[0065] As mentioned above, during the incremental backup process, within a backup cycle, since the incremental backup data of each backup in the backup data chain formed by the backup cycle are the data that have changed since the previous backup, if a certain backup data in the backup data chain is damaged (or lost), then the damaged (or lost) backup data and the backup data after it in the backup data chain cannot be used, and accordingly, it is no longer possible to continue incremental backup relative to the backup data in the backup data chain.

[0066] Currently, when this problem occurs, the incremental backup process for that backup cycle is typically stopped and a new incremental backup process begins. Specifically, a full backup is performed on the virtual machine's virtual disk to generate new full backup data. Subsequently, based on this new full backup data, each backup only backs up the data on the virtual machine's virtual disk that has changed since the previous backup, i.e., the incremental backup data. This process significantly increases the storage resources and time consumption of data backup.

[0067] In view of this, an embodiment of the present application provides a data backup method, wherein, during the data backup process, first bitmap data corresponding to the current disk data of the virtual machine is obtained, and the first bitmap data is stored in a first file, the first file is stored in a non-volatile memory, and the first bitmap data is used to indicate the data changes of the current disk data of the virtual machine relative to the original disk data of the virtual machine; based on the first bitmap data, second bitmap data is determined, and the second bitmap data is stored in the first file, the second bitmap data is used to indicate the data changes of the current disk data of the virtual machine relative to the original disk data of the virtual machine and the first backup number; the first backup data is stored, and the first backup data is the data of the changes of the current disk data of the virtual machine relative to the original disk data of the virtual machine.

[0068] Based on the above backup process, data backup of the virtual machine's disk data is achieved to protect the data security of the virtual machine, and the second bitmap data can persistently indicate that the first backup data is the data stored in the backup process corresponding to the first backup number. During multiple backup processes, the second bitmap data stored in the first file can persistently indicate which data blocks in the virtual disk of the virtual machine are used to store backup data at each backup, thus providing a basis for disaster recovery backup in subsequent data backup processes. For example, during a backup process, if it is determined that the backup data stored in the previous backup process is damaged, the second bitmap data stored in the first file can be combined with the disk data in which data blocks in the virtual disk of the virtual machine are stored at each backup (i.e., a backup corresponding to a backup number identifier) ​​to more conveniently locate the damaged backup data and the backup data after it, and then the damaged backup data and the backup data after it can be re-backed up to achieve disaster recovery backup without the need for a full backup again. The above process provides a basis for reducing storage resources and time consumption during the backup process, and can enhance the disaster recovery capability of the backup data.

[0069] To facilitate understanding of the technical solution of the embodiment of the present application, the data backup process of the embodiment of the present application is introduced below.

[0070] For example, Figure 2 A schematic diagram of an application scenario of an embodiment of the present application is shown. Figure 2 The data backup system shown includes a computing device and a backup pool. The backup pool can be composed of one or more storage devices (or computing devices that can provide storage space). The computing device includes a processor, a non-volatile memory, and a memory. The processor, the non-volatile memory, and the memory are connected via a bus. The computing device can deploy multiple virtual machines (such as Figure 2The virtual machines (VM1 and VM2) shown in FIG may also be deployed with a virtualization platform and a backup unit. Accordingly, the computing device can use its processor to run the deployed virtual machines, virtualization platform, and backup unit. The computing device uses the processor to run the virtual machines to provide various business services to users, and uses the processor to run the virtualization platform to manage the virtual machines. The computing device can also use the processor to run the backup unit to provide data backup services for the virtual machines. It can be understood that the computing device serves as the host for the virtual machines it runs.

[0071] like Figure 2 As shown, taking VM1 as an example, the virtualization platform can track the virtual disk IO of the virtual machine in real time. After receiving the disk IO write request of VM1, the data carried by the disk IO write request is written into one or more data blocks of the virtual disk of VM1; and the data changes of each data block in the virtual disk of VM1 are recorded in the bitmap data of VM1 in the memory of the computing device, that is, the data changes of the current disk data of VM1 relative to the original disk data of VM1 are recorded.

[0072] Subsequently, when it is determined that VM1's data needs to be backed up, the backup unit creates a snapshot based on the virtual machine's current disk data through the virtualization platform; and through the virtualization platform, obtains the bitmap data corresponding to VM1's current disk data from the computing device's memory, which is called the first bitmap data. The backup unit then stores the first bitmap data in a first file, which is stored in the aforementioned non-volatile memory. The first bitmap data is used to indicate the data changes of VM1's current disk data relative to its original disk data. Next, the backup unit determines the second bitmap data based on the first bitmap data, and stores the second bitmap data in the first file. The second bitmap data is used to indicate the data changes of VM1's current disk data relative to its original disk data and the first backup number; and stores the first backup data, which is the data of the changes of VM1's current disk data relative to its original disk data.

[0073] During the backup process, the virtualization platform may receive a new disk IO write request from VM1. At this time, in order to avoid the loss of data carried by the new disk IO write request during the backup process, the virtualization platform will write the data carried by the disk IO write request of VM1 received during the backup process into the snapshot created by the backup process; then, after storing the first backup data, the snapshot of the newly written disk data will be merged with the aforementioned current disk data of VM1.

[0074] In some examples, in order to ensure accurate recording of newly added disk data after this backup, the backup unit can also initialize the bitmap data in the memory of the computing device after storing the second bitmap data in the first file, that is, replace the value of the bit set to a specified value (for example, 1) in the bitmap data in the memory with a non-specified value (for example, 0), so that the data changes of VM1's disk data can be accurately recorded again based on the bitmap data in the memory.

[0075] Continuing with the above example, after initializing the bitmap data in the memory of the computing device and merging the snapshot with the current disk data of VM1, the backup unit also determines the data in the snapshot that has changed relative to the aforementioned current disk data of VM1 as target data; and, based on the target data, updates the initialized bitmap data in the memory of the computing device.

[0076] In some specific examples, the data blocks to which the target data belongs, called change blocks, can be determined based on the target data. Accordingly, based on the change blocks to which the target data belongs, the values ​​of the bits corresponding to the change blocks in the initialized bitmap data in the memory of the computing device can be replaced from non-specified values ​​(such as 0) to specified values ​​(such as 1).

[0077] exist Figure 2 In the data backup system shown, the communication between the virtual machines, virtualization platforms and backup units deployed by the computing devices can be achieved through internal calls of the processor, and the communication between the computing devices and the backup pool can be achieved through network requests.

[0078] In some possible examples, the backup unit may exist in the form of a plug-in of the virtualization platform. Accordingly, the backup unit may be considered as a functional unit of the virtualization platform.

[0079] It should be understood that the structure of the data backup system in the above example is merely illustrative and does not limit the structure of the data backup system. In other examples, the data backup system may include multiple computing devices and multiple backup pools, wherein the aforementioned virtualization platform, backup unit, and virtual machine may be deployed on different computing devices, and each backup pool may be composed of one or more storage devices (or computing devices that can provide storage space). And so on.

[0080] Next, based on the description of the above examples, the data backup method provided in the embodiment of the present application is introduced.

[0081] For example, Figure 3 The flowchart of a data backup method provided by an embodiment of the present application is shown in FIG. The method can be applied to a computing device (the computing device can be Figure 2The computing device shown is hereinafter referred to as the first computing device), and the first computing device is deployed with the aforementioned backup unit, through which data backup services can be provided for one or more virtual machines. Exemplarily, the one or more virtual machines can be built and managed through a virtualization platform.

[0082] In some possible examples, the first computing device may also be deployed with a virtualization platform, so that the virtualization platform and the backup unit can be used together to manage one or more virtual machines and provide data backup services. In other possible examples, the virtualization platform can be deployed in a non-first computing device, and accordingly, the first computing device can be used together with the device that deploys the virtualization platform to manage one or more virtual machines and provide data backup services.

[0083] Among them, each virtual machine corresponds to a virtual disk, and a single virtual disk can be divided into one or more data blocks for storing the disk data of the corresponding virtual machine. In a possible example, the data blocks of a single virtual disk can be evenly divided according to the size of the storage space. For example, when the virtualization platform is QEMU, the virtual disk can be in raw format or qcow2 format. It can be understood that the virtual disk can also be in other formats, and the embodiment of the present application does not limit the specific storage format of the virtual disk. The data backup process provided in the embodiment of the present application can realize the persistent storage of the bitmap data corresponding to the virtual disk, and can persistently record the correspondence between each backup process and the backup data stored in each backup process.

[0084] In some other possible examples, the one or more virtual machines may be deployed in one or more second computing devices, which may or may not include the first computing device. The following description uses the one or more second computing devices as the first computing device as an example. When one or more virtual machines are deployed on a first computing device, the first computing device may be referred to as the host of the one or more virtual machines. Correspondingly, the memory of the first computing device may be referred to as the host memory of the one or more virtual machines deployed thereon.

[0085] The data backup process is described below using any virtual machine A from one or more virtual machines as an example. For data backup processes corresponding to other virtual machines, refer to the data backup process corresponding to virtual machine A. In this embodiment of the present application, a first computing device uses an incremental backup method to back up the disk data in virtual disk A of virtual machine A (hereinafter referred to as the disk data of virtual machine A). The data backup process is described below using an example in which the backup unit, virtualization platform, and virtual machine A are all running on the first computing device.

[0086] like Figure 3 As shown, the method may include the following steps S310-S340:

[0087] In step 310, a first file is created. The first file may correspond to virtual machine A, wherein the first file includes a metadata area, a dynamic bitmap area, and a static bitmap area. The metadata area is used to store metadata of the first file, the dynamic bitmap area is used to store bitmap data obtained from the host memory of virtual machine A (hereinafter referred to as the first bitmap data); the static bitmap area is used to store second bitmap data, wherein the second bitmap data may be used to indicate data changes of disk data of virtual machine A and the number of backup times of each backup process.

[0088] In some possible examples, the backup unit may create the first file based on the size of virtual disk A corresponding to virtual machine A. In some cases, the first file may be created by the backup unit before starting virtual machine A, or during the operation of virtual machine A. Exemplarily, the first file is stored in a non-volatile memory, which may be provided by the first computing device or by a device other than the first computing device.

[0089] In some examples, when starting virtual machine A, if its corresponding first file has not yet stored the relevant data of virtual machine A during the backup process (such as the first bitmap data), then when starting virtual machine A, the virtualization platform can create and store the bitmap data corresponding to virtual machine A in the host machine memory of virtual machine A.

[0090] The bitmap data corresponding to virtual machine A may include bits corresponding to data blocks in virtual disk A, each bit being used to store a value indicating a change in data in the corresponding data block. For example, if the value of the bit corresponding to the i-th data block in the bitmap data is set to a specified value (e.g., 1), it may indicate that the data in the i-th data block of virtual disk A has changed; if the value of the bit corresponding to the i-th data block is set to a non-specified value (e.g., 0), it may indicate that the data in the i-th data block of virtual disk A has not changed.

[0091] Among them, in the case where the disk data in virtual disk A has not been backed up, the aforementioned "change" (or no change) in the data change in the i-th data block of virtual disk A may be relative to the data in the i-th data block of virtual disk A when virtual machine A is started; in the case where disk data A has been backed up, the aforementioned "change" (or no change) in the data change in the i-th data block of virtual disk A may be relative to the data in the i-th data block when the data storage of the previous backup process for virtual disk A is completed.

[0092] In some other examples, when starting virtual machine A, if the first file already stores bitmap data obtained from the host machine memory during the last backup during the previous operation process of virtual machine A before this startup, the backup unit can load the bitmap data stored in the first file into the host machine memory, so that the virtualization platform can continue to track the data changes of its virtual machine A's disk data based on the bitmap data.

[0093] It can be understood that, when there is no abnormality in the first file corresponding to virtual machine A, the step of creating the first file can be performed once. Accordingly, when there is no abnormality in the first file, each startup of virtual machine A and each backup during operation can be performed on the basis of the first file. If there is an abnormality in the first file, a new first file corresponding to virtual machine A can be recreated to store the first bitmap data obtained from the host machine memory and the second bitmap data determined based on the first bitmap data. Alternatively, if there is an abnormality in the first file, the first file corresponding to virtual machine A can be initialized to continue to follow the data backup process of virtual machine A based on the initialized first file, and the first bitmap data of each data backup process of virtual machine A and the second bitmap data determined based on the first bitmap data can continue to be stored in the initialized first file.

[0094] In some examples, one virtual machine may correspond to one first file, or multiple virtual machines may correspond to one first file. In this case, the first bitmap data and second bitmap data of each of the multiple virtual machines may be stored in the first file.

[0095] The first file is introduced below, wherein one virtual machine corresponds to one first file as an example for explanation.

[0096] It is understood that the first file is used to assist the backup unit in using an incremental backup method (e.g., using CBT technology) to back up the disk data of virtual machine A. In some possible examples, the first file can also be referred to as a CBT file. In some examples, the format of the first file can be raw format or qcow2 format, or the format of the first file can also be other file formats. The embodiments of the present application do not limit the format of the first file.

[0097] In one possible implementation, Figure 4 As shown, the first file may include three parts, which may also be referred to as three areas, wherein the first part is the metadata area, such as Figure 4 The CBT Header Region shown in the figure; the second part is the dynamic bitmap area, such as Figure 4The Dirty Bitmap Region shown in the figure, the third part is the static bitmap area, such as Figure 4 The Static Bitmap Region shown.

[0098] For example, Figure 4 As shown, the metadata area includes a sub-area for storing file metadata of the first file (such as Figure 4 Global Meta shown), a sub-area for storing metadata of a dynamic bitmap area (such as Figure 4 DirtyBitmap Meta) and a sub-area for storing metadata of a static bitmap area (such as Figure 4 The size of the metadata area can be set as required, for example Figure 4 As shown, it can be set to 2K (kilobytes), that is, the metadata area is located at an offset of 0 to 2K in the first file.

[0099] Exemplarily, the metadata of the first file includes, but is not limited to, at least one of the following information: file format (file magic), file version, size of the corresponding virtual disk A (img_size), file creation time (create_time), size of each data block in virtual disk A (block_size), and a data integrity checksum (also referred to as a file checksum) corresponding to the first file. The file checksum may be generated and stored based on the updated content after each update of the first file, and may be used to verify the data integrity of the first file before the next update of the first file.

[0100] The metadata of the dynamic bitmap area includes, but is not limited to, at least one of the following information: the dynamic backup times value (e.g. Figure 5 The ChgID1 shown indicates the number of times the dynamic bitmap area stores the first bitmap data. Since the first bitmap data needs to be stored in the dynamic bitmap area once during each backup process, the value of ChgID1 is equivalent to the number of backups corresponding to the latest backup of virtual machine A), the status of the dynamic bitmap area (for example, including three states, the first state normal indicates that the first file is normal, the second state updating indicates that the memory modification is being tracked, that is, the first bitmap data is being obtained from the host memory of virtual machine A, and the third state inva l id indicates that the first file is abnormal), and the data integrity check code corresponding to the dynamic bitmap area (hereinafter referred to as the first bitmap check code).

[0101] The first bitmap check code may be generated based on the first bitmap data j stored in the dynamic bitmap area after the first bitmap data j obtained from the host machine memory during the j-th backup process is stored in the dynamic bitmap area during each backup process (hereinafter, the j-th backup process is used as an example, where j is a positive integer). The first bitmap check code is used to perform a data integrity check on the first bitmap data stored in the first file before loading it into the host machine memory where virtual machine A resides after virtual machine A is restarted.

[0102] The metadata of the static bitmap area includes, but is not limited to, at least one of the following information: static backup times (e.g. Figure 5 The ChgID2 shown indicates the number of times the static bitmap area stores the second bitmap data. Since the second bitmap data needs to be stored once in the static bitmap area during each backup process, the corresponding ChgID2 value is also equal to the number of backups corresponding to the latest data backup of virtual machine A), the status of the static bitmap area (for example, including two states, the first state normal, that is, the first file is normal, and the second state pre-updating, that is, the static bitmap area is ready and to be persisted), and the data integrity check code corresponding to the static bitmap area (hereinafter referred to as the second bitmap check code).

[0103] The second bitmap check code may be generated and stored based on the second bitmap data j stored in the static bitmap area after the second bitmap data j determined based on the first bitmap data j is stored in the j-th backup process. The second bitmap check code may be used to perform a data integrity check on the second bitmap data j stored in the static bitmap area during the j+1-th backup process, before the second bitmap data j+1 determined based on the first bitmap data j+1 is stored in the static bitmap area.

[0104] It can be understood that the aforementioned first bitmap check code and second bitmap check code may be MD5 values ​​or check codes generated using other check code algorithms (such as a hash algorithm).

[0105] In some possible examples, if during the backup process, after the first bitmap data is stored in the first file, the value of ChgID1 has not been updated in time, and the first computing device is abnormally shut down, then the value of ChgID1 in the first file may not be equal to the backup number identifier corresponding to the latest data backup.

[0106] In some possible examples, the determination of whether the first file is normal or abnormal can be achieved in the following manner: for example, whether the first file is normal can be determined by comparing whether the dynamic backup number value and the static backup number value are the same; wherein, if the dynamic backup number value and the static backup number value are different, the first file is abnormal; if the dynamic backup number value and the static backup number value are the same, and the first bitmap data and the second bitmap data stored in the first file are respectively verified to be not modified through the aforementioned first bitmap check code and the second bitmap check code, then it can be determined that the first file is normal; if the dynamic backup number value and the static backup number value are the same, but the first bitmap data and / or the second bitmap data stored in the first file are respectively verified to be modified through the aforementioned first bitmap check code and / or the second bitmap check code, then it is determined that the first file is abnormal.

[0107] In some possible examples, in order to better ensure the data security of virtual machine A, the dynamic bitmap area may include two sub-regions (region1 and region2 respectively), which are used to write the first bitmap data obtained from the host memory of virtual machine A in turn. Accordingly, the metadata of the dynamic bitmap area may also include: information indicating that the first bitmap data is written to region1 or region2, namely current_db. Correspondingly, the metadata of the static bitmap area may also include: information indicating that the second bitmap data is updated based on the first bitmap data stored in region1 or region2 of the dynamic bitmap area, namely current_merge. Exemplarily, when writing the first bitmap data to region1, if region1 already stores bitmap data, the first bitmap data can be written to region1 to overwrite the bitmap data already stored in region1. If current_db indicates that the first bitmap data is written to region1, current_merge indicates that the second bitmap data is determined based on the first bitmap data stored in region1.

[0108] Since the first file is stored in a non-volatile memory, the first bitmap data stored in the dynamic bitmap area in the first file will not be lost due to power failure of the first computing device or shutdown of virtual machine A. Accordingly, it can be said that the dynamic bitmap area can be used to persistently store the first bitmap data obtained from the host machine memory where virtual machine A is located.

[0109] The size of the dynamic bitmap area can be set according to the requirements (such as the number of data blocks in virtual disk A) so that the integrity of the first bitmap data can be stored. For example, each sub-region (region1 and region2) in the dynamic bitmap area can be set to 4M (megabytes). Figure 4As shown, the dynamic bitmap area is located at an offset of 2K to 8M+2K in the first file. The size of each bit in the first bitmap data corresponding to each data block in the virtual disk A can be set to 1 bit.

[0110] Since the first file is stored in a non-volatile memory, the second bitmap data stored in the static bitmap area of ​​the first file will not be lost due to power failure of the first computing device or shutdown of virtual machine A. Accordingly, it can be said that the static bitmap area can realize persistent storage of the second bitmap data, that is, it can persistently store which data blocks in virtual disk A are stored during each backup process. The size of the static bitmap area is generated according to the size of virtual disk A, such as Figure 4 As shown, the static bitmap area may be located after the offset of the first file is 8M+2K.

[0111] In some possible exemplary embodiments, the second bitmap data includes: bits corresponding to each data block in virtual disk A, and the second bitmap data can realize the storage of the corresponding relationship between the backup number identifier of each backup process and the backup data that needs to be stored in each backup process (that is, the data block in virtual disk A to which the backup data belongs). For example, in the j-th backup process, its first bitmap data j indicates that the bit corresponding to data block 1 in virtual disk A is a specified value (for example, 1), that is, the first bitmap data indicates that the data in data block 1 is data that has changed relative to the original disk data of data block 1 in virtual disk A. In the above case, the value of the bit corresponding to data block 1 in the second bitmap data is the backup number identifier of the j-th backup process (that is, j). Exemplarily, the value of each bit in the second bitmap data can generally be set to 4 bytes, that is, the size of each bit corresponding to the data block in the second bitmap data can be set to 4 bytes.

[0112] Among them, when j is 1, the original disk data of the data block 1 can be the data stored in the data block 1 when the virtual machine A is started (for example, no data may be stored in the data block 1 when the virtual machine A is started); when j is not 1, the original disk data of the data block 1 can be the data stored in the data block 1 during the j-1th backup process.

[0113] Exemplarily, the relationship between the size of the static bitmap area and the size of the virtual disk A can be expressed by the following formula: S1 = S2 / S3*a, where S2 represents the size of the static bitmap area, S2 represents the size of the virtual disk A, S3 represents the size of a data block in the virtual disk A, for example, S3 is set to 2M (megabytes), and a represents the size of the bits corresponding to a data block in the second bitmap data stored in the set static bitmap area, for example, a can be set to 4 bytes.

[0114] After the backup unit creates the first file for virtual machine A, it can persistently store the first bitmap data and the second bitmap data of each backup process based on the first file during each backup process of virtual machine A, so as to use the persistently stored first bitmap data and second bitmap data for virtual machine A to load the first bitmap data from the first file to the host machine memory after restarting, so as to continue to track the data changes of virtual disk A of virtual machine A; and use the persistently stored second bitmap data to perform disaster recovery backup of the backup data of virtual machine A.

[0115] It can be understood that each data backup process of virtual machine A is similar. Below, an arbitrary data backup process (such as the j-th backup process) is taken as an example to illustrate each data backup process of virtual machine A.

[0116] In each backup process (for example, the j-th backup process), in step S320, the first bitmap data corresponding to the current disk data of virtual machine A is obtained, and the first bitmap data is stored in a first file, which is stored in a non-volatile memory. The first bitmap data is used to indicate the data changes of the current disk data of virtual machine A relative to the original disk data of virtual machine A.

[0117] In some possible examples, when the backup unit determines that virtual machine A needs to perform data backup, it can send a call request to the virtualization platform to call a specified interface of the virtualization platform. Accordingly, the virtualization platform determines that virtual machine A needs to perform data backup in response to the call request. Subsequently, the virtualization platform can obtain the first bitmap data j corresponding to virtual disk A (i.e., the current disk data of virtual machine A) from the host machine memory of virtual machine A (i.e., the memory of the first computing device) and feedback it to the backup unit. Accordingly, the backup unit obtains the first bitmap data j corresponding to the current disk data of virtual machine A through the virtualization platform; then, the backup unit stores the first bitmap data j in the first file. Specifically, the backup unit stores the first bitmap data j in the dynamic bitmap area of ​​the first file.

[0118] Exemplarily, the designated interface is an interface reserved by the virtualization platform and can be called to obtain the first bitmap data corresponding to the current disk data of virtual disk A from the host memory of virtual machine A.

[0119] In some possible examples, the aforementioned method of determining that virtual machine A needs to perform data backup may include at least one of the following methods: receiving a user-triggered data backup instruction for virtual machine A; or, detecting that the moment corresponding to the preset backup cycle for virtual machine A has arrived; or, detecting a shutdown event for virtual machine A.

[0120] For example, the backup cycle can be set to one week, and data backup can be performed at the arrival of XX time every day within a backup cycle; accordingly, the aforementioned detection of the arrival of the time corresponding to the backup cycle preset for virtual machine A can mean that every time the arrival of XX time every day within a backup cycle is detected, it is determined that virtual machine A needs to perform data backup.

[0121] As another example, the backup cycle can be set to one month, and data backup can be performed at time YY every day within the backup cycle. As another example, the backup cycle can be set to one day, and data backup can be performed at time aa intervals starting from time zz within the backup cycle. It should be noted that the length of a backup cycle and the interval between data backups within a backup cycle can be set as needed.

[0122] It can be understood that within a backup cycle, the first backup within the backup cycle can be a full data backup of the virtual disk A of the virtual machine A, that is, a backup of the data in all data blocks of the virtual disk A; the non-first backup within the backup cycle can be an incremental data backup of the virtual disk A of the virtual machine A, that is, a backup of the data in the virtual disk A that has changed since the previous backup (that is, the disk data at the time of the previous backup).

[0123] In some possible examples, the dynamic bitmap area of ​​the first file may include a first region and a second region (such as region 1 or region 2 of the dynamic bitmap area described above), each of which is used to alternately store first bitmap data obtained from the host memory of virtual machine A. For example, the aforementioned process of storing first bitmap data j in the dynamic bitmap area of ​​the first file may include: storing first bitmap data j corresponding to the j-th backup process in region 1. At this time, first bitmap data j-1 corresponding to the j-1-th backup process may be stored in region 2.

[0124] In some specific examples, the aforementioned process of storing the first bitmap data j corresponding to the j-th backup process in region1 may include: the backup unit may store the first bitmap data j in region1 of the dynamic bitmap area in the first file based on the metadata current_db of the dynamic bitmap area stored in the aforementioned metadata area, wherein the current_db is information indicating that the first bitmap data is written to region1 or region2 of the dynamic bitmap area. At this time, current_db indicates that the first bitmap data j is written to region.

[0125] In another possible example, after the first bitmap data j is stored in the dynamic bitmap area of ​​the first file, the backup unit may also store the dynamic backup times value (i.e., Figure 5 The ChgID1 shown in FIG. 1 is incremented by 1, so that the value of ChgID1 after incrementing by one is equal to the number of backups corresponding to this backup, that is, j.

[0126] As another example, the backup unit may further generate a first bitmap check code j based on the first bitmap data j, and store the first bitmap check code j in a corresponding position of the sub-area storing metadata of the dynamic bitmap area in the first file (i.e., Figure 4 Dirty Bitmap Meta structure shown).

[0127] In some examples, the first bitmap data may exist in the form of a table, which may be referred to as a first bitmap table. The first bitmap data may include bits corresponding to each data block of virtual disk A.

[0128] In the case where j is not equal to 1, the value of the bit corresponding to the data block can indicate whether the data in the data block has changed since the previous backup (for example, since the j-1th backup). For example, the value of the bit corresponding to the data block is a specified value (for example, 1), indicating that the data in the data block has changed since the previous backup (for example, since the j-1th backup); the value of the bit corresponding to the data block is a non-specified value (for example, 0), indicating that the data in the data block has not changed since the previous backup (for example, since the j-1th backup). Accordingly, the original disk data of the aforementioned virtual machine A can be the data in the snapshot corresponding to the previous backup process. In the case where j is equal to 1, the original disk data of the aforementioned virtual machine A can be the disk data in virtual disk A when virtual machine A is started (that is, data that has not been backed up).

[0129] Accordingly, based on the values ​​of the bits corresponding to the data blocks in virtual disk A in the first bitmap data, data changes of the current disk data of virtual disk A relative to the original disk data of the virtual disk can be determined.

[0130] Next, in step S330, second bitmap data is determined based on the first bitmap data, and the second bitmap data is stored in the first file. The second bitmap data is used to indicate the data change of the current disk data of virtual machine A relative to the original disk data of virtual machine A and the first backup number.

[0131] The first backup number indicates the backup number corresponding to the current backup of virtual machine A. For example, if this is the jth backup of the disk data of virtual machine A, the first backup number may be j. Accordingly, the current disk data of virtual machine A is the disk data in virtual disk A of virtual machine A at the jth backup; the original disk data of virtual machine A is the disk data in virtual disk A of virtual machine A at the j-1th backup.

[0132] It should be noted that when the j-th backup is the first backup, the disk data in the virtual disk A of virtual machine A during the j-1-th backup may refer to the disk data in the virtual disk A when virtual machine A is started (including data that has not been backed up).

[0133] In this step, the first bitmap data indicates the data change of the current disk data of virtual machine A relative to the original disk data of virtual machine A. Exemplarily, if the value of the bit corresponding to the data block in the first bitmap data is a specified value, it indicates that the data of the data block has changed since the previous backup (for example, the j-1th backup); if the value of the bit corresponding to the data block in the first bitmap data is a non-specified value, it indicates that the data of the data block has not changed since the previous backup.

[0134] In some specific examples, the aforementioned first bitmap data includes a bit set to a specified value (hereinafter referred to as a specified bit), and the specified value is used to indicate the data that has changed in the current disk data of virtual machine A relative to the original disk data of virtual machine A; accordingly, in the case where this backup requires incremental data backup, in step S330, based on the first bitmap data, the process of determining the second bitmap data can specifically include: replacing the specified value of the specified bit in the first bitmap data with the first backup number to obtain the second bitmap data. In this way, the corresponding relationship between the data required to be backed up in the j-th backup process (including the data stored in the data blocks corresponding to each specified bit, that is, the subsequent first backup data) and the backup number identifier of the j-th backup process can be stored. In this way, when the disk data of virtual machine A is subsequently backed up for disaster recovery, it can be more convenient to search for the data backed up by each backup process.

[0135] In some possible examples, the aforementioned process of determining the second bitmap data may include: Figure 4The static backup count value (CHgID2) stored in the Static Bitmap Meta structure (shown) is incremented by one, so that the incremented value of ChgID2 is equal to the first backup count corresponding to the current backup, i.e., j. Next, the value of the specified bit in the first bitmap data is replaced with the first backup count j, i.e., the value of CHgID2 incremented by one, to obtain the second bitmap data. Accordingly, this second bitmap data is used to indicate the data changes of the current disk data of virtual machine A since the previous backup of virtual machine A, as well as the first backup count.

[0136] After the backup unit determines the second bitmap data j, it stores the second bitmap data j in the first file. Specifically, it can be stored in the static bitmap area of ​​the first file. In some embodiments, after the backup unit stores the second bitmap data j in the first file, it can also generate a third bitmap check code based on the second bitmap data stored in the static bitmap area, and store the third bitmap check code in Figure 4 The Static Bitmap Meta structure shown in FIG. 10; and the value of CHgID2 plus one is stored in the Static Bitmap Meta structure.

[0137] For the sake of clarity, the following uses a specific example to illustrate the specific update process of the first file, that is, the process of storing the first bitmap data in the host memory of virtual machine A to the first file, and the process of storing the second bitmap data to the first file.

[0138] like Figure 5 As shown in FIG, assuming that the virtual disk A of virtual machine A includes 4 data blocks, data block 1 is written with data "a", data block 2 is written with data "b", and data blocks 3 and 4 are not written with data. Accordingly, the first bitmap data 1 (i.e., the bitmap table) stored in the host memory of virtual machine A is as follows: Figure 5 As shown, the values ​​of the bits corresponding to data block 1 and data block 2 are 1, and the values ​​of the bits corresponding to data block 3 and data block 4 are 0.

[0139] like Figure 5 As shown, during the first backup, that is, the first data backup of virtual machine A, the first command is called to write the first bitmap data 1 obtained from the host memory of virtual machine A into the dynamic bitmap area of ​​the first file (for example, write into region 1 of the dynamic bitmap area) through the write function.

[0140] Next, update the sub-area of ​​metadata of the dynamic bitmap area (i.e. Figure 4The dynamic backup times value stored in the Dirty Bitmap Meta shown is the value of CHgID1 (assuming that the first backup is started, the initial value of CHgID1 is set to 0, and the static backup times value is the initial value of CHgID2 is 0); specifically, read Figure 4 The value of CHgID1 stored in the Dirty BitmapMeta structure shown in the figure is added by 1 to obtain the updated value of CHgID1, and then the updated value of CHgID1 is stored in the Dirty Bitmap Meta structure. At this time, the value of CHgID1 stored in the first file is 1.

[0141] Subsequently, based on the first bitmap data 1 written in the dynamic bitmap area, the second bitmap data is determined; wherein, the process may include: reading the sub-area of ​​the metadata of the static bitmap area, i.e. Figure 4 In the Static Bitmap Meta structure shown in FIG, the value of CHgID2 is stored, and 1 is added to obtain the updated value of CHgID2, which is 1; the second command is called to modify the value of the bit with a value of 1 in the first bitmap data 1 to the updated value of CHgID2 (i.e. 1) (i.e., the first backup number 1) through the write function, and obtain the second bitmap data 1, as shown in FIG. Figure 5 As shown. Then, the second bitmap data 1 is stored in the static bitmap area. Here, this is the first time to store the second bitmap data, and the second bitmap data 1 can be directly stored in the static bitmap area.

[0142] Through the above process, for the first backup, the first bitmap data 1 in the host machine memory of virtual machine A is persisted to the first file, and the second bitmap data is stored in the static bitmap area of ​​the first file, wherein the second bitmap data indicates the current disk data of virtual disk A, the data changes relative to the original disk data of virtual disk A (all four data blocks are empty) (specifically, data block 1 writes data "a", data block 2 writes data "b", that is, the data in data blocks 1 and 2 changes, while the data in data blocks 2 and 4 does not change), and the first backup number 1.

[0143] like Figure 5 As shown, after the first backup is completed and before the second backup, virtual machine A writes data "c" to data block 3 of virtual disk A. Accordingly, at this time, as shown in FIG. Figure 5 As shown, the value of the bit corresponding to data block 3 in the first bitmap data 2 of the host memory of virtual machine A is 1. At this time, the data in other data blocks of virtual disk A has not changed compared to the first backup, and the values ​​of the bits corresponding to other data blocks in the corresponding first bitmap data 1 are 0.

[0144] During the first backup, after the first bitmap data 1 obtained from the host memory of virtual machine A is written into the dynamic bitmap area of ​​the first file, the first bitmap data 1 stored in the host memory of virtual machine A is initialized.

[0145] During the second backup, that is, the second data backup of virtual machine A, the first command is called to write the first bitmap data 2 obtained from the host memory of virtual machine A into the dynamic bitmap area of ​​the first file through the write function (at this time, region 2 of the dynamic bitmap area is written).

[0146] Next, update the sub-area of ​​metadata of the dynamic bitmap area (i.e. Figure 4 The value of CHgID1 stored in the Dirty Bitmap Meta shown in FIG. 1 (which is 1 at this time); specifically, read Figure 4 The value of CHgID1 stored in the Dirty Bitmap Meta structure shown in the figure is added by 1 to obtain the updated value of CHgID1, and the updated value of CHgID1 is stored in the DirtyBitmap Meta structure. At this time, the value of CHgID1 stored in the first file is 2.

[0147] Subsequently, based on the first bitmap data 2 written in the dynamic bitmap area, the second bitmap data 2 is determined; wherein, the process includes: reading the sub-area of ​​the metadata of the static bitmap area, i.e. Figure 4 The value of CHgID2 stored in the Static Bitmap Meta structure shown is added by 1 to obtain the updated value of CHgID2, which is 2; the second command is called to modify the value of the bit corresponding to the bit set to 1 in the first bitmap data 2 to the updated value of CHgID2 (i.e. 2) (i.e. the first backup number 2) through the write function to obtain the second bitmap data 2, and then the second bitmap data 2 is stored in the static bitmap area, as shown in FIG. Figure 5 shown.

[0148] Here, this is the second time that the second bitmap data is stored in the static bitmap area. The second bitmap data 2 is stored in the static bitmap area. The second bitmap data 2 can be stored in the static bitmap area by updating the value of the bit of the second bitmap data 2 whose value is the updated value 2 (i.e., the first backup number 2) of CHgID2 to the second bitmap data stored in the static bitmap area. Here, in the second bitmap data stored in the static bitmap area at this time, the value of the bit corresponding to data blocks 1 and 2 is 1 (i.e., indicating that the data in data blocks 1 and 2 are the backup data stored in the first backup process), the value of the bit corresponding to data block 3 is 2 (i.e., indicating that the data in data block 3 are the backup data stored in the second backup process), and the value of the bit corresponding to data block 4 is 0 (i.e., the data therein has not changed).

[0149] like Figure 5 As shown, after the second backup is completed and before the third backup, virtual machine A writes data to data block 2 of virtual disk A. At this time, data block 2 stores data "bb". Correspondingly, Figure 5 As shown, the value of the bit corresponding to data block 2 in the first bitmap data 3 of the host memory of virtual machine A is 1, and the data of other data blocks of virtual disk A have not changed compared to the second backup, and the values ​​of the bits corresponding to other data blocks in the corresponding first bitmap data 1 are 0.

[0150] During the second backup, after the first bitmap data 2 acquired from the host memory of virtual machine A is written into the dynamic bitmap area of ​​the first file, the first bitmap data 2 stored in the host memory of virtual machine A is initialized.

[0151] During the third backup, that is, the third time data is backed up for virtual machine A, the preset first command is called to write the first bitmap data 3 obtained from the host memory of virtual machine A into the dynamic bitmap area of ​​the first file through the write function (at this time, region 1 of the dynamic bitmap area is polled and written).

[0152] Update the metadata sub-area of ​​the dynamic bitmap area (i.e. Figure 4 The value of CHgID1 stored in the Dirty Bitmap Meta shown in FIG. 2 (which is 2 at this time); specifically, read Figure 4 The value of CHgID1 stored in the Dirty Bitmap Meta structure shown in the figure is added by 1 to obtain the updated value of CHgID1, and then the updated value of CHgID1 is stored in the DirtyBitmap Meta structure. At this time, the value of CHgID1 stored in the first file is 3.

[0153] Subsequently, based on the first bitmap data 3 written in the dynamic bitmap area, the second bitmap data 3 is determined; wherein, the process includes: reading the sub-area of ​​the metadata of the static bitmap area, i.e. Figure 4 The value of CHgID2 stored in the Static Bitmap Meta structure shown is added by 1 to obtain the updated value of CHgID2, which is 3; the preset second command is called to set the value of the bit corresponding to the first bitmap data 3 to 1, and is modified to the updated value of CHgID2 (i.e. 3) (i.e. the first backup number 3) through the write function to obtain the second bitmap data 3, and then the second bitmap data 3 is stored in the static bitmap area, as shown in FIG. Figure 5 shown.

[0154] This is the third time that the second bitmap data is stored in the static bitmap area. The process of storing the second bitmap data 3 into the static bitmap area can refer to the aforementioned process of storing the second bitmap data 2 into the static bitmap area, which will not be described in detail here.

[0155] By analogy, for each backup, the first file is updated through the above method, that is, the first bitmap data in the host memory of virtual machine A is persisted to the first file, and the second bitmap data determined based on the first bitmap data is persisted to the first file.

[0156] Persistently storing the second bitmap data in the first file can make it easier to trace back all changed data in a certain backup and all subsequent virtual disks A. For example, based on the second bitmap data stored in the static bitmap area after the second backup is completed, all changed data in the first backup and subsequent data (i.e., including the data changed in the first backup, i.e., the data in data blocks 1 and 2, and the data changed in the second backup, i.e., the data in data block 3) can be determined; for another example, based on the second bitmap data stored in the static bitmap area after the third backup is completed, all changed data in the second backup and subsequent data (i.e., including the data changed in the second backup, i.e., the data in data block 3, and the data changed in the third backup, i.e., the data in data block 2) can be determined, providing better convenience for the implementation of subsequent disaster recovery backup.

[0157] After the backup unit stores the second bitmap data in the first file, in step S340 , it stores first backup data, which is the data that changes between the current disk data of virtual machine A and the original disk data of virtual machine A.

[0158] It can be understood that the first backup data is data in a data block in the virtual disk A corresponding to a bit in the second bitmap data whose value is the first backup number.

[0159] In some possible examples, step S340 may include the following steps: storing the first backup data in a designated storage area of ​​the host machine of virtual machine A.

[0160] In some further possible examples, step S340 may include the following step: storing the first backup data in a backup pool corresponding to virtual machine A.

[0161] In some other possible examples, step S340 may include the following steps: storing the first backup data in a designated storage area of ​​the host machine of virtual machine A; and storing the first backup data stored in the designated storage area in a backup pool corresponding to virtual machine A.

[0162] It is understood that when storing the first backup data, the first backup number can be used as the data identifier of the first backup data to achieve a corresponding relationship between the backup indicated by the first backup number and the data backed up by it (i.e., the first backup data). Alternatively, the first backup data and the first backup number can be stored in correspondence, for example, in the backup pool corresponding to the first backup data, the corresponding relationship between the data identifier (or storage address) of the first backup data and the first backup data identifier is stored.

[0163] In the above process, a first file stored in a non-volatile memory is added. When backing up the disk data of the virtual machine, the first bitmap data corresponding to the current disk data of the virtual machine is stored in the first file to achieve persistent storage of the first bitmap data that can indicate the data changes of the current disk data relative to the original disk data of the virtual machine; then, based on the first bitmap data, second bitmap data indicating the data changes of the current disk data relative to the original disk data and the first backup number is determined, and the second bitmap data is stored in the first file, and the first backup data is stored. In this way, the second bitmap data can persistently indicate that the first backup data is the data stored in the backup process corresponding to the first backup number. Accordingly, after multiple backup processes, the second bitmap data stored in the first file can persistently indicate which data blocks in the disk have the backup data stored in each backup. This provides a basis for realizing disaster recovery backup in subsequent backup processes. For example, during a backup process, if it is determined that the backup data stored in the previous backup process is damaged, the backup data in which data blocks on the disk are stored during each backup (that is, a backup corresponding to a backup number identifier) ​​can be combined with the second bitmap data to more conveniently locate the backup data after the damaged backup data, and then the damaged backup data and the backup data after it can be re-backed up to achieve disaster recovery backup without the need for a full backup again, providing a basis for reducing storage resources and time consumption during the data backup process, and improving the disaster recovery capability of the backup data.

[0164] Furthermore, in the above example, the second bitmap data stored in the first file can indicate the backup times of each backup process and the data changes of the disk data of virtual machine A at each backup relative to the disk data at the previous backup of virtual machine A (or the disk data when virtual machine A was started). If virtual machine A is abnormally shut down, resulting in the disk data of virtual machine A not being backed up, the state of virtual machine A at the time of the last data backup before the abnormal shutdown can still be reproduced based on the second bitmap data and the backup data stored at each backup, thereby reducing the amount of data loss of virtual machine A caused by the abnormal shutdown.

[0165] The abnormal shutdown mentioned above may refer to a shutdown in which no shutdown event is triggered, resulting in no backup of the disk data of virtual machine A. Abnormal shutdowns include, for example, a power outage on the host machine of virtual machine A causing the shutdown of virtual machine A, a crash causing the shutdown of virtual machine A, etc.

[0166] In some possible examples, considering that during the data backup period (i.e., between the determination of data backup and the completion of the storage of the data required for this backup), there may be a need for the user to continue writing data to virtual disk A of virtual machine A, in order to ensure the accuracy of the data backup result (the backed up data is the data required to be backed up at the time of the data backup) and to ensure the normal writing of data to virtual disk A during the backup process to improve the user experience, during each backup process, before step S320, the method further includes step 11:

[0167] In step 11: a snapshot is created based on the current disk data of virtual machine A.

[0168] In some possible examples, when the backup unit determines that virtual machine A needs to perform data backup, it sends a call request to the virtualization platform to invoke a specified interface of the virtualization platform. In response to the call request, the virtualization platform determines that virtual machine A needs to perform data backup and can create a snapshot based on the current disk data of virtual machine A. Accordingly, the backup unit creates a snapshot based on the current disk data of virtual machine A through the virtualization platform. Step S320 is then executed.

[0169] The snapshot may include data stored in each data block in virtual disk A. The snapshot is used to continue writing data to virtual disk A in response to a request to write data during the j-th backup process (ie, during the j-th data backup).

[0170] Next, after step S340 , the method further includes step 12 : in step 12 , the aforementioned snapshot is merged with the current disk data of virtual machine A.

[0171] In this step, in order to ensure the normal writing of data to virtual disk A during the backup process and improve the user experience, during the j-th backup process, the write request to write data to virtual disk A can be redirected to the snapshot, that is, the data that needs to be written to virtual disk A during the j-th backup process is stored in the snapshot. After the first backup data is stored in step S340, the aforementioned snapshot is merged with the current disk data of virtual machine A, that is, the data stored in the snapshot that has changed relative to the current disk data (the disk data when the snapshot is generated) is stored in virtual disk A.

[0172] In some other possible examples, when there is no need to write data to virtual disk A during the backup process, the data stored in the snapshot is the same as the current disk data of virtual machine A (the disk data when the snapshot is generated). Merging the aforementioned snapshot with the current disk data of virtual machine A can refer to maintaining the current disk data of virtual disk A.

[0173] In some possible examples, the backup unit may periodically perform incremental backups on the disk data in disk data A of virtual machine A. The periodic incremental backups of the disk data in disk data A of virtual machine A may include: performing a full data backup of the disk data in disk data A of virtual machine A for the first backup in a backup cycle; and performing incremental data backups of the disk data in disk data A of virtual machine A for non-first backups in the backup cycle.

[0174] In this example, if the backup unit determines that this backup requires an incremental data backup, only the first backup data is stored in the aforementioned step S340. If the backup unit determines that this backup requires a full data backup, the first backup data and the fourth backup data are stored in the aforementioned step S340. The fourth backup data is the current disk data of virtual machine A that has not changed relative to the original disk data of virtual machine A. That is, if the backup unit determines that this backup requires a full data backup, all the current disk data of virtual machine A needs to be stored.

[0175] In some possible examples, the first backup number may indicate whether this backup is the first backup in a backup cycle or not the first backup. Accordingly, the first computing device may determine whether this backup requires incremental data backup or full data backup based on the first backup number.

[0176] In some other possible examples, within a backup cycle, there is data backup performed in response to a user-triggered data backup instruction and / or there is data backup performed when a shutdown event of virtual machine A is detected. In order to accurately determine whether this backup requires an incremental data backup or a full data backup, it can be determined whether this backup requires an incremental data backup or a full data backup based on the time corresponding to this backup.

[0177] Exemplarily, when it is determined that the time indication corresponding to this backup enters a new backup cycle, it is determined that this backup requires a full data backup. When it is determined that the time indication corresponding to this backup is still within the current backup cycle, it is determined that this backup requires an incremental data backup. For example, the backup cycle is set to one week, and data backup is performed at XX time every day. If the time indication corresponding to this backup is XX time on Sunday, it is determined that this backup requires a full data backup. Accordingly, all disk data in virtual disk A of virtual machine A needs to be stored. If the time indication corresponding to this backup is XX time on any day from Monday to Saturday (or indicates other times from Monday to Saturday), it can be determined that this backup requires an incremental data backup. Accordingly, it is sufficient to store the data corresponding to the current disk data of the current backup of virtual machine A relative to the disk data changes since the previous backup of virtual machine A.

[0178] It can be understood that when it is determined that a full data backup is required for this backup, the aforementioned process of determining the second bitmap data based on the first bitmap data can include: replacing the values ​​of all bits in the first bitmap data with the first backup number to obtain the second bitmap data, which is used to indicate the data changes of the current disk data of virtual machine A relative to the original disk data of the virtual machine (specifically, it indicates that all data have changed) and the first backup number.

[0179] In the above process, when backing up the virtual machine's disk data, a snapshot is created based on the virtual machine's current disk data. During the backup process, the newly written data is redirected to the snapshot, and after the data storage is completed, the snapshot is merged with the current disk data to avoid the loss of the user's newly written data during the backup process.

[0180] Considering that during the operation of virtual machine A, bitmap data will be stored in its host machine memory, so that the data changes of each data block in its virtual disk A (that is, the modification of disk data) can be tracked in real time, but after virtual machine A is shut down, the bitmap data in its host machine memory will be lost. Accordingly, after virtual machine A is restarted, if there is a first file corresponding to virtual machine A, it is necessary to reload the first bitmap data corresponding to the backup process before virtual machine A is shut down, which is currently stored in the dynamic bitmap area of ​​the first file, into the host machine memory of virtual machine A to continue tracking the modification of virtual machine A's disk data.

[0181] In order to ensure the data integrity and security of virtual machine A, before loading the first bitmap data corresponding to the latest backup process of virtual machine A before shutdown currently stored in the dynamic bitmap area into the host machine memory of virtual machine A, it is necessary to perform data integrity verification on the first bitmap data corresponding to the latest backup process before shutdown of virtual machine A currently stored.

[0182] Exemplarily, before performing data backup, that is, before step S320 (or the aforementioned step 11), the process of restarting virtual machine A is also included. Then, after restarting, virtual machine A triggers a load request to load the first bitmap data in the first file into its host machine memory. The metadata area of ​​the first file also stores a first bitmap check code corresponding to the dynamic bitmap area. The first bitmap check code is generated based on the first bitmap data corresponding to the previous backup process. In the case where this backup is the jth backup, the previous backup process is the j-1th backup. The first bitmap data corresponding to the previous backup process is: the first bitmap data corresponding to the disk data of virtual machine A obtained during the j-1th backup process. The first bitmap data corresponding to the previous backup process (j-1th backup) is the first bitmap data corresponding to the latest backup process before virtual machine A is shut down. For example, the first bitmap check code can be an MD5 value generated based on the stored first bitmap data, or it can be a hash value generated based on the stored first bitmap data. The following is an example of the check code corresponding to the dynamic bitmap area being an MD5 value generated based on the stored first bitmap data.

[0183] Accordingly, before step 320, the method may further include the following steps 21-24:

[0184] In step 21, after detecting a load request from virtual machine A to load the first bitmap data into its host machine memory, a second bitmap check code is generated based on the first bitmap data currently stored in the dynamic bitmap area corresponding to the previous backup process. The load request is sent after virtual machine A is shut down and restarted.

[0185] In some examples, the previous backup process (i.e., the j-1th backup) may be triggered by detecting a shutdown event of virtual machine A. Accordingly, after storing the backup data corresponding to the previous backup process, virtual machine A shuts down in response to the shutdown event. In other examples, the previous backup process may also be triggered by detecting the arrival of a time corresponding to a backup cycle or in response to a user-triggered data backup instruction. Subsequently, virtual machine A shuts down abnormally, resulting in no new data backup process being triggered upon shutdown. Accordingly, when virtual machine A shuts down abnormally, the dynamic bitmap area of ​​the first file stores the first bitmap data corresponding to the j-1th backup, and its static bitmap area stores the second bitmap data determined based on the first bitmap data corresponding to the j-1th backup.

[0186] After restarting, virtual machine A triggers a loading request to load the first bitmap data in the first file into its host machine memory. In order to ensure the data integrity of the first bitmap data loaded by virtual machine A, after detecting the loading request of virtual machine A, the first computing device (backup unit) generates a second bitmap check code based on the first bitmap data currently stored in the dynamic bitmap area and corresponding to the previous backup process (that is, the most recently stored first bitmap data), for example, calculates the MD5 value of the first bitmap data currently stored in the dynamic bitmap area and corresponding to the previous backup process as the second bitmap check code.

[0187] For example, the first bitmap data corresponding to the previous backup process is stored in region 1 of the dynamic bitmap area of ​​the first file. The data stored in region 1 of the dynamic bitmap area of ​​the first file generates a second bitmap check code based on the first bitmap data stored in region 1.

[0188] Then, in step 22, the first bitmap check code is compared with the second bitmap check code. In this step, the first bitmap check code is compared with the second bitmap check code to determine whether they are the same.

[0189] In step 23, if the first bitmap check code is the same as the second bitmap check code, the first bitmap data corresponding to the previous backup process currently stored in the dynamic bitmap area is loaded into the host machine memory.

[0190] In this step, if it is determined that the first bitmap check code is the same as the second bitmap check code, it is determined that the first bitmap data corresponding to the previous backup process currently stored in the dynamic bitmap area has not been modified. Accordingly, the first bitmap data is sent to virtual machine A so that virtual machine A loads the first bitmap data into its host machine memory.

[0191] In step 24, if it is determined that the first bitmap checksum is different from the second bitmap checksum, it can be determined that the first bitmap data corresponding to the previous backup process currently stored in the dynamic bitmap area has been modified, and the first bitmap data stored in the dynamic bitmap area of ​​the first file is unavailable. Subsequently, in some possible examples, the first computing device can recreate new first bitmap data for virtual machine A in the host machine memory of virtual machine A through its deployed virtualization platform. Exemplarily, the first computing device can also send a prompt message to inform the user of virtual machine A that the first bitmap data stored in the dynamic bitmap area of ​​the first file is unavailable.

[0192] In the above example, the data integrity of the first bitmap data loaded from the first file into the host memory of virtual machine A can be guaranteed, so as to better ensure the data security of virtual machine A.

[0193] In some other possible examples, considering that the second bitmap data stored in the static bitmap area of ​​the first file can indicate the backup number identifier corresponding to each backup process and the data backed up by each backup process, it is helpful to trace back a certain backup process and the data backed up thereafter. In order to ensure the data security of virtual machine A, the metadata area also stores a third bitmap check code, which is generated based on the second bitmap data currently stored in the static bitmap area and corresponding to the previous backup process; accordingly, after the aforementioned determination that the first bitmap check code is the same as the second bitmap check code, it is also necessary to verify the data integrity of the second bitmap data currently stored in the static bitmap area and corresponding to the previous backup process. Specifically, based on the second bitmap data currently stored in the static bitmap area and corresponding to the previous backup process, a fourth bitmap check code is generated; the third bitmap check code and the fourth bitmap check code are compared. If the third bitmap check code and the fourth bitmap check code are the same, it is determined that the second bitmap data currently stored in the static bitmap area and corresponding to the previous backup process has not been modified, and the first bitmap data corresponding to the previous backup process is sent to virtual machine A, so that virtual machine A loads the first bitmap data into its host machine memory. If the third bitmap check code and the fourth bitmap check code are different, it can be determined that the second bitmap data corresponding to the previous backup process currently stored has been modified and is no longer available. Accordingly, the first file is unavailable, and a prompt message can be output to prompt the user of virtual machine A that the first file of virtual machine A is wrong.

[0194] In some other possible examples, in step S330, after the second bitmap data corresponding to this backup (i.e., the j-th backup) is stored in the first file, the bitmap data in the host memory of virtual machine A is initialized, that is, the values ​​of the bits corresponding to all data blocks in the bitmap data in the host memory are modified to non-specified values ​​(e.g., 0) to indicate that the data of each data block in virtual disk A has not changed, so as to better and more accurately indicate the data changes during the next backup (j+1-th backup).

[0195] Correspondingly, in some other examples, after the aforementioned step 12, steps 13-14 may also be included to determine the data in the snapshot that has changed relative to the current disk data of virtual machine A (i.e., the disk data of virtual machine A when the snapshot is generated for the jth backup) as the target data; based on the target data, the initialized bitmap data in the host machine memory is updated.

[0196] In this example, the target data of the disk data change of virtual machine A when the snapshot is generated for the j-th backup of virtual machine A is determined, and based on the target data, the data block to which it belongs is determined as the changed block. Then, the value of the bit corresponding to each changed block in the initialized bitmap data in the host machine memory is modified to a specified value to indicate the data change in each changed block, thereby realizing the tracking and recording of the data change of the data block (in which the data is changed) in virtual disk A during the j-th backup process.

[0197] The following describes a data backup process provided by a specific embodiment of the present application. In this data backup process, the first computing device performs an incremental backup of the data of virtual machine A based on the first file created for virtual machine A.

[0198] For example, Figure 6 As shown, in step S610, the first computing device can detect whether data backup is required for virtual machine A. In step S620, if it is determined that data backup is required for virtual machine A, the snapshot function can be enabled and the COW (Copy-on-Write) technology of the snapshot function can be used to create a snapshot based on the current disk data of virtual machine A. In step S630, first bitmap data A corresponding to the current disk data of virtual machine A is obtained from the host memory of virtual machine A. And in step S640, the first bitmap data A is stored in the dynamic bitmap area of ​​the first file (for example, the first bitmap data B of the previous backup is stored in region 1 of the dynamic bitmap area, and the first bitmap data A is now stored in region 2 of the dynamic bitmap area).

[0199] Afterwards, in step S650, the first computing device adds 1 to the ChgID1 corresponding to the dynamic bitmap area stored in the metadata area; then, in step S660, the bit with a specified value (for example, 1) is determined from the first bitmap data A, and the bit with the specified value can indicate that the data of the corresponding data block has changed; in step S670, the first computing device adds 1 to the ChgID2 corresponding to the static bitmap area stored in the metadata area, and in step S680, the value of the bit with the specified value in the first bitmap data is replaced by the ChgID2 after adding 1 to obtain the second bitmap data, and the ChgID2 after adding 1 is equivalent to the first backup time of this backup, and S690, the second bitmap data is stored in the static bitmap area of ​​the first file.

[0200] Then, in step S6100, the first computing device stores first backup data, which is data of changes in the current disk data of virtual machine A relative to the original disk data of virtual machine A.

[0201] Next, the first computing device determines that it is necessary to back up data of virtual machine A, and before storing the first backup data, or while storing the first backup data, or after storing the first backup data (and before merging the snapshot obtained in step S620 into virtual disk A), as shown in FIG. Figure 6 As shown, it can also include step S6110. In step S6110, if a write request indicating that data is to be written to virtual disk A is received, the write request is redirected to the aforementioned snapshot to write the data involved in the write request into the aforementioned snapshot, so as to set virtual disk A to a read-only state, so that it remains in the state when it is determined that data backup of virtual machine A is required, and avoids writing data of the write request after it is determined that data backup of virtual machine A is required into virtual disk A, so that the first backup data determined for this backup is not the data when it is determined that data backup of virtual machine A is required, so that the state of virtual machine A when it is determined that data backup of virtual machine A is required cannot be restored subsequently.

[0202] Subsequently, in step S6120, the aforementioned snapshot and the current disk data of virtual machine A are merged, that is, the data written to the snapshot in step S6100 is merged into virtual disk A, and then the snapshot is deleted.

[0203] In the above example, during data backup of virtual machine A, data can still be written in response to the received write request to improve user experience and ensure that virtual disk A remains in the state when it is determined that data backup of virtual machine A is required.

[0204] In some other possible examples, Figure 6 As shown, after the first computing device stores the second bitmap data determined based on the first bitmap data in the static bitmap area of ​​the first file, it can also initialize the first bitmap data A in the host memory of the virtual machine in step S6130, that is, set the value of the bit with a specified value in the first bitmap data A to a non-specified value to indicate that the data of each data block in the virtual disk A has not changed.

[0205] After merging the aforementioned snapshot and the current disk data of virtual machine A in step S6120, and after initializing the first bitmap data A in the host memory of the virtual machine in step S6130, the initialized first bitmap data in the host memory can be used to continue tracking data changes in the data block. For example, this includes: modifying the value of the bit in the initialized first bitmap data corresponding to the data block to which the data involved in the corresponding write request was written in step S6110 to a specified value, so as to achieve the recording of data changes in the snapshot relative to the aforementioned current disk data, which is also equivalent to recording the incremental data in virtual disk A during the backup process; and continuing to use the initialized first bitmap data to continue tracking subsequent data changes in virtual disk A.

[0206] Understandably, Figure 6 It is only a flowchart showing the data backup process and does not constitute a limitation on the order of execution of the steps therein. For example, step S6130 can also be executed before step S6100 or step S640; step S6110 can also be executed before step S630, and so on.

[0207] The first computing device subsequently continues to detect whether data backup of virtual machine A is required, and if it is determined that data backup of virtual machine A is required, continues to execute the data backup process provided in this application.

[0208] Based on the above method embodiment, illustratively, Figure 7 A flow chart of another data backup method provided by an embodiment of the present application is shown in the figure. The method can be applied to the aforementioned first computing device, which is deployed with the aforementioned backup unit to provide data backup services for one or more virtual machines. Exemplarily, the one or more virtual machines can be built and managed through a virtualization platform. In some possible examples, the first computing device can also be deployed with a virtualization platform to jointly manage the one or more virtual machines with the virtualization platform and the backup unit. In some other possible examples, the virtualization platform can also be deployed in a non-first computing device. Accordingly, the first computing device can jointly manage the one or more virtual machines with the device on which the virtualization platform is deployed to provide data backup services.

[0209] Each virtual machine has a corresponding virtual disk, and a single virtual disk can be divided into one or more data blocks for storing data of the corresponding virtual machine. In a possible example, each data block of a single virtual disk can be evenly or unevenly divided according to the size of the storage space.

[0210] The data backup process will be described below using any virtual machine A from among one or more virtual machines as an example. For data backup processes corresponding to other virtual machines, refer to the data backup process corresponding to virtual machine A. In this embodiment of the present application, the first computing device uses an incremental backup method to back up the disk data in virtual disk A of virtual machine A (hereinafter referred to as the disk data of virtual machine A). The data backup process will be described below using the example of a backup unit, virtualization platform, and virtual machine A all running on the first computing device.

[0211] After each time you determine that data backup is necessary, Figure 7 As shown, the method may include the following steps S710-S780:

[0212] In step S710 , a snapshot is created based on the current disk data of virtual machine A.

[0213] In step S720, the first bitmap data corresponding to the current disk data of virtual machine A is obtained, and the first bitmap data is stored in a first file. The first file is stored in a non-volatile memory. The first bitmap data is used to indicate the data change of the current disk data of virtual machine A relative to the original disk data of virtual machine A.

[0214] In step S730, based on the first bitmap data, second bitmap data is determined and stored in the first file. The second bitmap data is used to indicate the data changes of the current disk data of virtual machine A relative to the original disk data of virtual machine A and the first backup number.

[0215] The implementation principle of step S710 is the same as that of the aforementioned step 11, and the implementation process thereof can refer to the implementation process of step 11; the implementation principle of steps S720-S730 is the same as that of step 11. Figure 3 The implementation principles of steps S320-S330 shown are the same. The implementation process can refer to the implementation process of steps S320-S330, which will not be repeated here.

[0216] In step S740, if it is determined that the current backup requires incremental data backup, an integrity check is performed on each second backup data backed up before the current backup.

[0217] The method for determining whether incremental data backup or full data backup is required for this backup can be referred to the method described in the above embodiment and will not be described in detail here.

[0218] In this step, if it is determined that this backup is not the first backup, that is, this backup needs to perform incremental data backup. Considering that the data backed up by this backup is the incremental data corresponding to the previous backup, if it is necessary to restore the state of virtual machine A at the time of this backup based on the data backed up by this backup, it is necessary to rely on the data backed up before this backup (that is, the second backup data). If one or some of the second backup data are abnormal (for example, damaged or lost), the second backup data with the abnormality and the second backup data after it cannot be used (that is, the state of virtual machine A at its corresponding backup cannot be restored). In view of this, in order to ensure the validity of this backup, it is necessary to verify the integrity of the second backup data backed up before this backup.

[0219] In some examples, the integrity of each second backup data can be verified in sequence according to the order of the backup process corresponding to each second backup data. If the integrity verification of a certain second backup data fails, the verification of the second backup data after the second backup data that failed the integrity verification can be stopped, so as to reduce the number of verifications and reduce the verification consumption.

[0220] In some examples, when the first computing device can perform periodic incremental backups of virtual machine A through its backup unit, the second backup data divided before this backup can be: the backup data backed up before this backup within the cycle in which this backup is located (hereinafter referred to as the current backup cycle).

[0221] In some possible examples, step S740 may specifically include steps 31-33:

[0222] In step 31 , a first data verification code corresponding to each second backup data is obtained, wherein the first data verification code corresponding to each second backup data is generated and stored based on the corresponding second backup data when backing up the corresponding second backup data.

[0223] Illustratively, the first data verification code corresponding to each second backup data may be stored in the aforementioned backup pool. Accordingly, the first computing device may obtain the first data verification code corresponding to each second backup data from the backup pool through its backup unit.

[0224] Next, in step 32, second verification codes are generated based on each of the currently stored second backup data. In this step, each of the second backup data may be stored in the aforementioned backup pool. The first computing device may obtain each of the currently stored second backup data from the backup pool and generate each of the second verification codes based on each of the currently stored second backup data.

[0225] Exemplarily, if the first data verification code corresponding to each second backup data is an MD5 value generated based on each second backup data, then the second verification code generated based on each currently stored second backup data is an MD5 value generated based on each currently stored second backup data. If the first data verification code corresponding to the second backup data is a hash value generated based on each second backup data using a specified hash algorithm, then the second verification code generated based on each currently stored second backup data is a hash value generated based on each currently stored second backup data using the specified hash algorithm.

[0226] Then, in step 33, for each second backup data, the first data verification code and the second data verification code corresponding to the second backup data are compared. If the comparison result indicates that the first data verification code and the second data verification code corresponding to each second backup data are the same, it is determined that the integrity check of each second backup data has passed.

[0227] In this step, the first computing device compares the first data verification code and the second data verification code corresponding to each second backup data to determine whether the first data verification code and the second data verification code corresponding to the second backup data are the same. If the comparison result indicates that the first data verification code and the second data verification code corresponding to each second backup data are the same, it can be determined that there is no abnormality in each second backup data (that is, neither is damaged nor lost). At this time, the first computing device can continue to perform incremental data backup relative to the previously backed up second backup data, and then continue to execute subsequent step S750.

[0228] In some possible examples, considering that one or more second backup data may be completely lost in the backups before the current backup, the first computing device may first obtain the backup times identifier corresponding to each second backup data before obtaining the first data verification code corresponding to each second backup data, and determine whether there is lost second backup data based on the backup times identifier corresponding to each second backup data and the first backup times of the current backup. If it is determined that there is no lost second backup data, continue with the aforementioned step S740. If it is determined that there is lost second backup data, and the lost second backup data is not the full backup data of the first backup, then the disaster recovery backup process can be entered. The disaster recovery backup process will be introduced later.

[0229] For example, if the backup times identifiers corresponding to the respective second backup data and the first backup times of the current backup are numerically continuous, and the number of existing second backup data meets expectations (for example, the number of backups performed (in the current backup cycle) can be counted, and the number of second backup data is equal to the count), then it can be determined that no lost second backup data exists. If the number of existing second backup data does not meet expectations, or the backup times identifiers corresponding to the respective second backup data and the first backup times of the current backup are numerically discontinuous, then it is determined that lost second backup data exists.

[0230] In step S750, if it is determined that the integrity check of each second backup data has passed, the first backup data is stored. Then, step S760 is executed to merge the aforementioned snapshot with the current disk data of virtual machine A.

[0231] In step S770, if it is determined that a full data backup is required for this backup, the first backup data and the fourth backup data are stored. The fourth backup data is the current disk data of virtual machine A that has not changed relative to the original disk data of virtual machine A (i.e., the data at the time of the backup before the current backup). In other words, the current disk data of virtual machine A is stored. Then, the aforementioned step S760 is executed.

[0232] In the above example, if it is determined that this backup requires an incremental data backup, the integrity of each second backup data backed up before this backup (within the current backup cycle) can be checked. After the check passes, the incremental data backup can be continued to ensure the availability of the incremental data chain formed (in the current backup cycle) and the data security of virtual machine A. If it is determined that this backup requires a full data backup, it is determined that this backup has entered a new backup cycle and is the first backup in the new backup cycle. Accordingly, the data in each data block in virtual disk A (i.e., the current disk data) can be directly stored to perform a full data backup of virtual machine A to ensure the data security of virtual machine A.

[0233] In some other possible examples, Figure 7 As shown, if the comparison result obtained in step S740 indicates that the integrity check of the third backup data in each second backup data fails (for example, the first data check code and the second data check code corresponding to the third backup data in each second backup data are different), the disaster recovery backup process is entered, that is, step S780 is executed. Specifically, Figure 7 As shown:

[0234] In step S780, if the integrity check of the third backup data in each second backup data fails, the second backup number corresponding to the third backup data is determined.

[0235] In this step, if the comparison result indicates that the integrity check of the third backup data in each second backup data fails (for example, the first data check code and the second data check code corresponding to the third backup data are different), it can be determined that the third backup data is damaged. Accordingly, the third backup data and each second backup data backed up after the third backup data cannot be used. At this time, disaster recovery backup of virtual machine A is required.

[0236] Specifically, the first computing device determines the second backup number corresponding to the third backup data (this determination may be based on a data identifier of the third backup data, or based on a correspondence between the third backup data and the second backup number). Then, in step S790, based on the second backup number and the second bitmap data, disaster recovery backup data for virtual machine A is determined. The disaster recovery backup data includes, in the current disk data of virtual machine A, data indicated by the second backup number, the first backup number, and the backup number identifiers therebetween.

[0237] In this step, the first computing device determines the data blocks corresponding to the second backup number, the first backup number, and the backup number identifiers therebetween from virtual disk A of virtual machine A based on the second backup number and the value of the bit corresponding to each data block in virtual disk A in the second bitmap data (i.e., the backup number identifier). The data in the data blocks corresponding to the second backup number, the first backup number, and the backup number identifiers therebetween are the aforementioned disaster recovery backup data.

[0238] In step S7100, the disaster recovery backup data is stored and the disaster recovery backup data is identified using the second backup number, the first backup number, and the backup number identifiers therebetween. Then, step S760 is executed.

[0239] In some possible examples, the first computing device can continue to store disaster recovery backup data based on the second backup data preceding the third backup data (in the current backup cycle). Using the second backup times, the first backup times, and the backup times between them, it can be identified that the disaster recovery backup data includes all data blocks that have changed relative to the disk data in the backup immediately preceding the third backup data. This allows for incremental re-backup of the damaged third backup data and subsequent backups, further reducing backup resource consumption and improving backup speed.

[0240] In some examples, the aforementioned use of the second backup number, the first backup number, and the backup number identifiers therebetween to identify disaster recovery backup data may include: using the second backup number, the first backup number, and the backup number identifiers therebetween as data identifiers of the disaster recovery backup data, so as to mark the disaster recovery backup data as including data that has changed from the previous backup corresponding to the second backup number to the current backup; or may include: storing the second backup number, the first backup number, and the backup number identifiers therebetween in correspondence with the disaster recovery backup data, for example, in the backup pool corresponding to the disaster recovery backup data, storing the correspondence between the data identifier (or storage address) of the disaster recovery backup data and the second backup number, the first backup number, and the backup number identifiers therebetween.

[0241] In some possible examples, the first computing device may copy each second backup data before the third backup data (in the current backup cycle), and continue to store the disaster recovery backup data based on the copied second backup data to form a new backup data chain (for the current backup cycle). Subsequently, to save storage space, the old backup data chain (i.e., the backup data chain containing the damaged third backup data) is deleted.

[0242] The following describes a specific example of a disaster recovery backup process for disk data of virtual machine A.

[0243] Assume that a backup cycle is set to one week, and data of virtual machine A is backed up at XX time every day.

[0244] Assume that virtual machine A is backed up for the first time on Sunday. At XX time on Sunday, the first computing device determines to back up virtual machine A for the first time and stores the data in all data blocks of virtual disk A. Figure 8 The full backup data-0 shown in the figure is first stored locally on the host machine of virtual machine A, and then the full backup data-0 is backed up to the backup environment (i.e., the backup pool), and the corresponding relationship between the full backup data-0 and the backup times identifier (i.e., 1) is stored in the backup environment (or the backup times identifier 1 can be used as the data identifier or name of the full backup data-0) to form an incremental data chain 1. Subsequently, the non-backup environment (such as the one in the backup pool) can also be backed up. Figure 8 The production environment shown is, for example, a local host machine of virtual machine A) with full backup data - 0 deletion to save local storage resources of the host machine.

[0245] At XX time on Monday, the first computing device determines to perform a second backup of virtual machine A. It is necessary to perform an incremental data backup of virtual machine A. Figure 8The incremental backup data -1 shown in the figure is first stored locally on the host machine of virtual machine A. After verifying that the full backup data -0 is not damaged, the incremental backup data -1 is backed up to the backup environment. In the backup environment, the corresponding relationship between the incremental backup data -1 and the backup times identifier (i.e. 2) is stored (or the backup times identifier 2 can be used as the data identifier or name of the incremental backup data -1). Subsequently, the non-backup environment (such as the one in Figure 8 In the production environment shown, for example, the incremental backup data of the host machine of virtual machine A (local) is deleted to save the local storage resources of the host machine.

[0246] When the XX time arrives on Tuesday and Wednesday, the data backup process of the first computing device on the virtual machine A can be referred to the data backup process of the first computing device on the virtual machine A when the XX time arrives on Monday, which will not be repeated here.

[0247] At XX time on Thursday, the first computing device determines to perform the fifth data backup of virtual machine A and needs to perform an incremental data backup of virtual machine A. At this time, the values ​​of ChgID1 and ChgID2 are both 4. The first bitmap data 5 corresponding to the current disk data of virtual disk A of virtual machine A is obtained from the host memory of virtual machine A. The first bitmap data 5 indicates the data changes of each data block in the virtual disk relative to the fourth backup.

[0248] The first computing device stores the first bitmap data 5 in the dynamic bitmap area of ​​the first file, and adds 1 to ChgID1 to obtain the added ChgID1, and stores it in the metadata area. At this time, ChgID1 = 5; then, based on the first bitmap data 5 stored in the dynamic bitmap area, a first bitmap check code is generated and stored in the metadata area.

[0249] Subsequently, the first computing device adds 1 to ChgID2 to obtain the incremented ChgID2. At this time, ChgID2=5, and the value of the incremented ChgID2 is equal to the backup times identifier 5 (i.e., the fifth backup); then, the value of the bit with the specified value (for example, 1) in the first bitmap data 5 is replaced with the incremented ChgID2, that is, replaced with 5, to obtain the second bitmap data 5, and the second bitmap data 5 is stored in the static bitmap area of ​​the first file, and the incremented ChgID2 is stored in the metadata area.

[0250] Next, the first computing device may call the preset third command, determine the bit with value ChgID2=5 (and its corresponding data block) based on the second bitmap data 5, and call the preset fourth command based on the data block corresponding to the bit with value ChgID2=5, and obtain the following from the virtual disk A: Figure 8 The incremental backup data -4 shown is first stored locally on the host machine of virtual disk A.

[0251] Next, obtain the verification code 01 corresponding to the aforementioned full backup data-0, the verification code 11 corresponding to the incremental backup data-1, the verification code 21 corresponding to the incremental backup data-2, and the verification code 31 corresponding to the incremental backup data-3 (the data backed up on Wednesday) in sequence; and generate verification code 02, verification code 12, verification code 22, and verification code 32 respectively based on the full backup data-0, incremental backup data-1, incremental backup data-2, and incremental backup data-3 currently stored in the backup environment; compare verification code 01 with verification code 02, compare verification code 11 with verification code 12, compare verification code 21 with verification code 22, and compare verification code 31 with verification code 32.

[0252] If the check code 01 is the same as the check code 02, the check code 11 is the same as the check code 12, the check code 21 is the same as the check code 22, but the check code 31 is different from the check code 32, then it is determined that the incremental backup data -3 is damaged; at this time, it is determined that the data of virtual machine A needs to be backed up for disaster recovery. Specifically, the backup times identifier 4 corresponding to the incremental backup data -3 is determined, that is, ChgID2 after adding one (that is, 4). Based on the backup times identifier 4 corresponding to the incremental backup data -3, the aforementioned third command is called, and based on the second bitmap data 5 stored in the first file, the bits (and their corresponding data blocks) with values ​​greater than or equal to 4 are determined, and the preset fourth command is called, based on the data in the data blocks corresponding to the bits with values ​​greater than or equal to 4 in the second bitmap data 5 in virtual disk A, the following is obtained. Figure 8 The incremental backup data-5 shown here includes the aforementioned incremental backup data-3 and incremental backup data-4.

[0253] The incremental backup data -5 is backed up to the backup environment (i.e., the backup pool), and in the backup environment, the incremental backup data -5 is associated with the backup times identifier 4 corresponding to the incremental backup data -3 and the backup times identifier 5 corresponding to the incremental backup data -4 (or the backup times identifier 4 corresponding to the incremental backup data -3 and the backup times identifier 5 corresponding to the incremental backup data -4 are used as the name of the incremental backup data -5). Subsequently, a corresponding verification code 51 may be generated based on the stored incremental backup data -5, and the verification code 51 may be stored corresponding to the incremental backup data -5, so as to be used to verify the data integrity of the incremental backup data -5 during the next backup.

[0254] Specifically, such as Figure 8 As shown, the first computing device can replicate the Figure 8In the example shown, the full backup data -0, incremental backup data -1, and incremental backup data -2 in backup data chain 1 are copied and combined with incremental backup data -5 to form a new incremental data chain 2, which is the disaster recovery backup incremental data chain 2. All data in backup data chain 1 is subsequently deleted.

[0255] Subsequently, on Fridays and Saturdays of this week (i.e., within the backup cycle), until time XX on the following Sunday, the first computing device can continue to perform incremental data backup on virtual machine A based on incremental data chain 2, thereby reducing backup resource consumption and increasing backup speed.

[0256] Based on the method in the above embodiment, the embodiment of the present application provides a data backup device. Figure 9 , Figure 9 It is a structural diagram of a data backup device provided in an embodiment of the present application.

[0257] like Figure 9 As shown, the data backup device 900 may include: a first acquisition module 910, configured to obtain the first bitmap data corresponding to the current disk data of the virtual machine, and store the first bitmap data in a first file, the first file being stored in a non-volatile memory, the first bitmap data being used to indicate the data changes of the current disk data of the virtual machine relative to the original disk data of the virtual machine; a first determination module 920, configured to determine the second bitmap data based on the first bitmap data, and store the second bitmap data in the first file, the second bitmap data being used to indicate the data changes of the current disk data of the virtual machine relative to the original disk data of the virtual machine and the first backup number; a first storage module 930, configured to store the first backup data, the first backup data being the data of the change of the current disk data of the virtual machine relative to the original disk data of the virtual machine.

[0258] Some possible examples include:

[0259] A first creation module (not shown in the figure) is configured to create a snapshot based on the current disk data of the virtual machine before obtaining the first bitmap data corresponding to the current disk data of the virtual machine;

[0260] Also includes:

[0261] A merging module (not shown in the figure) is configured to merge the snapshot with the current disk data of the virtual machine after storing the first backup data.

[0262] Some possible examples include:

[0263] The second creation module (not shown in the figure) is configured to create a first file corresponding to the virtual machine before obtaining the first bitmap data corresponding to the current disk data of the virtual machine, wherein the first file includes a metadata area, a dynamic bitmap area and a static bitmap area, the metadata area is used to store the metadata of the first file, the dynamic bitmap area is used to store the first bitmap data, and the static bitmap area is used to store the second bitmap data.

[0264] In some possible examples, the dynamic bitmap area includes a first area and a second area, and the first area and the second area are used to store the first bitmap data corresponding to each backup process in turn.

[0265] In some possible examples, the metadata area further stores a first bitmap check code corresponding to the dynamic bitmap area, where the first bitmap check code is generated based on the first bitmap data corresponding to a previous backup process;

[0266] The system further includes: a first generating module (not shown in the figure) configured to generate a second bitmap check code based on the first bitmap data currently stored in the dynamic bitmap area and corresponding to the previous backup process after detecting a load request from the virtual machine to load the first bitmap data into the memory of its host machine before obtaining the first bitmap data corresponding to the current disk data of the virtual machine, wherein the load request is sent after the virtual machine is restarted;

[0267] A first comparison module (not shown in the figure) is configured to compare the first bitmap check code with the second bitmap check code;

[0268] The first loading module (not shown) is configured to load the first bitmap data corresponding to the previous backup process currently stored in the dynamic bitmap area into the host machine memory if the first bitmap check code is the same as the second bitmap check code.

[0269] Some possible examples include:

[0270] An initialization module (not shown in the figure) is configured to initialize the bitmap data in the host memory of the virtual machine after storing the second bitmap data in the first file.

[0271] In some possible examples, the first storage module 930 includes: a verification unit (not shown in the figure), configured to perform integrity verification on each second backup data backed up before the current backup; a first storage unit (not shown in the figure), configured to store the first backup data if the integrity verification of each second backup data passes.

[0272] In some possible examples, the verification unit is specifically configured to obtain a first data verification code corresponding to each second backup data, wherein the first data verification code corresponding to each second backup data is generated and stored based on the corresponding second backup data when backing up the corresponding second backup data;

[0273] generating respective second data check codes based on respective currently stored second backup data;

[0274] For each second backup data, the first data verification code and the second data verification code corresponding to the second backup data are compared. If the comparison result indicates that the first data verification code and the second data verification code corresponding to each second backup data are the same, it is determined that the integrity check of each second backup data has passed.

[0275] In some possible examples, the apparatus further includes:

[0276] A second determining module (not shown in the figure) is configured to determine the second backup number corresponding to the third backup data if the integrity check of the third backup data in each second backup data fails;

[0277] a third determining module (not shown in the figure), configured to determine disaster recovery backup data of the virtual machine based on the second backup number and the second bitmap data, the disaster recovery backup data including, in the current disk data of the virtual machine, data indicated by the second backup number, the first backup number, and backup number identifiers therebetween;

[0278] The second storage module (not shown in the figure) is configured to store the disaster recovery backup data and identify the disaster recovery backup data using at least the first backup number.

[0279] In some possible examples, the first bitmap data includes a specified bit set to a specified value, where the specified value is used to indicate data of a change in the current disk data of the virtual machine relative to the original disk data of the virtual machine;

[0280] The first determining module 920 is specifically configured to replace the specified value of the specified bit in the first bitmap data with the first backup number to obtain the second bitmap data.

[0281] In some possible examples, the first storage module 930 is specifically configured to store the first backup data in a designated storage area of ​​the host machine of the virtual machine; or, to store the first backup data in a backup pool corresponding to the virtual machine; or, to store the first backup data in a designated storage area of ​​the host machine of the virtual machine; and to store the first backup data stored in the designated storage area in the backup pool corresponding to the virtual machine.

[0282] In some possible examples, the format of the first file is any one of the following formats: raw format or qcow2 format.

[0283] It should be understood that the above-mentioned device is used to execute the method in the above-mentioned embodiment. The implementation principle and technical effect of the corresponding program module in the device are similar to those described in the above-mentioned method. The working process of the device can refer to the corresponding process in the above-mentioned method and will not be repeated here.

[0284] Based on the method in the above embodiment, Figure 10 As shown, an embodiment of the present application provides a computing device 1000. The computing device may include: a first memory and a second memory, wherein the first memory is used to store programs, and the second memory is a non-volatile memory used to store a first file; at least one processor is used to execute the program stored in the first memory; the processor, the first memory, and the second memory are connected via a bus, wherein when the program stored in the first memory is executed, the processor is used to execute the method in the above embodiment.

[0285] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0286] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0287] It is understood that the order of execution of the steps in the above embodiments does not necessarily imply a specific order of execution. The order of execution of each process should be determined by its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. In addition, in some possible implementations, the steps in the above embodiments can be selectively executed according to actual circumstances, and can be executed partially or completely, which is not limited here.

[0288] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0289] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0290] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0291] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

Claims

1. A data backup method, characterized in that: The method comprises: Obtaining first bitmap data corresponding to current disk data of the virtual machine, and storing the first bitmap data in a first file, wherein the first file is stored in a non-volatile memory, and the first bitmap data is used to indicate data changes of the current disk data of the virtual machine relative to the original disk data of the virtual machine; Determine second bitmap data based on the first bitmap data, and store the second bitmap data in the first file, the second bitmap data being used to indicate data changes of current disk data of the virtual machine relative to original disk data of the virtual machine and a first backup number; The first backup data is stored, where the first backup data is data of changes of the current disk data of the virtual machine relative to the original disk data of the virtual machine.

2. The method according to claim 1, characterized in that Before obtaining the first bitmap data corresponding to the current disk data of the virtual machine, the method further includes: Creating a snapshot based on current disk data of the virtual machine; After storing the first backup data, the method further includes: The snapshot is merged with the current disk data of the virtual machine.

3. The method according to claim 1 or 2, characterized in that Also includes: Create a first file corresponding to the virtual machine, wherein the first file includes a metadata area, a dynamic bitmap area and a static bitmap area, the metadata area is used to store metadata of the first file, the dynamic bitmap area is used to store the first bitmap data, and the static bitmap area is used to store the second bitmap data.

4. The method according to claim 3, characterized in that The dynamic bitmap area includes a first area and a second area, and the first area and the second area are used to store the first bitmap data corresponding to each backup process in turn.

5. The method according to claim 3 or 4, characterized in that The metadata area also stores a first bitmap check code, where the first bitmap check code is generated based on the first bitmap data corresponding to the previous backup process; Before obtaining the first bitmap data corresponding to the current disk data of the virtual machine, the method further includes: After detecting a load request of the virtual machine to load the first bitmap data into the memory of its host machine, generating a second bitmap check code based on the first bitmap data corresponding to the previous backup process currently stored in the dynamic bitmap area, the load request being sent after the virtual machine is restarted; Comparing the first bitmap check code with the second bitmap check code; If the first bitmap check code is the same as the second bitmap check code, the first bitmap data currently stored in the dynamic bitmap area is loaded into the host machine memory.

6. The method according to claim 1, characterized in that After storing the second bitmap data in the first file, the method further includes: Initialize the bitmap data in the host memory of the virtual machine.

7. The method according to any one of claims 1 to 6, characterized in that: The first bitmap data includes a specified bit set to a specified value, wherein the specified value is used to indicate data of a change in the current disk data of the virtual machine relative to the original disk data of the virtual machine; The determining the second bitmap data based on the first bitmap data comprises: The specified value of the specified bit in the first bitmap data is replaced with the first backup number to obtain the second bitmap data.

8. The method according to any one of claims 1 to 7, characterized in that: The storing of the first backup data comprises: storing the first backup data in a designated storage area of ​​the host machine of the virtual machine; or, storing the first backup data in a backup pool corresponding to the virtual machine; or The first backup data is stored in a designated storage area of ​​the host machine of the virtual machine; and the first backup data stored in the designated storage area is stored in a backup pool corresponding to the virtual machine.

9. The method according to any one of claims 1 to 8, characterized in that The format of the first file is any one of the following formats: raw format or qcow2 format.

10. A computing device, characterized in that: include: A first memory, used for storing programs; A second memory, used for storing the first file, wherein the second memory is a non-volatile memory; at least one processor, configured to execute the program stored in the first memory; When the program stored in the first memory is executed, the processor is used to execute the method according to any one of claims 1 to 9.

Images