A data recovery method and apparatus

Abstract

This application discloses a data recovery method and apparatus, relating to the field of storage technology. Existing solutions suffer from long recovery times and high computational resource consumption when recovering stored data after an abnormal device restart. This application is applied to security equipment and includes: after an abnormal device restart, scanning backwards from a target location on the storage medium; wherein the storage medium stores self-describing data frames, which are constructed based on multimedia data frames and corresponding descriptive information, the descriptive information being used to locate and parse the multimedia data frames; based on the scanned descriptive information, locating the last fully written target self-describing data frame before the interruption, and performing data recovery based on the target self-describing data frame. This application can quickly and accurately recover stored data after an abnormal device restart and reduces the computational resource consumption during the recovery process.

Description

Technical Field

[0001] This invention relates to the field of storage technology, and in particular to a data recovery method and device. Background Technology

[0002] In the data storage scenarios of security equipment, security equipment needs to continuously collect and store multimedia data such as audio and video for a long time. Moreover, security equipment is often deployed in environments with complex power supply conditions, and abnormal situations such as abnormal power outages and abnormal restarts of equipment occur frequently.

[0003] Currently, security equipment commonly uses MP4 and other file encapsulation formats to store multimedia data, or raw stream storage methods based on standard encapsulation protocols such as PS (Program Stream) and TS (Transport Stream). However, when using MP4 or similar file encapsulation formats, a sudden power outage can easily corrupt the entire recording file, rendering it unreadable and resulting in the loss of all data recorded before the power outage. Using raw stream storage methods with standard encapsulation protocols requires encapsulation and parsing of the bitstream during both storage and recovery, consuming significant computational resources and making it unsuitable for security equipment with limited computing power. Furthermore, traditional solutions typically rely on file system metadata to locate the power outage recovery point. After an abnormal device restart, the entire file structure needs to be re-parsed to complete the repair, resulting in time-consuming and poorly performed recovery, with the last data written before the power outage often being difficult to retrieve.

[0004] In summary, how to quickly and accurately restore stored data after an abnormal device restart, while reducing the computational resource consumption during the recovery process, is a problem that needs to be solved. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a data recovery method and device that can quickly and accurately recover stored data after an abnormal device restart, while reducing the computational resource consumption during the recovery process. The specific solution is as follows: This application provides a data recovery method for use in security equipment, including: After the device restarts abnormally, a scan is performed backward from the target location on the storage medium; wherein, the storage medium stores self-describing data frames, which are constructed based on multimedia data frames and corresponding descriptive information, and the descriptive information is used to locate and parse multimedia data frames; Based on the scanned description information, locate the last fully written target self-describing data frame before the interruption, and perform data recovery based on the target self-describing data frame.

[0006] This application provides a security device, including: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the aforementioned disclosed data recovery method.

[0007] This application provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the steps of the aforementioned disclosed data recovery method.

[0008] Beneficial Effects: This application, by writing self-describing data frames containing descriptive information into the storage medium, ensures that each multimedia data frame carries complete location and parsing information, eliminating the need for external file indexes or standard encapsulation protocols. When the device restarts abnormally, it only needs to scan the descriptive information backward from the target location to quickly locate the last fully written data frame before the interruption and perform data recovery. Compared to traditional solutions, this application eliminates the need for parsing operations of standard encapsulation protocols on the bitstream, as well as the need to rely on file system metadata and reconstruct the file structure. This eliminates the computational overhead of encapsulation and decapsulation, significantly reducing the computational resource consumption of the recovery process and making it well-suited for low-power security devices with limited computing power. Furthermore, this application precisely locates the target self-describing data frame before the interruption at the frame level, ensuring that all multimedia data fully written to the storage medium before the interruption can be retrieved, controlling data loss to within the last incompletely written data frame, achieving a storage effect where no seconds are lost even after power failure. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0010] Figure 1 This is a flowchart of a data recovery method disclosed in this application; Figure 2 This is a flowchart illustrating the construction and writing process of a self-describing data frame as disclosed in this application; Figure 3 This is a schematic diagram of a data writing process disclosed in this application; Figure 4 This is a flowchart of a data frame positioning process disclosed in this application; Figure 5 This is a schematic diagram of a data recovery process disclosed in this application; Figure 6 This is a structural diagram of a security device disclosed in this application. Detailed Implementation

