A method, device and equipment for multi-policy integrity verification of a timing backup chain

Abstract

This invention relates to a multi-strategy integrity verification method, apparatus, and device for a timed backup chain, belonging to the field of disaster recovery backup. The method includes: acquiring backup metadata and backup data files; extracting sampled data fragments according to a sampling strategy; splicing the sampled data fragments and metadata to form a tiled hybrid input data, and generating its baseline fingerprint; associating and storing the baseline fingerprint and backup data; periodically recalculating the fingerprint to be verified, and completing fault judgment by comparing the fingerprints before and after. The apparatus includes: a sampled fragment extraction module, a hybrid encoding module, a baseline fingerprint generation module, an association storage module, a verification fingerprint generation module, and a comparison and verification module. This invention, based on a closed-loop coupled system formed by "fingerprint + tiled hybrid + sampling strategy," can achieve low-overhead support for high-frequency verification, high-frequency verification supports fine-grained sampling, fine-grained sampling achieves lightweight positioning, and lightweight positioning ensures security and reliability.

Description

Technical Field

[0001] This invention belongs to the field of disaster recovery and backup, and relates to a multi-strategy integrity verification method, device, computer equipment, computer storage medium and computer program product for a timed backup chain. Background Technology

[0002] A scheduled backup chain is a time-dependent data version chain built at predetermined time intervals through full, incremental, or differential backups. Its structure is linear or tree-like, and a single point of failure will cause all subsequent nodes to fail.

[0003] Integrity verification is a technique that verifies that backup data has not been corrupted during its lifecycle, with the core objective of ensuring availability during disaster recovery. As data volumes grow exponentially and operational costs increase, current technologies are shifting from full-scale verification to lightweight verification to reduce overhead, and from delayed recovery verification to proactive verification for continuous monitoring, while incorporating adaptive strategies to adapt to the complex structure of the backup chain and diverse data characteristics.

[0004] Currently, existing technology discloses a method, server, and storage medium for verifying backup data (CN201910147459.7), which proposes a layered verification scheme. This scheme first calculates CRC checksums at four levels during the backup process: table level, file level, data block level, and overall backup set. These checksums are then appended as metadata to the backup result set. During the data recovery phase, the checksums in the metadata at each level are parsed and compared layer by layer to accurately pinpoint the fault to a specific data table, file, or data block. While this scheme facilitates targeted repairs by maintenance personnel, the multi-layered metadata verification results in high storage redundancy, significant recovery verification delays, and insufficient timeliness as data can only be confirmed during the recovery phase. Furthermore, the layered logic is coupled to specific database structures, making it difficult to generalize to unstructured data scenarios.

[0005] Therefore, given that the current layered verification mechanism results in excessive metadata storage, and this problem is amplified exponentially in backup chain scenarios, the core pain points of current backup chain integrity verification are how to solve the common problems of high storage redundancy, difficulty in generalizing layered logic coupling from specific database forms to unstructured data, insufficient perception timeliness, and linear expansion of verification overhead with chain length. Summary of the Invention

[0006] In order to solve the technical problems in the background art, the present invention provides a multi-strategy integrity verification method, apparatus, computer equipment, computer storage medium and computer program product for timed backup chains.

[0007] The technical solution of the present invention to solve the above-mentioned technical problems is as follows:

[0008] Firstly, a multi-policy integrity verification method for a timed backup chain is provided, the method comprising the following steps:

[0009] Automatically obtain backup time point T n Metadata and backup data file contents;

[0010] According to the preset sampling strategy, extract sampled data fragments from the contents of the backup data file;

[0011] The metadata file name, metadata file content, backup data file name, and sampled data fragments are concatenated byte by byte to form a flat mixed input data;

[0012] Perform a hash operation on the mixed input data to generate a baseline fingerprint FP;

[0013] The baseline fingerprint FP is associated with and stored with the backup data;

[0014] Periodically reread backup time point T n The same metadata file content and the same sampled data fragment are used to recalculate the fingerprint FP´ to be verified;

[0015] The fingerprint to be verified, FP´, is compared with the reference fingerprint, FP. If they match, it is considered normal; if they do not match, it is considered that there is an integrity fault.

[0016] Secondly, a multi-policy integrity verification device for a timed backup chain is provided, the device comprising:

[0017] The initial data acquisition module is used to automatically obtain the backup time point T. n Metadata and backup data file contents;

[0018] The sampling fragment extraction module is used to extract sampling data fragments from the contents of backup data files according to a preset sampling strategy.

[0019] The hybrid encoding module is used to concatenate the filename of the metadata file, the content of the metadata file, the filename of the backup data file, and the sampled data fragments into tiling hybrid input data.

[0020] The baseline fingerprint generation module is used to perform hash operations on mixed input data to generate a baseline fingerprint FP;

[0021] The associated storage module is used to associate and store the baseline fingerprint FP with the backup data.

[0022] The fingerprint generation module is used to periodically reread the backup time point T. n The same metadata file content and the same sampled data fragment are used to recalculate the fingerprint FP´ to be verified;

[0023] The comparison and verification module is used to compare the fingerprint FP´ to be verified with the reference fingerprint FP. If they match, it is considered normal; if they do not match, it is considered that there is an integrity fault.

[0024] Thirdly, a computer device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the steps of the multi-strategy integrity verification method for the timed backup chain as described in any of the preceding claims.

[0025] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the multi-strategy integrity verification method of the timed backup chain as described above.

[0026] Fifthly, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the multi-strategy integrity verification method for the timed backup chain described in any of the preceding claims.

[0027] The beneficial effects of this invention are:

[0028] (1) This invention compresses traditional multi-layer verification information into a fixed-length hash value by calculating fingerprints, so that the verification storage overhead of the backup chain no longer increases linearly with the number of nodes, greatly saving metadata space. At the same time, only one hash calculation is needed to complete the integrity judgment during verification, without the need to parse the historical version layer by layer, reducing the computation and I / O costs in large-scale backup chain scenarios.

[0029] (2) The flat hybrid input of this invention encodes metadata file name, content and backup data file name, sampling fragment in a unified manner, breaking through the strong coupling of traditional layered verification to database table structure, so that the solution can be directly applied to unstructured data scenarios such as files, object storage, block devices without modification, and improve the generalization ability of the technology.

