File recovery method and device, electronic equipment, storage medium and product

Abstract

The application provides a file recovery method and device, electronic equipment, storage medium and product. The method comprises the following steps: receiving a file recovery request; determining a metadata structure of a target file system corresponding to a target object identifier according to the file recovery request; determining a target file directory item corresponding to the target object according to the metadata structure, the target file directory item being a data structure for storing file information and directory information; determining a plurality of target extension area structures according to the target file directory item, and determining a plurality of deleted files that have been deleted according to the plurality of target extension area structures; and performing recovery processing on the plurality of deleted files to obtain a target file. According to the above scheme, the extension area structure represents a file through continuous data blocks, and all continuous data blocks can be read at one time only by determining the position of the first data block of the file, so that the efficiency of determining the file is improved, and the efficiency of file recovery is further improved.

Description

Technical Field

[0001] This application relates to the field of data management technology, and in particular to a file recovery method, apparatus, electronic device, storage medium, and product. Background Technology

[0002] In the Linux operating system, the file system can manage files using optimized file allocation strategies, thus efficiently managing a large number of files and large files. With the gradual development of the Linux operating system, the fourth-generation extended file system (Ext4) has improved file system performance.

[0003] In related technologies, the files that need to be recovered are identified from the deleted files by querying the log files in Ext4, and then file recovery is performed.

[0004] However, the log files contain a large amount of information, making it inefficient to identify the files that need to be recovered, resulting in low file recovery efficiency. Summary of the Invention

[0005] This application provides a file recovery method, apparatus, electronic device, storage medium, and product to improve the efficiency of file recovery.

[0006] In a first aspect, this application provides a file recovery method, comprising: receiving a file recovery request, the file recovery request including a target object identifier of a target object; determining, based on the file recovery request, the metadata structure of a target file system corresponding to the target object identifier; determining, based on the metadata structure, a target file directory entry corresponding to the target object, the target file directory entry being a data structure storing file information and directory information; determining, based on the target file directory entry, multiple target extension area structures, and determining, based on the multiple target extension area structures, multiple deleted files that have been deleted, and performing recovery processing on the multiple deleted files to obtain a target file.

[0007] Optionally, the method described above, determining the metadata structure of the target file system corresponding to the target object identifier, includes: determining the target type of the target object through system calls or command-line tools, wherein the target type includes a disk or a partition; if the target type is a disk, determining the target partition information of the target object through the master boot record of the target object, and determining the target file system corresponding to the target object based on the file system signature value in the target partition information; if the target type is a partition, reading the target partition information of the target object, and determining the target file system corresponding to the target object based on the file system signature value in the target partition information; determining whether the target file system is a fourth-generation extended file system, and if so, determining the superblock and group descriptor from the target file system, and determining that the metadata structure includes the superblock and the group descriptor.

[0008] Optionally, the method described above, determining the target file directory entry corresponding to the target object based on the metadata structure, includes: determining the root directory index node from the metadata structure; determining the root directory based on the root directory index node; and determining the target file directory entry from the root directory.

[0009] Optionally, the method described above, determining multiple target extension area structures based on the target file directory entries, includes: recursively determining multiple candidate file identifiers from the target file directory entries; determining multiple deletion time field information corresponding to the multiple candidate file identifiers based on the metadata structure; determining multiple deleted file identifiers from the multiple candidate file identifiers based on the multiple deletion time field information, wherein the deletion time field information of any deleted file identifier is not 0; and determining multiple target extension area structures corresponding to the multiple deleted file identifiers based on the metadata structure.

[0010] Optionally, the method described above recursively determines multiple candidate file identifiers from the target file directory entry, including: determining multiple file system objects under the root directory and multiple object types corresponding to the multiple file system objects, wherein the object types include subdirectories or files; for any file system object, if the corresponding object type is a subdirectory, then reading the sub-objects under the file system object until a sub-object of object type is read, and determining the first file identifier of the sub-object, adding the first file identifier to the target group; if the file system object is a file, determining the second file identifier of the file system object, adding the first file identifier to the target group; determining the multiple candidate file identifiers includes the first file identifier and the second file identifier in the target group.

