Data backup method and computing device

Abstract

Embodiments of the present application relate to the technical field of virtual machines, and provide a data backup method and a computing device. The method comprises: acquiring first bitmap data corresponding to current disk data, 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 for indicating a data change situation of the current disk data relative to original disk data of a virtual machine; determining second bitmap data on the basis of the first bitmap data, and storing the second bitmap data in the first file, wherein the second bitmap data is used for indicating the data change situation of the current disk data relative to the original disk data and the number of times of first backup; and storing changed data of the current disk data relative to the original disk data. In this way, a new backup mode for disk data of the virtual machine is implemented, thereby avoiding full backup when backup data anomalies occur, and providing a foundation for reducing storage resources and time consumption.

Description

Data backup method and computing device

[0001] The present application claims priority to the Chinese patent application No. 202411133590.5, filed on August 16, 2024, and entitled "A data backup method and computing device", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the technical field of virtual machines, and in particular to a data backup method and computing device. BACKGROUND

[0003] At present, in order to better improve the resource utilization of physical computing devices, accelerate the deployment of application programs, reduce energy consumption, and improve application compatibility, more and more enterprises and organizations use virtualization technology, that is, deploy virtual machines on physical computing devices for work.

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

[0005] At present, in the process of backing up the disk data of a virtual machine, in order to reduce backup resource consumption and speed up data backup, an incremental backup method is generally used to backup the disk data of a virtual machine (i.e. the data in the virtual disk of a virtual machine). For example, the CBT (Changed Block Tracking) technology can be used to determine the current disk data of a virtual machine relative to the data changed since the previous backup (hereinafter referred to as incremental data), and then backup the determined incremental data, thereby realizing incremental backup of the disk data of a virtual machine.

[0006] However, in the incremental backup process, in a backup period, since the backup data chain formed by the backup period, except that the first backup is full data backup, the incremental backup data of each subsequent backup is the data changed since the previous backup, if the backup data in the backup data chain is damaged (or lost), the damaged (or lost) backup data and the subsequent backup data in the backup data chain cannot be used, accordingly, it is also impossible to continue incremental backup relative to the backup data in the backup data chain.

[0007] In the related art, after the above problems occur, the incremental backup process of the current backup period is generally stopped, and the incremental backup process of a new backup period is entered. Specifically, the disk data of the virtual machine is re-full backed up to obtain new full backup data, and then, on the basis of the new full backup data, in a backup period, each subsequent backup only backs up the data of the virtual machine that has changed relative to the previous backup, that is, the incremental backup data. This process increases the storage resources and time consumption of data backup to some extent.

[0008] Therefore, how to provide a new data backup method to help solve the above problems has become an urgent problem to be solved. SUMMARY

[0009] The embodiments of the present application provide a data backup method, device, computing device, computer storage medium and computer program product to implement a new virtual machine disk data backup method that reduces storage resources and time consumption.

[0010] In a first aspect, the embodiments of the present application provide a data backup method, which comprises:

[0011] Obtaining first bitmap data corresponding to the 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 the data change of the current disk data of the virtual machine relative to the original disk data of the virtual machine;

[0012] Based on the first bitmap data, determining second bitmap data, and storing the second bitmap data in the first file, wherein the second bitmap data is used to indicate the data change of the current disk data of the virtual machine relative to the original disk data of the virtual machine and the first backup times;

[0013] Storing first backup data, wherein the first backup data is the data of the current disk data of the virtual machine that has changed relative to the original disk data of the virtual machine.

[0014] In the above process, the first file stored in the non-volatile memory is added, and when the disk data of the virtual machine is backed up, the first bitmap data corresponding to the current disk data of the virtual machine is stored in the first file to realize persistent storage of the first bitmap data indicating the data change of the current disk data relative to the data in the original disk data of the virtual machine; then, based on the first bitmap data, the second bitmap data indicating the data change of the current disk data relative to the data in 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, so that 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. Correspondingly, after the multiple backup processes, the second bitmap data stored in the first file can persistently indicate which data blocks in the disk store the backup data at each backup. This provides a basis for realizing disaster recovery backup in subsequent backup processes. For example, in a backup process, if it is determined that the backup data stored in a previous backup process is damaged, the backup data stored in which data blocks in the disk at each backup (i.e. one backup number corresponds to one backup) can be combined with the second bitmap data indicated by the backup data to more conveniently locate the backup data after the damaged backup data, and then the damaged backup data and the backup data after the damaged backup data can be re-backed up to realize disaster recovery backup without the need for full backup again, thereby providing a basis for reducing storage resources and time consumption in the data backup process and improving the disaster recovery capability of the backup data.

[0015] In some possible examples, before the first bitmap data corresponding to the current disk data of the virtual machine is acquired, the method further includes: creating a snapshot based on the current disk data of the virtual machine; and after the first backup data is stored, the method further includes: merging the snapshot with the current disk data of the virtual machine.

[0016] In the above examples, when the backup process starts, a snapshot is created based on the current disk data of the virtual machine, and the snapshot is merged with the current disk data after the storage of the first backup data is completed, so as to avoid the loss of user new write data in the backup process.

[0017] In some possible examples, before the first bitmap data corresponding to the current disk data of the virtual machine is acquired, the method further 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 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.

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

[0019] 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 alternately store the first bitmap data corresponding to each backup process. In this example, the first area and the second area of the dynamic bitmap area are set to facilitate complete storage of the first bitmap data and facilitate management of the stored first bitmap data.

[0020] 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 a previous backup process. Before the first bitmap data corresponding to the current disk data of the virtual machine is obtained, the method further includes: after detecting a loading request for loading the first bitmap data to the host memory of the virtual machine, generating a second bitmap check code based on the first bitmap data corresponding to the previous backup process and currently stored in the dynamic bitmap area, the loading request is sent after the virtual machine is restarted; comparing the first bitmap check code with the second bitmap check code; and 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 to the host memory.

[0021] In the above example, after detecting the loading request for loading the first bitmap data to the host memory of the virtual machine 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 used to check the first bitmap data corresponding to the previous backup process and stored in the dynamic bitmap area at the time of the loading request, 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 is not modified, that is, the first bitmap data corresponding to the previous backup process and currently stored in the first file is accurate and consistent with the first bitmap data corresponding to the previous backup process and stored in the first file. At this time, the first bitmap data corresponding to the previous backup process and currently stored in the dynamic bitmap area is loaded to the host memory, thereby ensuring the accuracy of the loaded first bitmap data and achieving effective perception of whether the first bitmap data loaded from the first file to the host memory is consistent.

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

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

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

[0025] In the above examples, after storing the first backup data, integrity check is performed on each second backup data backed up before the first backup data. If the integrity check of each second backup data passes, it indicates that the data backed up before the first backup data (i.e., the current backup) is not damaged, and then the first backup data can 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, so as to avoid the damage of any second backup data, and even if the first backup data is stored, it cannot be used (to restore the corresponding state of the virtual machine), which causes waste of storage resources and storage time.

[0026] In some possible examples, the performing of the integrity check on each second backup data backed up before the current backup includes: obtaining a first data check code corresponding to each second backup data, wherein the first data check 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 a second data check code based on each currently stored second backup data; and comparing the first data check code and the second data check code corresponding to each second backup data, wherein if the comparison result indicates that the first data check code and the second data check code corresponding to each second backup data are the same, it is determined that the integrity check of each second backup data passes.

[0027] In the above examples, the first data check code and the second data check code corresponding to each second backup data are compared to determine whether each second backup data is damaged (e.g., modified). If the comparison result indicates that the first data check code and the second data check code corresponding to each second backup data are the same, it is determined that each second backup data at the time of the current backup is consistent with the second backup data itself when it is backed up, and neither of them is damaged or modified, thereby achieving the integrity check of each second backup data.

[0028] In some possible examples, the method further includes: determining a second backup number corresponding to third backup data in the second backup data if integrity verification of the third backup data fails; determining 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 the second backup number, the first backup number, and data indicated by the backup number identifier therebetween; and storing the disaster recovery backup data and identifying the disaster recovery backup data by using the second backup number, the first backup number, and the backup number identifier therebetween.

[0029] In the above examples, in the case where integrity verification of the third backup data fails, it can be determined that the third backup data is damaged (for example, modified), and in the case where the backup process adopts an incremental backup manner, the third backup data and each second backup data after the third backup data cannot be used (to restore the corresponding state of the virtual machine), that is, the disaster recovery backup data is directly determined and stored, and the disaster recovery backup process is performed, thereby avoiding re-performing full backup and reducing storage resource consumption and time consumption of the backup process.

[0030] 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 changed data of the current disk data of the virtual machine relative to the original disk data of the virtual machine; and the 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.

[0031] In the above examples, the value of the specified bit in the first bitmap data, which indicates 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 corresponding relationship between the changed data of the current disk data relative to the original disk data (that is, data that needs to be backed up) and the first backup number (that is, backup) and therebetween.

[0032] In some possible examples, the storing the first backup data includes: storing the first backup data in a specified storage area of a host 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 specified storage area of a host of the virtual machine, and storing the first backup data stored in the specified storage area to the backup pool corresponding to the virtual machine.

[0033] In the above examples, the storage manner of storing the first backup data is provided, which includes storage on the host, storage in the backup pool, or storage on the host and then storage in the backup pool, to implement various backup storage manners of data.

[0034] In some possible examples, the format of the first file is any one of the following formats: a raw format or a qcow2 format, so that the first bitmap data and the second bitmap data can be accurately and conveniently persisted.

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

[0036] A first obtaining module, configured to obtain first bitmap data corresponding to 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 a data change situation of the current disk data of the virtual machine relative to original disk data of the virtual machine;

[0037] 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 the data change situation of the current disk data of the virtual machine relative to the original disk data of the virtual machine and a first backup number;

[0038] A first storing module, configured to store first backup data, the first backup data being data changed by the current disk data of the virtual machine relative to the original disk data of the virtual machine.

[0039] 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; 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 configured to execute the method described in the first aspect or any possible implementation manner of the first aspect.

[0040] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, the computer readable storage medium storing a computer program, when the computer program is run on a processor, causing the processor to execute the method described in the first aspect or any possible implementation manner of the first aspect.

[0041] In a fifth aspect, an embodiment of the present application provides a computer program product, characterized by, when the computer program product is run on a processor, causing the processor to execute the method described in the first aspect or any possible implementation manner of the first aspect.

[0042] It can be understood that the beneficial effects of the second aspect to the fifth aspect can be referred to the related description in the first aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0043] FIG. 1 is a schematic diagram of a scene of incremental backup according to an embodiment of the present application;

[0044] FIG. 2 is a schematic diagram of a data backup application scene according to an embodiment of the present application;

[0045] FIG. 3 is a schematic diagram of a data backup method according to an embodiment of the present application;

[0046] FIG. 4 is a schematic diagram of a structure of a first file according to an embodiment of the present application;

[0047] FIG. 5 is a schematic diagram of a second bitmap data updating process in the first file according to an embodiment of the present application;

[0048] FIG. 6 is a schematic diagram of a data backup process according to an embodiment of the present application;

[0049] FIG. 7 is a schematic diagram of another data backup method according to an embodiment of the present application;