[0030] (3) The present invention is based on hash calculation of sampling strategy rather than full scan. It reduces the amount of verification data while ensuring the error detection rate, and realizes lightweight integrity monitoring. At the same time, the sampling segment itself is determined by the strategy to determine its position information. When the overall fingerprint comparison fails, the fault range can be limited to a small area by recalculating the sampling segment, avoiding byte-by-byte scanning, and balancing detection efficiency and positioning accuracy.

[0031] (4) The present invention uses the file name as part of the hash input, so that the fingerprint not only verifies the data content, but also verifies the data identifier, effectively preventing attack scenarios such as file name tampering and file replacement, and filling the security blind spot of traditional content verification only;

[0032] (5) The present invention is based on a closed-loop coupling system formed by "fingerprint + tiling hybrid + sampling strategy", which can achieve low overhead to support high frequency verification, high frequency verification supports fine-grained sampling, fine-grained sampling achieves lightweight positioning, and lightweight positioning ensures security and reliability. Attached Figure Description

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

[0034] Figure 1 This is a schematic diagram of the multi-strategy integrity verification method for the timed backup chain provided in Embodiment 1 of the present invention.

[0035] Figure 2 This is a schematic diagram of the full extraction strategy in Embodiment 1 of the present invention.

[0036] Figure 3 This is a schematic diagram of the compact sampling strategy in Embodiment 1 of the present invention.

[0037] Figure 4 This is a schematic diagram of the system block sampling strategy in Embodiment 1 of the present invention.

[0038] Figure 5 This is a schematic diagram of the window sampling strategy in Embodiment 1 of the present invention.

[0039] Figure 6 This is a schematic diagram of the tiled mixed input data structure of the length-value encoding splicing format in Embodiment 1 of the present invention.

[0040] Figure 7 This is a schematic diagram of the multi-strategy integrity verification method for the timed backup chain provided in Embodiment 2 of the present invention.

[0041] Figure 8 This is a schematic diagram of the structure of the multi-strategy integrity verification device for the timed backup chain provided in Embodiment 3 of the present invention.

[0042] Figure 9 This is a schematic diagram of the structure of the electronic device provided in Embodiment 4 of the present invention.

[0043] The attached diagram lists the components represented by each number as follows:

[0044] 3001 Initial Data Acquisition Module; 3002 Sampling Fragment Extraction Module; 3003 Hybrid Encoding Module; 3004 Baseline Fingerprint Generation Module; 3005 Associated Storage Module; 3006 Verification Fingerprint Generation Module; 3007 Version Identifier Loading Module; 3008 Comparison and Verification Module; 3009 Fault Location Module; 410 Processor; 420 Communication Interface; 430 Memory; 440 Communication Bus. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0046] Example 1

[0047] Currently, existing technology discloses a method, server, and storage medium for verifying backup data (CN201910147459.7), which proposes a layered verification scheme. This scheme first calculates CRC checksums at four levels during the backup process: table level, file level, data block level, and overall backup set. These checksums are then appended as metadata to the backup result set. During the data recovery phase, the checksums in the metadata at each level are parsed and compared layer by layer to accurately pinpoint the fault to a specific data table, file, or data block. While this scheme facilitates targeted repairs by maintenance personnel, the multi-layered metadata verification results in high storage redundancy, significant recovery verification delays, and insufficient timeliness as data can only be confirmed during the recovery phase. Furthermore, the layered logic is coupled to specific database structures, making it difficult to generalize to unstructured data scenarios.

[0048] Therefore, given that the current layered verification mechanism results in excessive metadata storage, and this problem is amplified exponentially in backup chain scenarios, the core pain points of current backup chain integrity verification are how to solve the common problems of high storage redundancy, difficulty in generalizing layered logic coupling from specific database forms to unstructured data, insufficient perception timeliness, and linear expansion of verification overhead with chain length.

[0049] To address the aforementioned issues, embodiments of the present invention provide a multi-strategy integrity verification method for a timed backup chain. Figure 1 This is a flowchart illustrating the multi-strategy integrity verification method for a timed backup chain provided in an embodiment of the present invention, as shown below. Figure 1 As shown, this method includes:

[0050] Step S101: Automatically obtain the metadata file content and backup data file content of the backup time point Tn.

[0051] It is understandable that, regarding the acquisition of metadata file content and backup data file content, this embodiment provides two modes that are automatically triggered by the completion event of the backup task for the scheduled backup scenario, without the need for manual intervention.

[0052] During the backup execution phase, when the scheduled task is triggered as planned and actively reads data blocks from the production system, metadata filenames, content snapshots, and sampled data fragments can be synchronously extracted from the memory buffer before the data is written to the final storage medium. Since the backup process is fully controlled by the backup software, processing logic can be flexibly inserted before the data is written to disk to ensure the instantaneous consistency of the state to be stored is captured.

[0053] Another mode is retrieval upon completion, which means that after the scheduled task reads all the data as planned, writes it, and closes the file handle, it reads the persisted complete metadata file and backup data file at once for processing.

[0054] Regardless of the mode used, data consistency must be guaranteed by the transaction boundary markers or file handle closing events of the backup software, and intermediate read / write operations must be eliminated.

[0055] Step S102: Extract sampled data segments from the contents of the backup data file according to the preset sampling strategy. The preset sampling strategy is to dynamically switch between full sampling and partial sampling based on the size of the backup data file. The partial sampling includes compact sampling, system block sampling, and window sampling.

[0056] Preferably, step S102 further includes:

[0057] The compact sampling is to extract continuous data from the beginning or end of the backup data file.

[0058] The system block sampling involves dividing the backup data file into equal-length blocks and sampling all blocks at fixed intervals determined by the product of the total number of blocks and the sampling ratio.

[0059] The window sampling involves dividing the backup data file into logical windows of equal size and then extracting the complete window or a representative block thereof.

[0060] To further understand the full extraction and several partial extraction strategies mentioned in this embodiment, the following will combine... Figures 2 to 5 Detailed introduction:

[0061] like Figure 2 As shown, the full backup data extraction is performed automatically at backup time point T. n After backing up the data file, the data is extracted to contain the entire contents of the backup data file. Full extraction is suitable for scenarios where the backup data file is relatively small (e.g., the configuration threshold is <500M), treating the entire backup file as a single point in time and reading all its data contents.

[0062] Meanwhile, since the total amount of small file data is limited, forced block sampling may lead to insufficient sample representativeness. Moreover, the computational cost and time consumption of full reading are within an acceptable range. A combination strategy of "full extraction + partial extraction" can be used to ensure the integrity of basic data while reducing the cost of redundant analysis through sampling.

[0063] Of course, in addition to file size, the configuration conditions that trigger "full read + sampling combination" can also cover multiple scenarios:

[0064] Data sensitivity priority: When the backup data contains highly sensitive business information, such as financial transaction records or medical privacy data, the system will force a full read to avoid the risk of information leakage introduced during the sampling process;

[0065] Data integrity requirements: For backup data of critical business systems, such as database transaction logs and core configuration files, it is necessary to ensure zero data loss during recovery. Therefore, full reading is adopted to avoid partial data omissions that may be caused by sampling.

[0066] Therefore, this embodiment can also dynamically adapt to data management needs in different scenarios through a combined judgment of "file size threshold + multi-dimensional business rules", ensuring sampling efficiency while covering the reliability requirements of special scenarios. This embodiment does not make specific limitations in this regard.

[0067] For backup data with large or very large amounts of data, using full data reading will inevitably lead to excessive time overhead in calculating point-in-time fingerprints. Therefore, a partial data sampling strategy is provided, which supports data sampling according to a proportion and a specified size.

[0068] However, it should be noted that in this embodiment, "small file" does not refer to the absolute number of bytes, but rather to a backup file whose computational overhead for full hashing is significantly lower than the metadata management overhead of the sampling strategy. A three-dimensional adaptive model can be used for specific determination:

[0069] Static threshold dimension: In the default configuration, files smaller than the preset threshold are considered small files, such as 500MB. The specific threshold can be set based on the balance between the hash calculation speed and IOPS overhead of the current mainstream servers.

[0070] Dynamic proportional dimension: When the overall file size of the backup chain is small, such as the average <100MB, the system will automatically adjust the threshold to 10% of the average file size to avoid statistical bias.

[0071] Performance budget dimension: In scenarios with tight backup windows, a hard time budget can be configured, such as single file verification ≤ 500ms. The system estimates the file hashing time in real time based on the current CPU / disk load and makes dynamic decisions.

[0072] like Figure 3 As shown, compact sampling involves extracting consecutive data blocks from the beginning or end of a file according to a configured ratio or size. For example, using pre-compact data sampling, the data is extracted at the backup time point T. n After backing up the data file, read the header contiguous data blocks according to the configured ratio or size; use post-compact data sampling, and automatically obtain the backup time point T. n After backing up the data file, read the tail contiguous data blocks according to the configured ratio or size; use front compact data sampling and back compact data sampling to simultaneously obtain the head and tail contiguous data blocks.

[0073] Compact sampling requires precise IO offset control: header truncation reads a data segment of size F×R from the beginning of the file, while tail truncation calculates the starting position of the F×R length at the end of the file and then reads it in a directional manner. Since the header can efficiently capture file header metadata, such as version declarations and encrypted headers, and the tail can cover time-sensitive traces such as log tails and transaction end-of-transactions, it achieves an approximate representation of global features by "local contiguous blocks". This is an effective sampling strategy that significantly reduces the processing time of tasks such as fingerprint calculation and difference analysis while ensuring the representativeness of data features.

[0074] like Figure 4 As shown, the system's block sampling achieves efficient feature extraction of partial data through "equal-length blocks + fixed-interval sampling," for example, when the backup time point T is automatically acquired. n After backing up the data files, the backup files are divided into continuous data blocks of fixed size, such as 4K to 8M. A fixed interval K is used, calculated as the product of the total number of blocks N = F / S and the sampling ratio R, to sample data blocks that satisfy block_id ≡ 0 (mod K). The system's block sampling adapts to storage I / O alignment through "block-level discretization," such as matching the block size to the file system block granularity, reducing cross-block read overhead. Simultaneously, a "fixed interval rule" ensures the uniform distribution of samples across the global data, avoiding the performance bottleneck of full reads and covering key intervals of the data distribution through the "equidistant rule."

[0075] As a preferred method, the calculation method for system block sampling is as follows:

[0076] Obtain the backup file size F, sampling ratio R, and block size S;

[0077] Calculate the total number of blocks N = F / S;

[0078] Calculate the sampling interval K = N × R;

[0079] Extract data blocks that satisfy block number block_id ≡ 0 (mod K), where the value of block_id ranges from 0 to N−1.

[0080] It is important to note that K = N × R is an integer, and the value of R ensures that N × R is an integer. block_id ≡ 0 (mod K) strictly depends on the integer K, ensuring that the "equal interval sampling" logic is executed unambiguously across all backup nodes; at the same time, by constraining the sampling ratio R to ensure that N × R is an integer, the accuracy of the sampling ratio at both the macro-statistical and micro-block-level operation levels is guaranteed, ensuring the stable operation of the algorithm.

[0081] When F is not divisible by S, the file is padded to make F divisible by S before calculating N. The padded file is equivalent to rounding up to N = F / S, avoiding the complexity of explicitly filling branch code while ensuring all data is included in the block system. If N = F / S were directly taken, the last data block might be missed due to truncation. The padded mechanism allows "equal-distance sampling" to cover the entire dataset, while also being compatible with the block alignment characteristics of the storage medium, effectively ensuring the algorithm's universality.

[0082] like Figure 5 As shown, window sampling involves dividing the backup data file into logical windows of equal size and then extracting the complete window or a representative block thereof. The window division can adopt a front-compact or back-compact pattern. For example, when the backup time point T is obtained... n After backing up the data file, it is first divided into two windows: a header contiguous data block and a middle contiguous data block, i.e., compact sampling before the two windows; then, at the backup time point T... n After backing up the data file, it is also divided into two windows: a continuous data block at the end and a continuous data block in the middle. That is, compact sampling is performed after the two windows.

