A data backup method and computing device

Abstract

The embodiment of the application provides a data backup method and a computing device, and relates to the technical field of virtual machines. The method comprises the following steps: acquiring first bitmap data corresponding to current disk data, storing the first bitmap data in a first file, the first file being stored in a nonvolatile memory, and the first bitmap data being used for indicating data change of the current disk data relative to original disk data of a virtual machine; determining second bitmap data based on the first bitmap data, storing the second bitmap data in the first file, and the second bitmap data being used for indicating data change of the current disk data relative to the original disk data and a first backup number; and storing data changed by the current disk data relative to the original disk data, so as to realize a new backup mode of disk data of the virtual machine, to prepare for not re-performing full backup in the case that backup data is abnormal, and to provide a basis for reducing storage resources and time consumption.

Description

Technical Field

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

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

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

[0004] Currently, in the process of backing up virtual machine disk data, incremental backup is generally used to reduce backup resource consumption and speed up the backup process. This involves backing up the virtual machine's disk data (i.e., the data in the virtual disk of the virtual machine). For example, CBT (Changed Block Tracking) technology can be used to determine the data on the virtual machine's disk that has changed since the last backup (hereinafter referred to as incremental data), and then back up the determined incremental data to achieve incremental backup of the virtual machine's disk data.

[0005] However, during incremental backup, within a backup cycle, the backup data chain formed during that backup cycle consists of data that has changed since the first backup (which is a full backup) and subsequent incremental backups. If a backup data in the backup data chain is corrupted (or lost), then the corrupted (or lost) backup data and all subsequent backup data in that backup data chain become unusable. Consequently, incremental backups cannot continue to be performed relative to the backup data in that backup data chain.

[0006] In related technologies, after the aforementioned problems occur, the incremental backup process for that backup cycle is generally stopped, and a new incremental backup process begins. Specifically, a full backup of the virtual machine's disk data is performed again, resulting in new full backup data. Then, based on this new full backup data, each subsequent backup within a backup cycle only backs up the virtual machine's disk data that has changed compared to the previous backup, i.e., it backs up incremental backup data. This process, to some extent, increases the storage resources and time consumption for data backup.

[0007] Therefore, how to provide a new data backup method to help solve the above problems has become an urgent issue. Summary of the Invention

[0008] This application provides a data backup method, apparatus, computing device, computer storage medium, and computer program product to achieve a new method for backing up virtual machine disk data that reduces storage resources and time consumption.

[0009] In a first aspect, embodiments of this application provide a data backup method, the method comprising:

[0010] The first bitmap data corresponding to the current disk data of the virtual machine is obtained, and the first bitmap data is stored in a first file. The first file is stored in non-volatile memory. 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.

[0011] Based on the first bitmap data, second bitmap data is determined and stored in the first file. The second bitmap data is used to indicate the data changes of the virtual machine's current disk data relative to the virtual machine's original disk data and the first backup count.

[0012] Store first backup data, which is the data showing changes in the virtual machine's current disk data relative to the virtual machine's original disk data.

[0013] In the above process, a first file stored in non-volatile memory is added. When backing up the virtual machine's disk data, the first bitmap data corresponding to the current disk data of the virtual machine is stored in the first file to achieve persistent storage of the first bitmap data that indicates the data changes of the current disk data relative to the original disk data of the virtual machine. Then, based on the first bitmap data, second bitmap data indicating the data changes of the current disk data relative to the original disk data and the first backup count is determined and stored in the first file. The first backup data is also stored there. 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 count. Correspondingly, after multiple backup processes, the second bitmap data stored in the first file can persistently indicate which data blocks on the disk were stored for backup data in each backup. This provides a foundation for disaster recovery backup in subsequent backup processes. For example, during a backup process, if it is determined that the backup data stored in a previous backup process is corrupted, the backup data in which data blocks on the disk were stored during each backup (i.e., a backup corresponding to a backup count) can be combined with the data indicated by the second bitmap to more easily locate the corrupted backup data and subsequent backup data. Then, the corrupted backup data and subsequent backup data can be backed up again to achieve disaster recovery backup without having to perform a full backup again. This provides a basis for reducing storage resources and time consumption during data backup and improves the disaster recovery capability of backup data.

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

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

[0016] In some possible examples, before obtaining the first bitmap data corresponding to the current disk data of the virtual machine, 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 the metadata of the first file, the dynamic bitmap area is used to store the first bitmap data, and the static bitmap area is used to store the second bitmap data.

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

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

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

[0020] In the example above, after detecting a loading request sent after a virtual machine restart to load the first bitmap data into its host memory, the first bitmap checksum generated and stored when storing the first bitmap data corresponding to the previous backup process in the first file is used to verify the first bitmap data corresponding to the previous backup process stored in the dynamic bitmap area when the loading request is obtained. That is, the first bitmap checksum is compared with the second bitmap checksum. If the first bitmap checksum and the second bitmap checksum are the same, it is determined that the first bitmap data stored in the first file has not been modified. That is, the first bitmap data corresponding to the previous backup process currently stored in the first file is accurate and consistent with the first bitmap data corresponding to the previous backup process stored in the first file. At this time, the first bitmap data corresponding to the previous backup process currently stored in the dynamic bitmap area is loaded into the host memory to ensure the accuracy of the loaded first bitmap data and to effectively detect whether the first bitmap data loaded from the first file into the host memory is consistent.

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

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

[0023] In some possible examples, storing the first backup data includes: performing integrity checks on each of the second backup data previously backed up; if the integrity checks on each of the second backup data all pass, storing the first backup data.

[0024] In the example above, after storing the first backup data, the integrity of each of the previously backed-up second backup data is checked. If the integrity checks of each second backup data pass, it can be concluded that the data previously backed up by the first backup data (i.e., this backup) has not been corrupted. In this case, the first backup data can continue to be stored to ensure the effective storage of the backup data and the availability of the backup data chain composed of each second backup data and the first backup data. This is to avoid the situation where any second backup data is corrupted, and even if the first backup data continues to be stored, it cannot be used (to restore the corresponding state of the virtual machine), resulting in a waste of storage resources and storage time.

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

[0026] In the above example, by comparing the first data check code and the second data check code corresponding to each second backup data, it is determined whether each second backup data has been 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 this backup time is consistent with the second backup data itself when it was backed up, and it has not been damaged or modified, thereby realizing the integrity verification of each second backup data.

[0027] In some possible examples, the method further includes: if the integrity verification of the third backup data in each of the second backup data fails, determining the second backup count corresponding to the third backup data; determining the disaster recovery backup data of the virtual machine based on the second backup count and the second bitmap data, wherein the disaster recovery backup data includes the second backup count, the first backup count, and the data indicated by the backup count identifier between them; storing the disaster recovery backup data, and identifying the disaster recovery backup data using the second backup count, the first backup count, and the backup count identifier between them.

[0028] In the example above, if the integrity verification of the third backup data fails, it can be determined that the third backup data is corrupted (e.g., modified). If the backup process uses incremental backup, the third backup data and all subsequent second backup data cannot be used (to restore the corresponding state of the virtual machine). In other words, the disaster recovery backup data is directly determined and stored, which is to execute the disaster recovery backup process, avoiding the need to perform a full backup again and reducing the storage resources and time consumption of the backup process.

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

[0030] In the example above, the value of a specified bit in the first bitmap data that indicates the changes in the current disk data relative to the original disk data is replaced with the first backup count to obtain the second bitmap data. This second bitmap data can indicate the changes in the current disk data relative to the original disk data (i.e., the data that needs to be backed up) and the first backup count (i.e., the backup), as well as the correspondence between them.

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

[0032] The above example provides storage methods for storing the first backup data: storing it on the host machine, storing it in the backup pool, or storing it on the host machine first and then in the backup pool, so as to realize multiple backup storage methods for the data.

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