[0050] FIG. 8 is a schematic diagram of a disaster recovery backup scene according to an embodiment of the present application;

[0051] FIG. 9 is a schematic diagram of a structure of a data backup apparatus according to an embodiment of the present application;

[0052] FIG. 10 is a schematic diagram of a structure of a computing device according to an embodiment of the present application. DETAILED DESCRIPTION

[0053] The term “and / or” in the present document is used to describe an association relationship of associated objects, which means that there can be three relationships, for example, A and / or B can mean that there are three cases of A alone, A and B together, and B alone. The symbol “ / ” in the present document represents an or relationship of associated objects, for example, A / B represents A or B.

[0054] The terms “first” and “second” and the like in the present description and claims are used to distinguish different objects, and are not used to describe a specific order of the objects. For example, the first response message and the second response message are used to distinguish different response messages, and are not used to describe a specific order of the response messages.

[0055] In the description herein, it should be understood that the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "circumferential", and the like are intended to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation.

[0056] In the embodiments of the present application, the words "exemplary" or "for example" are used to mean serving as an example, instance, or illustration, and not necessarily to imply any preference or superiority. In other words, the use of the words "exemplary" or "for example" is intended to present concepts in a concrete manner, and is not intended to be limiting or to imply any preference or superiority.

[0057] In order to facilitate the understanding of the technical solutions of the embodiments of the present application, the terms involved in the present application are explained as follows.

[0058] Virtual Machine (VM): refers to a complete computer system that is simulated by software, runs in a completely isolated environment, and has complete hardware system functions. The work that can be completed in an entity computer (also referred to as an entity computing device) can be realized in a virtual machine. When a virtual machine is created in an entity computing device, part of the hard disk and memory capacity of the entity computing device needs to be used as the hard disk and memory capacity of the virtual machine. Each virtual machine has independent CMOS (Complementary Metal-Oxide-Semiconductor), hard disk and operating system, and can be operated like an entity computing device. The entity computing device that creates and runs the virtual machine can be referred to as the host computer where the virtual machine is located.

[0059] Virtual disk is a virtualized hard disk, which can be divided into N blocks (Block ID) for storing and backing up the disk data written by the corresponding virtual machine. The disk data stored by the virtual disk, i.e., the disk data written by the virtual machine into its corresponding virtual disk, can include but is not limited to user data of the virtual machine and operating system data of the virtual machine.

[0060] QEMU is an open-source virtualization platform that can emulate various hardware platforms, including x86, ARM, and others, and support the running of multiple operating systems, such as Linux, Windows, FreeBSD, and others. QEMU can be used for virtualization, emulation, debugging, and testing, among other applications. QEMU can simulate a physical computing device as multiple virtual machines, providing an isolated environment for users to run different applications and operating systems. QEMU is a lightweight virtual machine software that is easy to install and configure, and has good portability and cross-platform compatibility.

[0061] QEMU can also manage virtual machines and track virtual disk IO (Input / Output) in real time. Upon receiving a disk IO write request from a virtual machine, QEMU writes the data carried by the disk IO write request to a certain data block or blocks of the virtual disk and supports incremental backup of the virtual machine based on the CBT (Changed Block Tracking) technology. Specifically, a bitmap data (i.e., bitmap table) is created in the host memory of the virtual machine, and the bitmap data is updated based on the ID (Identity document) of the data block (i.e., changed block) where the data is written. The bitmap data includes bits corresponding to the IDs of the data blocks in the virtual disk, indicating whether the data stored in the data blocks has changed. When the value of the bit corresponding to the ID of a data block is a specified value (e.g., 1), it indicates that the data in the corresponding data block has changed relative to the previous backup. When the value of the bit corresponding to the ID of a data block is a non-specified value (e.g., 0), it indicates that the data in the corresponding data block has not changed relative to the previous backup. During backup, only the modified data blocks (i.e., data blocks marked as "1" in the bitmap data) need to be backed up, and the entire virtual disk (i.e., all data blocks) does not need to be fully backed up.

[0062] Incremental backup is a data backup method that generally only backs up the data that has been added or modified since the previous backup after a full backup. 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 marks the end of a backup cycle.

[0063] As shown in FIG. 1 is an exemplary scenario of incremental backup, wherein, for the data in the disk, at T1, full backup is performed to obtain full backup data #1, at T2, incremental backup is performed to obtain incremental backup data *1, which is the data changed relative to the full backup data #1 at T1; at T3, incremental backup is performed to obtain incremental backup data *2, which is the data changed relative to the data in the disk at T1, and so on, at Tn, incremental backup data *Tn-1 is obtained.

[0064] Bitmap: is a collection of bits, is a data structure, which can be used to record a large number of 0-1 state, its advantage is that a very high space utilization can save a large number of 0-1 state.

[0065] Snapshot is a technology for recording all data states in a virtual disk, which can save the complete state of the disk at a certain time, so that the disk snapshot can be used to restore to the state at this time (for example, restore to the state of the virtual machine at this time). Snapshot can also be understood as a complete available copy of a specified data set (such as a virtual disk), which includes the image of the corresponding data at a certain time point (the time point when the copy starts). Snapshot can be a copy of the data it represents, or a replica of the data.

[0066] As described above, in the incremental backup process, in a backup period, the incremental backup data of each backup in the backup data chain formed by the backup period is relative to the data 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, the incremental backup cannot continue relative to the backup data in the backup data chain.

[0067] Currently, after the above problem occurs, the incremental backup process of the backup period is stopped, and the incremental backup process of a new backup period is entered. Specifically, full backup is performed on the data in the virtual disk of the virtual machine to obtain new full backup data, and then, on the basis of the new full backup data, each backup only backs up the data changed relative to the previous backup in the virtual disk of the virtual machine, i.e. incremental backup data. This process increases the storage resources and time consumption of data backup to some extent.

[0068] In view of this, the embodiment of the present application provides a data backup method, wherein in the data backup process, first bitmap data corresponding to current disk data of a virtual machine is acquired, and the first bitmap data is stored in a first file, the first file is stored in a nonvolatile memory, and the first bitmap data is used to indicate data change of the current disk data of the virtual machine relative to data in original disk data of the virtual machine; second bitmap data is determined based on the first bitmap data, and the second bitmap data is stored in the first file, and the second bitmap data is used to indicate data change of the current disk data of the virtual machine relative to data in the original disk data of the virtual machine and a first backup number; first backup data is stored, and the first backup data is data changed from the current disk data of the virtual machine relative to the original disk data of the virtual machine.

[0069] Based on the above backup process, data backup of disk data of the virtual machine is implemented to protect data security of the virtual machine, and the second bitmap data can persistently indicate that the first backup data is data stored in the backup process corresponding to the first backup number, and in the 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 store backup data at each backup, thereby providing a basis for disaster recovery backup in subsequent data backup processes. For example, in a backup process, if it is determined that backup data stored in a previous backup process is damaged, the disk data in which data blocks in the virtual disk of the virtual machine store disk data at each backup (i.e., a backup number identifier corresponds to a backup) can be indicated by the second bitmap data stored in the first file, so that the backup data after the damaged backup data can be more conveniently located, and then the damaged backup data and the backup data after the damaged backup data can be re-backed up to implement disaster recovery backup without performing full backup again. The above process provides a basis for reducing storage resources and time consumption in the backup process, and can enhance the disaster recovery capability of the backup data.

[0070] In order to facilitate understanding of the technical scheme of the embodiment of the present application, the data backup process of the embodiment of the present application is introduced below.

[0071] Exemplarily, FIG. 2 shows a schematic diagram of an application scenario of an embodiment of the present application. The data backup system shown in FIG. 2 includes a computing device and a backup pool, which can be composed of one or more storage devices (or computing devices capable of providing storage space). The computing device includes a processor and a non-volatile memory and a memory, which are connected through a bus. The computing device can deploy multiple virtual machines (such as virtual machines VM1 and VM2 shown in FIG. 2), and can also deploy a virtualization platform and a backup unit. Correspondingly, the computing device can run the deployed virtual machines, virtualization platform and backup unit through the processor thereof; the computing device runs the virtual machines through the processor to provide various service services for users, runs the virtualization platform through the processor to manage the virtual machines, and can also run the backup unit through the processor to provide data backup services for the virtual machines. It can be understood that the computing device serves as a host machine for the virtual machines running thereon.

[0072] As shown in FIG. 2, 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 virtualization platform writes the data carried by the disk IO write request into a certain data block or certain data blocks of the virtual disk of VM1; and records the data change of each data block in the virtual disk of VM1 in the bitmap data of VM1 in the memory of the computing device, that is, records the data change of the current disk data of VM1 relative to the original disk data of VM1.

[0073] Subsequently, when it is determined that data backup of VM1 is needed, the backup unit creates a snapshot based on the current disk data of the virtual machine through the virtualization platform; and obtains the bitmap data corresponding to the current disk data of VM1 from the memory of the computing device through the virtualization platform, which is referred to as first bitmap data. Then, the backup unit stores the first bitmap data in a first file, and the first file is stored in the non-volatile memory mentioned above. The first bitmap data is used to indicate the data change of the current disk data of VM1 relative to the original disk data thereof. Next, the backup unit determines 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 change of the current disk data of VM1 relative to the original disk data thereof and the first backup times; and stores the first backup data, which is the data changed from the original disk data of VM1 to the current disk data thereof.

[0074] During the backup, there can be a case that the virtualization platform receives a new disk IO write request of VM1, in order to avoid the data carried by the new disk IO write request being lost during the backup, the virtualization platform writes the data carried by the disk IO write request of VM1 received during the backup into the snapshot created by the backup, and then merges the snapshot of the new disk data with the aforementioned current disk data of VM1 after storing the first backup data.

[0075] In some examples, in order to ensure the accurate record of the newly added disk data after the current 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, i.e., replace the value of the bit set to the specified value (e.g., 1) in the bitmap data in the memory with the non-specified value (e.g., 0), so that the data change of the disk data of VM1 can be accurately recorded based on the bitmap data in the memory.

[0076] In 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 changed with respect to the aforementioned current disk data of VM1 in the snapshot as target data, and updates the initialized bitmap data in the memory of the computing device based on the target data.

[0077] In some specific examples, based on the target data, each data block to which the target data belongs can be determined, referred to as a change block, and accordingly, the value of the bit corresponding to each change block in the initialized bitmap data in the memory of the computing device can be replaced from the non-specified value (e.g., 0) to the specified value (e.g., 1) based on each change block to which the target data belongs.

[0078] In the data backup system shown in FIG. 2, the communication between the virtual machine, the virtualization platform and the backup unit deployed in the computing device can be implemented through internal calls of the processor, and the communication between the computing device and the backup pool can be implemented through network requests.

[0079] In some possible examples, the backup unit can exist in the form of a plug-in of the virtualization platform, and accordingly, the backup unit can be considered as a functional unit of the virtualization platform.

[0080] It can be understood that the structure of the data backup system in the above examples is only exemplary and does not constitute a limitation on the structure of the data backup system. In yet other examples, the data backup system can include multiple computing devices and multiple backup pools, wherein the above-mentioned virtualization platform, backup unit and virtual machine can be deployed in different computing devices, and each backup pool can be composed of one or more storage devices (or computing devices that can provide storage space). etc.