[0011] Optionally, the method described above, for any target extended region structure; determining the file to be deleted based on the target extended region structure includes: determining the first field information of the extended region header through the target extended region structure, the first field information including whether the extended region header is valid or invalid; if the first field information indicates that the extended region header is valid, then obtaining the target address information from the extended region header; and determining the file to be deleted based on the target address information.

[0012] Secondly, this application provides a file recovery apparatus, comprising: a request module for receiving a file recovery request, the file recovery request including a target object identifier of a target object; a determination module for determining, based on the file recovery request, the metadata structure of a target file system corresponding to the target object identifier; a processing module for determining, based on the metadata structure, a target file directory entry corresponding to the target object, the target file directory entry being a data structure storing file information and directory information; and a recovery module for determining, based on the target file directory entry, multiple target extension area structures, and based on the multiple target extension area structures, multiple deleted files that have been deleted, and performing recovery processing on the multiple deleted files to obtain a target file.

[0013] Optionally, in the apparatus described above, the determining module is specifically configured to determine the target type of the target object through system calls or command-line tools, wherein the target type includes a disk or a partition; the determining module is further configured to, if the target type is a disk, determine the target partition information of the target object through the master boot record of the target object, and determine the target file system corresponding to the target object based on the file system signature value in the target partition information; the determining module is further configured to, if the target type is a partition, read the target partition information of the target object, and determine the target file system corresponding to the target object based on the file system signature value in the target partition information; the determining module is further configured to, determine whether the target file system is a fourth-generation extended file system, and if so, determine the superblock and group descriptor from the target file system, and determine that the metadata structure includes the superblock and the group descriptor.

[0014] Optionally, the apparatus as described above further includes: a lookup module, configured to determine a root directory index node from the metadata structure; the lookup module is further configured to determine a root directory based on the root directory index node, and determine the target file directory entry from the root directory.

[0015] Optionally, the apparatus as described above further includes: a traversal module, configured to recursively determine multiple candidate file identifiers from the target file directory entries; the traversal module is further configured to determine multiple deletion time field information corresponding to the multiple candidate file identifiers based on the metadata structure; the traversal module is further configured to determine multiple deleted file identifiers from the multiple candidate file identifiers based on the multiple deletion time field information, wherein the deletion time field information of any deleted file identifier is not 0; the traversal module is further configured to determine multiple target extension area structures corresponding to the multiple deleted file identifiers based on the metadata structure.

[0016] Optionally, in the apparatus described above, the traversal module is specifically configured to determine multiple file system objects under the root directory and multiple object types corresponding to the multiple file system objects from the target file directory entries, wherein the object types include subdirectories or files; the traversal module is further configured to, for any file system object, if the corresponding object type is a subdirectory, read the sub-objects under the file system object until a sub-object of object type is a file is read, and determine the first file identifier of the sub-object, and add the first file identifier to the target group; the traversal module is further configured to, if the file system object is a file, determine the second file identifier of the file system object, and add the first file identifier to the target group; the traversal module is further configured to determine that the multiple candidate file identifiers include the first file identifier and the second file identifier in the target group.

[0017] Optionally, the apparatus described above is designed for any target extended region structure; the apparatus further includes: a verification module, configured to determine first field information of the extended region header through the target extended region structure, the first field information including whether the extended region header is valid or invalid; the verification module is further configured to obtain target address information from the extended region header if the first field information indicates that the extended region header is valid; the verification module is further configured to determine the deleted file based on the target address information.

[0018] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method described in any one of the first aspects.

[0019] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which are executed by a processor as described in any one of the first aspects.

[0020] Fifthly, this application provides a computer program product, including a computer program, which is executed by a processor as described in any one of the first aspects.

