Data backup and recovery method, electronic equipment and storage medium

Abstract

The invention relates to the technical field of embedded systems, in particular to a data backup and recovery method applied to an embedded device, an electronic device and a storage medium, comprising: in response to creation of a user partition and a backup partition, storing data in the user partition, and backing up the data stored in the user partition in the backup partition; wherein the user partition comprises a plurality of user sub-partitions, the backup partition comprises a plurality of backup sub-partitions, and each user sub-partition and each backup sub-partition store verification files; when it is confirmed that data consistency verification is started, whether data stored in the user sub-partition is consistent with data stored in the corresponding backup sub-partition or not is verified through the verification file; and if the user sub-partitions and the backup sub-partitions are not consistent, data recovery operation is performed, so that the data stored in the corresponding user sub-partitions and the backup sub-partitions are kept consistent, and the defects of an existing data backup and recovery mechanism of the embedded system are effectively overcome.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded systems, and in particular to a data backup and recovery method applied to embedded devices, an electronic device and a computer-readable storage medium. Background Art

[0002] Embedded systems usually divide the storage space into two partitions, such as user partition and backup partition. The user partition is used to store applications and data required for the normal operation of the system, while the backup partition is used to save the backup of the data to ensure the security and reliability of the data required for the normal operation of the system. The embedded system also has a backup and recovery mechanism for the user partition and the backup partition, which is an important means to ensure data security. Once the system fails or the data is damaged, the corresponding recovery process will be started to restore the normal operation of the system as soon as possible.

[0003] However, existing backup and recovery mechanisms usually require large storage and computing resources to support their operation, which makes them difficult to adapt to resource-constrained embedded devices. Especially in the scenario of multi-partition backup, the existing backup and recovery mechanisms are more easily limited by storage resources, making it difficult to achieve fast backup and recovery. The data consistency problem is also particularly prominent in the case of multiple partitions. The consistency between backup data often cannot be effectively verified, which may lead to data loss or logical errors. In addition, the existing backup and recovery mechanisms lack flexibility and cannot dynamically select the optimal recovery or backup strategy according to the actual scenario.

[0004] Therefore, it is urgent to improve the existing backup and recovery mechanisms of embedded systems to ensure that data security and consistency can be effectively protected in resource-constrained environments. Summary of the invention

[0005] In view of this, the present invention proposes a data backup and recovery method, an electronic device and a computer-readable storage medium applied to an embedded device, aiming to overcome the deficiencies of the existing data backup and recovery mechanism of the embedded system.

[0006] In order to solve the above problems, the present invention adopts the following technical solutions: In a first aspect, the present invention proposes a data backup and recovery method applied to an embedded device, comprising: In response to creating a user partition and a backup partition, data is stored in the user partition, and the data stored in the user partition is backed up in the backup partition; wherein the user partition includes a plurality of user sub-partitions, the backup partition includes a plurality of backup sub-partitions, the user sub-partitions and the backup sub-partitions correspond one-to-one, and the data stored in the user sub-partitions corresponds one-to-one to the data stored in the corresponding backup sub-partitions, and each of the user sub-partitions and each of the backup sub-partitions stores a verification file; When it is confirmed to start the data consistency check, the verification file is used to verify whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; if they are inconsistent, a data recovery operation is performed to make the data stored in the corresponding user sub-partition and the backup sub-partition consistent.

[0007] Further, the verifying by the verification file whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; if they are inconsistent, performing a data recovery operation includes: Confirming, through the verification file stored in the backup sub-partition, that the data stored in the backup sub-partition has not been tampered with; Determine whether the verification file stored in the backup sub-partition is consistent with the verification file stored in the corresponding user sub-partition; If yes, confirming that the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; If not, the data stored in the backup sub-partition is copied to the corresponding user sub-partition.

[0008] Further, the verifying by the verification file whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; if they are inconsistent, performing a data recovery operation includes: Confirming, through a verification file stored in the backup sub-partition, that data stored in the backup sub-partition has been tampered with; Determining whether data stored in the user sub-partition has been tampered with by using the verification file stored in the user sub-partition; If tampering occurs, confirm that the data stored in the user sub-partition is damaged; If no tampering occurs, determining whether the verification file stored in the user sub-partition is consistent with the verification file stored in the corresponding backup sub-partition; If they are consistent, confirm that the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; If they are inconsistent, the data stored in the user sub-partition is restored to the corresponding backup sub-partition.

[0009] Furthermore, when it is confirmed that the data consistency check is turned on, the verification file is used to verify whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition, including: In response to the embedded device being powered on and started, firstly erasing the backup sub-partition and then determining the startup mode of the embedded device; When the startup mode is the normal startup mode, the data stored in the user sub-partition and the data stored in the backup sub-partition are not verified; When the startup mode is the update mode, firstly confirming that the data stored in the backup sub-partition has not been tampered with by using the verification file, and then verifying whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition by using the verification file; When the startup mode is the forced partition check mode, the verification file is used to verify whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition.

[0010] Furthermore, after performing the data recovery operation, the method further includes: If the data recovery operation is confirmed to be completed, the mount command is called to dynamically mount the sub-partition of the recovered data to the preset mount point; If an upgrade instruction is received, first confirm that the data in the backup partition is successfully upgraded, and then perform an upgrade operation on the data in the user partition.

[0011] Furthermore, the performing of the data recovery operation includes: automatically performing the data recovery operation in sequence according to a preset priority order through a script.