[0011] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0012] Currently, security devices commonly use MP4 file formats or raw stream storage based on standard encapsulation protocols such as PS and TS to store multimedia data. However, when using MP4, a power outage can easily corrupt the entire recording file, rendering it unreadable and resulting in the loss of all data recorded before the power outage. Using raw stream storage with standard encapsulation protocols requires encapsulation and parsing of the bitstream during both storage and recovery, consuming significant computational resources and making it unsuitable for security devices with limited computing power. Furthermore, traditional solutions typically rely on file system metadata to locate the power outage recovery point. After an abnormal device restart, the entire file structure needs to be re-parsed to complete the repair, resulting in time-consuming and poorly performed recovery, with the last data written before the power outage often being difficult to retrieve. Therefore, this application discloses a data recovery method and device that can quickly and accurately recover stored data after an abnormal device restart, while reducing the computational resource consumption during the recovery process.

[0013] See Figure 1 As shown in the figure, this application discloses a data recovery method applied to security equipment. The method includes: Step S11: After the device restarts abnormally, scan backwards from the target location on the storage medium; wherein, the storage medium stores self-describing data frames, which are constructed based on multimedia data frames and corresponding description information, and the description information is used to locate and parse multimedia data frames.

[0014] First, it should be noted that the security devices involved in the embodiments of this application include, but are not limited to: network cameras, smart doorbells, security video recorders, vehicle-mounted video recording equipment, law enforcement recorders, smart door locks (with camera functions), etc. These security devices need to perform data collection and storage tasks for a long time without interruption. Taking network cameras as an example, the device will run continuously 24 hours a day, continuously receiving multiple video data, audio data, image data, and other types of data frames.

[0015] In practical applications, security equipment is often deployed in environments with complex power supply conditions, such as underground garages, construction sites, and vehicles. Factors such as mains power fluctuations, power line faults, and human-caused power outages can all lead to abnormal interruptions and restarts of the equipment. It should be noted that the abnormal restart of the equipment in this embodiment refers to a restart that occurs when the equipment has not performed the normal shutdown procedure, including but not limited to abnormal power outage restarts, system crash restarts, and watchdog reset restarts. In a specific implementation, the security equipment can identify abnormal restarts by determining whether a normal shutdown flag was left from the previous operating cycle. It can be understood that when the equipment is normally shut down, a normal shutdown flag is written to the storage medium or non-volatile memory. Each time the equipment is powered on, this flag is checked. If the flag does not exist or is not set, the current startup is determined to be an abnormal restart, thereby triggering the data recovery process disclosed in this embodiment; if the flag exists and is set, the previous shutdown is determined to be normal, and no recovery process is required, and the equipment can directly enter the normal recording and storage state.

[0016] In this embodiment, the storage medium can be any persistent data storage device such as SSD (Solid State Disk), TF (TransFlash Card), eMMC (Embedded Multi-Media Card), or mechanical hard drive. This embodiment does not limit the type of storage medium. The storage medium stores self-describing data frames. A self-describing data frame is a data frame constructed based on a multimedia data frame and its corresponding descriptive information. The descriptive information is used to locate and parse the corresponding multimedia data frame. That is, each self-describing data frame carries complete location and parsing information, forming a self-describing data frame structure. The system can read the descriptive information of any self-describing data frame to obtain key metadata such as the frame's boundary position and acquisition time, without relying on external file structures, file system metadata, or standard protocol encapsulation. It is understood that the multimedia data frame can be a video frame, an audio frame, or a mixed audio-visual data frame; this embodiment does not limit this.

[0017] In the actual operation of security equipment, abnormal power outages or system crashes are difficult to completely avoid. Traditional solutions in such scenarios typically rely on file system metadata to locate the interruption recovery point. Since file system metadata (such as file size and write pointers) is usually located in memory cache and has not yet been persisted to storage media, the state of the metadata records after a restart may lag behind the actual written data. For example, multimedia data frames may have been successfully written to storage media, but the file size in the metadata has not been updated, causing the last segment of recorded data to be deemed invalid and lost. This application solves this problem by embedding descriptive information in self-describing data frames. When the device restarts abnormally, it only needs to scan the descriptive information backward from the target position to recover the data. Compared to traditional solutions, this application does not require parsing and calculating the bitstream using standard encapsulation protocols, nor does it rely on file system metadata or reconstruct the file structure. It eliminates the computational overhead of encapsulation and decapsulation, significantly reducing the computational resource consumption of the recovery process and making it well-suited for low-power security devices with limited computing power.