[0021] This application provides a file recovery method, apparatus, electronic device, storage medium, and product. The method includes: receiving a file recovery request, the file recovery request including a target object identifier of a target object; determining the metadata structure of a target file system corresponding to the target object identifier based on the file recovery request; determining a target file directory entry corresponding to the target object based on the metadata structure, the target file directory entry being a data structure storing file information and directory information; determining multiple target extended area structures based on the target file directory entry, and determining multiple deleted files based on the multiple target extended area structures; performing recovery processing on the multiple deleted files to obtain the target file. In this scheme, the extended area structure represents a file using consecutive data blocks. Only the position of the first data block of the file needs to be determined to read all consecutive data blocks at once, thereby improving the efficiency of file determination and thus improving the efficiency of file recovery. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] Figure 1 This is a schematic diagram illustrating an application scenario of a file recovery method provided in an embodiment of this application;

[0024] Figure 2 A flowchart illustrating a file recovery method provided in an embodiment of this application;

[0025] Figure 3 A schematic diagram of the target file directory entries provided in an embodiment of this application;

[0026] Figure 4 A flowchart illustrating a file recovery method provided in an embodiment of this application;

[0027] Figure 5 A schematic diagram illustrating the structure of the extended region provided in this application embodiment;

[0028] Figure 6 This is a schematic diagram illustrating the acquisition and deletion of files provided in an embodiment of this application;

[0029] Figure 7 This is a schematic diagram of the structure of a file recovery device provided in an embodiment of this application;

[0030] Figure 8 This is a schematic diagram of the structure of a file recovery device provided in an embodiment of this application;

[0031] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0032] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0033] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0034] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse.

[0035] It should be noted that the document recovery method, apparatus, electronic device, storage medium and product of this application can be used in the field of data management technology, and can also be used in any field other than data management. The application field of the document recovery method, apparatus, electronic device, storage medium and product of this application is not limited.

[0036] Figure 1 This is a schematic diagram illustrating an application scenario of a file recovery method provided in this application embodiment. An example is given based on the illustrated scenario: receiving a file recovery request, locating the deleted file according to the file recovery request, and performing file recovery processing on the deleted file to realize the file recovery request.

[0037] Ext4 incorporates several improvements, including support for larger files and partitions, optimized file allocation strategies, and enhanced overall file system performance. It also strengthens journaling capabilities, improving data integrity and reliability. Furthermore, Ext4 supports larger file systems and file sizes, enabling it to better handle large-scale data processing.

[0038] The Extended Extent structure is a data structure in the Ext4 file system used to manage and allocate file data blocks. Traditional indirect block pointer methods require storing a pointer for each data block, leading to significant metadata overhead. The Extended Extent structure, however, represents a portion of the file using a set of contiguous data blocks, reducing the number of pointers required. Each Extended Extent entry contains information about a set of contiguous data blocks, reducing metadata storage space and improving metadata compactness.

[0039] In related technologies, deleted files are located by reading a journaling file system. Each time a file is modified or deleted, the log file records these operations, resulting in a scattered and complex log file. To recover the file, the log records need to be parsed to determine the location of each data block corresponding to the file from the scattered and complex information; this process is inefficient.

[0040] The document recovery method provided in this application aims to solve the above-mentioned technical problems of the prior art.

[0041] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0042] Figure 2 This is a flowchart illustrating a file recovery method provided in an embodiment of this application. The method includes the following steps:

[0043] S201, Receive file recovery request.

[0044] The file recovery request includes the target object identifier of the target object.

[0045] Optionally, the target object is a specified area, and the file recovery request is used to request the recovery of deleted files within the specified area.

[0046] For example, the target object identifier is used to indicate the type of the region corresponding to the target object.

[0047] With the example scenario, the specified area can include multiple deleted files. By specifying the area, multiple files can be requested to be recovered at the same time, thereby improving the efficiency of the request.

[0048] It should be noted that this application does not limit the type of file, such as documents, images, compressed files, or videos.

[0049] S202. Based on the file recovery request, determine the metadata structure of the target file system corresponding to the target object identifier.

[0050] The metadata structure includes, but is not limited to, information such as the file system block size, file system status, available data blocks of the file system, file attributes, inodes, or usage of each data block.

[0051] Optionally, the file system block size can be calculated using the logarithmic form of the block size field. The calculation formula can be:

[0052] block_size=1<<(s_log_block+10)

