Continuous data protection method, device and equipment based on Linux complete machine and storage medium

Abstract

The invention discloses a continuous data protection method, device and equipment based on a Linux complete machine and a storage medium, and the method comprises the steps: when a backup instruction is received, creating a backup plan, and determining a to-be-backed-up Linux system and an NFS storage end for backup processing; registering a corresponding request interface in the block device of the Linux system to be backed up, and intercepting the received BIO request based on the request interface; the request type of the BIO request is judged, and the request type comprises a write request and other requests; when it is judged that the request type is a write request, whether a backup instruction is executed or not is determined according to the BIO request, and when it is determined that the backup instruction is executed, the Linux system to be backed up is backed up to the NFS storage end. By directly intercepting a block device write request on a kernel level, realizing incremental backup based on a two-dimensional mapping table and combining a metadata management mechanism, the method has the advantages of improving backup universality, reducing system overhead and realizing block-level incremental backup.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security, and particularly relates to a continuous data protection method and device based on a Linux whole machine, and a storage medium. BACKGROUND

[0002] Existing snapshot technologies (such as LVM snapshot, ZFS, Btrfs) usually depend on specific file systems or logical volume managers, and have certain defects. First, the specific file system structure needs to be modified or depended on, which leads to poor universality and makes it difficult to be flexibly applied in different file system environments; second, the creation and maintenance of snapshots will generate high system overhead, and frequent snapshot operations will significantly affect the running performance of a production system; third, it is difficult to realize low-overhead, block-level, fine-grained incremental backup, and real-time data protection requirements cannot be met. In particular, in a Linux whole machine environment, the traditional scheme cannot directly intercept block device write requests at the kernel level, which leads to the fact that the backup process must pass through the file system layer, thus increasing the system burden and reducing the backup efficiency.

[0003] Therefore, there is an urgent need for a data protection method that improves data backup efficiency and universality. SUMMARY

[0004] The purpose of the embodiments of the present application is to provide a continuous data protection method and device based on a Linux whole machine, and a storage medium, which solve the above-mentioned problems and have the advantages of improving backup universality, reducing system overhead, and realizing block-level incremental backup.

[0005] In a first aspect, the embodiments of the present application provide a continuous data protection method based on a Linux whole machine, comprising: When a backup instruction is received, a backup plan is created, and a to-be-backed-up Linux system and an NFS storage end for backup processing are determined; A corresponding request interface is registered in a block device of the to-be-backed-up Linux system, and a received BIO request is intercepted and processed based on the request interface; The request type of the BIO request is determined, wherein the request type includes a write request and a read request; When it is determined that the request type is a write request, it is determined whether to execute the backup instruction according to the BIO request, and when it is determined to execute the backup instruction, the to-be-backed-up Linux system is backed up to the NFS storage end.

[0006] In a second aspect, the embodiments of the present application provide a continuous data protection device based on a Linux whole machine, comprising: The instruction receiving module is configured to create a backup plan and determine a to-be-backed-up Linux system and an NFS storage end for backup processing when a backup instruction is received. The request intercepting module is configured to register a corresponding request interface in a block device of the to-be-backed-up Linux system, and intercept a received BIO request based on the request interface. The judgment processing module is configured to judge a request type of the BIO request, wherein the request type includes a write request and a read request. The data backup module is configured to determine whether to execute the backup instruction according to the BIO request when the request type is determined to be the write request, and backup the to-be-backed-up Linux system to the NFS storage end when it is determined to execute the backup instruction.

[0007] In a third aspect, an electronic device is provided, which includes a processor, a memory, and a computer program or an embedded program stored in the internal storage of the memory and executable on the processor. The processor implements the steps of the continuous data protection method based on a Linux whole machine when executing the computer program or the embedded program.

[0008] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program or an embedded program. The computer program or the embedded program implements the steps of the continuous data protection method based on a Linux whole machine when executed by a processor.

[0009] The embodiments of the present application provide a continuous data protection method, device and equipment based on a Linux whole machine and a storage medium. When a backup instruction is received, a backup plan is created and a to-be-backed-up Linux system and an NFS storage end for backup processing are determined. A corresponding request interface is registered in a block device of the to-be-backed-up Linux system, and a received BIO request is intercepted based on the request interface. The request type of the BIO request is judged, wherein the request type includes a write request and a read request. When the request type is determined to be the write request, it is determined whether to execute the backup instruction according to the BIO request, and the to-be-backed-up Linux system is backed up to the NFS storage end when it is determined to execute the backup instruction. By directly intercepting the block device write request at the kernel level, the number of data copying times between the user state and the kernel state in the traditional scheme is reduced, the influence of the backup operation on the system performance is reduced, the incremental backup is realized based on the two-dimensional mapping table, and the problems of the traditional scheme, such as dependence on a specific file system, high system overhead and insufficient recovery accuracy, are solved. The present application has the advantages of improving backup universality, reducing system overhead and realizing block-level incremental backup. BRIEF DESCRIPTION OF DRAWINGS

