Backup data quick recovery method and device based on FUSE system

Abstract

The invention discloses a fast backup data recovery method based on a FUSE system, which comprises the following steps of: in response to an operation result of completion of current version backup of a data block, obtaining a version backup abstract file; according to the total information of each data block in the version backup abstract file, generating a recovery data block information table of the current version of each data block; receiving a recovery data reading request; searching a recovery data block information table of a recovery version number which is the same as the request recovery version number, and taking the recovery data block information table as a target recovery data block information table; obtaining a recovery data storage path; and reading the recovery data according to the recovery data storage path, and sending the read recovery data to the receiving platform according to the recovery data receiving path. According to the method, the low-efficiency operation of traversing, reading and writing complete disk data in a traditional recovery mode is avoided, and the recovery efficiency is remarkably improved. The invention further discloses a device for implementing the method, electronic equipment and a computer readable storage medium.

Description

Technical Field

[0001] The present invention relates to the technical field of server data management, and in particular to a method and device for quickly restoring backup data based on a FUSE system. Background Art

[0002] In the prior art, during the full disk backup of a block device, a dump file is usually generated by traversing the entire disk. The dump file is composed of data blocks and empty blocks. When performing incremental backup, corresponding differential files are generated based on the difference in data changes. These differential files are specifically used to store the original data overwritten by new data. Each time a full backup or incremental backup is performed, the system will generate corresponding summary files and differential files, where each incremental backup will generate a set of independent summary files and differential files. In addition, the bitmap file needs to be updated synchronously during the incremental backup process. In the data recovery stage, it is necessary to combine the dump file, summary file, differential file and bitmap file for overall recovery operations. Since the recovery process needs to process the entire disk, the recovery efficiency is low. Summary of the invention

[0003] In order to solve the above problems existing in the prior art, the present invention provides a method and device for fast recovery of backup data based on FUSE system. The technical problem to be solved by the present invention is achieved through the following technical solutions: A first aspect of an embodiment of the present invention provides a method for quickly restoring backup data based on a FUSE system, comprising the following steps: In response to the result of the operation of backing up the current version of the data block, obtaining a version backup summary file of the current version of the data block; Generate a recovery data block information table of the current version of each data block according to the full information of each data block in the version backup summary file; wherein the recovery data block information table includes: recovery version number, data block offset, file capacity, storage file name and compression level; Receive a read recovery data request; wherein the read recovery data request indicates a path of the backup virtual machine, a recovery data receiving path, and a requested recovery version number; Under the path of the backup virtual machine, searching for a recovery data block information table having a recovery version number that is the same as the requested recovery version number as the target recovery data block information table; Acquire a recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine; The recovery data is read according to the recovery data storage path, and the read recovery data is sent to the receiving platform according to the recovery data receiving path.

[0004] In one embodiment of the present invention, generating a restoration data block information table of the current version of each data block according to the full information of each data block in the version backup summary file includes: Determine whether the file capacity of the full information of each data block in the version backup summary file is 0; If yes, copy the version number and data block offset of the full information in the version backup summary file as the recovery version number and data block offset in the recovery data block information table, and configure other information in the recovery data block information table to 0; If not, copy the full information in the version backup summary file and add the full data storage file name as the recovery data block information table.

[0005] In one embodiment of the present invention, the step of acquiring the recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine includes: The recovery data storage path is acquired according to the recovery version number of the target recovery data block information table, the full data storage file name and the path of the backup virtual machine.

[0006] In one embodiment of the present invention, the method further includes: creating a cache file for storing write data under the recovery data receiving path.

[0007] A second aspect of an embodiment of the present invention provides a backup data fast recovery device based on a FUSE system, comprising: An acquisition module, configured to acquire a version backup summary file of the current version of the data block in response to a result of completing the operation of backing up the current version of the data block; A generation module, used to generate a recovery data block information table of the current version of each data block according to the full information of each data block in the version backup summary file; wherein the recovery data block information table includes: recovery version number, data block offset, file capacity, storage file name and compression level; A receiving module, configured to receive a request for reading and restoring data; wherein the request for reading and restoring data indicates a path of the backup virtual machine, a path for receiving restoration data, and a requested restoration version number; A search module, used to search for a recovery data block information table with a recovery version number that is the same as the requested recovery version number under the path of the backup virtual machine, as a target recovery data block information table; A determination module, configured to obtain a recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine; The reading module is used to read the recovery data according to the recovery data storage path, and send the read recovery data to the receiving platform according to the recovery data receiving path.

