Embedded device partition file monitoring and backup method and system
By adopting file whitelisting mechanism and secondary backup partitions in the embedded storage management system, real-time monitoring and generation of verification files is solved, and the problems of data loss and low backup efficiency in the existing technology are achieved, and efficient and secure file protection is achieved.
Patent Information
- Application Number
- CN202510447295.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-10
- Publication Date
- 2025-07-25
AI Technical Summary
In the prior art, when the embedded storage management system protects files within the partition, there is a risk of data being lost in hardware abnormalities, low backup efficiency, lack of accuracy and fault tolerance mechanism, and the backup process may contain unnecessary files, resulting in high complexity and error rate.
The file whitelist mechanism is used to monitor files that need to be backed up in real time, use the inotify mechanism to detect file changes, and immediately back up to the primary backup partition when changes are made, set up the secondary backup partition, generate verification files to ensure data validity, and manage it through the main control chip integration module.
Real-time and accurate file backup is realized, reducing the risk of data loss, improving backup efficiency and accuracy, providing dual guarantees, ensuring data security and integrity.
Smart Images
Figure CN120371608A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of embedded storage management, and in particular to a method and system for real-time monitoring of files in a storage device partition, automatically backing up when a file changes, and automatically recovering when a monitored file is lost, so as to ensure the security and integrity of data. Background Art
[0002] Embedded storage management is a technology and method for comprehensively controlling storage resources in an embedded system. It mainly includes reasonably allocating memory and external storage space and reclaiming them after a task is completed; converting logical addresses into physical addresses to ensure correct access by the processor; using hardware and software means to prevent illegal access and protect data security; managing data reading and writing, maintaining consistency, and performing backup and recovery. Through management methods such as partitioning, caching, and file systems, resource utilization is improved, system stability is guaranteed, system performance is enhanced, limited storage resources can meet multi-task requirements, data access is optimized, and efficient operation of the embedded system is ensured.
[0003] In the protection of files in a partition, "backup only when read-only" is a specific data backup strategy, which is briefly described from several aspects including monitoring, triggering, execution, and completion processing: Monitoring the partition status: A special program is used to check the partition status in real time or periodically, adopting a combination of polling and event-driven methods, obtaining status information through system low-level interfaces or file system functions, and timely judging whether the partition becomes read-only. Triggering the backup operation: Once it is detected that the partition becomes read-only, the program checks whether system resources such as CPU, memory, storage capacity, and network status meet the conditions. If they are met, according to a preset strategy, a backup tool or software is called to determine the backup file range and the target storage location, and the backup task is started. Executing the backup process: The backup program reads data from the read-only partition in blocks of a certain block size, and through a data transmission channel, transfers the data to a specified backup storage device such as a disk or a tape library according to the transmission protocol. At the same time, data verification is performed, such as calculating checksum, hash value, etc. to ensure data integrity, and information about the backup process is recorded. Backup completion processing: After the backup is completed, the system updates the partition backup status record related parameters and results, and sends a notification to the administrator or user. The backup data is named and classified for storage according to rules, and the retention time and deletion rules are determined according to the retention policy for subsequent management and data recovery.
[0004] In existing data storage management systems, the protection of files within a partition usually adopts the method of periodic full backup or backup when it is monitored that the partition becomes read-only. However, these methods have certain limitations. 1. When an exception occurs in the storage device, such as the partition not becoming read-only before the device restarts, but there are hardware abnormal behaviors such as unstable power supply and repeated power failures during startup, resulting in the partition being accidentally damaged and formatted, data may not be backed up in time, leading to data loss. 2. The backup process often involves the backup of the entire directory rather than specific files, which results in low backup efficiency and occupies a large amount of storage space. 3. The lack of an effective whitelist mechanism makes the backup process may include unnecessary files, increasing the complexity and error rate of the backup. 4. If the backup partition itself becomes read-only, there is no further fault tolerance mechanism.
[0005] Therefore, a more efficient, real-time, accurate, and better fault-tolerant file monitoring and backup method is needed. Summary of the Invention
[0006] I. Technical Solution
[0007] An embedded device partition file monitoring and backup method, characterized by comprising the following steps:
[0008] Set a file whitelist, the whitelist contains the file paths to be monitored, and the whitelist can be iteratively updated according to requirements, adding or deleting specific file paths or names;
[0009] Utilize the file system monitoring mechanism to monitor the changes of files in the whitelist in real time, and the file system monitoring mechanism includes but is not limited to the inotify mechanism;
[0010] When it is detected that a file in the whitelist has changed, immediately back up the file to the primary backup partition;
[0011] If a file in the whitelist is deleted, automatically delete the corresponding backup file in the primary backup partition;
[0012] When the primary backup partition becomes read-only, immediately back up the primary backup partition to the secondary backup partition.
[0013] Further preferably, it further includes a partition exception handling step:
[0014] During the application initialization process, check the status of the monitored partition. If it is detected that the monitored file exists in the backup partition but does not exist in the monitored partition, attempt to restore the file from the primary backup partition to the monitored partition;
[0015] If the data in the primary backup partition cannot be restored, attempt to restore the data from the secondary backup partition;
[0016] After the initialization recovery is completed, clear the secondary backup partition.
[0017] Further preferably, a verification file is generated when backing up a file. The verification file is used to verify the validity of the backup file during recovery, and the naming rule of the verification file is: based on the backup path of the file to be backed up, starting with "." and adding a specific hash algorithm suffix.
[0018] Further preferably, the monitoring process is implemented based on directories. A monitoring directory list is preset, and the directories where the files in the whitelist are located are all included in the monitoring directory list; during program initialization, traverse the whitelist to perform initialization backup checks. If the files in the whitelist exist but the backups of these files do not exist in the backup partition, perform initialization backups.
[0019] Further preferably, obtain the partition status through periodic queries. If it is found that the monitored partition becomes read-only, notify the application program to stop writing file system files and vote for a restart; if it is found that the primary backup partition becomes read-only, back up the content of the primary backup partition to the secondary backup partition and trigger a restart to attempt to recover the abnormal partition.
[0020] Further preferably, it includes:
[0021] A whitelist setting module for setting a whitelist containing the paths of files to be monitored and supporting iterative updates of the whitelist;
[0022] A file monitoring module that uses the file system monitoring mechanism to monitor the changes of files in the whitelist in real time;
[0023] A backup execution module that backs up files to the primary backup partition when the files change, deletes the corresponding backup files in the primary backup partition when the files are deleted, and backs up the primary backup partition to the secondary backup partition when the primary backup partition becomes read-only;
[0024] An exception handling module for checking the partition status during application initialization. When the monitored file exists in the backup partition but does not exist in the monitored partition, recover the file from the primary backup partition or the secondary backup partition, and clear the secondary backup partition after the recovery is completed;
[0025] A verification file generation module that generates a verification file for verifying the validity of the backup file when backing up the file;
[0026] A partition status monitoring module that periodically queries the partition status and performs corresponding notification, backup, and restart operations when the monitored partition or the primary backup partition becomes read-only.
[0027] Further preferably, the whitelist setting module, file monitoring module, backup execution module, exception handling module, verification file generation module, and partition status monitoring module are integrated into the main control chip of the embedded device, and the main control chip is connected to the storage partition and backup partition through a data bus and a control bus.
[0028] Further preferably, the file monitoring module monitors file changes based on the inotify mechanism, the backup execution module, exception handling module, and partition status monitoring module operate according to preset program logic, and the verification file generation module generates verification files using a specific hash algorithm.
[0029] II. Beneficial Effects
[0030] Real-time backup: By monitoring file changes in real time and backing up immediately, it maximally ensures that data is backed up before partition anomalies, significantly reducing the risk of data loss.
[0031] Secondary backup guarantee: Setting a secondary backup partition provides double guarantee for data, further enhancing data security.
[0032] Whitelist mechanism: The whitelist mechanism enables precise backup of discrete files, improving backup efficiency and accuracy and reducing unnecessary backup operations.
[0033] Verification mechanism: Verification files are generated when backing up files, ensuring the validity of files during recovery and avoiding recovery failures caused by file corruption. Description of the Drawings
[0034] Figure 1 Flowchart of the method for monitoring and backing up partition files of an embedded device;
[0035] Figure 2 Schematic diagram of the partitions involved in monitoring, backup, and recovery and the main operations;
[0036] Figure 3 Flowchart of monitoring, backing up, and deleting backups of partition directories / files;
[0037] Figure 4 Flowchart of monitoring partition status and triggering recovery;
[0038] Figure 5 Flowchart of file backup and recovery; Detailed Implementation Modes
[0039] A method for monitoring and backing up partition files of an embedded device includes the following steps:
[0040] S101. Set up a file whitelist. The whitelist contains file paths to be monitored, and the whitelist can be iteratively updated as needed to add or delete specific file paths or names.
[0041] S102. Use the file system monitoring mechanism to monitor the changes of files in the whitelist in real time. The file system monitoring mechanism includes but is not limited to the inotify mechanism.
[0042] S103. When it is detected that a file in the whitelist has changed, immediately back up the file to the primary backup partition.
[0043] S104. If a file in the whitelist is deleted, automatically delete the corresponding backup file in the primary backup partition.
[0044] S105. When the primary backup partition becomes read-only, immediately back up the primary backup partition to the secondary backup partition.
[0045] Specifically, it also includes the partition exception handling steps:
[0046] During the application initialization process, check the status of the monitored partition. If it is detected that the monitored file exists in the backup partition but does not exist in the monitored partition, try to restore the file from the primary backup partition to the monitored partition.
[0047] If the data in the primary backup partition cannot be restored, try to restore the data from the secondary backup partition.
[0048] After the initialization restoration is completed, clear the secondary backup partition.
[0049] Specifically, a verification file is generated when backing up the file. The verification file is used to verify the validity of the backup file during restoration, and the naming rule of the verification file is: based on the backup path of the file to be backed up, starting with "." and adding the specific hash algorithm suffix.
[0050] Specifically, the monitoring process is implemented based on directories. A monitoring directory list is preset in advance, and the directories where the files in the whitelist are located are all included in the monitoring directory list; during the program initialization, traverse the whitelist to perform the initialization backup check. If the file in the whitelist exists but there is no backup of the file in the backup partition, perform the initialization backup.
[0051] Specifically, obtain the partition status by periodic query. If it is found that the monitored partition becomes read-only, notify the application program to stop the file system file write operation and vote for a restart; if it is found that the primary backup partition becomes read-only, back up the content of the primary backup partition to the secondary backup partition and trigger a restart to try to restore the abnormal partition.
[0052] Specifically, it includes:
[0053] A whitelist setting module, which is used to set a whitelist including file paths to be monitored and supports iterative update of the whitelist;
[0054] A file monitoring module, which uses a file system monitoring mechanism to monitor changes of files in the whitelist in real time;
[0055] A backup execution module, which backs up files to a primary backup partition when the files change, deletes corresponding backup files in the primary backup partition when the files are deleted, and backs up the primary backup partition to a secondary backup partition when the primary backup partition becomes read-only;
[0056] An exception handling module, which is used to check the partition status during application initialization. When the monitored file exists in the backup partition but does not exist in the monitored partition, the file is restored from the primary backup partition or the secondary backup partition, and the secondary backup partition is cleared after the restoration is completed;
[0057] A verification file generation module, which generates a verification file for verifying the validity of the backup file when backing up the file;
[0058] A partition status monitoring module, which periodically queries the partition status and performs corresponding notification, backup and restart operations when the monitored partition or the primary backup partition becomes read-only.
[0059] Specifically, the whitelist setting module, the file monitoring module, the backup execution module, the exception handling module, the verification file generation module and the partition status monitoring module are integrated in the main control chip of the embedded device, and the main control chip is connected to the storage partition and the backup partition through a data bus and a control bus.
[0060] Specifically, the file monitoring module realizes the monitoring of file changes based on the inotify mechanism, the backup execution module, the exception handling module and the partition status monitoring module operate according to preset program logics, and the verification file generation module generates a verification file by using a specific hash algorithm.
[0061] Specifically, partition backup:
[0062] The program pre-sets a file whitelist and a monitoring directory list. The whitelist stipulates that when a write event occurs to a file therein, it needs to be backed up, and when a delete event occurs, the backup needs to be deleted, and file events not in the whitelist do not need to be processed. The monitoring directory list contains a list of directories that the monitoring program needs to monitor, and the directories where the files in the whitelist are located should all be in this list. The monitoring is implemented based on the directory because events such as creation, modification and deletion of files under the directory can be sensed, and monitoring based on the directory can effectively capture changes of the files concerned in the whitelist and avoid the problem that monitoring cannot be created when the file does not exist based on file monitoring.
[0063] When the program is initialized, it traverses the entire whitelist to perform an initialization backup check ("initial backup check"). If the file in the whitelist exists, but the backup of the file does not exist in the backup partition, an initialization backup is performed. This ensures that even if the file is not modified subsequently, there is an initial backup. For devices upgraded via OTA, the whitelist files can also be backed up, rather than just backing up newly generated content.
[0064] Based on the predefined whitelist and monitored directories, and after completing the "initial backup check", start monitoring all directories in the directory list. During the monitoring process, if a file in the monitored directory is modified by the application, after the monitoring logic captures the event, it identifies the event and performs a whitelist verification on the file that generated the event. If it is a concerned file in the whitelist and concerned write, delete, etc. events occur, further backup and backup deletion processing are performed.
[0065] If the device restarts abnormally just after the program finishes backing up, and the partition being monitored before the restart is undergoing frequent write operations, which may cause damage to the file system partition, the system will format the damaged partition during restart. At this time, due to the existence of backup files, after the monitored partition returns to normal, the lost files can be restored at any time, without having an obvious impact on the business, which is difficult to achieve with traditional periodic backup schemes and backup schemes when the partition becomes read-only.
[0066] Specifically, the naming rule for backup files:
[0067] The naming rule for backup files is: backup partition path + full path of the monitored file. For example, if the monitored files are located in / p1 and / p2 partitions respectively, and the files are / p1 / dir1 / file1 and / p2 / dir2 / file2, and the backup partition is / backup, the backup files generated in the backup partition and the verification files for the backup files are: / backup / p1 / dir1 / file1, / backup / p1 / dir1 / .file1.hash, / backup / p2 / dir2 / file2, / backup / p2 / dir2 / .file2.hash. Among them, the verification file starts with ".", indicating a hidden file, and the suffix is the specific hash algorithm. This naming method facilitates confirming the source of the backup file in the backup partition, making file backup and backup file restoration more convenient.
[0068] Specifically, partition status monitoring and secondary backup:
[0069] Obtain the partition status by periodic query. If it is found that the monitored partition becomes read-only, trigger a restart as early as possible to attempt recovery. If it is found that the primary backup partition becomes read-only, back up the content of the primary backup partition to the secondary backup partition, and trigger a restart as early as possible to attempt to recover the abnormal partition.
[0070] Specifically, partition status monitoring and trigger for recovery:
[0071] Periodically query the partition status through the file system status-related interface. If it is found that the partition becomes read-only, notify the application to stop writing operations to the file system files and vote for a restart. If the vote passes, perform the restart operation.
[0072] Specifically, file loss and backup recovery:
[0073] During the restart process, if the system can normally mount the partition, the partition is not damaged and the read / write state is restored; if the system cannot normally mount the partition, the partition will be formatted in an attempt to recover, and files will be lost at this time. When the partition is formatted and remounted, if the application recognizes that the backup files are missing, it will attempt to recover the file backups in the whitelist from the backup partition.
[0074] This specific embodiment is only an interpretation of the invention and is not a limitation on the invention. After reading this specification, those skilled in the art can make modifications to this embodiment without creative contributions as needed, but as long as they are within the protection scope of the invention, they are protected by the patent law.
Claims
1. An embedded device partition file monitoring and backup method, characterized in that, It includes the following steps: Step 1: Set up a file whitelist. The whitelist contains file paths to be monitored, and the whitelist can be iteratively updated as needed to add or delete specific file paths or names; Step 2: Use the file system monitoring mechanism to monitor the changes of files in the whitelist in real time. The file system monitoring mechanism includes but is not limited to the inotify mechanism; Step 3: When it is detected that a file in the whitelist has changed, immediately back up the file to the primary backup partition; Step 4: If a file in the whitelist is deleted, automatically delete the corresponding backup file in the primary backup partition; Step 5: When the primary backup partition becomes read-only, immediately back up the primary backup partition to the secondary backup partition.
2. The method for monitoring and backing up partition files of an embedded device according to claim 1, wherein, It also includes a partition exception handling step: During the application initialization process, check the status of the monitored partition. If it is detected that the monitored file exists in the backup partition but does not exist in the monitored partition, try to restore the file from the primary backup partition to the monitored partition; If the data in the primary backup partition cannot be restored, try to restore the data from the secondary backup partition; After the initialization restoration is completed, clear the secondary backup partition.
3. The method for monitoring and backing up partition files of an embedded device according to claim 1, wherein Generate a verification file when backing up a file. The verification file is used to verify the validity of the backup file during restoration, and the naming rule of the verification file is: based on the backup path of the file to be backed up, start with "." and add the specific hash algorithm suffix.
4. The method for monitoring and backing up partition files of an embedded device according to claim 1, wherein The monitoring process is implemented based on directories. A monitoring directory list is preset in advance, and the directories where the files in the whitelist are located are all included in the monitoring directory list; during program initialization, traverse the whitelist to perform an initialization backup check. If a file in the whitelist exists but there is no backup of the file in the backup partition, perform an initialization backup.
5. The method for monitoring and backing up partition files of an embedded device according to claim 1, characterized in that, Obtain the partition status through periodic queries. If it is found that the monitored partition becomes read-only, notify the application program to stop writing file system files and vote for a restart; If it is found that the primary backup partition becomes read-only, back up the content of the primary backup partition to the secondary backup partition and trigger a restart to try to recover the abnormal partition.
6. An embedded device partition file monitoring and backup system, characterized in that, It includes: A whitelist setting module, used to set up a whitelist containing file paths to be monitored and support the iterative update of the whitelist; A file monitoring module, which uses the file system monitoring mechanism to monitor the changes of files in the whitelist in real time; A backup execution module, which backs up a file to the primary backup partition when the file changes, deletes the corresponding backup file in the primary backup partition when the file is deleted, and backs up the primary backup partition to the secondary backup partition when the primary backup partition becomes read-only; An exception handling module, used to check the partition status during application initialization. When the monitored file exists in the backup partition but does not exist in the monitored partition, restore the file from the primary backup partition or the secondary backup partition and clear the secondary backup partition after the restoration is completed; A verification file generation module, which generates a verification file for verifying the validity of the backup file when backing up a file; A partition status monitoring module, which periodically queries the partition status and performs corresponding notification, backup, and restart operations when the monitored partition or the primary backup partition becomes read-only.
7. The embedded device partition file monitoring and backup system according to claim 6, wherein The whitelist setting module, file monitoring module, backup execution module, exception handling module, verification file generation module, and partition status monitoring module are integrated into the main control chip of the embedded device, and the main control chip is connected to the storage partition and backup partition through a data bus and a control bus.
8. The embedded device partition file monitoring and backup system according to claim 6, characterized in that The file monitoring module realizes the monitoring of file changes based on the inotify mechanism. The backup execution module, exception handling module, and partition status monitoring module operate according to the preset program logic, and the verification file generation module generates a verification file using a specific hash algorithm.