[0053] Wherein, block_size is the block size of the file system, and s_log_block is the logarithmic form of the block size field information.

[0054] For example, information in a file system is stored in blocks. Reading information by the block size of the file system ensures that each read operation retrieves complete information within a block, thereby improving the accuracy of file recovery. The information read includes, but is not limited to, file directory entries, data blocks, or extended area structures.

[0055] With the illustration of a scenario, by determining the metadata structure, the file under the target object can be accurately located.

[0056] S203. Based on the metadata structure, determine the target file directory entry corresponding to the target object.

[0057] The target file directory entry is a data structure that stores file and directory information.

[0058] For example, the target file directory entry stores multi-level directories and multiple file information, with each file information located at a corresponding level.

[0059] Below, in conjunction with Figure 3 Provide a description of the target file directory entries.

[0060] Figure 3 This is a schematic diagram of the target file directory entries provided in an embodiment of this application. For example... Figure 3 As shown, the root directory includes file information 1 and subdirectory information 1, indicating that both the file corresponding to file information 1 and the subdirectory corresponding to subdirectory information 1 are located in the root directory. The next level below subdirectory information 1 includes subdirectory information 2, indicating that the subdirectory corresponding to subdirectory information 2 is located at the next level below the subdirectory corresponding to subdirectory information 1. The next level below subdirectory information 2 includes file information 2, indicating that the file corresponding to file information 2 is located at the next level below the subdirectory corresponding to subdirectory information 2.

[0061] With the help of scenario examples, it is shown that by using the target file directory entry, files can be located precisely, thereby improving the accuracy of file recovery.

[0062] S204. Based on the target file directory entries, determine the structures of multiple target extended areas, and based on the structures of multiple target extended areas, determine the multiple deleted files that have been deleted, perform recovery processing on the multiple deleted files, and obtain the target file.

[0063] Deleted files refer to files that have been removed from the operating system but whose data is still stored on the disk. By determining the location of the file's data on the disk, deleted files can be restored to the operating system.

[0064] For example, each file corresponds to an Extent structure. Each node in an Extent structure consists of a header and multiple Extent_body nodes. Extent_body nodes are of two types: inodes (ext4_extent_idx) and leaf nodes (ext4_extent). Inodes store the intermediate paths to leaf nodes, while leaf nodes record the address information corresponding to a contiguous logical block of the file, i.e., the physical disk block range.

[0065] In a scenario example, the physical disk range of the deleted file is determined by the target extended area structure. Based on the physical disk range, the data corresponding to the deleted file can be accurately located, thereby accurately achieving file recovery.

[0066] The file recovery method provided in this application involves receiving a file recovery request, which includes a target object identifier; determining the metadata structure of the target file system corresponding to the target object identifier based on the file recovery request; determining the target file directory entry corresponding to the target object based on the metadata structure, where the target file directory entry is a data structure storing file information and directory information; determining multiple target extended area structures based on the target file directory entry; determining multiple deleted files based on the multiple target extended area structures; and performing recovery processing on the multiple deleted files to obtain the target file. In this scheme, the extended area structure represents a file using consecutive data blocks. By only needing to determine the position of the first data block of the file, all consecutive data blocks can be read at once, thereby improving the efficiency of file determination and thus improving the efficiency of file recovery.

[0067] Based on any of the above embodiments, the following, in conjunction with Figure 4 This section provides a detailed explanation of the file recovery process.

[0068] Figure 4 This is a flowchart illustrating a file recovery method provided in an embodiment of this application. Figure 4 As shown, the method includes:

[0069] S401, Receive file recovery request.

[0070] It should be noted that the execution process of S401 is the same as that of S201, and will not be repeated here.

[0071] S402. Based on the file recovery request, determine the metadata structure of the target file system corresponding to the target object identifier.