[0081] Next, based on the description of the above examples, the data backup method provided by the embodiments of the present application is introduced.

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

[0083] 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 and provide data backup service through the virtualization platform and the backup unit. In yet some possible examples, the virtualization platform can be deployed in a non-first computing device, and accordingly, the first computing device can jointly manage the one or more virtual machines and provide data backup service through the device in which the virtualization platform is deployed.

[0084] Each virtual machine corresponds to a virtual disk, and each virtual disk can be divided into one or more data blocks for storing disk data of the corresponding virtual machine. In one possible example, each data block of a single virtual disk can be obtained by uniformly dividing 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 embodiments of the present application do not limit the specific storage format of the virtual disk. The data backup process provided by the embodiments of the present application can achieve persistent storage of the bitmap data corresponding to the virtual disk, and can also persistently record the correspondence between each backup process and the backup data stored by each backup process.

[0085] In yet some possible examples, the one or more virtual machines can be deployed in one or more second computing devices, which can include or not include the first computing device. The one or more second computing devices are taken as an example of the first computing device in the following description. When the one or more virtual machines are deployed in the first computing device, the first computing device can be referred to as a host of the one or more virtual machines. Accordingly, the memory of the first computing device can be referred to as the host memory of the one or more virtual machines deployed therein.

[0086] The following describes the data backup process by taking any virtual machine A in one or more virtual machines as an example. For the data backup process corresponding to other virtual machines, refer to the data backup process corresponding to the virtual machine A. In an embodiment of the present application, the first computing device backs up the disk data in the virtual disk A of the virtual machine A (hereinafter referred to as the disk data of the virtual machine A) by running the backup unit and the virtualization platform in an incremental backup manner. The following describes the data backup process by taking the backup unit, the virtualization platform, and the virtual machine A all running on the first computing device as an example.

[0087] As shown in FIG. 3, the method can include the following steps S310-S340:

[0088] At step 310, a first file corresponding to the virtual machine A is created, where 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 (hereinafter referred to as first bitmap data) obtained from the host memory of the virtual machine A, and the static bitmap area is used to store second bitmap data. The second bitmap data can be used to indicate the data change of the disk data of the virtual machine A and the backup number identifier of each backup process.

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

[0090] In some examples, when the virtual machine A is started, if the first file corresponding to the virtual machine A does not store the relevant data (for example, the first bitmap data) of the virtual machine A in the backup process, the virtualization platform can create and store the bitmap data corresponding to the virtual machine A in the host memory of the virtual machine A when the virtual machine A is started.

[0091] The bitmap data corresponding to the virtual machine A can include bits corresponding to each data block in the virtual disk A, and each bit is used to store a value indicating the data change in the corresponding data block. For example, the value of the bit corresponding to the i th data block in the bitmap data is set to a specified value (for example, 1), which can indicate that the data in the i th data block of the virtual disk A is changed. The value of the bit corresponding to the i th data block is set to a non-specified value (for example, 0), which can indicate that the data in the i th data block of the virtual disk A is not changed.

[0092] In the case where the disk data in the virtual disk A has not been backed up, the "change" (or no change) indicating the change in the data in the i-th data block of the virtual disk A can be relative to the data in the i-th data block of the virtual disk A at the time when the virtual machine A is started. In the case where the disk data A has been backed up, the "change" (or no change) indicating the change in the data in the i-th data block of the virtual disk A can be relative to the data in the i-th data block at the time when the data storage of the previous backup process for the virtual disk A is completed.

[0093] In some examples, at the time when the virtual machine A is started, the first file can have stored the bitmap data obtained from the host memory at the time when the last backup in the previous running process of the current start of the virtual machine A. In this case, the backup unit can load the bitmap data stored in the first file into the host memory, so that the virtualization platform can continue to track the data change of the disk data of the virtual machine A on the basis of the bitmap data.

[0094] It can be understood that the step of creating the first file can be performed once in the case where the first file corresponding to the virtual machine A is normal. Correspondingly, in the case where the first file is normal, each start of the virtual machine A and each backup in the running process can be performed on the basis of the first file. If the first file is abnormal, a new first file corresponding to the virtual machine A can be created to store the first bitmap data obtained from the host memory and the second bitmap data determined on the basis of the first bitmap data. Alternatively, if the first file is abnormal, the first file corresponding to the virtual machine A can be initialized to continue the data backup process of the virtual machine A on the basis of the initialized first file, and the first bitmap data and the second bitmap data determined on the basis of the first bitmap data of each data backup process of the virtual machine A can be continuously stored in the initialized first file.

[0095] In some examples, one virtual machine can correspond to one first file, or a plurality of virtual machines can correspond to one first file. In this case, the first bitmap data and the second bitmap data of the plurality of virtual machines can be stored in the first file.

[0096] The first file will be described below, and one virtual machine corresponding to one first file will be taken as an example for description.

[0097] It can be understood that the first file is used to assist the backup unit to backup the disk data of the virtual machine A in an incremental backup manner (for example, using the CBT technology), and 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 a raw format or a qcow2 format, or the format of the first file can also be another file format, and the embodiments of the present application do not limit the format of the first file.

[0098] In a possible implementation, as shown in FIG. 4, the first file can include three parts, which can also be referred to as three regions, wherein the first part is a metadata region, for example, the CBT Header Region shown in FIG. 4; the second part is a dynamic bitmap region, for example, the Dirty Bitmap Region shown in FIG. 4; and the third part is a static bitmap region, for example, the Static Bitmap Region shown in FIG. 4.

[0099] For example, as shown in FIG. 4, the metadata region includes a sub-region (for example, the Global Meta shown in FIG. 4) for storing file metadata of the first file, a sub-region (for example, the Dirty Bitmap Meta shown in FIG. 4) for storing metadata of the dynamic bitmap region, and a sub-region (for example, the Static Bitmap Meta shown in FIG. 4) for storing metadata of the static bitmap region. The size of the metadata region can be set according to requirements, for example, as shown in FIG. 4, the metadata region can be set to 2K (kilobyte), that is, the metadata region is located at a position with an offset of 0-2K in the first file.

[0100] For example, the metadata of the first file includes 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 the virtual disk A (block_size), and data integrity check code (checksum, which can be referred to as file checksum) corresponding to the first file, and the like. The file checksum can be generated and stored based on the updated content each time the first file is updated, and can be used to check the data integrity of the first file before the first file is updated next time.

[0101] The metadata of the dynamic bitmap area includes, for example, but is not limited to, at least one of the following information: a dynamic backup times value (ChgID1 shown in FIG. 5, which indicates the number of times that the dynamic bitmap area stores the first bitmap data, since the first bitmap data needs to be stored in the dynamic bitmap area once in each backup process, and accordingly, the value of ChgID1 is equivalent to the backup times corresponding to the latest backup of the virtual machine A), a 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 obtained from the host memory of the virtual machine A, and the third state invalid indicates that the first file is abnormal), and a data integrity check code corresponding to the dynamic bitmap area (hereinafter referred to as a first bitmap check code).

[0102] The first bitmap check code can be generated based on the stored first bitmap data j after the first bitmap data j obtained from the host memory in the jth backup process is stored in the dynamic bitmap area in each backup process (hereinafter, the jth backup process is taken as an example for description, and j is a positive integer). The first bitmap check code is used to perform data integrity check on the first bitmap data stored in the first file before the first bitmap data is loaded into the host memory of the virtual machine A after the virtual machine A is restarted.

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

[0104] The second bitmap check code can be generated and stored based on the stored second bitmap data j after the first bitmap data j is determined to determine the second bitmap data j in the jth backup process. The second bitmap check code can be used to perform data integrity check on the second bitmap data j stored in the static bitmap area before the second bitmap data j+1 determined based on the first bitmap data j+1 is stored in the static bitmap area in the j+1th backup process.

[0105] It can be understood that the first bitmap check code and the second bitmap check code described above can be MD5 values or check codes generated by using other check code algorithms (for example, hash algorithms).

[0106] In some possible examples, if the first bitmap data is stored in the first file during the backup process, the value of ChgID1 is not updated before the first computing device is abnormally powered off, and the value of ChgID1 in the first file is not equal to the backup time identifier corresponding to the latest data backup.

[0107] In some possible examples, the normality or abnormality of the first file can be determined in the following manner: for example, whether the first file is normal can be determined by comparing whether the dynamic backup time value and the static backup time value are the same; if the dynamic backup time value and the static backup time value are different, the first file is abnormal; if the dynamic backup time value and the static backup time value are the same, and the first bitmap data and the second bitmap data stored in the first file are verified by the first bitmap check code and the second bitmap check code respectively, it is determined that the first file is normal; if the dynamic backup time value and the static backup time value are the same, but the first bitmap data and / or the second bitmap data stored in the first file are verified by the first bitmap check code and / or the second bitmap check code respectively, it is determined that the first file is abnormal.

[0108] In some possible examples, in order to better ensure the data security of the virtual machine A, the dynamic bitmap area can include two sub-areas (region1 and region2), which are used to write the first bitmap data obtained from the host memory of the virtual machine A alternately. Correspondingly, the metadata of the dynamic bitmap area can further include information (current_db) indicating that the first bitmap data is written into region1 or region2. Correspondingly, the metadata of the static bitmap area can further include information (current_merge) indicating that the second bitmap data is updated based on the first bitmap data stored in region1 or region2 of the dynamic bitmap area. For example, when the first bitmap data is written into region1, if region1 has stored bitmap data, the first bitmap data can be written into region1 to overwrite the bitmap data stored in region1. If current_db indicates that the first bitmap data is written into region1, current_merge indicates that the second bitmap data is determined based on the first bitmap data stored in region1.

[0109] Since the first file is stored in the non-volatile memory, the first bitmap data stored in the dynamic bitmap region in the first file will not be lost due to power-off of the first computing device or shutdown of the virtual machine A, and accordingly, the dynamic bitmap region can be used for persistent storage of the first bitmap data obtained from the memory of the host computer where the virtual machine A is located.

[0110] The size of the dynamic bitmap region can be set according to requirements (e.g., the number of data blocks in the virtual disk A) so that complete storage of the first bitmap data can be achieved. For example, each sub-region (region 1 and region 2) in the dynamic bitmap region can be set to 4M (megabytes), as shown in FIG. 4, and the dynamic bitmap region is located at the position with an offset of 2K-8M+2K in the first file. The size of each bit corresponding to each data block in the virtual disk A in the first bitmap data can be set to 1 bit.

[0111] Since the first file is stored in the non-volatile memory, the second bitmap data stored in the static bitmap region in the first file will not be lost due to power-off of the first computing device or shutdown of the virtual machine A, and accordingly, the static bitmap region can achieve persistent storage of the second bitmap data, i.e., persistent storage of data in which data blocks in the virtual disk A are stored in each backup process. The size of the static bitmap region is generated according to the size of the virtual disk A, as shown in FIG. 4, and the static bitmap region can be located at the position with an offset of 8M+2K in the first file.

