Data recovery method and device, equipment, storage medium and product

Abstract

The invention discloses a data recovery method and device, equipment, a storage medium and a product, and relates to the technical field of database flash back, and the method comprises the steps: when a data recovery request of a user is received, decomposing a data recovery task in the data recovery request into a plurality of subtasks, executing the plurality of subtasks in parallel in the plurality of concurrent execution units; and performing incremental recovery on the compressed difference data corresponding to the plurality of subtasks in the plurality of concurrent execution units. Due to the fact that the data recovery task is decomposed into the multiple sub-tasks through the parallel processing technology, the sub-tasks are executed in the multiple concurrent execution units concurrently, and the recovery efficiency is greatly improved. In addition, through an increment recovery technology, only changed data since last snapshot needs to be recovered, and the whole data set does not need to be recovered. And the recovered data is compressed, so that the consumption of storage and computing resources is effectively reduced.

Description

Technical Field

[0001] This application relates to the technical field of database flashback, and in particular, to a data recovery method, apparatus, device, storage medium, and product. Background Art

[0002] Flashback is a function in a database management system that allows users to restore data to a previous state, mainly used for data recovery and rollback. Existing database flashback functions are mainly implemented by some well-known database systems. These systems provide functions for data recovery and rollback to handle accidental data deletion, incorrect operations, or system failures. For example, the Oracle database provides a series of flashback functions, including Flashback Query, Flashback Table, Flashback Drop, and Flashback Database. By maintaining historical information of data, it allows users to query the past data state, roll back incorrect operations, and recover accidentally deleted data.

[0003] However, in existing database flashback technologies, there are some significant drawbacks that limit their performance and efficiency in practical applications. Existing flashback technologies usually need to maintain a complete historical record of data so that it can be restored to any past state when needed. Although this method can provide a high recovery accuracy, it also results in a large consumption of storage space and computing resources. At the same time, existing flashback technologies take a long time for data recovery when dealing with a large amount of data or a high-concurrency environment. Summary of the Invention

[0004] The main purpose of this application is to provide a data recovery method, apparatus, device, storage medium, and product, aiming to solve the technical problems of large resource consumption and slow recovery speed in existing flashback technologies.

[0005] To achieve the above object, this application proposes a data recovery method, and the method includes:

[0006] When receiving a user's data recovery request, decomposing the data recovery task in the data recovery request into multiple subtasks, and parallelly executing the multiple subtasks in multiple concurrent execution units;

[0007] Performing incremental recovery on the compressed differential data corresponding to the multiple subtasks in multiple concurrent execution units.

[0008] In an embodiment, the step of when receiving a user's data recovery request, decomposing the data recovery task in the data recovery request into multiple subtasks, and parallelly executing the multiple subtasks in multiple concurrent execution units includes:

[0009] When receiving a data recovery request from a user, parse the data recovery request to obtain various dimensional information, and determine a data recovery task according to the various dimensional information;

[0010] Decompose the data recovery task into multiple subtasks according to system parameters at the data block or table level;

[0011] Allocate the multiple subtasks to be executed in parallel in multiple concurrent execution units.

[0012] In one embodiment, the step of performing incremental recovery on the compressed differential data corresponding to the multiple subtasks in multiple concurrent execution units includes:

[0013] Determine the compressed differential data corresponding to the multiple subtasks from a preset differential storage file of the database in multiple concurrent execution units according to timestamps and version numbers;

[0014] Decompress the compressed differential data, rewrite the decompressed differential data into the database, and perform incremental recovery on the decompressed differential data.

[0015] In one embodiment, before the step of decomposing the data recovery task in the data recovery request into multiple subtasks when receiving the data recovery request from the user, further includes:

[0016] Real-time capture the changed data in the database, and generate differential data according to the changed data;

[0017] Compress the differential data through a real-time compression algorithm, and store the compressed differential data in the database.

[0018] In one embodiment, the step of real-time capture the changed data in the database, and generate differential data according to the changed data includes:

[0019] Real-time capture the changed data in the database through a multi-level data capture mechanism;

[0020] Compare the data before and after the change in the database through a hash algorithm, identify the changed parts at the table level, row level, and column level respectively, and generate differential data according to the changed parts.

[0021] In one embodiment, the step of compressing the differential data through a real-time compression algorithm, and storing the compressed differential data in the database includes:

[0022] Determine the optimal real-time compression algorithm according to the type and change frequency of the differential data, and compress the differential data through the optimal real-time compression algorithm to obtain the compressed differential data;

[0023] Segment the compressed differential data according to multiple dimension information to obtain multiple segmented differential data;

[0024] Generate a version number, and store the multiple segmented differential data and the version number in a preset differential storage file in the database.

[0025] In addition, to achieve the above object, the present application also proposes a data recovery device, and the data recovery device includes:

[0026] A task decomposition module, configured to decompose the data recovery task in the data recovery request into multiple subtasks when receiving a user's data recovery request, and execute the multiple subtasks in parallel in multiple concurrent execution units;

[0027] An incremental recovery module, configured to perform incremental recovery on the compressed differential data corresponding to the multiple subtasks in multiple concurrent execution units.

[0028] In addition, to achieve the above object, the present application also proposes a data recovery device, and the device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the data recovery method as described above.

[0029] In addition, to achieve the above object, the present application also proposes a storage medium, and the storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium, and when the computer program is executed by a processor, it implements the steps of the data recovery method as described above.

[0030] In addition, to achieve the above object, the present application also provides a computer program product, and the computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps of the data recovery method as described above.

[0031] The present application provides a data recovery method. When receiving a user's data recovery request, the data recovery task in the data recovery request is decomposed into multiple subtasks, and the multiple subtasks are executed in parallel in multiple concurrent execution units; incremental recovery is performed on the compressed differential data corresponding to the multiple subtasks in the multiple concurrent execution units. Since the present application decomposes the data recovery task into multiple subtasks through parallel processing technology and executes them concurrently in multiple concurrent execution units, the recovery efficiency is greatly improved. The present application also uses incremental recovery technology, only needing to recover the changed data since the last snapshot, without having to recover the entire data set. Moreover, the recovered data is compressed, effectively reducing the consumption of storage and computing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The drawings herein are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present application and used together with the specification to explain the principles of the present application.

[0033] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0034] Figure 1 It is a schematic flowchart provided for the first embodiment of the data recovery method of the present application;

[0035] Figure 2 It is a schematic flowchart provided for the second embodiment of the data recovery method of the present application;

[0036] Figure 3 It is a schematic flowchart provided for the third embodiment of the data recovery method of the present application;

[0037] Figure 4 It is a schematic overall flowchart of the data recovery method of the present application;

[0038] Figure 5 It is a schematic module structure diagram of the data recovery device in the embodiments of the present application;

[0039] Figure 6 It is a schematic device structure diagram of the hardware operating environment involved in the data recovery method in the embodiments of the present application.

[0040] The implementation, functional features, and advantages of the objectives of the present application will be further described with reference to the embodiments and the drawings. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0041] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0042] To better understand the technical solution of this application, the following will be described in detail in conjunction with the accompanying drawings of the specification and specific implementation manners.

[0043] The main solution of the embodiment of this application is: when receiving a data recovery request from a user, decomposing the data recovery task in the data recovery request into multiple subtasks, and concurrently executing the multiple subtasks in multiple concurrent execution units; performing incremental recovery on the compressed differential data corresponding to the multiple subtasks in the multiple concurrent execution units.

[0044] In the existing database flashback technology, there are some significant drawbacks, which limit its performance and efficiency in practical applications. The existing flashback technology usually needs to maintain a complete historical record of data so that it can be restored to any past state when needed. Although this method can provide a high recovery accuracy, it also results in a large consumption of storage space and computing resources. At the same time, in the existing flashback technology, when dealing with a large amount of data or a high-concurrency environment, the data recovery time is relatively long.