[0034] Secondly, embodiments of this application provide a data backup device, the device comprising:

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

[0036] The first determining module is 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 is used to indicate the changes in the current disk data of the virtual machine relative to the original disk data of the virtual machine and the number of first backups.

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

[0038] Thirdly, embodiments of this application provide a computing device, including: a first memory for storing a program; a second memory for storing a first file, the second memory being a non-volatile memory; and at least one processor for executing the program stored in the first memory; wherein, when the program stored in the first memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0039] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to perform the method described in the first aspect or any possible implementation thereof.

[0040] Fifthly, embodiments of this application provide a computer program product, characterized in that, when the computer program product is run on a processor, it causes the processor to execute the method described in the first aspect or any possible implementation of the first aspect.

[0041] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0043] Figure 2 This is a schematic diagram of a data backup application scenario provided in an embodiment of this application;

[0044] Figure 3 This is a flowchart illustrating a data backup method provided in an embodiment of this application;

[0045] Figure 4 This is a schematic diagram of the structure of the first document provided in an embodiment of this application;

[0046] Figure 5 This is a schematic diagram of the second bitmap data update process in the first file provided in the embodiments of this application;

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

[0048] Figure 7 This is a flowchart illustrating yet another data backup method in the embodiments of this application;

[0049] Figure 8 This is a schematic diagram of a disaster recovery backup scenario in the embodiments of this application;

[0050] Figure 9 This is a schematic diagram of the structure of a data backup device according to a specific embodiment of this application;

[0051] Figure 10 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0052] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

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

[0054] In the description herein, it should be understood that the terms “center,” “longitudinal,” “lateral,” “length,” “width,” “thickness,” “upper,” “lower,” “front,” “rear,” “left,” “right,” “vertical,” “horizontal,” “top,” “bottom,” “inner,” “outer,” and “circumferential” indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation.

[0055] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0056] To facilitate understanding of the technical solutions of the embodiments of this application, the terms used herein are explained below.

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

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

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

[0060] QEMU can also manage virtual machines, tracking virtual disk I / O (Input / Output) in real time. Upon receiving a disk I / O write request from a virtual machine, it writes the data carried in the request into one or more data blocks of the virtual disk. Based on CBT (Changed Block Tracking) technology, it supports incremental backups of virtual machines. Specifically, it creates bitmap data (i.e., a bitmap table) in the host memory of the virtual machine and updates this bitmap data according to the ID (Identity Document) of the data blocks (i.e., changed blocks) whose data was previously written. This bitmap data includes bits corresponding to the IDs of each data block in the virtual disk to indicate whether the data stored in the data block has changed. A specified value (e.g., 1) for the bit corresponding to the ID of a data block indicates that the data in that data block has changed compared to the previous backup; a non-specified value (e.g., 0) indicates that the data in that data block has not changed compared to the previous backup. When performing a backup, you can back up only the modified data blocks (i.e., the data blocks marked "1" in the bitmap data) instead of performing a full backup of the entire virtual disk (i.e., all data blocks).

[0061] Incremental backup is a data backup method where, after a full backup, subsequent backups only back up the data that has been added to or modified since the first full backup. This means the first incremental backup covers the data that has been added to or modified since the full backup (i.e., data in the changed data blocks, also known as incremental data); the second incremental backup covers the data that has been added to or modified since the first incremental backup, and so on, until the next full backup, constituting one backup cycle.

[0062] like Figure 1The diagram illustrates an exemplary scenario of incremental backup. At time T1, a full backup of the data on the disk is performed, resulting in full backup data #1. At time T2, an incremental backup of the data on the disk is performed, resulting in incremental backup data *1, which represents the changes made to the full backup data #1 at time T1. At time T3, an incremental backup of the data on the disk is performed, resulting in incremental backup data *2, which represents the changes made to the data on the disk at time T1. This process continues until, at time Tn, incremental backup data *Tn-1 is obtained.

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

[0064] A snapshot is a technique for recording the state of all data within a virtual disk. It saves the complete state of the disk at a specific point in time, allowing the data to be restored to that state (e.g., restoring the virtual machine to its state at that moment). A snapshot can also be understood as a fully usable copy of a specified set of data (e.g., a virtual disk), including an image of the corresponding data at a specific point in time (the point at which the copy began). A snapshot can be a copy of the data it represents, or a replica of the data.

[0065] As mentioned earlier, during incremental backup, within a backup cycle, each incremental backup in the backup data chain formed by that backup cycle represents data that has changed since the previous backup. If a backup data in the backup data chain is corrupted (or lost), then the corrupted (or lost) backup data and all subsequent backup data in that backup data chain become unusable. Consequently, incremental backups cannot continue to be performed relative to the backup data in that backup data chain.

[0066] Currently, when the above problems occur, the general procedure is to stop the incremental backup process for that backup cycle and start a new incremental backup cycle. Specifically, a full backup is performed on the virtual machine's virtual disk to obtain new full backup data. Then, based on this new full backup data, each backup only backs up the data on the virtual machine's virtual disk that has changed compared to the previous backup, i.e., incremental backup data. This process increases the storage resources and time consumption for data backup to some extent.

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

[0068] Based on the above backup process, data backup of the virtual machine's disk data is achieved to protect the virtual machine's data security. The second bitmap data persistently indicates that the first backup data is the data stored in the backup process corresponding to the first backup count. During multiple backup processes, the second bitmap data stored in the first file persistently indicates which data blocks in the virtual disk of the virtual machine were stored during each backup, thus providing a foundation for disaster recovery backups in subsequent data backup processes. For example, during a backup process, if it is determined that the backup data stored in a previous backup process is corrupted, the disk data in the virtual disk of the virtual machine stored during each backup (i.e., a backup corresponding to a backup count) indicated by the second bitmap data stored in the first file can be used to more easily locate the corrupted backup data and subsequent backup data. This allows for a re-backup of the corrupted backup data and subsequent backup data, achieving disaster recovery backup without needing to perform a full backup again. The above process provides a foundation for reducing storage resource and time consumption during backups and enhances the disaster recovery capability of backup data.

[0069] To facilitate understanding of the technical solutions of the embodiments of this application, the data backup process of the embodiments of this application will be described below.

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

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

[0072] Subsequently, upon determining that data backup of VM1 is necessary, the backup unit creates a snapshot based on the virtual machine's current disk data using the virtualization platform. It then retrieves the bitmap data corresponding to VM1's current disk data from the computing device's memory via the virtualization platform; this bitmap data is called the first bitmap data. The backup unit stores the first bitmap data in a first file, which is stored in the aforementioned non-volatile memory. The first bitmap data indicates the changes in VM1's current disk data relative to its original disk data. Next, based on the first bitmap data, the backup unit determines the second bitmap data and stores it in the first file. The second bitmap data indicates the changes in VM1's current disk data relative to its original disk data and the first backup count. Finally, the backup unit stores the first backup data, which represents the changes in VM1's current disk data relative to its original disk data.

[0073] During backup, the virtualization platform may receive a new disk I / O write request from VM1. In order to avoid data loss during the backup process, the virtualization platform will write the data carried by the disk I / O write request from VM1 received during the backup process into the snapshot created by the backup process. After storing the first backup data, the snapshot with the new disk data will be merged with the aforementioned current disk data of VM1.

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

[0075] Following the example above, 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 further determines the data in the snapshot that has changed relative to the aforementioned current disk data of VM1 as the target data; and, based on the target data, updates the initialized bitmap data in the memory of the computing device.

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

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

[0078] In some possible examples, the backup unit may exist as a plugin of the virtualization platform, and correspondingly, the backup unit can be considered as a functional unit of the virtualization platform.

[0079] It is understood that the structure of the data backup system in the above examples is merely illustrative and does not constitute a limitation on the structure of the data backup system. In other examples, the data backup system may include multiple computing devices and multiple backup pools, wherein the virtualization platform, backup units, and virtual machines described above may be deployed on different computing devices, and each backup pool may consist of one or more storage devices (or computing devices that can provide storage space). And so on.