[0112] In some possible exemplary embodiments, the second bitmap data includes bits corresponding to each data block in the virtual disk A, and the second bitmap data can achieve storage of the correspondence between the backup number identifier of each backup process and the backup data (i.e., data blocks in the virtual disk A to which the backup data belongs) that needs to be stored in each backup process. For example, in the jth backup process, the first bitmap data j indicates that the bit corresponding to data block 1 in the virtual disk A is a specified value (e.g., 1), i.e., the first bitmap data indicates that the data in data block 1 is data changed with respect to the original disk data of data block 1 in the 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 (i.e., j) of the jth backup process. For example, the value of each bit in the second bitmap data can be set to 4 bytes, i.e., the size of each bit corresponding to each data block in the second bitmap data can be set to 4 bytes.

[0113] When j is 1, the original disk data of data block 1 can be the data stored in data block 1 when the virtual machine A is started (for example, data block 1 can not store data when the virtual machine A is started); when j is not 1, the original disk data of data block 1 can be the data stored in data block 1 in the (j-1)th backup process.

[0114] For example, 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 one data block in the virtual disk A, for example, S3 is set to 2M (Mega), and a represents the size of the bit corresponding to one data block in the second bitmap data stored in the set static bitmap area, for example, a can be set to 4 bytes.

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

[0116] It can be understood that each data backup process of the virtual machine A is similar, and the following will take any one data backup process (for example, the jth backup process) as an example to describe each data backup process of the virtual machine A.

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

[0118] In some possible examples, when the backup unit determines that the virtual machine A needs to perform data backup, the backup unit can send a call request for calling a specified interface of the virtualization platform to the virtualization platform, and correspondingly, the virtualization platform determines that the 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 the virtual disk A (i.e., the current disk data of the virtual machine A) from the host memory (i.e., the memory of the first computing device) of the virtual machine A and feed back to the backup unit, and correspondingly, the backup unit obtains the first bitmap data j corresponding to the current disk data of the 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.

[0119] Exemplarily, the specified interface is an interface reserved by the virtualization platform and invocable to obtain the first bitmap data corresponding to the current disk data of the virtual disk A from the host memory of the virtual machine A.

[0120] In some possible examples, the foregoing manner of determining that the virtual machine A needs to perform data backup can include at least one of the following manners: receiving a data backup instruction triggered by a user for the virtual machine A; or detecting that a time corresponding to a preset backup period for the virtual machine A arrives; or detecting a shutdown event of the virtual machine A.

[0121] Exemplarily, the backup period can be set as one week, and data backup is performed when XX time of each day in a backup period arrives. Correspondingly, the foregoing detection that the time corresponding to the preset backup period for the virtual machine A arrives can mean that data backup is determined to be needed for the virtual machine A each time XX time of each day in a backup period arrives.

[0122] Exemplarily, the backup period can also be set as one month, and data backup is performed when YY time of each day in a backup period arrives. Exemplarily, the backup period can also be set as one day, and data backup is performed when a time corresponding to an interval of aa time length starts from zz time in a backup period. It should be noted that the length of a backup period and the interval time length for performing data backup in a backup period can be set according to requirements.

[0123] It can be understood that in a backup period, the first backup in the backup period can be full data backup of the virtual disk A of the virtual machine A, that is, backup of data in all data blocks of the virtual disk A; and the non-first backup in the backup period can be incremental data backup of the virtual disk A of the virtual machine A, that is, backup of data changed with respect to previous backup (that is, disk data at the time of previous backup) in the virtual disk A.

[0124] In some possible examples, the dynamic bitmap area of the first file can include a first region and a second region (region1 or region2 of the dynamic bitmap area as described above), which are respectively used to alternately store the first bitmap data obtained from the host memory of the virtual machine A. For example, the foregoing process of storing the first bitmap data j to the dynamic bitmap area of the first file can include storing the first bitmap data j corresponding to the jth backup process in region1, and the second bitmap data j-1 corresponding to the (j-1)th backup process can be stored in region2 at this time.

[0125] In some embodiments, the process of storing the first bitmap data j corresponding to the jth backup process in the region 1 can include: the backup unit can store the first bitmap data j in the region 1 of the dynamic bitmap area in the first file based on the metadata current_db of the dynamic bitmap area stored in the metadata area, where the current_db is information indicating that the first bitmap data is written in the region 1 or the region 2 of the dynamic bitmap area, and at this time, the current_db indicates that the first bitmap data j is written in the region 1.

[0126] In another possible embodiment, after the process of storing the first bitmap data j in the dynamic bitmap area of the first file, the backup unit can also increase the dynamic backup times value (i.e. ChgID1 shown in FIG. 5) in the metadata of the dynamic bitmap area by 1, so that the value of the ChgID1 after the increase is equal to the backup times corresponding to the current backup, i.e. j.

[0127] In another possible embodiment, after the process of storing the first bitmap data j in the dynamic bitmap area of the first file, the backup unit can also increase the dynamic backup times value (i.e. ChgID1 shown in FIG. 5) in the metadata of the dynamic bitmap area by 1, so that the value of the ChgID1 after the increase is equal to the backup times corresponding to the current backup, i.e. j.

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

[0129] 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 (e.g. since the (j-1)th backup). For example, the value of the bit corresponding to the data block is a specified value (e.g. 1), indicating that the data in the data block has changed since the previous backup (e.g. since the (j-1)th backup); the value of the bit corresponding to the data block is a non-specified value (e.g. 0), indicating that the data in the data block has not changed since the previous backup (e.g. since the (j-1)th backup). Correspondingly, the original disk data of the 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 virtual machine A can be the disk data in the virtual disk A when the virtual machine A is started (i.e. data that has not been backed up).

[0130] Correspondingly, based on the value of the bit corresponding to each data block in the virtual disk A in the first bitmap data, the current disk data of the virtual disk A can be determined, and the data change of the current disk data relative to the original disk data of the virtual disk can be determined.

[0131] Then, in step S330, the 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 the virtual machine A relative to the original disk data of the virtual machine A and the first backup number.

[0132] The first backup number indicates the backup number corresponding to the current backup of the virtual machine A. For example, if the current backup is the jth backup of the disk data of the virtual machine A, the first backup number can be j. Correspondingly, the current disk data of the virtual machine A is the disk data in the virtual disk A of the virtual machine A at the jth backup; and the original disk data of the virtual machine A is the disk data in the virtual disk A of the virtual machine A at the (j-1)th backup.

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

[0134] In this step, the first bitmap data indicates the data change of the current disk data of the virtual machine A relative to the original disk data of the virtual machine A. For example, 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 (e.g., the (j-1)th backup); and 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.

[0135] In some specific examples, the first bitmap data described above includes bits set to a specified value (hereinafter referred to as specified bits), and the specified value is used to indicate the data changed from the original disk data of the virtual machine A to the current disk data of the virtual machine A. Correspondingly, in the case where the current backup is an incremental data backup, in step S330, the process of determining the second bitmap data based on the first bitmap data can specifically include: replacing the specified value of the specified bits in the first bitmap data with the first backup number to obtain the second bitmap data. In this way, the correspondence between the data (i.e., the first backup data) to be backed up in the jth backup process and the backup number identifier of the jth backup process is stored. Thus, when performing disaster recovery backup of the disk data of the virtual machine A later, it is more convenient to search for the data backed up in each backup process.

[0136] In some possible examples, the foregoing process of determining the second bitmap data can include: increasing the value of the static backup times value ChgID2 stored in the sub-region of the metadata of the static bitmap region (i.e., at the Static Bitmap Meta structure shown in FIG. 4) by one, so that the value of the ChgID2 after the increase is equivalent to the first backup times corresponding to the current backup, i.e., j; and then replacing the specified value of the specified bit in the first bitmap data with the first backup times j, i.e., replacing the value of the ChgID2 after the increase, to obtain the second bitmap data. Correspondingly, the second bitmap data is used to indicate the data change of the current disk data of the virtual machine A relative to the previous backup of the virtual machine A and the first backup times.

[0137] After the backup unit determines the second bitmap data j, the backup unit stores the second bitmap data j in the first file. Specifically, the second bitmap data j can be stored in the static bitmap region of the first file. In some embodiments, after the backup unit stores the second bitmap data j in the first file, the backup unit can further generate a third bitmap check code based on the stored second bitmap data in the static bitmap region, and store the third bitmap check code to the Static Bitmap Meta structure shown in FIG. 4; and store the value of the ChgID2 after the increase to the Static Bitmap Meta structure.

[0138] For the sake of clarity, the following describes, by means of a specific example, the specific update process of the first file, i.e., the process of storing the first bitmap data in the host memory of the virtual machine A to the first file, and the process of storing the second bitmap data to the first file.

[0139] As shown in FIG. 5, it is assumed that the virtual disk A of the virtual machine A includes four data blocks, wherein the data block 1 writes the data "a", the data block 2 writes the data "b", and the data block 3 and the data block 4 do not write data. Correspondingly, the first bitmap data 1 (i.e., the bitmap table) stored in the host memory of the virtual machine A is as shown in FIG. 5, the values of the bits corresponding to the data block 1 and the data block 2 are 1, and the values of the bits corresponding to the data block 3 and the data block 4 are 0.

[0140] As shown in FIG. 5, in the first backup, i.e., the first data backup of the virtual machine A, the first command is called to write the first bitmap data 1 obtained from the host memory of the virtual machine A to the dynamic bitmap region (for example, the region 1 of the dynamic bitmap region) of the first file through the write function.

[0141] Then, the value of the dynamic backup times value CHgID1 stored in the sub-area of the metadata of the dynamic bitmap area (i.e. Dirty Bitmap Meta as shown in FIG. 4) is updated (assuming that the first backup is started, at this time, the initial value of CHgID1 is set to 0, and the initial value of the static backup times value CHgID2 is 0); specifically, the value of CHgID1 stored in the Dirty Bitmap Meta structure shown in FIG. 4 is read, which is added by 1 to obtain the updated value of CHgID1, and 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.

[0142] Subsequently, based on the first bitmap data 1 written in the dynamic bitmap area, the second bitmap data is determined; wherein the process can include: reading the value of CHgID2 stored in the sub-area of the metadata of the static bitmap area, i.e. the Static Bitmap Meta structure shown in FIG. 4, adding 1 to obtain the updated value of CHgID2, which is 1; calling the second command to modify the value of the bit with value 1 in the first bitmap data 1 to the updated value of CHgID2 (i.e. 1) (i.e. the first backup times 1) through the write function to obtain the second bitmap data 1, as shown in FIG. 5. Then the second bitmap data 1 is stored in the static bitmap area. At this time, it 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.

[0143] Through the above process, for the first backup, the first bitmap data 1 in the host memory of the virtual machine A is persisted to the first file, and the second bitmap data indicating the current disk data of the virtual disk A is stored in the static bitmap area of the first file, wherein the second bitmap data indicates the data change of the original disk data of the virtual disk A (specifically, data block 1 writes data "a", data block 2 writes data "b", i.e. the data in data blocks 1 and 2 is changed, and the data in data blocks 2 and 4 is not changed), and the first backup times 1.

[0144] As shown in FIG. 5, after the first backup is completed and before the second backup, the virtual machine A writes data "c" to data block 3 of the virtual disk A, accordingly, at this time, as shown in FIG. 5, the value of the bit corresponding to data block 3 in the first bitmap data 2 of the host memory of the virtual machine A is 1, at this time, the data in other data blocks of the virtual disk A does not change relative to the first backup, accordingly, the value of the bit corresponding to other data blocks in the first bitmap data 1 is 0.