[0045] This application provides a solution. When receiving a data recovery request from a user, decompose the data recovery task in the data recovery request into multiple subtasks, and concurrently execute the multiple subtasks in multiple concurrent execution units; perform incremental recovery on the compressed differential data corresponding to the multiple subtasks in the multiple concurrent execution units. Since this application uses parallel processing technology to decompose the data recovery task into multiple subtasks and concurrently execute them in multiple concurrent execution units, the recovery efficiency is greatly improved. This application also uses incremental recovery technology, only needs to recover the changed data since the last snapshot, without having to recover the entire data set. And the recovered data is compressed, effectively reducing the consumption of storage and computing resources.

[0046] It should be noted that the execution subject of the method in this embodiment can be a computing service device with functions of data recovery, network communication, and program running, such as a tablet computer, a personal computer, a mobile phone, etc.; it can also be a data recovery device with the same or similar functions, and a database management system is running on the data recovery device. This embodiment and the following embodiments will be described by taking the data recovery device as an example.

[0047] Based on this, the embodiment of this application provides a data recovery method, referring to Figure 1 , Figure 1 is a schematic flowchart of the first embodiment of the data recovery method of this application.

[0048] In this embodiment, the data recovery method includes steps S10 to S20:

[0049] Step S10, when receiving a data recovery request from a user, decompose the data recovery task in the data recovery request into multiple subtasks, and execute the multiple subtasks in parallel in multiple concurrent execution units.

[0050] It can be understood that this embodiment aims to improve resource utilization and speed up data recovery by optimizing the implementation of the database flashback function to meet the needs of large-scale data management and rapid recovery. It will be elaborated in detail mainly from two aspects: data storage optimization and recovery algorithm optimization. In the data recovery stage, when receiving a data recovery request from a user, in order to speed up the data recovery, the proposal adopts parallel processing technology. By decomposing the data recovery task into multiple subtasks and concurrently executing them in multiple concurrent execution units (such as threads or processes), the recovery efficiency is greatly improved. The implementation of parallel processing requires dynamically adjusting the degree of parallelism to ensure the efficient use of system resources. Through reasonable task decomposition and parallel execution framework, the speed and efficiency of the recovery operation can be significantly improved.

[0051] Step S20, perform incremental recovery on the compressed differential data corresponding to the multiple subtasks in multiple concurrent execution units.

[0052] It should be understood that in this embodiment, an incremental recovery technology is also introduced. Based on the incremental recovery method of differential storage, perform incremental recovery on the compressed differential data corresponding to multiple subtasks in multiple concurrent execution units. That is, only the changed data since the last snapshot needs to be recovered, rather than the entire data set. This method effectively reduces the amount of data to be recovered, thereby shortening the recovery time.

[0053] This embodiment provides a data recovery method. When receiving a data recovery request from a user, decompose the data recovery task in the data recovery request into multiple subtasks, and execute the multiple subtasks in parallel in multiple concurrent execution units; perform incremental recovery on the compressed differential data corresponding to the multiple subtasks in multiple concurrent execution units. Since this embodiment uses parallel processing technology to decompose the data recovery task into multiple subtasks and concurrently execute them in multiple concurrent execution units, the recovery efficiency is greatly improved. This application also uses incremental recovery technology, only the changed data since the last snapshot needs to be recovered, rather than the entire data set. And the recovered data is processed by compression, effectively reducing the consumption of storage and computing resources.

[0054] Based on the first embodiment of this application, in the second embodiment of this application, for the same or similar content as in the above-mentioned first embodiment, reference can be made to the above introduction and will not be elaborated hereinafter. On this basis, please refer to Figure 2 , Step S10, the data recovery method further includes steps S101 to S103:

[0055] Step S101: When receiving a data recovery request from a user, parse the data recovery request to obtain various dimension information, and determine a data recovery task according to the various dimension information.