[0010] Figure 1 is a framework schematic diagram of a Linux whole machine based continuous data protection system provided by an embodiment of the present application; Figure 2 is a flow schematic diagram of steps of a Linux whole machine based continuous data protection method provided by an embodiment of the present application; Figure 3 is another flow schematic diagram of a Linux whole machine based continuous data protection method provided by an embodiment of the present application; Figure 4 is a structure schematic diagram of a Linux whole machine based continuous data protection apparatus provided by an embodiment of the present application; Figure 5 is a structure schematic diagram of an electronic device provided by an embodiment of the present application; Figure 6 is another structure schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0011] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0012] It should be understood that each of the steps in the method embodiments disclosed by the present application can be executed in different orders and / or in parallel. In addition, the method embodiments can include additional steps and / or omit the execution of the illustrated steps. The scope of the present application is not limited in this respect.

[0013] The term "comprising" and variations thereof as used in the present application are open-ended, that is, "including but not limited to". The term "based on" is "based, at least in part, on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Related definitions of other terms will be given in the description below.

[0014] In the related art, the conventional snapshot technology usually needs to rely on a specific file system or a logical volume manager, for example, the LVM snapshot, the ZFS or the like solution needs to modify the file system structure, resulting in poor cross-platform compatibility. When creating a snapshot, such a technology needs to copy metadata or freeze the file system state, causing significant performance overhead, which easily affects the running efficiency of the production system in the frequent backup scenario. In addition, the existing solution is difficult to implement fine-grained incremental backup at the block device level, resulting in waste of storage resources. For example, in a cloud computing environment, a virtual machine needs to be backed up in real time but is limited by the file system difference, and often needs to be shut down or adopt a complex storage architecture.

[0015] To solve the technical problems in the related art, the present application provides a continuous data protection system based on a Linux system, referring to Figure 1 , Figure 1 is a schematic diagram of a continuous data protection system based on a Linux system provided by an embodiment of the present application. Specifically, the system is composed of a web end, a backup device and an NFS storage end, and the backup device is composed of a server and a backup agent, wherein the web end provides interaction with the user, the server stores device information, related configurations of backup or recovery, the NFS storage end is responsible for saving the backup set, and the backup agent is responsible for starting the kernel BIO write request interception and the kernel backup thread.

[0016] Actually, the web end is a user interaction entrance, providing an operation interface of "creating a backup / recovery task, viewing the state". The server is a control center, responsible for storing configurations, forwarding instructions and coordinating the work of various components. The backup agent is a kernel layer executor, responsible for "intercepting write requests, starting backup threads and generating metadata", and is a bridge between the "application layer (server)" and the "kernel layer (disk I / O)". The NFS storage end is a data warehouse, persistently storing "incremental backup data" and "metadata", and providing shared storage capability for multiple nodes (backup / recovery system).

[0017] Further, when the system shown in Figure 1 is processed, the backup and recovery processing of data can be performed, that is, including the backup scenario and the recovery scenario.

[0018] Among them, in the backup scenario, the following steps are included: 1. User interaction and configuration delivery.

[0019] The user initiates the "create backup task" operation through the web end (PC / web interface), specifies the key parameters, including: the Linux system to be backed up (explicitly specifies the target host to be protected), the backup strategy (such as timed backup, real-time incremental backup) and the NFS storage path (the network storage location where the backup data is to be saved).

[0020] Web sends these parameters to the server, which acts as a "control center" and stores device information and backup / restoration configurations (such as database records indicating which Linux system needs to be backed up and which directory on the NFS needs to be backed up).

[0021] 2. Backup agent initialization and kernel preparation.

[0022] The server issues a "start backup" instruction to the backup agent in the "Linux system to be backed up."

[0023] Backup agent performs kernel layer initialization and writes request interception registration: In the kernel's block device request_queue, a custom make_request_fn interface is registered to enable "BIO write request interception logic" (start monitoring disk write operations).

[0024] Backup thread startup: Create a separate kernel backup thread (such as "snapshot thread") and initialize the connection with the NFS storage end (ensure that subsequent data can be written to the NFS storage end).

[0025] 3. Write request interception and incremental backup execution When the block device of the "Linux system to be backed up" generates a write request, including: BIO request interception: Backup agent intercepts the BIO write request at the kernel layer (triggering "write request interception" logic); Request shunting and backup judgment: After determining that it is a write request, query the "backup mapping table", if the sector has been backed up: directly forward the request to the original block device, without repeating the backup; if the sector has not been backed up: clone the BIO (generate clone_bio), and push it into the "snapshot queue" (for asynchronous processing by the backup thread).

[0026] 4. Asynchronous backup to NFS storage end.

[0027] Kernel backup thread takes out clone_bio from "snapshot queue" and extracts original data (sector content before modification).

[0028] Write original data to the "incremental data file" on the NFS storage end through the kernel_write interface to achieve pre-write backup.

[0029] At the same time, backup agent constructs metaInfo structure (records timestamp, original sector number, backup sector position, etc.) and writes it to the "metadata file" on the NFS storage end (provides index for subsequent recovery).

[0030] 4. Status synchronization and display The service end synchronizes the "metadata file" and "backup progress" from the NFS storage end periodically, and feeds back the status to the web end, so that the user can check the information such as "whether the backup is completed, backup history" and the like through the web interface.

[0031] Meanwhile, in the recovery scenario, the processing procedure comprises: 1. User triggers recovery and parameter designation.

[0032] The user initiates a "recovery task" through the web end, and designates key parameters such as a target system (a new Linux system to be restored to, which requires that the kernel version is consistent with the original system), a recovery time point (restoring the system state to a historical moment), and a disk mapping relationship (such as the / dev / sda of the original backup corresponding to the / dev / sdb of the new system).

[0033] 2. Service end coordination and data reading.