[0145] In the first backup process, after the first bitmap data 1 obtained from the host memory of the 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 the virtual machine A is initialized.

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

[0147] Then, the value of CHgID1 stored in the sub-area of the metadata of the dynamic bitmap area (i.e., Dirty Bitmap Meta shown in FIG. 4) is updated (1 at this time); specifically, the value of CHgID1 stored in the Dirty Bitmap Meta structure shown in FIG. 4 is read, increased by 1, and 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 2.

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

[0149] At this time, the second bitmap data is stored in the static bitmap area for the second time, and the second bitmap data 2 is stored in the static bitmap area, which can be updating the value of the bit with the updated value of CHgID2 (i.e., the first backup times 2) in the second bitmap data 2 to the second bitmap data already stored in the static bitmap area. At this time, in the second bitmap data stored in the static bitmap area, the values of the bits corresponding to data blocks 1 and 2 are 1 (i.e., indicating that the data in data blocks 1 and 2 is 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 is 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 been changed).

[0150] As shown in FIG. 5, after the second backup is completed and before the third backup, the virtual machine A writes data into the data block 2 of the virtual disk A, at this time the data block 2 stores data "bb", and correspondingly, as shown in FIG. 5, the value of the bit corresponding to the data block 2 in the first bitmap data 3 of the host memory of the virtual machine A is 1, and the other data blocks of the virtual disk A have no data change relative to the second backup, and correspondingly, the value of the bit corresponding to the other data blocks in the first bitmap data 1 is 0.

[0151] In the process of the second backup, after the first bitmap data 2 obtained from the host memory of the 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 the virtual machine A is initialized.

[0152] In the third backup, that is, the third data backup of the virtual machine A, a preset first command is called to write the first bitmap data 3 obtained from the host memory of the virtual machine A into the dynamic bitmap area of the first file (at this time, the region 1 of the dynamic bitmap area is written in a polling manner).

[0153] The value of CHgID1 stored in the sub-region of the metadata of the dynamic bitmap area (that is, the Dirty Bitmap Meta shown in FIG. 4) is updated (at this time, the value is 2); specifically, the value of CHgID1 stored in the Dirty Bitmap Meta structure shown in FIG. 4 is read, the value is added by 1 to obtain the updated value of CHgID1, and 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 3.

[0154] Subsequently, the first bitmap data 3 written in the dynamic bitmap area is used to determine the second bitmap data 3; wherein the process includes: reading the value of CHgID2 stored in the sub-region of the metadata of the static bitmap area, that is, the Static Bitmap Meta structure shown in FIG. 4, adding 1 to the value to obtain the updated value of CHgID2, which is 3; a preset second command is called to modify the value of the bit corresponding to the set 1 bit in the first bitmap data 3 to the updated value of CHgID2 (that is, 3) (that is, the first backup number is 3) 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. 5.

[0155] At this time, it is the third time to store the second bitmap data in the static bitmap area, and the process of storing the second bitmap data 3 in the static bitmap area can refer to the process of storing the second bitmap data 2 in the static bitmap area described above, which will not be repeated here.

[0156] Then, for each backup, the first file is updated by the above manner, that is, the first bitmap data in the host memory of the 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.

[0157] Persisting the second bitmap data in the first file can facilitate the tracing of all changed data in the virtual disk A since the backup and thereafter, for example, based on the second bitmap data stored in the static bitmap area after the completion of the second backup, all changed data since the first backup and thereafter (i.e., including the changed data of the first backup, i.e., the data in the data blocks 1 and 2, and the changed data of the second backup, i.e., the data in the data block 3) can be determined; for another example, based on the second bitmap data stored in the static bitmap area after the completion of the third backup, all changed data since the second backup and thereafter (i.e., including the changed data of the second backup, i.e., the data in the data block 3, and the changed data of the third backup, i.e., the data in the data block 2) can be determined, thereby providing better convenience for the implementation of subsequent disaster recovery backup.

[0158] After the backup unit stores the second bitmap data in the first file, the backup unit stores, in step S340, first backup data, which is data changed from the original disk data of the virtual machine A to the current disk data of the virtual machine A.

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

[0160] In some possible examples, step S340 can include the following step: storing the first backup data in a specified storage area of the host of the virtual machine A.

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

[0162] In yet some possible examples, step S340 can include the following steps: storing the first backup data in a specified storage area of the host of the virtual machine A; and storing the first backup data stored in the specified storage area to a backup pool corresponding to the virtual machine A.

[0163] It can be understood that when storing the first backup data, the first backup times can be used as the data identifier of the first backup data to realize the correspondence between the backup indicated by the first backup times and the data (i.e., the first backup data) backed up thereby. Alternatively, the first backup data and the first backup times can be stored correspondingly, for example, in the backup pool corresponding to the first backup data, the correspondence between the data identifier (or storage address) of the first backup data and the first backup data identifier is stored.

[0164] In the above process, the first file stored in the non-volatile memory is additionally added, and when the disk data of the virtual machine is backed up, the first bitmap data corresponding to the current disk data of the virtual machine is stored in the first file to realize persistent storage of the first bitmap data indicating the data change of the current disk data relative to the original disk data of the virtual machine. Then, based on the first bitmap data, the second bitmap data indicating the data change of the current disk data relative to the original disk data and the first backup times 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 times. Correspondingly, after multiple backup processes, the second bitmap data stored in the first file can persistently indicate which data blocks in the disk store the backup data at each backup. This provides a basis for realizing disaster recovery backup in subsequent backup processes. For example, if it is determined that the backup data stored in a previous backup process is damaged in a certain backup process, the backup data stored in the disk in each backup (i.e., one backup times identifier corresponds to one backup) can be combined with the backup data indicated by 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 realize disaster recovery backup without the need for full backup again, thereby reducing storage resources and time consumption in the data backup process and improving the disaster recovery capability of the backup data.

[0165] In the above example, the second bitmap data stored in the first file can indicate the backup times identifier of each backup process and the data change of the disk data of the virtual machine A relative to the disk data of the virtual machine A at the previous backup (or the disk data of the virtual machine A at startup) at each backup. When the virtual machine A abnormally shuts down, thereby causing the disk data of the virtual machine A not to be backed up, the state of the virtual machine A at the last data backup before the abnormal shutdown can still be reproduced based on the second bitmap data and the backup data stored in each backup, thereby reducing the amount of data loss of the virtual machine A caused by abnormal shutdown.

[0166] The abnormal shutdown can refer to a shutdown event that is not triggered, thereby causing a shutdown without backing up the disk data of the virtual machine A. The abnormal shutdown can include, for example, a power failure of a host of the virtual machine A, a crash of the virtual machine A, and the like.

[0167] In some possible examples, considering that there can be a need for the user to continue to write data to the virtual disk A of the virtual machine A during the data backup (i.e., between determining to perform the data backup and completing the storage of the data to be backed up this time), in order to ensure the accuracy of the data backup result (the data to be backed up is the data to be backed up at the time of performing the data backup) and the normal writing of data to the virtual disk A during the backup process, the user experience is improved. In each backup process, before step S320, the method further includes step 11:

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

[0169] In some possible examples, when determining that the virtual machine A needs to perform data backup, the backup unit sends a calling request for calling a specified interface of the virtualization platform to the virtualization platform. After the virtualization platform determines that the virtual machine A needs to perform data backup, the virtualization platform can create a snapshot based on the current disk data of the virtual machine A. Accordingly, the backup unit creates a snapshot based on the current disk data of the virtual machine A through the virtualization platform. Then, step S320 is performed.

[0170] The snapshot can include data stored in each data block in the virtual disk A. The snapshot is used to continue to write data in response to a request for writing data to the virtual disk A during the jth backup process (i.e., during the jth data backup).

[0171] Then, after step S340, the method further includes step 12: merging the snapshot with the current disk data of the virtual machine A.

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

[0173] In yet some possible examples, in case there is no need to write data to the virtual disk A during the backup process, at this time the data stored in the snapshot is the same as the current disk data of the virtual machine A (the disk data at the time of generating the snapshot), the merging of the aforementioned snapshot and the current disk data of the virtual machine A can refer to keeping the current disk data of the virtual disk A.

[0174] In some possible examples, the backup unit can periodically perform incremental backup on the disk data in the disk data A of the virtual machine A. Wherein, the periodically performing incremental backup on the disk data in the disk data A of the virtual machine A can be: in a backup period, performing full data backup on the disk data in the disk data A of the virtual machine A in the first backup in the backup period; performing incremental data backup on the disk data in the disk data A of the virtual machine A in the non-first backup in the backup period.

[0175] In this example, if the backup unit determines that the current backup needs to perform incremental data backup, it can only store the first backup data in the aforementioned step S340. If the backup unit determines that the current backup needs to perform full data backup, it stores the first backup data and the fourth backup data in the aforementioned step S340, the fourth backup data is the data unchanged from the original disk data of the virtual machine A to the current disk data of the virtual machine A, that is, if the backup unit determines that the current backup needs to perform full data backup, it needs to store all data of the current disk data of the virtual machine A.

[0176] In some possible examples, the first backup time can indicate whether the current backup is the first backup or the non-first backup in a backup period, accordingly, the first computing device can determine whether the current backup needs to perform incremental data backup or full data backup according to the first backup time.

[0177] In yet some possible examples, in a backup period, there is data backup performed in response to a user triggered data backup instruction and / or there is data backup performed in response to a detected shutdown event of the virtual machine A, in order to accurately determine whether the current backup needs to perform incremental data backup or full data backup, the first computing device can determine whether the current backup needs to perform incremental data backup or full data backup according to the time corresponding to the current backup.

[0178] For example, if the backup period is set to one week, and data backup is performed at XX o'clock every day, if the time indication corresponding to the current backup is XX o'clock on Sunday, it is determined that the current backup needs to be full data backup, and accordingly, all disk data of the virtual disk A of the virtual machine A needs to be stored; if the time indication corresponding to the current backup is XX o'clock on Monday to Saturday (or other time indications on Monday to Saturday), it is determined that the current backup needs to be incremental data backup, and accordingly, only the changed data of the current disk data of the virtual machine A relative to the disk data since the previous backup of the virtual machine A needs to be stored.

[0179] It can be understood that, in the case of determining that the current backup needs to be full data backup, the foregoing 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 change of the current disk data of the virtual machine A relative to the original disk data of the virtual machine A (specifically, all data is changed) and the first backup number.

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

[0181] It is considered that, during the running of the virtual machine A, the bitmap data is stored in the host memory of the virtual machine A, so as to track the data change (i.e., the modification of the disk data) of each data block in the virtual disk A in real time. However, after the virtual machine A is shut down, the bitmap data in the host memory of the virtual machine A is lost. Accordingly, after the virtual machine A is restarted, if there is a first file corresponding to the virtual machine A, the first bitmap data corresponding to the backup process before the virtual machine A is shut down and currently stored in the dynamic bitmap area of the first file needs to be reloaded into the host memory of the virtual machine A, so as to continue to track the modification of the disk data of the virtual machine A.