[0056] It can be understood that when a user needs to recover data, the recovery request processing module receives the user's data recovery request through the RESTful API. The Representational State Transfer Application Programming Interface (RESTful API) is a software architecture style based on the HTTP protocol. The system parses various dimension information such as the time point, transaction ID, or specific table name in the data recovery request to determine the data range to be recovered, that is, to determine the data recovery task. After parsing the request, the system determines the specific recovery range based on the time point or transaction ID. For example, if the user specifies a certain time point, the system will search for the corresponding differential file and version information for subsequent accurate data recovery. This step ensures the accuracy of the recovery operation and provides an accurate data range for task decomposition.

[0057] Step S102: Decompose the data recovery task into multiple subtasks according to system parameters at the data block or table level.

[0058] It should be understood that in order to accelerate the data recovery speed, a corresponding task scheduling strategy needs to be designed, which is significantly different from the single-threaded or linear recovery methods of existing solutions. The system decomposes the recovery task into multiple subtasks according to the scale and complexity of the data, and dynamically allocates resources through the task scheduling module. The scheduling module will adjust the task decomposition and execution strategy in real time according to system parameters such as the current system load, available memory, and number of CPU cores to ensure the efficient use of system resources.

[0059] Step S103: Allocate the multiple subtasks to be executed in parallel in multiple concurrent execution units.

[0060] It can be understood that the parallel processing module can fully utilize the hardware performance in a multi-core Central Processing Unit (CPU) system by using a thread pool and a multi-process concurrency framework. Each subtask can be independently executed in a different thread or process. This design greatly improves the efficiency of data recovery. Especially when dealing with large-scale data, it can significantly shorten the recovery time. In contrast, existing solutions do not involve the application of parallel processing technology and have low recovery efficiency.

[0061] In this embodiment, to improve the efficiency of data recovery, when the system decomposes the recovery task into multiple subtasks, the task scheduling module dynamically adjusts the task decomposition strategy according to system parameters and data block or table levels. After the task decomposition is completed, the parallel processing module starts the recovery operation. Through the parallel framework, the recovery task is assigned to multiple concurrent execution units for parallel execution, thus making full use of system resources and significantly improving the recovery speed.

[0062] In a feasible embodiment, step S20 may include steps S201 to S202:

[0063] Step S201, determine the compressed differential data corresponding to the multiple subtasks from a preset differential storage file of the database according to timestamps and version numbers in multiple concurrent execution units.

[0064] It should be noted that in data recovery, only the data part that has changed since the last recovery or backup is extracted, rather than the full backup plus incremental log method in the existing solution. Through version numbers and timestamps, the system can accurately extract the compressed differential data corresponding to multiple subtasks from the preset differential storage file of the database. This method significantly reduces the workload of data extraction, avoids unnecessary data rereading, and improves the recovery speed. The data extraction module designs an optimized extraction strategy. For example, for frequently changed data, the module can batch extract and merge differential data of multiple versions to reduce repeated operations. For static data or data blocks with less changes, the module skips the extraction step and directly performs recovery.

[0065] Step S202, decompress the compressed differential data, rewrite the decompressed differential data back into the database, and perform incremental recovery on the decompressed differential data.

[0066] It can be understood that the extracted incremental data is compressed, so decompression is required during the recovery process. In this embodiment, multi-threaded decompression technology is adopted to restore the compressed data to its original state in the shortest time. At the same time, the system performs data integrity verification during decompression to ensure that the recovered data is consistent with the original data. This strategy effectively avoids the risk of data corruption or loss, in sharp contrast to the simple processing of data recovery in the existing solution.

[0067] It should be understood that the decompressed differential data will be written back to the database. To ensure the atomicity and consistency of data recovery, this embodiment introduces a transaction management mechanism. During the writing process, the system will perform independent transaction control on the data writing operations of each subtask to ensure that the data consistency will not be affected even in the case of parallel processing. At the same time, the system may batch submit the writing results of multiple subtasks, thereby reducing the number of transaction submissions and improving the writing performance.

[0068] It should be understood that when all subtasks complete data recovery, the system will automatically generate a detailed recovery report. This report not only records the execution status of each recovery step but also includes information such as the usage of system resources and recovery time. This information can help users evaluate the success rate of recovery and further optimize and adjust the system.