[0012] Further, the user sub-partition and the backup sub-partition each include a usr partition, an app partition, a web partition and a model partition; The usr partition, app partition, web partition and model partition are sorted in the order of preset priorities, namely app partition, usr partition, model partition and web partition.

[0013] Furthermore, the verification file includes an MD5 verification value.

[0014] In a second aspect, the present invention further provides an electronic device, comprising: a memory for storing program instructions; and The processor is used to execute the program instructions to implement the steps of the data backup and recovery method applied to the embedded device as described above.

[0015] In a third aspect, the present invention further proposes a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps of the data backup and recovery method applied to an embedded device as described above are implemented.

[0016] Compared with the prior art, the beneficial effects of the present invention are: a data backup and recovery method, electronic device and computer-readable storage medium applied to embedded devices, comprising: in response to creating a user partition and a backup partition, storing data in the user partition, and backing up the data stored in the user partition in the backup partition; wherein the user partition includes a plurality of user sub-partitions, the backup partition includes a plurality of backup sub-partitions, the user sub-partitions and the backup sub-partitions correspond one-to-one, and the data stored in the user sub-partitions correspond one-to-one to the data stored in the corresponding backup sub-partitions, and each of the user sub-partitions and each of the backup sub-partitions stores a verification file; when it is confirmed that the data consistency check is turned on, the verification file is used to check whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; if not, a data recovery operation is performed to make the data stored in the corresponding user sub-partition and the backup sub-partition consistent. It can be seen that the data backup and recovery method, electronic device and computer-readable storage medium applied to embedded devices divide the user partition and the backup partition into multiple sub-partitions to achieve fine-grained data management in limited storage resources. This sub-partitioning strategy enables resource-constrained embedded devices to allocate storage space more flexibly, thereby reducing the demand for storage and computing resources. A checksum file is stored in each sub-partition. Data consistency verification is performed through the checksum file, which can effectively ensure the data consistency between the user sub-partition and the corresponding backup sub-partition, reducing the risk of data loss or logical errors. Furthermore, the one-to-one correspondence between the user sub-partition and the backup sub-partition can also simplify the backup and recovery process. When performing data recovery operations, only the sub-partitions with inconsistent data can be processed without processing the data of the entire partition. This local backup and recovery method reduces the complexity of operations and significantly improves the speed of recovery operations, ensuring that the system can be quickly restored when a failure occurs. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings: Figure 1 A schematic diagram of a flow chart of a first embodiment of a data backup and recovery method for an embedded device according to the present invention; Figure 2 A schematic diagram of a flow chart of a second embodiment of a data backup and recovery method for an embedded device according to the present invention; Figure 3 A schematic diagram of a flow chart of a third embodiment of a data backup and recovery method for an embedded device according to the present invention; Figure 4 A schematic diagram of a flow chart of a fourth embodiment of a data backup and recovery method for an embedded device according to the present invention; Figure 5 A schematic diagram of a flow chart of a fifth embodiment of a data backup and recovery method for an embedded device according to the present invention; Figure 6 It is a schematic diagram of the structure of an electronic device in a hardware operating environment involved in an embodiment of the present invention. DETAILED DESCRIPTION

[0018] The scheme in the embodiment of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiment of the present invention. Obviously, the described embodiment is only a part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0019] It should be noted that if the embodiments of the present invention involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are only used to explain the relative position relationship, movement status, etc. between the components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0020] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present invention, the descriptions of "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or suggesting their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in the field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0021] It should be noted that embedded devices usually use embedded systems to implement their specific functions. An embedded system is a computer system designed specifically for a specific application and is usually embedded in a device to implement a specific function. Compared with general-purpose computer systems, embedded systems are more specialized and are specifically used to perform specific tasks or functions, such as multi-channel surveillance video systems and automotive control systems. These systems also require real-time performance to ensure that tasks are completed within strict time limits. Common real-time operating systems include Linux embedded systems, which can be configured and optimized to meet real-time requirements. In addition, embedded systems have very limited resources in terms of processing power, storage space, and power consumption, so they need to have efficient resource management capabilities. Embedded systems have a wide range of applications and play an important role in modern technology.

[0022] The data backup and recovery method applied to an embedded device in an embodiment of the present invention significantly enhances data security by creating a user partition and a backup partition. If a hard disk or partition fails, the backup partition can ensure the integrity and availability of the data. This dual backup strategy effectively prevents data loss due to hardware failure. In addition, if some data is lost or damaged due to misoperation or software errors, the backup partition can also provide a recovery point to quickly restore the system to a normal state, thereby avoiding a significant impact of data loss on the business.

[0023] See also Figure 1 As shown, it is a flow chart of the first embodiment of the data backup and recovery method applied to embedded devices of the present invention.

[0024] In this embodiment, the data backup and recovery method applied to the embedded device includes: Step S100: In response to creating a user partition and a backup partition, data is stored in the user partition, and the data stored in the user partition is backed up in the backup partition.

[0025] The user partition includes several user sub-partitions, the backup partition includes several backup sub-partitions, the user sub-partitions and the backup sub-partitions correspond one-to-one, and the data stored in the user sub-partitions corresponds one-to-one to the data stored in the corresponding backup sub-partitions, and each of the user sub-partitions and each of the backup sub-partitions stores a verification file.

[0026] Specifically, on the basis of creating user partitions and backup partitions, the user partitions and backup partitions are divided into multiple sub-partitions, which can make it easier to manage and organize data. Each user sub-partition corresponds to a backup sub-partition, making data search, access and maintenance more efficient. Moreover, by distributing data to multiple sub-partitions, storage resources can be better utilized, overload of a single partition can be avoided, and the overall performance of the system can be improved. When user data is lost or damaged, the system can quickly extract valid data from the backup partition and restore it to the previous normal state. At the same time, when backup data is lost or damaged, the system can also copy user data to the backup partition to ensure the latest and integrity of the backup data. This mutual recovery mechanism effectively reduces the risk of data loss and enhances the reliability of the system.