[0034] The web end sends the recovery parameters to the service end, and the service end reads the corresponding "metadata file" (obtains the timestamp, sector mapping and the like of the historical backup) from the NFS storage end.

[0035] The service end issues an "execute recovery" instruction to the "target system" (or a recovery agent thereof).

[0036] 3. Incremental data restoration to a new disk.

[0037] The recovery agent (or a similar component) performs the following operations: Baseline data recovery: reading the "baseline data at the time when the snapshot thread is started" from the NFS storage end, and writing into the block device (such as / dev / sdb) of the target system, so as to establish the "basis for data restoration".

[0038] Incremental data superposition: filtering according to the timestamp of the "metadata file" (only restoring the modifications before the target time point), reading the data from the "incremental data file" of the NFS storage end in sequence, and writing into the corresponding sector of the target block device (to ensure consistency with the state of the original system at the specified time point).

[0039] 4. System startup and verification.

[0040] After the recovery is completed, the service end notifies the web end, the user manually restarts the target system, and enters the BIOS interface to modify the "startup disk priority" (setting the new disk as the first startup item).

[0041] After the system starts from the new disk, the restored kernel and file system are loaded, and finally the system is restored to the state at the specified time point, and the whole recovery process is completed.

[0042] The embodiment of the application provides a continuous data protection method based on a Linux whole machine, please refer toFigure 2 , Figure 2 is a flowchart of steps of a Linux-based continuous data protection method provided by an embodiment of the present application, which includes steps 201 to 204.

[0043] Step 201, when receiving a backup instruction, creating a backup plan and determining a to-be-backed-up Linux system and an NFS storage end for backup processing.

[0044] In an embodiment, when receiving a backup instruction sent by a user through a corresponding operation, a corresponding backup plan is created, and a to-be-backed-up Linux system and an NFS system for backup processing are determined. Through responding to the backup plan, subsequent backup operations are completed.

[0045] Among them, the NFS storage end refers to a remote storage node based on the network file protocol, which can specifically use the standard NFSv4 protocol to realize network communication, and is used to receive and persist incremental backup data. The backup process is triggered by a user space backup instruction, and the kernel module establishes an association relationship between the to-be-backed-up system and the NFS storage end after receiving the instruction.

[0046] Therefore, when creating a backup plan, the user operates on the system based on Figure 1 to achieve, specifically including: when receiving a backup instruction, generating a backup selection interface and receiving a selection instruction input in the backup selection interface; determining a to-be-backed-up Linux system and an NFS storage end for backup processing based on the selection instruction.

[0047] That is, the user operates on the Web end of the system as shown in Figure 1 , such as adding NFS storage server information and adding Linux host. Through the addition of the device, the relationship between the two is established, that is, when performing backup processing, the to-be-backed-up Linux system and the NFS storage end are determined at the same time of creating a backup plan.

[0048] Step 202, registering a corresponding request interface in the block device of the to-be-backed-up Linux system, and intercepting and processing the received BIO request based on the request interface.

[0049] In an embodiment, after the to-be-backed-up Linux system and the NFS storage end are determined, a corresponding request interface is registered in the to-be-backed-up Linux system for intercepting and analyzing the received BIO request during application.

[0050] The request interface is a data processing entrance of a block device driver layer of the Linux system, and specifically, a custom make_request_fn interface can be registered in a request_queue of a block device of the Linux system to be backed up to intercept a BIO request entering the block device. The BIO request is a basic unit of a block device input / output operation, and specifically includes metadata such as a start sector number, a data length, and an operation type, and is used to identify a data area to be processed.

[0051] In step 203, the request type of the BIO request is determined, wherein the request type includes a write request and other requests.

[0052] In an embodiment, after the corresponding request interface is registered and the received BIO request is intercepted, the request type of the intercepted BIO request is identified and determined. In the current scenario, the request type of the BIO request can be divided into a write request and other requests based on subsequent operations. Of course, the other requests can include a read request, a flush request, and the like. When the request type of the BIO is a write request, subsequent backup processing is performed, and otherwise, the backup is skipped.

[0053] Exemplarily, when the request type of the intercepted BIO request is determined, the bi_opf flag in the intercepted BIO request can be parsed, and specifically, the REQ_OP_WRITE flag can be detected and identified to determine whether the BIO request is a write request.

[0054] In step 204, when it is determined that the request type is a write request, it is determined whether to execute a backup instruction according to the BIO request, and when it is determined to execute the backup instruction, the Linux system to be backed up is backed up to the NFS storage end.

[0055] In an embodiment, when it is determined that the request type of the intercepted BIO request is a write request, it is determined whether to execute the received backup instruction according to the intercepted BIO request, and when it is determined to execute the backup instruction, the Linux system to be backed up is backed up to the determined NFS storage end.

[0056] Specifically, when it is determined that the request type of the intercepted BIO request is a write request, it is further determined whether to execute the received backup instruction, that is, whether to perform subsequent backup operations, and when it is determined to perform subsequent backup operations, the data block content corresponding to the current write request is written to the NFS storage end through network transmission, while the normal processing of the original I / O path is maintained, ensuring that the operation of the production system is not interrupted.

[0057] It should be noted that, since the request type of the BIO request is diverse, and the subsequent further judgment processing is only performed when the request type of the BIO request is a write request, when determining the request type of the intercepted BIO request, the BIO request is also sent to the block device to enable the block device to respond to the BIO request when it is determined that the request type of the BIO request is not a write request.