[0008] In one embodiment of the present invention, generating a restoration data block information table of the current version of each data block according to the full information of each data block in the version backup summary file includes: Determine whether the file capacity of the full information of each data block in the version backup summary file is 0; If yes, copy the version number and data block offset of the full information in the version backup summary file as the recovery version number and data block offset in the recovery data block information table, and configure other information in the recovery data block information table to 0; If not, copy the full information in the version backup summary file and add the full data storage file name as the recovery data block information table.

[0009] In one embodiment of the present invention, the step of acquiring the recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine includes: The recovery data storage path is acquired according to the recovery version number of the target recovery data block information table, the full data storage file name and the path of the backup virtual machine.

[0010] In one embodiment of the present invention, the method further includes: creating a cache file for storing write data under the recovery data receiving path.

[0011] A third aspect of an embodiment of the present invention provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, a method for quickly restoring backup data based on a FUSE system provided by the first aspect of an embodiment of the present invention is implemented.

[0012] A fourth aspect of an embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, a method for quickly restoring backup data based on a FUSE system provided by the first aspect of an embodiment of the present invention is implemented.

[0013] Beneficial effects of the present invention: The present invention generates a recovery data block information table for each version based on the full information in the version backup summary file generated when backing up each version of data, integrates the information of the backup data, and when it is necessary to read the recovery data, the storage path of the data to be recovered can be determined by querying the information in the recovery data block information table, so that the data to be recovered can be read. The present invention avoids the inefficient operation of traversing and reading and writing the complete disk data in the traditional recovery method, significantly improves the recovery efficiency, especially when processing large-scale data, improves the processing efficiency.

[0014] At the same time, it ensures that the recovery operations of different users do not interfere with each other. Different users generate their own recovery data block information tables for the same database recovery data, and the recovery operations between them are not affected.

[0015] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures particularly pointed out in the written description, claims, and drawings.

[0016] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings: Figure 1 A flowchart of a method for quickly restoring backup data based on a FUSE system provided by an embodiment of the present invention; Figure 2 A block diagram of a FUSE-based fast recovery device for backup data provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0018] The present invention is further described in detail below with reference to specific embodiments, but the embodiments of the present invention are not limited thereto.

[0019] like Figure 1 As shown, a first aspect of an embodiment of the present invention provides a method for quickly restoring backup data based on a FUSE system, comprising the following steps: Step 11: in response to the result of the operation of backing up the current version of the data block, obtaining a version backup summary file of the current version of the data block.

[0020] Step 12: Generate a recovery data block information table of the current version of each data block according to the full information of each data block in the version backup summary file.

[0021] The restored data block information table includes: the restored version number, the data block offset, the file capacity, the storage file name and the compression level.

[0022] Step 13: Receive a request to read and restore data.

[0023] The read recovery data request indicates the path of the backup virtual machine, the recovery data receiving path and the requested recovery version number.

[0024] Step 14: Under the path of the backup virtual machine, search for a recovery data block information table with the same recovery version number as the requested recovery version number as the target recovery data block information table.

[0025] Step 15: Obtain the recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine.

[0026] Step 16, reading the recovery data according to the recovery data storage path, and sending the read recovery data to the receiving platform according to the recovery data receiving path.

[0027] In this embodiment, a recovery data block information table for each version is generated based on the full information in the version backup summary file generated when backing up each version of the data, and the information of the backup data is integrated. When it is necessary to read the recovery data, the storage path of the data to be recovered can be determined by querying the information in the recovery data block information table, so that the data to be recovered can be read, avoiding the inefficient operation of traversing and reading and writing the entire disk data in the traditional recovery method, significantly improving the recovery efficiency, especially when processing large-scale data, improving the processing efficiency.