[0018] In some implementations, before step S11, the method further includes: reading the metadata area of ​​the storage medium and obtaining the most recently persisted write pointer position as the target position. In this embodiment, the security device periodically persists metadata such as the current write pointer position and the time range of the data block to the metadata area of ​​the storage medium during operation. When the device restarts abnormally, the system first loads and parses the metadata of the storage medium, obtains the last written data block and its recorded write pointer position, and determines it as the target position. Since the metadata is periodically persisted, the interruption (e.g., at the time of power failure) may not have completed the most recent update, so the write pointer position may lag behind the actual amount of data written. To retrieve data frames that have been written but not recorded by the metadata, subsequent scanning starts from this target position and proceeds backward.

[0019] Step S12: Based on the scanned description information, locate the last fully written target self-describing data frame before the interruption, and perform data recovery based on the target self-describing data frame.

[0020] In this embodiment, since the description information of each self-describing data frame in the storage medium carries the location and parsing information of that frame, during the scanning process, the system only needs to read the description information of each frame sequentially to advance frame by frame and quickly locate the position of the last frame completely written before the interruption, that is, to locate the target self-describing data frame that was completely written before the interruption. Subsequently, the system performs data recovery based on the target self-describing data frame to accurately restore the recording content of the last second before the interruption. The entire location and recovery process only involves reading the description information and a small amount of numerical comparison operations. It does not require parsing the standard encapsulation protocol, rebuilding the file system metadata, or performing any parsing processing on the encoded and compressed audio and video data inside the frame. Therefore, it consumes very little computing resources from the device. After the recovery is completed, the security device provides the recovered valid data to the upper-layer application. In the video playback scenario, the upper-layer application can retrieve and play back the recording content of the last moment before the interruption through the timeline. Since the acquisition timestamp of each frame increases monotonically along the writing direction, the playback timeline remains complete and continuous. In the video export scenario, multimedia data frames from all self-describing data frames before the recovery cutoff position can be extracted and packaged into a standard video file format for users to export and back up.

[0021] Furthermore, this application precisely locates the target self-describing data frame that was fully written before the interruption at the frame level, so that all multimedia data that was fully written to the storage medium before the interruption can be retrieved. The amount of data loss is controlled within the last data frame that was not fully written. According to the common frame rate, this amount of loss is usually only at the millisecond level, achieving the storage effect of no loss of seconds in security scenarios when power is off.

[0022] Furthermore, embodiments of this application also disclose specific methods for data recovery based on target self-describing data frames.

[0023] In one specific implementation, this application embodiment can define the boundaries of valid data from a time dimension, which is suitable for use scenarios where upper-layer applications (such as video playback and video export) filter data by time intervals. This ensures the continuity of the video timeline after recovery and facilitates users to retrieve the video content before the interruption according to the timeline. Specifically, the data recovery based on the target self-describing data frame includes: using the acquisition timestamp in the description information of the target self-describing data frame as the recovery time point; determining the self-describing data frames written in the storage medium up to the recovery time point as readable valid data to restore the data content at the last moment before the interruption.

[0024] It is understandable that, since each self-describing data frame records a precise acquisition timestamp in its description information, and the acquisition timestamps of each frame monotonically increase along the writing direction, the acquisition timestamp of the target self-describing data frame represents the acquisition time corresponding to the last fully written data frame before the interruption. The system uses this acquisition timestamp as the recovery time point, determining all self-describing data frames written in the storage medium up to this recovery time point as readable valid data, thus recovering all valid recording content from the start of recording to the last moment before the interruption. Therefore, this application, by updating the time range metadata of the data block using this recovery time point, enables users to seamlessly read the footage from the last moment before the interruption when retrieving and playing back recordings by time.

[0025] In another specific implementation, this application embodiment can also define the boundary of valid data from the storage space dimension, which is applicable to underlying storage space management and can provide a clear storage space starting point for subsequent continuous writing of recordings. The two methods can be used in combination, that is, simultaneously updating the time index and storage space management information to achieve dual recovery in both the time and space dimensions. Specifically, the data recovery based on the target self-describing data frame includes: taking the end position of the target self-describing data frame as the recovery cutoff position; determining all self-describing data frames before the recovery cutoff position as readable valid data to restore the data content at the last moment before the interruption.

[0026] Understandably, the end position of the target self-describing data frame can be directly calculated from its start position and the data frame length in its description information. The system uses this end position as the recovery cutoff point, which is also the new valid boundary for stored data. All self-describing data frames before this recovery cutoff point are considered readable and valid data, while incomplete data after the recovery cutoff point is truncated. This excludes incomplete frame data that was being written at the time of interruption from the valid data, preventing incomplete data from interfering with subsequent reading and playback. Simultaneously, the system updates the write pointer position and time range information in the metadata, updating the write pointer to this recovery cutoff point to ensure consistency between the metadata and the actual valid data. The device can then continue writing new self-describing data frames from this position, restoring normal video recording storage.