[0027] Specifically, the user partition can be divided into sub-partitions such as application resource area, user data area, model resource area, and web data area. Correspondingly, the backup partition can also be divided into sub-partitions such as application resource area, user data area, model resource area, and web data area.

[0028] The application resource area is mainly used to store the core resources of the application, including the application's executable files, library files, configuration files, images, audio, video and other multimedia resources. The application resource area is the basis for the normal operation of the application. The lack or damage of the resources in it will cause the application to fail to start or limit its functions, so it is of the highest importance.

[0029] The user data area is mainly used to store user-generated data, such as user account information, personal settings, usage records, files, documents, photos, etc. The user data area is directly related to user experience and data security. The loss or damage of user data will greatly affect user satisfaction, so it is the second most important.

[0030] The model resource area is mainly used to store files of machine learning or deep learning models, including model weights, configuration files, training data sets, evaluation indicators, etc. The model resource area is crucial to the intelligent functions of applications. Missing or damaged model files will cause the intelligent functions to not work properly, so it is very important, especially in applications that rely on data analysis and prediction.

[0031] The web page data area is mainly used to store data related to the web page, including web page content, style sheets, script files, user interaction data, cache files, etc. The web page data area directly affects the user's access and browsing experience. The loss or damage of web page content will cause the user to be unable to access the website normally, so its importance is also relatively high.

[0032] These four sub-partitions each undertake different functions and data storage tasks, and complement each other. The application resource area and user data area are crucial to the basic operation of the application and the user experience, while the model resource area and web page data area play an important role in intelligence and network interaction. Ensuring the data integrity and security of these sub-partitions is a key task in system design and maintenance. Once data loss or damage is confirmed in these sub-partitions, immediate response is required to perform data recovery operations.

[0033] Step S200: When it is confirmed to start the data consistency check, the data stored in the user sub-partition is checked through the check file to see if it is consistent with the data stored in the corresponding backup sub-partition; if they are inconsistent, a data recovery operation is performed to make the data stored in the corresponding user sub-partition and the backup sub-partition consistent.

[0034] Specifically, when the system of an embedded device is running, data inconsistency may occur due to accidental damage, human error, software defects, or synchronization problems. Accidental damage may occur during data storage or transmission, such as hardware failure or system crash; human error may be that the user accidentally deletes or modifies data during operation. In addition, defects in the software may also cause errors when writing or reading data, and in a multi-user or multi-process environment, concurrent access to data may also cause updates to be out of sync, resulting in data inconsistency. Therefore, the timing to confirm the start of data consistency verification may be during the firmware upgrade process of the embedded device, or during the software update process, or during the preset regular maintenance process. Enabling data consistency verification can ensure the integrity and reliability of data. By verifying the data in the user sub-partition and the backup sub-partition, potential data damage or loss can be discovered in time, thereby maintaining data consistency. In addition, data consistency verification can also improve the reliability of the system, avoid failures or errors caused by data inconsistency, and ensure that users can always access accurate and complete data.

[0035] Compared with the prior art, the data backup and recovery method applied to embedded devices in the embodiment of the present invention divides the user partition and the backup partition into multiple sub-partitions to achieve fine-grained data management in limited storage resources. This sub-partition strategy enables resource-constrained embedded devices to allocate storage space more flexibly, thereby reducing the demand for storage and computing resources. A verification file is stored in each sub-partition, and data consistency verification is performed through the verification file, which can effectively ensure the data consistency between the user sub-partition and the corresponding backup sub-partition, and reduce the risk of data loss or logical errors. Furthermore, the user sub-partition corresponds to the backup sub-partition one by one, and the backup and recovery process can also be simplified. When performing data recovery operations, only the sub-partitions with inconsistent data can be processed without processing the data of the entire partition. This local backup and recovery method reduces the complexity of operations, significantly improves the speed of recovery operations, and ensures that the system can be quickly restored when a failure occurs.

[0036] See also Figure 2 As shown, it is a flow chart of the second embodiment of the data backup and recovery method applied to embedded devices of the present invention.

[0037] Based on the first embodiment of the data backup and recovery method applied to embedded devices, this embodiment describes in detail the recovery strategy adopted when the data of the backup sub-partition has not been tampered with. In this case, the embedded system first confirms the data integrity of the backup sub-partition, and then determines the data difference between the corresponding user sub-partition and the backup sub-partition. If the data of the user sub-partition is consistent with the data of the backup sub-partition, no recovery is required; if not, the data of the backup sub-partition is restored to the corresponding user sub-partition. Such a recovery process can be performed on all sub-partitions one by one to ensure that the data of each sub-partition is verified and restored, thereby ultimately achieving data consistency maintenance for the entire system.

[0038] In this embodiment, the data backup and recovery method applied to the embedded device includes: Step S100: In response to creating a user partition and a backup partition, data is stored in the user partition, and the data stored in the user partition is backed up in the backup partition.

[0039] The user partition includes several user sub-partitions, the backup partition includes several backup sub-partitions, the user sub-partitions and the backup sub-partitions correspond one-to-one, and the data stored in the user sub-partitions corresponds one-to-one to the data stored in the corresponding backup sub-partitions, and each of the user sub-partitions and each of the backup sub-partitions stores a verification file.