[0080] Next, based on the above examples, the data backup method provided in the embodiments of this application will be introduced.

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

[0082] In some possible examples, the first computing device may also be deployed with a virtualization platform to jointly manage one or more virtual machines and provide data backup services with the virtualization platform and backup unit. In still other possible examples, the virtualization platform may be deployed in a device other than the first computing device, and correspondingly, the first computing device may jointly manage one or more virtual machines and provide data backup services with the device deploying the virtualization platform.

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

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

[0085] The following description uses any virtual machine A among one or more virtual machines as an example to illustrate the data backup process. For the data backup process of other virtual machines, please refer to the data backup process corresponding to virtual machine A. In this embodiment, the first computing device backs up the disk data (hereinafter referred to as the disk data of virtual machine A) in virtual disk A of virtual machine A by running a backup unit and a virtualization platform using an incremental backup method. The following description uses the example where the backup unit, virtualization platform, and virtual machine A all run on the first computing device to illustrate the data backup process.

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

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

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

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

[0090] The bitmap data corresponding to virtual machine A may include bits that correspond to data blocks in virtual disk A, with each bit storing a value indicating changes in the data within its corresponding data block. For example, setting the bit corresponding to the i-th data block in the bitmap data to a specified value (e.g., 1) indicates that the data in the i-th data block of virtual disk A has changed; setting the bit corresponding to the i-th data block to a non-specified value (e.g., 0) indicates that the data in the i-th data block of virtual disk A has not changed.

[0091] Wherein, if the disk data in virtual disk A has not been backed up, the "change" (or "no change") in the aforementioned indication of data change in the i-th data block of virtual disk A may refer to the data in the i-th data block of virtual disk A when virtual machine A starts; where the disk data A has been backed up, the "change" (or "no change") in the aforementioned indication of data change in the i-th data block of virtual disk A may refer to the data in the i-th data block when the data storage of the previous backup process for virtual disk A is completed.

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

[0093] Understandably, if the first file corresponding to virtual machine A does not encounter any errors, the step of creating the first file can be performed once. Correspondingly, if the first file does not encounter any errors, each startup of virtual machine A and each backup during its operation can be based on this first file. If the first file encounters an error, a new first file corresponding to virtual machine A can be recreated to store the first bitmap data obtained from the host machine's memory and the second bitmap data determined based on the first bitmap data. Alternatively, if the first file encounters an error, the first file corresponding to virtual machine A can be initialized, allowing the data backup process of virtual machine A to continue following the data backup process of virtual machine A based on the initialized first file. The initialized first file will continue to store the first bitmap data of each data backup process of virtual machine A and the second bitmap data determined based on the first bitmap data.

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

[0095] The first file will be introduced below, with one first file corresponding to one virtual machine as an example.

[0096] Understandably, this first file is used to assist the backup unit in backing up the disk data of virtual machine A using an incremental backup method (e.g., CBT technology). In some possible examples, the first file may also be referred to as a CBT file. In some examples, the format of the first file may be raw or qcow2, or it may be other file formats. This application does not limit the format of the first file.

[0097] In one possible implementation, such as Figure 4 As shown, the first file can include three parts, or three areas. The first part is the metadata area, such as... Figure 4 The CBT Header Region is shown; the second part is the dynamic bitmap area, as shown. Figure 4The Dirty Bitmap Region shown above has a third part that is a static bitmap region, such as... Figure 4 The Static Bitmap Region shown.

[0098] For example, such as Figure 4 As shown, the metadata area includes a sub-area for storing the file metadata of the first file (such as...). Figure 4 The Graph Meta shown above is a sub-region used to store metadata for the dynamic bitmap region (such as...). Figure 4 The DirtyBitmap Meta shown) and the sub-area used to store metadata for the static bitmap area (such as Figure 4 The image shows a Static BitmapMeta. The size of the metadata area can be set according to requirements, for example... Figure 4 The value can be set to 2K (kilobytes), meaning the metadata area is located at an offset of 0 to 2K in the first file.

[0099] For example, the metadata of the first file may include, but is not limited to, at least one of the following: file format (file magic), file version, size of the corresponding virtual disk A (img_size), file creation time (create_time), size of each data block in virtual disk A (block_size), and data integrity checksum (which can be called file checksum) corresponding to the first file, etc. This file checksum may be generated and stored based on the updated content after each update of the first file, and can be used to verify the data integrity of the first file before the next update.

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

[0101] The first bitmap checksum can be generated based on the first bitmap data j retrieved from the host machine's memory during each backup process (the j-th backup process is used as an example below, where j is a positive integer). This first bitmap checksum is used to perform data integrity verification on the first bitmap data before loading the data stored in the first file into the host machine's memory after virtual machine A restarts.

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

[0103] The second bitmap checksum can be generated and stored based on the second bitmap data j determined from the first bitmap data j during the j-th backup process in the static bitmap area. This second bitmap checksum can be used to perform data integrity verification on the second bitmap data j stored in the static bitmap area before storing the second bitmap data j+1 determined from the first bitmap data j+1 in the (j+1)-th backup process.

[0104] Understandably, the aforementioned first bitmap checksum and second bitmap checksum can be MD5 values ​​or checksums generated using other checksum algorithms (such as hash algorithms).

[0105] In some possible examples, if during the backup process, after storing the first image data in the first file, the value of ChgID1 has not yet been updated, and the first computing device shuts down abnormally, then the value of ChgID1 in the first file may not be the same as the backup count identifier corresponding to the latest data backup.

[0106] In some possible examples, the normality or abnormality of the first file can be determined in the following ways: For example, the normality of the first file can be determined by comparing whether the dynamic backup count value and the static backup count value are the same; if the dynamic backup count value and the static backup count value are different, the first file is abnormal; if the dynamic backup count value and the static backup count value are the same, and the first image data and the second bit image data stored in the first file have not been modified by the aforementioned first image check code and second bit image check code respectively, the first file can be determined to be normal; if the dynamic backup count value and the static backup count value are the same, but the first image data and / or the second bit image data stored in the first file have been modified by the aforementioned first image check code and / or second bit image check code respectively, the first file is determined to be abnormal.

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

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

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

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

[0111] In some possible examples, the second bitmap data includes bits corresponding to each data block in virtual disk A. This second bitmap data stores the correspondence between the backup count identifier for each backup process and the backup data to be stored in each backup process (i.e., the data blocks in virtual disk A to which the backup data belongs). For example, in the j-th backup process, the first bitmap data j indicates that the bit corresponding to data block 1 in virtual disk A is a specified value (e.g., 1), that is, the first bitmap data indicates that the data in data block 1 is data that has changed relative to the original disk data of data block 1 in virtual disk A. In the above case, the value of the bit corresponding to data block 1 in the second bitmap data is the backup count identifier (i.e., j) of the j-th backup process. For example, the value of each bit in the second bitmap data can generally be set to 4 bytes, that is, the size of each bit in the second bitmap data corresponding to a data block can be set to 4 bytes.

[0112] Wherein, if j is 1, the original disk data of data block 1 can be the data stored in data block 1 when virtual machine A starts (for example, data block 1 may not have stored any data when virtual machine A starts); if j is not 1, the original disk data of data block 1 can be the data stored in data block 1 during the (j-1)th backup process.

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

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

[0115] Understandably, the data backup process for virtual machine A is similar for each backup. The following explanation will use any one data backup process (e.g., the j-th backup process) as an example to illustrate the data backup process for virtual machine A.

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

[0117] In some possible examples, when the backup unit determines that virtual machine A needs data backup, it can send a request to the virtualization platform to invoke a specified interface of the virtualization platform. In response to this request, the virtualization platform determines that virtual machine A needs data backup. Subsequently, the virtualization platform can retrieve the first bitmap data j corresponding to virtual disk A (i.e., the current disk data of virtual machine A) from the host memory of virtual machine A (i.e., the memory of the first computing device) and feed it back to the backup unit. The backup unit then retrieves the first bitmap data j corresponding to the current disk data of virtual machine A through the virtualization platform. Next, the backup unit stores the first bitmap data j in a first file. Specifically, the backup unit stores the first bitmap data j in the dynamic bitmap area of ​​the first file.

[0118] For example, the specified interface is an interface reserved by the virtualization platform that can be called to obtain the first bit graph data corresponding to the current disk data of virtual disk A from the host memory of virtual machine A.

[0119] In some possible examples, the aforementioned methods for determining that virtual machine A needs to be backed up may include at least one of the following: receiving a data backup command for virtual machine A triggered by a user; or detecting when the time corresponding to the preset backup cycle for virtual machine A arrives; or detecting a shutdown event for virtual machine A.

[0120] For example, the backup cycle can be set to one week, and the data backup can be performed when the time of XX arrives each day within a backup cycle; correspondingly, the aforementioned detection of the arrival of the time corresponding to the preset backup cycle for virtual machine A can mean that when the time of XX arrives each day within a backup cycle, it is determined that virtual machine A needs to be backed up.

[0121] For example, the backup cycle can be set to one month, and data backup can be performed at the YY time of each day within the backup cycle; or the backup cycle can be set to one day, and data backup can be performed at the time corresponding to each aa-hour interval starting from the zz time within the backup cycle. It should be noted that the length of a backup cycle and the interval between data backups within a backup cycle can both be set according to requirements.

[0122] Understandably, within a backup cycle, the first backup within that backup cycle can be a full data backup of virtual disk A of virtual machine A, that is, backing up the data in all data blocks of virtual disk A; the subsequent backups within that backup cycle can be incremental data backups of virtual disk A of virtual machine A, that is, backing up the data in virtual disk A that has changed since the previous backup (i.e., the disk data at the time of the previous backup).

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

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

[0125] In another possible example, after storing the first bitmap data j into the dynamic bitmap area of ​​the first file, the backup unit can also store the dynamic backup count value (i.e., ...) from the metadata of the aforementioned dynamic bitmap area. Figure 5 Add 1 to ChgID1 (as shown) so that the value of ChgID1 after adding one is equal to the number of backups corresponding to this backup, i.e., j.

[0126] For example, the backup unit can also generate a first-bit map checksum j based on the first-bit map data j, and store the first-bit map checksum j in the corresponding position of the sub-area storing the metadata of the dynamic bitmap area in the first file (i.e., as shown in the example). Figure 4 The Dirty Bitmap Meta structure shown.

[0127] In some examples, the first-order graph data may exist in the form of a table, which can be called the first-order graph. This first-order graph data may include bits corresponding to each data block of virtual disk A.

[0128] When 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, a specified value (e.g., 1) for the bit corresponding to the data block indicates that the data in the data block has changed since the previous backup (e.g., since the (j-1)th backup); a non-specified value (e.g., 0) indicates that the data in the data block has not changed since the previous backup (e.g., since the (j-1)th backup). Accordingly, the original disk data of the aforementioned virtual machine A can be the data in the snapshot corresponding to the previous backup process. When j equals 1, the original disk data of the aforementioned virtual machine A can be the disk data in virtual disk A when virtual machine A starts (i.e., data that has not been backed up).

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

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

[0131] Here, the first backup count represents the number of backups corresponding to this backup of virtual machine A. For example, if this backup is the j-th backup of the disk data of virtual machine A, then the first backup count can be j. Accordingly, the current disk data of virtual machine A is the disk data in virtual disk A of virtual machine A at the time of the j-th backup; the original disk data of virtual machine A is the disk data in virtual disk A of virtual machine A at the time of the (j-1)-th backup.

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

[0133] In this step, the first bit of the graph data indicates the changes in the current disk data of virtual machine A relative to the original disk data of virtual machine A. For example, if the value of the bit corresponding to the data block in the first bit of the graph 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). If the value of the bit corresponding to the data block in the first bit of the graph data is not a specified value, it indicates that the data of the data block has not changed since the previous backup.