[0072] One feasible implementation method is to determine the metadata structure of the target file system as follows: determine the target type of the target object through system calls or command-line tools; if the target type is a disk, determine the target partition information of the target object through the target object's master boot record, and determine the target file system corresponding to the target object based on the file system signature value in the target partition information; if the target type is a partition, read the target partition information of the target object, and determine the target file system corresponding to the target object based on the file system signature value in the target partition information; determine whether the target file system is a fourth-generation extended file system; if so, determine the superblock and group descriptors from the target file system, and determine that the metadata structure includes the superblock and group descriptors.

[0073] For example, the target object specifies a range, which can be a disk or a partition. A partition is a logical area on a disk that can be managed and used independently, and each group can have its own file system. If the target object is a partition, the target file system can be directly determined by the file system signature value in the target partition information. If the target object is a disk, it can include multiple partitions, which may correspond to different file systems. The file system type for each partition needs to be determined sequentially to avoid data conflicts between different partitions.

[0074] Optionally, the starting sector of the partition can be read, the file system signature value can be determined from the initial sector, and the file system type of the partition can be determined based on the file system signature value. It can be understood that by reading the starting sector of the partition, the file system type can be quickly identified without traversing the entire partition, thus improving the efficiency of file recovery.

[0075] For example, different file systems have different metadata structures. Ext4 can accurately locate deleted files through the superblock and group descriptors, so it is necessary to verify whether the target file system is Ext4.

[0076] Optionally, if the target object is a disk, which includes both Ext4 and non-Ext4 partitions, then only the metadata structure of the Ext4 partitions is determined.

[0077] In this feasible implementation, by accurately identifying the file system type of the target object, erroneous operations on partitions of other file systems can be avoided, reducing the risk of data corruption.

[0078] S403. Determine the root directory index node from the metadata structure.

[0079] Optionally, index node 2 can be determined from the metadata structure and designated as the root directory index node. Designating index node 2 as the root directory index node is a common practice.

[0080] With the help of scenario examples, the root directory inode is the unique identifier of the root directory in the file system. It can be used to accurately find all files and subdirectories in the hierarchical structure of the file system.

[0081] S404. Determine the root directory based on the root directory inode, and determine the target file directory entry from the root directory.

[0082] The root directory is the starting point of the file system hierarchy, and all files and directories begin from the root directory.

[0083] For example, starting from the root directory, the entire directory is traversed to obtain the target file directory entries, which include directories and / or files at each level.

[0084] Based on the above implementation method, the directory tree of the entire file system can be constructed by traversing the data, avoiding omissions and thus improving the accuracy of file recovery.

[0085] S405. Determine multiple candidate file identifiers from the target file directory entries through recursion.

[0086] The candidate file identifier is the identifier of all files in the directory entry.

[0087] One feasible implementation method is to determine multiple candidate file identifiers as follows: From the target file directory entries, determine multiple file system objects under the root directory, and multiple object types corresponding to these file system objects. Object types include subdirectories or files. For any file system object, if the corresponding object type is a subdirectory, read the sub-objects under the file system object until a sub-object of type file is read, and determine the first file identifier of the sub-object, adding the first file identifier to the target group. If the file system object is a file, determine the second file identifier of the file system object, adding the first file identifier to the target group. The determination of multiple candidate file identifiers includes both the first and second file identifiers in the target group.

[0088] With the example scenario, the root directory can include subdirectories and / or files. For files in the root directory, the file identifier is directly obtained and added to the target group. For subdirectories under the root directory, the process recursively enters each subdirectory, continues reading the sub-objects within the subdirectory, determines the type of the sub-object, records its file identifier and adds it to the target group if it is a file, and continues recursively processing if it is a subdirectory until no further subdirectories exist under the subdirectory. The target group includes the candidate file identifiers of all files in the target file directory entry.

[0089] In this feasible implementation, all candidate file identifiers are obtained through recursive traversal to avoid omissions, thereby improving the accuracy of file recovery.

[0090] S406. Based on the metadata structure, determine the multiple deletion time field information corresponding to multiple candidate file identifiers.

[0091] For example, the delete time field of the file node corresponding to each candidate file identifier is determined from the metadata structure. The delete time field information is the specific value of the delete time field, and the corresponding file is determined to be deleted based on the specific value.