[0040] Specifically, before performing a data recovery operation, you need to confirm that data consistency check is enabled. Data consistency check first needs to check whether the data of the backup sub-partition has been tampered with, because the backup data (data stored in the backup partition) is the basis for the recovery operation. If the backup data has been tampered with, then even if the data of the user sub-partition is correct, the recovery operation may cause data errors or damage. Therefore, ensuring the integrity of the backup data is the first step in the data recovery process. By first confirming the integrity of the backup data, you can effectively avoid copying incorrect or damaged backup data to the user sub-partition during the recovery process. If the backup data has been tampered with but the user data (data stored in the user partition) has not been tampered with, directly restoring the data of the backup sub-partition to the corresponding user sub-partition may cause loss or errors of user data, further increasing the risk of data damage.

[0041] Step S211: when it is confirmed to start the data consistency check, the verification file stored in the backup sub-partition is used to confirm that the data stored in the backup sub-partition has not been tampered with.

[0042] Specifically, the verification file stored in the backup sub-partition is implemented by storing the hash value (such as MD5, SHA-1, SHA-256, etc.) of the backup sub-partition data. When the data of the backup sub-partition is generated, the system calculates the hash value of the data and stores it in the verification file. Subsequently, when the integrity of the data needs to be verified, the system recalculates the hash value of the current backup sub-partition data and compares it with the hash value stored in the verification file. If the two are consistent, it means that the backup sub-partition data has not been tampered with; if they are inconsistent, it means that the data may have been tampered with or damaged.

[0043] Step S212: Determine whether the verification file stored in the backup sub-partition is consistent with the verification file stored in the corresponding user sub-partition.

[0044] Specifically, the verification file can not only be used to verify the integrity of the corresponding sub-partition data, but also to compare the consistency of the backup sub-partition data and the user sub-partition data. The system will calculate the data hash values ​​of the user sub-partition and the backup sub-partition respectively, and store them in their respective verification files. During the verification process, the system will compare the contents of the two verification files. If they are consistent, it means that the data of the user sub-partition is the same as the data of the backup sub-partition; if they are inconsistent, the data of the user sub-partition is different from the data of the backup sub-partition, and data recovery operations are required to ensure that the data of the user sub-partition is consistent with the data of the backup sub-partition.

[0045] Step S213: If yes, confirm that the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition.

[0046] Specifically, after confirming that the data stored in the user subpartition is consistent with the data stored in the corresponding backup subpartition, the system does not need to perform data recovery operations and can directly perform other operations, thereby improving the operating efficiency of the system and saving system resource consumption.

[0047] Step S214: If not, copy the data stored in the backup sub-partition to the corresponding user sub-partition, so that the data stored in the corresponding user sub-partition and the backup sub-partition remain consistent.

[0048] Specifically, in step S211, it is confirmed that the data stored in the backup sub-partition has not been tampered with, indicating that the integrity of the backup data is guaranteed and can be safely used for recovery operations. In step S214, it is confirmed that the data stored in the user sub-partition is inconsistent with the data stored in the corresponding backup sub-partition, indicating that the data of the user sub-partition may have been tampered with or damaged and needs to be restored. Therefore, the data stored in the valid backup sub-partition can be copied to the corresponding user sub-partition to ensure that the data of the user sub-partition is restored to a consistent and reliable state, thereby maintaining the normal operation of the system and the integrity of the data.

[0049] The data backup and recovery method applied to embedded devices of the present invention can process only the sub-partitions with inconsistent data when performing data recovery operations, without processing the data of the entire partition. Processing only the inconsistent sub-partition data is an efficient data recovery strategy. This strategy can significantly reduce the amount of data that needs to be transmitted, especially when the amount of data is large, saving time and reducing the use of storage resources. In addition, by processing only the inconsistent sub-partition data, the consistency between user data and backup data can be further ensured, avoiding the introduction of new errors or inconsistencies due to repeated copying.

[0050] See also Figure 3 As shown, it is a flow chart of the third embodiment of the data backup and recovery method applied to embedded devices of the present invention.

[0051] This embodiment, based on the first embodiment of the data backup and recovery method applied to embedded devices, describes in detail the recovery strategy adopted in the case where the data of the backup sub-partition is tampered. In this case, the embedded system first confirms that the data of the backup sub-partition is incomplete, and then determines whether the data of the user sub-partition has been tampered with through the verification file stored in the user sub-partition. If the data of the user sub-partition is tampered with, it is confirmed that the data stored in the user sub-partition is damaged, and additional measures need to be taken, such as restoring data from other backup sources or performing data repair to ensure that the data finally restored is reliable. If the data of the user sub-partition has not been tampered with, and the data of the user sub-partition is confirmed to be complete after comparing the data of the user sub-partition with the data of the backup sub-partition, the data of the user sub-partition can be directly restored to the backup sub-partition to ensure the consistency and integrity of the data.

[0052] In this embodiment, the data backup and recovery method applied to the embedded device includes: Step S100: In response to creating a user partition and a backup partition, data is stored in the user partition, and the data stored in the user partition is backed up in the backup partition.

[0053] The user partition includes several user sub-partitions, the backup partition includes several backup sub-partitions, the user sub-partitions and the backup sub-partitions correspond one-to-one, and the data stored in the user sub-partitions corresponds one-to-one to the data stored in the corresponding backup sub-partitions, and each of the user sub-partitions and each of the backup sub-partitions stores a verification file.

[0054] Step S221: When it is confirmed that the data consistency check is enabled, it is confirmed through the check file stored in the backup sub-partition that the data stored in the backup sub-partition is tampered with.