[0069] In this embodiment, multiple compressed differential data corresponding to multiple subtasks are determined from a preset differential storage file in the database according to timestamps and version numbers in multiple concurrent execution units; the compressed differential data is decompressed, and the decompressed differential data is rewritten to the database to perform incremental recovery on the decompressed differential data. During the entire recovery process, transaction management ensures the atomicity and consistency of data recovery.

[0070] In this embodiment, when the system decomposes the recovery task into multiple subtasks, the task scheduling module dynamically adjusts the task decomposition strategy according to system parameters and data block or table levels, improving the efficiency of data recovery. After the task decomposition is completed, the parallel processing module will start the recovery operation. Through the parallel framework, the recovery task is assigned to multiple concurrent execution units for parallel execution, thereby making full use of system resources and significantly improving the recovery speed. Through steps such as incremental data extraction, data decompression, and data writing operations in the incremental recovery process, transaction management ensures the atomicity and consistency of data recovery during the entire recovery process.

[0071] Based on the first embodiment of this application, in the third embodiment of this application, the same or similar content as the above-mentioned embodiment one can be referred to the above introduction and will not be repeated hereinafter. On this basis, please refer to Figure 3 , before step S10, the data recovery method further includes steps S01 to S02:

[0072] Step S01, capturing the changed data in the database in real time and generating differential data according to the changed data.

[0073] It is understandable that before data recovery, the database system needs to first store the data. When the data changes, the database monitoring module is responsible for capturing the data changes in real time. This step uses the database triggers, log monitoring or built-in functions to ensure that all changes are accurately recorded at the database engine level.

[0074] It should be understood that after capturing the data changes, the system will generate the delta. By comparing the data before and after the changes, the delta generation module uses the hash algorithm to identify the specific changed parts and generates the delta data.

[0075] In a feasible implementation manner, step S01 may include steps S011 to S012:

[0076] Step S011, capturing the changed data in the database in real time through a multi-level data capture mechanism.

[0077] It should be noted that in this implementation manner, a multi-level data capture mechanism is adopted. Through database triggers, real-time log monitoring and other means, it ensures the immediate capture of data changes. Different from the time point selection in the existing solutions, this implementation manner not only captures each change, but also quickly identifies the changed parts of the data through the trigger and records them in a specific log file. This way provides more refined control and can provide accurate basic data for subsequent delta generation.

[0078] Step S012, comparing the data before and after the changes in the database through the hash algorithm, identifying the changed parts at the table level, row level and column level respectively, and generating the delta data according to the changed parts.

[0079] It is worth noting that after capturing the data changes, this implementation manner introduces an accurate delta generation module. Different from the full backup method in the existing solutions, this implementation manner uses the hash algorithm to compare the differences before and after the data changes to generate the minimized delta data. This delta generation not only includes the data comparison at the table level, but also involves the in-depth comparison at the row and column levels to ensure that all minor data changes are captured. The generated delta data is immediately subjected to real-time compression processing, which is not involved in the existing solutions.

[0080] It is understandable that in order to optimize the generation efficiency of the delta data, the delta generation module adopts a hierarchical comparison strategy. First, calculate the hash value at the table level, and then perform a more fine-grained comparison at the row level or column level. This can not only quickly locate the location where the change occurs, but also reduce unnecessary data processing and further improve the delta generation efficiency.

[0081] In this embodiment, change data in the database is captured in real time through a multi-level data capture mechanism. The multi-level capture ensures that all changes are accurately recorded at the database engine level. By using a hashing algorithm to compare the differences in data before and after the change, minimized delta data is generated. This delta generation includes not only table-level data comparison but also in-depth column-level comparison to ensure that all minor data changes are captured.

[0082] Step S02, compress the delta data through a real-time compression algorithm and store the compressed delta data in the database.