[0083] When the file is large, the data is also broken down into units that can be processed in parallel through "window partitioning" to reduce the resource consumption pressure of a single node. At the same time, the sampling operation within each window ensures the mapping from "local representativeness" to "global features" - for example, when the backup file is 1PB and divided into 100 windows, the front-end 10% of metadata is extracted before each 1TB window is processed. This can quickly verify the validity of global metadata and avoid the resource consumption pressure of full reading.

[0084] It is worth noting that in the backup data integrity verification scenario of this embodiment, compact sampling, system block sampling, and window sampling are often not used individually. The three can achieve a balance of "lightweight detection + precise positioning" through layered complementarity. Window sampling breaks down ultra-large-scale files into sub-units that can be processed in parallel, breaking through the resource bottleneck of a single node; system block sampling covers the block-level distribution of the entire data with equidistant rules, ensuring statistical representativeness; compact sampling captures high-value local features such as header metadata and tail logs with minimal I / O, quickly anchoring key information.

[0085] Taking a 10GB backup file divided into 2560 blocks of 4MB each as an example, the hybrid strategy reads the complete 4MB block for each sampling point, with the following specific configuration:

[0086] Compact sampling: The first 12 blocks are directly extracted, with a single sampling rate of 0.47%, and the actual data read is 12 × 4MB = 48MB;

[0087] System block sampling: 1 block is sampled every 256 blocks, starting from block 0 and sampling 10 blocks consecutively. The sampling rate per sample is 0.39%, and the actual data read is 10 × 4MB = 40MB.

[0088] Window sampling: The 2560 blocks are divided into 256 windows, and 3 windows are sampled, numbered 3, 89 and 157 respectively. The last 2 blocks are extracted from each window using compact sampling, for a total of 3 blocks. The sampling ratio is 0.23%, and the actual data read is 6 × 4 MB = 24 MB.

[0089] In this embodiment, a total of 28 blocks were sampled, with a total sampling rate of 1.09%. The actual total amount of data read from the disk was 112MB, which is only 1.09% of the 10GB backup file. Under the premise of ensuring that each sampling point has complete block-level detection capability, spatial, temporal and header triple fault mode coverage was achieved with low overhead.

[0090] Therefore, this embodiment intelligently selects representative data segments to limit the fault range to the GB level or specific blocks with controllable computational cost, resolving the core contradiction of the incompatibility between "low overhead" and "location capability". Three strategies are respectively designed to target high-frequency errors at the head / tail, spatial random errors, and local errors with windows as time boundaries, optimizing the detection probability. The three types of sampling results are aggregated into a hash fingerprint, eliminating the need to store multiple layers of verification information and maintaining the simplicity of a single fingerprint. At the same time, when fingerprint matching fails, the fault can be located layer by layer. For example, first check the head / tail of compact sampling, then analyze the global blocks of system segmentation, and finally focus on the units sampled by window sampling. This gives the solution the operational and troubleshooting capabilities that are lacking in the current traditional merged verification architecture.

[0091] Step S103: The filename of the metadata file, the content of the metadata file, the filename of the backup data file, and the sampled data fragments are concatenated byte by byte to form a flat mixed input data.

[0092] It's worth noting that the tiling-style hybrid input data uses "tiling input data" as its core carrier, encompassing the filenames and content of metadata files, the filenames of backup data files, and tiered sampling fragments. This input mode integrates the sampling results into a single fingerprint through "tiered aggregation" logic. It preserves the integrity association between "metadata + data files" while simplifying engineering implementation through "tiling input." Only hash aggregation needs to be performed on the tiled sampling fragments to complete the full data integrity assertion with computational efficiency and memory usage proportional to the number of samples, effectively reducing overhead.

[0093] It's also worth noting that backup data is typically characterized by sequential writing of large files, and the need for "rapidly completing full data integrity assertions" is far greater than for "precise location of single data blocks." This embodiment's tiling-style hybrid sampling employs a layered strategy of "system block sampling + window sampling + compact sampling," breaking down the verification logic into "unitized parallel processing (window) → global block-level coverage (system block) → critical area reinforcement (compact)," effectively matching the backup scenario.

[0094] Sequential I / O friendly: The system reads continuous data blocks by block sampling according to equal interval rules, avoiding the overhead of random access in a tree-like structure;

[0095] Lightweight verification priority: Complete the representative verification of the entire data with a constant level of O(k) computation efficiency (k is the number of samples), which is different from the O(n) level computational resource consumption of the traditional technology of "database table → file → data block → whole" multi-layer CRC check, effectively reducing resource overhead;

[0096] Native streaming support: Sampling and aggregation can be completed with a single scan of the backup stream, eliminating the need for multiple data backtracking steps as required by hierarchical verification;

[0097] Therefore, this embodiment uses "sampling window positioning" instead of "single block positioning" to achieve performance improvement and engineering simplicity, which is Pareto optimal at the architecture level.

[0098] Preferably, in step S103, the splicing format of the mixed input data adopts a length-value encoding structure, and the metadata file name length, metadata file name, metadata content length, metadata content, backup data file name length, backup data file name, sampled data fragment length, and the sampled data fragment are written sequentially.

[0099] In this embodiment, as Figure 6As shown, through the length-value encoding structure, concatenated data is encapsulated into a continuous "length field + byte sequence" packet: a fixed 4-byte little-endian length field indicates the length of the subsequent content; the filename uses a UTF-8 byte stream occupying N bytes; and the content length is also 4 bytes in little-endian, occupying M bytes. The parser only needs to segment the data sequentially according to the length, without needing to care about platform endianness, delimiters, or encoding differences. It possesses self-descriptive properties across different operating systems or hardware platforms, thus achieving cross-platform integrity verification.

[0100] Step S104: Perform a hash operation on the mixed input data to generate a baseline fingerprint FP.