[0028] At the same time, it ensures that the recovery operations of different users do not interfere with each other. Different users generate their own recovery data block information tables for the same database recovery data, and the recovery operations between them are not affected.

[0029] Based on the first aspect of the embodiment of the present invention, the second aspect of the embodiment of the present invention further illustrates the method of the present invention.

[0030] Before backing up data, create a backup root directory / storage. All files generated during the following backup are in this directory. During the backup, create a backup subdirectory and generate directories such as 0, 1, 2... in this directory, representing version 0, version 1, and version 2, respectively storing the backup data and other related files of each backup, so that the corresponding version path can be easily obtained through string concatenation during subsequent reading.

[0031] Backup: First, back up data based on virtual machine snapshots. Whether it is incremental or full backup, it is backed up in blocks. Compression is also based on block compression, which makes it easy to obtain data blocks through count values. For example, the offset of the 0th block is 0* block_size, and the offset of the first block is 1* block_size. During the backup, a dump file (full data file) and a digest disk backup summary file (recording information about all blocks) will be generated. If it is an incremental backup, a differential diff file needs to be generated (to save the block data before the change, that is, the data of the previous version), and all differential data block information must be recorded in the differential file to the digest file. The structure of the digest file is as follows: Digest: 0 -- dump --<version, offset, size, compress> --diff --size=2 --<version1, offset, size, compress> --<version2, offset, size, compress> 1 -- dump --<version, offset, size, compress> --diff --size = 1 --<version1, offset, size, compress> 2 -- dump --<version, offset, size, compress> --diff --size = 2 --<version1, offset, size, compress> --<version2, offset, size, compress> ..... in,<version1, offset, size, compress> In the table, version indicates the version number, offset indicates the offset, size indicates the file capacity, and compress indicates the compression level. 0, 1, 2... respectively indicate the block numbers. Each block has only one dump record, but there may be multiple diff file records of length size. For example, if size=2, there are two diff file records. The digest file will be updated for each backup. If the block has not changed, just copy the block record and modify the version number of the dump information. If there is a change, update the dump block information and add a diff record to indicate that this version of the block has changed compared to the previous version. The advantage of this is that no matter whether the backup data is in raw format, qcow2 format, or any other format of data structure, the backup information can be used to locate the specific location of any block, thereby improving recovery efficiency. This backup structure applies to both the last version and the first version of the full data.

[0032] Full backup: Create dump backup files and digest backup summary files, read backup data through the virtualization platform and transmit it to the backup server through the network, save all valid data blocks in the dump file, and keep the position of each block the same as the source disk. Record the dump block information in the digest file, that is, record a structure of<version,offset, size,compress> The dump information of the diff file is initialized to 0. Each subsequent incremental backup will overwrite the changed block data into the dump file and update each block information in the digest file, that is, keep the latest version of the dump backup file and digest file with the latest data.

[0033] Incremental backup: Get the changed block information from the cbt changed block table through the virtual platform. Before writing the changed block to the dump file, copy the data block at the changed block location from the dump file to the diff file, that is, copy the corresponding data of the changed block of the previous version to the diff file. Then overwrite the changed data block to the corresponding offset position of the dump file. Add a diff information record of this block to the digest file. For example, after a full backup, this block record is: Digest: 0 -- dump --<version = 0, offset = 0, size = 2097152,compress = 0> --diff --size = 0 Then the first incremental backup is updated as follows: Digest: 0 -- dump --<version = 1, offset = 0, size = 2097100, compress = 1> --diff --size = 1 --<version = 1, offset = 0, size = 2097152, compress = 0> That is, add a diff information <1, 0, 2097152, 0> record, which means that this block has changed in version 1. The data before the change (0 version data) is saved in the diff file of version 1. The offset in the diff file is 0, the size is 2097152 bytes, and it is not compressed. From the updated dump information, we can see that since this block of data has changed, it has been compressed into a data block of 2097100 bytes and stored in the dump file. The compression level is 1, that is, if this block is restored, it needs to be decompressed. Note that the version number of each data recorded in the diff is incremented, so that it can be easily found during subsequent traversal. If this block is deleted, the diff information of this block is also recorded, but the size in the dump information is modified to 0, which means that this block is an empty block in the current version. If the block before the change is an empty block, the size in the diff information can be assigned to 0. In short, each incremental digest data is the digest data before the merger, ensuring that the block information recorded in the digest file of the last version is the most complete. By reading the block information of the latest digest file, the specific position of each block data in any version can be located.

