Method for Backup and Recovery
By determining the priority of data blocks based on file attributes when backing up data, and prioritizing the reception of high-priority data blocks during recovery, the problem of large backup data capacity resulting in long recovery time is solved, and faster service recovery and higher operational stability is achieved.
Patent Information
- Application Number
- CN202011507744.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-12-18
- Publication Date
- 2025-06-17
- Estimated Expiration
- 2040-12-18
AI Technical Summary
Due to the large capacity of backup data, the service recovery time is long and cannot meet the business needs of cloud computing and cloud storage technology.
By determining the priority of the data blocks based on the data file attributes to be backed up and storing these priority indications to the second storage device, the data blocks that are more important to recovery are determined when backing up the data. During recovery, high-priority data blocks are received first to speed up recovery.
It realizes the determination of data blocks that are more important for recovery while backing up data, so that these data blocks are preferred during recovery, significantly speeding up the recovery speed and improving the operational stability and user experience of cloud computing service providers.
Smart Images

Figure CN114647537B_ABST
Abstract
Description
Technical Field
[0001] Embodiments of the present disclosure relate to the field of computers, and more particularly, to a method for backup, a method for recovery, a computing device, a computer-readable storage medium, and a computer program product. Background Art
[0002] With the development of cloud computing and virtualization technologies, more and more Internet service providers host their servers and business data on virtual machines of computing infrastructures located in the cloud, and regularly back up their data to a data warehouse. When recovery from the data warehouse is needed, for example, when the computing infrastructure in the cloud unfortunately fails, the backed-up data is requested from the data warehouse and stored locally to restart the virtual machine and resume the service.
[0003] Although it does not occur frequently, it is still desirable to resume the service as soon as possible after a service interruption. Since the capacity of the backup data is usually hundreds of gigabytes or more, the time to resume the service is long. The usual recovery time objective (RTO) is up to several hours or even several days, which cannot meet the business requirements. This poses a challenge to cloud computing and cloud storage technologies. Summary of the Invention
[0004] The present disclosure provides a technical solution that facilitates more rapid recovery of a service from backup data, so as to improve the operational stability of cloud computing service providers and the user experience.
[0005] According to a first aspect of the present disclosure, there is provided a method for backup, including: determining a priority of a data block associated with at least one file based on an attribute of at least one file included in data to be backed up; and storing an indication of the priority of the data block and the data to be backed up into a second storage device.
[0006] According to a second aspect of the present disclosure, there is further provided a method for recovery, including: receiving, from a second storage device, an indication of a first priority and an indication of a second priority related to data to be recovered, the first priority being associated with a first set of data blocks, the second priority being associated with a second set of data blocks, and the first priority being higher than the second priority; receiving the first set of data blocks from the second storage device; and after completing the reception of the first set of data blocks, receiving the second set of data blocks from the second storage device.
[0007] According to a third aspect of the present disclosure, there is also provided a computing device, including: at least one processing unit; at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the computing device to execute the method according to one of the first aspect and the second aspect of the present disclosure.
[0008] According to a fourth aspect of the present disclosure, there is also provided a non-transitory computer storage medium including machine-executable instructions that, when executed by a device, cause the device to execute the method according to one of the first aspect and the second aspect of the present disclosure.
[0009] According to a fifth aspect of the present disclosure, there is also provided a computer program product including machine-executable instructions that, when executed by a device, cause the device to execute the method according to one of the first aspect and the second aspect of the present disclosure.
[0010] In this way, it is possible to determine data blocks that are more important for recovery while backing up data, for faster recovery of backup data in the future. Accordingly, when recovering data, it is possible to preferentially receive data blocks that are more important for recovery, accelerating the recovery speed.
[0011] It should be understood that the summary section is not intended to identify key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The above and other objects, features and advantages of the embodiments of the present disclosure will become more readily understood by referring to the following detailed description of the drawings. In the drawings, multiple embodiments of the present disclosure will be illustrated by way of example and not limitation, where:
[0013] Figure 1 A schematic diagram of an example computing system for backup and recovery is shown
[0014] Figure 2 A schematic diagram of a computing system for backup according to an embodiment of the present disclosure is shown
[0015] Figure 3 A schematic diagram of a computing system for backup according to an embodiment of the present disclosure is shown.
[0016] Figures 4A to 4F A schematic diagram showing the priorities of predicted files and data blocks is shown.
[0017] Figure 5Shows a schematic diagram of a computing system for recovery according to an embodiment of the present disclosure.
[0018] Figure 6 Shows a schematic diagram of a computing system for recovery according to another embodiment of the present disclosure.
[0019] Figure 7 Shows a schematic flow chart of a method for backup according to an embodiment of the present disclosure.
[0020] Figure 8 Shows a schematic flow chart of a method for recovery according to an embodiment of the present disclosure.
[0021] Figure 9 Shows an example processing platform including a cloud infrastructure according to an embodiment of the present disclosure.
[0022] Figure 10 Shows a schematic block diagram of a device that can be used to implement an embodiment of the present disclosure. Detailed implementation
[0023] Now, the concept of the present disclosure will be described with reference to various exemplary embodiments shown in the accompanying drawings. It should be understood that the description of these embodiments is only for enabling those skilled in the art to better understand and further implement the present disclosure, and is not intended to limit the scope of the present disclosure in any way. It should be noted that, where feasible, similar or identical reference numerals may be used in the figures, and similar or identical reference numerals may represent similar or identical elements. Those skilled in the art will understand that, from the following description, alternative embodiments of the structures and / or methods described herein may be adopted without departing from the principles and concepts of the present disclosure described.
[0024] In the context of the present disclosure, the term "comprising" and its various variants may be understood as open-ended terms, meaning "including but not limited to"; the term "based on" may be understood as "at least partially based on"; the term "one embodiment" may be understood as "at least one embodiment"; the term "another embodiment" may be understood as "at least one other embodiment". Other terms that may occur but are not mentioned here should not be interpreted or defined in a manner contrary to the concepts on which the embodiments of the present disclosure are based, unless explicitly stated.
[0025] As described above, when it is necessary to recover the backed-up data from the data warehouse to restart the virtual machine and restore the service, since the capacity of the backup data is usually hundreds of gigabytes or more, the time for restoring the service is long, and the usual recovery time objective is up to several hours or even several days, which cannot meet the business requirements.
[0026] To solve or mitigate the above problems and / or other potential problems, embodiments of the present disclosure propose a method for backup, which can be implemented, for example, in a cloud computing device. The method includes: determining the priority of data blocks associated with at least one file based on the attributes of at least one file included in the data to be backed up; and storing the data to be backed up and an indication of the determined priority of the data blocks in a second storage device (e.g., a remote data warehouse). In this way, while backing up the data, it is possible to determine the data blocks that are more important for recovery, for faster recovery of the backed-up data in the future.
[0027] Correspondingly, embodiments of the present disclosure also propose a method for recovery, which is implemented, for example, in a local cloud computing device. The method includes: receiving from a second storage device (e.g., a remote data warehouse) an indication of a first priority and an indication of a second priority related to the data to be recovered, the first priority being associated with a first set of data blocks, the second priority being associated with a second set of data blocks, and the first priority being higher than the second priority; receiving the first set of data blocks from the second storage device; and after completing the reception of the first set of data blocks, receiving the second set of data blocks from the second storage device. In this way, when recovering the backed-up data from the second storage device, it is possible to preferentially receive the data blocks that are more important for recovery, thereby accelerating the recovery speed.
[0028] The following illustrates the basic principles and implementation manners of the present disclosure with reference to the accompanying drawings. It should be understood that the exemplary embodiments given are only for enabling those skilled in the art to better understand and then implement the embodiments of the present disclosure, rather than limiting the scope of the present disclosure in any way.
[0029] Figure 1 A schematic diagram of an exemplary computing system 100 for backup and recovery is shown. As Figure 1 shown, the computing system 100 includes an application server 110, which can be a centralized or distributed entity computing device provided by a public cloud or a private cloud, on which several virtual machines (VMs) 130 providing services can run. For example, the application server 110 can run a virtual machine manager (VMM or Hypervisor) 120, which can control and schedule the computing resources of several virtual machines 130 thereon. By using virtualization technology, the virtual machine manager 120 can provide virtual devices, such as virtual processors, virtual memories, virtual I / O devices (such as virtual disk devices), etc., to the guest operating systems of the virtual machines it hosts.
[0030] In some embodiments, the virtual machine manager 120 can be, for example, a bare-metal virtual machine directly installed on a physical server, such as ESXi or the like, or a host virtual machine manager installed on a host operating system, such as Workstation or the like, or a combination of the above two, that is, a part of the hardware resources are directly controlled by the virtual machine manager, and a part are controlled by a privileged operating system, such as Xen or the like.
[0031] The virtual machine manager 120 can use, for example, containers to run a number of virtual machines 130 thereon, and the virtual machines 130 run applications to provide services. In some embodiments, each virtual machine 130 can create its virtual disk device (for example, having a virtual machine disk format VMDK) and store it in the physical storage device 150 of the application server 120. The virtual machine manager 120 also includes an agent 140, and the agent 140 is used to facilitate the interaction between the virtual machine 130 and components outside the virtual machine manager 130 to implement and control functions such as network connection of the virtual machine 130, input / output (I / O) device access, and the like.
[0032] The storage device 150 can be centralized or distributed. As shown in the figure, the storage device 150 stores virtual machine file data related to the virtual machine 130, which is organized as a virtual disk 160 in, for example, the VMDK format. The virtual disk 160 can manage files on the virtual disk via a virtual machine file system (VMFS), such as creating, reading, writing, deleting, and the like. Generally, the virtual disk 160 can represent a physical disk drive of the VMFS on the virtual machine, which can include all application data and configuration information related to the virtual machine itself. For example, the virtual disk 160 can be mounted as an I / O device (for example, by a MOUNT command) so that the virtual machine 130 can conveniently read, modify, add, delete, and save the content therein. As shown in the figure, the virtual disk 160 can be a block device and includes a plurality of data blocks. A data block is the smallest unit for storing file data, and its size is usually, for example, 512 bytes or 4K bytes. It can be understood that in a file system, a file can be split and stored in discontinuous data blocks, and the data blocks to which the file is split and stored can be found through the index of the file system. According to the embodiments of the present disclosure, the virtual disk 160 can include, but is not limited to, files related to virtual machine startup, configuration files, application files (for example, database files of an Internet service provider), and the like.
[0033] Such as Figure 1As shown by the dark arrow, when backing up data, the agent 140 can read the virtual disk 160 from the storage device 150 in response to a backup command and send it intact to the storage server 170. The storage server 170 can be a distributed large-capacity cloud storage infrastructure provided by a storage service provider, which can back up the business data of virtual machines on the application server 110 regularly or irregularly. For example, a full backup of a certain virtual machine can be performed once a week, and then an incremental backup can be performed once a day, so that more data can be stored with less space. In some embodiments, the logical data capacity of the full backup may reach multiple terabytes, and even after deduplication, the actual data capacity backed up to the storage server 170 is at least several hundred gigabytes. The logical data capacity of the incremental backup may reach dozens or hundreds of gigabytes, and after deduplication, the actual data capacity backed up to the storage server 170 is at least dozens of gigabytes.
[0034] When the application server 110 is damaged, for example, when the storage device 150 fails or is damaged for other reasons, in order to restart the service, the agent 140 needs to receive the backed-up data from the storage server 170 and save it to the storage device 150. Then, the virtual machine 130 can read all the data required for recovery from the mounted storage device 150 through an input / output (I / O) request to restart the service, as Figure 1 shown by the light arrow. In other words, for the virtual machine 130, the recovery requires that all the backed-up data be transmitted and written to the local storage device 150 before the virtual machine 130 can be restarted. As described above, since the capacity of the backed-up data is as high as dozens or hundreds of gigabytes, it is difficult to restore the service in a short time under the existing bandwidth conditions, especially when the application server 110 and the storage server 170 are in remote communication, the time required to restore the service is even longer.
[0035] Figure 2 FIG. shows a schematic diagram of a computing system 200 for backup according to an embodiment of the present disclosure. As shown, the computing system 200 includes an application server 210 and a storage server 270, and Figure 1The computing system 100 is similar. The storage server 270 is adapted to receive backup data from the application server 210. The virtual machine manager 220 can run a number of virtual machines 230 and includes an agent 240 for handling operations of the virtual machines 230 (such as network connection, input / output). The agent 240 can receive the virtual disk 260 to be backed up from the storage device 250 of the application server 210 in response to a backup request from the virtual machine manager 220 or the virtual machine 230. The virtual disk 260 includes a plurality of data blocks, which are organized as files through a file system. According to an embodiment of the present disclosure, the agent 240 includes a priority module 280, which can be implemented in the agent 240 in the form of a plug-in and is used to handle operations related to backup and recovery when it is called and runs. For example, during backup, the agent 240 can mount the data to be backed up related to the virtual machine 230 (for example, all data in a certain virtual disk 260) as a block device, such as a virtual disk device, and then run the priority module 280. The priority module 280 can generate priority information for the data blocks in the virtual disk 260 that is mounted as a block device. The priority information can be sent to the storage server 270 together with the virtual disk 260 to be backed up for backup. These priority information can help to recover the virtual machine 130 faster. More details about generating the priority information and using the priority information during recovery are described in detail below.
[0036] Figure 3 FIG. shows a schematic diagram of a computing system 300 for backup according to an embodiment of the present disclosure. As Figure 3 shown, the application server 310 runs a virtual machine monitor 320 (such as ESXi), a certain virtual machine (also known as the target virtual machine) 330 on the virtual machine monitor 320 needs to back up data. For example, the target virtual machine 330 indicates that it is necessary to back up its virtual disk 360 to the storage server 370. In some embodiments, the virtual disk 360 may have the virtual machine disk format VMDK, but is not limited thereto. Additionally, the types of files in the virtual disk 360 include, but are not limited to: virtual machine configuration files (VMX), virtual machine snapshot files (VMSD),.NVRAM files, VMX.LCK files, VMWARE.LOG, etc., and these files are stored as data blocks 362 in the virtual disk 360. In some embodiments, the virtual disk 360 may include a virtual machine file system (VM FileSystem, abbreviated as VFS). Additionally or alternatively, the virtual machine file 360 may also include other file systems, such as NTFS, FAT, CDFS, exFAT, Ext2, Ext3, Ext4, HFS+, etc. Similarly, via the file system, the files in the virtual disk are organized as data blocks 362. In some embodiments, the file system records the offset addresses of several data blocks associated with each file. Through the file system, the storage locations of all files in the virtual disk 360 and the data blocks 362 associated with each file can be determined.
[0037] According to an embodiment of the present disclosure, in order to transfer and back up the virtual disk 360 to the storage server 370, the agent 340 can mount the virtual disk 360 as a block device, such as a virtual disk device, and then can call and run the priority module 380. The priority module 380 can utilize the file system of the virtual disk 360 to generate a metadata file 381 (M) of all files of the virtual disk 360. The metadata file 381 records the attributes (also known as metadata) of the files of the virtual disk 360.
[0038] In some embodiments, the file system of the virtual disk 360 may include an index node (inode) for each file. The index node may include the attributes of the file, for example, the size of the file, the owner ID of the file, the read, write, and execute permissions for accessing the file, the timestamp of the file (including the last change time of the index node, the last change time of the file content, the last access time of the file), the location of the file data block, the number of blocks, the I / O block size, the device number, and so on. The priority module 380 can use at least a part of the attributes of the index node in the file system to generate the metadata file 381, and then can predict the priority of the data blocks 362 in the virtual disk 360 based on the metadata file 381. The predicted priority can be recorded in the priority file 382, which can be sent to the storage server 370 together with the virtual machine file 360 for backup, as Figure 3As shown by the dark arrows. In some embodiments, priorities for associated data blocks may be generated only for some of the files in the virtual disk 360, rather than for all files.
[0039] According to an embodiment of the present disclosure, when restoring the target virtual machine 330, the application server 320 may parse its priority file 382 to receive data blocks with higher priorities from the storage server 370 earlier, so as not to wait until all data blocks are received before starting to restore the virtual machine 330. In other words, when starting to restore the target virtual machine 330 on the application server 310, data blocks with high importance are preferentially transmitted and stored back to the storage device 350 local to the application server 310, so that the target virtual machine 330 can obtain these data blocks in time to restore the service faster. According to an embodiment of the present disclosure, the priority of data blocks can be predicted by predicting the priority of files. More details of predicting the priorities of files and data blocks are described below.
[0040] Figures 4A to 4F A schematic diagram showing the prediction of the priorities of files and data blocks is shown. According to an embodiment of the present disclosure, the last startup time of the target virtual machine 330 can be obtained by executing a command of the virtual machine (for example, a command in the virtual machine toolbox VMtools), and the time range from the last startup time to the present can be obtained, as Figure 4A shown. Then, the time range can be divided into multiple intervals, and the length of each interval can be fixed (such as 30 minutes) and uniform, or can also have a variable length with dynamic adjustment. As Figure 4B shown, the time range is divided into several intervals with a length of 30 minutes. Next, priorities can be assigned to each interval. As Figure 4C shown, higher priorities can be assigned to the intervals at both ends of the time range. For example, priority 1 is assigned to the leftmost and rightmost intervals of the time range, priority 2 is assigned to the second interval from the left and the second interval from the right, priority 3 is assigned to the third interval from the left and the third interval from the right, and so on. According to an embodiment of the present disclosure, time intervals closer to the last startup time or the current time are assigned higher priorities because when restoring the virtual machine, the behavior of the virtual machine and the files it operates on near the initial startup and backup times of the virtual machine can be predicted to be more important.
[0041] Next, the priority module 380 can obtain the attributes of the file by accessing the file system 361 of the virtual machine file 360. As described above, the attributes of the file can include the size of the file, the owner ID of the file, the read, write, and execute permissions for accessing the file, the timestamp of the file (including the last change time of the inode, the last change time of the file content, the last access time of the file), the location of the file data block (e.g., offset address), the number of blocks, the I / O block size, the device number, etc. In some embodiments, one or more of the above attributes can be used to assign a priority to the file. For example, the timestamp of the file, more specifically, the last access time of the file, can be used to assign a priority to the file. Thus, the last access time of the file can be mapped to each interval of the time range described with reference to Figure 4C and the priority of the corresponding interval can be used as the priority of the file. For example, as Figure 4D shown, if the file Kern.log is accessed within the first interval (the first 30 minutes) after starting the virtual machine, the file Kern.log can be assigned a priority of 1, and if the file Libc.so is accessed within the second interval (30 minutes to 60 minutes) after starting the virtual machine, the file Libc.so can be assigned a priority of 2. Similarly, corresponding to the interval closer to the current time, the file App.journal can be assigned a priority of 1, the file App.dat can be assigned a priority of 2, and so on.
[0042] According to an embodiment of the present disclosure, priorities can be assigned to all files in all virtual machine files 360. Alternatively, priorities can be assigned only to files belonging to a part of the priority intervals (e.g., priorities 1 and 2) to reduce the computational load during backup. The priority module 380 can generate a metadata file 381 based on the attributes of the file obtained from the file system 361, and the metadata file 381 can include some or all of the above attributes of the file. For example, the metadata file 381 can include the file name, path, last access time, last change time of the file content, last access time of the file, etc. of all files in the virtual disk 360. The metadata file 381 can also be generated as a queryable file type, for example, a data block type file of SQLite DB, so that files that need to be assigned priorities can be simply obtained by querying and filtering the metadata file 381. For example, referring to Figure 4CAn example of the time range and priority shown. If it is necessary to query files assigned priority 1 and priority 2, files with the last access time within the first hour after the startup time of the virtual machine 330 and files with the last access time within one hour before the backup time can be queried. Although the embodiments of the present disclosure describe assigning priorities to files based on the last access time of the files, it should be understood that priorities can also be assigned to files based on one or more other attributes of the files.
[0043] Next, it is necessary to map the priority of the file to the priority of the data block. It should be understood that files are stored on a disk or any other non-volatile storage device. For a disk, the smallest storage unit is called a "sector". Each sector stores 512 bytes of data. When accessing a file, multiple consecutive sectors, i.e., "blocks", are read. For example, a block can include eight consecutive sectors (usually 4KB). As described above, the inode of the file system also stores the correspondence between the file and its data blocks, i.e., the location of the data blocks in the virtual disk (also referred to as the offset or offset address). The priority module 380 can access the inode by calling a system command (e.g., the Linux command debugfs) to obtain the location of the data blocks of the file. In some cases, a file is stored in multiple data blocks, so the locations of these data can be obtained. For example, using the Linux command debugfs –r "stat / path / to / file" / dev / sdxxx, the data block locations of the following exemplary file can be obtained:
[0044] (0 - 2047): 600064 - 602111,
[0045] (2048 - 6143): 618496 - 622591,
[0046] (6144 - 8191): 624640 - 626687,
[0047] ……
[0048] (18432 - 20210): 742952 - 744730
[0049] The number ranges in parentheses in the figure represent the logical addresses of the data blocks of the example file, and on the right are the offset addresses of the corresponding data blocks in the virtual file 360 (for the virtual machine 330, it is not necessarily the physical address in the physical storage device). Further, the priority of the already assigned file can be assigned to the data blocks of the file. Thus, the mapping from the priority of the file to the priority of the data block is achieved. For example, refer to Figure 4E, a schematic diagram showing data blocks assigned priorities is presented. Among them, block 101 may be a data block of a file with priority 1, block 120 may be a data block of a file with priority 2, and so on. It should be noted that although the present disclosure takes a disk or a virtual disk as an example of the specific implementation of the storage device 350, it should be understood that other types of non-volatile storage devices may also be used as the storage device 350.
[0050] In addition to assigning priorities to files and their data blocks based on time ranges and access times, priorities can also be assigned based on other attributes such as the type and path of the file or data block itself. In some embodiments, files such as scripts, configuration files, kernels, etc. that are necessary for the boot and startup of the virtual machine 330 and their data blocks can be assigned the highest priority, such as priority 0. According to an embodiment of the present disclosure, partition information data blocks, such as data blocks of the master boot record (MBR) and the globally unique identifier partition table (GPT), can be assigned the highest priority. Additionally, files in the boot partition, such as Grub.cfg, grubenv, vmlinuz-*, initrd.img-*, etc., can also be assigned the highest priority (correspondingly, their data blocks also have the highest priority). Additionally, it can also be specified that files under certain paths are assigned the highest priority. For example, in a Linux environment, it can be specified that files in the / etc directory are assigned the highest priority. Thus, in a similar manner, the priority module 380 can obtain the priorities of some or all of the data blocks in the virtual disk 360. Figure 4F A schematic diagram showing the priorities of data blocks according to an embodiment of the present disclosure is presented, which includes data blocks with the highest priority (priority 0).
[0051] Return Figure 3 , according to an embodiment of the present disclosure, the priority module 380 can generate a priority file 382 for recording the obtained indications of the priorities of the data blocks. The priority file 382 can record the indication of each priority and the location of its corresponding data block in the form of a table or any other way. In some embodiments, the indication of the priority and the offset address of the data block associated with it are stored in the priority file 382 in tabular form. Then, the priority file 382 can be transmitted to the storage server 370 together with the virtual disk 360. When it is necessary to restart the target virtual machine 330 and restore the service, the priority file 382 can be first transmitted back to the application server 310 and parsed to accelerate the recovery speed of the target virtual machine 330. This process will be described in detail below.
[0052] Although numbers such as priority levels 0, 1, 2, etc. are used in this document to represent the priorities of files and data blocks, where the smaller the number, the higher the priority, and priority level 0 represents the highest priority, these numbers and their magnitude relationships are merely examples and not limitations. It should be understood that any number of letters, symbols, numbers (alone or in combination) can be used to represent priorities and the relationships between them.
[0053] Figure 5 FIG. shows a schematic diagram of a computing system 500 for recovery according to an embodiment of the present disclosure. The computing system 500 includes an application server 510 and a storage server 570 that stores backup data of the application server 510. The application server 510 includes a virtual machine manager 520 and a storage device 550. A number of virtual machines can run on the virtual machine manager 520, and when the storage device 550 fails or for any other reason requires the restart of a virtual machine 530 (referred to as the target virtual machine), the target virtual machine 530 can be restarted by restoring backup data from the storage server 570. The virtual machine manager 520 also includes an agent 540 that is adapted to interact with components external to the virtual machine manager 520 for network communication and input / output device access of the virtual machine. The storage device 550 can be any non-volatile storage device capable of persistently storing data related to the virtual machine manager and virtual machines, such as virtual disks (e.g., virtual disk file formats in VMDK format), etc.
[0054] During recovery, the target virtual machine 530 can restart the virtual machine and resume services by loading data blocks 562 in the storage device 550. To recover the target virtual machine 530 from the storage server 570 more quickly, a priority module 580 is configured in the agent 540. In response to a command to recover the target virtual machine 530, the priority module 580 can receive the corresponding priority file 582 from the storage server 570 and parse it. As described above, the priority file 582 records, in tabular form, an indication of the priority of data blocks in the backup data and the offset addresses of the associated data blocks. The indication of priority represents the priority of recovering the data blocks from the storage server 570 to the storage device 550 in the application server 510. In other words, the agent 540 first receives data blocks with higher priority from the storage server 570. Once the data blocks are received from the storage server 570, the agent 540 can store these data blocks 562 in the storage device 550. As shown in the figure, the data blocks 562 drawn with solid lines represent the data blocks that have been transmitted and stored, and the data blocks 562 drawn with dashed lines represent the data blocks that have not been transmitted and stored. Then, the target virtual machine 530 can read the stored data blocks 562 from the storage device 550 to resume services. For example, the priority module 580 can first parse from the priority file 582 the offset addresses of a set of data blocks with priority 0 (highest priority), i.e., the storage locations of these data blocks, and then use the offset addresses to request all data blocks with priority 0 from the storage server 570. As described above, the data blocks with priority 0 can include partition information data blocks, data blocks of files in the boot partition, and other specified data blocks, etc. After obtaining and storing all data blocks with priority 0 from the storage server 570, the agent 540 can further request a second set of data blocks with priority 1, a third set of data blocks with priority 2, and so on from the storage server 570. In this way, the data blocks that are more important for recovery services in the backup data can be recovered first to restart the virtual machine and resume services more quickly.
[0055] It should be understood that the number of data blocks associated with any priority is not limited and can be one or more, or even 0, in which case the offset addresses of the data blocks corresponding to the priority can be skipped during parsing.
[0056] In addition, in some cases, although high-priority data blocks are obtained from the storage server 570 earlier by the priority module 580, the target virtual machine may need data blocks that have not yet been restored to the storage device 550 during the recovery service. In this case, the target virtual machine 530 can request these data blocks from the agent 540, and then the agent 540 requests these data blocks from the storage server 570. This request has a higher priority than the currently transferred data blocks to obtain the data blocks from the storage server 570 as early as possible to meet the needs of the target virtual machine 530. In other words, the agent 540 can receive a request for a data block from the target virtual machine 530, insert it in front of the priority-based data block transfer queue, and directly send it to the target virtual machine and store it in the storage device 550 after obtaining the data block requested by the target virtual machine 530. After completing the above operations, the agent 580 continues to receive data blocks from the storage server 570 according to the indication of the priority of the data blocks provided by the priority file 582 and stores them in the storage device 550.
[0057] Figure 6 FIG. shows a schematic diagram of a computing system 600 for recovery according to another embodiment of the present disclosure. Compared with Figure 5 , the computing system 600 further includes a virtual machine input / output (VM I / O) control module 690. The virtual machine I / O control module 690 can be used to filter I / O requests of the virtual machine for the virtual disk to reduce additional I / O overhead. In some embodiments, the I / O requests generated by the virtual machine 630 need to be processed by the virtual machine I / O control module 690 before being submitted to the I / O device, such as the storage device 650.
[0058] According to an embodiment of the present disclosure, the process of receiving data blocks from the storage server 670 by the priority module 680 using the priority file 682 from the storage server 670 and according to the indication of the priority of the data blocks recorded in the priority file 682 and storing them in the storage device 650 is similar to the process described with reference to Figure 5 . In Figure 6In the example shown, the target virtual machine 630 to be restored can obtain the required data blocks with the help of the virtual machine I / O control module 690. The virtual machine I / O control module 690 can create and store a block table 692 for the virtual disk 660. The block table 692 is used to store index information of the data blocks that have been stored in the storage device 650 (including but not limited to, the offset address of the data block in the virtual disk or its hash, the identifier of the data block, the hash of the data block, etc.). That is to say, the block table 692 records information about which data blocks have been restored from the storage server 570 to the local. By using the block table 692, the target virtual machine 530 can query whether the storage device 650 has the requested data block before the I / O request is sent to the storage device 650, thereby avoiding invalid I / O requests to the storage device 650 when the storage device 650 does not have the requested data block.
[0059] According to an embodiment of the present disclosure, when the target virtual machine 630 starts up, the block table 692 can be initialized to be empty. Then, the target virtual machine 630 reads data blocks from the virtual disk 660 of the storage device 650 via the block table 692 of the virtual machine I / O control module 690, and the process will be described in detail below.
[0060] First, the agent 640 can execute the priority module 580 in response to the target virtual machine 530 about to start up, receive a priority file 682 related to the virtual disk of the target virtual machine 630 from the storage server 670, and parse it. The priority file 682 records an indication of the priority of the data blocks in the backup data. The indication of the priority represents the priority of restoring the data blocks from the storage server 670 to the storage device 650 in the application server 610. In other words, the agent 640 will first receive the data blocks with higher priority from the storage server 670. Once the data blocks are received from the storage server 670, the agent 640 records the index information of these data blocks 662 in the block table 692 via the virtual machine I / O control module 690, and stores the data blocks 662 in the storage device 650. As shown in the figure, the data blocks 662 in the solid line box are used to indicate the data blocks that have been transmitted and stored, and the data blocks 662 in the dashed line box are used to indicate the data blocks that have not been transmitted and stored.
[0061] Meanwhile, the target virtual machine 630 can generate I / O requests for data blocks in the storage device 650 and send the I / O requests to the virtual machine I / O control module 690. Then, the virtual machine I / O control module 690 processes the I / O requests by querying the block table 692. If the data block is found in the block table 692, that is, the data block has been restored and stored in the storage device 650 local to the application server 610, then the data block can be read from the storage device 650; conversely, if the data block is not found in the block table 692, the virtual machine I / O control module 690 can redirect the I / O request to the proxy 640, and the proxy 640 requests the data block from the storage server 670. According to an embodiment of the present disclosure, the I / O request can be inserted in front of the data block transfer queue based on priority so as to obtain the data block from the storage server 670 as early as possible. Similarly, after the data of the I / O request is received by the proxy 640, the index information of the data block is recorded in the block table of the virtual machine I / O control module 690 to update the block table 692. The data block of the I / O request can be directly sent from the proxy 640 to the target virtual machine 630, or can be obtained by the target virtual machine 630 again through an I / O request after being stored in the storage device 650.
[0062] Figure 7 FIG. shows a schematic flowchart of a method 700 for backup according to an embodiment of the present disclosure. The method 700 can be implemented by, for example, a cloud computing device for backing up data from a first storage device to a second storage device. The first storage device can be a non-volatile storage device (such as a disk, a solid-state drive, an SD card, etc.) and can be an input / output (I / O) device of the computing device as described above, for example, any one of the storage devices 150, 250, 350, 550, 650. The second storage device can be, for example, a distributed large-capacity cloud storage infrastructure or a data warehouse provided by a storage service provider, for example, any one of the storage servers 170, 270, 370, 570, 670.
[0063] The method 700 includes, in step 710, determining the priority of data blocks associated with at least one file based on the attributes of at least one file included in the data to be backed up. In step 720, storing the data to be backed up and an indication of the determined priority of the data blocks in the second storage device.
[0064] Through the method 700, when backing up data, it is possible to determine the data blocks that are more important for recovery for faster recovery of the backed-up data in the future.
[0065] In some embodiments, the data to be backed up may be included in a virtual machine disk device. For example, the data to be backed up may be stored in the VMDK format, so that the data therein can be read and written in units of data blocks, where each data block has its own location or offset address. In some embodiments, method 700 may further include generating a metadata file including the attributes of at least one file using the file system of the virtual disk device. As described above, the metadata records the attributes of the files in the virtual disk device, such as the size of the file, the owner ID of the file, the read, write, and execute permissions for accessing the file, the time stamps of the file (including the last change time of the inode, the last change time of the file content, the last access time of the file), the location of the file data blocks, the number of blocks, the I / O block size, the device number, and so on.
[0066] These attributes can be used to determine the priorities of the files and the associated data blocks. In some embodiments, the attributes include the access time of at least one file, and determining the priorities of the data blocks associated with at least one file may include: determining the boot time and the current time of the machine where the data to be backed up is located; and if it is determined that the first access time of the first file associated with the first data block is closer to the boot time than the second access time of the second file associated with the second data block, or it is determined that the first access time is closer to the current time than the second access time, determining that the first data block has a higher priority than the second data block. The access time of a file being close to the boot time or the current time of the virtual machine indicates that the file has a higher importance. Therefore, the data blocks of the file can be assigned a higher priority.
[0067] The entire time interval from the boot time to the current time can be divided into multiple intervals to determine the importance of the files and their data blocks. In some embodiments, determining the priorities of the data blocks associated with at least one file may include: dividing the time from the boot time to the current time into multiple time intervals, determining that the first access time is within the first time interval and the second access time is within the second time interval; if it is determined that the first time interval is closer to the boot time than the second time interval, or it is determined that the first time interval is closer to the boot time than the second time interval, determining that the first data block has a higher priority than the second data block. By dividing the time interval into multiple discrete intervals, it is beneficial to assign corresponding priorities to the files. For example, the priorities can be made to correspond to these time intervals, and the time intervals can be used as the priorities of the files.
[0068] In addition, considering the accessed files to determine the priority of files, the priority of files can also be determined according to attributes such as the type or storage location of the files. In some embodiments, determining the priority of data blocks associated with at least one file may include: if it is determined that the third data block is associated with the startup file of the machine where the data to be backed up is located, setting the priority of the third data block to the highest priority. In other words, if the data block is a data block of the startup file, this data block is restored with the highest priority to speed up the restoration of the virtual machine.
[0069] After determining the priority of the data block, save the indication of the priority to the second storage device. In some embodiments, storing the indication of the priority of the data block to the second storage device may include: storing the indication of the priority of the data block and the offset address of the data block in an associated manner to the second storage device. Thereby, the storage location of the data block can be obtained by parsing the indication of the priority, so as to request these data blocks when restoring the backup data.
[0070] In some embodiments, the indication of the priority and the offset address are stored in tabular form. The table can be stored as a queryable database file, which is conducive to efficient parsing.
[0071] Figure 8 FIG. shows a schematic flowchart of a recovery method 800 according to an embodiment of the present disclosure. The method 800 can be implemented by, for example, a cloud computing device to restore the backed-up data from the second storage device to the first storage device, so as to restore services when, for example, the cloud computing device fails. The first storage device can be a non-volatile storage device (such as a disk, a solid-state drive, an SD card, etc.), and can be an input / output (I / O) device of the cloud computing device as described above, for example, any one of the storage devices 150, 250, 350, 550, 650. The second storage device can be, for example, a distributed large-capacity cloud storage infrastructure or a data warehouse provided by a storage service provider, for example, any one of the storage servers 170, 270, 370, 570, 670.
[0072] The method 800 includes, in step 810, receiving from the second storage device a first priority indication and a second priority indication related to the data to be restored, the first priority being associated with a first set of data blocks, the second priority being associated with a second set of data blocks, and the first priority being higher than the second priority. It should be understood that the first set of data blocks may include one or more data blocks, and the second set of data blocks may also include one or more data blocks, and the number of data blocks in each set of data blocks is not limited. The method 800 further includes, in step 820, receiving the first set of data blocks from the second storage device. The method 800 further includes, in step 830, after completing the reception of the first set of data blocks, receiving the second set of data blocks from the second storage device.
[0073] According to method 800, when restoring backup data from a second storage device, it is possible to preferentially receive data blocks that are more important for restoration, for example, data blocks with higher priorities, thereby accelerating the restoration speed.
[0074] In step 810, it is possible to receive a priority file from the second storage device and parse the priority file to obtain an indication of the priorities of the data blocks. The priority file may include the priorities of the data blocks as shown in Figure 4F For example, the indication of the first priority is 0, and the associated data blocks include block 0, block 1, etc., the indication of the second priority is 1, and the associated data blocks include block 101, block 5000, and so on. As another example, regarding the priorities of the data blocks shown in 4F, first receive block 0 and block 1 with the highest priority 0 from the second storage device (as described above, the most important data blocks including partition information and startup configuration files), and then receive block 101, block 5600, etc. with a priority of 1. These data blocks are less important than block 0 and block 1, but may be urgently needed for the restoration service and are usually accessed earlier after starting the virtual machine or were accessed before the backup, and so on. Thus, the data to be restored can be received from the second storage device in order of decreasing priority or importance to accelerate the restoration.
[0075] In some embodiments, method 800 may further include: determining a first set of offset addresses for a first set of data blocks; and using the first set of offset addresses to request the first set of data blocks from the second storage device, and similarly, determining a second set of offset addresses for a second set of data blocks and using the second set of offset addresses to request the second set of data blocks from the second storage device. For example, the priority file as described above may include priority indications stored in tabular form and the offset addresses of the corresponding data blocks. The offset addresses of the associated data blocks can be queried from the priority file using the priority indications, and then, these offset addresses can be included in the restoration request and sent to the second storage device. In response, receive the requested data blocks from the second storage device.
[0076] The received data blocks will be stored locally, for example, in a first storage device. The first storage device may be a non-volatile storage device, such as a disk, a solid-state drive, an SD card, etc. The virtual machine after startup can access the data blocks stored in the first storage device through input / output (I / O) requests to restore the service.
[0077] In some embodiments, method 800 may further include storing the data blocks received from the second storage device in the first storage device; and recording the stored data blocks in a data block table at the first storage device. By recording the stored data blocks in the data block table, access to the first storage device can be controlled or filtered, improving the performance of the cloud computing device.
[0078] In some embodiments, method 800 may further include determining a data block to be read; and if the data block is recorded in the data block table, accessing the data block from a first storage device, otherwise requesting the data block from a second storage device. By using the data block table, it is possible to determine whether the requested data block exists in the first storage device before an access request for the first storage device is sent to the first storage device, thereby avoiding an invalid request to the first storage device when the first storage device does not have the requested data block.
[0079] Figure 9 An example processing platform including a cloud infrastructure 900 in accordance with an embodiment of the present disclosure is shown. The cloud infrastructure 900 includes a combination of physical and virtual processing resources, which can be used to implement any one of the computing systems 100 - 300, 500 - 600 as described in the embodiments of the present disclosure. The cloud infrastructure 900 includes a plurality of virtual machines (VMs) and / or container groups 902-1, 902-2... 902-L implemented using a virtualization infrastructure 904. The virtualization infrastructure 904 runs on top of a physical infrastructure 905 and may include one or more virtual machine managers and / or operating system-level virtualization infrastructure. The operating system-level virtualization infrastructure may include kernel control groups of a Linux operating system or other types of operating systems.
[0080] The cloud infrastructure 900 further includes a set of applications 910-1, 910-2... 910-L. These applications run on the respective VM / container groups among the VM / container groups 902-1, 902-2... 902-L under the control of the virtualization infrastructure 604. The virtual machine / container groups 902 may include respective VMs, respective container groups including one or more containers, or respective one or more container groups running in VMs.
[0081] In Figure 9 In some of the illustrated embodiments, the VM / container groups 902 may include respective VMs implemented using a virtualization infrastructure 604 including at least one virtual machine manager. An example of a virtual machine platform that can be used to implement a virtual machine manager within the virtualization infrastructure 604 is which may have an associated virtual infrastructure management system, such as The underlying physical machine may include one or more distributed processing platforms, which include one or more storage systems.
[0082] In Figure 9In the illustrated embodiment, the VM / container set 902 may include corresponding containers implemented using the virtualization infrastructure 604, which provides operating system-level virtualization capabilities, such as support for Docker containers running on a bare-metal host or Docker containers running on a VM. The containers are exemplarily implemented using the respective kernel control groups of the operating system.
[0083] Figure 10 FIG. shows a schematic block diagram of a device 1000 that may be used to implement embodiments of the present disclosure. The device 1000 may be used to implement the application servers 100-300, 500-600 described above with reference to the accompanying drawings. As shown, the device 1000 includes a central processing unit (CPU) 1001, which may execute various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 1002 or computer program instructions loaded from a storage unit 1008 into a random access memory (RAM) 1003. In the RAM 1003, various programs and data required for the operation of the device 1000 may also be stored. The CPU 1001, ROM 1002, and RAM 1003 are connected to each other via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.
[0084] A plurality of components in the device 1000 are connected to the I / O interface 1005, including: an input unit 1006, such as a keyboard, mouse, etc.; an output unit 1007, such as various types of displays, speakers, etc.; a storage unit 1008, such as a disk, optical disc, etc.; and a communication unit 1009, such as a network card, modem, wireless communication transceiver, etc. The communication unit 1009 allows the device 1000 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.
[0085] Each of the methods or processes described above may be executed by the processing unit 1001. For example, in some embodiments, the method may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 1008. In some embodiments, part or all of the computer program may be loaded and / or installed onto the device 1000 via the ROM 1002 and / or the communication unit 1009. When the computer program is loaded into the RAM 1003 and executed by the CPU 1001, one or more steps or actions of the methods or processes described above may be executed.
[0086] In some embodiments, the methods and processes described above may be implemented as a computer program product. The computer program product may include a computer-readable storage medium having thereon computer-readable program instructions for performing various aspects of the present disclosure.
[0087] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example—but not limited to—an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device, such as a punched card or raised structures in grooves storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage medium used herein is not construed as being an instantaneous signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.
[0088] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices, or can be downloaded to an external computer or an external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include a copper transmission cable, an optical fiber transmission, a wireless transmission, a router, a firewall, a switch, a gateway computer, and / or an edge server. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in each computing / processing device.
[0089] The computer program instructions for performing the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine - related instructions, microcode, firmware instructions, state - setting data, or source code or object code written in any combination of one or more programming languages, including object - oriented programming languages and conventional procedural programming languages. The computer - readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as a stand - alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network - including a local area network (LAN) or a wide area network (WAN) - or, alternatively, may be connected to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, by using the state information of the computer - readable program instructions to customize an electronic circuit, such as a programmable logic circuit, a field - programmable gate array (FPGA), or a programmable logic array (PLA), the electronic circuit can execute the computer - readable program instructions to implement various aspects of the present disclosure.
[0090] These computer - readable program instructions can be provided to the processing unit of a general - purpose computer, a special - purpose computer, or other programmable data - processing apparatus to produce a machine such that, when the instructions are executed by the processing unit of the computer or other programmable data - processing apparatus, a device is produced that implements the functions / actions specified in one or more blocks of the flowchart and / or block diagram. The computer - readable program instructions can also be stored in a computer - readable storage medium, and these instructions cause a computer, a programmable data - processing apparatus, and / or other devices to operate in a particular manner, so that the computer - readable medium storing the instructions includes a manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.
[0091] The computer - readable program instructions can also be loaded onto a computer, other programmable data - processing apparatus, or other devices such that a series of operation steps are executed on the computer, other programmable data - processing apparatus, or other devices to produce a computer - implemented process, so that the instructions executed on the computer, other programmable data - processing apparatus, or other devices implement the functions / actions specified in one or more blocks of the flowchart and / or block diagram.
[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a part of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur in a different order than noted in the accompanying drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified functions or actions, or may be implemented by a combination of dedicated hardware and computer instructions.
[0093] The embodiments of the present disclosure have been described above. The above description is exemplary and not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations are obvious to those of ordinary skill in the art in the technical field without departing from the scope and spirit of the described embodiments. The selection of the terms used herein is intended to best explain the principles of the embodiments, the practical application, or the technical improvement of the technology in the market, or to enable other ordinary skill in the art in the technical field to understand the embodiments disclosed herein.
Claims
1. A method for backup, comprising: Determine the priority of data blocks associated with at least one file among one or more files included in the data to be backed up, where data blocks associated with the same file among the at least one file have the same priority; And Store the data to be backed up and the indication of the priority of the determined data blocks in a second storage device, where storing the indication of the priority of the determined data blocks in the second storage device includes: Associatively store the indication and the offset address of the data block in the second storage device.
2. The method according to claim 1, wherein the data to be backed up is included in a virtual disk device, and the method further comprises: Generate a metadata file including the attributes of the at least one file using the file system of the virtual disk device.
3. The method according to claim 1, wherein the attribute includes the access time of the at least one file, and determining the priority of the data block associated with the at least one file comprises: Determine the startup time and the current time of the machine where the data to be backed up is located; And If it is determined that the first access time of a first file associated with a first data block is closer to the startup time than the second access time of a second file associated with a second data block, or if it is determined that the first access time is closer to the current time than the second access time, determine that the first data block has a higher priority than the second data block.
4. The method according to claim 3, wherein determining the priority of the data block associated with the at least one file comprises: Divide the time period from the startup time to the current time into multiple time intervals, Determine that the first access time is within a first time interval and the second access time is within a second time interval; If it is determined that the first time interval is closer to the startup time than the second time interval, or if it is determined that the first time interval is closer to the current time than the second time interval, determine that the first data block has a higher priority than the second data block.
5. The method according to claim 1, wherein determining the priority of the data block associated with the at least one file comprises: If it is determined that a third data block is associated with the startup file of the machine where the data to be backed up is located, set the priority of the third data block to the highest priority.
6. The method according to claim 1, wherein the indication and the offset address are stored in a table form.
7. A method for recovery, comprising: Receive from the second storage device an indication of a first priority and an indication of a second priority related to data to be restored, where the first priority is associatively stored with a first set of offset addresses of a first set of data blocks in the second storage device, the second priority is associatively stored with a second set of offset addresses of a second set of data blocks in the second storage device, and the first priority is higher than the second priority, where the first set of data blocks is for restoring a first file and the second set of data blocks is for restoring a second file; Receive the first set of data blocks from the second storage device; After completing the reception of the first set of data blocks, receive the second set of data blocks from the second storage device; Determine the first set of offset addresses of the first set of data blocks; Request the first set of data blocks from the second storage device using the first set of offset addresses; Determine the second set of offset addresses of the second set of data blocks; And Request the second set of data blocks from the second storage device using the second set of offset addresses.
8. The method according to claim 7, further comprising: Store the data blocks received from the second storage device in a first storage device; And Record the stored data blocks in a data block table at the first storage device.
9. The method according to claim 8, further comprising: Look up the data block to be accessed in the data block table; And If the data block to be accessed is recorded in the data block table, access the data block to be accessed from the first storage device; otherwise, request the data block to be accessed from the second storage device.
10. A computing device, comprising: At least one processing unit; At least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions when executed by the at least one processing unit cause the computing device to perform the method according to any one of claims 1 to 6 or 7 - 9.
11. A non-transitory computer storage medium, comprising machine-executable instructions that, when executed by a device, cause the device to perform the method according to any one of claims 1 to 6 or 7 - 9.
12. A computer program product, comprising machine-executable instructions that, when executed by a device, cause the device to perform the method according to any one of claims 1 to 6 or 7 - 9.
Citation Information
Patent Citations
A virtual machine backup and storage management method based on content analysis
CN108984343A
Method, system, and program for maintaining backup copies of files in a backup storage device
US20030177324A1