[0101] It is worth noting that the choice of sampling strategy directly determines the accuracy and efficiency of subsequent fault location when generating the baseline fingerprint. By using the logical location information recorded at the sampling time, such as block ID, offset, and window marker, as part of the mixed input, the fingerprint not only carries a summary of data integrity but also embeds traceable spatial coordinates. Once fingerprint matching fails, the fault range can be locked to a specific sampling area based on these coordinates without a full scan. The compact, block, and window strategies inject different dimensions of detection preferences at the fingerprint generation stage: continuous block sampling is good at capturing regional damage, hash block sampling can detect fragmented errors, and time window sampling is suitable for the local characteristics of log-type data. This "strategy equals accuracy" gives the fingerprint adjustable localization granularity from the very beginning.

[0102] It is also worth noting that the sampling rate k% can be used as a dynamic parameter when generating fingerprints, providing a flexible trade-off between efficiency and accuracy. When k=100%, the fingerprint degenerates into a hybrid hash of the entire dataset, achieving positioning accuracy comparable to hierarchical verification but losing its spatial advantage; when k=10%, the computation and storage overhead of the fingerprint is minimized, and although the positioning range expands to 10% of the dataset, it is still far superior to blind detection without positioning capabilities.

[0103] Therefore, in backup data integrity verification, this "accuracy-efficiency" continuum that can be configured at the fingerprint generation source enables the same fingerprint generation framework to meet both rapid inspection of large-scale images and in-depth inspection of key incremental nodes.

[0104] Preferably, step S104 further includes: responding to the backup task at time point T m The completed event, within the same atomic operation context where the backup data file has been written and the file handle has been closed, refers to the event at time point T. m The corresponding mixed input data is hashed to generate a baseline fingerprint FP.

[0105] It is worth noting that this instance responds to the backup task at time point T. mThe completed event provides atomicity guarantees at both the operating system and application levels. At the operating system level, the generation timing is locked in the critical section after the backup process calls the `close()` or `fsync()` system call but before the process exits. At this point, the file handle is closed, the kernel cache has been flushed to disk, but the process context has not yet been released, ensuring that the read data is completely written to disk and cannot be tampered with by other processes. At the application level, this event corresponds to the uninterruptible sequence of operations between the backup software marking the task status as "successful" and triggering fingerprint generation. Both are bound through the same transaction context, ensuring that mixed input data accurately corresponds to T. m A snapshot of the moment prevents timing errors caused by intermediate states or external concurrent writes.

[0106] The atomic binding mechanism strongly couples the time anchor point of integrity verification with the data persistence window, making a single point-in-time fingerprint the verification credential for successful backup task submission. Because the generation operation and T... m The completion events at any given moment share the same critical section. Any crash, malicious injection, or file tampering that occurs after backup is complete but before fingerprint generation will cause the entire transaction to roll back or fingerprint calculation to fail, thus being detected immediately. This avoids the silent data corruption caused by time differences during delayed verification. By atomicating verification credentials with business operations, it achieves zero-additional-latency guarantee for backup-to-verification, compressing the fault detection cycle from hours to seconds, and enabling the self-verification of data timeliness and consistency without relying on external clocks or logs.

[0107] It is important to note that in streaming mode, although the hash calculation of each sampled segment is distributed throughout the writing process, the generation of the final time fingerprint is still forcibly delayed until the backup completion event is triggered. This allows for atomic binding with the file handle closing operation, ensuring that the final hash state is locked only after all data blocks have been written to disk.

[0108] Step S105: Associate the baseline fingerprint FP with the backup data and store it.

[0109] Associated storage establishes a one-to-one correspondence between a point in time and its integrity certificate. During verification, the system can directly load the corresponding fingerprint for comparison based on the inherent attributes of the backup point in time, without scanning the preceding nodes. If the comparison fails, it can also immediately pinpoint the specific time point of the failure, providing precise context for repair and laying the foundation for lightweight verification in long-cycle backup chains.

[0110] Alternatively, the association can be achieved by storing the fingerprint as an independent verification file in the same directory as the backup data, or by embedding the fingerprint into the header of the backup metadata file to form a self-contained structure. This embodiment does not impose specific limitations on this.

[0111] Step S106: Periodically reread the backup time point Tn The same metadata file content and the same sampled data fragment are used to recalculate the fingerprint FP´ to be verified.

[0112] Step S107: Compare the fingerprint to be verified FP´ with the reference fingerprint FP. If they match, it is considered normal; if they do not match, it is considered that there is an integrity fault.

[0113] This embodiment replaces the traditional passive verification during recovery with periodic proactive verification, upgrading data integrity awareness from "post-event delayed diagnosis" to "real-time monitoring during the event." Combined with the lightweight computing characteristics of a single fingerprint, continuous comparison can be performed at the second level. Once silent damage or malicious tampering of the storage medium occurs, alarms can be triggered quickly, effectively preventing data corruption from spreading throughout the backup chain and significantly improving business continuity and data security timeliness.

[0114] In this embodiment, a closed-loop coupling system based on "fingerprint + tiling hybrid + sampling strategy" can achieve low-overhead support for high-frequency verification, high-frequency verification supports fine-grained sampling, fine-grained sampling achieves lightweight positioning, and lightweight positioning ensures security and reliability.

[0115] Example 2

[0116] like Figure 7 As shown, in one embodiment, a multi-policy integrity verification method for a timed backup chain is provided. This method includes:

[0117] Step S201: Automatically obtain backup time point T n The metadata file content and the backup data file content;

[0118] Step S202: Extract sampled data segments from the contents of the backup data file according to the preset sampling strategy. The preset sampling strategy is to dynamically switch between full sampling and partial sampling based on the size of the backup data file. The partial sampling includes compact sampling, system block sampling, and window sampling.

[0119] Step S203: The filename of the metadata file, the content of the metadata file, the filename of the backup data file, and the sampled data fragments are concatenated byte by byte to form a flat mixed input data.

[0120] Step S204: Perform a hash operation on the mixed input data to generate a baseline fingerprint FP, and at the same time generate a sampling descriptor that records the location information of each sampled data segment. The sampling descriptor includes the block number, window ID, offset, and pre-calculated check value of the segment.

[0121] Step S205: After establishing a directly addressable mapping relationship between the baseline fingerprint FP and the corresponding backup data using the version identifier as the key, store it.

[0122] Step S206: Periodically reread the backup time point T n The same metadata file content and the same sampled data fragment are used to recalculate the fingerprint FP´ to be verified;