[0027] Through the above mechanism, after an abnormal restart of the device, at most only the last incompletely written data frame will be lost. According to the common frame rate, this loss is usually only in the millisecond range, achieving the effect of no loss of seconds when power is off in security scenarios.

[0028] As can be seen, this application, by writing self-describing data frames containing descriptive information into the storage medium, enables each multimedia data frame to carry complete location and parsing information, without relying on external file indexes or standard encapsulation protocols. When the device restarts abnormally, it only needs to scan the descriptive information backward from the target position to quickly locate the last fully written data frame before the interruption and perform data recovery. Compared with traditional solutions, this application does not require parsing operations of standard encapsulation protocols on the bitstream, nor does it rely on file system metadata or reconstruct the file structure, saving the computational overhead of encapsulation and decapsulation, significantly reducing the occupation of device computing resources during the recovery process, and can be well adapted to low-power security devices with limited computing power. Furthermore, this application accurately locates the target self-describing data frame that was fully written before the interruption at the frame level, so that multimedia data that was fully written to the storage medium before the interruption can be retrieved, controlling the amount of data loss to within the last incompletely written data frame, and achieving a storage effect of no loss of seconds even when power is off.

[0029] Based on the foregoing embodiments, this application provides a detailed description of the construction and writing process of self-describing data frames during device operation. Specifically, as shown below... Figure 2 As shown, the data recovery method further includes: Step S21: During device operation, acquire the multimedia data frames to be stored.

[0030] In this embodiment, during the operation of the security equipment, the image sensor of the security equipment collects raw image data at a preset frame rate, and generates multimedia data frames after compression and encoding by the audio and video encoder.

[0031] Step S22: Generate corresponding description information for the multimedia data frame, and combine the multimedia data frame and the corresponding description information into a self-describing data frame.

[0032] In this embodiment, the audio / video encoder typically outputs encoded multimedia data frame by frame. Therefore, this embodiment acquires the multimedia data frames to be stored output by the audio / video encoder frame by frame, and then generates corresponding description information for each multimedia data frame. This description information is used to uniquely identify and locate the corresponding multimedia data frame, enabling each self-describing data frame to have independent parsing capabilities without relying on external file structures or protocol encapsulation. The two are then combined into a self-describing data frame.

[0033] In a specific implementation, combining the multimedia data frame and the corresponding descriptive information into a self-describing data frame includes: embedding the corresponding descriptive information into the header of the multimedia data frame to obtain the self-describing data frame; wherein, the descriptive information includes at least a capture timestamp, data frame length, and data frame type. That is, the descriptive information is embedded in the form of frame header descriptive information before each frame of audio and video data, and the self-describing data frame is presented on the storage medium as a data structure with the descriptive information first and the original multimedia data frame data last, with each descriptive data frame connected end-to-end and arranged sequentially.

[0034] The acquisition timestamp records the acquisition time of the multimedia data frame with microsecond-level accuracy. The data frame length records the total number of bytes in the entire self-describing data frame (including header description information and the multimedia data frame itself), allowing the system to determine the frame boundaries and the start position of the next frame without parsing the frame content. The data frame type identifies the type of the frame. For video data, this includes I-frames, P-frames, and B-frames. I-frames are keyframes, containing complete image information and can be decoded independently. P-frames are prediction frames, recording only the differences from the previous frame. B-frames are bidirectional prediction frames, encoded with reference to the preceding and following frames. For audio data, the data frame type can be identified as an audio frame. Frame type information helps achieve fast video indexing and playback navigation. For example, during playback, the system can quickly locate the nearest I-frame to begin decoding based solely on the frame type, achieving second-level positioning and playback. Furthermore, the frame header description information may also include extended information such as frame start identifier, encoding format, resolution, and checksum. These extended information can be flexibly selected and combined according to actual needs, and this embodiment does not impose any limitations on this.

[0035] Step S23: Write the self-describing data frame into the storage medium using the direct input / output method.