[0092] Optionally, the candidate file is identified by its index inode number. The corresponding inode information is read from the inode table using the inode number, and the timestamp field is extracted by parsing the inode information. The timestamp field includes the deletion time field.

[0093] The metadata structure includes an inode table, which stores the inode information of the file. The inode information includes various attributes of the file, including but not limited to file type, file permissions, file size, file owner, or timestamp.

[0094] Based on the above implementation methods, by determining the deletion time field, the deletion time of the file can be accurately determined, thereby improving the accuracy of file recovery.

[0095] S407. Based on multiple deletion time field information, determine multiple delete file identifiers from multiple candidate file identifiers.

[0096] In this case, the deletion time field of any deleted file identifier is not 0.

[0097] For example, a deletion time field value of 0 indicates that the corresponding file has not been deleted, while a deletion time field value of non-0 indicates that the corresponding file has been deleted. The specific value of the deletion time field is the moment of deletion.

[0098] With the help of scenario examples, the deletion time field information can be used to quickly identify the deleted file, thereby improving the efficiency of file recovery.

[0099] S408. Based on the metadata structure, determine the structures of multiple target extension areas corresponding to multiple deleted file identifiers.

[0100] For example, the metadata structure includes an inode table, from which the target extended region structure corresponding to multiple deleted file identifiers is determined.

[0101] Below, in conjunction with Figure 5 The structure of the extended region is explained.

[0102] Figure 5 This is a schematic diagram illustrating the structure of the defined extension region provided in an embodiment of this application. For example... Figure 5 As shown, multiple candidate file identifiers are obtained by recursively traversing each level of the target file directory entries. Based on the deletion time field, multiple deleted file identifiers corresponding to deleted files are determined from the multiple candidate file identifiers. The target extended area structure corresponding to each deleted file identifier is then determined.

[0103] Based on the above implementation methods, by determining the extended area structure, the location of data blocks of deleted files can be quickly located, thereby improving the efficiency of file recovery.

[0104] S409. Based on the structure of multiple target extended regions, determine the multiple deleted files that have been deleted, perform recovery processing on the multiple deleted files, and obtain the target file.

[0105] Optionally, recovery information can be generated based on the target file being recovered, and the recovery information can be visualized so that users can intuitively determine the recovery information.

[0106] One feasible implementation method, for any target extension region structure, is as follows: determine the file to be deleted by: determining the first field information of the extension region header through the target extension region structure, the first field information including whether the extension region header is valid or invalid; if the first field information indicates that the extension region header is valid, then obtain the target address information from the extension region header; and determine the file to be deleted based on the target address information.

[0107] For example, multiple fields of information are determined by the target extension area structure. The first field, such as the eh_magic field, indicates the validity of the extension area header. Only when the extension area header is valid, the target address information is further obtained from the extension area header. The target address information is the range of physical disk blocks where the file to be deleted is located.

[0108] Optionally, the disk device can be opened using file operation functions to obtain the data corresponding to the target address information, and multiple data sets can be concatenated to obtain a complete file.

[0109] Below, in conjunction with Figure 6 Instructions for retrieving and deleting files.

[0110] Figure 6 This is a schematic diagram illustrating the acquisition and deletion of files as provided in an embodiment of this application. Figure 6 As shown, based on the target extended region structure, the first field information of the extended region header is determined. The validity of the extended region header is then determined based on this first field information. If invalid, file recovery is terminated. If valid, the target address information is determined from the extended region header, and the deleted file is retrieved based on the address corresponding to that target address.

[0111] In this feasible implementation method, the target address information can be accurately determined through validity judgment, thereby improving the accuracy of file recovery.

[0112] Figure 7 This is a schematic diagram of a file recovery device provided in an embodiment of this application. Figure 7 As shown, the file recovery device 70 may include: a request module 71, a determination module 72, a processing module 73, and a recovery module 74, wherein,

[0113] Request module 71 is used to receive file recovery requests, which include the target object identifier of the target object.

[0114] The determination module 72 is used to determine the metadata structure of the target file system corresponding to the target object identifier based on the file recovery request.