[0123] Step S207, using the target backup time point T n The version identifier directly loads the corresponding baseline fingerprint FP;

[0124] Step S208: Compare the fingerprint to be verified FP´ with the reference fingerprint FP. If they match, it is considered normal; if they do not match, it is considered that there is an integrity failure.

[0125] Step S209, at the target backup time point T n After an integrity failure is detected, the sampling descriptor of each associated sampled data segment is read, and the independent check value of each sampled data segment is recalculated and compared with the pre-calculated check value. The specific faulty sampled data segment is located based on the comparison result.

[0126] It is understandable that the pre-computed check value refers to an independent hash value calculated and temporarily stored for each sampled data segment, which is not mixed into the overall fingerprint.

[0127] It's worth noting that the pre-calculated checksum and the generation of the time-point fingerprint are completed simultaneously: when the backup task ends at time point Tn, after the system reads all sampled fragments to construct the mixed data, it calculates the overall fingerprint for all the fragment concatenation results, and simultaneously calculates the checksum for each fragment independently. These two calculations share the same memory snapshot, but their paths are separate—the overall fingerprint only receives the concatenated byte stream, while the fragment checksums are stored separately in the sampled descriptors, without interfering with the overall hashing process. This ensures that each fragment checksum is strongly bound to time point Tn, yet can be read and compared independently during the verification phase.

[0128] Here is an example to help you understand:

[0129] Assuming the backup file is sampled into eight segments by the system, the system first reads these eight segments consecutively into a memory buffer to form mixed data A. Then, it performs two types of calculations in parallel: ① Performs SHA-256 once on the complete A to obtain the overall fingerprint; ② Performs SHA-256 on each sub-buffer (segment 1 to segment 8) in A to obtain eight pre-calculated checksums. The entire process is completed seamlessly before the backup software marks "task successful," without interruption or external intervention. When subsequent verification finds a mismatch in the overall fingerprint, the system only needs to recalculate the current checksums of the eight segments in the same order. The first segment with a discrepancy accurately points to the damaged location, achieving second-level location rather than hour-level full scan.

[0130] Regarding time consistency: The pre-calculated checksum must be generated within a millisecond-level time window before the backup completion signal is issued, after the data is written to disk, and before any other process can access it, and must be completed back-to-back with the overall fingerprint. If a time deviation causes the data state captured by the fragment checksum to be inconsistent with the overall fingerprint, the positioning mechanism will completely fail.

[0131] It is also understandable that the aforementioned version identifier can use a timestamp or backup chain sequence number to ensure the uniqueness and sortability of each backup time point.

[0132] The mapping can be implemented in three ways: First, independent key-value storage, where the FP is stored in an embedded database such as Berkeley DB or LevelDB with the version identifier as the key, and can be directly loaded in O(1) time during query; Second, object storage key name convention, such as storing the FP in the path backup / {version_id} / integrity.fp, and using the key prefix search capability of object storage to achieve direct addressing; Third, metadata file header embedding, reserving 32 bytes in the header of the backup result set metadata file, writing the FP directly, and locating it through the file path + fixed offset during reading. This embodiment does not make specific limitations on this, but regardless of the method, the mapping relationship must meet the requirements of persistence, immutability, and strong binding with the life cycle of the backup data, to ensure that even if it undergoes migration and renaming in PB-level storage, the corresponding baseline fingerprint FP can still be found through the version identifier.

[0133] This mapping relationship upgrades the verification process from traversal search to direct hit, and the fingerprint can be loaded in constant time using the version identifier, reducing the verification time from O(n) to O(1), effectively improving the performance of large-scale node chains. Operations and maintenance personnel can also quickly locate faults when randomly checking any historical version.

[0134] Furthermore, the immutability of the mapping ensures that fingerprints correspond one-to-one with data, and together with WORM storage, it enables cross-domain trust anchoring. Tampering requires breaking through two independent security domains simultaneously, which can also improve the strength of anti-tampering.

[0135] Furthermore, upon detecting an anomaly in the backup chain, an automatic degradation strategy is implemented. This involves discarding damaged nodes and regenerating a completely new backup chain based on the previous trusted and intact backup point. This silent, background process completes a full backup without manual intervention, rapidly restoring the health and integrity of the backup chain and preventing single-point failures from contaminating the entire chain structure. Simultaneously, when used in conjunction with checksum verification to locate the fault, a closed-loop diagnosis-repair mechanism can be achieved.

[0136] Unlike the previous embodiments, this embodiment clarifies the fault location process by calculating independent check values ​​for each sampled segment in parallel. It generates the check value within the same atomic context as the overall fingerprint and uses lightweight sampled descriptor storage, avoiding the operational dilemma of requiring a full scan when the overall fingerprint mismatches, effectively reducing fault location time and I / O overhead. Furthermore, by establishing an addressable mapping for the base fingerprint using the version identifier as the key, each backup time point has independent addressing capability. Combined with a direct loading mechanism, it avoids the time overhead of traversing previous nodes or parsing hierarchical metadata, effectively reducing cross-version verification latency and backup chain management complexity.

[0137] Example 3

[0138] like Figure 8 As shown, in one embodiment, a multi-policy integrity verification device for a timed backup chain is provided. This device includes:

[0139] Initial data acquisition module 3001 is used to automatically acquire backup time point T. n The metadata file content and the backup data file content;

[0140] The sampling fragment extraction module 3002 is used to extract sampling data fragments from the contents of the backup data file according to a preset sampling strategy. The preset sampling strategy is to dynamically switch between full extraction and partial extraction based on the size of the backup data file. The partial extraction includes compact sampling, system block sampling, and window sampling.

[0141] The hybrid encoding module 3003 is used to concatenate the filename of the metadata file, the content of the metadata file, the filename of the backup data file, and the sampled data fragments into byte-by-byte concatenation to form tiling hybrid input data.

[0142] The baseline fingerprint generation module 3004 is used to perform hash operations on the mixed input data to generate a baseline fingerprint FP, and at the same time generate a sampling descriptor that records the location information of each sampled data segment. The sampling descriptor includes the block number, window ID, offset and pre-calculated check value of the segment.

[0143] The associated storage module 3005 is used to establish a directly addressable mapping relationship between the base fingerprint FP and the corresponding backup data using the version identifier as the key, and then store it.