[0134] In some specific examples, the aforementioned first bitmap data includes bits set to a specified value (hereinafter referred to as specified bits). This specified value indicates the data changes in the current disk data of virtual machine A relative to the original disk data of virtual machine A. Correspondingly, when this backup requires incremental data backup, in step S330, the process of determining the second bitmap data based on the first bitmap data may specifically include: replacing the specified value of the specified bit in the first bitmap data with the first backup count to obtain the second bitmap data. In this way, the correspondence between the data to be backed up in the j-th backup process (including the data stored in the data blocks corresponding to each specified bit, i.e., the subsequent first backup data) and the backup count identifier of the j-th backup process can be stored. This makes it easier to find the data backed up in each backup process when performing disaster recovery backup of the disk data of virtual machine A in the future.

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

[0136] After the backup unit identifies the second bitmap data j, it stores the second bitmap data j in the first file. Specifically, it can store it in the static bitmap area of ​​the first file. In some embodiments, after storing the second bitmap data j in the first file, the backup unit can also generate a third bitmap checksum based on the stored second bitmap data in the static bitmap area, and store the third bitmap checksum in [the file]. Figure 4 The value of CHgID2 (incremented by one) is stored in the Static Bitmap Meta structure.

[0137] To illustrate this clearly, the following example will explain the specific update process of the first file, specifically the process of storing the first bitmap data from the host machine memory of virtual machine A into the first file, and the process of storing the second bitmap data into the first file.

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

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

[0140] Next, update the sub-regions of the dynamic bitmap region's metadata (i.e., such as...) Figure 4The Dirty Bitmap Meta shown shows the dynamic backup count value, i.e., the value of CHgID1 (assuming the first backup is started, the initial value of CHgID1 is set to 0, and the initial value of the static backup count value, i.e., CHgID2, is 0); specifically, read... Figure 4 The value of CHgID1 stored in the Di rty BitmapMeta structure is incremented by 1 to obtain the updated value of CHgID1. The updated value of CHgID1 is then stored in the Di rty Bitmap Meta structure. At this point, the value of CHgID1 stored in the first file is 1.

[0141] Subsequently, based on the first bitmap data 1 written to the dynamic bitmap area, the second bitmap data is determined; this process may include: reading a sub-area of ​​the metadata of the static bitmap area, i.e. Figure 4 The value of CHgID2 stored in the Static Bitmap Meta structure is incremented by 1 to obtain the updated value of CHgID2, which is 1. The second command is then called to modify the value of the bit with a value of 1 in the first bitmap data 1 to the updated value of CHgID2 (i.e., 1) using the write function, thus obtaining the second bitmap data 1. Figure 5 As shown. Then, the second bitmap data 1 is stored in the static bitmap area. Here, this is the first time the second bitmap data is stored; simply store the second bitmap data 1 in the static bitmap area.

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

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

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

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

[0146] Next, update the sub-regions of the dynamic bitmap region's metadata (i.e., such as...) Figure 4 The value of CHgID1 stored in the Dirty Bitmap Meta shown (which is 1 at this time); specifically, read... Figure 4 The value of CHgID1 stored in the Dirty Bitmap Meta structure is incremented by 1 to obtain the updated value of CHgID1. This updated value of CHgID1 is then stored in the Dirty Bitmap Meta structure. At this point, the value of CHgID1 stored in the first file is 2.

[0147] Subsequently, based on the first bitmap data 2 written to the dynamic bitmap area, the second bitmap data 2 is determined; this process includes: reading the sub-area of ​​the metadata of the static bitmap area, i.e. Figure 4 The value of CHgID2 stored in the Static Bitmap Meta structure is incremented by 1 to obtain the updated value of CHgID2, which is 2. The second command is called to modify the value of the bit corresponding to the 1-bit setting in the first bitmap data 2 to the updated value of CHgID2 (i.e., 2) (i.e., the first backup count 2) using the write function, thus obtaining the second bitmap data 2. The second bitmap data 2 is then stored in the static bitmap area, as shown below. Figure 5 As shown.