[0034] A second aspect of an embodiment of the present invention provides a method for quickly restoring backup data based on a FUSE system, comprising the following steps: Step 21 : in response to the result of the operation of backing up the current version of the data block being completed, obtaining a version backup summary file of the current version of the data block.

[0035] After a version of each data block is backed up, a version backup summary file of the current version is generated. The full information in the version backup summary file records the information of the data in the current version data block.

[0036] Step 22: Generate a recovery data block information table of the current version of each data block according to the full information of each data block in the version backup summary file.

[0037] The restored data block information table includes: the restored version number, the data block offset, the file capacity, the storage file name and the compression level.

[0038] The specific steps of step 22 include step 221 to step 223: Step 221, determine whether the file capacity of the full information of each data block in the version backup summary file is 0.

[0039] If the file capacity size in the full information is 0, it means that the current data block is empty in the current version. If size≠0, it means that the current data block is not empty.

[0040] Step 222, if the file capacity of the full information is 0, the version number and data block offset of the full information of the data block in the copy version backup summary file are used as the recovery version number and data block offset in the recovery data block information table, and other information in the recovery data block information table is configured to 0. The recovery data block information table is also called dbt (DataBlock Table).

[0041] Specifically, when the data block of the current version is empty, copy the full information of the data block, then set all information except the version number and data block offset to 0, and add the storage file name file, and file=0 as the recovery data block information table. For example, in the backup summary file dump--<version = 1, offset = 5, size = 0,compress = 0> , then the current data block record in the restored data block information table is<version = 1, offset = 5,size = 0, file = 0, compress = 0> The data block offset is the identifier of the data block.

[0042] Step 223, if the file capacity of the full information is not a data block of 0, the full information in the version backup summary file is copied, and the storage file name file is added as the recovery data block information table dbt. Among them, the value of the storage file name is the full data storage file name, that is, file = dump.

[0043] For example, the backup summary file is dump--<version = 1, offset = 5, size = 2097100,compress = 1> , then the current data block record in the restored data block information table is<version = 1, offset = 5,size = 2097100, file = dump, compress = 1> .

[0044] After the records of the data blocks in the version backup summary file are traversed, the dbt of the current version of each data block is obtained. Each time a version is backed up, a version of the dbt is generated, and the dbt of each version of each data block is obtained. All dbts can be merged according to the version. Each version corresponds to a dbt, and the information of each data block is recorded in one dbt.

[0045] When the dbt table is generated, it means that data recovery has been completed. You only need to read the data indicated in the dbt table. Since the fuse library is a user space file system, it provides various io interfaces, such as read and write system call interfaces. After implementing these interfaces, it can interact with the kernel. When the read and write system calls are made to the fuse mounted directory, these system calls will be intercepted by the fuse library, and then these interfaces will be called to read or write operations, thereby avoiding traversing and reading and writing the complete disk data during recovery, and realizing fast recovery of backup data.

[0046] The process of generating the dbt table is done in seconds because only the data block information is integrated and no large amount of data is restored. There is no decompression of data during the recovery process. After the restored virtual machine is started, the virtual platform will read the disk, call system functions such as wire and read to access the data, and pass it in.<offset,size> This parameter structure is used to access data. Since the disk file has been registered before, when the fuse matches the disk file to be accessed, it takes over the read and write io operations of the disk file. When reading the file, it finds the corresponding data through dbt and returns it. The data read by the virtual platform is the real disk data, that is, the backup data. When writing files, the idea of ​​copy-on-write is used. When reading files, the data will not be copied to the cache file. Only when writing data will the modified data be rewritten to the cache file.