[0083] It should be noted that after the delta data is generated, the system will immediately start the data compression module for real-time compression. The compressed delta data will be stored in a specific delta storage file. To improve storage efficiency and data access speed, a segmented storage structure is adopted, and version management is used to ensure data consistency and traceability.

[0084] In a feasible embodiment, step S02 may include steps S021 to S023:

[0085] Step S021, determine the optimal real-time compression algorithm according to the type and change frequency of the delta data, and compress the delta data through the optimal real-time compression algorithm to obtain the compressed delta data.

[0086] It can be understood that after the compression algorithm is selected to generate the delta data, the system will immediately start the compression module. The compression process selects the optimal compression algorithm based on the type and change frequency of the data, and then compresses the delta data through the optimal real-time compression algorithm to obtain the compressed delta data. Common compression algorithms include general compression algorithms such as Lempel-Ziv-Markovchain-4 (LZ4), Lempel-Ziv-Markov chain-Algorithm (LZMA), and Fast Compression And Decompression (Snappy). For frequently changed data, the system can select the faster LZ4; while for data with higher compression ratio requirements, compression algorithms such as LZMA are selected. This multi-level compression strategy ensures the best compression effect in the shortest time and further reduces the storage space occupation.

[0087] Step S022, segment the compressed delta data according to multiple dimension information to obtain multiple segmented delta data.

[0088] It should be understood that the differential data after compression in the segmented storage structure will be stored in a specific differential storage file. The storage module designs a segmented storage structure, which divides the differential data into multiple small segments according to multiple dimensional information such as time or transactions for storage. This segmented storage structure helps to improve the random access speed of data, and can also greatly improve the efficiency when batch reading is required.

[0089] Step S023, generate a version number, and store the multiple segmented differential data and the version number into a preset differential storage file in the database.

[0090] It should be noted that in order to ensure data consistency and traceability, the storage module is also responsible for version management of the differential storage file. Each time data is stored, the system assigns a version number to the data and records the detailed information of all changes. This method enables each data change to be accurately traced back to the corresponding differential file. Compared with the full backup method of the existing solution, this method not only reduces data storage redundancy, but also provides higher recovery flexibility and accuracy.

[0091] In this embodiment, after selecting the compression algorithm to generate the differential data, the system will immediately start the compression module. The compression process selects the optimal compression algorithm based on the data type and change frequency. This multi-layer compression strategy ensures the best compression effect in the shortest time and further reduces the storage space occupancy.

[0092] In this embodiment, in order to reduce the occupancy of storage space and improve the data writing speed, the differential storage technology is first introduced. By capturing and storing the changed parts of the data, replacing the existing full storage method, the storage requirements are significantly reduced. On this basis, the data compression algorithm is further introduced. By compressing the differential data to further reduce the occupancy of storage space.

[0093] Exemplarily, to help understand the implementation process of the data recovery method obtained by combining this embodiment with the above Embodiment 1, please refer to Figure 4 , Figure 4 which provides an overall flow schematic diagram of a data recovery method, specifically:

[0094] The core of this application includes two main modules: data change record and storage, and data recovery. These two modules respectively process the storage and recovery of data to meet the requirements of large-scale data management and fast recovery.

[0095] Among them, the data change record and storage module includes steps 1-4:

[0096] 1. Data Change Capture: When data changes occur, the database monitoring module in the system is responsible for capturing the data changes in real time. This step utilizes the database triggers, log monitoring, or built-in functions to ensure that all changes are accurately recorded at the database engine level.

[0097] 2. Delta Generation: After capturing the data changes, the system performs delta generation. By comparing the data before and after the changes, the delta generation module uses a hash algorithm to identify the specific changed parts and generates delta data.

[0098] 3. Data Compression: After generating the delta data, the system immediately starts the data compression module for real-time compression.

[0099] 4. Delta Data Storage: The compressed delta data will be stored in a specific delta storage file. To improve storage efficiency and data access speed, a segmented storage structure is adopted, and version management is used to ensure data consistency and traceability.

[0100] Among them, the data recovery module includes steps 5 - 12:

[0101] 5. Recovery Request Receiving: When the user needs to recover data, the recovery request processing module receives the user's request through the RESTful API. The system parses the time point or transaction ID in the request to determine the data range to be recovered.

[0102] 6. Recovery Task Decomposition: To improve the efficiency of data recovery, the system decomposes the recovery task into multiple subtasks. The task scheduling module dynamically adjusts the task decomposition strategy according to the system load and data block or table level.

[0103] 7. Parallel Recovery Processing: After the task decomposition is completed, the parallel processing module starts the recovery operation. Through a parallel framework of multi-threading or multi-processing, the recovery tasks are assigned to multiple threads or processes to execute in parallel, thus making full use of system resources and significantly improving the recovery speed.

[0104] 8. Incremental Data Extraction: During the recovery process, the data extraction module extracts the data part to be recovered from the delta storage file based on the timestamp and version number.

[0105] 9. Data Decompression: The extracted delta data is usually in a compressed state, and the decompression module is responsible for restoring it to the original data.

[0106] 10. Data Writing: The decompressed original data will be rewritten into the database to complete the data recovery operation.

[0107] 11. Recovery Completion Notification: When all subtasks are completed, the system automatically generates a recovery report, records the execution status of the recovery, and notifies the user of the completion of the recovery operation.

[0108] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the data recovery method of this application. Based on this technical concept, more forms of simple transformations are within the protection scope of this application.

[0109] This application also provides a data recovery device. Please refer to Figure 5 , and the data recovery device includes:

[0110] A task decomposition module 10, configured to decompose the data recovery task in the data recovery request into multiple subtasks when receiving a data recovery request from a user, and execute the multiple subtasks in parallel in multiple concurrent execution units;

[0111] An incremental recovery module 20, configured to perform incremental recovery on the compressed differential data corresponding to the multiple subtasks in multiple concurrent execution units.

[0112] The data recovery device provided by this application adopts the data recovery method in the above embodiment and can solve technical problems. Compared with the prior art, the beneficial effects of the data recovery device provided by this application are the same as those of the data recovery method provided by the above embodiment, and other technical features in the data recovery device are the same as those disclosed in the method of the above embodiment, which will not be elaborated here.

[0113] This application provides a data recovery device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the data recovery method in the first embodiment above.

[0114] Next, refer to Figure 6 , which shows a schematic structural diagram of a data recovery device suitable for implementing the embodiments of this application. The data recovery device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions: tablet computers), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The data recovery device shown is only an example and should not impose any limitations on the functions and usage scopes of the embodiments of this application.

[0115] As Figure 6As shown, the data recovery device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM: Random Access Memory) 1004. In the RAM 1004, various programs and data required for the operation of the data recovery device are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the data recovery device to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a data recovery device with various systems, it should be understood that it is not required to implement or have all the systems shown. Instead, more or fewer systems can be implemented or had.

[0116] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network through the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of the embodiments disclosed in the present application are executed.

[0117] The data recovery device provided by the present application adopts the data recovery method in the above-mentioned embodiment and can solve the technical problem of data recovery. Compared with the prior art, the beneficial effects of the data recovery device provided by the present application are the same as those of the data recovery method provided by the above-mentioned embodiment, and the other technical features in the data recovery device are the same as those disclosed in the method of the previous embodiment and will not be elaborated here.

[0118] It should be understood that each part disclosed in this application can be implemented by hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in a suitable manner in any one or more embodiments or examples.

[0119] As described above, the above are only specific embodiments of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art within the technical scope disclosed in this application can easily think of changes or substitutions, which should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

[0120] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the data recovery method in the above embodiments.

[0121] The computer-readable storage medium provided by this application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems, or devices, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or combined with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium can be transmitted by any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0122] The above computer-readable storage medium can be included in the data recovery device; it can also exist separately without being assembled into the data recovery device.