[0148] This is the second time the second bitmap data is stored in the static bitmap area. Storing the second bitmap data 2 into the static bitmap area can be achieved by updating the value of the bit with the updated value 2 (i.e., the first backup count 2) of CHgID2 in the second bitmap data 2 to the second bitmap data already stored in the static bitmap area. At this point, in the second bitmap data stored in the static bitmap area, the bit values ​​corresponding to data blocks 1 and 2 are 1 (indicating that the data in data blocks 1 and 2 is backup data stored in the first backup process), the bit value corresponding to data block 3 is 2 (indicating that the data in data block 3 is backup data stored in the second backup process), and the bit value corresponding to data block 4 is 0 (indicating that the data in it has not yet been changed).

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

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

[0151] During the third backup, i.e. the third data backup of virtual machine A, the preset first command is invoked to write the first bitmap data 3 obtained from the host memory of virtual machine A into the dynamic bitmap area of ​​the first file through the write ite function (at this time, region1 of the dynamic bitmap area is polled).

[0152] Update the metadata sub-area of ​​the dynamic bitmap area (i.e., such as...) Figure 4 The value of CHgID1 (which is 2 in this case) stored in the Dirty Bitmap Meta shown; specifically, read... Figure 4 The value of CHgID1 stored in the Di rty Bitmap Meta structure is incremented by 1 to obtain the updated value of CHgID1. This updated value of CHgID1 is then stored in the Di rty Bitmap Meta structure. At this point, the value of CHgID1 stored in the first file is 3.

[0153] Subsequently, based on the first bitmap data 3 written to the dynamic bitmap area, the second bitmap data 3 is determined; this process includes: reading the sub-area of ​​the metadata of the static bitmap area, i.e. Figure 4 The value of CHgID2 stored in the Static Bitmap Meta structure is incremented by 1 to obtain the updated value of CHgID2, which is 3. The preset second command is then called to modify the value of the bit corresponding to the 1-bit setting in the first bitmap data 3 to the updated value of CHgID2 (i.e., 3) (i.e., the first backup count 3) using the write function, thus obtaining the second bitmap data 3. The second bitmap data 3 is then stored in the static bitmap area, as shown below. Figure 5 As shown.

[0154] This is the third time that the second bitmap data is stored in the static bitmap area. The process of storing the second bitmap data 3 into the static bitmap area can be referred to the process of storing the second bitmap data 2 into the static bitmap area mentioned above, and will not be repeated here.

[0155] Then, following the same logic, for each backup, the first file is updated in the above way, that is, the first bitmap data in the host memory of virtual machine A is persisted to the first file, and the second bitmap data determined based on the first bitmap data is persisted to the first file.

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

[0157] After storing the second bitmap data in the first file, the backup unit stores the first backup data in step S340. The first backup data is the data showing the change in the current disk data of virtual machine A relative to the original disk data of virtual machine A.

[0158] It is understandable that the first backup data is the data in the data block in virtual disk A corresponding to the bit in the second bitmap data whose value is the first backup count.

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

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

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

[0162] Understandably, when storing the first backup data, the first backup count can be used as the data identifier for that first backup data to establish a correspondence between the backup indicated by the first backup count and the data it backs up (i.e., the first backup data). Alternatively, the first backup data and the first backup count can be stored in a corresponding manner, for example, by storing the correspondence between the data identifier (or storage address) of the first backup data and the first backup data identifier in the backup pool corresponding to the first backup data.

[0163] In the above process, a first file stored in non-volatile memory is added. When backing up the virtual machine's disk data, the first bitmap data corresponding to the current disk data of the virtual machine is stored in the first file to achieve persistent storage of the first bitmap data that indicates the data changes of the current disk data relative to the original disk data of the virtual machine. Then, based on the first bitmap data, second bitmap data indicating the data changes of the current disk data relative to the original disk data and the first backup count is determined and stored in the first file. The first backup data is also stored there. 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 count. Correspondingly, after multiple backup processes, the second bitmap data stored in the first file can persistently indicate which data blocks on the disk were stored for backup data in each backup. This provides a foundation for disaster recovery backup in subsequent backup processes. For example, during a backup process, if it is determined that the backup data stored in a previous backup process is corrupted, the backup data in which data blocks on the disk were stored during each backup (i.e., a backup corresponding to a backup count) can be combined with the data indicated by the second bitmap to more easily locate the corrupted backup data and subsequent backup data. Then, the corrupted backup data and subsequent backup data can be backed up again to achieve disaster recovery backup without having to perform a full backup again. This provides a basis for reducing storage resources and time consumption during data backup and improves the disaster recovery capability of backup data.

[0164] Furthermore, in the example above, the second bitmap data stored in the first file can indicate the backup count for each backup process and the changes in the disk data of virtual machine A during each backup compared to the disk data of virtual machine A during the previous backup (or the disk data when virtual machine A started). Even if virtual machine A experiences an abnormal shutdown, resulting in no backup of its disk data, the state of virtual machine A during 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, reducing the amount of data loss caused by the abnormal shutdown.

[0165] The aforementioned abnormal shutdown can refer to a shutdown that fails to trigger a shutdown event, resulting in the failure to back up the disk data of virtual machine A. Examples of abnormal shutdowns include virtual machine A shutting down due to a power outage on the host machine or virtual machine A crashing.

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

[0167] Step 11: Create a snapshot based on the current disk data of virtual machine A.

[0168] In some possible examples, when the backup unit determines that virtual machine A needs to be backed up, it sends a request to the virtualization platform to invoke a specified interface of the virtualization platform. In response to this request, the virtualization platform, after determining that virtual machine A needs to be backed up, can create a snapshot based on the current disk data of virtual machine A. Accordingly, the backup unit creates a snapshot based on the current disk data of virtual machine A through the virtualization platform. Then, step S320 is executed.

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

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

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

[0172] In some other possible examples, where there is no need to write data to virtual disk A during the backup process, the data stored in the snapshot is the same as the current disk data of virtual machine A (the disk data at the time the snapshot was generated). In this case, merging the aforementioned snapshot with the current disk data of virtual machine A can mean keeping the current disk data of virtual disk A.

[0173] In some possible examples, the backup unit can periodically perform incremental backups of the disk data in disk data A of virtual machine A. This periodic incremental backup of the disk data in disk data A of virtual machine A can be: during the first backup within a backup cycle, a full backup of the disk data in disk data A of virtual machine A is performed; and during subsequent backups within the same backup cycle, incremental backups of the disk data in disk data A of virtual machine A are performed.

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

[0175] In some possible examples, the first backup count can indicate whether this backup is the first backup in a backup cycle or not. Accordingly, the first computing device can determine whether this backup needs to be an incremental data backup or a full data backup based on the first backup count.

[0176] In some other possible examples, during a backup cycle there is a data backup performed in response to a user-triggered data backup command and / or a data backup performed upon detecting a shutdown event of virtual machine A. In order to accurately determine whether an incremental data backup or a full data backup is required for this backup, the time corresponding to this backup can be used to determine whether an incremental data backup or a full data backup is required for this backup.

[0177] For example, if the time indication for this backup is set to enter a new backup cycle, then a full data backup is required. If the time indication for this backup is still within the current backup cycle, then an incremental data backup is required. For instance, if the backup cycle is set to one week, and a backup is scheduled to occur at a specific time each day, then if the time indication for this backup is at a specific time on Sunday, then a full data backup is required, and correspondingly, all disk data in virtual disk A of virtual machine A needs to be stored. If the time indication for this backup is at a specific time on any day from Monday to Saturday (or any other time from Monday to Saturday), then an incremental data backup is required, and correspondingly, only the changes in disk data since the previous backup of virtual machine A need to be stored.