[0055] Step S222: judging whether the data stored in the user sub-partition is tampered with by using the verification file stored in the user sub-partition.

[0056] Specifically, the verification process of determining whether the data stored in the user sub-partition has been tampered with by using the verification file stored in the user sub-partition is similar to the verification process of determining whether the data stored in the backup sub-partition has been tampered with by using the verification file stored in the backup sub-partition, and examples will not be given here to describe them one by one.

[0057] Step S223: If tampering occurs, confirm that the data stored in the user sub-partition is damaged.

[0058] Step S224: If no tampering occurs, it is determined whether the verification file stored in the user sub-partition is consistent with the verification file stored in the corresponding backup sub-partition.

[0059] Step S225: If they are consistent, confirm that the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition.

[0060] Step S226: If they are inconsistent, the data stored in the user sub-partition is restored to the corresponding backup sub-partition, so that the data stored in the corresponding user sub-partition and the data stored in the backup sub-partition remain consistent.

[0061] The data backup and recovery method applied to embedded devices of the present invention, on the premise of confirming that the data of the backup sub-partition has been tampered with, confirms whether the data of the user sub-partition has been tampered with and the integrity through a verification file, and uses the data of the user sub-partition that has not been tampered with to restore the tampered data of the backup sub-partition.

[0062] Taking the firmware upgrade process of an embedded device as an example, the scenario corresponding to the second embodiment of the data backup and recovery method applied to an embedded device of the present invention is: during the system upgrade process, the data of the backup subpartition has been successfully backed up before the upgrade, and during the upgrade process, the data of the user subpartition is accidentally modified. For example, the user performs data operations during the system upgrade, resulting in changes in user data. The scenario corresponding to the third embodiment of the data backup and recovery method applied to an embedded device of the present invention is: during the system upgrade process, the data of the backup subpartition is tampered with before the upgrade, while the data of the user subpartition remains unchanged. For example, the backup data is maliciously tampered with during the storage process, but the user does not perform any operations during the upgrade.

[0063] See also Figure 4 As shown, it is a flow chart of the fourth embodiment of the data backup and recovery method applied to embedded devices of the present invention.

[0064] Compared with other embodiments of the data backup and recovery method applied to embedded devices, this embodiment details the data recovery and processing methods used when the embedded device enters three different modes (normal startup mode, update mode and forced partition check mode) after power-on.

[0065] In this embodiment, the data backup and recovery method applied to the embedded device includes: Step S100: In response to creating a user partition and a backup partition, data is stored in the user partition, and the data stored in the user partition is backed up in the backup partition.

[0066] The user partition includes several user sub-partitions, the backup partition includes several backup sub-partitions, the user sub-partitions and the backup sub-partitions correspond one-to-one, and the data stored in the user sub-partitions corresponds one-to-one to the data stored in the corresponding backup sub-partitions, and each of the user sub-partitions and each of the backup sub-partitions stores a verification file.

[0067] Step S231: in response to the embedded device being powered on and started, firstly erase and write the backup sub-partition and then determine the startup mode of the embedded device.

[0068] Specifically, after the embedded device is powered on, the backup sub-partition is first erased and written, and then it automatically determines whether to enter the normal startup mode, update mode or forced partition check mode. The settings of these three modes are intended to provide a flexible and secure data recovery mechanism for embedded devices to adapt to different usage scenarios. The normal startup mode focuses on fast startup and user experience, the update mode emphasizes data security and update success, and the forced partition check mode can ensure data consistency and fault recovery capabilities. Through this design, embedded devices can more effectively respond to various operational requirements and environmental changes.

[0069] Step S232: When the startup mode is the normal startup mode, the data stored in the user sub-partition and the data stored in the backup sub-partition are not verified.

[0070] Specifically, the normal startup mode is suitable for daily operation of embedded devices, and is intended to avoid additional verification operations during startup, thereby speeding up the startup speed and improving the user experience.

[0071] Step S233: When the startup mode is the update mode, first confirm that the data stored in the backup sub-partition has not been tampered with through the verification file, and then verify whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition through the verification file.

[0072] Specifically, the update mode is suitable for scenarios where embedded devices need to perform firmware upgrades or data updates. When performing firmware upgrades or data updates, it is very important to ensure the integrity and consistency of the data in the user partition and the backup partition in order to effectively prevent update failures or data loss caused by data tampering or data inconsistency.

[0073] Step S234: When the startup mode is the forced partition check mode, verify through the verification file whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition.

[0074] Specifically, in the forced partition check mode, when the embedded device starts, it will directly check whether the data of the user sub-partition is consistent with the data of the backup sub-partition, without considering the integrity of the backup sub-partition data. This mode is suitable for scenarios where data consistency needs to be strictly ensured, such as when the data is suspected to be tampered with or damaged. Through forced verification detection, problems can be discovered in time and corresponding measures can be taken. When an embedded device fails or anomalies, forced partition checking can help quickly locate the problem and ensure that the embedded device can quickly recover to a stable state.

[0075] It should be noted that there is no sequence relationship among step S232, step S233 and step S234, and they can be implemented one by one.

[0076] Step S235: If there is inconsistency, a data recovery operation is performed to make the data stored in the corresponding user sub-partition and the backup sub-partition consistent.

[0077] The following specifically describes the implementation steps of the data backup and recovery method applied to embedded devices of the present invention, including: 1. Backup initialization: Initialize the user partition (data) and backup partition (datb) and their sub-partitions (such as usr partition, app partition, web partition, and model partition); optimize the storage path and backup strategy according to the importance of the sub-partitions, for example, decide whether to support mandatory partition checking.