[0058] That is, when the request type is determined to be a read request or other non-write operation, the request is directly forwarded to the block device driver layer for processing. For example, when a user process initiates a file read operation, the BIO request generated by the kernel is determined by the interception module to be a read request, and then data reading is completed by calling the standard processing interface of the block device. In this process, there is no need to trigger the backup process or modify the request content, and only the integrity of the original request path needs to be maintained. As an embodiment, the request forwarding can be realized by calling the general block layer interface function provided by the kernel, such as calling the submit_bio function to submit the request to the device queue. In this way, the processing delay of non-write requests is consistent with the standard block device operation.

[0059] Further, when further processing is performed after determining that the request type of the intercepted BIO request is a write request, the following steps are included: when the BIO request is determined to be a write request, a two-dimensional mapping table is obtained, wherein the two-dimensional mapping table records the backup situation of each block device in the to-be-backed-up Linux system, and the backup situation includes backup and non-backup; the original sector number carried in the BIO request is queried in the two-dimensional mapping table to determine whether the original sector number is recorded in the two-dimensional mapping table; when the original sector number is recorded in the two-dimensional mapping table, it is determined to skip the backup instruction; and when the original sector number is not recorded in the two-dimensional mapping table, it is determined to execute the backup instruction.

[0060] The two-dimensional mapping table refers to a data structure indexed by block device identifiers and sector numbers, which can be implemented in a hash table or bitmap manner, for example, to record whether each sector has completed the first backup. The original sector number refers to a physical address identifier of a data storage location in the block device, which is used to accurately locate the position of the data to be backed up.

[0061] Specifically, when the BIO request received by the block device is a write request, the original sector number associated with the request is extracted through the kernel interception mechanism, and it is queried in the two-dimensional mapping table whether the sector has been marked as backed up. If the query result is backed up, it is determined that the sector data already exists in the NFS storage end, and the backup process is directly skipped to reduce I / O overhead; if the query result is not backed up, the data cloning process is triggered to write the current data into the incremental file, and the corresponding sector state is updated to backed up after the backup is completed.

[0062] Here, the backup state of the physical sector is directly recorded by the two-dimensional mapping table, avoiding performance loss caused by parsing of the file system structure. Repetitive backup is avoided to save storage resources, and a single backup mechanism is achieved by accurately identifying the first write sector, avoiding redundant data generated by multiple backups of the same sector.

[0063] Further, after determining whether to execute the received backup instruction by using the two-dimensional backup table, when it is determined to execute, the method comprises: when it is determined to execute the backup instruction, cloning the BIO request to obtain a copy request, and pushing the copy request into a corresponding snapshot queue; calling an independent kernel thread to sequentially process each segment of the copy request, and obtaining original data that needs to be backed up in the Linux system to be backed up according to a processing result; and writing the original data into an incremental data file of the NFS storage end.

[0064] The cloning of the BIO request refers to cloning the original input / output operation request, and creating a copy that is completely identical to and independent of the original data volume at the block device level rather than the file level.

[0065] Specifically, when it is determined to execute the received backup instruction, the original BIO request is completely copied to generate a new copy request, and the copy request is inserted into a pre-created snapshot queue. Then, an independent kernel thread is called to continuously monitor the queue, so as to sequentially process each segment of the copy request when the copy request is processed, such as splitting the copy request into multiple continuous data segments, and reading corresponding original data blocks in the Linux system to be backed up through a block device interface. After reading is completed, the original data is directly written into the incremental data file pre-created on the NFS storage end, and the file only records data content modified in the current backup period.

[0066] Further, while backing up the Linux system to be backed up to the NFS storage end, in order to facilitate subsequent tracing and recovery and the like, an "index" can be established for the backup data. Specifically, after the original data is written into the incremental data file on the NFS storage end, the method further comprises: recording an offset of the original data in the NFS storage end; constructing metadata based on a metaInfo structure body, and writing the metadata into a metadata file on the NFS storage end, wherein the metadata comprises a backup timestamp, an original sector number, a backup sector number, a data length and an offset; and when it is determined that the metadata is written into the metadata file, forwarding the BIO request to the block device for response.

[0067] Wherein, the offset refers to a physical position identifier of the data in the storage medium, and can be implemented by using a file pointer or an index mapping table, and is used for accurately locating a writing position of the incremental data in the storage end, the metaInfo structure refers to a data structure used for organizing backup metadata, and contains fixed-length fields used for storing timestamps, sector addresses and other key information, and the metadata file refers to a structured storage unit independent of the incremental data, and can be implemented by using a binary file format, and the associated information of each backup operation is recorded by using a sequential writing mode.

[0068] Specifically, when the original data is written into the incremental data file, the system immediately records the starting position offset of the data in the storage medium, that is, the BIO segment offset information. Subsequently, the backup timestamp, the original sector address, the target sector address, the data length and the offset are encapsulated by using the predefined metaInfo structure to form a standardized metadata record. The metadata record is sequentially appended to the independent metadata file to ensure that the information of each backup operation is completely saved. After the metadata writing operation is confirmed to be completed by the storage end, the original BIO request is released and forwarded to the underlying block device to perform an actual writing operation.