[0047] The above steps can be used to restore a copy-on-write disk file. Since the original backup data file is not modified, it supports the simultaneous rapid restoration of different versions of the same backup data disk file. And the recovery time of each recovery task is in seconds.

[0048] Step 23, receiving a request for reading and resuming data. After receiving the request for reading and resuming data, the fuse program performs disk registration.

[0049] The read recovery data request indicates the path of the backup virtual machine, the recovery data receiving path and the requested recovery version number.

[0050] The nfs (Network File System) network file system is used to optimize the time-consuming file network transmission and large amounts of data IO operations during the recovery process. First, create a directory fuse_nfs in the backup environment as the mount directory of the fuse service. When accessing this directory, the IO operation will be taken over by the fuse service. At the same time, an actual directory is required to store virtual machine disks and related configuration files, so a directory named fuse_space is created. The lib-fuse library can export fuse_space to the fuse_nfs directory. When we start the fuse service, we actually operate the fuse_space directory when we operate the fuse_nfs directory. At the same time, add the fuse_nfs directory of the backup environment as the nfs storage directory of the virtual platform, and the virtual platform can export fuse_nfs to the local nfs directory. Now the virtual platform operates the local nfs directory, which is the fuse_space directory of the backup server. Create a new virtual machine for recovery based on this nfs storage directory. At this time, the virtual platform will directly create the virtual machine directory and the most important disk files in the fuse_space directory. Because the recovery is performed in the backup environment and fuse is required to take over the IO operation, the directory operated during subsequent recovery is the intermediate mount directory fuse_nfs.

[0051] Restore the virtual machine configuration information and other files directly to the fuse_nfs directory, and then the recovery program communicates with the fuse service. The recovery program transmits the virtual disk path, the path of the backup virtual machine to be restored, the version number to be restored and other information to the fuse program. The fuse program registers this disk. After registration, regardless of whether the original disk is empty or not, the original disk content is invalid, and the disk data is now taken over by the fuse service. At the same time, a cache file named cache is created in the recovery file to store the new data blocks after the disk is written. That is, after the recovery is completed, only the backup file can be read, and the written data will be written to the corresponding position in this file.

[0052] Step 24: Under the path of the backup virtual machine, search for a recovery data block information table with the same recovery version number as the requested recovery version number as the target recovery data block information table.

[0053] Here, a restoration data block information table dbt having the same restoration version number as the requested restoration version number is searched in the restoration data block information table according to the path of the backup virtual machine.

[0054] Step 25: Obtain the recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine.

[0055] In this step, the user can read the data in the target recovery data block information table as needed, so as to quickly obtain the required recovery data. The user finds the information of the data block in the target recovery data block information table according to the data block to be read, and splices the recovery data storage path according to the recovery version number and storage file name of the data block and the path of the backup virtual machine, and reads from the path and returns it to the user. The path of the backup virtual machine includes the backup root directory and the directory under the root directory.

[0056] In this example, / storage / back1 is the backup root directory and the next-level directory. The requested recovery version number is version 5. According to the parameters of the read interface, the record of the data block found in the target recovery data block information table is<version = 5,offset =10, size = 2097100, file = dump, compress = 1> , then the restored data storage path obtained by splicing is / storage / back1 / 5 / dump, which means that the data to be obtained is in the dump file of version 5. The file capacity size of the data block. If size=0, it means that the data block is currently an empty block in this recovery version and there is no need to query the subsequent file file. If size>0, it is necessary to query the corresponding file and restore the data by combining the corresponding multiple files.

[0057] Step 27, reading the recovery data according to the recovery data storage path, and sending the read recovery data to the receiving platform according to the recovery data receiving path.

[0058] In this step, the recovery data receiving path is also the path of the restored virtual machine, and the receiving platform is also the restored virtual machine.