[0182] In order to ensure the data integrity and security of the virtual machine A, before the first bitmap data corresponding to the latest backup process before the virtual machine A is shut down and currently stored in the dynamic bitmap area is loaded into the host memory of the virtual machine A, data integrity check needs to be performed on the first bitmap data corresponding to the latest backup process before the virtual machine A is shut down and currently stored in the dynamic bitmap area.

[0183] For example, before the data backup, i.e. before step S320 (or step 11), the process of restarting the virtual machine A is further included, and then the loading request of loading the first bitmap data in the first file to the host memory of the virtual machine A is triggered after the virtual machine A is restarted. The metadata area of the first file further stores a first bitmap check code corresponding to the dynamic bitmap area, and the first bitmap check code is generated based on the first bitmap data corresponding to the previous backup process. When the current backup is the jth backup, the previous backup process is the (j-1)th backup, and the first bitmap data corresponding to the previous backup process is the first bitmap data corresponding to the disk data of the virtual machine A obtained in the (j-1)th backup process. The first bitmap data corresponding to the previous backup process (the (j-1)th backup) is the first bitmap data corresponding to the latest backup process before the 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 can be a hash value generated based on the stored first bitmap data. Hereinafter, the case that the check code corresponding to the dynamic bitmap area is an MD5 value generated based on the stored first bitmap data is taken as an example for description.

[0184] Correspondingly, before step 320, the method can further include steps 21-24.

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

[0186] In some examples, the previous backup process (i.e. the (j-1)th backup) can be triggered by detecting the shutdown event of the virtual machine A, and correspondingly, after storing the backup data corresponding to the previous backup process, the virtual machine A is shut down in response to the shutdown event. In yet other examples, the previous backup process can also be triggered by detecting the arrival of the time corresponding to the backup period or in response to the data backup instruction triggered by the user, and then the virtual machine A is abnormally shut down, so that the new data backup process is not triggered when the virtual machine A is shut down. Correspondingly, when the virtual machine A is abnormally shut down, the dynamic bitmap area of the first file stores the first bitmap data corresponding to the (j-1)th backup, and the static bitmap area stores the second bitmap data determined based on the first bitmap data corresponding to the (j-1)th backup.

[0187] After the virtual machine A is restarted, a loading request is triggered to load the first bitmap data in the first file to the host memory of the virtual machine A. In order to ensure the data integrity of the first bitmap data loaded by the virtual machine A, the first computing device (the backup unit) generates a second bitmap check code based on the first bitmap data (i.e. the latest stored first bitmap data) corresponding to the previous backup process currently stored in the dynamic bitmap area of the first file after detecting the loading request of the virtual machine A. For example, the first computing device calculates the MD5 value of the first bitmap data corresponding to the previous backup process currently stored in the dynamic bitmap area of the first file as the second bitmap check code.

[0188] 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 is used to generate the second bitmap check code based on the first bitmap data stored in region 1.

[0189] 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.

[0190] 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 to the host memory.

[0191] 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 is not modified. Accordingly, the first bitmap data is sent to the virtual machine A so that the virtual machine A loads the first bitmap data to the host memory.

[0192] In step 24, if it is determined that the first bitmap check code is different from 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 is modified, and it is determined that 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 create new first bitmap data for the virtual machine A in the host memory of the virtual machine A through the virtualization platform deployed by the first computing device. For example, the first computing device can also send prompt information to prompt the user of the virtual machine A that the first bitmap data stored in the dynamic bitmap area of the first file is unavailable.

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

[0194] In some possible examples, the second bitmap data stored in the static bitmap area of the first file can indicate the backup times corresponding to each backup process and the data backed up by each backup process, to help trace a backup process and the data backed up after the backup process. To ensure the safety of the data of the virtual machine A, the metadata area further stores a third bitmap check code, which is generated based on the second bitmap data corresponding to the previous backup process and currently stored in the static bitmap area. Accordingly, after determining that the first bitmap check code is the same as the second bitmap check code, the data integrity of the second bitmap data corresponding to the previous backup process and currently stored in the static bitmap area needs to be checked. Specifically, a fourth bitmap check code is generated based on the second bitmap data corresponding to the previous backup process and currently stored in the static bitmap area. The third bitmap check code and the fourth bitmap check code are compared. If the third bitmap check code is the same as the fourth bitmap check code, it is determined that the second bitmap data corresponding to the previous backup process and currently stored in the static bitmap area is not modified, and the first bitmap data corresponding to the previous backup process is sent to the virtual machine A, so that the virtual machine A loads the first bitmap data into the host memory. If the third bitmap check code is not the same as the fourth bitmap check code, it is determined that the second bitmap data corresponding to the previous backup process and currently stored in the static bitmap area is modified and cannot be used. Accordingly, the first file cannot be used, and a prompt information can be output to prompt the user of the virtual machine A that the first file of the virtual machine A is incorrect.

[0195] In some possible examples, after storing the second bitmap data corresponding to the current backup (i.e., the jth backup) in the first file in step S330, the bitmap data in the host memory of the 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 a non-specified value (for example, 0), to identify that the data of each data block in the virtual disk A has not changed, so as to better and more accurately indicate the data change in the next backup (j+1th backup).

[0196] Accordingly, in some examples, after step 12, steps 13-14 can be further included, that is, determining the data changed with respect to the current disk data of the virtual machine A (i.e., the disk data of the virtual machine A when the snapshot is generated in the jth backup) in the snapshot as target data; and updating the initialized bitmap data in the host memory based on the target data.

[0197] In this example, the target data of the disk data of the virtual machine A changed at the time when the snapshot is generated in the jth backup of the snapshot relative to the virtual machine A is determined, and based on the target data, the data block to which the target data belongs is determined as the changed block, and then the value of the bit corresponding to each changed block in the initialized bitmap data in the host memory is modified to the specified value to indicate the data change in each changed block, so as to realize the tracking record of the data change of the data block (in which the data is changed) in the virtual disk A in the jth backup process.

[0198] The data backup process provided by one specific embodiment of the present application is introduced below. In the data backup process, the first computing device performs incremental backup on the data of the virtual machine A based on the first file created for the virtual machine A.

[0199] For example, as shown in FIG. 6, in step S610, the first computing device can detect whether the virtual machine A needs to be backed up. In step S620, when it is determined that the virtual machine A needs to be backed up, the snapshot function is started, and the COW (Copy-on-write) technology of the snapshot function is used to create a snapshot based on the current disk data of the virtual machine A. In step S630, the first bitmap data A corresponding to the current disk data of the virtual machine A is obtained from the host memory of the virtual machine A. 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 the region 1 of the dynamic bitmap area, and the first bitmap data A is stored in the region 2 of the dynamic bitmap area at this time).

[0200] Then, 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 the 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 is changed. In step S670, the first computing device adds 1 to the ChgID2 corresponding to the static bitmap area stored in the metadata area. In step S680, the value of the bit with the specified value in the first bitmap data is replaced with the ChgID2 after adding 1, to obtain the second bitmap data, and the ChgID2 after adding 1 is equivalent to the first backup number of this backup. In S690, the second bitmap data is stored in the static bitmap area of the first file.

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

[0202] Then, the first computing device, before storing the first backup data, or at the same time as storing the first backup data, or after storing the first backup data (and before merging the snapshot obtained in step S620 into the virtual disk A), as shown in FIG. 6, can further include step S6110. In step S6110, if a write request indicating writing data into the 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, the virtual disk A is set to a read-only state to keep the virtual disk A in the state at the time when it is determined that the data backup of the virtual machine A is needed, and the data of the write request determined to be needed after the data backup of the virtual machine A is avoided from being written into the virtual disk A, so that the first backup data of the determined backup is not the data at the time when it is determined that the data backup of the virtual machine A is needed, so that the state of the virtual machine A at the time when it is determined that the data backup of the virtual machine A is needed cannot be restored subsequently.

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

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

[0205] In still some possible examples, as shown in FIG. 6, 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, the first bitmap data A in the host memory of the virtual machine can be initialized in step S6130, that is, the value of the bit with the specified value in the first bitmap data A is set to a non-specified value to indicate that the data of each data block in the virtual disk A has not changed.

[0206] After the aforementioned snapshot and the current disk data of the virtual machine A are merged in step S6120, and after the first bitmap data A in the host memory of the virtual machine is initialized in step S6130, the initialized first bitmap data in the host memory can be used to continue tracking the data change of the data block. For example, the value of the bit corresponding to the data block of the data involved in the corresponding write request written in step S6110 in the initialized first bitmap data is modified to the specified value to realize the record of the data change of the snapshot with respect to the aforementioned current disk data, which is equivalent to the record of the incremental data in the virtual disk A during the backup process, and the initialized first bitmap data is used to continue tracking the data change in the virtual disk A subsequently.

[0207] It can be understood that FIG. 6 is only a flow diagram illustrating the data backup process, and does not constitute a limitation on the execution order of each step, for example, step S6130 can also be executed before step S6100 or step S640; step S6110 can also be executed before step S630, and the like.

[0208] The subsequent first computing device continues to detect whether data backup is needed for virtual machine A, and continues to execute the data backup process provided in the present application upon determining that data backup is needed for virtual machine A.

[0209] Based on the above method embodiment, for example, FIG. 7 shows a flow diagram of another data backup method provided in an embodiment of the present application. The method can be applied to the aforementioned first computing device, which is deployed with the aforementioned backup unit to provide data backup service for one or more virtual machines, for example, the one or more virtual machines can be constructed and managed through a virtualization platform. In some possible examples, the first computing device can also be deployed with the virtualization platform to realize the management of the one or more virtual machines and the provision of data backup service in combination with the virtualization platform and the backup unit. In yet some possible examples, the virtualization platform can also be deployed in a non-first computing device, and accordingly, the first computing device can realize the management of the one or more virtual machines and the provision of data backup service in combination with the device deploying the virtualization platform.

[0210] Each virtual machine corresponds to a virtual disk, and each virtual disk can be divided into one or more data blocks for storing data of the corresponding virtual machine. In one possible example, each data block of a single virtual disk can be obtained by uniformly or non-uniformly dividing the storage space according to the size of the storage space.

[0211] The data backup process is described below by taking any virtual machine A in the one or more virtual machines as an example. For the data backup process corresponding to other virtual machines, refer to the data backup process corresponding to virtual machine A. In an embodiment of the present application, the first computing device adopts an incremental backup manner to backup disk data (hereinafter can be referred to as disk data of virtual machine A) in virtual disk A of virtual machine A. The data backup process is described below by taking the backup unit, the virtualization platform, and virtual machine A all running in the first computing device as an example.

[0212] After determining that data backup is needed each time, the method can include the following steps S710-S780, as shown in FIG. 7.

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

[0214] At step S720, first bitmap data corresponding to the current disk data of the virtual machine A is acquired, and the first bitmap data is stored in a first file, the first file being stored in the nonvolatile memory, the first bitmap data being used to indicate the data change of the current disk data of the virtual machine A relative to the original disk data of the virtual machine A.

[0215] At step S730, 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 being used to indicate the data change of the current disk data of the virtual machine A relative to the original disk data of the virtual machine A and the first backup times.

[0216] The implementation principle of step S710 is the same as that of the aforementioned step 11, and the implementation process can be referred to the implementation process of step 11; the implementation principle of steps S720-S730 is the same as that of steps S320-S330 shown in FIG. 3, and the implementation process can be referred to the implementation process of steps S320-S330, which will not be described herein.