[0036] In this embodiment, a Direct I / O method is used to sequentially write self-describing data frames with attached description information to the storage medium. It is understood that operating systems typically have a page cache mechanism. Under conventional write methods, data first enters the operating system's page cache, and then the kernel flushes it to the storage medium at an appropriate time. If an abnormal power outage occurs before the cached data is flushed to disk, the data in the cache will be lost. Direct I / O bypasses the operating system's page cache, that is, it completely bypasses the operating system's file system cache layer and the kernel cache, writing data directly to the physical storage space of the storage medium. This avoids multiple copies of data in the page cache and delayed flushing, ensuring that each self-describing data frame is persisted to the storage medium in real time after the write operation is completed, fundamentally eliminating the risk of data loss due to the system cache not being flushed during power outages. In other words, this application, through the combination of frame-level independent description information and direct-write disk method, ensures that every frame of data written before the power outage is actually written to disk, providing a fundamental guarantee for no data loss during power outages.

[0037] In a specific implementation, a direct I / O flag can be enabled when the storage device is opened, and the write buffer and write length can be aligned according to the sector size of the storage medium to meet the alignment requirements of direct I / O. At the same time, the storage space of the storage medium can be divided into several fixed-size data blocks. Self-describing data frames are sequentially written to the current target data block. After the current data block is full, the writing will switch to the next data block. The metadata such as the current write pointer position and the time range of the data block is periodically persisted to the metadata area of ​​the storage medium for reading after an abnormal restart.

[0038] For example, with Figure 3 The example below illustrates this: after the device starts the recording task, it begins recording and sequentially captures audio and video frames: I-frames, P-frames, and B-frames. It also generates corresponding description information for each frame, including the capture timestamp, data frame length, and data frame type. Then, the audio and video data frames and the corresponding description information are combined into a complete self-describing data frame, which is directly written to the corresponding physical address on the hard drive using a direct write method.

[0039] As can be seen, by embedding an independent description information block before each frame of multimedia data and adopting a direct I / O write-to-disk method, each self-describing data frame has complete positioning and parsing information, and is written to disk immediately after writing. This avoids the computing power overhead caused by standard protocol encapsulation and eliminates the risk of cached data loss, laying a data foundation for rapid recovery after abnormal device restart.

[0040] Based on the foregoing embodiments, this application further describes the scanning process. Specifically, the target position is the last written position recorded before the device abnormally interrupted; correspondingly, the scanning from the target position on the storage medium includes: using the last written position as the starting scan position; starting from the starting scan position, scanning the description information of each description data frame in the storage medium frame by frame along the data writing direction.

[0041] In this embodiment, the security device periodically records metadata such as the write pointer position to the storage medium during operation. After an abnormal restart, the device can read this metadata to obtain the last write position recorded before the interruption, and use this position as the target position to start scanning backward. Here, scanning backward refers to scanning the data area already written on the storage medium along the data writing direction and in the direction of increasing storage address.

[0042] As can be understood from the foregoing, since metadata (such as file size, time range, data block write pointers, etc.) is usually located in memory cache and has not yet been persisted to the storage medium, the state of the metadata records after a restart may lag behind the actual written data. Therefore, after an abnormal device restart, this application first loads and parses the metadata of the storage medium to obtain the last written data block and its recorded write pointer position, that is, the last write position recorded before the abnormal device interruption. Since metadata is periodically persisted, the most recent update may not have been completed at the time of the interruption. Therefore, this write pointer position may lag behind the actual amount of data written, meaning that there may be self-describing data frames that have been successfully written but not recorded by the metadata at the end of the last written data block. To retrieve this part of the data, the system uses this last write position as the starting scan position. Starting from this position, it scans the description information of each descriptive data frame in the storage medium frame by frame along the data write direction to confirm whether there are subsequent data frames that have been written but not recorded by the metadata. Because the scan only starts from the last written position, rather than scanning the entire storage medium or the entire file, and the persistence period of metadata is usually short, the amount of data between the starting scan position and the actual write end point is limited, so the scan process can be completed in a very short time.

[0043] See details Figure 4 and Figure 5 As shown, locating the last fully written target self-describing data frame before the interruption, based on the scanned description information, specifically includes the following steps: Step S31: Obtain the target description information at the current scanning position, and extract the corresponding data frame length from the target description information.

[0044] In this embodiment, at the start of scanning, the current scanning position is the aforementioned starting scanning position. The system reads a segment of data at the current scanning position according to a preset structure of the description information as target description information, and attempts to parse out each field from it. In a specific implementation, obtaining the target description information at the current scanning position includes: reading the data at the current scanning position; checking whether the frame start identifier matches a preset specific byte sequence; in response to the frame start identifier matching the specific byte sequence, checking whether the parsed timestamp increases normally relative to the previous frame, and checking whether the length of the parsed data frame is within a preset reasonable range; in response to the timestamp increasing normally and the data frame length being within a preset reasonable range, using the parsed information as target description information.