[0115] Processing module 73 is used to determine the target file directory entry corresponding to the target object based on the metadata structure. The target file directory entry is a data structure that stores file information and directory information.

[0116] The recovery module 74 is used to determine multiple target extension area structures based on the target file directory entries, and to determine multiple deleted files that have been deleted based on the multiple target extension area structures, and to perform recovery processing on the multiple deleted files to obtain the target file.

[0117] Optionally, request module 71 can execute Figure 2 S201 in the embodiment.

[0118] Optionally, module 72 can be executed. Figure 2 S202 in the embodiment.

[0119] Optionally, processing module 73 can execute Figure 2 S203 in the embodiment.

[0120] Optionally, recovery module 74 can execute Figure 2 S204 in the embodiment.

[0121] It should be noted that the file recovery device shown in the embodiments of this application can execute the technical solution shown in the above method embodiments, and its implementation principle and beneficial effects are similar, so they will not be described again here.

[0122] In one possible implementation, the determining module 72 is specifically used for:

[0123] The target type of the target object is determined through system calls or command-line tools. The target type includes disks or partitions.

[0124] If the target type is a disk, the target partition information of the target object is determined by the master boot record of the target object, and the target file system corresponding to the target object is determined by the file system signature value in the target partition information;

[0125] If the target type is a partition, then read the target partition information of the target object and determine the target file system corresponding to the target object based on the file system signature value in the target partition information;

[0126] Determine whether the target file system is a fourth-generation extended file system. If so, determine the superblock and group descriptors from the target file system, and determine the metadata structure including the superblock and group descriptors.

[0127] Figure 8 This is a schematic diagram of a file recovery device provided in an embodiment of this application. Figure 7 Based on the illustrated embodiments, as Figure 8 As shown, the file recovery device 80 further includes: a search module 75, a traversal module 76, and a verification module 77, wherein,

[0128] Lookup module 75 is used for:

[0129] Identify the root directory index node from the metadata structure;

[0130] Based on the root directory inode, determine the root directory, and then determine the target file directory entry from the root directory.

[0131] Traversal module 76, used for:

[0132] Multiple candidate file identifiers are determined from the target file directory entries using a recursive approach;

[0133] Based on the metadata structure, determine the deletion time field information corresponding to multiple candidate file identifiers;

[0134] Based on multiple deletion time field information, multiple file identifiers to be deleted are determined from multiple candidate file identifiers, wherein the deletion time field information of any file identifier to be deleted is not 0;

[0135] Based on the metadata structure, determine the structures of multiple target extension regions corresponding to multiple deleted file identifiers.

[0136] In one possible implementation, traversal module 76 is specifically used for:

[0137] Determine multiple file system objects under the root directory from the target file directory entry, as well as multiple object types corresponding to the multiple file system objects. The object types include subdirectories or files.

[0138] For any file system object, if the corresponding object type is a subdirectory, then read the sub-objects under the file system object until a sub-object of type file is read, determine the first file identifier of the sub-object, and add the first file identifier to the target group;

[0139] If the file system object is a file, determine the second file identifier of the file system object and add the first file identifier to the target group;

[0140] Multiple candidate file identifiers are identified, including the first file identifier and the second file identifier in the target group.

[0141] For any target extended region structure; verification module 77, used for:

[0142] The first field information of the extension header is determined by the target extension header structure. The first field information includes whether the extension header is valid or invalid.

[0143] If the first field information is valid for the extended header, then the target address information is obtained from the extended header;

[0144] Based on the target address information, determine which file to delete.

[0145] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 9 As shown, the electronic device includes:

[0146] The electronic device includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, memory 292, and communication interface 293 can communicate with each other via the bus 294. The communication interface 293 can be used for information transmission. The processor 291 can invoke logical instructions stored in the memory 292 to execute the methods of the above embodiments.

[0147] Furthermore, the logic instructions in the aforementioned memory 292 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0148] The memory 292, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, thereby implementing the methods in the above-described method embodiments.

[0149] The memory 292 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 292 may include high-speed random access memory and may also include non-volatile memory.