[0069] Here, the independent metadata file is directly constructed at the kernel block layer to make the backup information free from the constraints of the file system, and the structure body encapsulation mode is used to improve the metadata reading and writing efficiency and avoid performance loss caused by parsing a complex file format. By physically separating the backup data and the metadata, the incremental data can be accurately located by quickly searching the metadata file during the recovery operation, thereby solving the problem of low recovery efficiency caused by the dispersed storage of the metadata in the traditional scheme. Meanwhile, the record structure arranged in time sequence in the metadata file effectively avoids the data coverage risk caused by the confusion of backup versions.

[0070] Further, based on the system shown in Figure 1 , the application and processing scenarios include a backup scenario and a recovery scenario, and the foregoing description is directed to the processing procedure of the backup scenario. Therefore, when the system shown in Figure 1 performs the recovery processing of data, the foregoing description can be referred to. Figure 3 , Figure 3 is another flow diagram of the continuous data protection method based on the Linux whole machine provided by the embodiments of the present application, and specifically, the steps include steps 301 to 304.

[0071] Step 301, when receiving a recovery instruction, determining a to-be-recovered system, a recovery time point and a disk recovery relationship; Step 302, acquiring the block device data of each to-be-recovered block device in the to-be-recovered system before the time point, and writing the block device data into the corresponding to-be-recovered block device; Step 303, reading the metafile data in the NFS storage end in time sequence, and writing the incremental data before the recovery time point to the corresponding sectors of the corresponding block device according to the timestamp in the metafile data; Step 304, when the data recovery of all block devices in the to-be-recovered system is completed, restarting and setting the to-be-recovered system, and completing the recovery process of the to-be-recovered system when the setting is completed.

[0072] In an embodiment, the recovery time point refers to a specific time point specified by the user to which the system state needs to be rolled back, which can be implemented by parsing the time parameter carried in the recovery instruction, which can be, for example, a timestamp or a log sequence number, for locating the incremental data range in the metadata. The disk recovery relationship refers to the mapping relationship between the to-be-recovered block device and the backup data in the NFS storage end, which can be implemented by a predefined correspondence table of device identifiers and storage paths, ensuring that the incremental data is accurately written to the physical sectors of the target device. The metafile data refers to structured information recording the backup operation timestamp, original sector address and data offset, which is stored in a separate file in the NFS storage end in binary format, and the incremental data block meeting the time condition can be quickly located by traversing the file.

[0073] In the data recovery process, first, the base block device data before the recovery time point input by the user is obtained from the NFS storage end, which is completely overwritten to the to-be-recovered block device to restore the initial state. Then, by sequentially scanning the metadata file, the incremental data records with a timestamp earlier than the recovery time point are filtered out, and these data blocks are written to the original sector address of the corresponding block device in sequence.

[0074] In practical applications, the data recovery process does not need to rely on the file system structure, but directly implements data overwrite based on the block device layer. After the data is written, the to-be-recovered system is restarted and the device driver is reloaded to make the recovered disk state effective.

[0075] In summary, the above embodiment provides a Linux-based whole machine continuous data protection method. When a backup instruction is received, a backup plan is created, and a to-be-backed-up Linux system and an NFS storage end for backup processing are determined. A corresponding request interface is registered in a block device of the to-be-backed-up Linux system, and a received BIO request is intercepted based on the request interface. The request type of the BIO request is determined, wherein the request type includes a write request and a read request. When the request type is determined to be the write request, it is determined whether to execute the backup instruction according to the BIO request. When it is determined to execute the backup instruction, the to-be-backed-up Linux system is backed up to the NFS storage end. By directly intercepting the block device write request at the kernel level, the number of data copying times between the user state and the kernel state in the traditional scheme is reduced, the influence of the backup operation on the system performance is reduced, the incremental backup is implemented based on the two-dimensional mapping table, the problem of the traditional scheme depending on a specific file system, high system overhead, and insufficient recovery accuracy is solved, and the advantages of improving backup universality, reducing system overhead, and implementing block-level incremental backup are achieved.

[0076] According to the method described in the above embodiment, the present embodiment will be further described from the perspective of a Linux-based whole machine continuous data protection device. The Linux-based whole machine continuous data protection device can be implemented as an independent entity or integrated in an electronic device such as a terminal, which can include a mobile phone, a tablet computer, and the like.

[0077] Please refer to Figure 4 , Figure 4 is a structural schematic diagram of a Linux-based whole machine continuous data protection device provided by an embodiment of the present application, as Figure 4 indicated, the Linux-based whole machine continuous data protection device 400 provided by the present embodiment includes: An instruction receiving module 401 is configured to create a backup plan and determine a to-be-backed-up Linux system and an NFS storage end for backup processing when a backup instruction is received. A request intercepting module 402 is configured to register a corresponding request interface in a block device of the to-be-backed-up Linux system, and intercept a received BIO request based on the request interface. A judgment processing module 403 is configured to determine the request type of the BIO request, wherein the request type includes a write request and other requests. A data backup module 404 is configured to determine whether to execute the backup instruction according to the BIO request when the request type is determined to be the write request, and backup the to-be-backed-up Linux system to the NFS storage end when it is determined to execute the backup instruction.

[0078] In an embodiment, the data backup module 404 is further configured to: When determining that the BIO request is a write request, a two-dimensional mapping table is obtained, wherein the two-dimensional mapping table records backup conditions of each block device in the Linux system to be backed up, and the backup conditions include backup and non-backup; The original sector number carried in the BIO request is identified and queried in the two-dimensional mapping table to determine whether the original sector number is recorded in the two-dimensional mapping table; When the original sector number is recorded in the two-dimensional mapping table, it is determined that the backup instruction is skipped; When the original sector number is not recorded in the two-dimensional mapping table, it is determined that the backup instruction is executed.