[0059] Both read and write interfaces have offset and size parameters, and the offset can be used to locate the number of the starting data block. For example, the block size is 2, and the user performs a read operation. In the parameter, the offset offset=0, and the starting data block is the 0th block. Then the number of the ending block can be located by offset+size. For example, size=4 is the size of two blocks, and the ending block is the 1st block. Therefore, it is known that the 0th block and the 1st block need to be read. At this time, by looking up the records of the 0th block and the 1st block in the dbt table, the kernel read function is called normally to obtain the storage path and read the block data of the two blocks and merge them and return them to the user.

[0060] In a feasible implementation, after the dbt table is generated, the user can write data in the restored data block when operating the restored virtual machine. When performing a write operation, the data will be stored in the cache file cache. After the data is written, the data in the data block is updated to the written data. The written data is stored in the cache file cache, and the backup data will not be modified, which will not affect the backup data on the backup end. Specifically, after the data is written, the parameters of the write function are<offset ,size> According to this parameter, the data block to which the data is written and the location of the data block can be determined, and then the corresponding record in the dbt table is modified, that is, the value of file in the record of the corresponding data block in the dbt table is changed to cache, and the compression level is changed to 0. At this time, the data has been updated and the version number has no practical meaning, so the version number is changed to 0.

[0061] For example, taking the block size as 2, the parameters of the write function are<offset = 1, size = 5> First, read the offset to find that the starting data block to be modified is the 0th block. Through offset+size, we can know that the last data block is the 2nd block. Then we need to read the 0th, 1st and 2nd data blocks, and overwrite the second half of the 0th data block with the data to be written. The 1st and 2nd data blocks are all overwritten. Finally, write the 0th, 1st and 2nd blocks into the cache file, and update the dbt file. Update the offset of the 0th, 1st and 2nd blocks to the offset in the cache file, modify file to cache, and set the version number and compression level to 0. When reading these blocks again, we can read new data directly from the cache file. For example, the modified record of the 0th block is <0, 0, 2097152, cache, 0>. At this time, the data block has been recorded in the cache file, so the version value is meaningless, and its value must be 0 for the compression level.

[0062] like Figure 2 As shown, the third aspect of the embodiment of the present invention provides a backup data fast recovery device based on the FUSE system, including: An acquisition module 31 is used to acquire a version backup summary file of the current version of the data block in response to the result of the operation of completing the backup of the current version of the data block; A generating module 32 is used to generate a recovery data block information table of the current version of each data block according to the full information of each data block in the version backup summary file; wherein the recovery data block information table includes: recovery version number, data block offset, file capacity, storage file name and compression level; The receiving module 33 is used to receive a request for reading and restoring data; wherein the request for reading and restoring data indicates the path of the backup virtual machine, the path for receiving the restoration data, and the requested restoration version number; A search module 34 is used to search, under the path of the backup virtual machine, for a recovery data block information table having a recovery version number that is the same as the requested recovery version number, as a target recovery data block information table; A determination module 35, configured to obtain a recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine; The reading module 36 is used to read the recovery data according to the recovery data storage path, and send the read recovery data to the receiving platform according to the recovery data receiving path.

[0063] In one embodiment of the present invention, a recovery data block information table of the current version of each data block is generated according to the full information of each data block in the version backup summary file, including: Determine whether the file capacity of the full information of each data block in the version backup summary file is 0; If yes, the version number and data block offset of the full information in the copy version backup summary file are used as the recovery version number and data block offset in the recovery data block information table, and other information in the recovery data block information table is configured to 0; If not, copy the full information in the version backup summary file and add the full data storage file name as the recovery data block information table.

[0064] In one embodiment of the present invention, obtaining the recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine includes: Obtain the recovery data storage path according to the recovery version number of the target recovery data block information table, the full data storage file name, and the path of the backup virtual machine.

[0065] In one embodiment of the present invention, the method further includes: creating a cache file for storing write data under the recovery data receiving path.

[0066] A fourth aspect of an embodiment of the present invention provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, a method for quickly restoring backup data based on a FUSE system provided in the above embodiment of the present invention is implemented.