[0045] In other words, during parsing, the system can first check the frame start identifier to determine if the data at the current position begins with a pre-agreed specific byte sequence. If the frame start identifier matches, it initially determines that a valid frame header exists at the current position. In response to the frame start identifier matching the specific byte sequence, the system initially confirms the existence of a potential frame header at the current position. At this point, it can also perform reasonableness checks on the values ​​of fields such as timestamp and data frame length. For example, it checks whether the data frame length is within a reasonable range and whether the timestamp increases normally compared to the previous frame. Regarding timestamp checks, the system needs to check whether the timestamp of this frame increases normally relative to the acquisition timestamp of the previous frame. For example, it checks whether the timestamp difference is greater than zero and within the preset frame interval allowable error range to avoid time rollback due to reading out-of-order or corrupted data. Regarding data frame length checks, it is possible to check whether the length of the parsed data frame is within a preset reasonable length range. The lower limit of the reasonable length range should be at least greater than the fixed length of the description information itself to ensure that there is a readable multimedia data payload after the frame header. The upper limit should not exceed the maximum read / write unit length of the storage medium or the maximum allowable length of a single frame of data to avoid significant error jumps in the scan pointer due to abnormal data frame length field, which could cause the valid data area to be skipped or the blank area to be unwritten.

[0046] If the timestamp increments normally and the data frame length is within a preset reasonable range, it means that all checks have passed. The system confirms that the currently parsed description information is valid and reasonable, uses the parsed information as the target description information at the current scanning position, and extracts the corresponding data frame length from it.

[0047] Step S32: Based on the data frame length, verify the data integrity of the corresponding self-describing data frame.

[0048] In this embodiment, the data integrity of the corresponding self-describing data frame is verified based on the extracted data frame length. In a specific implementation, verifying the data integrity of the corresponding self-describing data frame based on the data frame length includes: determining the expected data length of the corresponding self-describing data frame based on the data frame length; comparing the actual data length of the corresponding self-describing data frame with the expected data length; and determining that the data integrity verification of the self-describing data frame passes if the comparison result is consistent, and failing if the comparison result is inconsistent.

[0049] Understandably, the data frame length field records the total number of bytes a self-describing data frame should have, i.e., the expected data length of the frame; while the actual data length is the effective data length that the frame can actually be read on the storage medium, such as the data length belonging to the frame from the current scan position to the actual write termination position. If the frame has been completely written when the interrupt occurs, the actual data length will necessarily match the expected data length, and the integrity check will pass; if the interrupt happens to occur during the writing process of the frame, only part of the data of the frame will be written to disk, the actual data length will be less than the expected data length, the comparison result will be inconsistent, the integrity check will fail, indicating that the data at that position is incomplete, and it is very likely that this is the frame that was being written when the anomaly occurred.

[0050] Furthermore, in an implementation where the description information includes a checksum field, the verification of the data integrity of the corresponding self-describing data frame further includes: in response to the matching comparison results, calculating a checksum value for the frame data of the self-describing data frame based on the checksum field in the description information and performing a comparison; and in response to the matching checksum values, confirming that the double verification of data integrity has passed.

[0051] In other words, after the length comparison is passed, the system can also calculate the checksum of the frame data and compare it with the checksum recorded in the description information to double verify the integrity and correctness of the frame data, thereby further improving the reliability of the recovery results.

[0052] Step S33: In response to the data integrity verification passing, determine the next scan position based on the data frame length.

[0053] In this embodiment, in response to the data integrity verification passing, it indicates that the current frame is not an incomplete frame being written at the time of the interruption, but a valid self-describing data frame that has been completely written to the storage medium and can be safely included in the scope of valid data recovery. Then, the next scan position is determined based on the data frame length.

[0054] Since the data frame length records the total number of bytes in the entire self-describing data frame, the system only needs to add the data frame length to the current scan position to directly obtain the end position of the frame, which is also the start position of the next self-describing data frame, and determine it as the next scan position. In other words, based on the value of the data frame length field, the system quickly jumps the read pointer to the end position of the frame and continues scanning the next frame, without needing to read and analyze the audio and video encoded data within the frame, thus avoiding the need for parsing and processing each frame of audio and video data.

[0055] Step S34: Update the next scan position to the current scan position, and jump to the step of obtaining the target description information at the current scan position until the data integrity check fails or there is no valid description information. Then, determine the last self-describing data frame that passes the data integrity check as the last fully written target self-describing data frame before the interruption.