[0078] 2. Data consistency check: After the embedded device is powered on, the backup partition (datb) is first erased. Then, the uboot program recognizes the upgrade command and passes the parameters to the command line. The kernel determines whether it is in update mode, normal start mode, or forced partition check mode based on these parameters.

[0079] In normal startup mode, the embedded device will start up according to the normal process without performing any data verification or upgrade operations.

[0080] In update mode, the system will call the DB_Same function to verify the backup sub-partition data under the backup partition to confirm that the data has not been tampered with. If the data has not been tampered with, the system will continue to verify the user sub-partition data under the user partition (data) to check the difference (consistency) between the two sub-partition data. Only the sub-partition data involving inconsistencies will be upgraded (restore update), and the sub-partition data that remains consistent will not be upgraded, which can avoid upgrade failures and partition anomalies to a certain extent.

[0081] In the forced partition check mode, each time the device is powered on, a difference check will be performed directly between the sub-partition data under the user partition and the backup partition. Similar to the update mode, only the sub-partition data involving inconsistencies will be upgraded, while the sub-partition data that remains consistent will not be upgraded.

[0082] Through this design, the embedded device can flexibly handle data consistency verification and upgrade processes according to different startup modes, ensuring data integrity during backup and recovery.

[0083] 3. Dynamic recovery and mounting: After completing the data consistency test, the system will call the DB_Recovery function to recover the data of the target sub-partition. At the same time, the DB_Mount function is used to dynamically mount the recovered sub-partition to ensure the normal operation of the system.

[0084] 4. Automated processing: After completing the data consistency check, the system can automatically trigger the data recovery process and complete the dynamic mounting of the recovered sub-partitions.

[0085] The data backup and recovery method applied to embedded devices in this embodiment can ensure that the system can access data normally during the upgrade process, confirm the integrity of the backup data before the upgrade, and dynamically select the optimal recovery or backup strategy according to the actual scenario to ensure data consistency during the backup and recovery process.

[0086] See also Figure 5 As shown, it is a flow chart of the fifth embodiment of the data backup and recovery method applied to embedded devices of the present invention.

[0087] Compared with other embodiments of the data backup and recovery method applied to embedded devices, this embodiment adds the steps of automatically recovering inconsistent sub-partition data according to a preset priority order, dynamically mounting the sub-partition of the recovered data to a preset mount point, and confirming that the data upgrade of the backup partition is successful.

[0088] In this embodiment, the data backup and recovery method applied to the embedded device includes: Step S100: In response to creating a user partition and a backup partition, data is stored in the user partition, and the data stored in the user partition is backed up in the backup partition.

[0089] The user partition includes several user sub-partitions, the backup partition includes several backup sub-partitions, the user sub-partitions and the backup sub-partitions correspond one-to-one, and the data stored in the user sub-partitions corresponds one-to-one to the data stored in the corresponding backup sub-partitions, and each of the user sub-partitions and each of the backup sub-partitions stores a verification file.

[0090] Step S201: When it is confirmed that the data consistency check is turned on, the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition through the verification file; if they are inconsistent, the data recovery operation is automatically performed in sequence according to the preset priority order through the script to ensure that the data stored in the corresponding user sub-partition and the backup sub-partition remain consistent.

[0091] Specifically, the automatic data recovery operation through scripts can reduce human intervention and ensure that the normal operation of the system can be restored quickly and reliably in the event of a failure. The process of automatically recovering inconsistent sub-partition data through scripts usually includes: the script generates a priority list according to the order of preset priorities. This priority list contains the names of all sub-partitions that need to be recovered, and is arranged from high to low in terms of priority (importance). The script traverses the priority list in turn and performs recovery operations for each inconsistent sub-partition. The recovery operation can be to copy the data of the backup sub-partition to the user sub-partition, or to restore the data of the user sub-partition to the backup sub-partition, depending on the recovery strategy. During the data recovery process, the script will also automatically record the operation and results of each step for subsequent auditing and troubleshooting. After the recovery operation is completed, the script can also automatically send a notification or update the status to inform the system or user of the recovery result.

[0092] Specifically, by presetting the priority order according to the importance of the data, it can ensure that the most important or most critical data sub-partitions are restored first, reducing the impact on system operation. During the recovery process, giving priority to important data can reduce the risk of system failure caused by data inconsistency and ensure that the system can maintain high availability during the recovery period. And by performing data recovery in the order of preset priorities, system resources can be used more effectively and unnecessary operations can be avoided. For example, if a high-priority sub-partition has been successfully recovered, subsequent low-priority sub-partitions may no longer need to be recovered. In addition, in addition to performing data recovery in the order of preset priorities, the order of priorities can also be dynamically adjusted. The system monitors the data status of each sub-partition in real time and dynamically adjusts the recovery strategy based on the inconsistencies detected in real time. For example, when the data inconsistency of a low-priority sub-partition is high, the system can temporarily increase the recovery priority of the partition to ensure the rapid recovery of critical data. This dynamic adjustment capability makes the recovery process more flexible and efficient, and can respond to different failure situations in a timely manner, further improving the overall availability of the system.

[0093] In some embodiments of the present application, the user sub-partition and the backup sub-partition each include a usr partition, an app partition, a web partition, and a model partition; The usr partition, app partition, web partition and model partition are sorted in the order of preset priorities, namely app partition, usr partition, model partition and web partition.