[0067] A fifth aspect of an embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of a method for quickly restoring backup data based on a FUSE system provided in the above embodiment of the present invention are implemented.

[0068] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0069] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware systems.

[0070] The method provided in the embodiment of the present invention can be applied to electronic devices. Specifically, the electronic device can be: a desktop computer, a portable computer, an intelligent mobile terminal, a server, etc. This is not limited here, and any electronic device that can implement the present invention belongs to the protection scope of the present invention.

[0071] As for the device / electronic device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0072] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (apparatus), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0073] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0074] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0075] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A method for fast recovery of backup data based on FUSE system, characterized in that: The following steps are involved: In response to the result of the operation of backing up the current version of the data block, obtaining a version backup summary file of the current version of the data block; Generate a recovery data block information table of the current version of each data block according to the full information of each data block in the version backup summary file; wherein the recovery data block information table includes: recovery version number, data block offset, file capacity, storage file name and compression level; Receive a read recovery data request; wherein the read recovery data request indicates a path of the backup virtual machine, a recovery data receiving path, and a requested recovery version number; Under the path of the backup virtual machine, searching for a recovery data block information table having a recovery version number that is the same as the requested recovery version number as the target recovery data block information table; Acquire a recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine; The recovery data is read according to the recovery data storage path, and the read recovery data is sent to the receiving platform according to the recovery data receiving path.

2. The method according to claim 1, characterized in that The step of generating a restoration data block information table of the current version of each data block according to the full information of each data block in the version backup summary file includes: Determine whether the file capacity of the full information of each data block in the version backup summary file is 0; If yes, copy the version number and data block offset of the full information in the version backup summary file as the recovery version number and data block offset in the recovery data block information table, and configure other information in the recovery data block information table to 0; If not, copy the full information in the version backup summary file and add the full data storage file name as the recovery data block information table.

3. The method according to claim 2, characterized in that The obtaining the recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine includes: The recovery data storage path is acquired according to the recovery version number of the target recovery data block information table, the full data storage file name and the path of the backup virtual machine.

4. The method according to claim 2, characterized in that The method further includes: creating a cache file for storing write data under the recovery data receiving path.

5. A fast recovery device for backup data based on FUSE system, characterized in that: include: An acquisition module, configured to acquire a version backup summary file of the current version of the data block in response to a result of completing the operation of backing up the current version of the data block; A generation module, used to generate a recovery data block information table of the current version of each data block according to the full information of each data block in the version backup summary file; wherein the recovery data block information table includes: recovery version number, data block offset, file capacity, storage file name and compression level; A receiving module, configured to receive a request for reading and restoring data; wherein the request for reading and restoring data indicates a path of the backup virtual machine, a path for receiving restoration data, and a requested restoration version number; A search module, used to search for a recovery data block information table with a recovery version number that is the same as the requested recovery version number under the path of the backup virtual machine, as a target recovery data block information table; A determination module, configured to obtain a recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine; The reading module is used to read the recovery data according to the recovery data storage path, and send the read recovery data to the receiving platform according to the recovery data receiving path.

6. The device according to claim 5, characterized in that The step of generating a restoration data block information table of the current version of each data block according to the full information of each data block in the version backup summary file includes: Determine whether the file capacity of the full information of each data block in the version backup summary file is 0; If yes, copy the version number and data block offset of the full information in the version backup summary file as the recovery version number and data block offset in the recovery data block information table, and configure other information in the recovery data block information table to 0; If not, copy the full information in the version backup summary file and add the full data storage file name as the recovery data block information table.

7. The device according to claim 5, characterized in that The obtaining the recovery data storage path according to the target recovery data block information table and the path of the backup virtual machine includes: The recovery data storage path is acquired according to the recovery version number of the target recovery data block information table, the full data storage file name and the path of the backup virtual machine.

8. The device according to claim 5, characterized in that Also includes: A cache file for storing write data is created under the recovery data receiving path.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method for quickly restoring backup data based on the FUSE system as described in any one of claims 1 to 4 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for quickly restoring backup data based on a FUSE system according to any one of claims 1 to 4 is implemented.

Images