[0144] The fingerprint generation module 3006 is used to periodically reread the backup time point T. n The same metadata file content and the same sampled data fragment are used to recalculate the fingerprint FP´ to be verified;

[0145] Version identifier loading module 3007 is used to load the target backup time point T. nThe version identifier directly loads the corresponding baseline fingerprint FP;

[0146] The comparison and verification module 3008 is used to compare the fingerprint to be verified FP´ with the reference fingerprint FP. If they match, it is considered normal; if they do not match, it is considered that there is an integrity fault.

[0147] Fault location module 3009 is used to determine the target backup time point T. n After an integrity failure is detected, the sampling descriptor of each associated sampled data segment is read, and the independent check value of each sampled data segment is recalculated and compared with the pre-calculated check value. The specific faulty sampled data segment is located based on the comparison result.

[0148] Below, we provide some comparative experiments to further illustrate this embodiment, as follows:

[0149] Table 1. Experimental Environment Configuration

[0150] Environmental Category Detailed configuration Hardware environment Backup and Verification Nodes: 2 x86_64 servers, Intel Xeon Silver 4214R processors, 128GB DDR4 memory, 10GbE network cards. Backup Target: 1 100TB SATA HDD storage array, RAID 6. Software environment Operating System: CentOS 8.4, Kernel 5.4; Backup Software: Self-developed prototype system compared to Commvault 11.24; Hash Algorithm: SHA-256 Test dataset MySQL 8.0 database backup, full snapshot 500GB, daily incremental binlog approximately 5GB block size: 4MB

[0151] (1) Experimental procedure setup

[0152] To simulate a real-world scenario of scheduled backup chains, three different sizes of backup chains were built for testing:

[0153] Small scale: 10 nodes, including 1 full data transfer plus 9 incremental data transfers, retained for 30 days;

[0154] Medium scale: 100 nodes, including 1 full data transfer plus 99 incremental data transfers, with a retention period of 90 days;

[0155] Large-scale: 1000 nodes, including 1 full iteration plus 999 incremental iterations, retained for 365 days.

[0156] Each node independently performs three operations: generating verification credentials (using the scheme in this embodiment and the comparative scheme respectively), simulating silent corruption (randomly injecting bit rot into a data block), and performing integrity verification and recording the location time.

[0157] (2) Test case design

[0158] Test Case 1: Storage Overhead Comparison

[0159] The total space occupied by the two schemes for verifying credentials under three scales was statistically analyzed. The comparative scheme adopted a layered verification method, calculating four levels of checksums: database / table level, file level, block level, and overall level, with each level occupying 64 bytes. This embodiment records only a single fingerprint (32 bytes) plus a sampling descriptor, with each fragment being 36 bytes. Based on a 1% sampling rate, approximately 13 fragments are calculated per node.

[0160] Test Example 2: Performance Comparison Verification

[0161] Randomly sample node T in a medium-scale chain 50 The time from initiating verification to obtaining the result is measured. In a comparative example, the metadata verification chain of the preceding 49 nodes needs to be parsed layer by layer; this embodiment directly loads T. 50 A single fingerprint is generated and recalculated locally.

[0162] Test Example 3: Cross-Platform Compatibility Verification

[0163] Backups and verifications were performed on 100GB each of MySQL table data, VMware VMDK image, and unstructured files in S3 object storage to observe whether the comparison ratio needed modification and whether this embodiment could be applied directly without modification.

[0164] Test Example 4: Fault Location Accuracy Test

[0165] In a large-scale chain, for node T 200 A single-bit flip is injected into data block 503 to record the number of I / O operations and time required for both schemes to go from "fingerprint mismatch alarm" to "location to block 503". In this embodiment, by comparing the pre-calculated checksums of 13 sample segments, the first mismatch points to block 503. The comparative scheme requires a full scan of all data blocks of the node, which takes approximately 2560 I / O operations to complete the location.

[0166] (3) Experimental results

[0167] Table 2. Test Data Results