[0094] Specifically, the usr partition, app partition, web partition and model partition correspond to the user data area, application resource area, web page data area and model resource area respectively. Of course, other sub-partitions can also be set according to the specific needs and application scenarios of the system, such as: Config partition: used to store system configuration files and parameter settings to ensure that the system can run normally according to the preset configuration.

[0095] Log partition: used to store system logs and operation records to facilitate subsequent auditing and troubleshooting.

[0096] temp partition: used to store temporary files and cache data to improve system operation efficiency.

[0097] Media partition: used to store multimedia resources, such as pictures, audio, and video files, to support the multimedia functions of applications.

[0098] The settings of these sub-partitions can be adjusted according to specific business needs, data management strategies and system architecture to achieve more efficient data management and resource utilization. Among them, app partition, usr partition, model partition and web partition are arranged in order from high to low data importance.

[0099] In some embodiments of the present application, the verification file includes an MD5 verification value.

[0100] Specifically, the MD5 checksum is a commonly used hash value. The process of calculating the MD5 checksum includes: dividing the input data into blocks, which are usually 512 bits; performing a series of bit operations and logical operations on each data block, and finally generating a 128-bit hash value. The MD5 checksum is often used to verify whether the file has been tampered with or damaged during transmission or storage. By comparing the MD5 value of the original file and the MD5 value of the received file, it can be determined whether the files are consistent, and thus whether the file data has been tampered with or damaged.

[0101] Step S301: If it is confirmed that the data recovery operation is completed, a mount command is called to dynamically mount the sub-partition of the recovered data to a preset mount point.

[0102] Specifically, after the data recovery operation is completed, the sub-partition of the recovered data needs to be dynamically mounted to the preset mount point. This step ensures that the system can smoothly access the recovered data, thereby ensuring the normal operation of the system.

[0103] Specifically, the steps of dynamically mounting the sub-partition of the recovery data to the preset mount point include: first, determining the name of the sub-partition to be mounted (such as / dev / app) and the preset mount point (such as / mnt / recovery). If the preset mount point does not exist yet, use sudo mkdir -p / mnt / recovery to create it. Next, use the sudo mount / dev / app / mnt / recovery command to mount the sub-partition to the preset mount point. Finally, you can also use the df -h command to verify whether the mount is successful. In order to achieve automation, these steps can be written into a script for easy reuse and management.

[0104] Step S302: If an upgrade instruction is received, first confirm that the data in the backup partition is successfully upgraded, and then perform an upgrade operation on the data in the user partition.

[0105] Specifically, the data upgrade success of the backup partition indicates that the data of the backup partition has been updated. After confirming that the data upgrade of the backup partition is successful, the data of the user partition is upgraded, which can ensure that the backup data is complete and available before the user data upgrade operation is performed, thereby reducing the risk of user data upgrade failure.

[0106] The data backup and recovery method applied to the embedded device in this embodiment proposes a data backup and recovery mechanism based on dual partition backup, which can efficiently and safely realize the backup and recovery of embedded system data, and mainly includes the following key technologies: Partition backup: Divide the stored data into different user sub-partitions (such as usr partition, app partition, web partition and model partition) in the user partition (data partition); each user sub-partition independently stores its verification file (such as MD5 verification file); and create a backup partition (datb partition), which also includes backup sub-partitions.

[0107] Difference check: Use MD5 checksum and difference comparison tools to verify whether the data of the backup sub-partition is consistent with the data of the user sub-partition; trigger the recovery process in time by checking the difference. When the system is upgraded, the datb backup partition will be erased first to ensure that the datb backup partition is upgraded successfully before the data user partition is upgraded to avoid bricking due to upgrade failure and ensure the integrity of data during the backup and recovery process.

[0108] Dynamic recovery: Dynamically select recovery strategies based on partition priorities; implement automatic recovery operations through scripts to reduce human intervention.

[0109] Mount management: Dynamically mount backup partitions in normal or abnormal conditions; achieve seamless operation after automatic data switching and recovery.

[0110] This data backup and recovery method for embedded devices is suitable for scenarios requiring data consistency, efficient backup and recovery operations in embedded systems, and is widely used in: 1. Firmware upgrade of embedded devices.

[0111] 2. Data integrity assurance and recovery.

[0112] 3. Partition data backup and verification mechanism based on embedded system.

[0113] The data backup and recovery method applied to embedded devices in this embodiment proposes a sub-partition backup and recovery mechanism for embedded systems. This mechanism can not only ensure the success of embedded device firmware upgrades, protect data security and system stability during the upgrade process, but also significantly improve the operational efficiency and data consistency of data storage.

[0114] The following is an embodiment of the electronic device provided by the present invention. The embodiment of the electronic device and the embodiment of the data backup and recovery method applied to the embedded device belong to the same concept, and the details not described in detail in the embodiment of the electronic device can refer to the embodiment of the data backup and recovery method applied to the embedded device.

[0115] See also Figure 6 As shown, it is a schematic diagram of the structure of an electronic device in a hardware operating environment involved in an embodiment of the present invention.

[0116] In this embodiment, an electronic device includes: Memory 1005, used to store program instructions; and The processor 1001 is used to execute the program instructions to implement the steps of the data backup and recovery method applied to the embedded device as described above.

[0117] The electronic device of the embodiment of the present invention can be a computing device such as a desktop computer, a notebook, a palm computer, and a server. Figure 6As shown, the electronic device may include: a processor 1001 (such as a CPU), a network interface 1004, a user interface 1003, a memory 1005 and a communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit, such as a keyboard (Keyboard), and the user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0118] Those skilled in the art will understand that Figure 6 The electronic device structure shown in the figure does not constitute a limitation of the electronic device, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0119] like Figure 6 As shown, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module and a computer program.