[0056] In this embodiment, the scanning process is repeatedly executed by iteratively updating and jumping to the current scan position. This involves a frame-by-frame loop of reading descriptive information, verifying integrity, and jumping to the next frame, until any of the following termination conditions occur: First, the data integrity verification of a frame fails, for example, the actual data length does not match the expected data length; second, there is no valid descriptive information at the current scan position, such as the frame start identifier not being identifiable, the parsed data frame length being abnormal, or the timestamp being backtracked or out of bounds. This indicates that there are no fully written self-describing data frames after this position, and what is scanned may be incomplete data being written at the time of the anomaly, or a blank area where no data has been written yet. After the scan terminates, the system stops scanning and identifies the last self-describing data frame that passed the data integrity verification as the last fully written target self-describing data frame before the interruption. Because the scan proceeds frame-by-frame with frame-level precision, this positioning result is accurate to the frame level, enabling all data frames that were fully written to disk before the interruption to be included within the recoverable range.

[0057] It should be noted that in actual abnormal interruption scenarios, the interruption may occur precisely during the writing of description information for a frame, during the writing of multimedia data for a frame, or even in the gap between two frames. The above scanning mechanism can cover all situations: if the interruption occurs during the writing of description information, the first step of frame start identifier matching or checksum verification will fail, and the system will use the previous complete frame as the target frame; if the interruption occurs during the writing of multimedia data, the actual data length will be insufficient through data frame length comparison, and the system will also use the previous complete frame as the target frame; if the interruption occurs in the gap between two frames, there is no valid description information at the current scanning position, the system stops scanning, and the previous complete frame is still correctly identified. Therefore, this application can accurately locate the last completely written data frame in various abnormal interruption scenarios.

[0058] As can be seen, through the collaborative work of frame-level description information and direct IO sequential writing in the above scheme, the last fully written self-describing data frame can be accurately identified and recovered when the device restarts abnormally. This compresses the potentially lost seconds of video data in traditional solutions to the millisecond level, significantly improving the integrity of security video data and ensuring the reliability of evidence for critical events. Simultaneously, based on the fast jump mechanism of data frame length, the system does not need to parse the complex encoded data within the frame during the scanning and recovery process; it can complete frame boundary positioning simply by reading the description information. This greatly improves recovery efficiency and significantly reduces the demand for computing resources on edge devices, making it particularly suitable for low-power security device scenarios.

[0059] In some implementations, the embedding of descriptive information in the frame header of a self-describing data frame, real-time persistent writing based on direct I / O, and jump-based scan recovery based on frame length are not simply parallel processes, but rather a collaborative design under the low-power constraints of security devices. If only frame header embedding is used without direct I / O, data frames not flushed to disk in the system cache will still be lost when power is lost, failing to guarantee real-time disk writing at the frame level. If only direct I / O is used without embedding frame header descriptive information, file system metadata or standard protocols still need to be parsed during recovery, making it impossible to achieve fast location with low computational consumption. If only frame header embedding is used and direct I / O is employed without jump scanning based on frame length, the entire data area needs to be scanned byte by byte, significantly increasing recovery time. Only when all three work together can low-overhead, high-efficiency, and millisecond-level data loss control be achieved across the entire chain from power failure to recovery on low-power security devices with limited computing power, producing technical effects far exceeding those achievable by simply piecing together the individual parts.

[0060] Figure 6This is a schematic diagram of a security device provided in an embodiment of this application. Specifically, it may include: at least one processor 21, at least one memory 22 communicatively connected to the at least one processor 21, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the data recovery method performed by the security device disclosed in any of the foregoing embodiments.

[0061] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the security device 20; the communication interface 24 can create a data transmission channel between the security device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0062] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0063] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored on it include operating system 221, computer program 222 and data 223, etc., and the storage method can be temporary storage or permanent storage.

[0064] The operating system 221 manages and controls the various hardware devices and computer programs 222 on the security equipment 20, enabling the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. The operating system can be Windows, Unix, Linux, etc. The computer program 222, in addition to including a computer program capable of performing the data recovery method executed by the security equipment 20 as disclosed in any of the foregoing embodiments, may further include computer programs capable of performing other specific tasks. The data 223 may include data received by the security equipment from external devices, as well as data collected by its own input / output interface 25.

[0065] Furthermore, embodiments of this application also disclose a computer-readable storage medium storing a computer program, which, when loaded and executed by a processor, implements the data recovery method steps disclosed in any of the foregoing embodiments.