[0150] This application provides a non-transitory computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods described in the foregoing embodiments.

[0151] This application provides a computer program product, including a computer program that, when executed by a processor, implements the method as described in the foregoing embodiments.

[0152] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0153] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0154] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0155] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0156] When the integrated unit / module is implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. The processor can be any suitable hardware processor, such as CPU, GPU, FPGA, DSP, and ASIC. The storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0157] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 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 of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0158] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0159] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0160] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A file recovery method characterized by, include: Receive a file recovery request, wherein the file recovery request includes the target object identifier of the target object; Based on the file recovery request, determine the metadata structure of the target file system corresponding to the target object identifier; Based on the metadata structure, the target file directory entry corresponding to the target object is determined, wherein the target file directory entry is a data structure that stores file information and directory information; Based on the target file directory entries, multiple target extension area structures are determined, and multiple deleted files that have been deleted are identified based on the multiple target extension area structures. The multiple deleted files are then recovered to obtain the target file.

2. The method of claim 1, wherein, Determining the metadata structure of the target file system corresponding to the target object identifier includes: The target type of the target object is determined by system calls or command-line tools, and the target type includes a disk or partition. If the target type is a disk, the target partition information of the target object is determined through the master boot record of the target object, and the target file system corresponding to the target object is determined according to the file system signature value in the target partition information; If the target type is a partition, then read the target partition information of the target object, and determine the target file system corresponding to the target object based on the file system signature value in the target partition information; Determine whether the target file system is a fourth-generation extended file system. If so, determine the superblock and group descriptor from the target file system, and determine that the metadata structure includes the superblock and the group descriptor.

3. The method according to claim 1 or 2, characterized in that, Based on the metadata structure, the target file directory entry corresponding to the target object is determined, including: The root directory index node is determined from the metadata structure; Based on the root directory inode, determine the root directory, and from the root directory, determine the target file directory entry.

4. The method according to any one of claims 1 to 3, characterized in that, Based on the target file directory entries, determine multiple target extension region structures, including: Multiple candidate file identifiers are determined from the target file directory entries using a recursive approach. Based on the metadata structure, determine the multiple deletion time field information corresponding to the multiple candidate file identifiers; Based on the multiple deletion time field information, multiple delete file identifiers are determined from the multiple candidate file identifiers, wherein the deletion time field information of any delete file identifier is not 0; Based on the metadata structure, determine the multiple target extension area structures corresponding to the multiple deleted file identifiers.

5. The method of claim 4, wherein, Multiple candidate file identifiers are determined recursively from the target file directory entries, including: From the target file directory entry, determine multiple file system objects under the root directory, and multiple object types corresponding to the multiple file system objects, wherein the object types include subdirectories or files; For any file system object, if the corresponding object type is a subdirectory, then read the sub-objects under the file system object until a sub-object of object type is a file is read, and determine the first file identifier of the sub-object, and add the first file identifier to the target group; If the file system object is a file, determine the second file identifier of the file system object and add the first file identifier to the target group; The plurality of candidate file identifiers are determined to include the first file identifier and the second file identifier in the target group.

6. The method according to any one of claims 1-5, characterized in that, For any given target extended region structure; determining the file to be deleted based on the target extended region structure, including: The first field information of the extension region header is determined by the target extension region structure, and the first field information includes whether the extension region header is valid or invalid. If the first field information is a valid extended header, then the target address information is obtained from the extended header; The file to be deleted is determined based on the target address information.

7. A file recovery apparatus characterized by comprising: include: The request module is used to receive file recovery requests, wherein the file recovery request includes the target object identifier of the target object; The determination module is used to determine the metadata structure of the target file system corresponding to the target object identifier based on the file recovery request; The processing module is used to determine the target file directory entry corresponding to the target object based on the metadata structure, wherein the target file directory entry is a data structure that stores file information and directory information; The recovery module is used to determine multiple target extended area structures based on the target file directory entries, determine multiple deleted files based on the multiple target extended area structures, and perform recovery processing on the multiple deleted files to obtain the target file.

8. An electronic device, comprising: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterised in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images