[0168] Experiment Items scale Comparative Example This embodiment Storage overhead 10 nodes 2.5 KB 0.5 KB 100 nodes 25 KB 5 KB 1000 nodes 256 KB 50 KB Verification time <![CDATA[T 50 Medium-sized 2.3 seconds 0.08 seconds Cross-platform adaptation MySQL tables Needs renovation No modification required VMDK image Needs renovation No modification required S3 object Needs renovation No modification required Location I / O count Block 503 is damaged. Full scan of 2560 blocks Only 13 times tampering detection rate File name modification 0% missed detection 100% detection Sampling rate impact 1%→5% not applicable Storage + 68B / node, positioning accuracy improved by 5 times

[0169] (4) Experiment Summary

[0170] Storage and performance: This embodiment compresses the verification credentials from linear growth to constant level, saving 80% of storage and reducing verification time by 96%. In a chain with tens of thousands of nodes, the performance advantage is amplified exponentially, effectively solving the chain length sensitivity problem of hierarchical verification.

[0171] Universality: The flat hybrid architecture treats structured / unstructured data equally, requires no modification for cross-platform testing, and reduces implementation costs by about 70% compared to the proportionally coupled database table structure, significantly shortening the adaptation cycle.

[0172] Fault location capability: The location accuracy in this embodiment depends on the sampling rate. 1% sampling can lock the range to a window of about 40MB, which is slightly coarser than the block-level location of the comparative model. However, block-level accuracy can be achieved by dynamically adjusting the sampling rate to 5%, sacrificing only a small amount of storage. This exhibits a continuously adjustable accuracy-efficiency characteristic, while hierarchical verification cannot be dynamically optimized.

[0173] Security Boundary: This embodiment uses filenames to participate in hashing, which naturally defends against attacks that tamper with the entire metadata file. This is a scenario that is not covered by the comparison, and the anti-tampering dimension is more complete.

[0174] In summary, this embodiment significantly outperforms the comparative embodiment in three core metrics: storage overhead, verification speed, and general compatibility. It achieves an acceptable range in positioning accuracy through strategy optimization and has incremental advantages in security protection. Overall, it exhibits Pareto improvement and is suitable for large-scale, multi-cloud, heterogeneous backup chain scenarios.

[0175] Unlike the above embodiments, this embodiment compresses traditional multi-layer verification information into a fixed-length hash value by calculating fingerprints. This prevents the verification storage overhead of the backup chain from increasing linearly with the number of nodes, significantly saving metadata space. At the same time, integrity judgment can be completed with only one hash calculation during verification, without the need to parse historical versions layer by layer, reducing the computation and I / O costs in large-scale backup chain scenarios. Meanwhile, the flat mixed input encodes metadata file names, content, backup data file names, and sample fragments in a unified manner, allowing the solution to be directly applied to unstructured data scenarios such as files, object storage, and block devices without modification, improving the generalization ability of the technology.

[0176] Example 4

[0177] exist Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention, such as... Figure 9 As shown, the electronic device may include a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute the multi-strategy integrity verification method of the timed backup chain as described in Embodiment 1 or 2.

[0178] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0179] Example 5

[0180] In this embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, it implements the multi-strategy integrity verification method for the timed backup chain as described in Embodiment 1 or 2.

[0181] Example 6

[0182] In this embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the multi-strategy integrity verification method for a timed backup chain as described in Embodiment 1 or 2.

[0183] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0184] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0185] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0186] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, Ruby, and Go, as well as conventional procedural programming languages ​​such as "C" or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0187] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A multi-strategy integrity verification method for a timed backup chain, characterized in that, The method includes the following steps: Automatically obtain backup time point T n Metadata and backup data file contents; According to the preset sampling strategy, sampled data segments are extracted from the contents of the backup data file. The sampling strategy determines the location information of the sampled data segments in the backup data file, which is used to locate the fault range in the event of an integrity failure. The metadata file name, metadata file content, backup data file name, and sampled data fragments are concatenated byte by byte to form a flat mixed input data; Perform a hash operation on the mixed input data to compress the multi-layer verification information into a fixed-length hash value and generate a baseline fingerprint FP; The baseline fingerprint FP is associated with and stored with the backup data; Periodically reread backup time point T n The same metadata file content and the same sampled data fragment are used to recalculate the fingerprint FP´ to be verified; The fingerprint to be verified, FP´, is compared with the reference fingerprint, FP. If they match, it is considered normal. If there is a discrepancy, an integrity failure is determined.

2. The multi-strategy integrity verification method for timed backup chains according to claim 1, characterized in that, The step of extracting sampled data fragments from the contents of the backup data file according to a preset sampling strategy further includes: The default sampling strategy is to dynamically switch between full sampling and partial sampling based on the size of the backup data file, wherein partial sampling is at least one or more combinations of compact sampling, system block sampling, or window sampling.

3. The multi-strategy integrity verification method for timed backup chains according to claim 2, characterized in that, Also includes: The compact sampling is to extract continuous data from the beginning or end of the backup data file. The system block sampling involves dividing the backup data file into equal-length blocks and sampling all blocks at fixed intervals determined by the product of the total number of blocks and the sampling ratio. The window sampling involves dividing the backup data file into logical windows of equal size and then extracting the complete window or a representative block thereof.

4. The multi-strategy integrity verification method for a timed backup chain according to any one of claims 1 to 3, characterized in that, The step of performing a hash operation on the mixed input data to generate a baseline fingerprint FP further includes: In response to the backup task at time T m The completed event, within the same atomic operation context where the backup data file has been written and the file handle has been closed, refers to the event at time point T. m The corresponding mixed input data is hashed to generate a baseline fingerprint FP.

5. The multi-strategy integrity verification method for a timed backup chain according to any one of claims 1 to 3, characterized in that, The step of associating and storing the baseline fingerprint FP with the backup data further includes: The baseline fingerprint FP is stored after establishing a directly addressable mapping relationship between the version identifier and the corresponding backup data. The step of comparing the fingerprint FP´ to be verified with the reference fingerprint FP further includes: Based on the target backup time point T n The version identifier directly loads the corresponding baseline fingerprint FP; The fingerprint to be verified, FP´, is compared with the reference fingerprint, FP. If they match, it is considered normal; if they do not match, it is considered that there is an integrity fault.

6. The multi-strategy integrity verification method for a timed backup chain according to any one of claims 1 to 3, characterized in that, After the step of performing a hash operation on the mixed input data to generate a baseline fingerprint FP, the method further includes: Perform a hash operation on the mixed input data to generate a baseline fingerprint FP. At the same time, generate a sampling descriptor that records the location information of each sampled data segment. The sampling descriptor includes the block number, window ID, offset, and pre-calculated check value of the segment. The method further includes: Determining the target backup time point T n After an integrity failure is detected, the sampling descriptor of each associated sampled data segment is read, and the independent check value of each sampled data segment is recalculated and compared with the pre-calculated check value. The specific faulty sampled data segment is located based on the comparison result.

7. A multi-strategy integrity verification device for a timed backup chain, characterized in that, The device includes: The initial data acquisition module is used to automatically obtain the backup time point T. n Metadata and backup data file contents; The sampling fragment extraction module is used to extract sampling data fragments from the contents of the backup data file according to a preset sampling strategy. The sampling strategy determines the location information of the sampling data fragments in the backup data file, which is used to locate the fault range in the event of an integrity failure. The hybrid encoding module is used to concatenate the filename of the metadata file, the content of the metadata file, the filename of the backup data file, and the sampled data fragments into tiling hybrid input data. The baseline fingerprint generation module is used to perform hash operations on mixed input data, compress multi-layer verification information into a fixed-length hash value, and generate a baseline fingerprint FP; The associated storage module is used to associate and store the baseline fingerprint FP with the backup data. The fingerprint generation module is used to periodically reread the backup time point T. n The same metadata file content and the same sampled data fragment are used to recalculate the fingerprint FP´ to be verified; The comparison and verification module is used to compare the fingerprint FP´ to be verified with the reference fingerprint FP. If they match, it is considered normal; if they do not match, it is considered that there is an integrity fault.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the multi-strategy integrity verification method for the timed backup chain as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the multi-strategy integrity verification method for the timed backup chain as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-strategy integrity verification method for the timed backup chain as described in any one of claims 1 to 6.

Images