[0217] At step S740, if it is determined that the incremental data backup needs to be performed for the current backup, integrity check is performed on each second backup data backed up before the current backup.

[0218] The manner of determining whether the incremental data backup or the full data backup needs to be performed for the current backup can be referred to the manner described in the foregoing embodiments, which will not be described herein.

[0219] In the present step, in the case that it is determined that the current backup is not the first backup, that is, the incremental data backup needs to be performed for the current backup, it is considered that the data backed up in the current backup is the incremental data corresponding to the previous backup, if the data backed up in the current backup needs to be used to restore the state of the virtual machine A at the time of the current backup in the future, it needs to rely on each data (i.e., each second backup data) backed up before the current backup, if one or more second backup data appears abnormal (e.g., damaged or lost), the abnormal second backup data and the second backup data after the abnormal second backup data cannot be used (i.e., the state of the virtual machine A at the corresponding backup time cannot be restored). Therefore, in order to ensure the effectiveness of the current backup, the integrity of each second backup data backed up before the current backup needs to be checked.

[0220] In some examples, the integrity of each second backup data can be checked in turn according to the front-back order of the corresponding backup process between the second backup data, and in the case that the integrity check of a certain second backup data fails, the second backup data after the second backup data whose integrity check fails can be stopped from being checked, so as to reduce the number of checks and reduce the check consumption.

[0221] In some examples, in the case that the first computing device through its backup unit can perform periodic incremental backup for the virtual machine A, the second backup data before the present backup can be: each backup data backed up before the present backup in the period (hereinafter referred to as the current backup period) of the present backup.

[0222] In some possible examples, in step S740, can specifically include steps 31-33:

[0223] In step 31, the first data check code corresponding to each second backup data is obtained, wherein the first data check 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.

[0224] For example, the first data check code corresponding to each second backup data can correspond to the storage of each second backup data in the backup pool. Correspondingly, the first computing device through its backup unit can obtain the first data check code corresponding to each second backup data from the backup pool.

[0225] Then, in step 32, each second check code is generated based on the currently stored each second backup data. In this step, each second backup data can be stored in the backup pool, and the first computing device can obtain the currently stored each second backup data from the backup pool and generate each second check code based on the currently stored each second backup data.

[0226] For example, in the case that the first data check code corresponding to each second backup data is the MD5 value generated based on each second backup data, the generation of each second check code based on the currently stored each second backup data is the MD5 value generated based on the currently stored each second backup data. If the first data check code corresponding to the second backup data is the hash value generated based on each second backup data by using a specified hash algorithm, the generation of each second check code based on the currently stored each second backup data is the hash value generated based on the currently stored each second backup data by using the specified hash algorithm.

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

[0228] In this step, the first computing device compares the first data check code and the second data check code corresponding to each second backup data to determine whether the first data check code and the second data check code corresponding to each second backup data are the same. If the comparison result indicates that the first data check code and the second data check code corresponding to each second backup data are the same, it can be determined that each second backup data is normal (i.e., not damaged and not lost), and the first computing device can continue to perform incremental data backup with respect to each second backup data previously backed up, and then continue to perform the subsequent step S750.

[0229] In some possible examples, considering that the entire loss of one or more second backup data in each backup before this backup can also occur, the first computing device can obtain the backup time identifiers corresponding to each second backup data before obtaining the first data check code corresponding to each second backup data. Based on the backup time identifiers corresponding to each second backup data and the first backup time of this backup, it is determined whether there is lost second backup data. If it is determined that there is no lost second backup data, the preceding step S740 is executed. 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, the disaster recovery backup process can be entered. The disaster recovery backup process is introduced later.

[0230] For example, if the backup time identifiers corresponding to each second backup data and the first backup time of this backup are continuous in value, and the number of existing second backup data meets the expectation (for example, the number of second backup data can be counted according to the number of backups performed in the (current backup period), and the number of second backup data is equal to the count), it can be determined that there is no lost second backup data. If the number of existing second backup data does not meet the expectation, or the backup time identifiers corresponding to each second backup data and the first backup time of this backup are not continuous in value, it is determined that there is lost second backup data.

[0231] In step S750, if it is determined that the integrity check of each second backup data is passed, the first backup data is stored. Then step S760 is performed, in which the snapshot and the current disk data of the virtual machine A are merged.

[0232] In step S770, if it is determined that full data backup is required for this backup, the first backup data and the fourth backup data are stored, wherein the fourth backup data is the current disk data of the virtual machine A that has not changed with respect to the original disk data of the virtual machine A (i.e., the data at the time of the previous backup of this backup), that is, the current disk data of the virtual machine A is stored. Then the preceding step S760 is performed.

[0233] In the above examples, in a case where it is determined that the current backup needs to be incremental data backup, the second backup data backed up before the current backup (in the current backup period) is checked for integrity, and after the check passes, the incremental data backup is continued to ensure the availability of the incremental data chain formed (in the current backup period) and the data security of the virtual machine A. In a case where it is determined that the current backup needs to be full data backup, it is determined that the current backup enters a new backup period and is the first backup of the new backup period, and accordingly, the data in each data block of the virtual disk A (i.e., the current disk data) can be directly stored to perform full data backup of the virtual machine A and ensure the data security of the virtual machine A.

[0234] In some possible examples, as shown in FIG. 7, in a case where the comparison result obtained in step S740 indicates that the integrity check of the third backup data in the second backup data fails (for example, the first data check code and the second data check code corresponding to the third backup data in the second backup data are different), the backup process proceeds to step S780, that is, the disaster recovery backup process is performed. Specifically, as shown in FIG. 7:

[0235] In step S780, in a case where the integrity check of the third backup data in the second backup data fails, the second backup number corresponding to the third backup data is determined.

[0236] In this step, in a case where the comparison result indicates that the integrity check of the third backup data in the 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, and accordingly, the third backup data and each second backup data backed up after the third backup data cannot be used. At this time, the virtual machine A needs to be backed up for disaster recovery.

[0237] Specifically, the first computing device determines the second backup number corresponding to the third backup data (which can be determined based on the data identifier of the third backup data or based on the 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, the disaster recovery backup data of the virtual machine A is determined, which includes the data in the current disk data of the virtual machine A indicated by the second backup number, the first backup number, and the backup number identifier therebetween.

[0238] In this step, the first computing device determines the second backup times, the first backup times and the data blocks corresponding to the backup times identifiers therebetween from the virtual disk A of the virtual machine A based on the second backup times and the values of the bits corresponding to the data blocks in the virtual disk A in the second bitmap data (i.e. the backup times identifiers).

[0239] In step S7100, the disaster recovery backup data is stored, and the disaster recovery backup data is identified by the second backup times, the first backup times and the backup times identifiers therebetween. Then step S760 is performed.

[0240] In some possible examples, the first computing device can continue to store the disaster recovery backup data based on each second backup data before the third backup data (in the current backup period). The disaster recovery backup data can be identified by the second backup times, the first backup times and the backup times identifiers therebetween, which includes the data of all data blocks that have changed relative to the disk data at the previous backup of the backup corresponding to the third backup data. In this way, the re-incremental backup of the damaged third backup data and the data after the third backup data is implemented, which better reduces the backup resource consumption and improves the backup speed.

[0241] In some examples, the identification of the disaster recovery backup data by the second backup times, the first backup times and the backup times identifiers therebetween can include: taking the second backup times, the first backup times and the backup times identifiers therebetween as the data identifier of the disaster recovery backup data, so as to indicate that the disaster recovery backup data includes the data that has changed since the previous backup of the backup corresponding to the second backup times; or can include: storing the second backup times, the first backup times and the backup times identifiers therebetween and the disaster recovery backup data correspondingly, for example, storing the correspondence between the data identifier (or storage address) of the disaster recovery backup data and the second backup times, the first backup times and the backup times identifiers therebetween in the backup pool corresponding to the disaster recovery backup data.

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

[0243] The disaster recovery backup process of the disk data of the virtual machine A is described below through a specific example.

[0244] Suppose a backup cycle is set as one week, and XX time point of each day is set to perform data backup on virtual machine A.

[0245] Suppose the first backup on virtual machine A is performed on Sunday, and XX time point of Sunday arrives, the first computing device determines to perform the first backup on virtual machine A, and stores the data in all data blocks in virtual disk A to obtain full backup data-0 as shown in FIG. 8; first, the full backup data-0 is stored in the local host of virtual machine A, then the full backup data-0 is backed up to the backup environment (i.e. backup pool), and the correspondence between the full backup data-0 and the backup frequency identifier (i.e. 1) is stored in the backup environment (or the backup frequency identifier 1 can be used as the data identifier (i.e. name) of the full backup data-0), to form an incremental data chain 1. Subsequently, the full backup data-0 in the non-backup environment (such as existing in the production environment shown in FIG. 8, for example, the local host of virtual machine A) can also be deleted to save the storage resources of the local host.

[0246] XX time point of Monday arrives, the first computing device determines to perform the second backup on virtual machine A, and needs to perform incremental data backup on virtual machine A, and the incremental backup data-1 as shown in FIG. 8 is determined from virtual disk A; first, the incremental backup data-1 is stored in the local host of virtual machine A, and then, after verifying that the full backup data-0 is not damaged, the incremental backup data-1 is backed up to the backup environment, and the correspondence between the incremental backup data-1 and the backup frequency identifier (i.e. 2) is stored in the backup environment (or the backup frequency identifier 2 can be used as the data identifier (i.e. name) of the incremental backup data-1). Subsequently, the incremental backup data-1 in the non-backup environment (such as existing in the production environment shown in FIG. 8, for example, the local host of virtual machine A) can also be deleted to save the storage resources of the local host.

[0247] XX time point of Monday arrives, the first computing device determines to perform the second backup on virtual machine A, and needs to perform incremental data backup on virtual machine A, and the incremental backup data-1 as shown in FIG. 8 is determined from virtual disk A; first, the incremental backup data-1 is stored in the local host of virtual machine A, and then, after verifying that the full backup data-0 is not damaged, the incremental backup data-1 is backed up to the backup environment, and the correspondence between the incremental backup data-1 and the backup frequency identifier (i.e. 2) is stored in the backup environment (or the backup frequency identifier 2 can be used as the data identifier (i.e. name) of the incremental backup data-1). Subsequently, the incremental backup data-1 in the non-backup environment (such as existing in the production environment shown in FIG. 8, for example, the local host of virtual machine A) can also be deleted to save the storage resources of the local host.

[0248] When XX time point of Thursday arrives, the first computing device determines to perform the fifth data backup on virtual machine A, and needs to perform incremental data backup on 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 local host memory of virtual machine A, and the first bitmap data 5 indicates the data change of each data block in the virtual disk relative to the fourth backup.

[0249] 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 incremented ChgID1, and stores the incremented ChgID1 in the metadata area. At this time, ChgID1 = 5. Then, the first computing device generates a first bitmap check code based on the first bitmap data 5 stored in the dynamic bitmap area, and stores the first bitmap check code in the metadata area.

[0250] Subsequently, the first computing device adds 1 to ChgID2 to obtain the incremented ChgID2. At this time, ChgID2 = 5. The value of the incremented ChgID2 is equal to the backup times identifier 5 (i.e., the fifth backup). Then, the first computing device replaces the value of the bit with the specified value (e.g., 1) in the first bitmap data 5 with the incremented ChgID2 (i.e., 5) to obtain second bitmap data 5. 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.

[0251] Then, the first computing device can call a preset third command to determine the bit (and the corresponding data block) with the value ChgID2 = 5 based on the second bitmap data 5, and call a preset fourth command based on the data block corresponding to the bit with the value ChgID2 = 5 to obtain the incremental backup data-4 shown in FIG. 8 from the virtual disk A, which is first stored in the host computer locally.

[0252] Then, the check code 01 corresponding to the full backup data-0, the check code 11 corresponding to the incremental backup data-1, the check code 21 corresponding to the incremental backup data-2, and the check code 31 corresponding to the incremental backup data-3 (data of the backup on Wednesday) are obtained in sequence. The check code 02, the check code 12, the check code 22, and the check code 32 are generated based on the full backup data-0, the incremental backup data-1, the incremental backup data-2, and the incremental backup data-3 currently stored in the backup environment, respectively. The check code 01 is compared with the check code 02, the check code 11 is compared with the check code 12, the check code 21 is compared with the check code 22, and the check code 31 is compared with the check code 32.

[0253] If the check code 01 and the check code 02 are the same, the check code 11 and the check code 12 are the same, the check code 21 and the check code 22 are the same, but the check code 31 and the check code 32 are different, it is determined that the incremental backup data-3 is damaged; at this time, it is determined that the data of the virtual machine A needs to be disaster recovery backed up, specifically, it is determined that the backup times identifier 4 corresponding to the incremental backup data-3, that is, the ChgID2 (that is, 4) after adding one, based on the backup times identifier 4 corresponding to the incremental backup data-3, the third command is called, based on the second bitmap data 5 stored in the first file, the bit (and the corresponding data block) whose value is greater than or equal to 4 is determined, the fourth preset command is called, based on the data in the data block corresponding to the bit whose value is greater than or equal to 4 in the virtual disk A, the incremental backup data-5 as shown in FIG. 8 is obtained. At this time, the incremental backup data-5 includes the incremental backup data-3 and the incremental backup data-4.

[0254] The incremental backup data-5 is backed up to the backup environment (that is, the backup pool), and in the backup environment, the corresponding relationship between the incremental backup data-5 and 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 taken as the name of the incremental backup data-5). Subsequently, the corresponding check code 51 can also be generated based on the stored incremental backup data-5, and the check code 51 is stored corresponding to the incremental backup data-5, so as to check the data integrity of the incremental backup data-5 when the next backup is performed.