[0178] Understandably, if it is determined that a full data backup is required for this backup, the aforementioned process of determining the second bitmap data based on the first bitmap data may include: replacing the value of all bits in the first bitmap data with the first backup count to obtain the second bitmap data, which is used to indicate the data changes of the current disk data of virtual machine A relative to the original disk data of the virtual machine (specifically, indicating that all data has changed) and the first backup count.

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

[0180] Considering that during the operation of virtual machine A, bitmap data is stored in its host memory to track the data changes of each data block in its virtual disk A in real time (i.e., the modification of disk data), but the bitmap data in its host memory will be lost after virtual machine A is shut down, accordingly, after virtual machine A restarts, if the first file corresponding to virtual machine A exists, the first bitmap data corresponding to the backup process of virtual machine A before shutdown, which is currently stored in the dynamic bitmap area of ​​the first file, needs to be reloaded into the host memory of virtual machine A to continue tracking the modification of the disk data of virtual machine A.

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

[0182] For example, before data backup, i.e. before step S320 (or the aforementioned step 11), the process includes restarting virtual machine A. After restarting, virtual machine A triggers a loading request to load the first bitmap data from the first file into its host memory. The metadata area of ​​the first file also stores the first bitmap checksum corresponding to the dynamic bitmap area. This first bitmap checksum is generated based on the first bitmap data from the previous backup process. If this backup is the j-th backup, the previous backup process is the (j-1)-th backup. The first bitmap data corresponding to the previous backup process is the first bitmap data corresponding to the disk data of virtual machine A obtained during the (j-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 virtual machine A was shut down. For example, the first bitmap checksum can be an MD5 value generated based on the stored first bitmap data, or a hash value generated based on the stored first bitmap data, etc. The following explanation uses the example of the checksum corresponding to the dynamic bitmap area being based on an MD5 value generated from the stored first bitmap data.

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

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

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

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

[0187] For example, the first bitmap data corresponding to the previous backup process is stored in region1 of the dynamic bitmap area of ​​the first file. The data stored in region1 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 region1.

[0188] Next, in step 22, the first bitmap check code and the second bitmap check code are compared. This step compares the first bitmap check code and the second bitmap check code to determine if they are the same.

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

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

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

[0192] In the above example, the integrity of the first graph data loaded from the first file into the host memory of virtual machine A can be guaranteed, thus better ensuring the data security of virtual machine A.

[0193] In some other possible examples, considering that the second bitmap data stored in the static bitmap area of ​​the first file can indicate the backup count identifier and the data backed up by each backup process, it helps to trace back a certain backup process and the data backed up after it. To ensure the data security of virtual machine A, the metadata area also stores a third bitmap checksum, which is generated based on the second bitmap data currently stored in the static bitmap area corresponding to the previous backup process. Accordingly, after determining that the first bitmap checksum and the second bitmap checksum are the same, it is also necessary to verify the data integrity of the second bitmap data currently stored in the static bitmap area corresponding to the previous backup process. Specifically, a fourth bitmap checksum is generated based on the second bitmap data currently stored in the static bitmap area corresponding to the previous backup process. The third bitmap checksum and the fourth bitmap checksum are compared. If the third bitmap checksum and the fourth bitmap checksum are the same, it is determined that the second bitmap data currently stored in the static bitmap area corresponding to the previous backup process has not been modified. Then, the first bitmap data corresponding to the previous backup process is sent to virtual machine A so that virtual machine A loads the first bitmap data into its host memory. If the third bitmap checksum and the fourth bitmap checksum are different, it can be determined that the second bitmap data corresponding to the previous backup process of the current storage has been modified and is no longer usable. Consequently, the first file is unusable, and a prompt message can be output to indicate to the user of virtual machine A that the first file of virtual machine A has an error.

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

[0195] Correspondingly, in some other examples, after step 12 mentioned above, steps 13-14 may also be included, which determine the data in the snapshot that has changed relative to the current disk data of virtual machine A (i.e., the disk data of virtual machine A when the snapshot was generated during the j-th backup) as the target data; and update the initialized bitmap data in the host machine memory based on the target data.

[0196] In this example, the target data of the disk data change of virtual machine A relative to the j-th backup of virtual machine A is determined in the snapshot. Based on the target data, the data block to which it belongs is determined as the change block. Then, the values ​​of the bits corresponding to each change block in the initialized bitmap data in the host machine memory are modified to the specified values ​​to indicate the data change in each change block. This realizes the tracking and recording of the data change of data blocks (where the data is changed) in virtual disk A during the j-th backup.

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

[0198] For example, such as Figure 6 As shown, in step S610, the first computing device can detect whether virtual machine A needs to be backed up. In step S620, when it is determined that virtual machine A needs to be backed up, the snapshot function can be started, and a snapshot can be created based on the current disk data of virtual machine A using the COW (Copy-on-write) technology of the snapshot function; in step S630, the first bitmap data A corresponding to the current disk data of virtual machine A is obtained from the host memory of virtual machine A; and in step S640, the first bitmap data A is stored in the dynamic bitmap area of ​​the first file (for example, the first bitmap data B of the previous backup is stored in region1 of the dynamic bitmap area, and the first bitmap data A is stored in region2 of the dynamic bitmap area).

[0199] Next, in step S650, the first computing device increments the ChgID1 corresponding to the dynamic bitmap area stored in the metadata area by 1; then, in step S660, it determines the bit with a specified value (e.g., 1) from the first bitmap data A, which indicates that the data of the corresponding data block has changed; in step S670, the first computing device increments the ChgID2 corresponding to the static bitmap area stored in the metadata area by 1; in step S680, it replaces the value of the bit with the specified value in the first bitmap data with the incremented ChgID2 to obtain the second bitmap data, which is equivalent to the first backup number of this backup; in step S690, it stores the second bitmap data in the static bitmap area of ​​the first file.

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

[0201] Next, the first computing device determines that data backup of virtual machine A is required, and performs this backup before, simultaneously with, or after storing the first backup data (and before merging the snapshot obtained in step S620 into virtual disk A), as follows: Figure 6 As shown, it may also include step S6110. In step S6110, if a write request indicating that data should be written to virtual disk A is received, the write request is redirected to the aforementioned snapshot so that the data involved in the write request is written into the aforementioned snapshot. This sets virtual disk A to a read-only state so that it remains in the state when it was determined that data backup of virtual machine A was needed. This avoids writing data from write requests after it was determined that data backup of virtual machine A was needed into virtual disk A, so that the first backup data determined for this backup is not the data when it was determined that data backup of virtual machine A was needed, and thus the state of virtual machine A when it was determined that data backup of virtual machine A was needed cannot be restored later.

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

[0203] In the example above, while virtual machine A is backing up data, it can still respond to received write requests and write data to improve the user experience, and ensure that virtual disk A remains in the state it was in when it was determined that virtual machine A needed to be backed up.

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

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

[0206] Understandable. Figure 6 This is merely a schematic diagram of a data backup process and does not constitute a limitation on the order in which the steps are executed. For example, step S6130 may be executed before step S6100 or step S640; step S6110 may be executed before step S630, and so on.

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

[0208] Based on the above method embodiments, exemplarily, Figure 7 The diagram illustrates a flowchart of another data backup method provided in this application. This method can be applied to the aforementioned first computing device, which is equipped with the aforementioned backup unit, to provide data backup services for one or more virtual machines. Exemplarily, the one or more virtual machines can be built and managed through a virtualization platform. In some possible examples, the first computing device can also be equipped with a virtualization platform to jointly manage one or more virtual machines and provide data backup services. In yet other possible examples, the virtualization platform can also be deployed in a non-first computing device; correspondingly, the first computing device can jointly manage one or more virtual machines and provide data backup services with a device that has deployed the virtualization platform.

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

[0210] The following description uses any virtual machine A from one or more virtual machines as an example to illustrate the data backup process. For the data backup process of other virtual machines, please refer to the data backup process for virtual machine A. In this embodiment, the first computing device uses incremental backup to back up the disk data in virtual disk A of virtual machine A (hereinafter referred to as the disk data of virtual machine A). The following description uses the example where the backup unit, the virtualization platform, and virtual machine A all run on the first computing device to illustrate the data backup process.

[0211] After each time it is determined that a data backup is necessary, such as Figure 7 As shown, the method may include the following steps S710-S780:

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

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

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

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

[0216] In step S740, if it is determined that incremental data backup is required for this backup, the integrity of each second backup data previously backed up is verified.

[0217] The method for determining whether this backup requires incremental or full data backup can be found in the methods described in the foregoing embodiments, and will not be repeated here.

[0218] In this step, assuming this backup is not the first backup, meaning it requires incremental data backup, and considering that the data backed up in this backup is incremental data corresponding to the previous backup, if it is necessary to restore virtual machine A to its state at the time of this backup based on the data backed up in this backup, it will depend on the data backed up before this backup (i.e., each second backup data). If one or more second backup data are abnormal (e.g., corrupted or lost), then the abnormal second backup data and all subsequent second backup data will be unusable (i.e., virtual machine A cannot be restored to its state at the time of its corresponding backup). Therefore, to ensure the effectiveness of this backup, it is necessary to verify the integrity of each second backup data backed up before this backup.

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

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

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

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

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

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

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

[0226] Then, in step 33, for each second backup data, the first data check code and the second data check code corresponding to the second backup data are compared. 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, then it is determined that the integrity verification of each second backup data has passed.

[0227] 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 the 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 not abnormal (i.e., it is not damaged and not lost). At this time, the first computing device can continue to perform incremental data backup relative to the previously backed-up second backup data, and then continue to execute the subsequent step S750.

[0228] In some possible scenarios, considering the possibility that one or more second backup data sets from previous backups might be completely lost, the first computing device can obtain the backup count identifier corresponding to each second backup data set before acquiring the first data checksum for each set. Based on the backup count identifier and the first backup count for this backup, it can determine whether any second backup data is missing. If it is determined that no second backup data is missing, proceed to step S740. If it is determined that second backup data is missing, and the missing second backup data is not a full backup of the first backup, then the disaster recovery backup process can begin. This disaster recovery backup process will be described later.

[0229] For example, if the backup count identifiers corresponding to each second backup data are numerically consecutive to the first backup count of this backup, and the number of existing second backup data is as expected (for example, the number of backups performed (in the current backup cycle) can be counted, and the number of second backup data equals that count), then it can be determined that there is no missing second backup data. If the number of existing second backup data is not as expected, or the backup count identifiers corresponding to each second backup data are not numerically consecutive to the first backup count of this backup, then it is determined that there is missing second backup data.

[0230] In step S750, if the integrity verification of each second backup data is found to be successful, the first backup data is stored. Then, step S760 is executed, in which the aforementioned snapshots and the current disk data of virtual machine A are merged.

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

[0232] In the above example, if it is determined that incremental data backup is required for this backup, the integrity of each second backup data previously backed up (within the current backup cycle) can be verified. After the verification passes, incremental data backup continues to ensure the availability of the incremental data chain formed (in the current backup cycle) and the data security of virtual machine A. If it is determined that a full data backup is required for this backup, then this backup is determined to have entered a new backup cycle and is the first backup of the new backup cycle. Accordingly, the data in each data block of virtual disk A (i.e., the current disk data) can be directly stored to perform a full data backup of virtual machine A and ensure the data security of virtual machine A.

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

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

[0235] In this step, if the comparison result indicates that the integrity verification of the third backup data in each of the second backup data failed (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 corrupted. Accordingly, the third backup data and each of the second backup data backed up after the third backup data are unusable. At this time, disaster recovery backup of virtual machine A is required.

[0236] Specifically, the first computing device determines the second backup count corresponding to the third backup data (this 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 count). Next, in step S790, based on the second backup count and the second bitmap data, the disaster recovery backup data for virtual machine A is determined. This disaster recovery backup data includes the data indicated by the second backup count, the first backup count, and the backup count identifiers between them in the current disk data of virtual machine A.

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

[0238] In step S7100, disaster recovery backup data is stored, and the data is identified using the second backup count, the first backup count, and the backup counts in between. Then, step S760 is executed.

[0239] In some possible examples, the first computing device can continue storing disaster recovery backup data based on each of the second backups preceding the third backup data (in the current backup cycle). By identifying the number of second backups, the number of first backups, and the backup counts in between, the disaster recovery backup data can be identified as including all data blocks whose data has changed relative to the disk data at the time of the backup preceding the third backup data. This enables incremental backups of the corrupted third backup data and subsequent backups, better reducing backup resource consumption and improving backup speed.

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

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

[0242] The following example illustrates the disaster recovery backup process for the disk data of virtual machine A.

[0243] Suppose we set a backup cycle of one week, and we set virtual machine A to be backed up at XX time every day.

[0244] Suppose that virtual machine A is backed up for the first time on Sunday. At XX o'clock on Sunday, the first computing device determines to perform the first backup of virtual machine A, storing the data in all data blocks of virtual disk A, and obtaining the following... Figure 8 The full backup data -0 shown is first stored locally on the host machine of virtual machine A. Then, full backup data -0 is backed up to the backup environment (i.e., the backup pool). In the backup environment, the correspondence between full backup data -0 and the backup count identifier (i.e., 1) is stored (or the backup count identifier 1 can be used as the data identifier, i.e., name, of full backup data -0) to form incremental data chain 1. Subsequently, backups from non-backup environments (such as those existing in the backup pool) can also be backed up. Figure 8 The production environment shown (e.g., the host machine of virtual machine A) is fully backed up and deleted (-0) to save local storage resources on the host machine.

[0245] At XX o'clock on Monday, the first computing device determined to perform a second backup of virtual machine A. This required incremental data backup of virtual machine A, and the data to be determined from virtual disk A was... Figure 8The incremental backup data-1 shown is first stored locally on the host machine of virtual machine A. Then, after verifying that the full backup data-0 is not corrupted, incremental backup data-1 is backed up to the backup environment. In the backup environment, the correspondence between incremental backup data-1 and the backup count identifier (i.e., 2) is stored (or the backup count identifier 2 can be used as the data identifier, i.e., name, of incremental backup data-1). Subsequently, data from non-backup environments (such as those existing in the backup environment) can also be backed up. Figure 8 The production environment shown (e.g., the host machine of virtual machine A) incremental backup data -1 is deleted to save local storage resources on the host machine.

[0246] The data backup process for virtual machine A by the first computing device at XX o'clock on Tuesday and Wednesday can be referred to in the aforementioned data backup process for virtual machine A by the first computing device at XX o'clock on Monday, and will not be repeated here.

[0247] At XX o'clock on Thursday, the first computing device determines that it will perform the fifth data backup of virtual machine A. Incremental data backup of virtual machine A is required. At this time, the values ​​of ChgID1 and ChgID2 are both 4. The first bit graph data 5 corresponding to the current disk data of virtual disk A of virtual machine A is obtained from the host memory of virtual machine A. The first bit graph data 5 indicates the data changes of each data block in the virtual disk relative to the fourth backup.

[0248] The first computing device stores the first bitmap data 5 in the dynamic bitmap area of ​​the first file, and increments ChgID1 by 1 to obtain the incremented ChgID1, which is then stored in the metadata area. At this time, ChgID1 = 5. Then, based on the first bitmap data 5 stored in the dynamic bitmap area, the first bitmap check code is generated and stored in the metadata area.

[0249] Subsequently, the first computing device increments ChgID2 by 1 to obtain an incremented ChgID2, at which point ChgID2 = 5. The value of the incremented ChgID2 is equal to the backup count identifier 5 (i.e., the fifth backup). Then, the value of the bit with a specified value (e.g., 1) in the first bitmap data 5 is replaced with the incremented ChgID2, i.e., replaced with 5, to obtain the 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.

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

[0251] Next, the checksum 01 corresponding to the full backup data-0, the checksum 11 corresponding to the incremental backup data-1, the checksum 21 corresponding to the incremental backup data-2, and the checksum 31 corresponding to the incremental backup data-3 (data backed up on Wednesday) are obtained sequentially. Then, based on the full backup data-0, incremental backup data-1, incremental backup data-2, and incremental backup data-3 currently stored in the backup environment, checksums 02, 12, 22, and 32 are generated respectively. Checksums 01 and 02 are compared, checksums 11 and 12 are compared, checksums 21 and 22 are compared, and checksums 31 and 32 are compared.

[0252] If checksums 01 and 02 are the same, checksums 11 and 12 are the same, and checksums 21 and 22 are the same, but checksums 31 and 32 are different, then incremental backup data -3 is determined to be corrupted. At this point, it is determined that disaster recovery backup of virtual machine A's data is required. Specifically, the backup count identifier 4 corresponding to incremental backup data -3 is determined, which is ChgID2 incremented by one (i.e., 4). Based on the backup count identifier 4 corresponding to incremental backup data -3, the aforementioned third command is invoked. Based on the second bitmap data 5 stored in the first file, the bits with values ​​greater than or equal to 4 (and their corresponding data blocks) are determined. The preset fourth command is invoked. Based on the data in the data block in virtual disk A corresponding to the bits with values ​​greater than or equal to 4 in the second bitmap data 5, the following is obtained: Figure 8 The incremental backup data shown is 5. At this point, the incremental backup data 5 includes the aforementioned incremental backup data 3 and incremental backup data 4.

[0253] Incremental backup data-5 is backed up to the backup environment (i.e., the backup pool). Within the backup environment, a mapping is established between incremental backup data-5 and the backup count identifiers 4 and 5 corresponding to incremental backup data-3 (or, the backup count identifiers 4 and 5 corresponding to incremental backup data-4 are used as the name of incremental backup data-5). Subsequently, a corresponding checksum 51 can be generated based on the stored incremental backup data-5, and this checksum 51 can be stored for verification of the data integrity of incremental backup data-5 during the next backup.

[0254] Specifically, such as Figure 8 As shown, the first computing device can copy data in a backup environment, such as... Figure 8The full backup data-0, incremental backup data-1, and incremental backup data-2 in the backup data chain 1 shown will be copied and combined with incremental backup data-5 to form a new incremental data chain 2, which is the disaster recovery backup-prepared incremental data chain 2. All data in backup data chain 1 will then be deleted.

[0255] Subsequently, during this week (i.e., within the backup cycle), on Fridays and Saturdays until XX o'clock next Sunday, the first computing device can continue to perform incremental data backups of virtual machine A based on incremental data link 2. This is to reduce backup resource consumption and improve backup speed.

[0256] Based on the methods described in the above embodiments, this application provides a data backup device. Please refer to... Figure 9 , Figure 9 This is a schematic diagram of the structure of a data backup device provided in an embodiment of this application.

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

[0258] In some possible examples, this also includes:

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

[0260] Also includes:

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

[0262] In some possible examples, this also includes:

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

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

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

[0266] It also includes: a first generation module (not shown in the figure), configured to generate a second bitmap check code based on the first bitmap data currently stored in the dynamic bitmap area corresponding to the previous backup process, after detecting a loading request for the virtual machine to load the first bitmap data into its host memory before obtaining the first bitmap data corresponding to the current disk data of the virtual machine; the loading request is sent after the virtual machine restarts.

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

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

[0269] In some possible examples, this also includes:

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

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

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

[0273] Generate a second data check code based on each of the currently stored second backup data;

[0274] For each second backup data, compare the first data check code and the second data check code corresponding to that second backup data. 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, then it is determined that the integrity verification of each second backup data has passed.

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

[0276] The second determining module (not shown in the figure) is configured to determine the number of second backups corresponding to the third backup data if the integrity verification of the third backup data in each second backup data fails.

[0277] The third determining module (not shown in the figure) is configured to determine the disaster recovery backup data of the virtual machine based on the second backup count and the second bitmap data. The disaster recovery backup data includes the data indicated by the second backup count, the first backup count and the backup count identifier between them in the current disk data of the virtual machine.

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

[0279] In some possible examples, the first bitmap data includes a specified bit set to a specified value, the specified value being used to indicate that the current disk data of the virtual machine has changed relative to the original disk data of the virtual machine;

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

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

[0282] In some possible examples, the first file may be in any of the following formats: raw or qcow2.

[0283] It should be understood that the above-described device is used to execute the methods in the above embodiments. The implementation principle and technical effect of the corresponding program modules in the device are similar to those described in the above methods. The working process of the device can be referred to the corresponding process in the above methods, and will not be repeated here.

[0284] Based on the methods in the above embodiments, such as Figure 10 As shown in the figure, 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 for executing the program stored in the first memory; the processor, the first memory, and the second memory are connected via a bus, wherein when the program stored in the first memory is executed, the processor is used to execute the method described in the above embodiment.

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

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

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

[0288] 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. The general-purpose processor may be a microprocessor or any conventional processor.

[0289] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from 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 reside in an ASIC.

[0290] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as 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 this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive (SSD)).

[0291] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

Claims

1. A data backup method, characterized in that, The method includes: The first bitmap data corresponding to the current disk data of the virtual machine is obtained and stored in a first file. The first file is stored in non-volatile memory. 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. The first bitmap data includes a specified bit set to a specified value. The specified value 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. Based on the first bitmap data, second bitmap data is determined and stored in the first file. The second bitmap data is used to indicate the data changes of the virtual machine's current disk data relative to the virtual machine's original disk data and the first backup count. The step of 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 count to obtain the second bitmap data. Store first backup data, which is the data showing changes in the virtual machine's current disk data relative to the virtual machine's original disk data.

2. The method as described in claim 1, characterized in that, Before obtaining the first-bit graph data corresponding to the current disk data of the virtual machine, the method further includes: Create a snapshot based on the current disk data of the virtual machine; After storing the first backup data, the following is also included: The snapshot is merged with the current disk data of the virtual machine.

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

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

5. The method as described in claim 3, characterized in that, The metadata area also stores the first bit map check code, which is generated based on the first bit map data corresponding to the previous backup process. Before obtaining the first-bit graph data corresponding to the current disk data of the virtual machine, the method further includes: After detecting a loading request from the virtual machine to load the first bitmap data into its host memory, a second bitmap check code is generated based on the first bitmap data currently stored in the dynamic bitmap area corresponding to the previous backup process. The loading request is sent after the virtual machine restarts. Compare the first bitmap checksum with the second bitmap checksum; If the first bitmap check code is the same as the second bitmap check code, then the first bitmap data currently stored in the dynamic bitmap area is loaded into the host machine memory.

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

7. The method according to any one of claims 1-6, characterized in that, The storage of the first backup data includes: The first backup data is stored in a designated storage area of ​​the virtual machine's host machine; or, The first backup data is stored in the backup pool corresponding to the virtual machine; or... The first backup data is stored in a designated storage area on the host machine of the virtual machine; and the first backup data stored in the designated storage area is stored in the backup pool corresponding to the virtual machine.

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

9. A computing device, characterized in that, include: The first memory is used to store the program; The second memory is used to store the first file, and the second memory is a non-volatile memory; At least one processor for executing a program stored in the first memory; When the program stored in the first memory is executed, the processor is used to execute the method as described in any one of claims 1-8.

Images