[0066] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0067] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0068] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, compact disc read-only memory (CD-ROM), or any other form of storage medium known in the art.

[0069] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0070] The data recovery method and device provided by the present invention have been described in detail above. Specific examples have been used to illustrate the principle and implementation of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core idea of ​​the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation and application scope based on the idea of ​​the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A data recovery method, characterized in that, Used in security equipment, including: After the device restarts abnormally, a scan is performed backward from the target location on the storage medium; wherein, the storage medium stores self-describing data frames, which are constructed based on multimedia data frames and corresponding descriptive information, and the descriptive information is used to locate and parse multimedia data frames; Based on the scanned description information, locate the last fully written target self-describing data frame before the interruption, and perform data recovery based on the target self-describing data frame.

2. The data recovery method according to claim 1, characterized in that, Also includes: During device operation, acquire multimedia data frames to be stored; Generate corresponding description information for the multimedia data frame, and combine the multimedia data frame and the corresponding description information into a self-describing data frame; The self-describing data frame is written into the storage medium using a direct input / output method.

3. The data recovery method according to claim 2, characterized in that, The step of combining the multimedia data frame and the corresponding description information into a self-describing data frame includes: The corresponding description information is embedded in the header of the multimedia data frame to obtain a self-describing data frame; wherein the description information includes at least the acquisition timestamp, data frame length and data frame type.

4. The data recovery method according to claim 1, characterized in that, The target location is the last written location recorded before the device experienced an abnormal interruption; Accordingly, the scanning backward from the target location on the storage medium includes: Use the last written position as the starting scan position; Starting from the initial scan position, the description information of each data frame in the storage medium is scanned frame by frame along the data writing direction.

5. The data recovery method according to claim 4, characterized in that, The process of locating the last fully written target self-description data frame before the interruption, based on the scanned description information, includes: Obtain the target description information at the current scanning position, and extract the corresponding data frame length from the target description information; Based on the data frame length, verify the data integrity of the corresponding self-describing data frame; If the data integrity check passes, the next scan position is determined based on the data frame length; The next scan position is updated to the current scan position, and the process jumps to the step of obtaining the target description information at the current scan position. This continues until the data integrity check fails or there is no valid description information. Then, the last self-describing data frame that passes the data integrity check is determined as the last fully written target self-describing data frame before the interruption.

6. The data recovery method according to claim 5, characterized in that, The step of verifying the data integrity of the corresponding self-describing data frame based on the data frame length includes: Based on the data frame length, determine the expected data length of the corresponding self-describing data frame; Compare the actual data length of the corresponding self-describing data frame with the expected data length; If the comparison results are consistent, the data integrity check of the self-describing data frame is deemed to have passed; if the comparison results are inconsistent, the data integrity check of the self-describing data frame is deemed to have failed.

7. The data recovery method according to claim 6, characterized in that, The step of obtaining target description information at the current scanning location includes: Read the data at the current scan position and check if the frame start identifier matches a preset specific byte sequence; In response to the frame start identifier matching the specific byte sequence, it is checked whether the parsed timestamp increases normally relative to the previous frame, and whether the parsed data frame length is within a preset reasonable range. If the timestamp increments normally and the data frame length is within a preset reasonable range, the parsed information will be used as the target description information. Accordingly, the verification of the data integrity of the corresponding self-describing data frame further includes: In response to the matching result, the checksum value of the frame data of the self-describing data frame is calculated and compared according to the checksum field in the description information; Since the checksum is consistent, the double-confirmation data integrity check has passed.

8. The data recovery method according to any one of claims 1 to 7, characterized in that, The data recovery based on the target self-describing data frame includes: The collection timestamp in the description information of the target self-describing data frame is used as the recovery time point; The self-describing data frames written in the storage medium up to the recovery time point are identified as readable and valid data in order to restore the data content at the last moment before the interruption.

9. The data recovery method according to any one of claims 1 to 7, characterized in that, The data recovery based on the target self-describing data frame includes: The end position of the target self-describing data frame is taken as the recovery cutoff position; All self-describing data frames prior to the recovery cutoff position are identified as readable and valid data in order to restore the data content at the last moment before the interruption.

10. A security device, characterized in that, include: At least one processor; The at least one processor is also connected in communication with a memory, wherein the memory stores a computer program that, when executed by the at least one processor, causes the at least one processor to implement the steps of the data recovery method as described in any one of claims 1 to 9.

Images