[0255] Specifically, as shown in FIG. 8, the first computing device can copy the full backup data-0, the incremental backup data-1 and the incremental backup data-2 in the backup data chain 1 as shown in FIG. 8 in the backup environment, and group the copied full backup data-0, incremental backup data-1 and incremental backup data-2 with the incremental backup data-5 to form a new incremental data chain 2, that is, a disaster recovery backed incremental data chain 2. Subsequently, all data in the backup data chain 1 is deleted.

[0256] Subsequently, on Friday and Saturday of this week (that is, within the backup period), until the XX time of next Sunday arrives, the first computing device can continue to perform incremental data backup on the virtual machine A based on the incremental data chain 2. To reduce backup resource consumption and improve backup speed.

[0257] Based on the method in the above embodiment, the embodiment of the present application provides a data backup device. Please refer to FIG. 9, which is a structural schematic diagram of a data backup device provided by the embodiment of the present application.

[0258] As shown in FIG. 9, the data backup apparatus 900 can comprise: a first obtaining module 910, configured to obtain first bitmap data corresponding to 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 data change of the current disk data of the virtual machine relative to original disk data of the virtual machine; a first determining module 920, 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 data change of the current disk data of the virtual machine relative to the original disk data of the virtual machine and a first backup times; and a first storing module 930, configured to store first backup data, the first backup data being data changed by the current disk data of the virtual machine relative to the original disk data of the virtual machine.

[0259] In some possible examples, the apparatus further comprises:

[0260] a first creating module (not shown in the figure), configured to create a snapshot based on the current disk data of the virtual machine before the first bitmap data corresponding to the current disk data of the virtual machine is obtained.

[0261] The apparatus further comprises:

[0262] a merging module (not shown in the figure), configured to merge the snapshot with the current disk data of the virtual machine after the first backup data is stored.

[0263] In some possible examples, the apparatus further comprises:

[0264] a second creating module (not shown in the figure), configured to create a first file corresponding to the virtual machine before the first bitmap data corresponding to the current disk data of the virtual machine is obtained, wherein the first file comprises 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.

[0265] In some possible examples, the dynamic bitmap area comprises a first area and a second area, and the first area and the second area are used to alternately store the first bitmap data corresponding to each backup process.

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

[0267] The method further comprises: generating, by a first generation module (not shown in the figure), a second bitmap check code based on the first bitmap data corresponding to the previous backup process and currently stored in the dynamic bitmap area after detecting a loading request of the virtual machine to load the first bitmap data into the host memory of the virtual machine, wherein the loading request is sent after the virtual machine is restarted;

[0268] comparing, by a first comparison module (not shown in the figure), the first bitmap check code with the second bitmap check code;

[0269] loading, by a first loading module (not shown in the figure), the first bitmap data corresponding to the previous backup process and currently stored in the dynamic bitmap area to the host memory of the virtual machine if the first bitmap check code is the same as the second bitmap check code.

[0270] In some possible examples, the method further comprises:

[0271] initializing, by an initialization module (not shown in the figure), the bitmap data in the host memory of the virtual machine after storing the second bitmap data in the first file.

[0272] In some possible examples, the first storage module 930 comprises: a check unit (not shown in the figure) configured to perform integrity check on each second backup data backed up before the present backup; and a first storage unit (not shown in the figure) configured to store the first backup data if the integrity check on each second backup data passes.

[0273] In some possible examples, the check unit is specifically configured to obtain a first data check code corresponding to each second backup data, wherein the first data check 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.

[0274] generate a second data check code based on each currently stored second backup data respectively;

[0275] compare, for each second backup data, the first data check code corresponding to the second backup data with the second data check code, wherein if the comparison result indicates that the first data check code corresponding to each second backup data is the same as the second data check code, it is determined that the integrity check on each second backup data passes.

[0276] In some possible examples, the apparatus further comprises:

[0277] The second determining module (not shown in the figure) is configured to determine a second backup time corresponding to third backup data in the second backup data if the third backup data fails in the integrity check.

[0278] The third determining module (not shown in the figure) is configured to determine disaster recovery backup data of the virtual machine based on the second backup time and the second bitmap data, wherein the disaster recovery backup data comprises data indicated by the second backup time, the first backup time and backup time identifiers therebetween in the current disk data of the virtual machine.

[0279] 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 by at least the first backup time.

[0280] In some possible examples, the first bitmap data comprises a specified bit set to a specified value, and the specified value is used to indicate data changed in the current disk data of the virtual machine relative to the original disk data of the virtual machine.

[0281] 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 time to obtain the second bitmap data.

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

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

[0284] It should be understood that the above apparatus is used to execute the method in the above embodiments, and the corresponding program modules in the apparatus have similar implementation principles and technical effects to those described in the above method, and the working process of the apparatus can refer to the corresponding process in the above method, which will not be described here.

[0285] Based on the methods in the above embodiments, as shown in FIG10, this application provides a computing device 1000. The computing device may include: a first memory and a second memory, the first memory being used to store a program, and the second memory being a non-volatile memory used to store a first file; at least one processor being 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 methods in the above embodiments.

[0286] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0287] Based on the methods in the above embodiments, this application provides a computer program product, characterized in that, when the computer program product is run on a processor, the processor executes the methods in the above embodiments.

[0288] It is understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In addition, in some possible implementations, each step in the above embodiments may be selectively executed according to the actual situation, and may be partially or fully executed, which is not limited here.

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

[0290] The method steps in the embodiments of the present application can be implemented by hardware, or by a combination of software and hardware executed by a processor. The software instructions can be composed of a corresponding software module, which can be stored in a random access memory (RAM), a flash memory, a read-only memory (ROM), a programmable read-only memory (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), a register, a hard disk, a mobile hard disk, a CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, so that the processor can read information from the storage medium and 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.

[0291] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments can be implemented 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, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted by 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 by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)), etc.

[0292] It can be understood that the various numerical numbers involved in the embodiments of the present application are only for the convenience of differentiation, and are not used to limit the scope of the embodiments of the present application.

Claims

1. A data backup method characterized by, The method comprises: acquiring first bitmap data corresponding to current disk data of a virtual machine, and storing 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 data change of the current disk data of the virtual machine relative to original disk data of the virtual machine; 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 data change of the current disk data of the virtual machine relative to the original disk data of the virtual machine and a first backup times; storing first backup data, the first backup data being data changed by the current disk data of the virtual machine relative to the original disk data of the virtual machine.

2. The method of claim 1, wherein, Before the acquiring of the first bitmap data corresponding to the current disk data of the virtual machine, the method further comprises: creating a snapshot based on the current disk data of the virtual machine; after the storing of the first backup data, the method further comprises: merging the snapshot with the current disk data of the virtual machine.

3. The method of claim 1 or 2, wherein, The method further comprises: creating a first file corresponding to the virtual machine, wherein the first file comprises a metadata area, a dynamic bitmap area and a static bitmap area, the metadata area being used to store metadata of the first file, the dynamic bitmap area being used to store the first bitmap data, and the static bitmap area being used to store the second bitmap data.

4. The method of claim 3, wherein, The dynamic bitmap area comprises a first area and a second area, and the first area and the second area are used to alternately store the first bitmap data corresponding to each backup process.

5. The method of claim 3 or 4, wherein, The metadata area further stores a first bitmap check code, and the first bitmap check code is generated based on the first bitmap data corresponding to a previous backup process. Before the acquiring of the first bitmap data corresponding to the current disk data of the virtual machine, the method further comprises: after detecting a loading request of the virtual machine to load the first bitmap data into a host memory of the virtual machine, generating a second bitmap check code based on the first bitmap data corresponding to a previous backup process and currently stored in the dynamic bitmap area, the loading 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, loading the first bitmap data currently stored in the dynamic bitmap area into the host memory.

6. The method of claim 1, wherein, After the storing of the second bitmap data in the first file, the method further comprises: initializing bitmap data in the host memory of the virtual machine.

7. The method according to any one of claims 1 to 6, wherein The first bitmap data comprises a specified bit set to a specified value, and the specified value is used to indicate data changed by the current disk data of the virtual machine relative to the original disk data of the virtual machine; The determining of the second bitmap data based on the first bitmap data comprises: replacing the specified value of the specified bit in the first bitmap data with the first backup times to obtain the second bitmap data.

8. The method according to any one of claims 1 to 7, wherein, The storing of the first backup data comprises: storing the first backup data in a specified storage area of a host 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 a host computer 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.

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

10. A computing device, comprising: The method comprises: a first memory for storing a program; a second memory for storing a first file, the second memory being a non-volatile memory; 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 configured to perform the method according to any one of claims 1-9.

Images