[0120] exist Figure 6 In the electronic device shown, the network interface 1004 is mainly used to connect to the background server and communicate data with the background server; the user interface 1003 is mainly used to connect to the client (user end) and communicate data with the client; and the processor 1001 can be used to call the computer program stored in the memory 1005. When the computer program is called and executed by the processor 1001, the steps of the data backup and recovery method applied to the embedded device are implemented.

[0121] The following is an embodiment of the computer-readable storage medium provided by the present invention. The embodiment of the computer-readable storage medium and the embodiment of the data backup and recovery method and electronic device applied to the above-mentioned embedded device belong to the same concept, and the details not described in detail in the embodiment of the computer-readable storage medium can refer to the embodiment of the data backup and recovery method and electronic device applied to the above-mentioned embedded device.

[0122] In this embodiment, a computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps of the data backup and recovery method applied to an embedded device as described above are implemented.

[0123] Since the electronic device and computer-readable storage medium of the present invention can both implement the steps of the above-mentioned data backup and recovery method applied to embedded devices, they at least have all the beneficial effects brought by the technical solutions of the above-mentioned step embodiments of the data backup and recovery method applied to embedded devices, which are not described one by one here.

[0124] The above description is only a partial or preferred embodiment of the present invention. Neither the text nor the drawings can limit the scope of protection of the present invention. All equivalent structural changes made by using the contents of the present invention specification and drawings under the overall concept of the present invention, or direct / indirect application in other related technical fields are included in the scope of protection of the present invention.

[0125] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

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

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

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

[0129] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A data backup and recovery method applied to an embedded device, characterized in that: include: In response to creating a user partition and a backup partition, data is stored in the user partition, and the data stored in the user partition is backed up in the backup partition; wherein the user partition includes a plurality of user sub-partitions, the backup partition includes a plurality of backup sub-partitions, the user sub-partitions and the backup sub-partitions correspond one-to-one, and the data stored in the user sub-partitions corresponds one-to-one to the data stored in the corresponding backup sub-partitions, and each of the user sub-partitions and each of the backup sub-partitions stores a verification file; When it is confirmed to start the data consistency check, the verification file is used to verify whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; if they are inconsistent, a data recovery operation is performed to make the data stored in the corresponding user sub-partition and the backup sub-partition consistent.

2. The data backup and recovery method for embedded devices according to claim 1, characterized in that: Verifying through the verification file whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; If they are inconsistent, data recovery operations are performed, including: Confirming, through the verification file stored in the backup sub-partition, that the data stored in the backup sub-partition has not been tampered with; Determine whether the verification file stored in the backup sub-partition is consistent with the verification file stored in the corresponding user sub-partition; If yes, confirming that the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; If not, the data stored in the backup sub-partition is copied to the corresponding user sub-partition.

3. The data backup and recovery method for embedded devices according to claim 1, characterized in that: Verifying through the verification file whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; If they are inconsistent, data recovery operations are performed, including: Confirming, through a verification file stored in the backup sub-partition, that data stored in the backup sub-partition has been tampered with; Determining whether data stored in the user sub-partition has been tampered with by using the verification file stored in the user sub-partition; If tampering occurs, confirm that the data stored in the user sub-partition is damaged; If no tampering occurs, determining whether the verification file stored in the user sub-partition is consistent with the verification file stored in the corresponding backup sub-partition; If they are consistent, confirm that the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition; If they are inconsistent, the data stored in the user sub-partition is restored to the corresponding backup sub-partition.

4. The data backup and recovery method for embedded devices according to claim 1, characterized in that: When it is confirmed that the data consistency check is turned on, the verification file is used to verify whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition, including: In response to the embedded device being powered on and started, firstly erasing the backup sub-partition and then determining the startup mode of the embedded device; When the startup mode is the normal startup mode, the data stored in the user sub-partition and the data stored in the backup sub-partition are not verified; When the startup mode is the update mode, firstly confirming that the data stored in the backup sub-partition has not been tampered with by using the verification file, and then verifying whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition by using the verification file; When the startup mode is the forced partition check mode, the verification file is used to verify whether the data stored in the user sub-partition is consistent with the data stored in the corresponding backup sub-partition.

5. The data backup and recovery method for embedded devices according to claim 1, characterized in that: After the data recovery operation is performed, the method further includes: If the data recovery operation is confirmed to be completed, the mount command is called to dynamically mount the sub-partition of the recovered data to the preset mount point; If an upgrade instruction is received, first confirm that the data in the backup partition is successfully upgraded, and then perform an upgrade operation on the data in the user partition.

6. The data backup and recovery method for embedded devices according to claim 1, characterized in that: The data recovery operation includes: automatically and sequentially performing the data recovery operation in the order of preset priorities through a script.

7. The data backup and recovery method for embedded devices according to claim 6, characterized in that: The user sub-partition and the backup sub-partition both include a usr partition, an app partition, a web partition and a model partition; The usr partition, app partition, web partition and model partition are sorted in the order of preset priorities, namely app partition, usr partition, model partition and web partition.

8. The data backup and recovery method for embedded devices according to claim 1, characterized in that: The verification file includes an MD5 verification value.

9. An electronic device, characterized in that: include: A memory for storing program instructions; as well as A processor is used to execute the program instructions to implement the steps of the data backup and recovery method applied to an embedded device as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps of the data backup and recovery method applied to an embedded device as described in any one of claims 1 to 8 are implemented.

Images