[0079] In an embodiment, the data backup module 404 is further configured to: When it is determined that the backup instruction is executed, the BIO request is cloned to obtain a copy request, and the copy request is pushed into a corresponding snapshot queue; An independent kernel thread is called to sequentially process each segment of the copy request, and the original data that needs to be backed up is obtained in the Linux system to be backed up according to the processing result; The original data is written into an incremental data file of the NFS storage end.

[0080] In an embodiment, the data backup module 404 is further configured to: The offset of the original data in the NFS storage end is recorded; Metadata is constructed based on the metaInfo structure, and the metadata is written into a metadata file of the NFS storage end, wherein the metadata includes a backup timestamp, an original sector number, a backup sector number, a data length, and an offset; When it is determined that the metadata is written into the metadata file, the BIO request is forwarded to the block device for response.

[0081] In an embodiment, the instruction receiving module 401 is further configured to: When the backup instruction is received, a backup selection interface is generated, and a selection instruction input in the backup selection interface is received; Based on the selection instruction, the Linux system to be backed up and the NFS storage end for backup processing are determined.

[0082] In an embodiment, the data backup module 404 is further configured to: When it is determined that the request type of the BIO request is not a write request, the BIO request is sent to the block device, so that the block device responds to the BIO request.

[0083] In an embodiment, the Linux whole machine-based continuous data protection device 400 further includes a data recovery module configured to: When the recovery instruction is received, the system to be recovered, the recovery time point, and the disk recovery relationship are determined; Acquire the block device data of each block device to be recovered in the system to be recovered before the time point, and write the block device data into the corresponding block device to be recovered; Read the metafile data in time sequence in the NFS storage end, and write the incremental data before the recovery time point into the corresponding sector of the corresponding block device to be recovered according to the timestamp in the metafile data; When the data recovery of all block devices in the system to be recovered is completed, restart and set the system to be recovered, and complete the recovery processing of the system to be recovered when the setting is completed.

[0084] In addition, please refer to Figure 5 , Figure 5 is a structural schematic diagram of an electronic device provided by an embodiment of the present application. As shown in Figure 5 , the electronic device 500 includes a processor 501 and a memory 502. The processor 501 is electrically connected to the memory 502.

[0085] The processor 501 is the control center of the electronic device 500, and connects each part of the entire electronic device through various interfaces and circuits, etc. Through running or loading the application program stored in the internal flash of the memory 502, and the application program can be an embedded program, and calling the data stored in the memory 502, the signal obtained in the dual-mode communication is realized based on the above-mentioned Linux-based continuous data protection method of the whole machine.

[0086] In the embodiment, the processor 501 in the electronic device 500 will load the instruction corresponding to the process of one or more application programs into the memory 502 according to the steps in the above-mentioned Linux-based continuous data protection method of the whole machine, and the processor 501 runs the application program stored in the memory 502, thereby realizing the continuous data protection and analysis based on the Linux-based whole machine.

[0087] The electronic device 500 can realize the steps in any embodiment of the Linux-based continuous data protection method provided by the embodiment of the present application, and thus can realize the beneficial effects that any Linux-based continuous data protection method provided by the embodiment of the present application can realize. Details are described above, and will not be repeated here.

[0088] Please refer to Figure 6 , Figure 6 is another structural schematic diagram of an electronic device provided by an embodiment of the present application. As shown in Figure 6 , Figure 6 a specific structural block diagram of an electronic device provided by an embodiment of the present application is shown, which can be used to implement the Linux-based continuous data protection method provided in the above-mentioned embodiments.