[0123] Computer program code for performing the operations of this application can be written in one or more programming languages or combinations thereof. The above-mentioned programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can 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 a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any kind of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (for example, by using an Internet service provider to connect through the Internet).

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and 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 diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0125] The modules described in the embodiments of this application can be implemented in software or in hardware. Among them, the name of the module does not constitute a limitation on the unit itself in some cases.

[0126] The readable storage medium provided in this application is a computer-readable storage medium. The computer-readable storage medium stores computer-readable program instructions (i.e., computer programs) for performing the above data recovery method and can solve technical problems. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the data recovery method provided in the above embodiments and will not be elaborated here.

[0127] The present application also provides a computer program product, including a computer program, which when executed by a processor implements the steps of the data recovery method as described above.

[0128] The computer program product provided by the present application can solve technical problems. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as those of the data recovery method provided by the above embodiments, and will not be elaborated here.

[0129] The above are only some embodiments of the present application, and thus do not limit the patent scope of the present application. Any equivalent structural transformation made under the technical concept of the present application by using the content of the specification and drawings of the present application, or any direct / indirect application in other related technical fields, is included in the patent protection scope of the present application.

Claims

1. A data recovery method, characterized in that: The method includes: When receiving a data recovery request from a user, decomposing a data recovery task in the data recovery request into a plurality of subtasks, and executing the plurality of subtasks in parallel in a plurality of concurrent execution units; Incrementally restore the compressed differential data corresponding to the multiple subtasks in multiple concurrent execution units.

2. The method according to claim 1, characterized in that The step of decomposing the data recovery task in the data recovery request into a plurality of subtasks upon receiving the data recovery request from the user, and executing the plurality of subtasks in parallel in a plurality of concurrent execution units comprises: When receiving a data recovery request from a user, parsing the data recovery request, obtaining multiple dimensional information, and determining a data recovery task according to the multiple dimensional information; Decomposing the data recovery task into multiple subtasks at data block or table level according to system parameters; The plurality of subtasks are distributed to a plurality of concurrent execution units for parallel execution.

3. The method according to claim 1, characterized in that The step of incrementally restoring the compressed differential data corresponding to the multiple subtasks in the multiple concurrent execution units includes: Determine, in the multiple concurrent execution units, compressed differential data corresponding to the multiple subtasks from a preset differential storage file in the database according to the timestamp and the version number; The compressed differential data is decompressed, and the decompressed differential data is rewritten into the database, and the decompressed differential data is incrementally restored.

4. The method according to claim 1, characterized in that Before the step of decomposing the data recovery task in the data recovery request into a plurality of subtasks upon receiving the data recovery request from the user, the method further includes: Capturing the changed data in the database in real time, and generating differential data based on the changed data; The differential data is compressed by a real-time compression algorithm, and the compressed differential data is stored in the database.

5. The method according to claim 4, characterized in that The step of capturing the change data in the database in real time and generating differential data according to the change data includes: Capture the changed data in the database in real time through a multi-level data capture mechanism; The data before and after the change in the database is compared by a hash algorithm, the changed parts are identified at the table level, row level and column level respectively, and differential data is generated based on the changed parts.

6. The method according to claim 4, characterized in that The step of compressing the differential data by a real-time compression algorithm and storing the compressed differential data in the database comprises: Determining an optimal real-time compression algorithm according to the type and change frequency of the differential data, and compressing the differential data using the optimal real-time compression algorithm to obtain compressed differential data; Segmenting the compressed differential data according to multiple dimensional information to obtain multiple segmented differential data; A version number is generated, and the plurality of segmented differential data and the version number are stored in a preset differential storage file in the database.

7. A data recovery device, characterized in that: The data recovery device comprises: A task decomposition module, used for decomposing a data recovery task in a data recovery request into a plurality of subtasks upon receiving a data recovery request from a user, and executing the plurality of subtasks in parallel in a plurality of concurrent execution units; The incremental recovery module is used to perform incremental recovery on the compressed differential data corresponding to the multiple subtasks in multiple concurrent execution units.

8. A data recovery device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the data recovery method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the data recovery method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the data recovery method according to any one of claims 1 to 6 are implemented.

Images