[0089] The RF circuit 610 is used to receive and send electromagnetic waves, and to convert the electromagnetic waves and electrical signals to each other, so as to communicate with a communication network or other devices. The RF circuit 610 can include various existing circuit elements for performing these functions, such as an antenna, a radio frequency transceiver, a digital signal processor, an encryption / decryption chip, a subscriber identity module (SIM) card, a memory, and the like. The RF circuit 610 can communicate with various networks, such as the Internet, an intranet, a wireless network, or other devices through the wireless network. The wireless network can include a cellular telephone network, a wireless local or metropolitan area network. The wireless network can use various communication standards, protocols, and technologies, including but not limited to Global System for Mobile Communication (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (WCDMA), Code Division Access (CDMA), Time Division Multiple Access (TDMA), Wireless Fidelity (Wi-Fi) (such as IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, and / or IEEE 802.11n), Voice over Internet Protocol (VoIP), Worldwide Interoperability for Microwave Access (Wi-Max), other protocols for email, instant messaging, and short message service, and any other suitable communication protocol, even those not yet developed as of the date of the disclosure.

[0090] The memory 502 can be used to store software programs and modules, such as the program instructions / modules corresponding to the Linux-based whole-machine continuous data protection method described in the above embodiments. The processor 501 executes various functional applications to implement the Linux-based whole-machine continuous data protection method by running the dual-mode module and the program for controlling the dual-mode module stored in the internal flash of the memory 502. The program for controlling the dual-mode module can be an embedded program stored in the internal flash of the memory 502.

[0091] Memory 502 can include high-speed random access memory and can also include nonvolatile memory, such as one or more magnetic data storage devices, flash memory, or other nonvolatile solid-state memory. In some examples, memory 502 can further include memory that is remote from processor 501, such as the memory memory of a remote server that is connected to electronic device 500 through a network. Examples of such networks include, without limitation, the Internet, an enterprise intranet, a local area network, a mobile communications network, and combinations thereof.

[0092] Input unit 630 can be used to receive uploaded digital or character information, and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function controls. In particular, input unit 630 can include a touch-sensitive surface 631 and other input devices 632. Touch-sensitive surface 631, also known as a touch display or touchpad, can gather touch operations by a user thereon or proximate thereto (such as operations by a user using a finger, a stylus, or any suitable object or accessory on or proximate to touch-sensitive surface 631) and drive corresponding connected devices according to pre-set programs. Optionally, touch-sensitive surface 631 can include both touch detection means and touch controller. The touch detection means detects the position of a user's touch and detects signals resulting from the touch operation and transmits the signals to the touch controller; the touch controller receives the touch information from the touch detection means and converts it to touch coordinates, which are sent to processor 501, and can also receive commands from processor 501 and execute them. In addition, touch-sensitive surface 631 can be implemented in a variety of types, such as resistive, capacitive, infrared, and surface acoustic wave. In addition to touch-sensitive surface 631, input unit 630 can also include other input devices 632. In particular, other input devices 632 can include one or more of, without limitation, a physical keyboard, function keys (such as volume control keys, on / off keys, etc.), a trackball, a mouse, a joystick, and the like.

[0093] The display unit 640 can be used to display information input by a user or provided to the user, as well as various graphical user interfaces of the electronic device 500, which can be composed of graphics, text, icons, video, and any combination thereof. The display unit 640 can include a display panel 641, which can be configured in the form of an LCD (Liquid Crystal Display), an OLED (Organic Light-Emitting Diode), or the like, optionally. Further, the touch-sensitive surface 631 can cover the display panel 641, and when the touch-sensitive surface 631 detects a touch operation thereon or adjacent thereto, transmit to the processor 501 to determine the type of touch event, and then the processor 501 provides corresponding visual output on the display panel 641 according to the type of touch event. Although in the figure, the touch-sensitive surface 631 and the display panel 641 are implemented as two independent components to realize the input and output functions, in some embodiments, the touch-sensitive surface 631 and the display panel 641 can be integrated to realize the input and output functions.

[0094] The electronic device 500 can further include at least one sensor 650, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor can include an ambient light sensor that can adjust the brightness of the display panel 641 according to the brightness of ambient light, and a proximity sensor that can generate an interrupt when the cover is closed or turned off. As one of the motion sensors, the gravity acceleration sensor can detect the magnitude of acceleration in each direction (generally three axes), and when at rest, can detect the magnitude and direction of gravity, which can be used for applications such as identifying the posture of the mobile phone (such as switching between landscape and portrait screens, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometers, tapping), and the like; as well as other sensors that the electronic device 500 can be configured, such as a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, and the like, which will not be described here.

[0095] The audio circuit 660, the speaker 661, and the microphone 662 can provide an audio interface between the user and the electronic device 500. The audio circuit 660 can convert received audio data into an electrical signal, transmit the electrical signal to the speaker 661, and convert the electrical signal into a sound signal output by the speaker 661; on the other hand, the microphone 662 converts the collected sound signal into an electrical signal, which is received by the audio circuit 660 and converted into audio data, which is output to the processor 501 for processing, and then transmitted to another terminal via the RF circuit 610, or output to the memory 502 for further processing. The audio circuit 660 can also include an earphone jack to provide communication between an external earphone and the electronic device 500.

[0096] The electronic device 500 can help the user to receive requests, send information, etc. through the transmission module 670 (e.g., a Wi-Fi module), which provides the user with wireless broadband Internet access. Although the transmission module 670 is shown in the figure, it can be understood that it does not belong to the necessary components of the electronic device 500, and can be omitted as needed without changing the essence of the application.

[0097] The processor 501 is the control center of the electronic device 500, which connects various parts of the entire mobile phone through various interfaces and lines, executes various functions of the electronic device 500 and processes data by running or executing software programs and / or modules stored in the memory 502 and calling data stored in the memory 502, thereby monitoring the entire electronic device. Optionally, the processor 501 can include one or more processing cores; in some embodiments, the processor 501 can integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application program, etc., and the modem processor mainly processes wireless communication. It can be understood that the above-mentioned modem processor can also not be integrated into the processor 501.

[0098] The electronic device 500 further includes a power supply 690 (such as a battery) for supplying power to various components. In some embodiments, the power supply can be logically connected to the processor 501 through a power management system, so as to realize functions such as management of charging, discharging, and power consumption management through the power management system. The power supply 690 can also include one or more direct or alternating power supplies, recharging systems, power failure detection circuits, power converters or inverters, power status indicators, and any other components.

[0099] In this embodiment, the display unit of the electronic device is a touch screen display. The mobile terminal further includes a memory and one or more programs stored in the memory and configured to be executed by one or more processors to implement any of the steps of the Linux-based continuous data protection method provided by the above embodiments.

[0100] In specific implementation, the above various modules can be implemented as independent entities, or can be combined as the same or several entities, and the specific implementation of the above various modules can be referred to the method embodiments described above, which will not be described here.

[0101] Those skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructions or by controlling relevant hardware by the instructions, which can be stored in a computer readable storage medium and loaded and executed by a processor. To this end, the embodiments of the present application provide a storage medium, which stores a plurality of instructions, which can be executed by a processor to implement any step in the Linux-based continuous data protection method provided by the above embodiments.

[0102] The storage medium can include a read only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc. Specifically, the storage medium can be an internal flash memory, and the embedded program for implementing the Linux-based continuous data protection method can be stored in the internal flash memory.

[0103] Since the instructions stored in the storage medium can execute the steps in any embodiment of the Linux-based continuous data protection method provided by the embodiments of the present application, the beneficial effects of any Linux-based continuous data protection method provided by the embodiments of the present application can be achieved, which are described in detail in the above embodiments and will not be repeated here.

[0104] The above describes in detail a Linux-based continuous data protection method, device, electronic equipment and storage medium provided by the embodiments of the present application. The principle and implementation mode of the present application are described by applying specific examples. The above embodiment is only used to help understand the method of the present application and its core idea. Meanwhile, for those skilled in the art, according to the principle of the present application, the specific implementation mode and application range can be changed. In summary, the content of the specification should not be understood as a limitation of the present application. Moreover, for those skilled in the art, some improvements and refinements can be made without departing from the principle of the present application, and these improvements and refinements are also considered as the protection scope of the present application.

Claims

1. A continuous data protection method based on a Linux system, characterized in that, include: When a backup instruction is received, a backup plan is created and the Linux system and NFS storage to be backed up are determined. Register the corresponding request interface in the block device of the Linux system to be backed up, and intercept and process the received BIO requests based on the request interface; Determine the request type of the BIO request, wherein the request type includes write requests and other requests; When the request type is determined to be a write request, the system determines whether to execute the backup instruction based on the BIO request. If it is determined to execute the backup instruction, the Linux system to be backed up is backed up to the NFS storage.

2. The method as described in claim 1, characterized in that, When determining that the request type is a write request, determining whether to execute the backup instruction based on the BIO request includes: When the BIO request is determined to be a write request, a two-dimensional mapping table is obtained, wherein the two-dimensional mapping table records the backup status of each device in the Linux system to be backed up, and the backup status includes backed up and not backed up; The original sector number carried in the BIO request is identified and queried in the two-dimensional mapping table to determine whether the original sector number is recorded in the two-dimensional mapping table. If the original sector number is recorded in the two-dimensional mapping table, it is determined to skip the backup instruction; If the original sector number is not recorded in the two-dimensional mapping table, the backup instruction is executed.

3. The method as described in claim 1, characterized in that, The step of backing up the Linux system to be backed up to the NFS storage terminal when determining to execute the backup instruction includes: When it is determined to execute the backup instruction, the BIO request is cloned to obtain a copy request, and the copy request is pushed into the corresponding snapshot queue; An independent kernel thread is invoked to process each segment of the copy request sequentially, and the original data to be backed up is obtained from the Linux system to be backed up based on the processing results. The original data is written to the incremental data file on the NFS storage terminal.

4. The method as described in claim 3, characterized in that, After writing the original data into the incremental data file on the NFS storage terminal, the method further includes: Record the offset of the original data in the NFS storage terminal; Metadata is constructed based on the metaInfo structure and written to the metadata file of the NFS storage terminal. The metadata includes backup timestamp, original sector number, backup sector number, data length and offset. When it is determined that the metadata has been written to the metadata file, the BIO request is forwarded to the block device for response.

5. The method as described in claim 1, characterized in that, When a backup instruction is received, the process of creating a backup plan and determining the Linux system and NFS storage to be backed up includes: When a backup instruction is received, a backup selection interface is generated, and the selection instruction entered on the backup selection interface is received. Based on the selection instructions, the Linux system to be backed up and the NFS storage terminal to be backed up are determined.

6. The method as described in claim 1, characterized in that, After determining the request type of the BIO request, the method further includes: When it is determined that the request type of the BIO request is not a write request, the BIO request is sent to the block device so that the block device can respond to the BIO request.

7. The method as described in claim 1, characterized in that, The method further includes: When a recovery command is received, the system to be recovered, the recovery time point, and the disk recovery relationship are determined. Obtain the block device data of each block device to be recovered in the system to be recovered before the time point, and write the block device data to the corresponding block device to be recovered; In the NFS storage, metadata is read in chronological order, and incremental data before the recovery time point is filtered according to the timestamp in the metadata and written to the corresponding sector in the corresponding block device to be recovered. When the data recovery of all block devices in the system to be recovered is completed, the system to be recovered is restarted and configured, and the recovery process of the system to be recovered is completed when the configuration is completed.

8. A continuous data protection device based on a Linux system, characterized in that, include: The instruction receiving module is used to create a backup plan and determine the Linux system and NFS storage to be backed up when a backup instruction is received. The request interception module is used to register the corresponding request interface in the block device of the Linux system to be backed up, and to intercept and process the received BIO requests based on the request interface; The judgment and processing module is used to determine the request type of the BIO request, wherein the request type includes write request and read request; The data backup module is used to determine whether to execute the backup instruction based on the BIO request when the request type is determined to be a write request, and to back up the Linux system to be backed up to the NFS storage terminal when it is determined to execute the backup instruction.

9. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a computer program or embedded program stored in the internal storage of the memory and executable on the processor, wherein the processor executes the computer program or embedded program to implement the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or embedded program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 7.

Images